undefined | Better HN

0 pointstinco2y ago0 comments

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?

0 comments

6 comments · 2 top-level

PeterZaitsev2y ago· 3 in thread

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

tincoOP2y ago

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.

compsciphd2y ago

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.

maffulli2y ago

> 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.

maffulli2y ago· 1 in thread

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.

tincoOP2y ago

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.

j / k navigate · click thread line to collapse

0 comments

6 comments · 2 top-level

PeterZaitsev2y ago· 3 in thread

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

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

tincoOP2y ago

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.

compsciphd2y ago

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

maffulli2y ago

> 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.

maffulli2y ago· 1 in thread

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.

tincoOP2y ago

j / k navigate · click thread line to collapse