The Case Against the Server Side Public License (SSPL)

Almost four years ago MongoDB introduced the Server side Public License (SSPL) and started releasing MongoDB server software under this non-OSI approved proprietary (Source Available) license instead of the AGPL v3 it used previously.

As a founder of Percona, which provides enterprise support for open source software, I’m not a big fan of SSPL (check out “Why SSPL is Bad for You” for more on this topic). In this article, I wanted to see what changes this step leads to in an open source database ecosystem.

How SSPL Impacts Traction

👁 Image

I find this DB-Engines Graph comparing PostgreSQL and MongoDB the most telling — we can see that while the MongoDB score continued to grow, after this change it started to fall starting in early 2021. This is of course correlation not causation but still interesting.

This still has not impacted StackOverflow Survey results (only available for 2021) where MongoDB adoption metrics continue to grow (27.7% vs 26.4% in 2020).

Elastic was another company that followed changing from Apache 2.0 to SSPL and calling it “doubling down on open.” This made their software impossible to use for many companies embedding Elastic as permitted by the very permissive Apache 2.0 license and ensured unlike with MongoDB a fork was born — OpenSearch.

MongoDB avoided fork perhaps because it has been using AGPLv3 license, which is already a rather restrictive license and intentionally did not develop a community of contributors capable of forking. However, MongoDB protocol level compatibility was added on top of different Database Engines by AWS, Azure, Oracle, FerretDB (OSS).

👁 Image

If we look at DB-Engines, we see Elastic has been stagnating in 2022 while OpenSearch has been growing very rapidly.

Both MongoDB and Elastic are public companies so we can see how they have been performing on the public markets:

👁 Image

We can see MongoDB is doing much better than Elastic and while both companies are down from the peak (together with most of the stocks in Tech sector), MongoDB is trading quite a bit higher than the time it ditched open source and Elastic is quite a bit lower.

So we can’t really say that ditching open source is bad for business (as measured by a stock price) at least in the short and medium term.

Bad Ideas Are Contagious

While SSPL is bad for you, as a consumer, the fact MongoDB did not crash and burn as a business after the license change emboldened a lot more companies in the database space to ditch open source licenses or get started with source-available licenses to begin with.

CockroachDB, TimescaleDB, Redis, and Confluent all changed their license for all or some parts of their platform from open source to source-available.

What is even worse, rather than being honest and positioning such software as the proprietary software it is, which just happens to have source code you can see, they position it as if it is almost as good as open source. I feel they intentionally use misleading terminology, as “open” (in the case of Elastic) and in the case of MongoDB even trying to convince OSI to have SSPL recognized as an open source license (thankfully unsuccessfully).

Let’s be clear: This new kind of proprietary software with a license you can see does provide more freedoms than conventional proprietary software of decades past. But it is not open source.

DBaaS Is All That Matters

If you look at the restrictions which are introduced in those source-available licenses in the database space you will find most of them are focused on creating a DBaaS monopoly, so if you want to run DBaaS you have to go buy it from a software vendor or provide it under the license of such vendor.  You can’t proceed with the wonderful permissionless innovation open source is so known for and build something as Amazon Aurora or Neon PostgreSQL.

“So what,” you say, I can still deploy database software non-DBaaS ways, whenever on your own or with help of other parties making deployment easier. Yes, you can, but it will be no match to DBaaS in simplicity, usability, or agility, especially at scale.

DBaaS is akin to a wheel for transportation on land, while wheelless transportation methods are possible they are impractical.

As the expectation for simplicity continues to grow among a new generation of developers we see DBaaS of some forms becoming an expected norm both in public and private cloud. “Other ways” to deploy databases are quickly becoming irrelevant.

With a single vendor exercising a monopoly on DBaaS deployment of their software, we’re back in the good old days of “customer as a hostage” having no real choices,  which creates a wonderful source of reliable profitability for software vendors.

Competition

If Commodity is a dirty word in Business, then it relates to being one, at the same time relying on commodity with multiple feasible interchangeable sources for your inputs is considered a great positive as it gives you both a pricing advantage and protection from many other risks.

Competition is known to improve quality, drive prices down, and increase innovation and open source is great in sparking such competition as it makes the technological barrier to entry very low.

DBaaS neutering Source Available licenses attempt to take it away.

With that let’s actually look at what has been going on in the competition in DBaaS space for MongoDB and PostgreSQL, as examples of perhaps the most permissively licensed database in terms of DBaaS Availability

Official MongoDB DBaaS is called MongoDB Atlas. The same Atlas is available on some cloud marketplaces such as AWS Marketplace. MongoDB also forced some other cloud vendors ranging from Alibaba to Linode in all cases (as I can see) it is plain old MongoDB with no core database engine innovation done by those vendors. If it looks exactly like the Oracle database is available on AWS and other clouds, it is because it is.

Let’s look at PostgreSQL as a comparison though — in addition to many cloud vendors offering “vanilla” managed PostgreSQL we are seeing AWS Aurora,  AlloyDB, Neon PostgreSQL, TimescaleDB, BigAnimal which all have built significant innovations on PostgreSQL core (without needing any permission from everyone or incurring some license fees.)

Costs of Being a Hostage

You may wonder though if you’re using third-party DBaaS rather than MongoDB Atlas are your costs any different compared to other database technologies, say PostgreSQL? I will use Linode for comparison because it makes it very easy with its transparent pricing.

Let’s look at a midsize database running on three node cluster with 128GB nodes and shared CPU, three Nodes on their own will cost $1920 per Month, the PostgreSQL cluster will set you down $4,480 while MongoDB will cost $5,760 which is $15K a year for basically software license for just single replica set.

You may also see from this pricing that there is a 130% surcharge on Linode for Managed DBaaS on PostgreSQL compared to cost of infrastructure — if you want to target these price savings consider using Kubernetes and Operators, such as those provided by Percona.

Summary

We can see while it is hard to judge financial outcomes from license changes we can suspect adopting a non-open source license reduces traction and adoption, but what is most important it reduces innovation, reduces competition and increases prices. Want to be a customer rather than a hostage? Choose real open source, not a bad imitation called Source Available Software.