<div dir="ltr"><p>I’ve been asked by the OSI to provide monthly summaries of the 
license-review and license-discuss mailing lists. Unfortunately, the 
large number of references is impractical in an email, so please check 
out the <a href="https://opensource.org/LicenseDiscuss122018">version on the OSI blog</a> for all the links to the individual 
messages. Any feedback is welcome, though replies on the content should 
of course be made to the original threads.</p>
<p>This month’s topics:</p>
<ul><li>International Licenses Redux</li><li>Proposed license decision process</li><li>“Consideration” in open source licenses</li><li>Open source license with obligation to display an attribution?</li><li>SSPL loose ends</li></ul><p><b id="gmail-international-licenses-redux">International Licenses Redux</b></p>
<p>Richard Fontana suggests that the “International” <a href="https://opensource.org/licenses/category">license category</a>
 should be expanded from non-English language licenses (LiLiQ) to cover 
licenses “targeting specific languages and jurisdictions”, regardless of
 their language (EUPL, CeCILL). Language and jurisdiction are 
intertwined, as Mike Milinkovich explains: “By convention, OSS expects 
English as the language of the license, but there are places in the 
world where that is legally impossible [due to statutory language 
requirements].”</p>
<p><b id="gmail-proposed-license-decision-process">Proposed license decision process</b></p>
<p>Richard Fontana posts a draft for a clarified license decision 
process as discussed by the OSI Board. The proposal adds a clear 
Decision Date 60 days after initial license submission after which the 
OSI will defer the decision if discussion is ongoing, approve or reject 
the license if the discussion is conclusive, or withhold approval if the
 license can be reworked.</p>
<p>Bruce Perens appreciates that “software freedom” is an explicit goal 
of the proposed decision process, but notes that the term can be 
unclear. Lawrence Rosen argues that open source should be based on a 
more pragmatic definition.</p>
<p>Luis Villa asks about a specific test for software freedom, and 
whether license review would be coordinated with the FSF. Richard 
Fontana replies that he considers the OSD to be an attempt of a 
definition of software freedom, but that the OSD is limited and should 
not be viewed as as checklist or interpreted too literally. Focusing on 
software freedom as the actual goal would help avoid this. While Fontana
 would like to see greater harmonization between OSI and FSF wrt 
decisions on edge-case FOSS licenses, he doesn’t think their very 
different review processes should be closely coordinated.</p>
<p>What about harmful licenses that have been accepted by the OSI in the
 past? Perens specifically considers the SIL Open Font License. Rick 
Moen thinks that these licenses are a lingering though minor problem 
since there’s a community expectation to use one of the major licenses. 
Luis Villa thinks a cleanup of old licenses might be a good idea and 
could also provide “case law” for the new license review process. 
Nicholas Weinstock would prefer existing licenses to be grandfathered.</p>
<p><b id="gmail-consideration-in-open-source-licenses">“Consideration” in open source licenses</b></p>
<p>As a more pragmatic basis for the license review process than “software freedom”, Lawrence Rosen proposes:</p>
<blockquote>
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p>“Open source software” means software actually distributed under 
terms that grant a copyright and patent license from all contributors to
 the software for every licensee to access and use the complete source 
code, make copies of the software or derivative works thereof and, 
without payment of royalties or other consideration, to distribute the 
unmodified or modified software.</p></blockquote><blockquote>
</blockquote>
<p>A discussion starts on the “without consideration” point. Florian 
Weimer notes that this term is difficult to understand outside of common
 law. For example, Kevin P. Fleming and Nicholas Weinstock note that the
 copyleft requirement to distribute source code might be interpreted as a
 consideration. Bruce Perens responds that the Jacobsen v. Katzer case 
shows that open source licenses do indeed have non-monetary 
considerations.</p>
<p>Lawrence Rosen insists that “considerations” should not be confused 
with “conditions”. Rosen claims that no open source licenses require 
considerations but that the OSI accepts some license conditions 
(e.g. copyleft conditions). Rosen thinks that creating open source 
software or receiving attribution is its own reward. (Note: Rosen’s 
distinction between considerations and conditions seems to prove 
Weimer’s point, and the claim about considerations directly contradicts 
Perens.)</p>
<p>A number of OSI-approved licenses explicitly mention considerations 
and conditions, as noted by Nicholas Weinstock. Perhaps the concepts can
 be distinguished by whether rights are surrendered or gained? Rosen 
agrees that these terms can have “subtle legal meanings, including in 
other countries” but explains that a consideration can be anything 
valued by the licensor, including “<a href="https://en.wikipedia.org/wiki/Peppercorn_(legal)">Peppercorns</a>”.</p>
<p>Nigel Tzeng notes that it is exactly the acceptable level of 
considerations that is at question for an open source license: “Some 
forms of consideration is okay, even good. Others become overreach.” 
Rosen acknowledges that and explains that he is primarily concerned 
about considerations by downstream users. (Note: it seems Rosen’s gripe 
with considerations is not so much the consideration itself, but that 
there might not be a clear recipient of the consideration.)</p>
<p>Regarding the “actually distributed” part, Nicholas Weinstock notes 
that the BSD license might fail that criterion since it has no express 
patent grant. Lawrence Rosen agrees and would object to new licenses 
without an explicit patent grant. In fact, licenses that expressly 
exclude patent grants have been rejected. However, Rosen acknowledges 
that especially academic licensors might only be able to provide limited
 grants. Rosen also points to possible issues around open standards.</p>
<p><b id="gmail-open-source-license-with-obligation-to-display-an-attribution">Open source license with obligation to display an attribution?</b></p>
<p>Simon Cox asks  whether any open source license requires public 
attribution as a gesture of acknowledgement, e.g. as a logo on a 
website. Such attributions would make it easier to demonstrate the 
impact of open source projects, especially in the public sector/GOSS as 
emphasized by Stephen Michael Kellat.</p>
<p>Such attributions can be tricky. Danese Cooper recalls the tension between the OSI-approved Attribution Assurance License <a href="https://opensource.org/licenses/AAL">AAL</a> and SugarCRM’s previous requirement to display their logo in the middle of each page (cf <a href="https://www.zdnet.com/article/podcast-sugarcrm-ceo-says-attribution-in-open-source-licenses-is-about-fairness/">ZDNet</a>)
 which was considered counter to the OSD. David Woolley mentions the 
difficulty around the advertising clause in the 4-clause BSD license.</p>
<p>Antoine Thomas notes  that attribution is usually not a problem since
 all attributions in a software are typically gathered on a separate 
page. Thorsten Glaser responds that this is only possible if the license
 is technology-neutral and doesn’t prescribe a specific attribution 
style. Glaser also raises the issue that a requirement for public 
attribution could fail the “Dissident” or “Desert Island” test (see <a href="https://people.debian.org/~bap/dfsg-faq.html#testing">DFSG</a>).</p>
<p>Bruce Perens mentions two issues with “badgeware”: It would trigger 
requirements on mere use, and would make compliance infeasible for large
 projects such as Debian. Lawrence Rosen points out that OSD #10 
“License Must Be Technology Neutral” prevents some badgeware licenses.</p>
<p>Bruce Perens notes that attribution requests rather than requirements
 are unproblematic. Lawrence Rosen thinks that mild requirements are 
perfectly reasonable, e.g.: “Licensee must display the name and source 
of the embedded software in as prominent a manner and place as the 
licensee displays its own trademarks.”</p>
<p>Rosen also voices an interesting view on the license review process: 
“Our job is to approve licenses that experiment successfully (?) with 
new license models, not to keep rejecting ways to obtain profit and 
recognition from software. Let us leave it up to the marketplace to 
determine acceptability of the license, as long as it is ‘open source 
software.’”</p>
<p>Chris Lamb suggests  adding a rider with an attribution request to 
any well-known license, e.g. the GPLv3. (Note: this could be a GPLv3 
Additional Term.) Lawrence Rosen claims that the GPLv3 “doesn’t protect 
attribution in derivative works.”</p>
<p>Regarding the Government Open Source Software (GOSS) attribution 
aspect, Nigel Tzeng expresses considerable frustration with respect to 
available open source licenses and the open source community. Visible 
attribution is often needed by public projects to ensure future funding.</p>
<p>Jim Jagielski and Lawrence Rosen disagree that GOSS would be 
fundamentally different from other projects in this respect. However, 
Rosen agrees that present licenses such as the GPLv3 fail to ensure 
sufficient attribution.</p>
<p>Christopher Sean Morrison lists a few US-specific problems or 
unresolved legalities that GOSS faces. This limits public sector 
participation in open source: “Nobody wants to be the guinea pig.” Tzeng
 points to the <a href="https://opensource.org/licenses/NASA-1.3">NASA</a> and <a href="https://opensource.org/licenses/ECL-2.0">ECL</a> licenses as examples where other public sector needs already made specific licenses necessary.</p>
<p><b id="gmail-sspl-loose-ends">SSPL loose ends</b></p>
<p>The submission of the SSPL sparked lots of discussions about copyleft and review processes in general. A number of loose ends:</p>
<p>Kyle Mitchell followed up on two points from November. Responding to the older <a href="https://www.gnu.org/philosophy/freedom-or-power.en.html">Freedom or Power?</a>
 essay, Mitchell notes that there isn’t just the essay’s producer–user 
power imbalance, but also an imbalance between producers. Mitchell 
argues that non-permissive licenses such as the SSPL are necessary to 
protect producers from their competitors.</p>
<p>There have not been many supporters for the SSPL. Mitchell notes that
 the number of supporters should not matter, so that the license review 
process doesn’t turn into a popularity contest.</p>
<p>Previously, Kyle Mitchell had noted that some OSI-approved licenses 
trigger requirements on use and not just on copying: the OSL and AGPL. 
Florian Weimer thinks that the AGPL was originally intended for servers 
that also serve their source code and not for open-core business models.
 “People who have tried to use the AGPL in this way have been 
disappointed about the effects, I believe.” Weimer wonders whether such 
business models were a consideration for the OSL.</p>
<p>Should a license review focus on the license text or its potential 
use? Florian Weimer prefers a textual review because this avoids having 
to take a stance on Open Core business models. Brendan Hickey clarifies 
that a 2010 post on the OSI blog about this is a personal opinion and 
not official OSI stance.</p>

</div>