[License-discuss] 2018 December Summary

[Lukas Atkinson]

I’ve been asked by the OSI to provide monthly summaries of the
license-review and license-discuss mailing lists. Unfortunately, the large
number of references is impractical in an email, so please check out
the version
on the OSI blog <https://opensource.org/LicenseDiscuss122018> for all the
links to the individual messages. Any feedback is welcome, though replies
on the content should of course be made to the original threads.

This month’s topics:

   - International Licenses Redux
   - Proposed license decision process
   - “Consideration” in open source licenses
   - Open source license with obligation to display an attribution?
   - SSPL loose ends

*International Licenses Redux*

Richard Fontana suggests that the “International” license category
<https://opensource.org/licenses/category> should be expanded from
non-English language licenses (LiLiQ) to cover licenses “targeting specific
languages and jurisdictions”, regardless of their language (EUPL, CeCILL).
Language and jurisdiction are intertwined, as Mike Milinkovich explains:
“By convention, OSS expects English as the language of the license, but
there are places in the world where that is legally impossible [due to
statutory language requirements].”

*Proposed license decision process*

Richard Fontana posts a draft for a clarified license decision process as
discussed by the OSI Board. The proposal adds a clear Decision Date 60 days
after initial license submission after which the OSI will defer the
decision if discussion is ongoing, approve or reject the license if the
discussion is conclusive, or withhold approval if the license can be
reworked.

Bruce Perens appreciates that “software freedom” is an explicit goal of the
proposed decision process, but notes that the term can be unclear. Lawrence
Rosen argues that open source should be based on a more pragmatic
definition.

Luis Villa asks about a specific test for software freedom, and whether
license review would be coordinated with the FSF. Richard Fontana replies
that he considers the OSD to be an attempt of a definition of software
freedom, but that the OSD is limited and should not be viewed as as
checklist or interpreted too literally. Focusing on software freedom as the
actual goal would help avoid this. While Fontana would like to see greater
harmonization between OSI and FSF wrt decisions on edge-case FOSS licenses,
he doesn’t think their very different review processes should be closely
coordinated.

What about harmful licenses that have been accepted by the OSI in the past?
Perens specifically considers the SIL Open Font License. Rick Moen thinks
that these licenses are a lingering though minor problem since there’s a
community expectation to use one of the major licenses. Luis Villa thinks a
cleanup of old licenses might be a good idea and could also provide “case
law” for the new license review process. Nicholas Weinstock would prefer
existing licenses to be grandfathered.

*“Consideration” in open source licenses*

As a more pragmatic basis for the license review process than “software
freedom”, Lawrence Rosen proposes:

“Open source software” means software actually distributed under terms that
> grant a copyright and patent license from all contributors to the software
> for every licensee to access and use the complete source code, make copies
> of the software or derivative works thereof and, without payment of
> royalties or other consideration, to distribute the unmodified or modified
> software.
>
A discussion starts on the “without consideration” point. Florian Weimer
notes that this term is difficult to understand outside of common law. For
example, Kevin P. Fleming and Nicholas Weinstock note that the copyleft
requirement to distribute source code might be interpreted as a
consideration. Bruce Perens responds that the Jacobsen v. Katzer case shows
that open source licenses do indeed have non-monetary considerations.

Lawrence Rosen insists that “considerations” should not be confused with
“conditions”. Rosen claims that no open source licenses require
considerations but that the OSI accepts some license conditions
(e.g. copyleft conditions). Rosen thinks that creating open source software
or receiving attribution is its own reward. (Note: Rosen’s distinction
between considerations and conditions seems to prove Weimer’s point, and
the claim about considerations directly contradicts Perens.)

A number of OSI-approved licenses explicitly mention considerations and
conditions, as noted by Nicholas Weinstock. Perhaps the concepts can be
distinguished by whether rights are surrendered or gained? Rosen agrees
that these terms can have “subtle legal meanings, including in other
countries” but explains that a consideration can be anything valued by the
licensor, including “Peppercorns
<https://en.wikipedia.org/wiki/Peppercorn_(legal)>”.

Nigel Tzeng notes that it is exactly the acceptable level of considerations
that is at question for an open source license: “Some forms of
consideration is okay, even good. Others become overreach.” Rosen
acknowledges that and explains that he is primarily concerned about
considerations by downstream users. (Note: it seems Rosen’s gripe with
considerations is not so much the consideration itself, but that there
might not be a clear recipient of the consideration.)

Regarding the “actually distributed” part, Nicholas Weinstock notes that
the BSD license might fail that criterion since it has no express patent
grant. Lawrence Rosen agrees and would object to new licenses without an
explicit patent grant. In fact, licenses that expressly exclude patent
grants have been rejected. However, Rosen acknowledges that especially
academic licensors might only be able to provide limited grants. Rosen also
points to possible issues around open standards.

*Open source license with obligation to display an attribution?*

Simon Cox asks whether any open source license requires public attribution
as a gesture of acknowledgement, e.g. as a logo on a website. Such
attributions would make it easier to demonstrate the impact of open source
projects, especially in the public sector/GOSS as emphasized by Stephen
Michael Kellat.

Such attributions can be tricky. Danese Cooper recalls the tension between
the OSI-approved Attribution Assurance License AAL
<https://opensource.org/licenses/AAL> and SugarCRM’s previous requirement
to display their logo in the middle of each page (cf ZDNet
<https://www.zdnet.com/article/podcast-sugarcrm-ceo-says-attribution-in-open-source-licenses-is-about-fairness/>)
which was considered counter to the OSD. David Woolley mentions the
difficulty around the advertising clause in the 4-clause BSD license.

Antoine Thomas notes that attribution is usually not a problem since all
attributions in a software are typically gathered on a separate page.
Thorsten Glaser responds that this is only possible if the license is
technology-neutral and doesn’t prescribe a specific attribution style.
Glaser also raises the issue that a requirement for public attribution
could fail the “Dissident” or “Desert Island” test (see DFSG
<https://people.debian.org/~bap/dfsg-faq.html#testing>).

Bruce Perens mentions two issues with “badgeware”: It would trigger
requirements on mere use, and would make compliance infeasible for large
projects such as Debian. Lawrence Rosen points out that OSD #10 “License
Must Be Technology Neutral” prevents some badgeware licenses.

Bruce Perens notes that attribution requests rather than requirements are
unproblematic. Lawrence Rosen thinks that mild requirements are perfectly
reasonable, e.g.: “Licensee must display the name and source of the
embedded software in as prominent a manner and place as the licensee
displays its own trademarks.”

Rosen also voices an interesting view on the license review process: “Our
job is to approve licenses that experiment successfully (?) with new
license models, not to keep rejecting ways to obtain profit and recognition
from software. Let us leave it up to the marketplace to determine
acceptability of the license, as long as it is ‘open source software.’”

Chris Lamb suggests adding a rider with an attribution request to any
well-known license, e.g. the GPLv3. (Note: this could be a GPLv3 Additional
Term.) Lawrence Rosen claims that the GPLv3 “doesn’t protect attribution in
derivative works.”

Regarding the Government Open Source Software (GOSS) attribution aspect,
Nigel Tzeng expresses considerable frustration with respect to available
open source licenses and the open source community. Visible attribution is
often needed by public projects to ensure future funding.

Jim Jagielski and Lawrence Rosen disagree that GOSS would be fundamentally
different from other projects in this respect. However, Rosen agrees that
present licenses such as the GPLv3 fail to ensure sufficient attribution.

Christopher Sean Morrison lists a few US-specific problems or unresolved
legalities that GOSS faces. This limits public sector participation in open
source: “Nobody wants to be the guinea pig.” Tzeng points to the NASA
<https://opensource.org/licenses/NASA-1.3> and ECL
<https://opensource.org/licenses/ECL-2.0> licenses as examples where other
public sector needs already made specific licenses necessary.

*SSPL loose ends*

The submission of the SSPL sparked lots of discussions about copyleft and
review processes in general. A number of loose ends:

Kyle Mitchell followed up on two points from November. Responding to the
older Freedom or Power?
<https://www.gnu.org/philosophy/freedom-or-power.en.html> essay, Mitchell
notes that there isn’t just the essay’s producer–user power imbalance, but
also an imbalance between producers. Mitchell argues that non-permissive
licenses such as the SSPL are necessary to protect producers from their
competitors.

There have not been many supporters for the SSPL. Mitchell notes that the
number of supporters should not matter, so that the license review process
doesn’t turn into a popularity contest.

Previously, Kyle Mitchell had noted that some OSI-approved licenses trigger
requirements on use and not just on copying: the OSL and AGPL. Florian
Weimer thinks that the AGPL was originally intended for servers that also
serve their source code and not for open-core business models. “People who
have tried to use the AGPL in this way have been disappointed about the
effects, I believe.” Weimer wonders whether such business models were a
consideration for the OSL.

Should a license review focus on the license text or its potential use?
Florian Weimer prefers a textual review because this avoids having to take
a stance on Open Core business models. Brendan Hickey clarifies that a 2010
post on the OSI blog about this is a personal opinion and not official OSI
stance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190107/a1ca1b8e/attachment.html>