January 2019 License-Review Summary
In January, the License-Review mailing list discussed:
* the new license review process
* Server Side Public License, Version 2 (SSPL v2)
* Convertible Free Software License, Version 1.3 (C-FSL v1.3)
* What are the problems with Original Authors?
* How is the C-FSL different from CLAs or permissive licenses?
* Why is the publication requirement a problem?
* Can the C-FSL be OSI-approved?
* Convertible Free Software License, Version 1.4 (C-FSL v1.4)
The corresponding License-Discuss summary is online
at
and covers discussion on
the opensource.dev info site,
Open Data,
“intimacy” in open source licenses,
relicensing and maintainer–community dynamics,
and VanL’s upcoming license.
## License Committee Report
Richard Fontana provides the license committee report
[[1][fontana-report],[2][fontana-process]].
The new license review process has been adopted,
and will apply for ongoing reviews.
[Simon Phipps][phipps-process] clarifies
that the OSI Board will handle review decisions like any other board vote,
but taking into account the advice and discussion
on the license-review mailing list
[Phipps confirms][phipps-process2] that this new process means
that “Stallman’s four freedoms are an assumed precondition for evaluation.”
OSI-approved licenses should be fine for general use,
and ensure a level playing field.
SSPL v2: the discussion is ongoing.
The board will decide on 2019-02-18.
C-FSL v1.3: approval of the previous version was withheld,
and version 1.3 was submitted.
The board will decide on 2019-02-18.
[Bruce Perens][perens-report] suggests
that both licenses should be rejected:
The new version of the C-FSL
just seems to package the same discriminatory terms
in different words.
And the SSPL only receives
comments on how it conflicts with Open Source principles
or comments that argue that such a license is necessary,
without proposing a solution to these conflicts.
[fontana-report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003904.html
[fontana-process]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003926.html
[fontana-report2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003927.html
[phipps-process]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003930.html
[phipps-process2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003924.html
[perens-report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003905.html
## Server Side Public License, Version 2
[Eliot Horowitz (MongoDB)][horowitz-ann] announces that
MongoDB is working towards a new revision of the SSPL.
Horowitz clarifies that the focus on “service”
is intended to cover multiple facets:
not only offering a network service,
but also offering services that derive their *value* from the software
or services that provide the functionality of the software.
Horowitz claims that the source disclosure requirements
are narrower under the SSPL
(only when offering the software as a service)
than under the AGPL
(when users interact with modified versions of the software)
because he considers it to be
easier to determine the purpose of the use of the software
than to determine whether the software has been modified
(Note: hmm).
[Gil Yehuda][yehuda-sspl]
appreciates the clarifications of the SSPL over the AGPL,
but notes that the SSPL only seems to be OSD-compliant
for most users – but not all.
[Bruce Perens][perens-osd9] sees the SSPL as incompatible with
OSD #9 “License must not restrict other software”
because the SSPL requires the disclosure of software
that is aggregated with
but not derivative or part of the SSPL-covered software.
“I wrote #9 into the OSD to prohibit *exactly* this sort of conduct.
Exactly. The text is really clear.”
Horowitz asserts that the goal of the SSPL
is not to prevent commercial use in order to sell enterprise licenses,
merely to protect “innovative open source software”
(read: MongoDB’s own hosted offering)
from exploitation (read: competition) by large cloud vendors.
[John Cowan][cowan-value] finds this confusing: why would MongoDB
be fine with users installing MongoDB on servers in the cloud,
but not with cloud providers offering managed services?
The cloud provider would get paid either way.
[Vadim Tkachenko][tkachenko-sspl] views MongoDB’s stance as hypocritical:
they want to suppress competitors to their business model,
while still painting themselves as an Open Source company
because that drove adoption of MongoDB by developers.
[Rob Landley][landley-sspl]
notes that license or governance changes
often result in more successful forks, as in the case of XFree86/X.Org.
MongoDB’s license change to the SSPL
has already caused it to be dropped by Linux distros,
and compatible replacements (e.g. from Amazon)
or maintained forks (e.g. from Percona)
are already available.
“OSI aside, the community seems to have pretty clearly spoken.”
However, [Nigel Tzeng][tzeng-sspl] cautions
that this is a matter of long-term investment.
MongoDB will certainly continue to invest into their core product,
whereas forks might not see comparable effort.
[Carlo Piana][piana-sspl] insists
that the review should focus on the legally binding license text,
not on MongoDB’s intention.
However, this also means that Horowitz’ clarifications are irrelevant
unless they become part of the license.
[horowitz-ann]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003933.html
[yehuda-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003934.html
[perens-osd9]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003935.html
[cowan-value]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003936.html
[tkachenko-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003938.html
[landley-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003939.html
[tzeng-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003941.html
[piana-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003940.html
## Convertible Free Software License, Version 1.3
Elmar Stellnberger submits a completely rewritten version of the license
[[1](http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003891.html),[2](http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003892.html)].
The goal of this license is that maintainers of an open source project
are free to change the license of the project,
and can integrate any downstream modifications.
Without the C-FSL, the project license could only be changed
if the project uses a permissive license,
if all copyright holders consent,
or if all contributors signed a Contributor License Agreement (CLA)
– but none of these ensure
that downstream modifications are available under the same license.
The C-FSL is therefore a copyleft license
where contributors give designated “Original Authors”
special relicensing rights.
The idea of this license in general
and the rewrite for the third version specifically
are viewed quite critically on the mailing list.
[Carlo Piana][piana-reaction] recognizes “substantial effort
to overcome most of the criticisms to the original version”
but [is frustrated][piana-cfsl] with the apparent lack of understanding
Stellnberger shows for this criticisms.
[Bruce Perens][perens-reaction] isn’t satisfied at all:
“When you request a “rewrite” of a license
with a *fundamental goal* that is in conflict with the OSD,
you are likely to get a rewritten license
with the same problem as the original.
And in this case we did.”
Similarly, [Brendan Hickey][hickey-cla] finds that the rewrite
“doesn’t address fundamental objections raised in the last version.
[…] There’s nothing wrong with proprietary software,
just don’t call it open source.”
There are three major criticisms of the C-FSL:
1\) The special role of Original Authors is discriminatory,
as argued by [Brendan Hickey][hickey-oa-copyright]:
“This is conceptually incompatible with the OSD.
Any license that implements this is non-free.”
2\) The C-FSL is trying to do copyright assignments in disguise.
3\) The license imposes an onerous publication requirement for all changes.
[Carlo Piana][piana-cfsl]
provides an excellent analysis of the biggest problems with the license.
[piana-reaction]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003894.html
[stellnberger-oa-copyright]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003908.html
[hickey-oa-copyright]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003910.html
[piana-cfsl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html
[phipps-asymmetric]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003924.html
[stellnberger-65]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003909.html
[landley-65]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003896.html
[landley-joint]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003919.html
[cowan-joint]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003920.html
[rosen-joint]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003921.html
[stellnberger-implicit]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003922.html
[hickey-cla]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003897.html
### What are the problems with Original Authors?
Under the C-FSL, Original Authors can be appointed
to act as the “[effective copyright holders][stellnberger-implicit]“.
These can relicense the software by themselves,
without having to acquire individual consent from all copyright holders
– contributors have given implicit consent in advance.
It is [not clear][piana-reaction]
what the rules of consensus among Original Authors are (majority vote?).
These Original Authors are [just a subset][hickey-oa-copyright]
of all copyright holders,
[which disenfranchises][piana-cfsl] other contributors.
[Simon Phipps][phipps-asymmetric] points out
that while there is precedent for asymmetric licenses,
each half must still effectively be an OSI-approved license.
(Note: Asymmetry was debated but ultimately removed
during the [approval process of the
Upstream Compatibility License][ucl-submission]
in 2016–2017.)
[ucl-submission]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2016-October/002856.html {.no-elide}
Forks can assign their own Original Authors
only if the fork is at least 65% different
– a [very high threshold][piana-reaction].
This deprives the forked project of their rights in the code.
[Stellnberger’s intention][stellnberger-65] for this hurdle
is that it prevents two concurrent groups of Original Authors.
But the freedom to fork is exactly what Open Source is about!
[Rob Landley][landley-xfree86]
writes a long email which traces through xfree96 and early Linux history,
highlighting the differences between project forks and community forks
and why a fork can be good for the community:
“what this license is trying to do with its “original developers” nonsense
does not match reality, even a little. […] It is *conceptually* broken.”
[Bruce Perens][perens-cfsl-community] agrees:
the C-FSL not only violates the OSD, it is also bad for the community.
A separate thread ensues with numerous examples of
relicensing, forks, and maintainer–community dynamics
(Note: covered in the License-Discuss summary).
The Original Authors can always appoint more Original Authors.
But this [doesn’t guarantee][piana-reaction]
that the Original Authors hold a significant copyright stake in the work.
The concept of authorship also [gets muddy][landley-65]
when code from another project is included.
[Brendan Hickey][hickey-cla] notices that
this allows the 65% rule to be circumvented,
for example by including a huge third party library,
or by including only a tiny part of the C-FSL covered code.
[Rob Landley][landley-joint] points out
that licenses don’t determine who the copyright holder is,
but what the copyright holders allow *other* people to do.
This spawns a small discussion
about the role of *joint authorship* in Open Source
[[1][cowan-joint],[2][rosen-joint]].
[landley-xfree86]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html
[perens-cfsl-community]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003901.html
### How is the C-FSL different from CLAs or permissive licenses?
The goal of this license is
that the maintainers can easily relicense the project,
without having to deal with CLAs.
If the CLAs and the C-FSL are criticized so much
why not also permissive licenses,
[Stellnberger asks][stellnberger-oa-copyright]?
Permissive licenses effectively allow anyone to relicense the code,
whereas the C-FSL assigns this right to the Original Authors
(see above criticism).
[Carlo Piana][piana-cfsl] notes that
contributors can refuse to sign a CLA
in which case their changes cannot be merged into the upstream project,
but contributors cannot refuse the C-FSL
because it applies implicitly as soon as the changes are made.
Brendan Hickey [[1][hickey-oa-copyright],[2][hickey-cla]] points out that
[Project Harmony](http://www.harmonyagreements.org/)
can be used for standard-ish CLA templates.
In any way, allowing a maintainer team to do arbitrary relicensing
is not a problem for Open Source to solve.
Note: a further problem with allowing arbitrary relicensing
is that contributors do not know up front which rights may be licensed.
Contributors must therefore assume that they retain no rights
except those explicitly licensed back through the C-FSL.
A CLA at least explicitly enumerates which rights are licensed,
and says whether they are licensed exclusively.
The C-FSL’s implicitness might be a problem
if a jurisdiction’s copyright laws
require a specific contract form for these right transfers.
### Why is the publication requirement a problem?
[Carlo Piana][piana-cfsl] notices that any changes to a C-FSL covered work
must be published within a month, even incomplete or buggy changes.
This violates the author’s right to decide whether to publish at all.
> This is APPROPRIATION, plain and simple.
> So any changes I make, whether or not released to the public,
> are contributed with an equivalent of an assignment,
> granting rights over the derivative code,
> including the copyright of the developer,
> which are not available to the developer
> and there is no way to avoid it.
[Elmar Stellnberger][stellnberger-publication] responds that
the publication requirement for buggy changes was not intentional.
And isn’t such a publication obligation
similar to the Vim or Affero licenses?
(Note: Nope.
While Vim has a publication requirement,
it also has an alternative GPLv2+ relicensing clause.
And the AGPL doesn’t require publication
except when the software is conveyed
or made available to users over a network.)
[Nigel Tzeng][tzeng-obligation]
sees this publication requirement as a deal killer.
All changes would have to be in public repositories.
And because it would be extremely easy to be non-compliant,
the C-FSL is a license trap.
[stellnberger-publication]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003913.html
[tzeng-obligation]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003918.html
### Can the C-FSL be OSI-approved?
[Brendan Hickey][hickey-oa-copyright] points out
that the Debian Project has [long argued][debian-cfsl]
that the C-FSL violates the DFSG,
so OSI will hopefully not decide differently.
[Carlo Piana][piana-cfsl] suggests that
the license might become OSD-compliant if the CLA-like aspect
only triggers on contribution to the upstream project,
not as soon as the code is modified.
“I expected something in this direction with the new license,
conversely I only see stubborn rewording
that makes it more hard to lay persons to spot
how the license in practice work.”
[Elmar Stellnberger][stellnberger-improvements] rejects this suggestion:
“That would lead the whole clause of original authors ad absurdum”
and make it too easy for other people to relicense the project.
[debian-cfsl]: https://lists.debian.org/debian-legal/2016/01/msg00023.html
[piana-reaction]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003894.html
[piana-cfsl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html
[perens-reaction]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003895.html
[hickey-oa-copyright]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003910.html
[landley-65]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003896.html
[fleming-cfsl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003923.html
[stellnberger-improvements]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003914.html
## Convertible Free Software License, Version 1.4
[Elmar Stellnberger][stellnberger-cfsl14]
submits the next revision of the C-FSL.
[Lukas Atkinson][atkinson-cfsl14]
summarizes the changes: minor clarifications and a closed loophole.
But no progress regarding the fundamental criticism has been made,
so that further review seems pointless.
[stellnberger-cfsl14]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003928.html
[atkinson-cfsl14]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003931.html