<div dir="ltr"><p></p>
<p>In January, the License-Discuss mailing list discussed:</p>
<ul><li>the opensource.dev info site</li><li>Open Data</li><li>“intimacy” in Open Source licenses
<ul><li>process and interface boundaries</li><li>corresponding Source</li><li>is it a problem that the FSF introduced a new word?</li><li>making sense of the law, and bright lines</li><li>licensor expectations</li></ul></li><li>relicensing and maintainer–community dynamics</li><li>VanL’s upcoming copyleft license</li></ul>
<p>This summary can also be read online at <a class="gmail-uri" href="https://opensource.org/LicenseDiscuss012019">https://opensource.org/LicenseDiscuss012019</a>.</p>

<p>The corresponding License-Review summary is online at <a class="gmail-uri" href="https://opensource.org/LicenseReview012019">https://opensource.org/LicenseReview012019</a> and covers discussion on the SSPL v2 and the C-FSL.</p>
<p><b id="gmail-opensource.dev">opensource.dev</b></p>
<p>Chris DiBona (Google) announces <a class="gmail-uri" href="https://opensource.dev/">https://opensource.dev/</a>,
 an info page about Open Source by Google. It seems to be aligned with 
OSI interpretation and receives general praise and appreciation from the
 list. Christopher Sean Morrison lauds the good collection of resources 
about Open Source, and notes how accessible it is to new developers and 
non-developers as well.</p>
<p>The opensource.dev site links to the <a href="https://opensource.org/licenses">OSI’s licenses page</a>.
 There is some discussion whether the EPL and CDDL should really be on 
that list of popular licenses. While no one disagrees on the CDDL, Mike 
Milinkovich (Eclipse Foundation) points out that the many Eclipse 
projects are a strong community that uses the EPL – though some might 
disagree that a foundation is a community.</p>
<p><b id="gmail-open-data">Open Data</b></p>
<p>Christopher Sean Morrison announces that the US has signed a new open
 data law into effect. Gil Yehuda wonders whether there is a widely 
accepted definition of Open Data, similar to the OSD and the Four 
Freedoms for software? Sander van der Waal (Open Knowledge Foundation, 
OKFN) points to the OKFN’s <a class="gmail-uri" href="https://opendefinition.org">https://opendefinition.org</a>
 which was inspired by the OSD. The OKFN also offers a license review 
process for Open Data licenses. However, version 4 of the Creative 
Commons licenses might make special Open Data licenses unnecessary. 
(Note: for example, CCv4 also considers database rights.)</p>
<p><b id="gmail-afl-attribution-notice">AFL “attribution notice”</b></p>
<p>Antoine Thomas (PrestaShop) asks for clarification how derivative 
works should provide attribution under the Academic Free License. No one
 responded on-list :(</p>
<p><b id="gmail-intimacy-in-open-source">Intimacy in Open Source</b></p>
<p>Gil Yehuda asks what the (A)GPLv3 means by “intimate data 
communication”. For example, would a database client/driver not have 
intimate communication with its database server? Or are they completely 
separate works? Lawrence Rosen also raises the issue how this interacts 
with API copyrightability and what this means for network copyleft like 
AGPL and SSPL. Extensive discussion ensues.</p>
<p><b id="gmail-process-and-interface-boundaries">Process and interface boundaries</b></p>
<p>John Cowan argues that communication is intimate when data structures
 are shared in memory. Shelling out would not count as intimate because 
that uses the software’s standard interface. (Note: while the conclusion
 seems correct, the GPL defines Standard Interfaces more narrowly.) Luis
 Villa agrees with Cowan and even suggests that communication via a well
 defined interface cannot be intimate.</p>
<p>Nicholas Weinstock thinks that this viewpoint makes sense and can 
explain why/when downstream users are subject to the (A)GPL, but wonders
 whether this would go against the “Torvalds Exception” (a statement 
that user space programs are not derivative of the Linux kernel). Bruce 
Perens confirms Weinstock’s understanding that copyleft affects 
downstream use, but notes that the Torvalds Exception isn’t so much an 
exception as a clarification of what the GPL is saying anyway. Perens 
cautions that if APIs are indeed copyrightable (cf Oracle v Google) then
 dynamic linking does not insulate downstream users from GPL-covered 
code.</p>
<p>In general, Perens subscribes to the idea that intimacy does not 
apply when using a public API: “The programmers intended for you to use 
the API to connect to other programs” and “Intimacy requires intrusion 
into the internals of the program beyond the API published for 
programmers to use.” But with API copyrightability, “intimacy is not 
required for the creation of a derivative work” and a software would be 
derivative “even if it only uses the library’s published API.” Weinstock
 points out that the distinction between internal and external APIs is 
not clear, for example when a fork could expose previously-internal 
APIs.</p>
<p><b id="gmail-corresponding-source">Corresponding Source</b></p>
<p>Lukas Atkinson notes that the GPL only talks about intimate 
communication as an example for what must be included in the software’s 
Corresponding Source. The Corresponding Source must include everything 
necessary to build, install, and run the software, i.e. any <em>upstream</em> dependencies.</p>
<p>Talking about intimate communication or different kinds of linking is pointless when looking at <em>downstream</em>
 usage of the software: the GPL does not and cannot define what counts 
as a derivative work, because that is the job of copyright law.</p>
<p>Nicholas Weinstock asks whether this means that a GPL application is 
forbidden from relying on incompatibly-licensed libraries, and whether 
non-necessary libraries would not be intimate. Bruce Perens agrees with 
Atkinson’s understanding of Corresponding Source and confirms that 
dependencies of GPL software must use a compatible license. Perens adds 
that the GPL Additional Permissions mechanism can be used to avoid some 
incompatibilities.</p>
<p><b id="gmail-is-it-a-problem-that-the-fsf-introduced-a-new-word">Is it a problem that the FSF introduced a new word?</b></p>
<p>There is some discontent that the GPLv3 introduces the term 
“intimate” which has no definition within the license or in legal usage.
 Such a vague word brings legal uncertainty, and might discourage (A)GPL
 use. Therefore, many people would like to see a clear statement from 
the FSF on the meaning of this word, in particular on when two programs 
perform intimate communication.</p>
<p>Bruce Perens explains why that is not going to happen: The GPL tries 
to discourage license circumvention attempts, so it will not use narrow 
language. As a matter of strategy, the FSF does not issue such 
clarifications because that would limit them. They want to be able to 
use the maximal interpretation available in a jurisdiction.</p>
<p>Scott Peterson points at the GPL FAQ for examples that discuss intimacy and at the <a href="http://gplv3.fsf.org/gpl3-dd3-rationale.pdf">GPLv3 rationale documents</a>.
 The license draft had originally talked about “complex” data 
communication, but that was considered to suggest incorrect 
interpretations:</p>
<blockquote>
<p>“Intimate” is the most useful term we know to describe the kind of 
convoluted interaction and deep knowledge that suggest that one part is 
specifically designed to require another part.</p>
</blockquote>
<p>Lawrence Rosen is sceptical about the legal relevance of “convoluted 
interaction” and “deep knowledge” and thinks that the concept of 
Corresponding Source was “the worst mistake of GPLv3 drafting.” John 
Cowan thinks that “designed to require” is a useful test. Cowan points 
to the CLISP, which became available under the GPL because it required 
the readline library. But things get murky when considering alternative 
implementations: was a program using an alternative implementation 
designed to require the (interface of the) GPL-covered program? The FSF 
seems to think so, leading to proliferation of different APIs and 
compatibility wrappers.</p>
<p><b id="gmail-making-sense-of-the-law-and-bright-lines">Making sense of the law, and bright lines</b></p>
<p>When talking with engineers, Nicholas Weinstock has also hear some 
other ideas on what intimacy could mean here: Maybe two programs are 
intimate if their interaction was developed together? Or “intimate” 
could refer to categories of data rather than to the mechanism of 
communication?</p>
<p>Bruce Perens cautions that legal topics don’t necessarily make sense 
for engineers. License compliance is required “whether or not it fits 
with conventional process in your industry.” Instead of trying to find 
ways to combine copyleft with proprietary code, the better approach is 
to architect the software to keep them clearly apart.</p>
<p>Rick Moen concurs: whether a work is derivative is for caselaw to 
decide, not for engineers or licenses. And there is little reason to 
think that courts would be impressed by coder’s ideas regarding internal
 or external APIs, or different kinds of linking. This isn’t just about 
the GPL but about using any kind of copyrighted material. The solution 
is to either hire legal help, pay for license exceptions, or to just 
stay away from areas of controversy.</p>
<p>John Cowan notes that the industry usage of a word might very well be
 relevant before a court, but unfortunately “intimate” has no industry 
usage.</p>
<p>Lawrence Rosen would like more clarity on technical architectures 
that safely allow use of copyleft interfaces. “No FOSS license that 
prohibits that is truly open source!” Bruce Perens seems a bit fed up 
with that attitude: some licenses clearly intend to prevent combination 
with proprietary software. “There is nothing about Open Source that says
 they have to give a free ride to anyone”. Suitable architectures 
clearly avoid derivative works and keep a “bright line” that would be 
“extremely clear to any court.”</p>
<p>Gil Yehuda thinks that if creating a compliant architecture requires a
 lawyer, that is a problem with the license. (Note: but this discussion 
is about architectures that <em>avoid</em> the need for license 
compliance!) No license can be simple, as Perens points out, because 
these legal documents rest on a huge body of case law. And even simple 
documents can have complicated results, for example an implied patent 
grant in the BSD license.</p>
<p><b id="gmail-great-expectations">Great Expectations</b></p>
<p>Gil Yehuda thinks it is important to distinguish two separate 
motivations for using copyleft: some want Free Software, but others want
 to a license that is permissive enough to see their software be widely 
adapted, but still sufficiently restricted to convert some users to 
commercial licenses. There’s nothing wrong with dual licensing (in fact,
 Bruce Perens considers dual licensing to be beneficial because it funds
 the production of more Open Source software) but it is unsurprising 
that there will be misunderstanding and frustration when dual-licensing 
businesses use Free Software licenses.</p>
<p>For example, Lawrence Rosen repeatedly suggests his OSL 3.0 as a less
 extreme network-copyleft license than the AGPL. Rosen reminds that Open
 Source is more than the GPL. Many other licenses are being proposed 
because the GPL doesn’t fulfil those licensor’s motivations. “Perhaps we
 should consider the intent of the SSPL licensors and help them create 
or use an alternative non-GPL license?” Bruce Perens notes that the SSPL
 goes far beyond the OSL as well. He writes: “Unfortunately, a lot of 
what these companies want to do can’t be achieved as Open Source, and it
 is best that all sides understand that and go on.”</p>
<p><b id="gmail-relicensing-and-maintainercommunity-dynamics">Relicensing and Maintainer–Community Dynamics</b></p>
<p>Out of the C-FSL discussion on the license-review list, a discussion 
forms about historical examples of maintainer–community dynamics, forks,
 and license changes. For context, the C-FSL gives some Original Authors
 the right to change the licensing of the code, without having to get 
extra permission from all copyright holders.</p>
<p>The typical mechanism for license changes is to contact all copyright
 holders. If a few copyright holders reject the change, their 
contributions can be removed. And this is workable, as history points 
out: Dungeon Crawl, Toybox, Mozilla, OpenSSL, OpenStreetMap are 
mentioned by Brendan Hickey and Rob Landley.</p>
<p><span class="gmail-no-elide"><a href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html">Rob Landley</a></span>
 writes an epic email with lots of project histories. A fork is not 
necessarily an alternative version of some project, but could also be a 
new project that an existing community rallies around. For example, 
Linux could be interpreted as a fork of the Minix community.</p>
<p>Of particular interest is XFree86, which suffered a relicensing by 
its management. But: “The code survived, forked under new maintainership
 and a new name, with many of the same developers and inheriting pretty 
much all the users.” Looking forward, Landley asks: “The bad things 
happened <em>anyway</em>. What methods of organization <em>survived</em>
 the bad things?” Bruce Perens notes: “It is definitively a really good 
and important feature of Open Source licenses that developers can 
abscond from bad management.”</p>
<p>For the C-FSL, this means that it might be a very bad idea to give 
one group of maintainers too much power with the intention of preventing
 forks. For MongoDB’s relicensing, it remains to be seen whether the 
community stays with the original project or moves to forks.</p>
<p>John Cowan cautions that forks can have many fates: while some might 
eat their parent and inherit the name (like GCC 3) or eat their parent 
under a different name (like LibreOffice) some also just fizzle out 
(like Drizzle from MySQL). But “Open-source software doesn’t necessarily
 entail open-source development”. If the software is maintained 
cathedral-style rather than by a community, then giving the original 
developers special rights might not be a big deal. (Note: but what if 
the original maintainers cease to be good stewards? See XFree86 above.)</p>
<p><b id="gmail-developing-a-new-open-source-license">Developing a new Open Source License</b></p>
<p>Van Lindberg announces that he is drafting a new open source license 
for Holo Ltd. and will submit it for OSI approval. The license will be 
AGPL-ish but have an option for an LGPL/Classpath style exception.</p>
<p>Bruce Perens notices that this license is planned to extend to all 
software “that implements a compatible API”. Such an extension of 
copyleft would violate OSD #9 “license must not restrict other software”
 and approval would seem undesirable for the OSI.</p>
<p>Van Lindberg understands and tries to be careful around this, 
especially since he has criticized similar problems with the SSPL. But 
if interfaces are copyrightable (cf Oracle v Google) then such a 
requirement would only affect derivative works, not unrelated software. 
VanL won’t define interfaces but instead considers public performance 
rights. This is analogous to the AGPL network interaction clause, but 
better in line with copyright. (Note: I’d instead say that the AGPL just
 chooses to use one small aspect of public performance.)</p>
<p>Bruce Perens is sceptical of any extensions of copyleft/copyright, 
and points to Open Hardware as an example. The risk is that courts might
 consider this to be valid, thus extending copyright. But that would 
have a stifling effect, especially on Open Hardware. “Extension of 
copyright is bad for Open Source, even if it helps us enforce our 
licenses more effectively. It will always work against us to a greater 
extent [than] it can be put to work for us.”</p>

</div>