Elastic promises "open"—delivers proprietary
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
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
Posted Jan 27, 2021 20:33 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (10 responses)
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.
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.
Posted Jan 27, 2021 22:42 UTC (Wed)
by himi (subscriber, #340)
[Link] (8 responses)
Posted Jan 27, 2021 23:52 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (7 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.
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,
Posted Jan 28, 2021 0:02 UTC (Thu)
by pizza (subscriber, #46)
[Link] (5 responses)
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)
Posted Jan 28, 2021 0:08 UTC (Thu)
by himi (subscriber, #340)
[Link] (2 responses)
Posted Jan 28, 2021 1:53 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
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...)
Posted Jan 28, 2021 23:27 UTC (Thu)
by himi (subscriber, #340)
[Link]
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 . . .
Posted Jan 31, 2021 19:14 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Jan 31, 2021 20:48 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Posted Jan 28, 2021 0:02 UTC (Thu)
by himi (subscriber, #340)
[Link]
Posted Feb 1, 2021 1:31 UTC (Mon)
by ras (subscriber, #33059)
[Link]
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
>
> 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.
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Wol
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Wol
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary
Elastic promises "open"—delivers proprietary