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 <opensou...@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@lists.opensource.org > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org >
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
