All kinds of licenses
After the recent news that HashiCorp has changed the licenses of its hitherto-open-source products, I thought it would be a good time to take a look at the licenses that have sprung up around PostgreSQL and adjacent and related communities, since quite a bit has changed there recently, and it’s hard to keep track.
(Maybe HashiCorp is not really directly adjacent to PostgreSQL, but the license it chose (see below) came from the database space. Also, there is some overlap of users.)
Disclaimer: I work for EDB, which produces PostgreSQL-based software, some of which is open-source and some of which is closed-source/proprietary. Some of the companies listed below could be considered competitors.
Overview
Here is my understanding of the current licensing situation of various projects and companies:
It’s important to note that in some cases, the new license applies to most or all of the product stack (such as in the cases of MongoDB and presumably HashiCorp), whereas in many cases, it only applies to certain add-on products (such as in the cases of Confluent and Redis). You really need to check the details. The source code links above go to the actual source code repositories with the license information in them.
Licenses
Now let’s do a not-legally-rigorous summary of what these licenses mean.
Open source
First, here are licenses mentioned that are recognized as open-source licenses:
- BSD
- This license only requires that derivative works maintain the copyright notice and license text. Otherwise, you can do pretty much anything with the code, including incorporating it into proprietary code or differently-licensed open-source code.
- PostgreSQL
- This is the same as the BSD license in practice.
- Apache 2
- This license is permissive like the BSD license, but has additional terms about patents.
- MPL
- This license requires that in derived works, changes to the files covered under the MPL must be made available. But it permits combination with code under other licenses, and the MPL requirements only apply to files originally covered under the MPL. (This is often described as a middle ground between the BSD and GPL licenses.)
- GPL 2
- This license requires that all derived works are also published under the same license and that any recipient of a derived work also gets the source code.
- GPL 3
- This is the newer version of the GPL that has additional conditions dealing with DRM and patents. For most practical purposes it is the same as the GPL 2.
- AGPL 3
- This is like the GPL 3 with the additional condition that when you provide the software as a network service, you need to provide any modifications for download. This was a first attempt to address software provided as a service. It’s purpose was to preserve the rights that the GPL would give you. Since software provided as a service is not “distributed” in the sense of the GPL, it expands the requirements to software provided as a service.
Other
These are licenses that are not recognized as open-source but are sometimes categorized as “source-available” licenses, since you can still get access to the source code, but don’t have all the rights of an open-source license:
- SSPL
- This is a license based on the AGPL 3. The AGPL 3 requires that if
you offer the software as a service, you need to make any
modifications to the licensed software available for download. The
change in the SSPL is that you need to make all the software that is
used to provide the service available for download, not just the
licensed software. Which would basically require a cloud provider
to publish the entirety of their internal source code, which might
be nice for users, but clearly untenable for most providers.
This license was created by MongoDB, but has since found further adoption.
- BSL
- This license essentially says, you can have the source code, you can
make changes in the source code, and you can use the software, but
not in production. But after four years from publication, the
software becomes available as under the GPL. This means, when the
software is new (not yet four years old), you can try it out, but if
you want to use it in production, you must obtain a different
license from the vendor, presumably for a fee.
This license was created by MariaDB. Note that the “Change License” can be chosen by the licensor. The default, used by MariaDB, is the GPL, but HashiCorp uses the MPL (which is what HashiCorp’s software was licensed under before the change to BSL).
- Confluent Community License
- “This new license allows you to freely download, modify, and redistribute the code (very much like Apache 2.0 does), but it does not allow you to provide the software as a SaaS offering (e.g. KSQL-as-a-service).” Actually, this license reads pretty much like a BSD license, with the express “excluded purpose” of offering the software “-as-a-service”.
The above three appear to have gotten some traction outside of the companies that originally created and used them, and in some cases it was explicitly intended like that. So they could be considered standard licenses by now.
Then there are a few licenses among the ones mentioned in the table above that have only seen one-off use so far:
- Elastic License
- This license was written for Elasticsearch. It has since been replaced by the SSPL. This custom license is very restrictive and really just a small step down from a full proprietary license but that you can get the source code to look at (but not change it).
- RSAL
- This stands for “Redis Source Available License”. It is used for some Redis-related products. This appears similar in purpose to the Confluent license. You can do pretty much anything with the software except make it available as a service to others.
- TSL
- This stands for “Timescale License”. This is a custom license written by Timescale for its own product. It’s hard to classify this as, “it’s just like this other license but with a cloud restriction”, but I think the closest is that it’s a lot like the very permissive open-source licenses in that you can view and change the code and use it internally and distribute it without providing the changed source code, but you can’t run it as a cloud service. (This is for the version 2 license, which is more permissive that than the first version.)
Conclusion
Obviously, the issue here is that a lot of people don’t like these new “source available” licenses. There is a discussion to be had there. But at least there is some emergent standardization happening in this space, so that you only have to know a handful of licenses to understand what you are getting.
-
Update 2024-05-15: With the Redis licensing change announced on 2024-03-20, SSPL and RSAL now govern everything, including the core, and the BSD license is no longer used. I kept my original entry in place but struck through the obsolete parts. ↩