February 2019 License-Review Summary
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
The corresponding License-Discuss summary is online
at
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][fontana_report] 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.
[fontana_report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003974.html
## Convertible Free Software License
In response to last month’s review,
[Elmar Stellnberger][stellnberger_consent] clarifies that
the Original Authors have to decide via consensus
or set up their own statutes that cover their decision process.
[Rob Landley][landley_transfer]
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.
[stellnberger_consent]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003943.html
[landley_transfer]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003944.html
## Twente License
[Anand Chowdhary][chowdary_twente]
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][tzeng_twente] points out that
this fails OSD #6 “No Discrimination Against Fields of Endeavor”,
while [Josh Berkus][berkus_osd6] disagrees.
[Lawrence Rosen][rosen_twente_values]
criticizes that the license tries to enforce values:
“far more ambitious than software can protect with its mere open source licenses.”
[Eric Schultz][schultz_twente] suggests other ways than licenses
for open source projects to express values,
for example by refusing to support unethical use cases.
[Bruce Perens][perens_apartheid]
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][apartheid])
[Josh Berkus][berkus_values] 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][chowdary_values] 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 [[1][piana_twente],[2][piana_more_twente]] 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][atkinson_twente] 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][piana_transparency] 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][chowdary_controller] clarifies their goals
and starts drafting a transparency clause.
[chowdary_twente]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003945.html
[tzeng_twente]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003946.html
[berkus_osd6]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003954.html
[rosen_twente_values]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003947.html
[schultz_twente]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003949.html
[perens_apartheid]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003951.html
[apartheid]: http://www-cs-students.stanford.edu/~cale/cs201/index.html
[berkus_values]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003952.html
[chowdary_values]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003953.html
[piana_twente]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003955.html
[piana_more_twente]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003957.html
[atkinson_twente]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003962.html
[piana_transparency]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003964.html
[chowdary_controller]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003965.html
## Server Side Public License, Version 2
[Eliot Horowitz (MongoDB)][horowitz_clarification]
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][perens_clarification] 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][perens_objections] 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][hickey_objections] 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][mitchell_lgtm] finds that
Horowitz’ clarifications address the objections he had.
[horowitz_clarification]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003975.html
[perens_clarification]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003976.html
[perens_objections]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003977.html
[hickey_objections]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003980.html
[mitchell_lgtm]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003978.html
## Review process, governance, and the OSD
In the context of the SSPL review,
[Kyle Mitchell][mitchell_lgtm] 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][moen_listen] 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][perens_honcho] 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][mitchell_what_osd] 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][perens_line] 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][rosen_discuss]
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][mitchell_silent] 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][perens_silent] 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
for information on how to subscribe.
[moen_listen]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003981.html
[perens_honcho]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003979.html
[mitchell_what_osd]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003985.html
[perens_line]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003986.html
[rosen_discuss]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003982.html
[mitchell_silent]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003983.html
[perens_silent]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-February/003984.html