<div dir="ltr"><p></p>
<p>In April, the License-Discuss mailing list:</p>
<ul><li>talked about non-commercial licensing</li><li>discussed license revocability</li><li>answered a question about LGPL/Apache compatibility</li></ul>
<p>The summary can also be read online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss042019">https://opensource.org/LicenseDiscuss042019</a></p>
<p>The corresponding License-Review summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseReview042019">https://opensource.org/LicenseReview042019</a> and covers extensive discussion about the Cryptographic Autonomy License.</p>
<p><b id="gmail-international">International Licenses Redux</b></p>
<p>As proposed in <a href="https://opensource.org/LicenseDiscuss122018">December</a>, Richard Fontana has updated the “International” license category of the OSI license list.</p>
<p><b id="gmail-non-commercial-doesnt-compose">Non-Commercial doesn’t compose</b></p>
<p>Chris Webber posts an essay about non-commercial licenses to the list, based on his experience working at Creative Commons.</p>
<p>Webber is “sad to see history repeat itself […] given the [recent]
volume of submissions in favor some sort of noncommercial style license”
(Note: like SSPL). Whereas Rob Myers joked that NC stands for No
Community, Webber argues it represents “‘No Composition’, which is just
as much or more of a threat”. Core points:</p>
<ul><li><p>Defining (non-)commercial use is extremely difficult. See <a class="gmail-uri" href="https://wiki.creativecommons.org/wiki/Defining_Noncommercial">https://wiki.creativecommons.org/wiki/Defining_Noncommercial</a>.</p></li><li><p>NC is asymmetric. “NC has the kind of appeal that a lottery does:
it’s very fun to think about participating when you imagine yourself as
the recipient.”</p></li><li><p>NC feels like a minefield. If single NC licenses are already
confusing, how would it feel if the whole system switched? For example,
would a partially-NC Debian distribution be usable?</p></li><li><p>Different license users have opposed goals. “Libre Commoners”
want to protect the commons, and want everyone to abide by the license.
In contrast, “Proprietary Relicensors” want to prevent free riders in
order to develop income. This is anti-community.</p></li></ul>
<p>Webber concludes that “Noncommercial fails in its goals and it fails
the community. It sounds nice when you think you’ll be the only one on
top, but it doesn’t work, and it never will.”</p>
<p><b id="gmail-can-a-contributor-take-back-open-source-code">Can a contributor take back open source code?</b></p>
<p>Antoine Thomas asks whether a contributor would be able to
revoke/remove their contributions from a project, and how this would
affect old versions of a project.</p>
<p>Kevin Fleming responds that legitimately provided open source
licenses are not revocable, but that a project might honor a request out
of courtesy.</p>
<p>Brendan Hickey points out that copyright law may provide special
revocation rights, e.g. 17 USC §203. And even without revocation, a
contributor could make life difficult for users.</p>
<p><b id="gmail-compatibility-of-lgplv2.1-and-apache-2.0">Compatibility of LGPLv2.1 and Apache 2.0</b></p>
<p>Bryan Christ asks whether Apache-covered software can link with
LGPLv2.1 libraries and vice versa. The question is motivated by their
incompatible patent clauses.</p>
<p>Bruce Perens affirms that either direction of linking is fine:
neither license imposes terms on the software it is linked with. But the
LGPL does extend some terms onto the linked work in its entirety, which
could be a problem e.g. with proprietary licenses that prohibit reverse
engineering. While the Apache-2 patent clause is incompatible with the
GPLv2, the LGPL is structured differently.</p>
<p>Bryan Christ notes that the <span class="elide">ASF lists the LGPL as incompatible</span>.
Bruce Perens explains that the Apache Foundation excludes LGPL software
from their own projects because the LGPL affects the larger work, but
that the licenses themselves allow linking with each other.</p>
<p>McCoy Smith links to the FSF comment on the Apache license, but notes that it only discusses GPL and not LGPL.</p>
</div>