http://ipkitten.blogspot.com/2019/09/commons-clause-in-open-source-licences.html
Accommodation of new business models and technological advances has fundamentally disrupted the open source industry. Unlike on-prem solutions, which are installed in a user environment, cloud-based software remains hosted on the vendor’s servers and is accessed by users through a web browser. Because cloud-based offerings do not involve software distribution, the copyleft effect of open source licences is not triggered.
Large cloud providers use their market power and infrastructure to generate significant revenues by offering proprietary services around successful open source projects, thus depriving such projects of an opportunity to commercialise similar services.
| This feline is ever hopeful about his licensing experiments |
This has led to various licensing “experiments”, one of which is imposing additional restrictions on the use of open source software. Licence modifications effectively mean new licences being added to the open source ecosystem, a phenomenon known as licence proliferation.
For example, IPKat has writtenabout MongoDB’s attempt to close the GNU Affero General Public License loophole for cloud-based services by issuing a Server Side Public Licence. For its Confluent platform, Confluence movedfrom Apache 2.0 to a Confluent Community License, which allows users to freely download, modify, and redistribute the code (very much like Apache 2.0 does), but it does not allow provision of the software as a SaaS offering.
In the context of another cloud business model, Redis Labs came upwith their own Redis Source Available License as a “modern variant” of open source licensing. Not to be outdone, Cockroach Labs choseMariaDB’s Business Source License for its CockroachDB and included a restriction to “offer a commercial version of CockroachDB as a service without buying a license” but by also adding the following limitation:
In order to continue building a strong open source core, this restriction has a rolling time limit: three years after each release, the license converts to the standard Apache 2.0 license. Our goal in relicensing with a time restriction is two-pronged: to simultaneously create a competitive database as a service (DBaaS) while also providing a guarantee that the core product will become pure open source.
What is Commons Clause?
Against this backdrop, this post turns to the Commons Clause, a licence condition that may be added to an existing open source licence allowing all original permissions contained in such licence, except selling the software. It also prohibits hosting or offering consulting or support services as “a product or service whose value derives, entirely or substantially, from the functionality of the software” (emphasis added). Technically speaking, the resulting licence as a whole is not an open source, but rather a source-available licence. [Software licences may be deemed open source only when they fit the Open Source Definition and are approved by the Open Source Initiative.]
As the FAQ document explains, the rationale of the Commons Clause is to incentivise investment in open source projects by preserving the rights of developers to benefit from commercial use of their work and, as well, to protect open source community from “those who take predatory commercial advantage of open source development”, but do not contribute anything back. The Commons Clause allegedly does not restrict code sharing or development. It is less permissive than non-copyleftopen source licences, such as Apache, BSD, and MIT, and allows greater commercial freedom than reciprocallicences, such as AGPL or GPL.
A blessing in disguise?
Indeed, Commons Clause is drafted in the spirit of a copyleft licence, thereby aiming to protect source code availability. Prima facie, therefore, it seems a better alternative to proprietary licensing and closed source, but is it really?
There are a few inherent problems in the Commons Clause. First, a concept of a “substantial derivative” is vital in determining the scope of the license, but it is not defined. The FAQ suggests that it should be interpreted as restricting one from “[s]elling a product which adds only an insubstantial value to the software — such as changing the product name, changing some API or function names”. This may be helpful in a handful of use cases, but overall it seems open ended, vague and uncertain.
Another difficulty stems from the licence construct itself. Combining a known and trusted open source license with a proprietary (i.e., non-open source) rider with unknown implications is set to cause user confusion as to licence compliance obligations as well as conforming with internal third party software usage policies.
The third argument against Commons Clause is eloquently madeby the open source community. Commons Clause attached to the open source projects is likely to discourage the community from contributing to such projects because the new products made [Commons Clause is not retroactive] can only be monetised by the licensing entity.
Whether the benefits of employing the Commons Clause outweigh the potential risks is likely to invoke a case by case analysis. The community consensus on the four software freedoms [the freedom to run the program for any purpose, the freedom to modify it for private or public use, the freedom to make copies and distribute the program and its derivatives] is under continuous pressure for modification. Indeed reshaping the portfolio of freedoms may not necessarily be a threat to open source as we know it, but rather an evolution thereof.
As Heather Meeker, the drafter of the Commons Clause, has noted, the choice is often between the full proprietary route and a source-available licensing. By choosing the latter, we may preserve at least some of the freedoms.
Image credits: The Cat Experiment
Content reproduced from The IPKat as permitted under the Creative Commons Licence (UK).