Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Posted Feb 1, 2021 19:22 UTC (Mon) by kemitchell (subscriber, #124442)In reply to: Elastic promises "open"—delivers proprietary by jejb
Parent article: Elastic promises "open"—delivers proprietary
I don't doubt this has come up before, or that folks involved at the time came to an understanding. But I don't think that understanding, whatever it was, flows inexorably from the plain text of GPLv2.
Nothing strange about that idea. Both FSF and the kernel have developed, and often shared, lots of understandings and expectations about how the license applies to their work. Some of that ends up documented, like the kernel user-space exception or the FSF GPL FAQs. Some of it's scattered around in mailing list archives and between devs' ears.
I'm interested in the written record of the conversation around this because that would give me a sense of the arguments deployed, as well as who, and which projects, might be held to that interpretation. If it's an FSF thing, it may not apply to the kernel, and vice versa. Or it may be the accepted norm for both FSF projects and the kernel, but not necessarily for other GPLv2-licensed projects.
It's a tangent, but on your note about build tools: Especially GPLv3 spilled a bit of ink to catch scripts, but not tools they invoke, like compilers. Which, as you point out, weren't free early on in free software history. Ref:
However, it [Corresponding Source] does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.
One of the complaints against SSPLv1 is that it threatens to reach the kernel and other system-level utilities, because it doesn't have this kind of limitation in section 13. Mongo sent a proposed revision of SSPL to the OSI mailing list that partially addressed those concerns. I suspect they initially left it out because they'd seen it was possible to argue that the definition of "Corresponding Source" in AGPLv3 "insulates" containerized services from the reach of copyleft. It's analogous to the (somewhat dubious) idea that you can "wrap" GPL code, and then invoke the wrapper in a way that avoids triggering copyleft.
