LWN: Comments on "Elastic promises "open"—delivers proprietary"

Elastic promises "open"—delivers proprietary

robert.berger — Sun, 12 Mar 2023 09:10:26 +0000

relicensing:

Here[1] it says: ". What are the Apache License terms & conditions?
The Apache License is a permissive open source software license - so you can release your modified version of the Apache licensed product under any license of your choice..."

"... However, you are required to release all the unmodified parts of the software under the same license (the Apache License)..."

[1] https://www.mend.io/resources/blog/top-10-apache-license-...

Elastic promises "open"—delivers proprietary

emorrp1 — Mon, 08 Feb 2021 09:52:23 +0000

Wow, thank you for all the prose you've spent time writing, I did read the OSI thread about SSPL originally but I'm inherently biased to trust Debian's approach. Thank you for providing a fascinating, well-argued perspective engaging in all the objections and keeping the discussion human leading to some some great quotes.

Elastic promises "open"—delivers proprietary

flussence — Fri, 05 Feb 2021 20:56:51 +0000

Where AT&T (and SCO) failed was in not obfuscating the fraud well enough, and choosing to make an enemy of a large, well-organised group instead of trampling individuals. For a success story, see VMware.

Incidentally, this sort of scam is now the main business model of the “music rights societies” (a euphemism if there ever was one) feeding off of Youtube's automated system. Make a throwaway shell company with a name that looks like it was algorithmically generated itself, upload recordings of white noise, covers of other people's music, microphones pointed at bird feeders, and monetise, monetise, monetise. The system they abuse is built to be a death march for anyone coming in at the other side (Google will do anything to avoid employing real humans to support their products), so this is virtually consequence-free.

Elastic promises "open"—delivers proprietary

Wol — Fri, 05 Feb 2021 15:13:37 +0000

Does Apache 2 allow re-licencing? PROBABLY NOT.

Does it allow mixing with closed code? I think it does.

So no you probably can't *change* Apache 2 to closed, but there is no bar to inluding Apache 2 code in your closed project.

Okay, nit-picking, but get the legal nits wrong and it can be nasty - nits bite!

Cheers,
Wol

Elastic promises "open"—delivers proprietary

robert.berger — Thu, 04 Feb 2021 21:12:53 +0000

I am not a lawyer but also thought that Apache 2 does not require a CLA to be changed to a proprietary license. This might also be a reason why its usage is on the rise while copyleft license usage is declining.

Elastic promises "open"—delivers proprietary

amacater — Thu, 04 Feb 2021 10:02:38 +0000

Possibly University of New South Wales - John Lions was there. https://en.wikipedia.org/wiki/John_Lions

Elastic promises "open"—delivers proprietary

Wol — Thu, 04 Feb 2021 09:48:26 +0000

Bear in mind that - in the US - they weren't part of Berne until 1984. It was therefore assumed that software was covered by contract and trade secret, not copyright. Also, when was GNU founded? Early 80s? Nearly all software prior to Berne/mid-80s was open source, as in when you bought a computer you got the software AND THE SOURCE to the software.

At some point late 70s early 80s I guess, especially given that AT&T was governed by the anti-trust rules that they weren't allowed to compete in the software business, it was *company* *policy* that all software should be supplied without copyright notices (seeing as it was believed copyright didn't apply).

Problem was, Unix as supplied by AT&T contained a LOT of code from three University sources - Berkeley who claimed copyright, that Australian university who's name I always forget, and University College London, for whom the latter two copyright definitely DID apply.

So the Judge's guidance before making a ruling said "AT&T have deleted the copyright notices, therefore it's down to AT&T to prove they own the code". Seeing as I guess they didn't have a decent and long-standing backup system to prove where the code came from, they threw in the towel pretty quick, rather than have the Judge rule that they couldn't prove they owned it therefore they didn't. Hence the extreme secrecy over the settlement ... the Emperor had no clothes ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

nix — Thu, 04 Feb 2021 01:40:41 +0000

Now the unanswerable question, of course: was this incompetence (which I can *easily* see), or malice backfiring (attempts to claim stuff as their own that really wasn't)...

Elastic promises "open"—delivers proprietary

Wol — Thu, 04 Feb 2021 01:23:18 +0000

I should have added this was what killed the SCOG case - it proved that SCOG had no valid claim to any part of Unix before SysV and all they had was the stuff written by Novell and themselves.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Wol — Thu, 04 Feb 2021 01:16:40 +0000

Bear in mind that this is the real BSD licence - as in you must credit Berkeley...

But what happened was that, as part of their claim that Berkeley infringed AT&T copyrights, AT&T claimed ownership of utilities like vi. Berkeley promptly brought evidence that, not only was vi written at Berkeley not AT&T, but that the reason AT&T mistakenly claimed it was that they had deleted all evidence as to who owned the copyright!

That was why they capitulated so quickly, and wanted it all sealed - if they mistakenly claimed stuff that clearly belonged to other people, then they had no way to prove they owned anything, and even worse that lack of proof was down to the fact they themselves had destroyed it.

The settlement should be available on Groklaw somewhere - someone made a Freedom of Information request for it and sent it to PJ. In hindsight everyone was surprised no one had tried that earlier ...

Cheers,
Wol

Elastic promises "open"—delivers proprietary

nix — Thu, 04 Feb 2021 00:41:42 +0000

I must have missed that one. How?! (Was this the advertising clause version, and they didn't attach the attribution that clause requires?)

Elastic promises "open"—delivers proprietary

Wol — Wed, 03 Feb 2021 23:17:26 +0000

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

nix — Wed, 03 Feb 2021 21:46:45 +0000

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

kemitchell — Mon, 01 Feb 2021 19:22:02 +0000

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

jejb — Mon, 01 Feb 2021 18:52:31 +0000

> 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

Wol — Mon, 01 Feb 2021 18:51:28 +0000

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

kemitchell — Mon, 01 Feb 2021 18:04:38 +0000

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

kemitchell — Mon, 01 Feb 2021 18:01:53 +0000

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

Elastic promises "open"—delivers proprietary

jejb — Mon, 01 Feb 2021 16:12:46 +0000

> 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

Wol — Mon, 01 Feb 2021 08:21:44 +0000

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

Wol — Mon, 01 Feb 2021 08:14:41 +0000

> 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

kemitchell — Mon, 01 Feb 2021 02:32:33 +0000

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

kemitchell — Mon, 01 Feb 2021 02:26:30 +0000

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

jejb — Mon, 01 Feb 2021 02:20:41 +0000

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

kemitchell — Mon, 01 Feb 2021 02:11:28 +0000

<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

mjg59 — Mon, 01 Feb 2021 02:05:52 +0000

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

jejb — Mon, 01 Feb 2021 01:53:20 +0000

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

ras — Mon, 01 Feb 2021 01:31:00 +0000

> Derived work (or more commonly "derivative work") is a term of art in copyright law. Judges decide what it is; licenses don't.

I presume that's the correct legal stance. But in my experience, when legal theories clash with reality, it's the legal theories that bend.

The reality in this case is some very prominent open source projects define what they consider a derivative work to be, and it would be a very game lawyer who took that on. For example, the prime distinction between the GPL / LGPL / AGPL is their definition of what a derivative work is. The kernel has also drawn their own line in the sand on the subject.

Maybe your answer is "they can weaken the definition of derivative work (ie, define less things to be derived), but not strengthen it beyond what it means in law". If so "Judges decide what it is; licenses don't" isn't the clearest way of saying that. Licenses have been defining it for years now, and from what I can tell doing so very successfully.

The interesting thing for me is how they draw this line. They don't use legal terms. They use terms that to us are clear and well defined, "linking", "header files", "kernel API" and so on, thus providing certainty about what is covered and what isn't. It proves you don't need difficult to reason about / need to be decided by a Judge definitions to achieve useful outcomes.

This clause looks to me to fall squarely in the "difficult to reason about / need to be decided by a Judge" definition:

> offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version

Lawyers can have a field day defining what "derives value from" means. Does a backup program derive value from the data it is backing up? Does the kernel derive it's value from the applications it runs?

Elastic promises "open"—delivers proprietary

kemitchell — Mon, 01 Feb 2021 01:29:34 +0000

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

kemitchell — Mon, 01 Feb 2021 01:23:20 +0000

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

kemitchell — Mon, 01 Feb 2021 01:09:08 +0000

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.

Elastic promises "open"—delivers proprietary

jejb — Sun, 31 Jan 2021 23:49:47 +0000

> 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

jejb — Sun, 31 Jan 2021 23:44:51 +0000

> 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

mjg59 — Sun, 31 Jan 2021 23:38:50 +0000

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.

If you won't be bound by your own license, why should we take you seriously?

Wol — Sun, 31 Jan 2021 21:57:35 +0000

> As such, my priority, as a copyleft theorist is to figure out why copyleft is not working to defend software freedom and what we need to do to fix it

I think that's pretty obvious. Certainly in America, it's difficult to enforce. Copyright theft is just accepted as a fact of life.

One only has to look at Reuters - they nicked a newspaper article (where the author had basically licenced it "Creative Commons just attribute me") and when the author complained, they just said "if you kick up a fuss we'll make sure you never publish another article again!"

What you want is the European attitude - copyright theft for gain is a criminal offence in Britain (even if it's not really enforced), and given that Europe tends to emphasise preventing future breaches it shouldn't be too hard - given evidence of previous breaches - to get an injunction requiring importers to certify IN ADVANCE that their gear doesn't breach copyright.

That would pretty much kill the habit of importing something illegal and discontinuing it before you get called on it ...

Cheers,
Wol

If you won't be bound by your own license, why should we take you seriously?

bkuhn — Sun, 31 Jan 2021 21:40:19 +0000

> Would you be willing to address some (perceived or real) loophole in the AGPL ?

I've encouraged anyone who thinks we need to come up with better copyleft to join the copyleft-next project. I am not willing to take seriously companies who don't even bind themselves by copyleft licenses they promulgate when they disingenuously claim, as Elliot of MongoDB did, that they're attempting to make a better copyleft for end-users. Their goal is to push people from copyleft to proprietary licensing. Period.

As a matter of community priority: copyleft violation is widespread and that most devices in the world today (by a count of millions and perhaps billions) do not give users the software freedom that copyleft ensures due to copyleft violations. As such, my priority, as a copyleft theorist is to figure out why copyleft is not working to defend software freedom and what we need to do to fix it. Making a even stronger copyleft than AGPL can't be the right priority in that climate, since even the weaker copylefts, such as plain GPL, are so widely violated.

Elastic promises "open"—delivers proprietary

pizza — Sun, 31 Jan 2021 20:48:49 +0000

That has always "worked" via the honor system.

Elastic promises "open"—delivers proprietary

kemitchell — Sun, 31 Jan 2021 20:26:38 +0000

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

Wol — Sun, 31 Jan 2021 19:23:40 +0000

It's more than enough of a bar to cause big companies severe discomfort - we didn't know it at the time, but the reason AT&T got crucified in court over Unix was they managed to - *seriously* - be in breach of the BSD licence!

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Wol — Sun, 31 Jan 2021 19:14:24 +0000

> In the US at least, this has explicitly not been a copyright violation for about 40 years.

Then how does trial-ware (aka "if you like it pay for it") work? You can freely copy and share it, but in order to actually use it "for real" you're expected to pay for it. The licence is quite clear ...

Cheers,
Wol