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

Elastic promises "open"—delivers proprietary

Posted Jan 28, 2021 2:20 UTC (Thu) by kemitchell (subscriber, #124442)
In reply to: Elastic promises "open"—delivers proprietary by mjg59
Parent article: Elastic promises "open"—delivers proprietary

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.

to post comments

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.