One could argue that the SSPL brings justice to open-source, as cloud providers will not be able to monetize a project without giving anything back. SSPL forces them to pay a license fee.
On the other hand, this also creates a vendor lock-in situation for the user, simply because not all service providers will be able to negotiate a deal with the developer of the SSPL-licensed product. This limits choice, limits competition between providers, among other things.
This license fee may also be increased at the sole discretion of the developer, and the increased fee will be paid by the user in the end. This all doesn't sound open-source to me at all.
[1]: https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
If you want to offer MongoDB as a service, you can still do so free of charge, as long as the service infrastructure is also made openly available, right? And if you don’t want to make the source available, you can purchase a license and do so, right?
Furthermore, if you’re using MongoDB, be it self-hosted, with a vendor, or even some proprietary database that implements the wire protocol for compatibility, you’re likely using MongoDB-developed clients/drivers, which are Apache 2.0 (“OSI-approved open source”).
So it seems like the only way to be locked into a vendor is if you’re using MongoDB drivers to connect with a 3rd party database that doesn’t fully implement all functionality of MongoDB in a compatible way… Right?
I could be wrong, but as someone who contributed to MongoDB as an open source project, and was later hired by MongoDB based on said contributions, it kinda hurts to see the OSI’s “MongoDB isn’t open source anymore” campaign work so well.
That said, I sincerely wish the team behind this project all the best!
My complaints aren’t against anyone in the open source communities I’ve known and loved. Just this self-important legal organization that acts like it controls (and even gets to define) open source software.
P.S. I left MongoDB in 2015 due to a neurological disability, but it was one of the highlights of my career, with so many kind and brilliant people. But it’s also been a while, and my brain doesn’t work so well these days, so please correct me if I got anything wrong!
The license text is worded as such that it is basically impossible to comply with.
> OSI’s “MongoDB isn’t open source anymore” campaign work so well.
It is hardly OSIs campaign. Pretty much all major organizations involved in FOSS licensing have rejected sspl. For example this is Fedoras stance:
> Fedora considers the Server Side Public License (v1) to be a Non-Free license. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk.
It's not. It's source available, and that's still proprietary.
The reason why the SSPL is not Open Source is pretty simple: it doesn't convey the four essential freedoms of free software [1]. That's it, there is essentially no more to it: it imposes usage restrictions, and that's orthogonality against the spirit.
Whether it is "except this or that" or "AGPLv3 but with this additional clause" is irrelevant: even the tiniest change can cause significant differences, and this is the case: it removes the freedom to run the program as you want, as it imposes restrictions to some use cases. And these restrictions go beyond the realm of the software itself.
In contrast, Open Source copyleft software, like AGPLv3, never go beyond the software itself. It provides guarantees that modified versions of it also remain available for users of modified software (forward carrying guarantees) but do not add a requirement to also provide under the same license other unrelated software (which is essentially a nice way of saying "simply don't do this", turning de facto into a usage restriction).
[1]: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms
MongoDB Specifically switches from Open Source License to SSPL to create monopoly in DBaaS Space. IT is business decision so lets not pretend here.
If you look at Real Open Source software it is created for cooperation and innovation together, not monopoly.
Also, if you bought something closed-source to sell MongoDB as a service, why isn’t it realistic to buy a license?
Your suggestion of a monopoly in the DBaaS space seems to preclude the existence of other databases… Or am I misunderstanding?
I’m not sure what you mean by “IT is a business decision” — could you elaborate?
-edit- P.S. I’m trying to be supportive here; not trying to take anything away from what you’ve built with FerretDB! Honestly, there’s room for so room for innovation in this domain, and it’s nice to see new projects…
Lets say you are running your infra on any cloud provider. Do you think its realistic to get them to hand out their source code?
In fact, you can build a similar service and offer it within your organization (and subsidiaries), and you still don’t have to release anything. The license only applies to companies like Amazon if they offer MongoDB as their own service (DocumentDB).
I know that’s a bit tangential, but hope that helps a bit?
And OSI thinking they alone get to decide what is and what is not open source is arrogant.
I think that arrogance is when a single vendor tries to single-handedly redefine open-source to fit their business needs better. Not just a license, but the definition itself.
A quote from the MongoDB CEO: "MongoDB was built by MongoDB. There was no prior art. We didn't open source it for help; we open sourced it as a freemium strategy". [1]
Whether the OSI was arrogant or not, I really don't want this person to define opensource.
[1]: https://techmonitor.ai/leadership/strategy/mongodb-ceo-inter...
If it wasn’t for copy-left licenses that forced companies to release code that they used to create their products we wouldn’t have Linux in its current state.
In a world, where many products are cloud based it seems fair and within the current model of open source to force code sharing.
The SSPL license reads:
> […] you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
> “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.
You just can't comply with those terms if you don't have access to the source code of your storage software, for example.
(but I'm not a lawyer, of course)
> And OSI thinking they alone get to decide what is and what is not open source is arrogant.
OSI invented the term “open source”: https://web.archive.org/web/20021001164015/http://www.openso... I think they are in a position to define what it means.
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...
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!
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.
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...
All new licenses come with risk since the decisions can only be made via court decisions.
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...
This is not true. People who are saying this would have said this about GPL when it first came out.
This was benefit for users but obviously not something classical corporaton would enjoy
> “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.
Basically it is saying you need to release the source of every tiny bit in your stack and then some.
If you disagree, could you indicate the relevant text?
Let's say you decided to run MongoDB as a service, and you are fine with releasing Service Source Code under SSPL. The problem is – you can't. You don't own the source code for your NAS and can't relicense it. Nothing in the text says, "relicense all you can, and then you are fine". Clause 13 puts requirements on software that are completely unrelated in terms of copyright.
> I am confused. If you use a custom storage system then you would have the code for it. No?
Nothing in the license text says that the storage system has to be custom.
> The idea you need to release code for the os, file system, network routers, etc is absurd.
I agree with you that this is absurd. But that's what the license text says.
I suggest you read section 13, not MongoDB's FAQs or other explanations of how it works. The actual legal tech is very different from what you seem to think it is.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the… SNIP …programs that you use to make the Program or modified version available as a service…
I’m eliding for clarity, but the NAS doesn’t make the program available as a service. The code that accesses the file system on the NAS to offer your service? Probably need to release code that calls fread/fwrite/NtFileX in your infrastructure code.
I get that it sounds vague and everything, but the FAQ also clarifies none of this applies unless you’re competing and targeting third parties. If you’re one of the few companies who want to do that, your legal team can formalize the line of demarcation.
Apologies, I hate defending the SSPL, but I can’t think of any better way to stop the monopolistic and EEE practices against open source projects. If anyone has a better solution to protect the freedoms of open-source developers, please, please publish it!
FWIW, just realized it doesn’t even apply if deployed internally (within an organization and/or subsidiaries)…