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 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 [1,2].

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 [1,2]. 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 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 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 [1,2].

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 [1,2] points out that Project Harmony 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 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.