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

AuthorNicholas D. Petrella - Stephen E. Kabakoff
PositionNicholas 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...
Pages34-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

To continue reading

Request your trial

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT