<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>