[License-review] January 2019 Summary

Tue Feb 5 14:34:47 UTC 2019

   Basically all original authors need to consent on an issue (as is 
with any kind of copyright holders) at least if they have not signed a 
contract to install a majority vote which can be done in addition to the 
C-FSL license.

   The license which was discussed in detail with Debian folks was 
S-FSL. However this license is somewhat fundamentally different to C-FSL.

Elmar

On 04.02.19 23:01, Lukas Atkinson wrote:
> 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)
>       o What are the problems with Original Authors?
>       o How is the C-FSL different from CLAs or permissive licenses?
>       o Why is the publication requirement a problem?
>       o 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 
> <https://opensource.org/LicenseReview012019>
> 
> The corresponding License-Discuss summary is online at 
> https://opensource.org/LicenseDiscuss012019 
> <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.
> 
> 
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
> 