SSPL Is Bad
ssplisbad.com
ssplisbad.com
I think MongoDB and Elastic did not expect that AWS would simply repackage their product and start offering it as a service becoming a competitor. Technically the Apache License that Elasticsearch was using allowed that, but ethics should have prevented it.
AWS could have approached the vendors for an OEM agreement or some sort of partnership which could have resulted in a "win-win" rather than pissing them off, up to the point that they had to come up with the nasty form of block that SSPL is.
People are often complaining that SSPL is created to please investors and bla bla bla, but at the end, even if the software was open source, the company was never supposed to be a no-profit, so I don't understand where the scandal is, and why everyone blames Elastic or MongoDB and nobody blames AWS.
There is no ethics in capitalism, only money at any cost.
Just because you can do something doesn't mean that you should and certainly doesn't mean it is right to do so.
[1] https://en.wikipedia.org/wiki/B_Corporation_(certification)
I think in a few years we'll look back and we'll see a bunch of mostly failing former OSS companies being milked by hedge funds or companies like Oracle, Salesforce, etc. for profit and a lot of thriving open source communities around the only thing that made those companies successful: forks of their software; pre-license change.
I'm well familiar with Opensearch now being the preferred choice over Elasticsearch as I am active doing consulting around both and the overwhelming majority of my clients defaults to Opensearch at this point. I'm neutral about this and still use Elasticsearch myself. But I can see the logic of my clients.
Morals and ethics don't really factor into this. All you need to do is follow the money, users, and developers. It's very predictable what happens: no company has a perpetual license on their loyalty or attention and that's exactly what you throw out of the window with SSPL.
That's interesting feedback, I am using Elasticsearch and was looking into Opensearch as an alternative. What I see from their respective repositories is that Elasticsearch is more actively developed, it receives almot 3x commits in the same amount of time. Plus, as some of my clients want to install on-prem, it's not clear to me if you can get commercial support for on-prem installations.
There are enough companies going down this path that you should be able to get support.
The license conveys the intent of the authors. If the license explicitly allows something like "reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form" then clearly the authors who picked that license wanted people to be able to do those things. If they didn't want that, they'd have picked a different license to begin with. If you don't want companies to take your work and close the source, distributing it only in object form, then don't use a license that indicates you want that to be possible.
Cloud services are harder, since they don't involve distributing copies of the work, so an EULA like the AGPL is needed instead of just a copyright/patent/trademark license. But when they started they didn't pick one of these licenses, they picked a license that clearly indicated intent to allow their work to be closed & sold.
They instead picked one license, then complained when companies did what they intended them to be able to do, and swapped to a different license. This is why people blame MongoDB and nobody blames AWS. It's a "bait and switch" on MongoDB's part, not on AWS's.
Cloud services can also eat the lunch of companies that are using AGPL. AGPL just makes it so that the service's fork of the code is available to the company and the company can incorporate it or part of it if they wish.
But in most cases I don't think it is being able to add proprietary things to their fork is what causes people to pick the service's offering over the company's offering when they decide they need to purchase support. Most will go with the cloud service's offering even if it has no proprietary things added because it is integrated with the other things they are using at the cloud service, and can be added to their existing support plan with that service.
Imagine your child makes lemonade to sell and a friend drops by, they say it's OK for the friend to have some, and then said friend takes a good amount of that lemonade, sets up a stand beside your child's, and sells that lemonade which they just poured into their own container for less, or with cookies made by yet another. Is that OK? How would you feel?
This is what large cloud providers are doing.
If only the license change could be retroactive so said cloud companies had to either go to something totally different or build from scratch with their own hired team, instead of only having to fork from the last version before the change. They still have it really good, and that's why they continue to call for and abuse permissive licenses.
Luckily one can choose not to use SSPL projects just like one can choose not to download freeware closed source software.
The entire site can be refuted with the question: what’s worse, the software not existing at all, or published with an SSPL license?
The author wrongfully believes all SSPL licensed code would be “open source” otherwise. This is incorrect. SSPL is good compared to the default, which is closed source.
Go see all of the Show HN posts. Most not on GitHub are closed source. Better or worse with SSPL?
Worse, far worse. SSPL is viral to everything that is used to offer your service.
"The SSPL is based on the GNU Affero General Public License (AGPL), with a modified Section 13 that requires that those making SSPL-licensed software available to third-parties (modified or not) as part of a "service" must release the source code for the entirety of the service, including without limitation all "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", under the SSPL"
> words need interpretation and both SSPL and AGPL are written vaguely.
Absolutely, but that doesn't mean you should take the risk. They are both crap licenses imho and our lawyers are not allowing either of them inside anything. And I hear that from all big corp peeps I speak to; except the same software with a commercial license (which will happen to many in the Redis case and it happened in the Mongo case; it's a good bat to beat money out of companies).
The point is that 'vague' is a red flag and unless you have a bone to pick, your law dept is not going to allow it which is the intended reaction to sspl by people licensing that way. You offer dual sspl or commercial; sspl will put you in danger, so you just fork over $.
If you're a big corp ponny up the cash for the commercial license.
Where did I say that? I am asking money for the software I make. Of course it's fine. Using SSPL to do it is just not great imho, but it's their right of course.
The SSPL virality clause is a way to scare away free users (Amazon, GCloud, Hetzner, those kinds of companies) from hosting it as a service. Those companies can still pay for the proprietary license, of course.
But is that the only thing it makes impossible? Doesn't it also make it impossible to use the code in your service? And if you can't use the code then how is it open source now?
> how is it open source now
It's really important to realise it's not: https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
> If you make the functionality of the Program or a modified version available to third parties as a service
Which boils down to "if the program is included in your service"
> you must make the Service Source Code available via network download ... “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,
Which boils down to "you must release not only the program but also everything that interacts with it"
So if the Program is a DB or graphics engine, and the service offered is a game for example, there is no trigger. But if the service is just a thin layer, such as maybe a translation layer for a DB or a few bells and whistles to a graphics engine, then it triggers.
> The author wrongfully believes all SSPL licensed code would be “open source” otherwise. This is incorrect. SSPL is good compared to the default, which is closed source.
The other alternative would be not really having enough funding to keep developing the software, especially if a larger org comes along and earns money from it and you get nothing. Surely we know that many open source projects are struggling: https://staltz.com/software-below-the-poverty-line.html
And if you don't think about protecting your code or ideas, things like this will inevitably happen: https://keivan.io/the-day-appget-died/
If someone wants to have AGPL or SSPL for their software, that's okay. If I find myself in circumstances where I can't use their project or code because of this (e.g. closed source project for someone else, where that would be an issue), that's just what I'll have to deal with.
What happens is that VC invests into successful open source community projects and then tightens the license. It's the enclosures all over again.
I don’t know about y'all but I want a healthy mix and I want a path for small companies to compete and grow, so we don’t get another AT&T technology stall. Although you can’t prove what would exist “otherwise”, I strongly suspect we’re already in an era of stifling innovation, especially the kind that has positive externalities, like interop and standardization.
So when you see BSL and friends, put it in this context. They most likely didn’t get it fully right, indeed. But is this because of ill intent? Or is it because it takes a lot of work and luck to strike the right balance?
I don’t know, but I feel strongly that we need solutions that lead to a healthy middle. Just imagine the best-of-worlds outcome, where OSS development is a viable way to make a living. Imagine working with an ecosystem of tools and libraries made by more people who currently don’t have the luxury of spending their spare time volunteering. Licensing is just one tool, but it’s an interesting one because it makes the tech giants uncomfortable. At the very least, it’s worthy of good-faith critique.
A Slightly Less Strict Public License that would enable the developer of SLSPLed programs to accept contributions under the SLSPL without immediately being noncompliant themselves (something the SSPL is unsuited for due to the lack of SSPLed operating systems).
I don't think the requirement to release supporting software as well is a bad idea, but when you make a new viral license, there needs to be some kind of upgrade path for existing open-source software. The AGPL has a special upgrade path from the GPL, and the SLSPL needs an upgrade path from the AGPL, the GPL and other licenses. So allow that supporting software for SLSPLed works is released under any OSI-approved license, not just the SLSPL.
Then when you have a bog-standard Linux server with a mix of software using various licenses and you want to run an SLSPLed program on it, you can just publish the bog-standard software on your server under its existing licenses and you're done.
Which 3 mega-corps do you mean? Apple? Alphabet? Walmart? Your statement is true of virtually any large US company and many others as well. The problem is you won't be able to monetize open source software sufficiently from any of these if you are looking for the 100 to 1 shot that makes the VC funding model work.
Therein lies the answer to your original question. It's time to get back to building open source products incrementally without huge injections of capital. There's plenty of room to build profitable businesses. They just won't make you or somebody's limited partners a billion dollars.
> Use copyleft licenses to ensure companies will give back to the community: "if you modify our code, share it with the community".
It's fine to disagree but at least add something on top of the points in the linked article.
Non-Affero GPL would not prevent a networked services company from keeping modifications proprietary, as there would be no distribution to activate the license.
Use over a network triggering license activation is the reason the Affero version exists.
Amazon doesn't need to modify your software to provide a differentiated offering: they'll build a bunch of platform-specific, closed source, "secret sauce" to scale it on their infrastructure only and sell that.
(And for bonus points: their secret sauce may or may not affect interop, creating an awkward rift in the capabilities between their managed offering of your software.)
https://en.wikipedia.org/wiki/Focal_point_(game_theory)
No, we shouldn't. There is value in agreeing on definitions, and knowing a common set of rights you have with all Open Source licenses.
Is this right? I may have an overly good faith interpretation of the SSPL, but the word 'directly' implies to me that a Redis or MongoDB host/platform would be affected but not, say, a regular webapp that merely uses Redis as a background component.
Is a route in a webapp that uses a MongoDB change stream (to use the site's example) behind the scenes 'directly' providing MongoDB? I'd generously say no, but it feels like the sort of thing that lawyers would love to scrap over and I guess is part of why people are worried.
> If you make the functionality of the Program or a modified version available to third parties as a service ...
This is sufficiently vague that proxying a verbatim response from SSPL software is in a grey area.
> premium support: "if you need support, we have the best team on the planet for that".
I know people like to think that the software industry is full of fakes and idiots, but really there a lot of people that can get up to speed on software projects and be really productive in them, to the point where you can just hire your own engineers and have them support it in house.
Personally I always find it frustrating to deal with enterprise support after being able to just get into a code base my self.
Actually introduced in 2018, not 2008.
> This is why MongoDB has its "Enterprise Server" edition. Or Elasticsearch has its "Elastic Enterprise Search" product. Or Graylog has its "Enterprise" version. These companies got profits before SSPL, with their open-source editions and commercial editions.
So when AWS starts offering it as managed service, the author thinks nobody will migrate to that? That's very naive. Many companies will choose AWS-first because everything else is in AWS.
In general if you're making money using some piece of software you should contribute, as much as I love using OSS it does cut down the value of software engineers when a company can just leech of someone else's work.
"Thanks for all the work guys! Thanks for signing the CLA and see you around." This is how I interpret it.
Thouse who belive they are fine with SSPL are not looking at bigger picture. SSPL promotes mononopoly and reduces community engagement both of these over time impact every user
> SSPL includes most of the AGPLv3 ... but modifies its provisions for software that is conveyed over a network—requiring that anyone who offers the functionality of SSPL-licensed software to third-parties as a service must release the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL. In contrast, the AGPL v3's equivalent provision covers only the licensed work itself.
I can't believe they made the AGPLv3 seem moderate.
SSPL is not.
Or any of the 4 freedoms for that matter.
Marcan wrote it better than me https://news.ycombinator.com/item?id=30044019
At the end of the day, it does not prevent the four freedoms unless you're trying to curtail the four freedoms to begin with, much like the GPL and its clauses against patent-based workarounds or tivoization.
And it is still a license, the only thing allowing anybody to do anything with that code. The suggested workaround attempts would never fly in court. Even separate legal entities would be deemed conspirators.
Full disclosure: IANAL, and I do not like the AGPL at all, personally favoring MIT license.
OTOH, most of the world seems to consign licensing entirely into contract law - the license is always a civil contract nothing more, which already causes some issues between reading the text in various jurisdictions. And local "spirit of the law" that backs the license also differs.
Also pretty sure at least USA is place where strict reading are at least a viable court strategy, to my understanding.
AGPL has provisions that only apply when a remote user interacts with the program over a computer network. Those provision do not apply if a local user interacts with the program or if a remote user interacts with it by some means other than a computer network.
To meet the requirements of item 10 those provisions should apply when any user interacts with the program regardless of whether they are local or remote and regardless of what particular technology is used to carry the communications between the user and the program.
Since they ask us to ask ourselves some questions, let's do that and get some answers.
> How a company can ask others to "give back to the community" while they are not using open-source anymore?
You read section 13, you decide wether it's open source. The extra strict clause forcing users of the software to make their software open source. Aka copyleft, aka the most strongly community driven definition of open source.
> How a company can ask others to publish their source code while it doesn't publish its own cloud services source code?
By making sure they have their copyrights in order. No one's forcing anyone to use their copyleft licensed software. They offer their software under a copyleft license, that's more charitable than most companies to begin with.
> How a company can declare open-source is part of its DNA while it uses a non-open source license?
This is just the same question as the first one.
> How many of the 3000+ employees share their work and source code with the community? (spoiler alert: way behind 3000)
You want MongoDB's sales staff to share their work with the community? What about Google's 190,234 employees, and AWS's 1,541,000 employees? Where's their open source communities.
Is this some sort of joke? The double standards are ridiculous, did the author even consider who is hurt by the SSPL and who is not? Hint, it's not the community, and hint, it is companies with more than 3000 non-developer staff.
> Are those companies tech companies that want to share with the community or sales companies that want to increase investors' profits?
They are sales companies that want to increase investors' profits. And they do so by participating in the open source community. It is an amazing fact that this is possible, and the Open Source community should be supporting them and engaging with them to find a way to do so that benefits the entire community, instead of building attack ad websites.
> SSPL licensed products are not open-source
That is indeed a problem for open source supporters. With Mongo and Redis, you're stuck on older versions, requiring yourself or someone else to maintain it.
> SSPL is killing cloud and managed services competitors
Yeah, that's kind of the point of it.
> SSPL will rise hosting prices
The competition needing to make their own product to compete may indeed raise prices. However, one could argue that those prices were reduced to the level where no competition was possible in the first place.
> SSPL is killing open-source
[Citation needed]. SSPL is killing the free hosting that software development companies were giving you before, as far as I can see. Healthy open source communities won't switch over to SSPL.
> SSPL goal is probably not about fighting big firms, but more about getting money back to investors
The investors get their money back because the big firms can't compete.
If I was trying to make money on software I wrote, most of these points would make for a pretty compelling argument to choose SSPL over something like AGPL or GPLv3.
I think there are different kinds of Open Source. There's "Linux" open source, which is open source not because one person decides to, but there are countless stakeholders that have contributed their code, many of them with competing interests, all wanting to keep the code open. There is also "Redis open source": a product, developed by a single company, given away for free. The company does accept third party contributions, but the vast majority of code is written by a single core team, working together to make money. I would classify the latter type of open source as "open source as a product". The openness isn't based on some kind of core value, or some kind of project management design decision, but as a way to market the product and get it in the hands of as many people as possible until investor funds start drying up.
I'm sure it sucks having to write plans to overthrow your company's entire software stack after having bought into these technologies, but any "open source" project backed by only one company can disappear or go proprietary at any point, without warning.
I think it's telling that there is no active open-source version of MongoDB, not even one maintained by Amazon. There's FerretDB, which is also company-backed (though that company is still small), but that seems to be a competitor using the same API rather than a direct Mongo fork. Either MongoDB's open source contributors didn't really care about their work going SSPL, or there was no open source community to maintain and support MongoDB in the first place.
With Redis, I hope things go differently. I hope someone will set up an open source fork, and I hope everyone will flock to that. It happened to ElasticSearch, in the form of OpenSearch, and perhaps it can happen again. However, SSPL isn't the problem here; it's merely a symptom of a bigger problem: the productisation of open source, and the ease with which people will accept these productised open source projects as if the license can never change.
> SSPL includes most of the AGPLv3 ... but modifies its provisions for software that is conveyed over a network—requiring that anyone who offers the functionality of SSPL-licensed software to third-parties as a service must release the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL. In contrast, the AGPL v3's equivalent provision covers only the licensed work itself.
This just goes beyond anything reasonable IMO, they set terms that no-one could comply with so you need to negotiate to have it under a different license.
And why is that unreasonable?
- all your changes to the product
- all infrastructure code you use to deploy the product for your customers
- all billing code you use to bill for the product
But I would not expect you to release code for e. g. services based on other products (open source or otherwise), or your whole billing stack, or your internal services you use for customer support for example. Just the code that you use with my particular product.
Now, SSPL is a bad license for numerous reasons (many of the concerns in the OP article are valid!) and this is why I've decided against it on my project [1], but I think the basic premise of it is completely valid.
[1]: https://lunni.dev/, licensed AGPL-3.0
SSPL also deals with selling the software under license as a service, but it does not define _exactly_ what is included as pertaining to being SaaS. It only gives you some examples. This means the actual test can only be determined in a civil suit.
* note to enforcers. /S is a common internet idiom indicating sarcasm.
** note to enforcers. Sarcasm is a form of irony whereby one mocks the thing one appears to say by meaning the opposite of the saying