<div dir="ltr"><div>Hey Lukas -</div><div><br></div><div>I just want to say "thank you" for putting these summaries together. As someone whose participation on this list is more limited by my available time than I would like, I really appreciate your boiled-down digests of the threads I can't track in real-time.</div><div><br></div><div>Thank you!</div><div><br></div><div>Cheers,</div><div>Ben<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 4, 2019 at 5:03 PM Lukas Atkinson <<a href="mailto:opensource@lukasatkinson.de">opensource@lukasatkinson.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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-m_-2176610082629728792gmail-uri" href="https://opensource.org/LicenseDiscuss012019" target="_blank">https://opensource.org/LicenseDiscuss012019</a>.</p>
<p>The corresponding License-Review summary is online at <a class="gmail-m_-2176610082629728792gmail-uri" href="https://opensource.org/LicenseReview012019" target="_blank">https://opensource.org/LicenseReview012019</a> and covers discussion on the SSPL v2 and the C-FSL.</p>
<p><b id="gmail-m_-2176610082629728792gmail-opensource.dev">opensource.dev</b></p>
<p>Chris DiBona (Google) announces <a class="gmail-m_-2176610082629728792gmail-uri" href="https://opensource.dev/" target="_blank">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" target="_blank">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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-uri" href="https://opendefinition.org" target="_blank">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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-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" target="_blank">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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-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-m_-2176610082629728792gmail-no-elide"><a href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html" target="_blank">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-m_-2176610082629728792gmail-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>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>