December 2018 License-Discuss List Summary
I’ve been asked to provide monthly summaries of the license-review and license-discuss mailing lists.
The summaries will also be posted on their respective lists, though this blog version includes detailed links into the list archives.
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
License-Review summary:
## International Licenses Redux
[Richard Fontana suggests][RF:international] that the “International” [license category][Categories] 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][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].”
[RF:international]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020156.html
[Milinkovich]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020160.html
[Categories]: https://opensource.org/licenses/category
## Proposed license decision process
[Richard Fontana posts a draft][RF:process] 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.
[RF:process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020157.html
[Bruce Perens][BP:freedom] appreciates that “software freedom” is an explicit goal of the proposed decision process, but notes that the term can be unclear. [Lawrence Rosen argues][LR:freedom] that open source should be based on a [more pragmatic definition][LR:consideration].
[BP:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020159.html
[LR:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020162.html
[LR:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020189.html
[Luis Villa asks][LV:freedom] about a specific test for software freedom, and whether license review would be coordinated with the FSF. [Richard Fontana replies][RF:freedom] 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.
[LV:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020163.html
[RF:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020165.html
What about harmful licenses that have been accepted by the OSI in the past? [Perens][BP:example] specifically considers the SIL Open Font License. [Rick Moen][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][LV:cleanup] 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][Weinstock:consideration] would prefer existing licenses to be grandfathered.
[BP:example]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020168.html
[Moen]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020170.html
[LV:cleanup]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020173.html
[Weinstock:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020172.html
## “Consideration” in open source licenses
As a more pragmatic basis for the license review process than “software freedom”, [Lawrence Rosen proposes][LR:consideration]:
> “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][Weimer] that this term is difficult to understand outside of common law. For example, [Kevin P. Fleming][Fleming:consideration] and [Nicholas Weinstock][Weinstock:edgecase] note that the copyleft requirement to distribute source code might be interpreted as a consideration. [Bruce Perens responds][BP:consideration] that the Jacobsen v. Katzer case shows that open source licenses do indeed have non-monetary considerations.
[Lawrence Rosen insists][LR:condition] 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][Weinstock:consideration]. Perhaps the concepts can be distinguished by whether rights are surrendered or gained? [Rosen][LR:peppercorn] 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]”.
[Nigel Tzeng][Tzeng:consideration] 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][LR:consideration] 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][Weinstock:edgecase] notes that the BSD license might fail that criterion since it has no express patent grant. [Lawrence Rosen][LR:condition] 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.
[Weimer]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020183.html
[Fleming:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020185.html
[Weinstock:edgecase]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020169.html
[BP:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020186.html
[Tzeng:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020188.html
[LR:condition]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020171.html
[LR:peppercorn]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020174.html
[Peppercorns]: https://en.wikipedia.org/wiki/Peppercorn_(legal)
## Open source license with obligation to display an attribution?
Simon Cox asks [[1][Cox:1],[2][Cox:2],[3][Cox:3]] 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][Kellat].
[Cox:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020123.html
[Cox:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020127.html
[Cox:3]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020138.html
[Kellat]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020143.html
Such attributions can be tricky. [Danese Cooper recalls][Cooper] the tension between the OSI-approved Attribution Assurance License [AAL] and SugarCRM’s previous requirement to display their logo in the middle of each page (cf [ZDNet]) which was considered counter to the OSD. [David Woolley][Woolley] mentions the difficulty around the advertising clause in the 4-clause BSD license.
[Cooper]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020124.html
[AAL]: https://opensource.org/licenses/AAL
[Woolley]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020125.html
[ZDNet]: https://www.zdnet.com/article/podcast-sugarcrm-ceo-says-attribution-in-open-source-licenses-is-about-fairness/
Antoine Thomas notes [[1][Thomas:1],[2][Thomas:2]] that attribution is usually not a problem since all attributions in a software are typically gathered on a separate page. [Thorsten Glaser responds][Glaser:1] that this is only possible if the license is technology-neutral and doesn’t prescribe a specific attribution style. Glaser also [raises the issue][Glaser:2] that a requirement for public attribution could fail the “Dissident” or “Desert Island” test (see [DFSG]).
[Thomas:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020126.html
[Thomas:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020128.html
[Glaser:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020133.html
[Glaser:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020134.html
[DFSG]: https://people.debian.org/~bap/dfsg-faq.html#testing
[Bruce Perens mentions][BP:badgeware] 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][LR:badgeware] that OSD #10 “License Must Be Technology Neutral” prevents some badgeware licenses.
[BP:badgeware]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020131.html
[LR:badgeware]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020132.html
Bruce Perens notes that attribution requests rather than requirements are unproblematic. [Lawrence Rosen][LR:requirements] 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.’”
[BP:requirements]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020139.html
[LR:requirements]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020140.html
Chris Lamb suggests [[1][Lamb:1],[2][Lamb:2]] 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][LR:GPL] that the GPLv3 “doesn’t protect attribution in derivative works.”
[Lamb:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020141.html
[Lamb:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020145.html
[LR:GPL]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020142.html
Regarding the Government Open Source Software (GOSS) attribution aspect, [Nigel Tzeng][Tzeng:1] 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][JJ] and [Lawrence Rosen][LR:GOSS] 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][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][Tzeng:2] points to the [NASA] and [ECL] licenses as examples where other public sector needs already made specific licenses necessary.
[Tzeng:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020146.html
[Tzeng:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020152.html
[NASA]: https://opensource.org/licenses/NASA-1.3
[ECL]: https://opensource.org/licenses/ECL-2.0
[JJ]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020147.html
[LR:GOSS]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020150.html
[Morrison]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020151.html
## 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][Mitchell] followed up on two points from November. Responding to the older [Freedom or Power?] 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.
[Mitchell]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020181.html
[Freedom or Power?]: https://www.gnu.org/philosophy/freedom-or-power.en.html
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][Weimer:replication] 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.
[Weimer:replication]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020184.html
Should a license review focus on the license text or its potential use? [Florian Weimer][Weimer:opencore] prefers a textual review because this avoids having to take a stance on Open Core business models. [Brendan Hickey][Hickey:opencore] clarifies that a 2010 post on the OSI blog about this is a personal opinion and not official OSI stance.
[Weimer:opencore]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003884.html
[Hickey:opencore]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003886.html