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

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:14 UTC (Wed) by NYKevin (subscriber, #129325)
In reply to: Elastic promises "open"—delivers proprietary by kemitchell
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. If I stick a reverse proxy in front of an AGPL'd origin server, the reverse proxy is not required to be AGPL. I (probably) still need to offer the origin server's source code to my end users, of course, but that's where the obligation ends.

The OSL 3.0, which you claim to be different, is not:

> 5) External Deployment. The term "External Deployment" means the use, distribution, or communication of the Original Work or Derivative Works in any way such that the Original Work or Derivative Works may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. As an express condition for the grants of license hereunder, You must treat any External Deployment by You of the Original Work or a Derivative Work as a distribution under section 1(c).

There is simply nothing in this language which can be read to extend from the origin server to the reverse proxy. On the other hand, the SSPL not only (probably) extends to the reverse proxy, but expressly includes "without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software." That is an extraordinarily expansive set of demands going up and down the entire software stack. No other purportedly open source license is anything like that. In practice, these requirements are basically impossible to meet unless I own the copyrights to all of those pieces of software, since the vast majority of those products are not available under the SSPL (e.g. I'm not aware of any SSPL-licensed backup software, so either I have to roll my own, or go without backups!).

to post comments

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:59 UTC (Wed) by kemitchell (subscriber, #124442) [Link] (12 responses)

This is disingenuous. AGPL does *not* reach through network connections in the same way that GPL reaches through linking.

How "disingenuous"? Mongo made just this point when proposing SSPL, as primary motivation for new terms.

The GPLs, and by extension AGPLv3, embody implementation choices and underlying assumptions that in retrospect arguably limit their copyleft to some means of software combination, and not others. A lot of us are building applications these days by composing services "linked" by HTTP API calls, often with each service in its own OS container. AGPL acknowledges services as a means of software delivery, but not as a means of software composition. It doesn't reflect any awareness that was possible.

Have a closer look at OSL. It shared the "solve the Google problem" goal of AGPL, but took a clean-slate approach to design and drafting of legal terms. As a start, OSL copyleft triggers when you offer a network service, whether you "modify" or not. It doesn't bend over backward to avoid saying "if you use this software to provide a network service, then..." as AGPL did, for various doctrinal reasons peculiar to FSF. OSL also defines the reach of copyleft more directly in terms of copyright "derivative works", without extra GPL-style verbiage like the definition of "Corresponding Source". Which is to my point about the breadth you see, in licenses like SSPL, versus the breadth that's hidden behind legal terms, like "derivative work". Upshot: There's nothing essential about the quirkly limitations AGPL self-imposed, intentionally or unintentionally.

Every new strong copyleft license has addressed new means of software combination or software delivery. Every new strong copyleft license has faced "slippery slope" arguments about the scope of what must be shared back. That's what it takes to remain "strong", to apply in the circumstances that matter for the industry and end users.

Sometimes projects have gone out of their way to publish a free exception to allow closed use in cases where the license would arguably require release. For examples: the kernel user-space exception, Mongo's AGPL application exception. Those exceptions implicitly acknowledge the broad reach of copyleft as written, and, once upon a time, OSI and FSF approved.

I'm personally not terribly impressed with how section 13 of SSPL turned out, either. It could be much improved. Mongo acknowledged this, floating a revision of SSPL adding more clarity and flexibility around existing open source in the stack under different licenses, akin to the "System Libraries" exception to "Corresponding Source" under *GPLv3. But by the time they did, "review" had devolved to "pillory" so far that they essentially left that olive branch on the table as they made for the door. The process, such as it was, didn't help. It was too caught up in denouncing the license, or rather, denouncing Mongo as a company, to improve it.

The question about a new copyleft license isn't just whether it does something more or something different than older copyleft licenses. If it doesn't, the concern is proliferation—lack of novelty—and you might as well pick the already-approved license.

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 22:11 UTC (Wed) by mjg59 (subscriber, #23239) [Link] (11 responses)

> Every new strong copyleft license has addressed new means of software combination or software delivery. Every new strong copyleft license has faced "slippery slope" arguments about the scope of what must be shared back. That's what it takes to remain "strong", to apply in the circumstances that matter for the industry and end users.

Are there any copyleft licenses that are broadly accepted as free software that go beyond "derived work" when addressing software combination? Section 13 of the SSPL isn't a logical extension of the GPL's requirements in this respect, it's a far greater reach (to the point where it's probably impossible to satisfy under any real world conditions)

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 23:25 UTC (Wed) by kemitchell (subscriber, #124442) [Link] (10 responses)

*GPLv3 are by far the best known licenses that explicitly reach beyond "derivative work". SSPL and other license that reach beyond that have to argue to do so.

I believe those arguments will prove very strong, on the merits. Free software wasn't about accepting copyright concepts as moral truths. Quite the opposite. Copyleft was designed to give the proprietary industry some of their own medicine, and proprietary licenses don't hobble themselves the way some open source license drafters have. Nor were open source or free software principles wedded to specific models of software development or delivery. They were more general than that, even universal. If you used a system, you needed all the source and rights to hack it. No matter what language or means of combination was used to develop it.

The early FSF licenses strained to speak in specific copyright terms because less of copyright law was clear back then, including whether such a license could be enforced as a general matter. That was a long time ago. There's no longer any reason to "implement" the copyleft in self-limiting terms that only clearly apply to copying and pasting or linking compiled software.

Please don't let any of this lull you into thinking lawyers know just what "derivative work" means in software. There's a statutory definition in 17 U.S.C. 101:

A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.

But beyond that, it's case law—court decisions. Which there isn't a ton of in software. If we get more soon, in the form of an Oracle v. Google decision that endorsed copyright protection for APIs, "derivative work" is going to expand, to clearly include derivatives of works that are APIs. It's a very dynamic situation.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 0:38 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (9 responses)

> *GPLv3 are by far the best known licenses that explicitly reach beyond "derivative work"

In terms of the Installation Information requirement? I accept that there's an obligation placed on you that stretches to things other than the covered work itself, but there's no requirement that those also be provided under the terms of the GPL - it's intended to ensure that a user has the practical freedom to modify the work. If we extend that to the SSPL situation, it feels like we'd end up with a section 13 that required that it be possible for the user to be able to stand up a modified version of the covered work on the same infrastructure running the service - so, we could imagine (say) Amazon running an Elasticsearch instance inside a container and communicating with other Amazon components, and the license requiring Amazon to permit users to swap out that container with a modified one and run a competing service.

What the SSPL actually requires, though, is more akin to a GPL variant that requires *all* code in a User Product be provided under the terms of that license if a single component is under that license. This isn't just a difference of degree, it's a difference of kind - the requirement is no longer about enabling the user to have practical exercise of their freedoms, it's about ensuring that the user has the same freedoms for every component in the system.

And ensuring that users have additional freedoms is good! But that doesn't seem to be the goal of the SSPL - it's described in terms of requiring that beneficiaries of the freedoms granted be required to contribute back to the wider community, not in terms of ensuring that users of a service have a practical mechanism to benefit from the four freedoms.

So what is section 13 supposed to achieve? The final sentence implies that the intent is to require that the service vendor provide everything required to run a local instance. In Amazon's case that's presumably not just the code running on the machine providing the service, it's also every other component the service relies on - so Amazon would have to hand over the code to Route 53, S3, and a whole lot of other components. And in order to actually bring up the local instance of the service, I need to bootstrap all of that infrastructure locally. This is, to put it mildly, impractical. Regardless of any nominal freedoms embodied by the license, I have no way to make a modification to the original work and deploy it in an equivalent way. Instead I need to rebuild Amazon's infrastructure first. And that's ignoring the fact that Amazon can't do this anyway, given that (for instance) they'd somehow need to relicense Linux under the SSPL first.

So, as written, section 13 doesn't feel like something that's intended to grant practical user freedoms. Instead it feels like it's deliberately written to be impossible to meet, thus coercing anyone using the covered code to provide a service to pay for a proprietary license instead. And in that respect it definitely meets the stated goal - users of the code have to pay for the privilege. But this doesn't result in users gaining more freedoms. Instead, I'm now forbidden by the license from running a small public Elasticsearch service on top of Linux.

I think the problems the SSPL aims to solve are real and we do need to provide solutions to them. But I don't think the SSPL is a sincere attempt to grant freedoms to users, and as a result I don't think it counts as open source.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 1:38 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (7 responses)

Howdy, Matthew. Hope you're doing alright.

The thing you must provide and license under *GPLv3 is "Corresponding Source". Here's the relevant part of the definition:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it 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. ...

The requirements to convey and license "Corresponding Source" are in section 6 and section 13 of AGPLv3.

*GPLv3 "invokes" the copyright concept of "derivative work" elsewhere, in the definition of "modify":

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

With legal X-ray glasses on: The phrase "requiring copyright permission" will catch "preparing derivative works" of the software under United States Code title 17, section 106, the list of exclusive rights of copyright holders in the Copyright Act. The phrase "based on" appears in that section, as well as the Copyright Act definition of "derivative work".

For what it's worth, I think we agree on implementation. SSPL, especially section 13 of SSPLv1, could be a lot better written. The v2 improvements, which Mongo proposed before fleeing the OSI scene, were an improvement, though still not great. Personally, I think forking AGPLv3 probably doomed them to confusion from the start. I suspect the lawyer who did the forking knew that, but could not convince their client. Having seen the difference between OSI process as perceived and OSI practice as practiced come crashing right down on their heads, it was just another bit of feedback they were done hearing, maybe even came to suspect as Trojan Horse.

I'm not sure whether we agree that the intended functionality of SSPL would make an open license. I certainly do. Partly out of frustration with the decision to start from AGPL, and then out of further frustration with the "review" process, which achieved no improvement to the v1 and couldn't be expected to, I drafted and shopped around a license we eventually called "Round Robin". More in an effort to depersonalize the proposal and the issues than anything else.

I don't know how to allocate responsibility for the total unproductive waste that was the OSI thread on SSPL. I see with just two eyes. Mongo definitely contributed, but they were hardly the only one. More naive than evil, methinks. In any event, I'm disappointed to see arguments that judge Mongo (or Elastic) rather than the terms. MIT and BSD certainly weren't drafted with "software freedom" in mind. It was at best one line of input to MPLv2 and EPL. But in the end, licenses are just tools. Especially when others not the drafter start using them.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 1:59 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

> I'm not sure whether we agree that the intended functionality of SSPL would make an open license.

I think that depends on what the intended functionality of SSPL actually is.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 2:20 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (2 responses)

Completely fair.

The tragedy here is the communication breakdown. The sides have squared off and don't talk in earnest. When they happen to catch a word, they assume hostility or duplicity. Increasingly, they're right.

I for one lay that first at OSI's feet. They tolerated, even welcomed, ad hominem attacks on the company, rather than holding discussion to the license. Whatever reason someone had to oppose either company or license---not good for their business, not drafted through their process, not motivated by their politics---they were free to wreck the assumption of good faith, backchannel as well as publicly.

It's not actually fair to say the license review process failed. It was never allowed to start earnest. Filibustered or shouted down, not really debated. But some can chalk it up as a "win", because their interest lies in the outcome, and not the process.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 2:59 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (1 responses)

It's not hard to see why people would conclude that section 13 in its original form was effectively impossible to comply with, and that's effectively a pretty obvious violation of the fields of endeavour criterion. The modified version is much better in that respect, but as you say I think people had already made up their minds at that point. But I think it's still fair to question the motivation - quoting from the original rationale:

"Many open source developers are struggling with a similar reality, and some of our competitors have moved to proprietary licensing models. The alternative, to be blunt, is for us to be that last standing unpaid open source database developer for cloud providers, who sell access to our software for significant fees, but may not adequately contribute back to our community."

Even in version 2, section 13 would appear to require Amazon to hand over a significant amount of code that wouldn't have benefited the MongoDB community - the greatest beneficiaries would be other large cloud providers. Again, the easy way to go from the rationale to the license terms is to assume that most vendors will find the terms overly onerous and will pay for an alternative license.

So, what /is/ the intended functionality of the SSPL? Is it intended to increase the amount of free software in the world, or is it intended to support the business model of the authors?

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 3:58 UTC (Thu) by kemitchell (subscriber, #124442) [Link]

I don't doubt the honesty of your reading at all. I do worry about standards. We may be more familiar with seeing "Corresponding Source" in GPLv3 or "derivative work" in a bunch of licenses. But when someone comes to me for legal advice about what, exactly, they have to release, I've rarely got a 100% answer. Usually we can find some approach that works, mixing good faith, a willingness to communicate, and a little conservatism (in favor of release). But line drawing can be hard even under licenses that took pains to make it easier, like MPLv2. Implementation-wise, our best tools look a lot more like SSPL, which used industry terms for what has to be shared, rather than more copyright law esoterica.

I also see—not speaking of your comments here—a willingness to hide behind the "impracticality" of compliance. In my mind, the fact there isn't a world-famous, pure-open-source cloud provider yet isn't SSPL's problem. It's a movement problem, and something we ought to be agitating for. Neither is it relevant that a particular cloud vendor won't share such-and-such code. That's taking the proprietary part of their business model as granted, instead of a call for advocacy. To my mind, the whole concern is whether a developer or company fully willing to share their work as required can feel confident in compliance. The readings that involve SSPL'ing all the firmware blobs for your rack server strike me as motivated stretches to failure.

I was glad to see that quote from Mongo's submission statement again. It's important. SSPL wasn't Commons Clause. It was an attempt to get some of the effect of Commons Clause by using the if-then of copyleft, and conceding the maybe-someone-will of copyleft, rather than the hard "no" so common in proprietary licensing.

I'm guessing that sounds like a big admission. I do suspect the primary motivation for SSPL was just what they said: defense against Amazon. But if the people involved didn't gain meaning in work from broader movement principles, I don't think they would have tried to address their goal under open source limitations. It's so much easier to draft and administer a flat restriction, as in Commons Clause. And Mongo had a ton more leverage than the startups who announced Commons Clause to do it.

In short, I don't think the motivation question is either-or. It should be both-and. The hope for free software in business was that advancing "freedom" could also be good for business. And in fact we've repeatedly seen commercial firms carrying the torch of the latest, strongest copyleft license. MySQL and Sleepycat in the early days. MongoDB for AGPL, which was actually written for Affero, another company. There have been some activists licenses that really only activists used, and some upstart company licenses that really only the companies themselves used. But the heydays, as I see them, were all periods when activists and upstart companies backed each other up. The coalition on the permissive side—anti-IP activists and companies who like free stuff—hasn't wavered. Plenty of permissive licenses have been drafted by corporate lawyers with no thought to end-user service or software-freedom ideology.

A small nit on dual licensing: Mongo continues to tell folks that SSPL doesn't require sharing applications that use Mongo for a database. Just offerings that provide Mongo as a service. They did the same for AGPL before that. It's analogous to the user-space exception to GPLv2 from the kernel. I don't know the terms of deals they've done with cloud providers. But looking at their application-developer offerings, it's all hosting and open core. I don't think they'd call themselves a dual licensing company.

I've really appreciated your messages. Thanks.

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 16:25 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> The thing you must provide and license under *GPLv3 is "Corresponding Source". Here's the relevant part of the definition:

Picking on you because you admit to being a lawyer :-)

See my other post, but you wrote "provide AND LICENSE". Delete the words "and license" because YOU DO NOT HAVE THE RIGHT TO DO SO!!!

ABSOLUTELY NO Open or Free licence I am aware of gives you the right to re-licence somebody else's code.

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 16:59 UTC (Thu) by kemitchell (subscriber, #124442) [Link] (1 responses)

<p>GPLv3, section 5, subsection c:</p>
<blockquote><p>You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.</p></blockquote>

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 20:24 UTC (Thu) by Wol (subscriber, #4433) [Link]

"Entire Work" and "Corresponding Source" are two different things.

If part of the "Entire Work" is derivative of GPL, then, as a *single derivative item*, it can be licenced under the GPL.

But if the "Corresponding Source" contains large chunks of my MIT-licenced work, you can NOT licence the corresponding source as GPL because I didn't give you permission to relicence my work. What you CAN do is distribute the entire corresponding source AS IF it was GPL.

Note that the terms "Entire Work" and "Corresponding Source" imply that the two are completely separate items (linked by the fact that if you pass the "corresponding source" through a compiler/linker, you get the "entire work" as said separate item).

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 16:21 UTC (Thu) by Wol (subscriber, #4433) [Link]

> What the SSPL actually requires, though, is more akin to a GPL variant that requires *all* code in a User Product be provided under the terms of that license if a single component is under that license. This isn't just a difference of degree, it's a difference of kind - the requirement is no longer about enabling the user to have practical exercise of their freedoms, it's about ensuring that the user has the same freedoms for every component in the system.

Snag is, any licence that requires that IS NOT OPEN SOURCE. In fact, it's probably not legal. This is what bugs me about many many many discussions of copyright.

What it should have said is "is more akin to a GPL variant that requires *all* code in a User Product be provided AS IF under the terms of that license if a single component is under that license." - because that is actually the magic of the GPL.

Let's say I write some nifty code and release it as MIT. You then include it in your niftier GPL version. The GPL *does not* require you to relicence my code to GPL because you CAN NOT. What the GPL requires is a guarantee that - by complying with the terms of the GPL - you are also complying with the terms of the MIT licence that I applied to my oode. So when the GPL is applied to collaborative code it is NOT a guarantee that all the code is GPL, but it is a guarantee that if you comply with GPL then you are also complying with all the other myriad licences that may apply.

(So actually, if you really meant what you wrote, that's another nail in the coffin of the SSPL, because it's trying to enforce the impossible ...)

Cheers,
Wol

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 20:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> 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

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?