<div dir="ltr"><div dir="ltr"><div dir="ltr"><p>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 <a href="https://opensource.org/LicenseReview122018">version on the OSI blog</a> 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.</p>
<p>This month’s topics:</p>
<ul><li>License committee report and review status changes</li><li>Server Side Public License, Version 2 (SSPL v2)</li><li>Support for SSPL v2</li><li>(A new license review process is being discussed on the license-discuss list)</li></ul>

<p><b id="gmail-license-committee-report-and-review-status-changes">License committee report and review status changes</b></p>
<p>Report by Richard Fontana</p>
<p>libpng license: Cosmin Truta withdraws the license.</p>
<p>SSPLv2: discussion will continue on the revised version.</p>
<p>YetiForce Public License 3.0: rejected.</p>
<p>License Zero Public License (L0-R): no decision because it had been effectively withdrawn.</p>
<p>Convertible Free Software License, Version 1.1: approval withheld 
pending a redrafted version. Elmar Stellnberger (the license submitter) 
is not certain which points would have to be changed. Carlo Piana 
emphasizes that giving the original authors special relicensing rights 
is discriminatory, especially in case of a fork.</p>
<p><b id="gmail-server-side-public-license-version-2-sspl-v2">Server Side Public License, Version 2 (SSPL v2)</b></p>
<p>On Nov 21, the SSPL v2 has been submitted for review.</p>
<p>Eric 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.”</p>
<p>Bruce Perens links to <a href="https://techcrunch.com/2018/11/29/the-crusade-against-open-source-abuse/">Sunil Deshpande’s comments on the SSPL</a>
 and feels “it manifests a lot of ignorance about Open Source and utter 
contempt for our community.” Eliot Horowitz (MongoDB) responds that 
Deshpande is unaffiliated with MongoDB. Instead, Horowitz points to an <a href="http://www.eliothorowitz.com/blog/2018/12/11/open-source-and-the-sspl/">article on his blog</a>. He also responds to individual issues:</p>
<p>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 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.</p>
<p>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.</p>
<p>Florian Weimer asks whether this would include services like 
providing pre-built binaries. Horowitz (MongoDB) responds 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.</p>
<p>(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.)</p>
<p>Lawrence Rosen 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. :-)”</p>
<p>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.</p>
<p><b id="gmail-support-for-sspl-v2">Support for SSPL v2</b></p>
<p>Greg Luck (Hazelcast) 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 and even the 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.</p>
<p>Rob 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”.</p>
<p>Carlo Piana 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 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.”</p>
<p>Bruce Perens 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 points at CC-NC as a non-open
 license with a large community.</p>
<p>Perens also responds 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.”</p>
<p>Brendan Hickey 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.</p>
<p>Martin Verburg (jClarity)  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?</p></div></div></div>