Thank you, and it's great that it was recognised a structural change was needed inside and that they attracted you to help implement that. I understand there's deep and long threads on the mailing list, and that there are great flaws with the SSPL.

That the communication with MongoDB crashed and left a sour after taste I can imagine. But the fact now is that there's a deeply flawed SSPL out there, OSI's only real public statement is very dismissive of it. It does not address at all the concerns of Elastic or MongoDB, painting them as some sort of bad guys, when in fact their products have always been open source, even when they were so valuable they really didn't need to be.

And the companies that drove them away from what OSI considers open source, are OSI's two biggest sponsors! Two sponsors it is worth mentioning, who built their products entirely as proprietary closed software, on top of open source software.

So now, wether they meant to or not, OSI has profiled themselves as defenders of proprietary platforms, making no effort to acknowledge the plight of open source companies, and lost credibility to such a degree that now again one the great open source companies has dismissed their approval and went for an unapproved license.

If the OSI was really serious about the "greater good", they would have worked with the FSF and helped MongoDB, Elastic and Redislabs defend against proprietary platform companies such as AWS and Google with an AGPLv4 that has the provisions the SSPL introduced without causing the concerns other people raised in this thread with regard to (possibly intentional?) vagueness around what does and does not need to be open sourced.

If that had happened, then maybe today Redislabs would have announced their switch to an OSI approved open source license, and the OSI would have retained its legitimacy and reputation. How many great budding open source/open core projects have been inspired by the success of Redis, MongoDB and Elastic, that now will consider the same path as these companies, or worse, that of Hashicorp?

I don't accept that this is OSI's fault thought: It takes two to tango. The OSI has been thinking about a more appropriate format to address the issues of copyleft in the cloud world. I recognize that the problem exists, I wrote about it here: https://opensource.net/lost-decade-crucial-lessons-for-ai/

Frankly speaking, I would love to see also a detailed criticism of the AGPLv3. I would love to have a better understanding of why the SSPL was deemed necessary and what needs the AGPLv3 fails to satisfy... So far, the only explanations I've heard are superficial at best.

You have to also realize that most of these companies are not interested in copyleft or in the values of Open Source to empower users. They're following a very well known path, one that Phipps calls the rights ratchet model. Call it the SugarCRM model, if you prefer: it's a very very predictable pattern, from Open Source to proprietary in about 10 years https://meshedinsights.com/2021/02/02/rights-ratchet/

These are complex matters though and I'm convinced that they cannot be eviscerated properly on a social media, or only on an online forum. We need better ways.

You're right, I don't want to imply it's OSI's fault at all. There is an incentive from the ex-opensource companies to move on from their permissive licenses to something else. That movement is entirely separate from OSI, the best OSI can do is entice and encourage project to go or stay open source. You can take a horse to water, but in the end you can't make it drink.

I agree that the companies are not really interested in copyleft. They built a business on open source, and as they gain popularity the edge they have in competition by virtue of being the original authors of the project is eclipsed by the resources and marketing power of platform operators. They turn to copyleft to ensure the platform operators can not use their superior resources to embrace, extend and extinguish their product. They use copyleft to even the playing field, and maintain their profit margin.

And yeah there's the ratchet. I think it's in the open source community's interest to try keep projects inside the "open" part of the ratchet cycle. I imagine that if there was an AGPLv4 that had more of the SSPL style provisions it could've kept Redislabs inside the "open" part of the ratchet for another 5 years.

With regards to a detailed criticism of the AGPLv3, the SSPL is a straight fork with a small diff, which basically amounts to rewriting section 13. I feel it is really clear what the intended effect of the changes is, what do you think the OSI could learn from a more detailed criticism? The goal is that platform companies can no longer use proprietary software to operate their product. That might be superficial, but I just don't see a reason why it would have to go deeper than that.

What I would rather see from OSI is defining Source Available licenses better.

MongoDB, Elastic, Now Redis do not really provide the practical freedoms one comes to expect from Open Source software - it is clearly anti competitive by design which is bad for the use who will suffer bad quality and inflated prices as you always do when monopoly is created.

Having said that Source Available Licenses are better for end user in many circumstances than old fashioned Proprietary licenses and spliting the world in black and white does not help

I'm not familiar with the Elastic ecosystem, but both MongoDB and Redis have a great plenty of competitors, many of which implement the same wire protocols even, that don't make use of their license at all. So I don't think symmetric competition is affected or even a concern of these companies. Symmetric competition still drives them to improve quality and pressure prices.

It's the asymmetric competition from the platforms that's siphoning resources from these companies that could have been spent on improving the core product.

I don't understand your point with regards to Source Available licenses. Sure, source available is beneficial to the end user, but what does that have to do with open source licenses and the OSI? Source available licenses are simply irrelevant. If source available licenses need representation there should be a new organisation formed for them, no need to involve the OSI. You could call it the Source Available Initiative.

The SSPL is more than just source available. Except for the anti-competitive poison pill in it, its effectively the same as rights granted under the GPL. It's just taking the GPL viral nature to its ultimate extent.

As a simple thought experiment outside the cloud space (or in the pre cloud times) on how the GPL is just as "anti-competitive"

I can release code as GPL. Lets assume either I am the only contributor to this code or I have a CLA allowing me extra rights to the code. In that case, only I have the right to use that GPLd code in a closed source product. That's fundamentally not any more "anti-competitive" or "discriminatory" than the SSPL. Just like the GPL would have allow you to use my code in your commercial product shipped to customers, as long as you GPLd the entire code base (which many might find untenable), so to the SSPL allows you to use a "service" oriented code base, as long as you open source the entire service structure that delivers your version of the service to the end user.

As I wrote above, its mostly a question on values and how one emotionally reacts to those values than simple logic. As the arguments made against the SSPL (or at least a theoretically more perfect SSPL type license, as the emotionally arguments against the SSPL have created an environment where there has been no desire to improve it) really apply just as equally to the GPL.

> What I would rather see from OSI is defining Source Available licenses better.

Let's have a coffee and you can explain to me why you think this would be useful. I'll email you.

To quote wikipedia on the SSPL

Certification with OSI

"In 2018, MongoDB submitted the license to the Open Source Initiative (OSI) for approval. The company withdrew its submission in 2019.[19][20] In January 2021, following the re-licensing move by Elastic, OSI released a statement declaring that the SSPL does not comply with its Open Source Definition because it discriminates against specific fields of endeavor,[which?] describing it as a "fauxpen" source license.[7]"

wikipedia links to https://opensource.org/blog/the-sspl-is-not-an-open-source-l...

So it would seem your take is not quite accurate. It's not simply that it was withdrawn, the OSI board of directors has made public statements.

I'd note that the argument made above "discriminating against specific fields of endeavor" is not fundamentally different than other viral copyleft licenses.

While it has a big poison pill, the whole point of viral copyleft statements is about having a poison pill. The GPL arguably discriminates against fields of endeavor (i.e. closed source code, actually preventing it). The SSPL discriminates against cloud service providers by having a poison pill, which in theory, actually discriminates less, as that field is allowed to use it, just the requirements to use it might be to onerous to be reasonable. But there should be no logical difference if its just about "discriminating against specific fields of endeavor".

i.e. it comes down to a value/emotional statement vs a pure logic statement. The value is that cloud providers need to be allowed to use the code without severe restriction, while its ok to prevent closed source products from using the code.

It's fine for the OSI to make decisions that are not purely logical, but are simply about trying to protect the values that they want to push, but they should also be honest about it.

Does this also extend to the BUSL?

I don't think anybody would argue that the BUSL is an open source license. OSI has investigated and released a report last year about the business practices similar to what the BUSL uses: https://opensource.org/delayed-open-source-publication