[License-review] January 2019 Summary

Tue Feb 5 16:09:37 UTC 2019

Whether or not OSI approves of it, transfer of copyright ownership is
extra-weird and requires a written "instrument of conveyance" signed by the
copyright holder, ala section 204:

  https://www.copyright.gov/title17/92chap2.html

This is usually interpreted as "on paper, with a pen, kept in a filing cabinet",
and even if you go "docusign, I choose you!" and win your pokebattle it probably
still requires every single contributor's name to be tracked and an individual
record kept of their informed consent (a bit like establishing privity of contract).

I'd worry that if somebody challenged this point in court, a license attempting
to substitute itself for copyright assignment might be held to the same
requirements _as_ copyright assignment. Because it _is_ clearly an attempt at an
end-run around the legal requirement placed on copyright assignment (that's why
the license exists), and a judge could easily go "nice try" and smack it down.
("But we don't _wanna_, it's too hard" is seldom a compelling legal argument.
Unless you have a _lot_ of money.)

(P.S. I'm still totally not a lawyer, this is just "ooh, that looks bad, maybe
as a professional about it".)

Rob

On 2/5/19 8:34 AM, Elmar Stellnberger wrote:
>   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
>>
> 
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org