I agree, it would be very helpful to have a clear statement of the intent of that paragraph in (A)GPLv3.
I've seen two very different concepts discussed in this thread. On Sunday the 13th, Lukas discussed the idea that "intimate" communication is in regards to distributing Corresponding Source, so the license must mean that "anything needed to run the software" must also be released under (A)GPLv3. He effectively suggests that if a GPLv3 application is developed so that it cannot run without a given library, the library must also be released under (A)GPLv3. The next day, on Monday the 14th, John Cowan described the idea in the exact inverse: If you develop an application so that it cannot run without a given (A)GPLv3 library, your application must also be released under (A)GPLv3. Both are tempting, but I'm not sure that either makes sense in all situations. Lukas' idea certainly makes sense within the context of that paragraph. But what if I want to modify an existing open source application under GPLv3 to interact with an existing open source library under one of the licenses that are not compatible with GPLv3 (as discussed by GNU.org at https://www.gnu.org/licenses/license-list.en.html#GPLIncompatibleLicenses)? Does this mean I'm not allowed to modify the application to work with the library? If I modify the application to work with the library, but the application is also capable of working without the library (similar to 2(a) from LGPLv3), does this mean it's no longer "intimate" since the library is no longer needed to run the software? John's idea makes sense philosophically for GPLv3, but I'm not sure that the additional permissions in LGPLv3 are enough to work with this interpretation in all cases. What if I want to modify an existing application that is under an incompatible open source license to work only with an LGPLv3 library, and the application's license requires me to distribute as source? LGPLv3 doesn't grant any additional permissions that would save the application in this case. Although it's not directly relevant because of different license versions, I'd also point out that John's interpretation goes against the so-called "Torvalds Exception." One other point of consideration: When I give training on open source licenses, this idea of "intimate" nearly always comes up. I lead the class (generally Engineers not trained in law nor familiar with the GPLv3 background) in a discussion of what it might mean. Some other notable ideas I've heard: * Maybe it means only if the two are developed together, so that the application and library are both developed to run only with each other. * Slight modification: Could also include if both were modified in regards to the specific "intimate" data communications. * Maybe it needs to be complex data structures, so if the interaction only uses default data types present in the language (e.g., int, char, bool, String) it can't ever be intimate. * Maybe grammatically it should be read as "communication of intimate data" which is judging the data being communicated, so a banking app communicates intimate data but a weather app does not. Thanks, Nick From: License-discuss <license-discuss-boun...@lists.opensource.org> On Behalf Of Lawrence Rosen Sent: Friday, January 18, 2019 2:33 PM To: license-discuss@lists.opensource.org Subject: [License-discuss] Intimacy in open source (SSPL and AGPL) There is a lot of recent news about the SSPL license reactions by Red Hat and OSI and others. FWIW (despite the fact that I don't use MongoDB), I agree with their decisions to forego MongoDB software because of its overbroad "copyleft" and "corresponding source" SSPL license requirements. Requiring licensees to disclose the source code of much of their other networking software is a burden too painful. But I also understand and appreciate the MongoDB business case dilemma. If they just give their software away without some copyleft conditions for free network use, they will not profit much from it. SSPL and that MongoDB issue is not a unique situation. There is also a lot of AGPL license resistance by licensees for many of the same reasons of "overbroad copyleft" and its definition of "corresponding source". I asked Bruce Perens and John Cowen about it privately. They reminded me of the Oracle v. Google case, where various courts had various opinions about whether APIs (and thus the interactions among software components) could be "fair use" or could alternatively require copyleft and licensing. This was recently described on the OSI license-discuss@ email list as "Intimacy in open source," quoting the AGPL and the GPLv3 discussion drafts. I'll suggest instead that all software (especially open source software!) is intended to be intimate with other software, and thus the word "intimate" is both overbroad and completely vague. So is the phrase "corresponding source." Bruce pointed out that we should consider instead the "intent" of the license authors, rather than focus on vague words like "intimacy." The FSF has written volumes about its GPL and AGPL copyleft requirements. We think we know their intent. I like his word "intent." It is an important word in law and with software licenses. But in civil litigation or criminal cases, "intent" can't be used vaguely, or the defendant won't be convicted. Licenses and laws should say exactly what they mean. So, if our community can come up with an adequate definition of "corresponding source" (or "intimacy") in the open source software context to enforce the intent of our network services copyleft licenses, I'm all ears. Neither SSPL nor AGPL currently meet that clarity requirement. /Larry Lawrence Rosen Rosenlaw (www.rosenlaw.com<http://www.rosenlaw.com/>) LinkedIn: LawrenceRosen 3001 King Ranch Rd., Ukiah, CA 95482 Cell: 707-478-8932 This email is licensed under CC-BY-4.0<https://creativecommons.org/licenses/by/4.0/>. Please copy freely. [https://licensebuttons.net/l/by/4.0/88x31.png]
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
