After MongoDB switched to SSPL I wrote part one of this article, titled “Why MongoDB’s SSPL is Bad For You”. At the time it was a MongoDB phenomenon, though over the last 2+ years more companies (typically VC-funded unicorns or public companies) changed licenses to SSPL or similar. This culminated in Elastic changing their license to SSPL, which is a particularly concerning case, for a number of reasons.
So, before we jump to the main topic of this article, let me talk about why I see Elastic’s change as being much more concerning than MongoDB’s.
Elastic’s Promise, Unkept
Elastic already did some license soul searching in 2018. In that post, Shay Banon made the commitment “We will remain an open source company.” You can also see that because Open and Non-Open code were mixed in the same GitHub repository, this explanation and promise was provided:
There is an interesting Twitter thread on this, check it out.
As far as I know, MongoDB never gave a similar promise, and in general, they have been a “Reluctant Open Source Company” and quite open that releasing MongoDB as Open Source was their Freemium Marketing Strategy (source).
Changing From Permissive License
MongoDB was AGPL licensed to begin with… which is a very restrictive copyleft license. In theory, it should have protected MongoDB from having to compete with cloud hyper-scalers in offering DBaaS. In practice, though, there were a number of companies offering AGPL licensed MongoDB as part of their DBaaS and as rumor has it, it was not easily enforceable.
The fact that MongoDB was AGPL licensed to begin with means there never was a “level playing field” for MongoDB and other contributors. For example, at Percona we are building an extended version of MongoDB – Percona Server for MongoDB – and we can only distribute it first under the AGPL and then the SSPL license. MongoDB can sell it under a proprietary license (think MongoDB Enterprise) or any other Open Source license if they chose to. This is important as a number of companies, including Google, do not permit the use of AGPL software.
Apache 2.0 is a very permissive license though, as one is able to embed such software in virtually any Proprietary (or Open Source) software, make it available as cloud, etc. This means the Elastic license change will affect many more users, and much more drastically, than in the case of MongoDB.
Contributors, Mislead
Elastic has a huge number of contributors, more than 1,500 if you believe this source. Elastic relied on its contributors far more heavily than MongoDB for speed of innovation. This is not a surprise, as due to the Apache 2.0 license used for core software, it made sense for many companies to make ElasticSearch better to meet their own needs.
Many of those contributions were done because the combined work could be used under the Apache 2.0 license, and because Shay was very vocal about Elastic’s commitment to sticking to the Apache 2.0 license forever.
I wonder how many of them would have contributed if they had known the only way they could use derived work was under the terms of the SSPL license… Probably not many.
You can argue, of course, that contributors still have access to Apache 2.0-licensed old software and they could fork it if they do not like what Elastic is doing. But, it is not practical for companies who don’t specialize in Elasticsearch development to do this.
There are companies that have big business tied to the need for Elastic to be truly open (but not Elastic’s definition of open). As I expected and hoped, AWS is forking ElasticSearch, building on its work of Open Distro for Elasticsearch. And it is not alone. Logz stated they are doing the same, and while not promising to do it themselves, Aiven expressed hope that the community would come together to do so.
Dangerous Wordplay
The title of the blog post on the license change is “Doubling down on open, Part II.” It does not say we’re moving to non-OSI license or “Source Available License,” as such licenses are often called, but actively uses the words “Open” and “Free” (as in Beer) through the post. These words are typically associated with Open Source Software, so it looks to me like intent to confuse the reader.
To be fair, it is not just Elastic. For ages, SQL was marketed as “Open Standard”. AWS talks about “Open Source Databases” while, of course, AWS offerings range from proprietary code database engine technology, such as DocumentDB and Aurora, to the Proprietary Management level.
I very much worry that the marketing efforts of companies with budgets much larger than those of most Open Source communities will erode the understanding of what Open Source was really intended to be about.
With all that in mind, let’s now think about why SSPL is bad for you.
SSPL is Bad for End Users
If you’re just using software, SSPL is bad for you because it restricts your choices. SSPL is usually chosen to give one vendor a monopoly on their SaaS/DBaaS deployment model, which means reduced choice and higher prices. The SaaS/DBaaS model is the fastest-growing usage model for a lot of software.
Do not believe vendors downplaying it by saying, “well, unless you’re going to sell it as SaaS it will not affect you.” It is likely to affect you directly, or even indirectly, if other vendors have to pay higher costs for their DBaaS, as they inevitably pass costs on to you as a customer.
SSPL stifles innovation by discouraging code contributors and creating increased vendor lock-in. While SSPL can be better for you than a conventional proprietary license, you should choose a more liberally-licensed alternative if you have a choice.
SSPL is Bad for Code Contributors
If you’re contributing or planning to contribute code, SSPL is bad for you because you only get access to the combined work under the terms of SSPL. This benefits the vendor but places severe restrictions on how you can use the software yourself.
If a project’s license is changed to the SSPL after the fact, you are likely to find yourself a member of a quickly-shrinking contributor community, because fewer people will find it attractive to contribute.
SSPL is Bad for Vendors
MongoDB and Elastic will probably not agree with this, but in fact, they changed the license to be in a better position as a business. I believe this is short-term thinking though. The wheels of Open Source often move slowly, but inevitably. I would be very interested to look at MongoDB and Elastic 5-10 years from now. Will it still be a thriving technology that businesses build new applications with, or will it be a new Oracle, sucking more and more revenue from a shrinking user base of legacy deployments?
MongoDB and Elastic are probably betting on the Cloud making Open Source all but irrelevant. However, I believe we will see a new wave of Open Source Software, offering us usability of current Proprietary Public Clouds, but as a no-lock-in Open Source solution you can run everywhere. Similar to server hardware, Virtualization Hypervisors were commoditized and so will the Cloud be. With commoditized Cloud, we will be looking for truly Open Source Data Stores to have a complete stack, which will inevitably lead to their creation.
Looking for more wisdom? Take a look at the article Why Real Open Source is Better by Matt Yonkovit.
Apparently AWS’s fork & Logz’s fork are just one:
“Since Elastic’s announcement, we’ve been collaborating with the AWS team to work towards a single distribution both organizations will take part in.”
https://logz.io/blog/truly-doubling-down-on-open-source-2/
Yep. I think if AWS fork is well governed it makes sense for community to cooperate instead of create many competing forks
I am trying to understand one situation here. Would like your inputs.
Lets say I provide a SaaS which uses MongoDB as a backend provider. This mongodb instance is then installed in a cloud instance for example for every customer seperately. And the same endpoint connects the application to Backend for functioning.
Would this fall under SSPL ?
Deepankar,
We at Percona, are not in position to provide a legal advise. I can speak only about myself and only hypothetically. So let’s say hypothetically I were to provide a SaaS service based on MongoDB. The SSPL license is kind of fuzzy about this, and I can make a conclusion either way. For some help there is SSPL FAQ
https://www.mongodb.com/licensing/server-side-public-license/faq
which covers this situation, to quote:
“What are the implications of this new license on applications built using MongoDB and made available as a service (SaaS)?
The copyleft condition of Section 13 of the SSPL applies only when you are offering the functionality of MongoDB, or modified versions of MongoDB, to third parties as a service. There is no copyleft condition for other SaaS applications that use MongoDB as a database.”
So it kind of gives assurance that I can provide SaaS application based on MongoDB and I am not required to open source code of my whole stack and my application. So I probably would be less worrying about this part.
However it is worth to remember that SSPL FAQ is NOT a part of license itself, so if it ever goes to a court, the court will consider only SSPL License text, not some outsides FAQs, so I would seek an additional confirmation from my legal team, that they are ready to deal with this case in a court if it is ever comes to it.