[vrtx0]

No, the term “open source” was in use before long before the OSI, and it was in popular/hacker culture in the 1980s. UNIVAC used it in for a major system in the 1950s. [1] I used it in 1993 (I wrote a small BBS).

The OSI looks and sounds like an authority on open source software, but their entire strategy is legal, political and quasi-philosophical. I get how easy it is to be mislead by them though — they’re good at spinning things and rewriting history.

https://en.m.wikipedia.org/wiki/History_of_free_and_open-sou...

[PeterZaitsev]

There are 3 "competing" Open Source and Free Software definitions - from OSI, Free Software Foundation and Debian. MongoDB does not match any of them and most importantly does not match the spirit of Open Source Software Movement.

[vrtx0]

I could name more, but let me clarify something. I’m not a fan of the SSPL, but I get why it was necessary.

It was rough seeing huge cloud providers profit off open source projects without giving anything back. When they offered competing hosting services with no value added (well, past “integrated billing”), no contributions or innovation, and drove their new customers to the documentation and libraries of the companies backing these projects, they crossed a huge line.

And it’s not just MongoDB. Or Elastic. Just look at all the “services” AWS offers, and note how many AWS actually invented or even contributed to…

Monopolistic practices forced a lot of companies to either shut down, or find a way to survive. I’m glad MongoDB decided to use the SSPL instead of shut down like so many others. I’m glad they’ve continued to thrive.

Changing to the SSPL isn’t ideal, but it only impacts people who want to sell hosted versions of the software (not users, self-hosted or otherwise). For those infinitesimal few selling hosted versions of the software, it doesn’t even stop them from doing what they want — it just stopped the monopolies from destroying something a lot of people dedicated a lot of effort to... That seems like a pretty amazing feat to me, given the reality...

I wish the OSI wasn’t so successful painting users of the SSPL as somehow betraying the open source community. And I wish the SSPL wasn’t necessary. But until there a better option, I’m ok with the SSPL…

Again, I say this with all due respect, and this is just my opinion. Corrections and new perspectives welcome!

[PeterZaitsev]

Well, In my opinion this is exactly how Open Source is suppose to work - you get benefit of collaboration on writing the code and promoting your software by broad community, you give more value to your customers because they have a choice of vendors rather than single vendor lockin but also as you give up on having monopoly it is well possible someone else will be making more money than you on your product.

You mention Elastic - do not forget it was built on top of Lucene, capturing most of the value in that project.

It DOES very much impact users because users increasingly want DBaaS experience and if the only one you can get is through MongoDB or MongoDB authorized partnershp it is really no different than proprietary software.

In any case I agree for certain users SSPL is just a good as Open Source, same however can be said about Proprietary Software - some who just "buy subscription" do not care.

[that_guy_iain]

Please state in what way they don’t? This is what I’m confused about. Apgl is open source but a sspl isn’t? They seem to be aimed at solving the same thing, which is cloud/server based code modifications.

[peterfarkas]

SSPL goes way beyond AGPL as it contains an additional clause called "Offering the Program as a Service". It is not defined at all what constitutes providing MongoDB as a service. How many layers are needed to abstract MongoDB in a way that it doesn't trigger this clause? There are no answers for that in the SSPL. It comes with an enormous amount of risk compared to AGPL. There is a good article from Dor Laor at ScyllaDB which explains this in detail [1].

Moreover, cloud providers are not limited to AWS, Azure and GCP. Smaller providers whom we talked to are not able to negotiate licensing terms with MongoDB the same way as how AWS could. For this reason, these providers are not able to provide MongoDB as a service. Yes, it's great for MongoDB that they were stopped from providing MongoDB for free, but now they can't provide the service at all. This limits competition and choices, and that is never in the favor of users.

[1]: https://www.scylladb.com/2018/10/22/the-dark-side-of-mongodb...

[that_guy_iain]

AGPL is basically the same thing, except far more reaching. AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels. “Program as a Service” seems a lot more limited in scope.

All new licenses come with risk since the decisions can only be made via court decisions.

[aleksi]

> AGPL, to my understanding, makes it a requirement if you allow people to use the software via network levels.

AGPL requirements do not trigger if you don't modify the source code. The relevant text is in section 13:

> […] if you modify the Program, your modified version must prominently offer all users […]

See also [1], [2], [3].

> “Program as a Service” seems a lot more limited in scope.

AGPL scope:

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

Basically, the software itself and build scripts.

SSPL scope:

> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

As noted in another thread, that's not only beyond the scope of the software itself – it is beyond the scope you _can_ relicense and arguably beyond the scope of the copyright terms themselves.

[1] https://opensource.com/article/17/1/providing-corresponding-...

[2] https://fossa.com/blog/open-source-software-licenses-101-agp...

[3] https://opensource.stackexchange.com/questions/650/do-i-have...

[that_guy_iain]

> As noted in another thread, that's not only beyond the scope of the software itself – it is beyond the scope you _can_ relicense and arguably beyond the scope of the copyright terms themselves.

This is not true. People who are saying this would have said this about GPL when it first came out.

[PeterZaitsev]

Well, AGPL did no allow to create Monopoly in practice - Compose.io, ObjectRocket and others could offer alternatives to MongoDB Atlas without any permission.

This was benefit for users but obviously not something classical corporaton would enjoy

[that_guy_iain]

It was a benefit for classical corporations not users. These companies can still create alternatives. It’s just they’re forced to share how they did it. It’s that forcing of sharing which is at the heart of GPL.