[License-discuss] January 2019 Summary

Mon Feb 18 16:31:34 UTC 2019

Hey Lukas -

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.

Thank you!

Cheers,
Ben

On Mon, Feb 4, 2019 at 5:03 PM Lukas Atkinson <opensource at lukasatkinson.de>
wrote:

> 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.”
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190218/38a77a50/attachment-0001.html>