Redis modules and the Commons Clause

The "Commons Clause", which is a condition that can be added to an open-source license, has been around for a few months, but its adoption by Redis Labs has some parts of the community in something of an uproar. At its core, using the clause is meant to ensure that those who are "selling" Redis modules (or simply selling access to them in the cloud) are prohibited from doing so—at least without a separate, presumably costly, license from Redis Labs. The clause effectively tries to implement a "no commercial use" restriction, though it is a bit more complicated than that. No commercial use licenses are not new—the "open core" business model is a more recent cousin, for example—but they have generally run aground on a simple question: "what is commercial use?"

Redis is a popular in-memory database cache that is often used by web applications. Various pieces of it are licensed differently; the "Redis core" is under the BSD license, some modules are under either Apache v2.0 or MIT, and a handful of modules that Redis Labs created are under Apache v2.0, now with Commons Clause attached. Cloud services (e.g. Amazon AWS, Microsoft Azure, Google Compute Engine, and other smaller players) provide Redis and its modules to their customers and, naturally, charge for doing so. The "charge" part is what the adoption of the clause is trying to stamp out—at least without paying Redis Labs.

The clause itself is admirably brief, just three paragraphs that are meant to be tacked on as an additional restriction to a permissive license, such as the Apache License 2.0. It overrides the license text to prohibit selling the software and defines what it means by "sell":

One can immediately see some "wiggle room" that will have to be evaluated by lawyers (and, eventually, judges) to define various pieces of that sentence. "Value derives", "entirely or substantially", and even "from the functionality" are all open to interpretation. The Redis Labs announcement tries to make it clear what is being targeted:

That provides some of the reasoning behind the move, but it may make others who are outside of the target zone leery of using the Redis modules that are now covered by the clause. The "this must be changed" wording about the BSD license may also make some worry about the license for the Redis core (which remains under the BSD without the addition of the clause) down the road. There is a contributor license agreement [PDF] for at least some contributions to the project, which might allow relicensing if Redis Labs—or some company that buys it—decides that is in its interest. It should be noted that the agreement allows Redis Labs to make money on any contributions made under it, which is the norm for such things but might be seen as a tad hypocritical. The Redis Labs page clearly disclaims the possibility of changing the license, though that assurance may not be ironclad:

So it is not quite a "no commercial use" clause, at least as interpreted by Redis Labs, but that brings problems of its own and may provide ways for the cloud providers to evade the clause entirely. As both the Commons Clause and Redis Labs pages clearly note, adding the clause to an open-source license does not result in something that falls under the Open Source Definition. That means that the Redis modules in question are no longer open source, thus Linux distributions and others may not be willing or able to distribute them any longer. The issue has already been raised for Fedora; Debian is looking into it as well and others will likely follow. That alone shows some of the collateral damage that can occur when licenses are changed this way.

Redis Labs is not alone in using the clause for licenses; other projects are adopting it as well. Neo4j Enterprise has added the clause to the AGPLv3 and Dgraph has switched from AGPLv3 to Apache v2.0 with the Commons Clause, which it called a move to a "liberal license". The clause is addressing a real problem, but the cure could be worse than the disease.

Permissively licensed code (e.g. BSD or Apache v2.0) is subject to the "abuse" that is being claimed—in fact, that is much of the point of those licenses. Permissive licensing means that the code can be changed and distributed without making any of those changes public. But copyleft-style licensing wouldn't necessarily help the problem that Redis Labs is complaining about. Large (or small) cloud providers probably do not make substantive changes to the Redis modules in question—if they do, it seems likely they would be unfazed by having to release the changes if they were required to. The AGPL was meant to help with this "as a service" loophole in the GPL, but it is not meant to stop people from running the software any way they want—quite the opposite.

And that is really the crux of the matter. Being a part of the open-source world means accepting some things, including that code you release under those terms might be used in ways you don't like. It may also be used in ways that make money for someone else. It is part and parcel of what open source is all about.

There was a time when licenses with no commercial use clauses were relatively common. Before the turn of the century or thereabouts, lots of software was distributed under those terms (e.g. Linux 0.01, the Majordomo mailing-list manager). That was an accepted practice, mostly because people weren't really paying that much attention to the terms under which all of this free (as in beer) software was being made available. That changed along the way; as it did, the perils of no commercial use clauses became more apparent.

Redis Labs has tried to clarify what it means by selling the modules and others have tried to do so with their licenses as well (e.g. the NonCommercial interpretation from Creative Commons). But a restriction of that sort, with all of its various gray areas, rarely actually hits the target sought. It is the smaller cloud providers that will be affected by this move more than Amazon, Google, or Microsoft will be. It will also split off distributions and users that are not willing to get involved with non-open-source software. Restricting the use cases for a piece of software just makes it harder to actually use that software because no one truly knows which uses are blessed and which aren't.

One of the reasons that Redis is open source is presumably for attracting a community of users, developers, and others who will help broaden the reach of the project. Redis Labs appears to want to have its cake and eat it too. Perhaps this move will give the company some time to find a way to appease its investors, but it is not a community move—and the community has noticed. A look at threads on Hacker News or Reddit will show that many are not pleased with this change. Not surprisingly, longtime free-software advocate Bradley M. Kuhn has also criticized the clause.

The clause was written by Heather Meeker, who has been involved in multiple open-source disputes (on both sides) along the way. It is being pushed by FOSSA, which is a company that provides license-compliance tools. While the problem of financially supporting open-source development is real, and that is what FOSSA/Commons Clause are trying to promote, doing so with a clause restricting the scope of open-source licenses is a non-starter.

Buried in the text of the FAQ at the Commons Clause site may be a clue to what the real goal is. In two places, it mentions conversations that it is hoping will start:

These conversations may truly be the goal, though it may be more difficult to have that first conversation with those that have been labeled as "predatory". The latter conversation is welcome, though it is hard to see licensing as much of a tool to use in pursuit of that goal. Smaller open-source projects (or even critical infrastructure projects like OpenSSL prior to Heartbleed) often struggle to make ends meet, which is a shame. Finding better ways to fund open-source development (for projects small and large, company-backed or not) would be fabulous; changing licenses in a way that violates one of the core tenets of open-source software seems like the wrong way to go about it.