Elastic promises "open"—delivers proprietary

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.