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

Elastic promises "open"—delivers proprietary

Posted Jan 27, 2021 19:59 UTC (Wed) by kemitchell (subscriber, #124442)
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.

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.

to post comments

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