[License-discuss] January 2019 Summary

[Lukas Atkinson]

In January, the License-Discuss mailing list discussed:

   - the opensource.dev info site
   - Open Data
   - “intimacy” in Open Source licenses
      - process and interface boundaries
      - corresponding Source
      - is it a problem that the FSF introduced a new word?
      - making sense of the law, and bright lines
      - licensor expectations
   - relicensing and maintainer–community dynamics
   - VanL’s upcoming copyleft license

This summary can also be read online at
https://opensource.org/LicenseDiscuss012019.

The corresponding License-Review summary is online at
https://opensource.org/LicenseReview012019 and covers discussion on the
SSPL v2 and the C-FSL.

*opensource.dev*

Chris DiBona (Google) announces https://opensource.dev/, 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.

The opensource.dev site links to the OSI’s licenses page
<https://opensource.org/licenses>. 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.

*Open Data*

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 https://opendefinition.org 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.)

*AFL “attribution notice”*

Antoine Thomas (PrestaShop) asks for clarification how derivative works
should provide attribution under the Academic Free License. No one
responded on-list :(

*Intimacy in Open Source*

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.

*Process and interface boundaries*

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.

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.

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.

*Corresponding Source*

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 *upstream* dependencies.

Talking about intimate communication or different kinds of linking is
pointless when looking at *downstream* 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.

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.

*Is it a problem that the FSF introduced a new word?*

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.

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.

Scott Peterson points at the GPL FAQ for examples that discuss intimacy and
at the GPLv3 rationale documents
<http://gplv3.fsf.org/gpl3-dd3-rationale.pdf>. The license draft had
originally talked about “complex” data communication, but that was
considered to suggest incorrect interpretations:

“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.

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.

*Making sense of the law, and bright lines*

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?

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.

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.

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.

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.”

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 *avoid* 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.

*Great Expectations*

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.

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.”

*Relicensing and Maintainer–Community Dynamics*

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.

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.

Rob Landley
<http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html>
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.

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 *anyway*.
What methods of organization *survived* 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.”

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.

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.)

*Developing a new Open Source License*

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.

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.

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.)

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.”
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190204/0a0ae0e9/attachment-0001.html>