Strong OSS licenses is the new black? Understanding SSPL, ELv2, BSL and the Commons Clause
Why ElasticSearch, MongoDB and MariaDB switched to strong licenses? What is the difference between them? How does they impact community? Read below to find the answers.
In the previous article Open-source licenses 101 for startup founders I covered the most popular licensing options. In general, early-stage open-source startups choose very permissive licenses like MIT or Apache, but then at later stages switch to heavier licenses like GPL.
But times are changing and open-source projects become more and more "calculated". Founders start open-source projects as businesses from the day one. Eventually, this influences their attitude towards licensing. I believe in the nearest future we will see many open-source companies switching to heavy licenses or even adopting them right from the inception.
Today I want to talk about iconical open-source companies which started this heavy licensing trend: ElasticSearch, MongoDB, and MariaDB. Why they decided to do this? What is the difference between their licenses? How does it impact their communities? Read below to find the answers.
TL;DR version is here.
MongoDB license (SSPL)
MongoDB has been the first major player who switched from a permissive license to a copyleft one. In October 2018, MongoDB announced its transition to the new license called SSPL or server side public license. You can find the original blog post about it here.
SSPL license is a very strong copyleft license and it is basically the heavier version of GPL. SSPL requires that anyone who offers the functionality of the software or its modified version to third-parties as a service, must release all the source code, including software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL.
In other words, this means that if you release SaaS version of SSPL-licensed software hosted on AWS (or any other provider), then you would have to release all the source code of your hosting provider. Therefore, this means you can't create a competing SaaS solution using SSPL-licensed code. Unless you have your own open-source hosting provider :)
You can see that the main purprose of SSPL license is to defend the company from competing SaaS solutions. An excerpt from the official FAQ confirms that:
When and how to use SSPL?
SSPL is used by companies like MongoDB and Elastic (company has two licenses to choose from). SSPL is quite well-known and provides very accurate language which protects your software from reselling. The main drawback is a long text, which could scare away contributors.
To use SSPL, you shoud simply add its text to the repo.
Elastic License (EL)
A bit of the history…
In January 2021 ElasticSearch announced a switch from Apache License 2.o to the Elastic License. This decision was mostly driven by the fact that AWS for several years has been providing Amazon Elasticsearch Service, which is based completely on Elasticsearch.
If you are familiar with Apache License 2.0, you know that AWS had the right to sell Elastic via managed service. But still, they didn't have the right to use Elastic's trademark as it is explicitly stated in Apache License 2.0. AWS violated this clause and additionally created a confusion that Amazon Elasticsearch Service is a partnership between AWS and Elastic.
Combination of these events led to Elastic's decision to change the license. Actually, company adopted both the SSPL and Elastic License – users can choose on their own which licence to pick. Well, it didn't really stopped AWS. They just forked the latest avaliable version of Elastic under Apache License and renamed it to "Amazon OpenSearch Service". Simple like this.
ELv1
Elastic License 1.o (ELv1) is the initial version of Elastic License. It was originally introduced in 2018 for X-pack directory of the Elastic source code. In January 2o21 this license was applied to the all Elastic codebase, but it was quickly changed to Elastic License 2.o. If you are interesed, you can find the text for ELv1 here.
Basically, these ELv1 and ELv2 are almost identical – ELv2 is just shorter and a bit more permissive. Probably, you don't need to know a lot about ELv1.
ELv2
Elastic License 2.o is a very short and simple non-copyleft license, which allows to use, copy and distribute the software. It has only three limitations:
- You cannot provide the software to others as a managed service
- You cannot hack the license key functionality or remove/obscure features protected by license keys
- You cannot remove or obscure any licensing, copyright, or other notices
Well, short and sweet. Nothing to remove, nothing to add.
Limitations of the ELv2 ans SSPL are actually quite similar except for one point:
When and how to use ELv2?
ELv2 is obviously used by Elastic and already adopted by startups liked AriByte and OpenReplay. It is an interesting indicator that ELv2 is already being adopted by "young" projects.
I think ELv2 is a good choice for "heavy" infrastructural products, which are in a risk of being reselled by hosting companies. ELv2 protects them from this issue and at the same time it doesn't forbide to use the software as a part of different product. I do believe this freedom is absolutely instrumental to grow the community around the product.
To use ELv2, you should simply add its text to the repo.
MariaDB Business Source License (BSL)
MariaDB Corporation in 2017 introduced new license called BSL or Business Source License. This license is used for MariaDB MaxScale, an intelligent database proxy. MariaDB Server is a community fork of MySQL server, which is licensed under GPL. As you may remember, GPL is a copyleft license and all derivative works of the GPL-licensed software are forced to be licensed under GPL as well. That's why BSL is applied only to MariaDB MaxScale and not to MariaDB Server itself.
BSL license is a tricky one. By default it doesn't allow commercial use of the software, but garantees that in the future this software will become open-source (GPL of Apache licensed). Yes, that sounds complicated, so let's break it down step by step.
No production use
Basically, BSL forbides production use of the software. Though limited production use can be allowed by "Additional Use Grant". We will talk about it a bit later.
Production use is quite a vogue term as you can imagine. According to the official FAQ, production use "is typically indicative of an environment that is delivering significant value to a business". Well, I guess it can be translated as no commercial use is allowed. Of course, BSL license is not recognized by OSI as an open-source license.
It does not matter whether you want to provide BSL'ed software as a service or just use it as a part of different service. BSL by default forbides both of these use cases, unless something is allowed in "Additional Use Grant".
Additional User Grant
"Additional Use Grant" is an island of freedom in the sea BSL. It is a very flexible construction that allows to grant users additional freedoms.
For instance, take a look at "Additional Use Grant" clause from the MariaDB MaxScale License:
So you are free to use MariaDB MaxScale for commercial purposes if you have less than three server instances.
You can also take a look at this clause for Sentry and CockroachDB, which also adopted BSL.
Change date
The last important part about BSL is its guarantee to turn into an open-source license somewhere in the future. Again, let's take a look at MariaDB MaxScale's license:
Change Date clause effectively says when this software will change the license. If date is not specified, then it equals to 4 years from the day of the code release.
Change License clause specifies the license which will become active on the Change Date. Change License can be any BSL competible license such as GPL or Apache 2.0.
Interesting fact that Change Date can be altered as many times as you want. This actually allows to set distinct dates for different versions of the software. For instance, MariaDB MaxScale 2.0 is already open-source and GPL'ed, but MariaDB MaxScale 6.2 is planned to become open-source only in 2026.
When and how to use BSL?
BSL is being used by companies like MariaDB, Sentry and CockroachDB. Probably, it is the most flexible license out of stong ones avalialbe out there. It might be a good choice for companies where functionality significantly changes from one version to another – newer versions would be protected from commercial use and older would be automatically released under permissive license.
To use BSL you should simply include license text in the repo. For instance, take a look at how Sentry adopted this license.
Apache 2.0 with the Commons Clause
Last but not least in the list of strong licenses is Apache 2.0 with Commons Clause. It is well-known Apache 2.o license with a quite short preambula called "Commons Clause". Let's take a look at the language of this clause from the n8n's repo:
Basically, this clause says you can do anything with the software as it said below in Apache License 2.o, but you cannot "Sell" this software. It explicitly forbides to provide paid hosting, consulting or support services for this software.
The good thing about Commons Clause is that one can sell the derivative version of the software which is "substantially" different. I'll clarify this one a bit later.
Apache 2.0 with added Commons Clause is no longer considered an open-source license by OSI. In a nutshell, it is a compromise between permissive and copyleft licenses, but it has some inborn drawbacks.
The Commons Clause
The Commons Clause was initially drafted by Heather Meeker, well-known open-source licensing expert. In theory, this clause can be applied to different permissive license like MIT, Apache and BSD. But still, Apache is the most commom option for that.
The Commons Clause coins a vogue term "substantial derivative". Probably, it should be interpreted as a restriction to sell the derivative product which adds only an insubstantial value to the software – like changing names, APIs or function signatures. As you can imagine, this definition can be treated very differently, so in practice it is quite risky to use Commons Clause licensed software inside a paid product.
Another problem with the Commons Clause is confusion. When developers see Apache 2.0, they wait for Apache 2.0. But, the Commons Clause turns everything upside down, so there is basically nothing left from the Apache 2.o despite the fact its text is comming right after the Commons Clause.
When and how to use Apache 2.0 with the Commons Clause?
Well, to use this licensing option you should simply add the license next to your repo. You just take Apache 2.o text, Commons Clause text and put the former before the first one. Simple as that.
Apache 2.0 with Commons Clause is used by companies like n8n and Redis Labs (for some modules). Apparently, the Commons Clause could be a "soft" option for transitioning from a completely permissive license to a stronger version. But in my opinion, confusion created by this license outweighs its "softness".
Community Impact
A common drawback for all licenses mentioned here is community impact. They are not recognized as open-source licenses by Open Source Initiative (OSI), because they violate 6th clause from the definition of open-source software. This clause basically says that an open-source license must not restrict anyone from using the software in a specific field or endeavour.
Besides that, there are some signs of community frustration about new licensing trend. For instance, there is a recently emerged "truly open-source" alternative to MongoDB. Take a look at how FerretDB accuses MongoDB in "abandoning its open-source roots".
Giants like MongoDB are unlikely to loose a lot from this frustration. But one should keep in mind, that it could harm signficantly to an early-stage open-source startup which is only looking for a product-community fit.
In my opinion, there are three important aspects minimizing the community impact:
- License should be short, simple and clear
- It should only forbid to resell the software directly. Usage of the software as a part of a different service should not be forbidden.
- It should not confuse developers
Final Words
Choosing license is hard, but I hope this article sheds some light on this complicated topic.
As promised, here you can find a TL;DR infographics for this article. Hope you will enjoy it! 😊
If you really liked something from this article, please consider sharing it or leaving a comment here. Let's help OSS founders to choose licenses wisely!