Source-available licenses - Elastiscsearch and SSPL

Florian Idelberger
 
Time and time again, companies have struggled with their licensing. It has often been a challenge for companies to find a business model that enables them to make money, but still provide truly open-source software. That said, the precise economics are often not verifiable as it is also possible that at some point a pivot to a more closed license is simply an enabler to achieve higher market share, whereas in other cases it is about survival.
Recently this was in the news again as Elasticsearch, a web server frontend on top of the Apache licensed Lucene database framework switched to a choice between SSPL (Server Side Public License) or Elastic License, a custom source available license. Below, the AGPL is contrasted with the SSPL and BSL (Business Source License) which has a similar aim.
 

AGPL
 
At first, there was AGPL (Affero General Public License) and later AGPL-3.0 (GNU Affero General Public License, version 3 (https://www.gnu.org/licenses/agpl-3.0.en.html)) to extend the Copyleft of the GPL-3.0 to web services. The core tenet there is, that the license is intended to ensure availability of source code, thus increasing the availability of knowledge and information. To achieve this, it has extended the scope of ‘conveying’ a product and its object code in such a manner, that access or use of a modified product by an end user requires proper conveyance of the corresponding source code, as opposed to only in case of ‘linking’ in the original GPL.
There are also projects and products that choose a version of the AGPL as a measure to defend against perceived ‘free-riding’ or abuse. One recent example where AGPL was chosen is plausible, a privacy-conscious alternative to google analytics, which can be either used as a hosted service or self-hosted, which recently announced that it changed future versions to the AGPL. In some cases, companies also offer an AGPL version and then employ ‘dual licensing’ where the same software is available under a proprietary license, without AGPL obligations, for a fee. This is however generally only possible if a project or company owns the complete copyright or was assigned or licensed via a contributor license agreement to change the license of the project and corresponding contributions.
 
The same, or a similar narrative is spun by other past and recent projects where a license change took place, especially database products have an increasing affinity for changes towards a more restrictive license. The main licenses that are used are the SSPL (Server Side Public License) and the BSL (Business Source License) as well as custom ‘source available’ licenses, where the license is particular to a specific entity, but nonetheless source code is shared with customers and sometimes also with the public.
 

SSPL (Server Side Public License)
 
The SSPL was premiered by database company MongoDB and is a modification of the AGPL-3.0 as demonstrated in this document where the changes are highlighted. It was originally submitted to the OSI (Open-Source Initiative) for certification as an open-source license, but after criticism that this submission was withdrawn. Most recently, Elastic also switched to a choice of either SSPL or Elastic License, their custom source available license.
From a legal certainty point of view, it is certainly preferable that the SSPL is not a ‘fill in the blanks’ license such as the BSL, as this is at least more predictable and provides a modicum of increased legal certainty in comparison.
The main difference pertains to the added section 13, to which use and distribution of the covered work in any form is subject. Where the AGPL-3.0 uses the general term ‘remote network interaction’, the SSPL aims squarely at SaaS (Software as a Service) offerings, with the heading ‘Offering the Program as a service’. Furthermore, where the AGPL cares only about making modifications and improvements available, the SSPL obligates publication of the source code of a service offered using the SSPL licensed project and everything necessary for that service. This is such a broad obligation on anyone that would want to do this, it would be often even uncertain if it is even possible, depending on which services this specific service interacts with.
Granted, supposedly this does not apply if an instance of an SSPL licensed product is not interacted with directly, and does not ‘entirely or primarily’ provide the value of a service. This is however subject to more precise interpretation and no reasonable business or open-source project should rely on assurances by vendors that a certain endeavour or practice is currently not considered to fall under this obligation, especially as time progresses, managers change and financial and business incentives change.
In addition to SSPL, products are often also offered under a proprietary license, in the case of Elastic Search the latest is called Elastic License v2. It has similar restrictions to SSPL, but in addition also adds license key functionality, which directly places it outside of free and open licensing.
 

BSL (Business Source License) 
 
The main feature of BSL is customizability by vendors generally, and specifically a customizable ‘change date’ at which point the code is automatically relicensed under an open-source license, as well as an ‘Additional use grant’. While the source code is available before, and it is allowed to test and modify software, each vendor defines in the ‘Additional use grant’ which usage beyond testing private usage is permissible. In the case of MariaDB, this does also not apply to the core database product, but to products that build on top of this or enable and improve scaling and deployment such as MariaDB Maxscale, a database proxy. The actual database was previously forked from MySQL and is licensed under the GPL v2. In the case of Maxscale, the filled in license grant specifies that use is free for up to 3 database server instances.
In the case of Zerotier, a software to enable seamless virtual private networking between many devices that switched from GPL to BSL, they claim that apart from all the other reasons like use by competitors (‘SaaSification’) the main reason for switching from GPL (and optional commercial licenses under a dual licensing model) was that supposedly enterprise customers still have an irrational fear of GPL ‘infection’, even when this is in no way applicable if they just use a tool conveyed under the GPL. In their case, their usage grant allows all uses except selling Zerotier service as SaaS, creating proprietary (non-open source) derivatives, remove licensing information or use the software in governments with the exception of healthcare, social services and other care related activities. Furthermore, their change date is four years, which in technology is a long time.
While the frustration with perceived abuse of available sources is understandable, especially the Zerotier example showcases how far the restrictions go and how hard this makes the assessment if or how a specific project under such a license can be used, especially when these restrictions go far beyond merely keeping away direct competitors.
 
 
In the end, both the SSPL and BSL are not open-source licenses. Free- and open-source licenses derive their value precisely from not limiting what a user can do with a specific software, and even more important, from relative legal certainty derived from knowing that a specific software is available under a certain license. Having fixed licenses is also important for relatively easy assessment of compatibility between licenses. 
The main takeaway here is that while past experience has shown that copyright can be a useful tool to produce and distribute open and free code, its ability is very limited in that regard. From a personal, moral or other subjective point of view it is very relatable that companies, project, contributors think about how to prevent abuse of their work, either in an economic sense or a moral one, like when public software is used for military applications. But in a very direct sense it also contravenes the spirit of free- and open-source licensing, even if a license with limited freedom might still be preferable in some cases than a completely proprietary one.
 

Appendix
 
Further database products with similar licenses are Redis under the ‘Redis source available license', Confluent under the ‘Confluent Community License’, CockroachDB with a relatively permissive version of the BSL or the ‘Cockroach Community License’ and TimescaleDB with its ‘Timescale License’. (non-exhaustive)