Why Open Source Licenses with a Commons Clause May Become Less Common

• Author: Nicholas D. Petrella - Stephen E. Kabakoff
• Position: Nicholas D. Petrella is an associate at Finnegan in Palo Alto, California. He specializes in litigation, client counseling, and patent prosecution. He can be reached at nicholas.petrella@finnegan.com. Stephen E. Kabakoff is a partner at Finnegan in Atlanta, Georgia. He specializes in licensing, litigation, client counseling, and patent...
• Pages: 34-64

Published in Landslide® magazine, Volume 12, Number 2, a publication of the ABA Section of Intellectual Property Law (ABA-IPL), ©2019 by the American Bar Association. Reproduced with permission. All rights reserved.

This information or any portion thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.

Why

Open Source

Licenses

with a

Commons

Clause

May Become

Less Common

By Nicholas D. Petrella and Stephen E. Kabakoff

O

pen source software is founded on the

principle that it should be made freely

available for anyone to use, distrib-

ute, or improve. Promotors of open

source ideals believe that freely avail-

able source code will encourage more

extensive distribution and use of the

code, spurring further innovations and

improvements. Given the complexi-

ties of today’s software applications,

and typical modular or object-based

designs, open source software pro-

vides signicant efciencies to

developers who can focus their efforts

on core products and technologies

without reinventing the wheel for cer-

tain 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, Cassan-

dra, Redis, MongoDB, and Neo4J, among others, support the

modern internet infrastructure. One of the benets for com-

panies 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 back-

ing 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

Published in Landslide® magazine, Volume 12, Number 2, a publication of the ABA Section of Intellectual Property Law (ABA-IPL), ©2019 by the American Bar Association. Reproduced with permission. All rights reserved.

This information or any portion thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.

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.3 Before the licens-

ing change, the Redis modules were licensed under the Affero

General Public License (AGPL),4 which was created to address

open source software used for SaaS and other cloud-based

applications. The AGPL intended to x a perceived loophole

in the GPL family of licenses because their source code disclo-

sure 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:

Cloud providers have been taking advantage of the open source

community for years by selling (for hundreds of millions of

dollars) cloud services based on open source code they didn’t

develop (e.g. Docker, Spark, Hadoop, Redis, Elasticsearch and

others). This discourages the community from investing in devel-

oping open source code, because any potential benet goes to

cloud providers rather than the code developer or their sponsor.5

Nevertheless, Redis Labs eventually stopped using the Com-

mons Clause when licensing its Redis modules. This exemplary

rise and fall of the Commons Clause is emblematic of the bal-

ance 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.6 With reference to an open

source license (“License”), the clause states in relevant part:

Without limiting other conditions in the License, the grant

of rights under the License will not include, and the License

does not grant to you, the right to Sell the Software.

For purposes of the foregoing, “Sell” means practicing any or all

of the rights granted to you under the License to provide to third

parties, for a fee or other consideration (including without limita-

tion fees for hosting or consulting/support services related to the

Software), a product or service whose value derives, entirely or

substantially, from the functionality of the Software. Any license

Nicholas D. Petrella is an associate at Finnegan in Palo Alto,

California. He specializes in litigation, client counseling, and patent

prosecution. He can be reached at nicholas.petrella@nnegan.com.

Stephen E. Kabakoff is a partner at Finnegan in Atlanta, Georgia.

He specializes in licensing, litigation, client counseling, and patent

prosecution. He can be reached at stephen.kabakoff@nnegan.com.

software may be easily provided back to the open source com-

munity. Several well-known open source licenses have become

staples for providing a legal framework for managing intellec-

tual 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 De-

nition.1 Some open source licenses, such as the MIT, BSD, or

Apache licenses, are “permissive” in allowing licensees to mod-

ify 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 con-

cern that existing open source licenses do not adequately

protect the ability of copyright owners to monetize their soft-

ware. 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 nd it difcult to sell

their software when the source code is already publicly avail-

able. 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 soft-

ware and managing its open source project.

The proliferation of cloud-based services, such as soft-

ware-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 man-

aging 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 sub-

stantially, in its development.

The Commons Clause was developed as a license condi-

tion that may be added to conventional open source licenses

in response to the apparent inequities of having cloud service

providers prot 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 devel-

opers of open source software and “those who take predatory

commercial advantage of open source development.”2 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