United States: Why Open Source Licenses With A Commons Clause May Become Less Common

Open source software is founded on the principle that it should be made freely available for anyone to use, distribute, or improve. Promotors of open source ideals believe that freely available source code will encourage more extensive distribution and use of the code, spurring further innovations and improvements. Given the complexities of today's software applications, and typical modular or object-based designs, open source software provides significant efficiencies to developers who can focus their efforts on core products and technologies without reinventing the wheel for certain enabling or peripheral code.

The growing user and contributor communities of many open source projects have allowed them to mature into essential technologies for much of the backbone of today's internet. Open source software, such as the Apache web server, are used by most websites today. Likewise, database technologies such as MySQL, MariaDB, Postgres, Cassandra, Redis, MongoDB, and Neo4J, among others, support the modern internet infrastructure. One of the benefits for companies using these maturing open source technologies is the ability to commercialize around a product that is already proven in the marketplace and has a larger contributor backing than might be otherwise available from a proprietary solution. And because of the large contributor base, open source software is often more robust than many in-house solutions developed merely as a means to an end.

Open source projects use copyright licenses to ensure their source code remains freely available and improvements to the software may be easily provided back to the open source community. Several well-known open source licenses have become staples for providing a legal framework for managing intellectual property contributions to open source projects. These are typically licenses that have been approved by the Open Source Initiative (OSI) as satisfying the criteria of its Open Source Definition.¹ Some open source licenses, such as the MIT, BSD, or Apache licenses, are "permissive" in allowing licensees to modify the software to create derivative works that may be licensed under different copyright licenses. The licensee is typically only required to include a copy of the license in the source code. Other open source licenses, such as the GNU General Public License (GPL), impose requirements that any distributions or derivative works based on the software must make the source code publicly available and under the same licensing terms. These licenses are sometimes called "copyleft."

Some in the open source community have expressed concern that existing open source licenses do not adequately protect the ability of copyright owners to monetize their software. While open source software is freely available, that does not mean it must be free of cost. But companies that develop open source software often find it difficult to sell their software when the source code is already publicly available. Companies instead may monetize hosting, consulting, or support services related to the software. Ideally, at least a portion of the proceeds from such efforts may be reinvested into further developing and improving the open source software and managing its open source project.

The proliferation of cloud-based services, such as software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS), has highlighted some of these monetization concerns. Cloud service providers that did not contribute to an open source project may freely obtain copies of the open source software, rebrand it as their own, and make it available as a cloud-based application for a fee. In such cases, the cloud service providers may not reinvest any of their proceeds into improving the software or managing the open source project. As a result, the companies generating income from the open source software are not necessarily the same companies that have invested, often substantially, in its development.

The Commons Clause was developed as a license condition that may be added to conventional open source licenses in response to the apparent inequities of having cloud service providers profit from freely obtained open source software, while the authors and contributors of that software may not receive any compensation for their work. The Commons Clause was intended to force a negotiation between the developers of open source software and "those who take predatory commercial advantage of open source development."² Those wishing to sell software licensed under the Commons Clause would be required to negotiate a separate, proprietary license with the open source software developers in order to rebrand and monetize software from their open source projects.

The Commons Clause became more prominent in the open source community in August 2018 when Redis Labs, the maker of the popular Redis in-memory database, adopted this clause as a contractual rider to the Apache 2.0 license for many of its Redis modules. These modules are software that enhance or add functionality to the core Redis database, which itself remained licensed under the permissive BSD license.³ Before the licensing change, the Redis modules were licensed under the Affero General Public License (AGPL),⁴ which was created to address open source software used for SaaS and other cloud-based applications. The AGPL intended to fix a perceived loophole in the GPL family of licenses because their source code disclosure requirements were only triggered by a distribution of the licensed software, and such a "distribution trigger" did not apply to cloud-based offerings that were never distributed. While the AGPL addressed source code disclosure requirements, it did not address the monetization concerns above.

At the time of the Redis modules' licensing change from the AGPL to Apache 2.0 with the Commons Clause, the cofounder and CTO of Redis Labs explained in a blog post:

Nevertheless, Redis Labs eventually stopped using the Commons Clause when licensing its Redis modules. This exemplary rise and fall of the Commons Clause is emblematic of the balance of advantages and disadvantages that such a licensing provision may provide. Here, we consider the Commons Clause and the competing policy issues that can arise when deciding whether to modify existing open source licenses.

The Commons Clause

The Commons Clause is a contractual rider that can be added to an existing open source license to restrict the sale of the licensed software. It was created in early 2018 as a result of coordination among several open source companies and was publicly contributed by FOSSA.⁶ With reference to an open source license ("License"), the clause states in relevant part:

Accordingly, the Commons Clause prohibits a cloud service provider from copying open source software, rebranding it, and selling a cloud-based product or service whose value derives entirely or substantially from the software's functionality. The clause similarly does not permit the cloud service provider to monetize "hosting or consulting/support services" for any product or service whose value derives entirely or substantially from the software's functionality. The cloud service provider, however, still may make the open source software available as a product or service, so long as it does not charge users to access the software's functionality.

The documentation for the Commons Clause makes clear that it is not compliant with the requirements of an open source license. For example, it adds a restriction on selling the licensed software, which fails to satisfy certain criteria in the OSI Open Source Definition.⁸ Instead, the Commons Clause transforms an open source license into a "source available" license that, while being more restrictive than a permissive license, attempts to provide more commercial freedom than a copyleft license. When the Commons Clause is added to an open source license, all permissions of the original license remain except for the ability to "Sell" the software as defined in the Commons Clause. For this reason, an open source license is not equivalent to that same license modified by the Commons Clause. In the case of Redis Labs, for example, the Redis modules were licensed under the Apache 2.0 license with a Commons Clause (a source available license), which is not the same as the Apache 2.0 license alone (an open source license).

Advantages of Adding the Commons Clause to Open Source Licenses

The Commons Clause was intended to prevent large cloud-based service providers from selling and benefiting from open source software without providing back to the open source community. While there are no inherent commercial restrictions on many permissive open source licenses, use of open source projects with little or no contribution back to the community is generally discouraged. Moreover, it is understandable that developers who provide open source software to the community want to protect their own intellectual property from being used in direct competition against them and seek a financial return on their investment from having developed the open source software.

The Commons Clause can be an effective tool to achieve these goals. It allows the copyright owners (typically developers) to maintain control over which companies may profit from use of the open source software's functionality. It also provides leverage for the copyright owners to initiate further negotiations with third parties, such as cloud service providers, who might want to sell the software as a service but are not active in the open source project.

Further, the Commons Clause's use of an underlying and accepted open source license gives the clause some inherent authority. Viewed in this way, the Commons Clause is simply a minor change to already well-accepted and well-established open source licenses. For example, software developers who are familiar with a conventional open source license, such as the Apache 2.0 license, will understand that all the provisions of that license still apply when it is combined with the Commons Clause, which merely adds another provision to the existing license. Thus, an Apache 2.0 license with the Commons Clause includes all the expected provisions of the Apache 2.0 license. Additionally, because the Commons Clause does not restrict the open source software other than the sale provisions, it still allows for distribution and modification of the source code and, more importantly, contribution from the community.

The Commons Clause also does not require each contributing developer or company to negotiate a separate license as might be necessary using a dual-licensing strategy or open core licensing model. Using a dual-licensing strategy, for example, a software product could be licensed under a proprietary license for cloud-based applications and under a separate open source license for other uses. In this case, each cloud service provider might be required to take a proprietary license to use the software in cloud-based offerings and provide compensation to the copyright owners, whereas other users of the software may be separately licensed under a permissive open source license, such as the Apache, MIT, or BSD licenses. In contrast, the Commons Clause may achieve a similar result without the administrative overhead and associated costs of managing and negotiating multiple licenses because it adds a sales restriction provision to a single open source license that may be used for all licensees.

The Commons Clause has a similar advantage relative to the open core model. Using this licensing model, a company may limit use of some of its software by cloud service providers by distributing a "core" software product under a permissive open source license although its supporting modules are licensed under a proprietary license. Like the dual-licensing strategy, the open core model could require more overhead and costs to manage and negotiate multiple licenses than modifying a single open source license with the Commons Clause for all licensees.

Finally, an open source license modified with the Commons Clause also may be preferable over the AGPL because the AGPL cannot prevent cloud service providers from selling functionality of open source software in a cloud-based application without compensating the open source community, either through remuneration or contributions back to the open source project. The AGPL also has been criticized for having its own ambiguities and concerns.⁹ Because many companies have not adopted the AGPL for these reasons, the Commons Clause may provide a better alternative for licensing open source software in cloud-based applications.

Disadvantages of Using the Commons Clause in Open Source Licenses

The Commons Clause has no shortage of detractors. Despite the advantages above, there are many aspects of the Commons Clause that have raised concerns with members of the open source community. Despite its stated goal of being a simple contractual rider added to well-known and well-understood open source licenses, the Commons Clause effectively transforms the license into a non-open source license. This can be particularly problematic where a project is chosen because it uses an OSI-approved license. Many companies, as a corporate policy, will only use open source software that has been licensed under OSI-approved licenses to ensure they are compliant with open source ideals. The Commons Clause, however, changes an OSI-approved license into a license that does not satisfy the OSI Open Source Definition due to the added sales restriction, which may jeopardize the adoption of such projects. Likewise, some developers may view the Commons Clause as abandoning the tenets of open source software and refrain from making contributions to such a project.

The similarity in naming of licenses using the Commons Clause also may be misleading or introduce confusion in the open source community. Using the Redis Labs license as an example, it may not be readily apparent that an "Apache 2.0 license with the Commons Clause" or "Apache 2.0 license modified by the Commons Clause" is not the same as the Apache 2.0 license. A developer may incorrectly assume by the similarity in their names that these licenses can be interpreted exactly the same as the Apache 2.0 license, which could lead to unintentional breaches of the sales restrictions added by the Commons Clause.

Further, because the Commons Clause adds a sales restriction to open source licenses, some critics express concern that this could be a slippery slope in which multiple possible contractual riders, or combinations of riders, could be added to the same open source license, resulting in different effective licenses with similar names. In addition to the Commons Clause, one can imagine additional proposed clauses for open source licenses, for example, to limit types of systems, forms of storage, methods of distribution, types of copying, and so forth. This could lead to a confusing open source landscape, where multiple different licenses have similar names. Suppose, for example, that clauses 1–5 were created as separate contractual provisions that each could be separately added to a conventional three-clause BSD license. In this example, it could be confusing to distinguish the BSD license modified by various combinations of the additional clauses, e.g., the BSD license modified by clauses 1, 3, and 4 versus the BSD license modified by clauses 2, 3, and 5, and so on.

Additionally, critics of the Common Clause argue that its language is ambiguous. The Commons Clause restricts sales for "a product or service whose value derives, entirely or substantially, from the functionality of the Software." While the Commons Clause documentation argues that "substantially" is a common legal term,¹⁰ it nonetheless fails to provide clear guidance on what is allowed or prohibited activity. For example, if a user pays a cloud service provider a flat subscription fee to access an SaaS application comprised of multiple software modules including one that is subject to a license with the Commons Clause, how is that subscriber fee allocated among all the modules' functionalities? Does it matter if the functionality subject to the Commons Clause is within the scope of the fee but never actually accessed by the user? Further, what if the fee is only for purposes of an internal or intracompany accounting and does not represent an arms-length sale between different parties?¹¹

The Commons Clause also is ambiguous in its prohibition against selling "hosting or consulting/support services related to the Software" for any product or service whose value derives entirely or substantially from the software's functionality. A plain reading of this provision suggests that a cloud service provider cannot host the licensed software for free and charge a fee for customer support or consulting relating to the software's functionality (e.g., how to use the software). The Commons Clause documentation refers to a discussion board suggesting that consulting may be permitted, but the language of the clause and the contents of that online discussion appear to suggest otherwise.¹²

Where Do We Go from Here?

The debate about the Commons Clause may continue in the open source community, as companies and developers struggle with finding a balance between the open and free software ideals at the foundation of the open source movement and the need for open source companies to monetize their innovations and thrive in the market. Companies and developers may continue having legitimate concerns about third parties taking their open source software and using it against them in a competitive marketplace.

The Commons Clause presents one potential solution for striking this balance but, as described, is not without its own complications. While the Commons Clause adds a sales restriction provision to known open source licenses to prevent undesirable, predatory use of code by cloud service providers, it also creates ambiguity in the licenses it modifies, and transforms established OSI-approved licenses into nonapproved, non-open source licenses.

Redis Labs' decision to adopt and then reject the Commons Clause demonstrates its uncertainties. As discussed above, Redis Labs originally licensed certain Redis modules under the AGPL, then converted these licenses to the Apache 2.0 with the Commons Clause. Redis eventually changed these licenses again, instead opting to create its own proprietary Redis Source Available License (RSAL). The RSAL is intended to grant equivalent rights as permissive open source licenses for most users, but restricts the licensed software from being used in a database, a caching engine, a stream processing engine, a search engine, an indexing engine, or an ML/DL/AI serving engine.¹³ Thus, Redis Labs changed strategies for preventing cloud service providers from monetizing its Redis modules by switching from a source available license with a sales restriction (Apache 2.0 with the Commons Clause), to a source available license with a field-of-use limitation (RSAL).

When Redis Labs first made the change to the Commons Clause, there were strong opinions in the open source community for and against its use.¹⁴ Ultimately, Redis Labs decided to move away from the clause, identifying the following considerations: the term "Apache2 modified by Commons Clause" caused confusion with some users, who thought they were only bound by the terms of the Apache 2.0 license; the term "substantial" in the Common Clause was unclear; and the Commons Clause restriction regarding "support" appeared to work against Redis Labs' intention of growing the ecosystem around Redis modules.¹⁵

While Redis Labs' adoption of the Commons Clause is generally viewed in hindsight as a case study in the problems of modifying OSI-approved open source licenses, the fundamental issues Redis Labs was trying to address remain. Companies that want to use and contribute to the open source community must continue to find ways to do so while protecting their investments and intellectual property. These motivations must be balanced against the risks that creating new licenses, or modifying existing ones, may alienate the open source community, stifle adoption, or prevent meaningful contribution to the project. While Redis Labs' experience with the Commons Clause may be a cautionary tale, it also exposes the many licensing-related choices companies and developers must make when working with open source software.

Footnotes

¹ See The Open Source Definition, Open Source Initiative, https://opensource.org/osd (last modified Mar. 22, 2007).

² Commons Clause, https://commonsclause.com (last visited Oct. 2, 2019).

³ See Yiftach Shoolman, Redis' License Is BSD and Will Remain BSD, Redis Labs (Aug. 22, 2018), https://redislabs.com/blog/redis-license-bsd-will-remain-bsd.

⁴  See Sarah Schlothauer, Is Commons Clause Open Source? Weighing In on the Redis License Change, JAXenter (Aug. 23, 2018), https://jaxenter.com/redis-commons-clause-open-source-148558.html.

⁵  Shoolman, Redis' License Is BSD, supra note 3.

⁶  See Salil Deshpande, Commons Clause Stops Open-Source Abuse, TechCrunch (Sept. 7, 2018), https://techcrunch.com/2018/09/07/commons-clause-stops-open-source-abuse; Commons Clause, GitHub, https://github.com/fossas/commons-clause (last updated Dec. 4, 2018).

⁷ Commons Clause, supra note 2.

⁸ See The Open Source Definition, supra note 1 ("The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources." (emphasis added)).

⁹  See Commons Clause, supra note 2.

¹⁰ Id.

¹¹ See Stephen O'Grady, Tragedy of the Commons Clause, RedMonk (Sept. 10, 2018), https://redmonk.com/sogrady/2018/09/10/tragedy-of-the-commons-clause.

¹² Commons Clause, supra note 2; see Tobias Davis, Preventing Specialized Consultants?, GitHub (Aug. 22, 2018), https://github.com/fossas/commons-clause/issues/4.

¹³ See Yiftach Shoolman, Redis Labs' Modules License Changes, Redis Labs (Feb. 21, 2019), https://redislabs.com/blog/redis-labs-modules-license-changes.

¹⁴ See Steven J. Vaughan-Nichols, Open-Source Licensing War: Commons Clause, ZDNet (Aug. 28, 2018), https://www.zdnet.com/article/open-source-licensing-war-commons-clause.

¹⁵ See Shoolman, Redis Labs' Modules, supra note 13.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.