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
and covers discussion on the SSPL v2 and the C-FSL.
## opensource.dev
[Chris DiBona (Google)][dibona] announces
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][morrison_opensource.dev]
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][cowan_epl] 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)][milinkovich_epl]
points out that the many Eclipse projects
are a strong community that uses the EPL
– though some might [disagree][glaser_epl]
that a foundation is a community.
[dibona]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020193.html
[morrison_opensource.dev]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020198.html
[cowan_epl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020202.html
[OSI’s licenses page]: https://opensource.org/licenses
[milinkovich_epl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020204.html
[glaser_epl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020207.html
## Open Data
[Christopher Sean Morrison][morrison_open]
announces that the US has signed a new open data law into effect.
[Gil Yehuda][yehuda_open] 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)][SvdW_open]
points to the OKFN’s
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.)
[morrison_open]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020219.html
[yehuda_open]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020220.html
[SvdW_open]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020222.html
## AFL “attribution notice”
[Antoine Thomas (PrestaShop)][thomas_afl]
asks for clarification
how derivative works should provide attribution
under the Academic Free License.
No one responded on-list 🙁
[thomas_afl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020221.html
## Intimacy in Open Source
[Gil Yehuda][yehuda_intimacy] 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][rosen_intimate] also raises the issue
how this interacts with API copyrightability
and what this means for network copyleft like AGPL and SSPL.
Extensive discussion ensues.
[yehuda_intimacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020208.html
[rosen_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020224.html
### Process and interface boundaries
[John Cowan][cowan_intimate] 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][villa_intimate] agrees with Cowan
and even suggests that communication via a well defined interface
cannot be intimate.
[Nicholas Weinstock][weinstock_ccs] 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][perens_downstream]
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][perens_intent] 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][weinstock_intext] points out that
the distinction between internal and external APIs is not clear,
for example when a fork could expose previously-internal APIs.
[cowan_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020209.html
[villa_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020210.html
[perens_downstream]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020228.html
[weinstock_intext]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020232.html
### Corresponding Source
[Lukas Atkinson][atkinson_intimate] 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][weinstock_ccs]
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][perens_resp]
agrees with Atkinson’s understanding of Corresponding Source
and confirms that
dependencies of GPL software must use a compatible license.
[Perens adds][perens_intent] that the GPL Additional Permissions mechanism
can be used to avoid some incompatibilities.
[atkinson_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020215.html
[weinstock_ccs]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020227.html
[perens_resp]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020228.html
[perens_intent]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020231.html
### 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][rosen_intimate] (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][perens_was_there] explains why that is not going to happen:
The GPL tries to [discourage license circumvention attempts][perens_nope],
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][perens_downstream] in a jurisdiction.
[Scott Peterson][peterson_intimate] 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][rosen_gpl3rationale] 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][cowan_readline] 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.
[perens_was_there]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020246.html
[peterson_intimate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020216.html
[GPLv3 rationale documents]: http://gplv3.fsf.org/gpl3-dd3-rationale.pdf
[rosen_gpl3rationale]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020217.html
[cowan_readline]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020218.html
[perens_nope]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020233.html
### Making sense of the law, and bright lines
When talking with engineers, [Nicholas Weinstock][weinstock_ccs]
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][perens_resp] 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][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][cowan_court] 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][rosen_no_true_fossman] 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][perens_come_on] 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][yehuda_nolawyer] 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][perens_simple] 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.
[moen]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020241.html
[rosen_no_true_fossman]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020237.html
[perens_come_on]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020236.html
[cowan_court]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020244.html
[yehuda_nolawyer]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020245.html
[perens_simple]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020247.html
### Great Expectations
[Gil Yehuda][yehuda_tale_of_two] 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][perens_dual_funding]
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][rosen_more] 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][perens_beyond] notes that the SSPL goes far beyond the OSL as well.
[He writes][perens_move_on]:
“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.”
[yehuda_tale_of_two]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020251.html
[perens_dual_funding]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020246.html
[rosen_more]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020254.html
[perens_beyond]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020255.html
[perens_move_on]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020252.html
## 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][hickey_relicensing]
and [Rob Landley][landley_relicensing].
[Rob Landley][landley_epic]
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][landley_methods]:
“The bad things happened *anyway*.
What methods of organization *survived* the bad things?”
[Bruce Perens][perens_abscond] 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][landley_mongodb]
whether the community stays with the original project or moves to forks.
[John Cowan][cowan_fork] 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.)
[hickey_relicensing]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003897.html
[landley_relicensing]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003898.html
[landley_epic]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html
[landley_methods]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003906.html
[perens_abscond]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003903.html
[landley_mongodb]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003939.html
[cowan_fork]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003907.html
## Developing a new Open Source License
Van Lindberg [[1][vanl_ann],[2][vanl_classpath]] 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][perens_aal] 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][vanl_careful_interface] 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][vanl_performance].
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][perens_extensions]
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.”
[vanl_ann]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020257.html
[vanl_classpath]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020258.html
[perens_aal]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020259.html
[vanl_careful_interface]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020264.html
[vanl_performance]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020263.html
[perens_extensions]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020261.html