January 2019 License-Discuss Summary

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

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


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. 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. 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 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 [1,2] 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.”

To promote and protect open source software and communities...

For over 20 years the Open Source Initiative (OSI) has worked to raise awareness and adoption of open source software, and build bridges between open source communities of practice. As a global non-profit, the OSI champions software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition (OSD), and preventing abuse of the ideals and ethos inherent to the open source movement.

Open source software is made by many people and distributed under an OSD-compliant license which grants all the rights to use, study, change, and share the software in modified and unmodified form. Software freedom is essential to enabling community development of open source software.