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

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 18:56 UTC (Sun) by jejb (subscriber, #6654)
In reply to: Elastic promises "open"—delivers proprietary by kemitchell
Parent article: Elastic promises "open"—delivers proprietary

> The trouble with the nondiscrimination criteria, read broadly, is that they'd preclude all copyleft. Copyleft discriminates against closed source development. RMS wrote GPL to discriminate against non-free software and non-free software makers. The whole point was to use copyright against non-free software, as non-free software was using it against free. Free software, and by extension open source, taught the difference between open and closed, and came out strongly for open. "Discriminating" against closed software isn't antithetical to open source, but the point. The choice open source offered to developers was whether to effect that distinction through licensing, by choosing copyleft rather than permissive terms. Both are "open source".

The nondiscrimination criteria of OSD 4,5 aren't broad, they're specific to people or groups and fields of endeavour. Carlo Piana gave an eloquent explanation why the GPL is nondiscriminatory, which you didn't refute, in the original thread you keep referring to:

http://lists.opensource.org/pipermail/license-review_list...

I'm rather reminded of monopolists trying to argue they shouldn't be separately regulated because of the equal protection clause.

> The other-software arguments try to go the other way. Instead of working down from a vague criterion to an oddly specific rejection, they start from a specific criterion, OSD 9, and try to argue that it should really be vague and general.

To me the OSD 9 argument is simple. OSD9 says "License Must Not Restrict Other Software" GPL gets around this by only trying to restrict derivative works, which are ipso facto the same software. SSPL tries to encumber every other work used to make the service:

"Service Source Code" means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service

It's a clear restriction on other software.

to post comments

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 20:26 UTC (Sun) by kemitchell (subscriber, #124442) [Link] (22 responses)

I didn't argue with Carlo about AGPL passing the nondiscrimination criteria because he was making my point. The very broad readings of OSD 5 and 6 pushed against new, stronger copyleft licenses can't be right, because they'd have excluded older copyleft licenses, like AGPL, GPL, and even LGPL/MPL/EPL. When we apply OSD criteria, we have to do consistently. We can't read OSD 5 and 6 against SSPL today in ways that would have excluded AGPL years ago.

As for OSD 9, the original heading in DFSG is "License Must Not Contaminate Other Software". That's even more general. But we get a better sense of what was actually meant in the text, below the heading. The only change in the text of criterion 9 from DFSG to OSD was replacing "free" with "open source". It's the same old Debian distribution protection.

Ignoring the text and focusing on the vague heading is just as I said: a way to smudge out a specific criterion into something vague. Vagueness can be weaponized against new terms.

We don't know the full extent of "derivative work" in software under US law. Don't trust anyone who pretends they do. But copyleft licenses haven't just limited themselves to derivative works, either. Have a look at the definition of "Corresponding Source" in GPLv3, AGPLv3, inherited also in SSPLv1.

I agree with many critics that paragraph 1 of section 13 of SSPL could be better written. And I've collaborated on a license that I think goes to the same goal, with a much more robust and approachable language. But I don't think the functional specification for SSPL is anything but a predictable evolution of open source network copyleft. It's basically LAGPLv4.

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:38 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

I think this is a much more reasonable license than SSPL. I worry about a couple of things:

1) The requirement that changes be made available to the public even if the code isn't exposed to the public in any way. This feels like something that, realistically, just results in the software not being used for that purpose rather than increasing useful contributions. It's also something Debian has traditionally had objections to, for instance in cases where software is developed to use in activities that your government may not approve of.
2) There being a bunch of argument around what "practical substitute" ends up meaning

/Personally/, I don't think these affect the freedom of the license (although others might). I think (1) would be enough for me to avoid releasing any of my code under this license, but probably not enough for me to refuse to contribute to projects under it.

Elastic promises "open"—delivers proprietary

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

First of all: I really appreciate your candid feedback. You didn't have to read a license just because I linked to it.

Second: Are you in Oakland? If so, we're overdue for a meet-and-greet. I have a pretty good excuse these days, but still...

You were right to home in on the fact that share-alike kicks in whether you "distribute" or not. That's an important point. I'd love to discuss if you're interested, but it's definitely a deep hole. My personal take is that it's essential for strong network copyleft, the Debian Desert Island and Dissident tests are more fun to think about than coherent or useful, and some existing licenses have gone there already, most notably OSL.

I was also super impressed to see that you alerted on "practical substitute", too. Not because I'm any kind of Super Lawyer, but because it's hard to cold read a new set of terms and issue spot like that. Takes a lot of attention.

The license had to draw a line around what users can do without releasing code and what requires releasing code. We didn't want to bind strongly to any particular means of software combination—copy-paste, linking, service composition—hence the focus on APIs. But you have to catch the "proxy" case where new code essentially just wraps the API of the existing code.

PolyForm project released two restricted licenses, Perimeter and Shield, that tackle analogous drafting problems. But for Round Robin, the mental model wasn't commercial anti-competition, but anti-fork, in the sense that MPL defended against closed or differently-licensed forks, in favor of a unified open project.

Again, real pleasure reading your comment.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:05 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (1 responses)

I absolutely agree with the fact that it should not be possible for someone to simply take some code under a copyleft license, wrap it in something that calls into that code via a defined API, extends the original functionality of that code and is never under any obligation to share their modifications[1]. I assume the concern here is that "derived work" may not cover that case? You're certainly in a better position than me to have feelings about how a court might interpret the "practical substitute" language, but my gut feeling is that people would be happier if there was some more examples of cases that might or might not be considered a practical substitute.

(By the way, I *love* the option of releasing impacted code under different license terms. Even as someone who leans strongly towards copyleft, there are cases where imposing the same level of requirement on impacted code may not be the best way to encourage adoption)

[1] Although we may well differ in terms of when that obligation should kick in, and yes, once the situation has normalised somewhat I would appreciate the opportunity to discuss that

Elastic promises "open"—delivers proprietary

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

I could make legal arguments about the scope of "derivative work" in your hypothetical, but frankly, they're so deep in the weeds, not to mention arguable, that most non-lawyers would do best to just avoid the issue if at all possible. To give a sense, we don't even know for sure the full extent of what can be the "original work" a "derivative work" could be based on. If you copy and adapt the whole API, did you just create a "derivative work" of a copyrightable API design? Maybe the Supreme Court will get around to telling us next month.

As for the motive behind that drafting, it didn't have to do anything with whether an API wrapper or proxy would count as preparing a derivative work. As a practical matter, you're not going to develop, much less distribute, that kind of software without reproducing copies of the original. Which means you need a copyright license. Which can set its own terms. To my mind, it was 100% a problem of clear writing at the right level of abstraction. The language you saw was massively improved by input from others, and specifically others not irrevocably warped by legal education.

I'll never say that I originated the idea of copyleft that leaves a choice of more permissive terms, but the first time I saw it was in Parity, which I wrote for License Zero. I still go back and forth, finding hypotheticals when I'd want to require the same license terms, and also the other way around. Overall, I do think possession of source code is nine tenths of freedom, and that curtailing license-compatibility madness is a huge boon.

I've added you to my "after COVID" list. Hopefully we'll get a chance sooner than we expect.

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:44 UTC (Sun) by jejb (subscriber, #6654) [Link] (15 responses)

> But copyleft licenses haven't just limited themselves to derivative works, either. Have a look at the definition of "Corresponding Source" in GPLv3, AGPLv3, inherited also in SSPLv1.

"Corresponding Source" in the GPL family of licences means the components and scripts necessary to turn the covered source code into a binary representation, excluding all those pieces that are commonly available. It also just requires a source release and doesn't prescribe the licence of that release. Such specific scripts might not be derived works of the original but, since they're so tightly coupled to the build, neither are they other software (and they're certainly not usually distributed with the work). Calling something "Corresponding Source" in a licence doesn't make it equivalent to GPL "Corresponding Source" particularly when it tries to scoop up everything necessary to deliver the service.

I think we could have a useful conversation about what could be corresponding source when delivering a network service, and people have speculated about building a maximal copyleft licence to move closer to the line of impinging on other software. However, it seems obvious to me that "everything required to deliver the service" is way over the line wherever it happens to be.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 1:29 UTC (Mon) by kemitchell (subscriber, #124442) [Link] (14 responses)

Can you point me to some reading about the argument that Corresponding Source need not be licensed under GPLv3? I don't believe I've ever seen an argument that GPL requires conveying code without also requiring it be licensed. The requirement to offer source under section 13 or AGPL, for example, is read to trigger the requirements of section 5.

Elastic promises "open"—delivers proprietary

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

I deal mostly with GPLv2 not v3. For v2 there was a discussion about this over a decade ago when Intel tried to make the kernel compatible with the icc as well as gcc. icc at the time was an intel proprietary compiler. Releasing only the Makefiles for icc was deemed good enough and a source release of icc wasn't required.

The reasoning for v2 was that the licence only attaches to the Program and section 2 only requires the program and derivatives to be under the GPL. Section 3 which mentions complete and corresponding source says nothing about the licence it should be under and does contemplate that corresponding source may be more than the Program to which the rest of the licence refers. Thus the rule of thumb that as long as we have enough information to build the binary, that's good enough regardless of the licence of the additional information.

A cursory reading of GPLv3 shows that it also seems to maintain this separation between "the Program" and its derivatives and the corresponding source which includes the build scripts.

Elastic promises "open"—delivers proprietary

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

<p>GPLv2 doesn't say "Corresponding Source", but it defines "complete source code" to include build and install scripts.</p>

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 2:20 UTC (Mon) by jejb (subscriber, #6654) [Link] (10 responses)

Well it doesn't have a definitions section like v3, certainly.

However section 2 refers to both "complete source code" and "complete corresponding machine-readable source code"

But regardless of the terminology confusions in v2 it still doesn't contemplate the scripts being released under the same licence as the program, merely the source code for them being made available.

Elastic promises "open"—delivers proprietary

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

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?

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.

Elastic promises "open"—delivers proprietary

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

> Can you point me to some reading about the argument that Corresponding Source need not be licensed under GPLv3?

USE YOUR LAWYERLY BRAIN!!!

Pretty much ANY large GPL project will not have all its Corresponding Source licenced under the GPL. The linux kernel for one. LibreOffice for another.

What happens if you take SOMEONE ELSE'S eg MIT-licenced code and include it in your GPL project? YOU CANNOT RELICENCE THEIR CODE.

The project as a whole can only be safely distributed under the GPL - that is the intent and magic of the GPL. But each piece of the Corresponding Source is licenced according to the ORIGINAL AUTHOR, and needn't be GPL at all.

Ask yourself this simple question - "If I include someone else's NON-GPL code in my project, how do I re-licence it for release under the GPL?" The answer is YOU CAN'T.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 23:49 UTC (Sun) by jejb (subscriber, #6654) [Link] (1 responses)

> And I've collaborated on a license that I think goes to the same goal, with a much more robust and approachable language.

The Round Robin Licence to me actually seems very similar in intent and action to the Reciprocal Public Licence, which is OSI approved.

Elastic promises "open"—delivers proprietary

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

As much as it warms my heart to read the letters "RPL" from someone else, I must warn you, from experience, that you will make a lot more people angry than happy by mentioning it!

Fun Fact! The Technical Pursuit guys, who came up with RPL for a JavaScript web framework before anybody thought that was a thing, are still at it. I've run into a few other companies, too: ActiveAgenda, Open Justice Broker Consortium, Particular Software, Pixelglow.