<div dir="ltr"><p></p>
<p>In February, the License-Review mailing list discussed:</p>
<ul><li>Convertible Free Software License (C-FSL)</li><li>Twente License</li><li>Server Side Public License, Version 2 (SSPL v2)</li><li>Review process, governance, and the OSD</li></ul>
<p>This summary can also be read online at <a class="gmail-uri" href="https://opensource.org/LicenseReview022019">https://opensource.org/LicenseReview022019</a></p>

<p>The corresponding License-Discuss summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss022019">https://opensource.org/LicenseDiscuss022019</a>
 and covers discussions on how to keep the mailing lists civil, and to 
what degree the business model of a license submitter should be 
relevant.</p>
<p><b id="gmail-license-committee-report">License Committee Report</b></p>
<p>Richard Fontana provides the license committee report. Currently, three licenses are under review:</p>
<ul><li>C-FSL 1.4: A decision is due 2019-02-22.</li><li>SSPL v2: A decision is due 2019-02-18.</li><li>Twente License: A decision is due 2019-04-05.</li></ul>
<p><b id="gmail-convertible-free-software-license">Convertible Free Software License</b></p>
<p>In response to last month’s review, Elmar Stellnberger clarifies that
 the Original Authors have to decide via consensus or set up their own 
statutes that cover their decision process.</p>
<p>Rob Landley points out that copyright transfers must be written and 
signed (at least in the US), so that a license like the C-FSL that tries
 to circumvent this requirement might not hold up in court.</p>
<p><b id="gmail-twente-license">Twente License</b></p>
<p>Anand Chowdhary submits his Twente License for approval. It is an 
MIT-style license, except that it also tries to ensure “European values”
 and privacy: derivatives of the software may only collect and share 
personal data with the user’s prior consent.</p>
<p>Nigel Tzeng points out that this fails OSD #6 “No Discrimination 
Against Fields of Endeavor”, while Josh Berkus disagrees. Lawrence Rosen
 criticizes that the license tries to enforce values: “far more 
ambitious than software can protect with its mere open source licenses.”
 Eric Schultz suggests other ways than licenses for open source projects
 to express values, for example by refusing to support unethical use 
cases.</p>
<p>Bruce Perens adds a bit of historical background to the OSD: it was 
written to with anti apartheid licenses in mind that ended up hurting 
innocent people after the apartheid had ended. (Note: e.g. see <a href="http://www-cs-students.stanford.edu/~cale/cs201/index.html">Computers and the Apartheid Regime in South Africa</a>)</p>
<p>Josh Berkus criticizes that licenses should not mandate values 
because the interpretation of these values can be quite subjective – 
thus making it unclear whether the license has been violated. Anand 
Chowdhary responds that while expressing certain values is the rationale
 of this license, the text of the license only contains a specific, 
unambiguous condition.</p>
<p>Carlo Piana argues that it is not the job of licenses to ensure 
compliance with legal obligations: “the entire concept is wrong” and 
fails to account for changing laws over time.</p>
<p>Lukas Atkinson argues that data protection is not inherent in a 
software but depends on how the software is used. Therefore, a copyright
 license doesn’t offer a suitable enforcement tool. And while the 
license seems to emulate the GDPR, it is both more narrow and more 
restrictive. Atkinson suggests that it might be a better approach to 
combine the MIT-like attribution requirement with a GDPR-like 
transparency requirement, but without directly restricting the use of 
the software. Carlo Piana thinks this is a good idea in principle, but 
that correctly implementing such a requirement in a license would be 
rather difficult. In response to this, Anand Chowdhary clarifies their 
goals and starts drafting a transparency clause.</p>
<p><b id="gmail-server-side-public-license-version-2">Server Side Public License, Version 2</b></p>
<p>Eliot Horowitz (MongoDB) responds to criticism of the SSPL’s section 
13, and provides some clarifications. Horowitz proposes a rewritten 
section that explicitly defines “Software as a Service” as “enabling a 
user to interact with software remotely through a computer network.”</p>
<p>Bruce Perens appreciates this clarification, but notes that this 
definition was not subject to major objections. Instead, Perens suggest 
removing the concept of “Service Source Code” in favour of sticking with
 the AGPL’s Corresponding Source concept. Perens summarizes his 
objections: that the Service Source Code concept attempts to encumber 
unrelated programs thus running into OSD #9, and that section 13 as 
written restricts fields of endeavour such as offering the software as a
 service, thus running into OSD #6.</p>
<blockquote>
<p>I don’t see how you can change this while keeping the intent of your 
license […] subsequent alterations to the license text have not 
substantially addressed [these objections].</p>
</blockquote>
<p>Similarly, Brendan Hickey finds that the central objections have not 
been addressed, though Hickey also points out the SSPL’s use of “value” 
and “primary purpose” as problematic. “What’s so special about these 
claims versus others? Simply, a license that doesn’t conform to the OSD 
must be rejected. As long as these problems are unresolved everything 
else – like the definition of SAAS – is just window dressing.” In 
contrast, Kyle Mitchell finds that Horowitz’ clarifications address the 
objections he had.</p>
<p><b id="gmail-review-process-governance-and-the-osd">Review process, governance, and the OSD</b></p>
<p>In the context of the SSPL review, Kyle Mitchell criticizes the OSI’s
 license review process, in particular the weight given to Peren’s 
voice. “I’ve lost confidence in this body’s ability to make rigorous 
decisions, or even facilitate focused debate, on any remotely 
interesting new copyleft license.” Rick Moen quips: “I think Bruce is 
permitted to be correct and listened to, despite the admitted difficulty
 of his having credibility on the subject.”</p>
<p>Perens responds to Mitchell that he founds his SSPL criticism solely 
on the question whether the license can be Open Source: “This is not an 
issue of my being a honcho, but of clearly stated rules in the OSD that 
the license intent very obviously came into conflict with.” Perens is 
also happy to engage with new licensing ideas when they don’t purport to
 be Open Source. In turn, Mitchell disagrees that the OSD would be so 
clear. “If OSD 6 banned any kind of [discrimination], GPLv2 
discriminated against proprietary software makers.” “There should be a 
new, crips, clear rule on open source copyleft scope. OSD 9 isn’t it.” 
Perens responds to individual points in Mitchell’s message. “Free 
Software and Open Source drew a line in the sand, gave it a brand, and 
have defended that line. There will always be attempts to push it 
elsewhere, and they will always be resisted.”</p>
<p>Lawrence Rosen shares some of Mitchell’s concerns regarding the 
scopes of the OSD versus SSPL, but thinks the discussion on these should
 be separated from the SSPL. In particular:</p>
<blockquote>
<ul><li><p>What components or other aspects of server applications are potentially subject to open source copyleft?</p></li><li><p>Is “corresponding source” more than only the Original Work and Derivative Works as defined in copyright law? How much more?</p></li></ul>
</blockquote>
<p>There’s also some debate about the “silent majority” who do not 
participate on the license-review list. Do they approve of everything 
and would speak up otherwise? Or are they absent because they disagree 
with the review? Bruce Perens suggests a third option:</p>
<blockquote>
<p>Very few people in the world want to be involved with license 
approval. Not even a majority of OSI directors. That’s why what happens 
on this list is important. They’re all trusting us to get it right.</p>
</blockquote>
<p>Note: If you’d like to participate on the lists, head over to <a class="gmail-uri" href="https://opensource.org/lists">https://opensource.org/lists</a> for information on how to subscribe.</p>

</div>