In principle I agree that SSPL is "bad", but I understand the reasons behind it. Plus, I don't like the way article 13 is described, the intent was to be sensational rather than an objective analysis.
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.
SSPL is mainly bad for the companies that use the license. They cut themselves off from their own open source communities. Those typically reorganize around a fork, which then starts competing with the SSPL version for new users. Most of those users end up paying somebody else for hosting, support, etc. As a long term business strategy that seems misguided.
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.
> I'm well familiar with Opensearch now being the preferred choice over Elasticsearch
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.
Amazon won't have much interest in supporting on-prem. But I'm sure you can find independent companies that would be willing to help with this. I wouldn't know any one of them well enough to vouch for any at this point. But with a quick Google search I was able to pull out some company names.
There are enough companies going down this path that you should be able to get support.
> Technically the Apache License that Elasticsearch was using allowed that, but ethics should have prevented it.
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.
AGPL wouldn't help in this situation either, as it focuses on the sharing of modifications of the original.
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?
So you put a nice restrictive license on the lemonade, and sure it makes your kid's customers unhappy, but at least it stops- oh wait, actually the other kid just made their own lemonade that's drop-in compatible and they still sell more.
The kid's customers have no reason to be unhappy. They come, pay for their lemonade and go. No problem if that other one goes off and makes their own; at least it's a more fair affair and they can honestly compete on actual merits. Although it still isn't even that fair IMO as the other is still using water and sugar that isn't theirs. They should be using all their own resources from scratch.
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.
> 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.
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.
there is ethics in FOSS and that is the conflict that this is about. companies are trying to build an ethical business and find that they are at a disadvantage against the non-ethical ones, so they are trying to find a license that enforces the ethics
It's not always true, a small but growing number of companies have ethics and solid principles and are becoming B-Corp [1] certified. I am lucky enough to work for one of such companies.
This view of capitalism is relatively recent in origin. Prior to the adoption of the "shareholder value is the only purpose of a company" nonsense by Wall Street in the 1980s, it was understood that companies have obligations to their employees and their country.
Just because you can do something doesn't mean that you should and certainly doesn't mean it is right to do so.
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?
I think people will take issue with this comment due to hating anything that is not open source, but I think that it rings true.
> 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
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.
That's clearly not the direction of travel. Closed source products are not being released as SSSL because some bigCo wants to open up/create community/whatever
What happens is that VC invests into successful open source community projects and then tightens the license. It's the enclosures all over again.
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"
Ah, but this is why almost all SSPL-licensed software is actually dual-licensed: there's the "paying customer" license, which gets you the software without the virality, and there's the "free user" license, which is the SSPL and makes it impossible to sell the code as a service.
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.
> makes it impossible to sell the code as a service
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?
That's why it's not an Open Source license, for the reason that it's viral to all your service, not just the SSPL package you are using. So it might as well be closed source really for most companies.
> 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"
The former doesn't boil down to that at all. Read the entire section without picking out bits. Providing the functionality of the Program as a service is NOT the same as providing a service that uses the Program's functionality.
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.
So you would want to take the risk testing this out with your company? I don't, so ... Closed source, I know the direct legal risks at least. This might not be tested, but no company will want to test it. AGPL is also avoided like the plague by the way by big corps.
And how many of those are paying for a commercial license instead of using it under SSPL license?
> 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 $.
How a company paying for software they use to make money is a bad thing? The open source distribution model was mainly aimed at "normal" users, not multinationals using it to make millions contributing nothing back.
If you're a big corp ponny up the cash for the commercial license.
> How a company paying for software they use to make money is a bad thing?
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.
SSPL and (practical use of) AGPLv3 center around getting companies to cough up money for commercial licensing when due diligence shows up and points out the problem.
To sound like a broken record, what’s the alternative? To put into context: we have an enormously distorted ecosystem today compared to just a decade ago, consisting of open source projects like Linux, Postgres, and all your programming languages. And then we have trillions of dollars going to like 3 mega-corps. They base their entire infrastructure on top of open source projects, and in aggregate give very little back relative to their size and revenue. The small-medium sized companies are often bought, or fail to compete because of lock-in and other competitive advantages in the cloud.
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.
> And then we have trillions of dollars going to like 3 mega-corps. They base their entire infrastructure on top of open source projects, and in aggregate give very little back relative to their size and revenue.
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.
I think it is a bit odd that they ranted about SSPL without mentioning the AGPL for people that want to maintain users’ freedom without the complication of being (almost?) impossible to comply with. It’s almost as if they really just want to use free software without giving back.
AGPL isn't a fix for the Big 3 co-opting projects.
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.)
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.
Yes but specifically mentioning AGPL would have been extremely relevant. It's something that often feels like a thing only licence geeks widely understand.
Maybe, but accusing the author of malicious intent and that they "want to use free software without giving back" because they didn't recommend a specific copyleft license is ridiculous.
True. There's a bit of a chorus of "So you want to steal people's lovely open source?" in this thread in response to anyone who has doubts that SSPL is the right way to do it.
It's fine to disagree but at least add something on top of the points in the linked article.
One thing I’ve learned in all my years is that it’s ok to not be a zealot. You don’t need to pick a side. We should look at these things on a case by case basis. Sweeping dismissal of an approach discards the reasons behind such actions. SSPL is probably good for some companies that are trying to survive against cloud behemoths. It’s also bad when some companies want to take advantage of their contributors.
Everyone that proposes MongoDB, Elasticsearch, or Graylog products directly to its customers is not allowed to do it. You have an API that exposes a route to a MongoDB change stream? BEEP! You are not allowed!
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.
Just saying things are bad, but not addressing the original problem or providing realistic alternatives is just annoying noise. Imo this is what the link is.
> 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.
Exactly. The author shows a few examples of commercial endeavors open source projects could pursue, and acknowledge the projects in question were already doing that. Yet somehow they don't arrive at the conclusion that those commercial offerings simply don't pay enough to be able to build and support their products.
> Any company needs money to survive, of course. And money in open-source is not bad at all.
> 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.
It is mainly bad to big cloud corps. I don't see anything wrong with the people behind these products not trying to get fleeced by Bezons and the rest out of their sweat and hard work.
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.
Functional Source License (FSL) is a good alternative, it automatically converts the released source code to to Apache 2.0 or MIT after two years. It's simple, provides a reasonable way for SaaS companies to function with source available and works automatically, so if the company goes under the users/community are not left with nothing.
My biggest problem is the sheer dishonesty of it. If it said just "not allowed to use to host as a service" then it would be ok, but hiding behind that impossible to comply clause to muddy the discussion and masquerading as pseudo-opensource is bad.
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.
I don't see how AGPL does not run afoul of item 10 of OSI's definition of open source [1], which is that the license must be technology-neutral, which they describe as "No provision of the license may be predicated on any individual technology or style of interface".
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.
Unsurprisingly based on strict readings, and not spirit of the law (judges are human).
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.
I'd argue that AGPL veers off from copyright law there into pure contract law.
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.
This message is brought to you by AWS? Or by whom?
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.
Bad... for who, exactly? Bad for the hosts of MongDB, which the author seems to be, for sure, but amazing for companies not wanting to let Amazon eat up their customer base with their own work. The license should be treated the same way the Windows EULA should be: it's intended to make the code almost proprietary, except you can go digging into it to debug stuff. It's mostly as "source available" license.
> 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.
It might literally be impossible to comply with SSPL - if you use a closed source piece of software to perform some other backoffice/billing/ERM software, you literally don't have the capability to release to comply.
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.
> 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
I do think that when the shared code scope is limited correctly, this is a good faith offer. For example, if you offer my product under SSPL as a service, I would expect that you share:
- 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.
I think the bigger issue is that you'll basically be at the mercy of the courts on how far you need to go with it. The scope isn't well defined IMO and it really couldn't be. Do I need to open source components that I don't have any control over and are proprietary? The questions are endless...
Yeah, that's part of the problem, too. Although it's also a problem with GPL and the likes: you can't integrate closed-source components from third parties with GPL software.
This is extortion if you want to not share back. For Libre software maximalists, this is a good thing: considering you can't do anything without others, it is only normal that you share what you do with others.
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.
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.
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.
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.
There is no ethics in capitalism, only money at any cost.
[1] https://en.wikipedia.org/wiki/B_Corporation_(certification)
Just because you can do something doesn't mean that you should and certainly doesn't mean it is right to do so.
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?
> 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.
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"
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.
> 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.
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.
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.)
> Use copyleft licenses to ensure companies will give back to the community: "if you modify our code, share it with the community".
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.
https://www.gnu.org/licenses/gpl-faq.en.html#UnreleasedMods
It's fine to disagree but at least add something on top of the points in the linked article.
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.
https://fsl.software/
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.
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.
[1] https://opensource.org/osd
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.
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.
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.
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
* 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