Almost nothing inspires a spirited discussion among the open source faithful as much as introducing a new open source license, or a major change in an existing license’s terms. In the case of version 3 of the GPL, the update process took years and involved dozens of lawyers in addition to community members. So, it’s no surprise that the pot is already boiling over something called the “Commons Clause.” How energetically? Well, one blog entry posted yesterday was titled The Commons Clause Will Destroy Open Source. The spark that turned up the heat was the announcement the same day by RedisLabs that it was adopting the license language.

The clause itself is short (you can find it here, together with an explanatory FAQ). It was drafted by Heather Meeker, an attorney with long open source involvement, in conjunction with “a group of developers behind many of the world’s most popular open source projects.”

It’s also simple in concept: basically, it gives a developer the right to make sure no one can make money out of her code – whether by selling, hosting, or supporting it – unless the Commons Clause code is a minor part of a larger software product. In one way, that’s in the spirit of a copyleft license (i.e., a prohibition on commercial interests taking advantage of a programmer’s willingness to make her code available for free), but it also violates the “Four Freedoms” of Free and Open Source software as well as the Open Source Definition by placing restrictions on reuse, among other issues.

That’s the first cause of unhappiness: adding the Commons Clause to an open source license makes it no longer an open source license. Second, if the Commons Clause catches on, it could give rise to an unwelcome trend. The wide proliferation of licenses in the early days of open source was unhelpful and a cause of ongoing confusion and complexity, since not all licenses were compatible with other licenses. That means that before any piece of open source code can be added to a code base, its necessary to determine whether its license is compatible with the licenses of all other software in the same product. That’s a big and ongoing headache.

Partly in response to this proliferation of licenses, Bruce Perens and Eric S. Raymond created the Open Source Definition and the Open Source Initiative so that there would be a central reference point and authority to determine what was and was not an “Open Source License.” That definition and process has held now for twenty years – an eternity, in open source history.

Over time, the number of additions to the list of approved licenses has dramatically decreased, and many licenses already on the list have fallen into disuse.  Today, the vast amount of OSS is released under just five licenses. Introducing any new license variant – and especially a restrictive one – is therefore a step backward from a process point of view. Worse, it would be a very disturbing development if the release of the Commons Clause inspired more people to come up with their own license “extensions,” especially if they are also not compliant with the Open Software Definition and the Four Freedoms.

There are other concerns as well. Some arise from the language of the clause, and particularly this part:

…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 limitation 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.

The word that causes the most concern is “substantially.” Without a bright-line test, it will be impossible to tell when one can and cannot use the code in a commercial product (or host or support one). And note that the test is functionality, rather than lines of code. How do we judge functionality? Are some functions more important than other ones?

And so on. Without a clear understanding of what “substantial” means, software vendors, hosts and consultants will be reluctant to want to deal with software that includes any meaningful amount of Commons Clause software. This is ironic, because one reason given in the FAQ for the development of the Commons Clause is that certain terms of an earlier OSI-compliant license, the AGPL, left “many potential users … more confused and cautious about using AGPL code” than non-compliant licenses.

The inclusion of the Commons Clause in a software product can also lead to some novel results. For example, someone hosting a free copy of a software product containing a “substantial” amount of Commons Clause software on their own server for their internal use would not be in violation of its terms. But a Cloud provider hosting the same software for the same customer would be violating the copyright of the developer. And in either case, a third-party service provider might engage in conduct that violates the license. Adding yet another way for innocent violations of contract terms seems like a bad development.

It will also increase the level of paranoia of software vendors who are already having a hard time policing employees who are all too quick to grab a piece of software from GitHub to fill a gap in a program under development without worrying about compatibility issues.

And then there are the commentators (like Drew DeVault, in the blog entry referred to above) who have expressed more serious concerns, viewing the Commons Clause as some kind of viral plot intended to scare people away from using OSS at all, and or as a threat with the potential to rob open source developers of the ability to make a living out of their open source skills. George Greve expressed a similar concern in a Tweeted list of potential concerns that included this one:

Overall it seems purposefully vague & misleading, probably overreaching and terribly one-sided to establish Fear, Uncertainty and Doubt for any professional use of software licensed under it while making it terribly easy to “accidentally” incorporate such components.

The Software Conservancy is also unimpressed. An August 22 blog post by Bradley M. Kuhn includes the following:

The so-called “Commons Clause” purposely confuses and conflates many issues. The initiative is backed by FOSSA, a company that sells materiel in the proprietary compliance industrial complex. This clause recently made news again since other parties have now adopted this same license.

So, what problem is the Commons Clause trying to solve? Somewhat counterintuitively, given the fact that the clause prohibits the monetization of software, the FAQ gives this answer:

The Commons Clause was intended, in practice, to have virtually no effect other than force a negotiation with those who take predatory commercial advantage of open source development.

Presumably, what this means is that the developer of the code can first make the code visible under the Commons Clause for study purposes. Anyone that wants to include the code in a free product is free to do so under the Commons Clause and the Apache 2.0 license, with which it was paired by Meeker. But anyone wishing to sell or license a product with a “substantial” amount of Commons Clause – or even to host a free copy of the product – would need to obtain a paid license from the developer.

This economic focus helps explain an otherwise seeming contraction: under the Commons Clause, you could have a program that was made up entirely of Commons Clause software and be able to monetize it, so long as no single package was “substantial.” In other words, it appears we’re talking about dollars here, and not free software philosophical convictions.

Where this will all shake out will be interesting to observe. How much notice and debate the Commons Clause inspires will have a lot to do with how many developers opt to employ it. But either way, it seems likely we’ll all be reading about it quite a bit more.