A clear statement about API interaction sounds like it would go a long way to clarify this section.
Some additional considerations: * What about internal vs external APIs, so internal APIs are “intimate” but external APIs aren’t, similar to the Kernel’s UAPI? * Could a library require API callers be under (A)GPLv3? Or would it need to use something like the Kernel’s MODULE_LICENSE interface? * What is necessary for API extensions to be considered “documented user calls and data structures”? Is it sufficient for the maintainers to integrate source modifications even if the accompanying documentation isn’t updated? Is it sufficient for source modifications to be publicly submitted to the maintainers? What if either of those were maintainers of a distinct fork rather than the original project? Is it sufficient for me to publish my modified version on my personal GitHub page as a one-time fork? Thanks, Nick From: License-discuss <license-discuss-boun...@lists.opensource.org> On Behalf Of Bruce Perens Sent: Tuesday, January 22, 2019 1:21 PM To: license-discuss@lists.opensource.org Subject: Re: [License-discuss] Intimacy in open source (SSPL and AGPL) On Tue, Jan 22, 2019 at 12:32 PM Nicholas Matthew Neft Weinstock <nwein...@qti.qualcomm.com<mailto:nwein...@qti.qualcomm.com>> wrote: Can you explain how you reach this conclusion? My reading of section 6 suggests that Corresponding Source must be conveyed under the terms of this License (e.g., GPLv3). Where does the license allow Corresponding Source to be distributed under a GPLv3-compatible license? You have the whole of section 7 on additional terms to consider. This is really essential, since most of FSF's own libraries are under a compatible license other than (A)GPL3. I’m flipping it around. In this example, we’re saying that if the application needs the library in order to run, this is “intimate data communication” I think you're confused about what is "intimate". Which is completely excusable, it's a confusing term of art and I don't particularly like it. If the application limits its use of the library to the library's API exclusively, using documented user calls and data structures, it's not intimate. Intimacy requires intrusion into the internals of the program beyond the API published for programmers to use. Here is where I think "intent" works better. The programmers intended for you to use the API to connect to other programs. However, given that a court has held that an API can be copyrightable, and no other court has come around to contradict that, intimacy is not required for the creation of a derivative work. Your application licensing must be compatible with that of the library, even if it only uses the library's published API. There is an existing application under CDDL. GNU.org states that this license is incompatible with GPLv3 because it is file-based copyleft, and section 3.1 states that if you distribute in Executable form you must also distribute in Source form under CDDL. There is an existing library under LGPLv3. I want to modify the application so that it needs the unmodified library in order to run. Since CDDL is file-based copyleft, it doesn't impose its own conditions on libraries. And LGPLv3 doesn't impose its conditions on the application. This goes to 1.3 and 1.9 in CDDL. Covered Software doesn't include your own original work, not containing code from the CDDL work, in a separate file. Including libraries. So I don’t believe John’s statement is a complete and usable test for “intimacy” because it is broader than intended as the basis for LGPLv3. I think John intended to imply that his definition covered use other than through the defined API. Thanks Bruce
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
