[License-review] February 2019 Summary

[Lukas Atkinson]

In February, the License-Review mailing list discussed:

   - Convertible Free Software License (C-FSL)
   - Twente License
   - Server Side Public License, Version 2 (SSPL v2)
   - Review process, governance, and the OSD

This summary can also be read online at
https://opensource.org/LicenseReview022019

The corresponding License-Discuss summary is online at
https://opensource.org/LicenseDiscuss022019 and covers discussions on how
to keep the mailing lists civil, and to what degree the business model of a
license submitter should be relevant.

*License Committee Report*

Richard Fontana provides the license committee report. Currently, three
licenses are under review:

   - C-FSL 1.4: A decision is due 2019-02-22.
   - SSPL v2: A decision is due 2019-02-18.
   - Twente License: A decision is due 2019-04-05.

*Convertible Free Software License*

In response to last month’s review, Elmar Stellnberger clarifies that the
Original Authors have to decide via consensus or set up their own statutes
that cover their decision process.

Rob Landley points out that copyright transfers must be written and signed
(at least in the US), so that a license like the C-FSL that tries to
circumvent this requirement might not hold up in court.

*Twente License*

Anand Chowdhary submits his Twente License for approval. It is an MIT-style
license, except that it also tries to ensure “European values” and privacy:
derivatives of the software may only collect and share personal data with
the user’s prior consent.

Nigel Tzeng points out that this fails OSD #6 “No Discrimination Against
Fields of Endeavor”, while Josh Berkus disagrees. Lawrence Rosen criticizes
that the license tries to enforce values: “far more ambitious than software
can protect with its mere open source licenses.” Eric Schultz suggests
other ways than licenses for open source projects to express values, for
example by refusing to support unethical use cases.

Bruce Perens adds a bit of historical background to the OSD: it was written
to with anti apartheid licenses in mind that ended up hurting innocent
people after the apartheid had ended. (Note: e.g. see Computers and the
Apartheid Regime in South Africa
<http://www-cs-students.stanford.edu/~cale/cs201/index.html>)

Josh Berkus criticizes that licenses should not mandate values because the
interpretation of these values can be quite subjective – thus making it
unclear whether the license has been violated. Anand Chowdhary responds
that while expressing certain values is the rationale of this license, the
text of the license only contains a specific, unambiguous condition.

Carlo Piana argues that it is not the job of licenses to ensure compliance
with legal obligations: “the entire concept is wrong” and fails to account
for changing laws over time.

Lukas Atkinson argues that data protection is not inherent in a software
but depends on how the software is used. Therefore, a copyright license
doesn’t offer a suitable enforcement tool. And while the license seems to
emulate the GDPR, it is both more narrow and more restrictive. Atkinson
suggests that it might be a better approach to combine the MIT-like
attribution requirement with a GDPR-like transparency requirement, but
without directly restricting the use of the software. Carlo Piana thinks
this is a good idea in principle, but that correctly implementing such a
requirement in a license would be rather difficult. In response to this,
Anand Chowdhary clarifies their goals and starts drafting a transparency
clause.

*Server Side Public License, Version 2*

Eliot Horowitz (MongoDB) responds to criticism of the SSPL’s section 13,
and provides some clarifications. Horowitz proposes a rewritten section
that explicitly defines “Software as a Service” as “enabling a user to
interact with software remotely through a computer network.”

Bruce Perens appreciates this clarification, but notes that this definition
was not subject to major objections. Instead, Perens suggest removing the
concept of “Service Source Code” in favour of sticking with the AGPL’s
Corresponding Source concept. Perens summarizes his objections: that the
Service Source Code concept attempts to encumber unrelated programs thus
running into OSD #9, and that section 13 as written restricts fields of
endeavour such as offering the software as a service, thus running into OSD
#6.

I don’t see how you can change this while keeping the intent of your
license […] subsequent alterations to the license text have not
substantially addressed [these objections].

Similarly, Brendan Hickey finds that the central objections have not been
addressed, though Hickey also points out the SSPL’s use of “value” and
“primary purpose” as problematic. “What’s so special about these claims
versus others? Simply, a license that doesn’t conform to the OSD must be
rejected. As long as these problems are unresolved everything else – like
the definition of SAAS – is just window dressing.” In contrast, Kyle
Mitchell finds that Horowitz’ clarifications address the objections he had.

*Review process, governance, and the OSD*

In the context of the SSPL review, Kyle Mitchell criticizes the OSI’s
license review process, in particular the weight given to Peren’s voice.
“I’ve lost confidence in this body’s ability to make rigorous decisions, or
even facilitate focused debate, on any remotely interesting new copyleft
license.” Rick Moen quips: “I think Bruce is permitted to be correct and
listened to, despite the admitted difficulty of his having credibility on
the subject.”

Perens responds to Mitchell that he founds his SSPL criticism solely on the
question whether the license can be Open Source: “This is not an issue of
my being a honcho, but of clearly stated rules in the OSD that the license
intent very obviously came into conflict with.” Perens is also happy to
engage with new licensing ideas when they don’t purport to be Open Source.
In turn, Mitchell disagrees that the OSD would be so clear. “If OSD 6
banned any kind of [discrimination], GPLv2 discriminated against
proprietary software makers.” “There should be a new, crips, clear rule on
open source copyleft scope. OSD 9 isn’t it.” Perens responds to individual
points in Mitchell’s message. “Free Software and Open Source drew a line in
the sand, gave it a brand, and have defended that line. There will always
be attempts to push it elsewhere, and they will always be resisted.”

Lawrence Rosen shares some of Mitchell’s concerns regarding the scopes of
the OSD versus SSPL, but thinks the discussion on these should be separated
from the SSPL. In particular:


   -

   What components or other aspects of server applications are potentially
   subject to open source copyleft?
   -

   Is “corresponding source” more than only the Original Work and
   Derivative Works as defined in copyright law? How much more?

There’s also some debate about the “silent majority” who do not participate
on the license-review list. Do they approve of everything and would speak
up otherwise? Or are they absent because they disagree with the review?
Bruce Perens suggests a third option:

Very few people in the world want to be involved with license approval. Not
even a majority of OSI directors. That’s why what happens on this list is
important. They’re all trusting us to get it right.

Note: If you’d like to participate on the lists, head over to
https://opensource.org/lists for information on how to subscribe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190304/b5bd49a3/attachment.html>