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

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 20:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Elastic promises "open"—delivers proprietary by NYKevin
Parent article: Elastic promises "open"—delivers proprietary

> This is disingenuous. AGPL does *not* reach through network connections in the same way that GPL reaches through linking.
AGPL is pretty vague on that (it actually says nothing about what exactly is a derived work). Even basic questions are not answered. E.g. if you provide a web mail service and want to use an AGPL-ed PDF renderer in an iframe, then will AGPL propagate to all of the software?

SSPL on the other hand does limit it to:
> 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

to post comments

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 20:33 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (10 responses)

> (it actually says nothing about what exactly is a derived work)

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

The FSF has taken the position that dynamic linking creates a derivative work; they may even be right about that. But legally, it would be up to a judge to decide on a case-by-case basis, or up to a national legislature to codify explicitly. If dynamic linking does not create a derivative work, then there's no substantive difference between the GPL and the LGPL, never mind the AGPL.

> if you provide a web mail service and want to use an AGPL-ed PDF renderer in an iframe, then will AGPL propagate to all of the software?

There is nothing in AGPL which suggests that the answer should be "yes." You would not need to modify the renderer in order to do this, and the extra AGPL obligations (in section 13) attach at time of modification. If the software is unmodified, the AGPL is materially identical to the GPL.

Even if the software *is* modified, however, the normal GPL limitations in section 0 still apply, particularly this:

> To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
>
> To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

In other words, the AGPL does not have a different "test" for what counts as "modification" than the GPL; they both use exactly the same set of legal definitions, right down to limiting "conveying" to *not* include "mere interaction [...] through a computer network." The AGPL is almost entirely identical to the GPL, in fact. Section 13 is pretty much the only difference, so if your hypothetical does not implicate section 13, then you can analyze most of the legal consequences in the same way you would analyze the GPL. If section 13 is implicated, it still has to be analyzed in the context of the rest of the GPL, because that's what the AGPL is - the GPL with an extra section.

In short, the AGPL probably doesn't cover your hypothetical.

> SSPL on the other hand does limit it

"It" in this context does not refer to "derivative work." It refers to "making the functionality of the Program or modified version available to third parties as a service," which is a contractual term, not a copyright term. You can define and limit contractual terms in whatever way you like.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 22:42 UTC (Wed) by himi (subscriber, #340) [Link] (8 responses)

I'm actually curious about exactly how the SSPL can be in any way enforceable given the constraints imposed by copyright law (particularly the fact that it only "infects" through copying or derivation, and simply communicating with a service seems like a pretty solid boundary). Wouldn't any unenforceable clauses in the license simply be made null, and only the enforceable clauses would remain? Leaving the whole thing potentially even more open than a plain GPL license would . . .

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 23:52 UTC (Wed) by Wol (subscriber, #4433) [Link] (7 responses)

> I'm actually curious about exactly how the SSPL can be in any way enforceable given the constraints imposed by copyright law (particularly the fact that it only "infects" through copying or derivation, and simply communicating with a service seems like a pretty solid boundary)

You are missing a very crucial point, which is that in order to run software YOU HAVE TO COPY IT. At which point, COPYRIGHT BITES.

The GPL quite explicitly grants unrestricted rights to copy and use. Because they are needed!

So if you want to put SSPL software onto your server to provide a service, you need to copy it. And if the SSPL does not give you unconditional rights to copy and run, then you have to agree to the licence.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:02 UTC (Thu) by pizza (subscriber, #46) [Link] (5 responses)

> You are missing a very crucial point, which is that in order to run software YOU HAVE TO COPY IT. At which point, COPYRIGHT BITES.

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

If you legally acquired a copy of the software (ie the person who gave it to you did so legally) then you are free to *use* it to your heart's content, at least as far as copyright is concerned. Copyright can only restrict the creation of further copies or derivative works.

(This is why the AGPL's terms only kick in if the software is modified)

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:08 UTC (Thu) by himi (subscriber, #340) [Link] (2 responses)

I thought this was still an issue at least up to the DMCA and some way beyond it - I recall it being a significant matter for discussion during the various flame wars that happened when the idea of "open source" as a distinct concept was being developed, as well as later on during the discussions around tivoisation which happened after the DMCA came into effect. Do you know what the case law or legislation was that explicitly carved out that exception?

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 1:53 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> Do you know what the case law or legislation was that explicitly carved out that exception?

https://itlaw.wikia.org/wiki/Computer_Software_Copyright_...

(I'm sure there's plenty of nuance involved in the case law that followed, and the DMCA's anti-cirvumvention stuff threw a big monkey wrench into everything, but the original intent does seem clear...)

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 23:27 UTC (Thu) by himi (subscriber, #340) [Link]

Okay, reading through other parts of this discussion I've realised what my niggling issue/misunderstanding is here: if the /use/ of the code doesn't provide an avenue for copyright law to bite, how does a person running a service using this SSPL licensed code, assuming they acquired it entirely legally (i.e. they received all the necessary source and so forth), become in any way bound by the terms of the license? They're providing a service, not distributing the code, so how can they end up bound by the terms of a copyright license?

Unless there's some other kind of contract involved, in which case how would that kind of contract obligation be created?

I'm sorry to be asking what are probably dumb questions here, but this really is something that's hard to understand just by trying to read up on it in your spare time . . .

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 19:14 UTC (Sun) by Wol (subscriber, #4433) [Link] (1 responses)

> 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

Elastic promises "open"—delivers proprietary

Posted Jan 31, 2021 20:48 UTC (Sun) by pizza (subscriber, #46) [Link]

That has always "worked" via the honor system.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:02 UTC (Thu) by himi (subscriber, #340) [Link]

Okay, yeah, you're right. This isn't any kind of "infection" of other code by SSPL covered code, it's an outright "you can only use this code if..." which means there are no constraints beyond whatever limitations are imposed on contracts or similar.

Elastic promises "open"—delivers proprietary

Posted Feb 1, 2021 1:31 UTC (Mon) by ras (subscriber, #33059) [Link]

> 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?