Goodwin
Offering a software product under a open-source (OSS) license can have its benefits. You can accelerate the adoption of your software by making your source code available for redistribution, modification, and often at no cost. It’s more likely if you license your software under “permissive” conditions, such as the MIT License or Apache License, version 2.0 (ASLv2). A company can, for example, use its expertise to provide paid support and customization of its product. It can also offer a closed-source, commercially licensed version of the software with premium features. Or it can offer paid cloud hosting services. What works for one company might not work for another. True “open source” licenses (such MIT and ASLv2) offer limited protection against the pitfalls associated with OSS. Whether you are just starting out or have been commercializing OSS projects for years, you might find that your software is being used by other companies to compete against you. Although you pour significant resources into developing your software, OSS licenses enable competitors to freely use it to offer their own products, and many potential customers can avoid paying you anything.
There is an increasing trend of companies with OSS products moving to more-restrictive OSS licenses such as stronger copyleft licenses, including non-OSS license options such as having the option of licensing the software under a copyleft license or a commercial license, or even moving away from their OSS license entirely. OSS licenses are often replaced by what is known as a “source-available” license. Source-available licenses are similar to OSS licenses in that they make software available in source code and allow it to be freely modified and distributed. Source-available licenses are often more restrictive than OSS licenses. They may restrict commercial or competitive usage in some way. Cloud service vendors, such as Amazon, have been a major driver for OSS product providers to seek non-OSS licensing solutions. They are causing confusion about the origin of the OSS they offer their clients and offering third-party OSS services without collaborating or giving back. Moreover, cloud service vendors such as Amazon often have substantially more resources than the OSS product providers, putting the providers at a significant competitive disadvantage.
MongoDB was a notable early mover from an open-source license to a source-available license. MongoDB released its Server Side Public License in 2018, a carbon-copy of the network copyleft OSS licence it had previously used (the Affero GNU Public License version 3
). The only difference is that the SaaS section of the license was replaced. The AGPLv3 requires that anyone who provides a modified version AGPL-licensed Software that is interacted remotely through a computer networking, provide the source code necessary to generate, modify, and run this version of software. The SSPL aims to make it clear that SaaS licensed under the SSPL triggers similar requirements. The SSPL requires that anyone providing SSPL-licensed or modified software to third parties in the form of a service must provide the source code for the programs needed by the user to run his own instance of the service. MongoDB changed its license due to concerns about certain organizations testing the limits of the AGPLv3. In January 2021, Elastic announced it would update the license for portions of Elasticsearch, Kibana, from ASLv2 into a dual license structure. The user will be able to choose between two licenses, SSPL and Elastic License 2.0 (ELv2). Elastic made the switch after what it described as years of bad behaviour by Amazon and AWS. The ELv2 license is not a copyleft and does not require the sharing of source code for derivative works. However, it does prohibit the provision of a large set of features or functionalities of the software to third parties as a managed or hosted service. Amazon forked the Apache licensed version of Elasticsearch and branded it OpenSearch. Elastic announced in August 2024, that it would add the AGPLv3 to its existing SSPL, ELv2, and ELv2 licensing options. As noted above, the AGPLv3 is very similar to the SSPL but, unlike the SSPL, the AGPLv3 has been approved by the Open Source Initiative.
Redis also provides software under a dual license structure (SSPL and Redis Source Available License v2 [AGPLv3]). The RSALv2 has similar restrictions to the ELv2, but is more restrictive in terms of commercializing software. The RSALv2 specifically states that the licensee cannot make the functionality of software available to third-parties as a service, or distribute the software so that its functionality is available to third-parties. Redis adopted this licensing structure for its Redis Stack in November 2022, while keeping its open core under a permissive BSD 3-clause licence. Redis abandoned the BSD license on March 20, 2024 in favor of licensing Redis under SSPL/RSALv2. The company stated that this licensing paradigm was at variance with the company’s future success, and allowed cloud-service providers the ability to commoditize Redis’s investments. Redis has a history of licensing changes. In 2018, it changed the licensing of Redis modules from AGPLv3 with the Commons Clause to ASLv2 and the Commons Clause – an additional term which, in essence restricts commercialization — before abandoning this approach in 2019. The BuSL allows redistribution of licensed software and modification, but only for nonproduction purposes. The BuSL allows for “additional grants” to support production use under certain conditions specified by the licensee. This license is particularly useful for companies that want to allow commercial use within specific parameters (e.g. no more than a specified number of instances), or fields (e.g. no use of the database software). The BuSL allows companies to maintain open source values because it requires that the software transition to an open source license (specifically a GPLv2+ compliant license) no later then four years after its initial public distribution. For example, if the provider releases version 1.0 under the BuSL in January 2024 and specifies that the “change license” is GPLv3.0 with a “change time” of three years, the version will be available under GPLv3.0 as of January 1, 2027. The clock starts over for each new version. If the provider releases version 1.1.1 on June 1, 2024 with the same license and date of change, then that version will not be available under GPLv3.0 before June 1, 2027. HashiCorp cited a need to better manage commercial use of its source code, while allowing its existing community of customers and users to continue using their products in the same way. HashiCorp’s additional use grant in the BuSL allows production use of their products, as long as the use does NOT include hosting or embedding them to provide a competing offering. HashiCorp’s license change spawned OpenTofu – a fork Terraform that was made before the license change, and continues to be updated under the MPLv2. OpenTofu is backed by the Linux Foundation and continues to add supporters.
Other notable examples of changes to more-restrictive copyleft or source available licenses include the following:
In 2018, Neo4j moved its enterprise software from AGPLv3 to AGPLv3 with the Commons Clause (which some argued was an incompatible combination) and soon after relicensed to a proprietary commercial license and discontinued public availability of the source code. Neo4j’s community version is still available under GPLv3.[RSALv2]In the same year, Timescale began licensing certain features of its TimescaleDB software under the Timescale License (revised in 2020), which restricts use of the software to provide a database-as-a-service. The core version TimescaleDB continues to be made available under ASLv2.
In late 2018, Confluent changed the license for certain components of the Confluent Platform from ASLv2 to the Confluent Community License, which is a permissive-style license but restricts making the software available as a service that competes with Confluent products or services that provide such software.
Cockroach Labs changed its core software in October 2019 from ASLv2 to the BuSL, permitting production use of the software except as a database service. Each version of software released under the BuSL will convert to ASLv2 four years after its release. Graylog also changed its open-source projects from GPLv3 to SSPL in 2021. Also in 2021, Graylog moved its open-source projects from GPLv3 to SSPL.
In December 2023, Element relicensed Synapse and related backend Matrix projects from ASLv2 to AGPLv3, citing profitability issues and Element’s carrying of the development load while others built on Element’s software without contributing to the underlying development costs.
- Whatever the reason for considering a license change, it is critical to keep the big picture in mind. It is crucial for an OSS company to structure its licensing in a way that generates sufficient revenue. However, potential licensing changes need to be examined from multiple perspectives. This includes a broad range of issues including business and commercial concerns, marketing and reputational concerns, and legal considerations. Find out who is using your product, how they use it, and if anyone is paying for it. Do you have users who use your software for free, but are able to pay? Third parties are able to use your software for free to compete with you. Determine which use cases of your software are desirable. While some licenses (e.g., Elastic, RSALv2, Timescale, and Confluent) have built-in restrictions relating to hosted or competitive products or services, it should be noted that these licenses were drafted to address specific concerns of their providers and may not be a perfect fit for other products.
- Just as important is the reception of your community and customer base to a new license. It is important to anticipate the reactions of your community and customers when considering a new license. What is the composition of your community? Is there a significant part of your community that strongly believes in open-source licensing, and/or has made substantial contributions to the codebase? Will they feel betrayed? Consider whether there are customers, resellers, OEMs, or others that will be significantly affected and if they have the resources or incentives to fork your software prior to the licensing change and maintain a competing version. Consider also whether there are customers, resellers, OEMs, or others that will be significantly affected and whether they would have incentives or resources to fork the version of your software prior to the licensing change and maintain a competing version.
- There are also important legal considerations involved in choosing a license. It is crucial to have a knowledgeable lawyer review the license before you adopt it as-is, modify it, or create a new one. If you’re moving software from one license type to another, it’s important to know if and how you can modify your licensing terms. Third-party contributors are often involved in OSS projects. If you do not have an agreement with the contributors which gives you the right to change their license, (e.g. a standard Contributor Agreement), it is not practical to ask for their consent or remove their code. This may not be a big deal if the current license is a permissive OSS licence. If the current license is copyleft, relicensing may be difficult.
