Moving Away From Open Source: Trends in Source-Available Licensing

Offering your software product under an open-source software (OSS) license has its advantages. By making the source code of your product available for redistribution and modification, and in many instances at no cost, you may drive widespread adoption of your software at an accelerated pace. It’s even more likely if your software is licensed under so-called “permissive” terms, such as the MIT license or Apache License, Version 2.0 (ASLv2).

OSS can support a successful business, despite being offered free of charge. For example, a company can use its expertise to offer paid support and customization services of its product; it can offer a commercially licensed, closed-source version of the software that includes premium features; or it can provide paid cloud hosting services. But what works for one company may not work for another. And true “open source” software licenses (such as MIT and ASLv2) provide limited ability to protect against the pitfalls of OSS. Whether you’re just getting your company off the ground or you’ve been commercializing an OSS project for years, you may find that you have more nonpaying users than paying ones or that other companies are leveraging your own software in competition 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. Frequently, the OSS license is replaced with what is commonly referred to as a “source available” license. Like software made available under an OSS license, software provided under a source-available license is made available in source code form and, in many instances, can be freely modified and redistributed. However, unlike OSS licenses, source-available licenses often restrict commercial or competitive use in some form.

Cloud service vendors, such as Amazon, have been notable drivers of OSS product providers seeking non-OSS licensing solutions. OSS product providers have raised concerns about these cloud service vendors creating confusion about the source of the OSS products they offer their customers and providing third-party OSS products as a service without collaborating with or giving back to the OSS community. 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. In 2018, MongoDB released the Server Side Public License (SSPL), a carbon copy of the network copyleft OSS license it was previously using (the Affero GNU Public License, version 3 [AGPLv3]), save for its replacement of the license’s SaaS section. The AGPLv3 requires anyone providing a modified version of the AGPL-licensed software that is interacted with remotely through a computer network to provide the source code needed to generate, install, modify and run that version of the software. The SSPL seeks to make it clear that providing SSPL-licensed SaaS triggers similar requirements. Specifically, the SSPL requires anyone making the SSPL-licensed software or a modified version available to third parties as a service to provide the source code of the programs required for a user to run their own instance of the service. In changing its license, MongoDB cited concerns with certain organizations testing the boundaries of the AGPLv3. Notably, the SSPL does not forbid providing the licensed software as a service, but it places such a potentially significant burden on the service provider (including the prospect of having to disclose proprietary source code) that potential licensees are often likely to seek a commercial license instead.

A few years later, in January 2021, Elastic announced that it was updating the license of portions of Elasticsearch and Kibana from ASLv2 to a dual-license structure, in which the user can select one of two source-available licenses under which to use the software: SSPL or a new license, Elastic License 2.0 (ELv2). Elastic made the change following what it characterized as years of bad behavior by Amazon and AWS. While the ELv2 is not a copyleft license and does not condition use of the licensed software on sharing the source code of derivative works, it forbids providing third parties with access to a substantial set of features or functionality of the software as a hosted or managed service. Amazon subsequently forked the Apache-licensed version of Elasticsearch, branding it as OpenSearch. Interestingly, Elastic made a move back to open source by announcing in August 2024 that it is adding the AGPLv3 as a third licensing option, in addition to SSPL and ELv2. 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 [RSALv2]). The RSALv2 is similar to the ELv2 but with stronger restrictions on commercializing the software. Specifically, the RSALv2 states that the licensee may not make the functionality of the software available to third parties as a service or distribute the software in a manner that makes its functionality available to third parties. Redis applied this licensing structure to its Redis Stack and modules in November 2022 while maintaining its open core under the permissive BSD 3-clause license. Subsequently, on March 20, 2024, the BSD was abandoned in favor of licensing all of Redis under SSPL/RSALv2, with Redis indicating that this licensing paradigm was at odds with the company’s future success and enabled cloud-service providers to commoditize Redis’s investments. It’s worth noting that Redis is no stranger to licensing changes, having changed the licensing of its Redis modules in 2018 from AGPLv3 to ASLv2 with the Commons Clause — an additional term that, in essence, restricts commercialization of the licensed software — prior to abandoning this approach in 2019 in favor of the first version of the RSAL.

The Business Source License (BuSL) is a unique source available license created by MariaDB for application to its products, with the most recent version of the license (v1.1) published in 2017. By default, the BuSL permits redistribution and modification of the licensed software but only for nonproduction use. However, the BuSL accommodates the inclusion of “additional use grants” supporting production use in limited circumstances specified by the licensor. The customizable nature of this license makes it particularly useful to companies looking to permit commercial use within certain parameters (e.g., no more than a certain number of instances) or fields (e.g., no use of the software in a database service). The BuSL also allows companies to continue to maintain open-source values, because it requires the software to transition to an open-source license (specifically, a GPLv2+ compatible license) no later than four years from its initial public distribution. To illustrate, if a provider releases version 1.0 of its software under the BuSL on January 1, 2024, and specifies a “change license” of GPLv3.0 and a “change date” of three years, that version will become available under the GPLv3.0 on January 1, 2027. However, the clock restarts for each version released later. That is, if the provider releases version 1.1 on June 1, 2024, with the same change license and change date, that version is not available under GPLv3.0 until June 1, 2027.

While a number of well-known open-source software products have adopted the BuSL, HashiCorp stirred up significant controversy by transitioning the licensing for its products (notably Terraform) from the Mozilla Public License, version 2.0 (MPLv2), a weak copyleft license, to the BuSL in August 2023. HashiCorp cited the need to better manage commercial uses of its source code while permitting much of its existing community of users and customers to continue using its products in the same manner. The additional use grant provided by HashiCorp in the BuSL permits production use of its products, provided the use does not include hosting or embedding the products to provide a competitive offering. The license change by HashiCorp rather quickly spawned OpenTofu, a fork of Terraform made prior to the license change that continues to be updated and made available 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.
• 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 the software released under the BuSL converts to ASLv2 after four years. Cockroach also recently announced that in late 2024 it will consolidate its database software into a single enterprise version and offer it under a new, source available license it calls the CockroachDB Software License.
• In 2021, Grafana Labs relicensed its core OSS projects from ASLv2 to AGPLv3. 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. While it is important (if not existential) for an OSS business to structure the licensing of its software in a manner that drives sufficient revenue, potential licensing changes should be examined through multiple lenses. Looking broadly, this involves considering business and commercial issues, marketing and reputational issues, and legal issues.

There are infinite ways in which to license software, but to find the right direction, you should identify the goals for commercialization (or other goals) for your software. Get a handle on who is using your software, how they are using it, and who (if anyone) is paying for it. Are there users who are using your software for free but are capable of paying? Are third parties able to freely use your software to compete with you? Determine what use cases for your software are desirable and which are not. 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. Project relicensing announcements often cause firestorms of varying degrees, and it is critical to anticipate these reactions when considering a license change. What is the makeup of your community? Is there a significant portion that feels strongly about open-source licensing and/or have made substantial contributions to your codebase? Will they feel betrayed by the change? If maintaining an “open source” image is critical, it may be better to move to a more restrictive open-source license, such as AGPLv3, or a license that includes a mechanism to eventually change to open source, such as the BuSL or Functional Source License, rather than a purely source-available license. 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. Every word of the license is important, so whether you are adopting an existing license as-is, modifying an existing license, or drafting a new license from scratch, it is critical to involve knowledgeable legal counsel. Further, if you are moving your software from one license to another, you need to determine whether, and to what extent, you can change your licensing terms. OSS projects often have third-party contributors. If no agreements are in place with the contributors that give you the right to change the license under which they made their contributions (e.g., a standard Contributor License Agreement), and it is impractical to seek their consent or remove the code they contributed, those portions of your project will need to remain under their current license terms. If the current license is a permissive OSS license, this may not be a significant issue. On the other hand, if the current license is a copyleft license, there may be substantial roadblocks to relicensing the project as a whole.

Choosing the right license for your software at the right time is important. Whether you’re just getting started with your OSS project, trying to commercialize an existing OSS project, or considering changing the licensing for an established OSS product, Goodwin can help. Contact a Goodwin OSS licensing attorney for more information.

 

The authors would like to thank Jillian Wolf for her contribution to this insight.

 

This informational piece, which may be considered advertising under the ethical rules of certain jurisdictions, is provided on the understanding that it does not constitute the rendering of legal advice or other professional advice by Goodwin or its lawyers. Prior results do not guarantee a similar outcome.