<div dir="ltr"><p></p>
<p>In January, the License-Review mailing list discussed:</p>
<ul><li>the new license review process</li><li>Server Side Public License, Version 2 (<span class="" style="" id=":20q.1" tabindex="-1">SSPL</span> v2)</li><li>Convertible Free Software License, Version 1.3 (C-<span class="" style="" id=":20q.2" tabindex="-1">FSL</span> v1.3)
<ul><li>What are the problems with Original Authors?</li><li>How is the C-<span class="" style="" id=":20q.3" tabindex="-1">FSL</span> different from <span class="" style="" id=":20q.4" tabindex="-1">CLAs</span> or permissive licenses?</li><li>Why is the publication requirement a problem?</li><li>Can the C-<span class="" style="" id=":20q.5" tabindex="-1">FSL</span> be <span class="" style="" id=":20q.6" tabindex="-1">OSI</span>-approved?</li></ul></li><li>Convertible Free Software License, Version 1.4 (C-<span class="" style="" id=":20q.7" tabindex="-1">FSL</span> v1.4)</li></ul>
<p>This summary can also be read online at <a class="gmail-uri" href="https://opensource.org/LicenseReview012019"><span class="" style="" id=":20q.8" tabindex="-1">https</span>://<span class="" style="" id=":20q.9" tabindex="-1">opensource</span>.org/LicenseReview012019</a></p>
<p>The corresponding License-Discuss summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss012019"><span class="" style="" id=":20q.10" tabindex="-1">https</span>://<span class="" style="" id=":20q.11" tabindex="-1">opensource</span>.org/LicenseDiscuss012019</a>
and covers discussion on the <span class="" style="" id=":20q.12" tabindex="-1">opensource</span>.<span class="" style="" id=":20q.13" tabindex="-1">dev</span> info site, Open Data,
“intimacy” in open source licenses, <span class="" style="" id=":20q.14" tabindex="-1">relicensing</span> and maintainer–community
dynamics, and VanL’s upcoming license.</p>
<p><b id="gmail-license-committee-report">License Committee Report</b></p>
<p>Richard <span class="" style="" id=":20q.15" tabindex="-1">Fontana</span> provides the license committee report.</p>
<p>The new license review process has been adopted, and will apply for
ongoing reviews. Simon Phipps clarifies that the <span class="" style="" id=":20q.16" tabindex="-1">OSI</span> 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.” <span class="" style="" id=":20q.17" tabindex="-1">OSI</span>-approved licenses should be
fine for general use, and ensure a level playing field.</p>
<p><span class="" style="" id=":20q.18" tabindex="-1">SSPL</span> v2: the discussion is ongoing. The board will decide on 2019-02-18.</p>
<p>C-<span class="" style="" id=":20q.19" tabindex="-1">FSL</span> v1.3: approval of the previous version was withheld, and version 1.3 was submitted. The board will decide on 2019-02-18.</p>
<p>Bruce <span class="" style="" id=":20q.20" tabindex="-1">Perens</span> suggests that both licenses should be rejected: The new
version of the C-<span class="" style="" id=":20q.21" tabindex="-1">FSL</span> just seems to package the same discriminatory terms
in different words. And the <span class="" style="" id=":20q.22" tabindex="-1">SSPL</span> 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.</p>
<p><b id="gmail-server-side-public-license-version-2">Server Side Public License, Version 2</b></p>
<p>Eliot Horowitz (<span class="" style="" id=":20q.23" tabindex="-1">MongoDB</span>) announces that <span class="" style="" id=":20q.24" tabindex="-1">MongoDB</span> is working towards a
new revision of the <span class="" style="" id=":20q.25" tabindex="-1">SSPL</span>. 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 <em>value</em>
from the software or services that provide the functionality of the
software. Horowitz claims that the source disclosure requirements are
narrower under the <span class="" style="" id=":20q.26" tabindex="-1">SSPL</span> (only when offering the software as a service)
than under the <span class="" style="" id=":20q.27" tabindex="-1">AGPL</span> (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: <span class="" style="" id=":20q.28" tabindex="-1">hmm</span>).</p>
<p>Gil <span class="" style="" id=":20q.29" tabindex="-1">Yehuda</span> appreciates the clarifications of the <span class="" style="" id=":20q.30" tabindex="-1">SSPL</span> over the <span class="" style="" id=":20q.31" tabindex="-1">AGPL</span>,
but notes that the <span class="" style="" id=":20q.32" tabindex="-1">SSPL</span> only seems to be <span class="" style="" id=":20q.33" tabindex="-1">OSD</span>-compliant for most users –
but not all.</p>
<p>Bruce <span class="" style="" id=":20q.34" tabindex="-1">Perens</span> sees the <span class="" style="" id=":20q.35" tabindex="-1">SSPL</span> as incompatible with <span class="" style="" id=":20q.36" tabindex="-1">OSD</span> #9 “License must
not restrict other software” because the <span class="" style="" id=":20q.37" tabindex="-1">SSPL</span> requires the disclosure of
software that is aggregated with but not derivative or part of the
<span class="" style="" id=":20q.38" tabindex="-1">SSPL</span>-covered software. “I wrote #9 into the <span class="" style="" id=":20q.39" tabindex="-1">OSD</span> to prohibit <em>exactly</em> this sort of conduct. Exactly. The text is really clear.”</p>
<p>Horowitz asserts that the goal of the <span class="" style="" id=":20q.40" tabindex="-1">SSPL</span> 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 <span class="" style="" id=":20q.41" tabindex="-1">Cowan</span>
finds this confusing: why would <span class="" style="" id=":20q.42" tabindex="-1">MongoDB</span> be fine with users installing
<span class="" style="" id=":20q.43" tabindex="-1">MongoDB</span> on servers in the cloud, but not with cloud providers offering
managed services? The cloud provider would get paid either way. <span class="" style="" id=":20q.44" tabindex="-1">Vadim</span>
<span class="" style="" id=":20q.45" tabindex="-1">Tkachenko</span> 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 <span class="" style="" id=":20q.46" tabindex="-1">MongoDB</span> by
developers.</p>
<p>Rob <span class="" style="" id=":20q.47" tabindex="-1">Landley</span> 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 <span class="" style="" id=":20q.48" tabindex="-1">SSPL</span> has already caused it to be dropped by Linux
<span class="" style="" id=":20q.49" tabindex="-1">distros</span>, and compatible replacements (e.g. from Amazon) or maintained
forks (e.g. from <span class="" style="" id=":20q.50" tabindex="-1">Percona</span>) are already available. “OSI aside, the
community seems to have pretty clearly spoken.” However, Nigel <span class="" style="" id=":20q.51" tabindex="-1">Tzeng</span>
cautions that this is a matter of long-term investment. <span class="" style="" id=":20q.52" tabindex="-1">MongoDB</span> will
certainly continue to invest into their core product, whereas forks
might not see comparable effort.</p>
<p>Carlo <span class="" style="" id=":20q.53" tabindex="-1">Piana</span> 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.</p>
<p><b id="gmail-convertible-free-software-license-version-1.3">Convertible Free Software License, Version 1.3</b></p>
<p><span class="" style="" id=":20q.54" tabindex="-1">Elmar</span> <span class="" style="" id=":20q.55" tabindex="-1">Stellnberger</span> 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-<span class="" style="" id=":20q.56" tabindex="-1">FSL</span>, 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 (<span class="" style="" id=":20q.57" tabindex="-1">CLA</span>) – but none of these ensure that downstream
modifications are available under the same license. The C-<span class="" style="" id=":20q.58" tabindex="-1">FSL</span> is
therefore a copyleft license where contributors give designated
“Original Authors” special <span class="" style="" id=":20q.59" tabindex="-1">relicensing</span> rights.</p>
<p>The idea of this license in general and the rewrite for the third
version specifically are viewed quite critically on the mailing list.</p>
<p>Carlo <span class="" style="" id=":20q.60" tabindex="-1">Piana</span> <span class="" style="" id=":20q.61" tabindex="-1">recognizes</span> “substantial effort to overcome most of the
criticisms to the original version” but is frustrated with the apparent
lack of understanding <span class="" style="" id=":20q.62" tabindex="-1">Stellnberger</span> shows for this criticisms. Bruce
<span class="" style="" id=":20q.63" tabindex="-1">Perens</span> isn’t satisfied at all: “When you request a “rewrite” of a
license with a <em>fundamental goal</em> that is in conflict with the
<span class="" style="" id=":20q.64" tabindex="-1">OSD</span>, 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.”</p>
<p>There are three major criticisms of the C-<span class="" style="" id=":20q.65" tabindex="-1">FSL</span>:</p>
<p>1) The special role of Original Authors is discriminatory, as argued
by Brendan Hickey: “This is conceptually incompatible with the <span class="" style="" id=":20q.70" tabindex="-1">OSD</span>. Any
license that implements this is non-free.”</p>
<p>2) The C-<span class="" style="" id=":20q.74" tabindex="-1">FSL</span> is trying to do copyright assignments in disguise.</p>
<p>3) The license imposes an onerous publication requirement for all changes.</p>
<p><span class="gmail-no-elide"><a href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html">Carlo <span class="" style="" id=":20q.81" tabindex="-1">Piana</span></a></span> provides an excellent analysis of the biggest problems with the license.</p>
<p><b id="gmail-what-are-the-problems-with-original-authors">What are the problems with Original Authors?</b></p>
<p>Under the C-<span class="" style="" id=":20q.86" tabindex="-1">FSL</span>, Original Authors can be appointed to act as the
“effective copyright holders“. These can <span class="" style="" id=":20q.92" tabindex="-1">relicense</span> 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?).</p>
<p>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 <span class="" style="" id=":20q.117" tabindex="-1">OSI</span>-approved license. (Note: Asymmetry was debated but
ultimately removed during the <a class="gmail-no-elide" href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2016-October/002856.html">approval process of the Upstream Compatibility License</a> in 2016–2017.)</p>
<p>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.</p>
<p>But the freedom to fork is exactly what Open Source is about! Rob
<span class="" style="" id=":20q.148" tabindex="-1">Landley</span> 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 <em><span class="" style="" id=":20q.175" tabindex="-1">conceptually</span></em>
broken.” Bruce <span class="" style="" id=":20q.177" tabindex="-1">Perens</span> agrees: the C-<span class="" style="" id=":20q.179" tabindex="-1">FSL</span> not only violates the <span class="" style="" id=":20q.181" tabindex="-1">OSD</span>, it is
also bad for the community. A separate thread ensues with numerous
examples of <span class="" style="" id=":20q.189" tabindex="-1">relicensing</span>, forks, and maintainer–community dynamics (Note:
covered in the License-Discuss summary).</p>
<p>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-<span class="" style="" id=":20q.218" tabindex="-1">FSL</span>
covered code.</p>
<p>Rob <span class="" style="" id=":20q.220" tabindex="-1">Landley</span> points out that licenses don’t determine who the copyright holder is, but what the copyright holders allow <em>other</em> people to do. This spawns a small discussion about the role of <em>joint <span class="" style="" id=":20q.234" tabindex="-1">authorship</span></em> in Open Source.</p>
<p><b id="gmail-how-is-the-c-fsl-different-from-clas-or-permissive-licenses">How is the C-<span class="" style="" id=":20q.235" tabindex="-1">FSL</span> different from <span class="" style="" id=":20q.236" tabindex="-1">CLAs</span> or permissive licenses?</b></p>
<p>The goal of this license is that the maintainers can easily <span class="" style="" id=":20q.238" tabindex="-1">relicense</span>
the project, without having to deal with <span class="" style="" id=":20q.241" tabindex="-1">CLAs</span>. If the <span class="" style="" id=":20q.243" tabindex="-1">CLAs</span> and the
C-<span class="" style="" id=":20q.244" tabindex="-1">FSL</span> are <span class="" style="" id=":20q.245" tabindex="-1">criticized</span> so much why not also permissive licenses,
<span class="" style="" id=":20q.248" tabindex="-1">Stellnberger</span> asks?</p>
<p>Permissive licenses effectively allow anyone to <span class="" style="" id=":20q.254" tabindex="-1">relicense</span> the code,
whereas the C-<span class="" style="" id=":20q.256" tabindex="-1">FSL</span> assigns this right to the Original Authors (see above
criticism).</p>
<p>Carlo <span class="" style="" id=":20q.261" tabindex="-1">Piana</span> notes that contributors can refuse to sign a <span class="" style="" id=":20q.264" tabindex="-1">CLA</span> in which
case their changes cannot be merged into the upstream project, but
contributors cannot refuse the C-<span class="" style="" id=":20q.271" tabindex="-1">FSL</span> because it applies implicitly as
soon as the changes are made. Brendan Hickey points out that <a href="http://www.harmonyagreements.org/">Project <span class="" style="" id=":20q.279" tabindex="-1">Harmony</span></a>
can be used for standard-<span class="" style="" id=":20q.282" tabindex="-1">ish</span> <span class="" style="" id=":20q.283" tabindex="-1">CLA</span> templates. In any way, allowing a
maintainer team to do arbitrary <span class="" style="" id=":20q.290" tabindex="-1">relicensing</span> is not a problem for Open
Source to solve.</p>
<p>Note: a further problem with allowing arbitrary <span class="" style="" id=":20q.295" tabindex="-1">relicensing</span> 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-<span class="" style="" id=":20q.313" tabindex="-1">FSL</span>. A <span class="" style="" id=":20q.315" tabindex="-1">CLA</span> 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.</p>
<p><b id="gmail-why-is-the-publication-requirement-a-problem">Why is the publication requirement a problem?</b></p>
<p>Carlo <span class="" style="" id=":20q.334" tabindex="-1">Piana</span> notices that any changes to a C-<span class="" style="" id=":20q.336" tabindex="-1">FSL</span> 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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p><span class="" style="" id=":20q.368" tabindex="-1">Elmar</span> <span class="" style="" id=":20q.369" tabindex="-1">Stellnberger</span> responds that the publication requirement for
buggy changes was not intentional. And isn’t such a publication
obligation similar to the Vim or <span class="" style="" id=":20q.376" tabindex="-1">Affero</span> licenses? (Note: Nope. While Vim
has a publication requirement, it also has an alternative GPLv2+
<span class="" style="" id=":20q.382" tabindex="-1">relicensing</span> clause. And the <span class="" style="" id=":20q.384" tabindex="-1">AGPL</span> doesn’t require publication except when
the software is conveyed or made available to users over a network.)</p>
<p>Nigel <span class="" style="" id=":20q.390" tabindex="-1">Tzeng</span> 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-<span class="" style="" id=":20q.399" tabindex="-1">FSL</span> is a license trap.</p>
<p><b id="gmail-can-the-c-fsl-be-osi-approved">Can the C-<span class="" style="" id=":20q.401" tabindex="-1">FSL</span> be <span class="" style="" id=":20q.402" tabindex="-1">OSI</span>-approved?</b></p>
<p>Brendan Hickey points out that the <span class="" style="" id=":20q.405" tabindex="-1">Debian</span> Project has <a href="https://lists.debian.org/debian-legal/2016/01/msg00023.html">long <span class="" style="" id=":20q.407" tabindex="-1">argued</span></a> that the C-<span class="" style="" id=":20q.408" tabindex="-1">FSL</span> violates the <span class="" style="" id=":20q.410" tabindex="-1">DFSG</span>, so <span class="" style="" id=":20q.412" tabindex="-1">OSI</span> will hopefully not decide differently.</p>
<p>Carlo <span class="" style="" id=":20q.415" tabindex="-1">Piana</span> suggests that the license might become <span class="" style="" id=":20q.416" tabindex="-1">OSD</span>-compliant if
the <span class="" style="" id=":20q.417" tabindex="-1">CLA</span>-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 <span class="" style="" id=":20q.436" tabindex="-1">practice</span> work.” <span class="" style="" id=":20q.438" tabindex="-1">Elmar</span> <span class="" style="" id=":20q.439" tabindex="-1">Stellnberger</span> rejects this suggestion: “That
would lead the whole clause of original authors ad absurdum” and make it
too easy for other people to <span class="" style="" id=":20q.453" tabindex="-1">relicense</span> the project.</p>
<p><b id="gmail-convertible-free-software-license-version-1.4">Convertible Free Software License, Version 1.4</b></p>
<p><span class="" style="" id=":20q.454" tabindex="-1">Elmar</span> <span class="" style="" id=":20q.455" tabindex="-1">Stellnberger</span> submits the next revision of the C-<span class="" style="" id=":20q.457" tabindex="-1">FSL</span>. Lukas
Atkinson <span class="" style="" id=":20q.460" tabindex="-1">summarizes</span> the changes: minor clarifications and a closed
loophole. But no progress regarding the fundamental criticism has been
made, so that further review seems pointless.</p>
</div>