[License-review] January 2019 Summary

Lukas Atkinson opensource at lukasatkinson.de
Mon Feb 4 22:01:22 UTC 2019


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)

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

The corresponding License-Discuss summary is online at https://opensource
.org/LicenseDiscuss012019 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.

The new license review process has been adopted, and will apply for ongoing
reviews. Simon Phipps 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 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 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.

*Server Side Public License, Version 2*

Eliot Horowitz (MongoDB) 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 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 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 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
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 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 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 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.

*Convertible Free Software License, Version 1.3*

Elmar Stellnberger submits a completely rewritten version of the license.
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 recognizes “substantial effort to overcome most of the
criticisms to the original version” but is frustrated with the apparent
lack of understanding Stellnberger shows for this criticisms. Bruce Perens
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 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: “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
<http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html>
provides an excellent analysis of the biggest problems with the license.

*What are the problems with Original Authors?*

Under the C-FSL, Original Authors can be appointed to act as the “effective
copyright holders“. 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 what
the rules of consensus among Original Authors are (majority vote?).

These Original Authors are just a subset of all copyright holders, which
disenfranchises other contributors. Simon Phipps 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
<http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2016-October/002856.html>
in 2016–2017.)

Forks can assign their own Original Authors only if the fork is at least
65% different – a very high threshold. This deprives the forked project of
their rights in the code. Stellnberger’s intention 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
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 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 that the Original Authors hold a significant copyright
stake in the work. The concept of authorship also gets muddy when code from
another project is included. Brendan Hickey 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 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.

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

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

*Can the C-FSL be OSI-approved?*

Brendan Hickey points out that the Debian Project has long argued
<https://lists.debian.org/debian-legal/2016/01/msg00023.html> that the C-FSL
violates the DFSG, so OSI will hopefully not decide differently.

Carlo Piana 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 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.

*Convertible Free Software License, Version 1.4*

Elmar Stellnberger submits the next revision of the C-FSL. Lukas Atkinson
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190204/61d377b8/attachment-0001.html>


More information about the License-review mailing list