[License-review] 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/LicenseReview122018> 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:

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

*License committee report and review status changes*

Report by Richard Fontana

libpng license: Cosmin Truta withdraws the license.

SSPLv2: discussion will continue on the revised version.

YetiForce Public License 3.0: rejected.

License Zero Public License (L0-R): no decision because it had been
effectively withdrawn.

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.

*Server Side Public License, Version 2 (SSPL v2)*

On Nov 21, the SSPL v2 has been submitted for review.

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

Bruce Perens links to Sunil Deshpande’s comments on the SSPL
<https://techcrunch.com/2018/11/29/the-crusade-against-open-source-abuse/>
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 article
on his blog
<http://www.eliothorowitz.com/blog/2018/12/11/open-source-and-the-sspl/>.
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 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 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.

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

*Support for SSPL v2*

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.

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

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

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.

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

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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190107/338e3147/attachment.html>