Elastic promises "open"—delivers proprietary [LWN.net]

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:32 UTC (Mon) by kemitchell (subscriber, #124442)
In reply to: Elastic promises "open"—delivers proprietary by jejb
Parent article: Elastic promises "open"—delivers proprietary

It's not clear, to my eye:

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; ... [emphasis mine]

2. ...
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

Have you seen a specific position on this from FSF or others?

to post comments

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 8:21 UTC (Mon) by Wol (subscriber, #4433) [Link] (4 responses)

Ahhhh - looking at 2(b) the source of your confusion is obvious.

It does NOT say "the Corresponding Source must be released under this licence".

It says "the Corresponding Source AS A WHOLE WORK .... EXCLUDING any sections that are identifiable and not derived works" (ie pretty much any source file you have not edited!) And if you edit a source file it becomes a derived work, and you must release your modifications to it "under this licence".

You are making the same mistake I have a habit of making - you are not READING THE FULL TEXT. It's called "taking things out of context" and it leads to exactly this sort of mistake.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:01 UTC (Mon) by kemitchell (subscriber, #124442) [Link] (3 responses)

"Derivative works" aren't necessarily limited to files you edit.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:51 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

At which point, I just HAVE to call "troll". Either that, or you're a real copyright lawyer who doesn't have a clue about copyright - which wouldn't surprise me at all :-)

You misquote legalese. You have too many glib answers. And you've made no attempt whatsoever to address direct questions as to how you'd achieve what you say others must do!

Sorry - that's ABSOLUTELY TYPICAL troll.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 3, 2021 21:46 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Err... derivative works are definitely not limited to files you edit. If you have a program A and you edit a dozen files and then release it again, the *whole work* is a derivative of the original, even though most of the files were not edited. (Similarly, if you edit a book and change half the chapters and then republish it, the new book is a derivative of the old even though half the chapters are unchanged.)

Elastic promises "open"—delivers proprietary

Posted Feb 3, 2021 23:17 UTC (Wed) by Wol (subscriber, #4433) [Link]

In the "Corresponding Source"?

Certainly if you edit source file A and re-release it, the resulting *binary* is a derived work, but source files B, C and D are not.

kemitchell is classic troll, relying on people like you missing that fact ... *detail* *matters*.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 16:12 UTC (Mon) by jejb (subscriber, #6654) [Link] (3 responses)

> Have you seen a specific position on this from FSF or others?

I gave the example I know about. It has now been accepted practice for over a decade that the Linux Kernel can be built by proprietary toolchains and the FSF hasn't objected. I would imagine by now there's a strong estoppel argument against anyone trying to say that GPLv2 requires releasing the build scripts and tools under GPLv2.

Even if you overcome the estoppel problem, under section 2, you'd really have to get a court to agree that build tools and build scripts are derived from the program, because if they're not, they are "identifiable sections" that don't have to be under the licence. Given the uncertainty over linking, that sounds like a huge stretch to me.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:04 UTC (Mon) by kemitchell (subscriber, #124442) [Link] (2 responses)

I asked about another source for this argument, because I suspect it was either FSF gloss or kernel lore. Both of those institutions have developed a "folk law" of GPLv2 interpretation that doesn't necessarily follow from its text.

I don't think estoppel would apply so cleanly as you think. Especially if there's no written statement out there telling people they can share some parts of complete source code / Corresponding Source without licensing under GPL.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 18:52 UTC (Mon) by jejb (subscriber, #6654) [Link] (1 responses)

> I asked about another source for this argument, because I suspect it was either FSF gloss or kernel lore. Both of those institutions have developed a "folk law" of GPLv2 interpretation that doesn't necessarily follow from its text.

I already told you I was present for the discussion: this isn't some received wisdom, it's something I remember happening. Likely we may have email archives from the time as well (although I'm not certain about how long ago it was, so finding them is going to be a pain) and I can bet intel is going to have preserved the records to make absolutely sure we have no claim requiring their open sourcing of icc.

This isn't just the kernel being different, it has been the FSF practice since the early days as well: the gnu tools were created and released under GPLv2 long before we had a usable gcc. The only way to build them in those days was with the proprietary tools on whatever unix platform you had. Most of those projects still have autoconf fragments that check for the proprietary compilers if you need written evidence.

> I don't think estoppel would apply so cleanly as you think. Especially if there's no written statement out there telling people they can share some parts of complete source code / Corresponding Source without licensing under GPL.

My understanding based on having a lawyer take me through the various estoppel doctrines for another matter is that if it becomes standard practice it may be relied on without a written promise. icc isn't the only proprietary toolchain that has been used to compile Linux: the practice is rife throughout the embedded space as well.

Plus, as I said before, the clear exclusion of identifiable sections of the corresponding source that aren't derived works of the program in section 2 means that to require the scripts and the compiler to be under GPLv2 you'll have a way to prove in court that they're derived works of the Program the licence was protecting.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 19:22 UTC (Mon) by kemitchell (subscriber, #124442) [Link]

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.