December 2018 License-Review 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:
* License committee report and review status changes
* Server Side Public License, Version 2 (SSPL v2)
* Support for SSPL v2
* (A new license review process is being [discussed on the license-discuss list][new-process])
[new-process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020157.html
License-Discuss summary:
## License committee report and review status changes
[Report by Richard Fontana][Report]
libpng license: [Cosmin Truta] withdraws the license.
SSPLv2: discussion will continue on the revised version.
YetiForce Public License 3.0: [rejected][YetiForce].
License Zero Public License (L0-R): [no decision][L0-R] because it had been effectively withdrawn.
Convertible Free Software License, Version 1.1: [approval withheld][C-FSL] pending a redrafted version. Elmar Stellnberger (the license submitter) is not certain which points would have to be changed. [Carlo Piana][Piana:convertible] emphasizes that giving the original authors special relicensing rights is discriminatory, especially in case of a fork.
[Report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003869.html
[Cosmin Truta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003874.html
[YetiForce]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003854.html
[L0-R]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003855.html
[C-FSL]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003856.html
[Piana:convertible]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003862.html
## Server Side Public License, Version 2 (SSPL v2)
On Nov 21, the [SSPL v2] has been submitted for review.
[SSPL v2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.html
[Eric Schultz][Schultz] feels the revision has not been made in good faith and finds no substantial improvements. Schultz is particularly concerned that the “limitations what code is included on Section 13 seem practically limitless because Service is not defined.”
[Bruce Perens][BP:Deshpande] links to [Sunil Deshpande’s comments on the SSPL][Deshpande] and feels “it manifests a lot of ignorance about Open Source and utter contempt for our community.” [Eliot Horowitz (MongoDB)][Horowitz] responds that Deshpande is unaffiliated with MongoDB. Instead, Horowitz points to an [article on his blog][Horowitz:blog]. He also responds to individual issues:
Is it a problem that the SSPL extends to other software? Horowitz argues “no”: combining services over a network is the new dynamic linking, so it’s OK to extend copyleft. (Note: this fails to consider the bounds of copyright, and that the SSPL would not just affect other services but e.g. deployment tools.) [McCoy Smith][Smith] is also concerned that the SSPL could require the disclosure of software that is similar or reverse engineered, without being a derivative work in the sense of copyright.
What constitutes making the Program available as a service? Horowitz claims that the SSPL’s definition is easier to understand than the comparable section in the AGPL, and says the license cannot be more specific while remaining technology-agnostic and understandable.
[Florian Weimer][Weimer:service] asks whether this would include services like providing pre-built binaries. [Horowitz (MongoDB) responds][Horowitz:service] that the terms covering distribution of binaries are identical with the GPL. Horowitz explains that running the software as a service here means running the software on behalf of someone else, and that this meaning is common and well understood.
(Note: I previously read the SSPL with service as in service oriented architecture, not as in cleaning service. Apparently, only service as in SaaS/PaaS is meant. Common usage or not, this is quite ambiguous.)
[Lawrence Rosen][LR:available] takes issue with the SSPL’s “making available” definition: the “value” of a service cannot be calculated, and what a program “accomplishes for users” is subjective and addled by marketing. “You have created, at least in part, an unenforceable FOSS license with a nicer definition than AGPL of “program as a service” that still doesn’t help much. :-)”
Nevertheless, Rosen thinks the flaws of the SSPL do not prevent it from being an open source license and votes for approval as an experimental license.
[Schultz]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003847.html
[BP:Deshpande]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003851.html
[Deshpande]: https://techcrunch.com/2018/11/29/the-crusade-against-open-source-abuse/
[Horowitz]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003863.html
[Horowitz:blog]: http://www.eliothorowitz.com/blog/2018/12/11/open-source-and-the-sspl/
[LR:available]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003864.html
[Smith]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003865.html
[Weimer:service]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003885.html
[Horowitz:service]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003889.html
## Support for SSPL v2
[Greg Luck (Hazelcast)][Luck:support] voices support for the SSPL v2. He argues that there is a need for an OSI-approved license addressing the issues raised by the Commons Clause and SSPL in order to prevent proliferation of open source-ish licenses in this area. Luck considers [GPLv3 style copyleft][Luck:gpl] and [even the AGPL][Luck:agpl] insufficient at preventing service wrapping by cloud providers. In his understanding, copyleft should prevent selling free software or the original developers should get a fair share of the profits.
[Luck:support]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003866.html
[Luck:gpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003868.html
[Luck:agpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003878.html
[Rob Landley][Landley] responds that Stallman was well aware of the “service provider loophole” prior to creating the (A)GPLv3 license family. “If he and Eben Moglen working together for half a decade couldn’t manage to address the issue and still call the result “Free Software”, what makes you think you’re going to?” Landley accuses SSPL supporters of wishful thinking: “that’s now how copyright law and open source work”.
[Carlo Piana][Piana:SSPL] sympathizes with Luck’s sentiment but doesn’t think the SSPL should be the license that OSI approves for this purpose. Piana is particularly concerned that the SSPL is so unclear in so many scenarios that most users are effectively forced to obtain a proprietary license. “It’s the dual licensing paradigm on steroids”. [Nigel T][NigelT:1] concurs and suggests that it’s not the responsibility of open source to enable a particular business model: “If you don’t want folks to profit from your codebase just make it shared source and move on.”
[Bruce Perens][BP:special] adds that the “OSI doesn’t prevent you from using any license. Just don’t call it Open Source.” Perens points out that the OSD/DFSG ban on usage restrictions excludes some special interests, e.g. educational-only software. This is necessary so that an open source system can be used with legal certainty, for any purpose. But where are the communities that promote special non-open source licenses? “IMO the problem for some of the proposed licenses is not a lack of OSI’s approval, but a lack of interest.” [Nigel T][NigelT:2] points at CC-NC as a non-open license with a large community.
Perens [also responds][BP:tent] that any confusion due to a proliferation of non-OSS licenses “will not be OSI or Open Source’s problem. You create this problem by leaving the tent.”
[Brendan Hickey][Hickey:sspl] points out Luck’s misunderstanding of Free Software: it’s about reciprocity, not about encumbering commercial interests. Furthermore, Hickey argues that cloud providers sell reliability, not software. Therefore, the SSPL will not prevent large cloud providers from profiting from hosting open source software but at most inconvenience users.
[Landley]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003867.html
[Piana:SSPL]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003870.html
[NigelT:1]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003873.html
[NigelT:2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003876.html
[BP:special]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003875.html
[Hickey:sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003871.html
[BP:tent]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003879.html
Martin Verburg (jClarity) [[1][Verburg:1],[2][Verburg:2]] chimes in with support for a common license that addresses these concerns, but advises caution – acceptance of such a license or even changing the OSD would have far-reaching and long-lasting effects. Instead he suggests a Infrastructure License Consortium in which vendors should develop a common license, independent of possible OSI approval. Regarding the SSPL, Verburg suggests to wait and watch: will other vendors take up this license?
[Verburg:1]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003881.html
[Verburg:2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003883.html