Most people wouldn't know an open-source license from their driver's license. For those who work with open-source software, it's a different story. Open-source license fights can be vicious, cost serious coin, and determine the fate of multi-million dollar companies. So, when Redis Labs added a new license clause, Commons Clause, on top of Redis, an open-source, BSD licensed, in-memory data structure store, all hell broke loose.
Why? First, you need to understand that while you may never have heard of Redis, it's a big deal. It enables real-time applications such as advertising, gaming financial services, and IoT to work at speed. That's because it can deliver sub-millisecond response times to millions of requests per second.
But Redis Labs has been unsuccessful in monetizing Redis, or at least not as successful as they'd like. Their executives were discovering, like the far more well-known Docker, that having a great open-source technology did not mean you'd be making millions. Redis' solution was to embrace Commons Clause.
This license forbids you from selling the software. It also states you may not host or offer consulting or support services as "a product or service whose value derives, entirely or substantially, from the functionality of the software".
If that doesn't sound like open-source software to you, you have lots of company.
Simon Phipps, president of the Open Source Initiative (OSI), snapped on Twitter: "Redis just went proprietary, which sucks. No, this is not just 'a limitation concerning fair use,' it is an abrogation of software freedom."
In an email, Phipps added, "Adding a significant clause to an existing license that has been approved by OSI instantly renders it non-approved, and the text of the so-called 'Commons Clause,' which actually fences off the commons, is clearly intended to violate clause 1 of the Open Source Definition and probably also violates clauses 3, 5 and 6. As such adding this clause to a license would be a major abrogation of software freedom removing essential rights from any affected open-source community."
Software programmer Drew DeVault made his stance clear from his opening words: "Commons Clause will destroy open source." Commons Clause, he continued, "presents one of the greatest existential threats to open source I've ever seen. It preys on a vulnerability open-source maintainers all suffer from, and one I can strongly relate to. It sucks to not be able to make money from your open-source work. It really sucks when companies are using your work to make money for themselves. If a solution presents itself, it's tempting to jump at it. But the Commons Clause doesn't present a solution for supporting open-source software. It presents a framework for turning open-source software into proprietary software."
Bradley M Kuhn, president of the Software Freedom Conservancy and author of the Affero General Public License, blogged, "This proprietary software license, which is not open source and does not respect the four freedoms of free software, seeks to hide a power imbalance ironically behind the guise 'open source sustainability.' Their argument, once you look past their assertion that the only way to save open source is to not do open source, is quite plain: If we can't make money as quickly and as easily as we'd like with this software, then we have to make sure no one else can as well."
Andrew 'Andy' Updegrove, a founding partner of Gesmer Updegrove, a top technology law firm, and open-source legal expert, found it no surprise that many open-source supporters hate Commons Clause. He rejects the conspiracy theory, "that the Commons Clause will be some sort of virus that will deprive innocent developers of the ability to make a living, and will persuade businesses owners to avoid buying or using code that has any commons clause in it."
Updegrove believes this is because Heather Meeker, a partner at O'Melveny law firm who drafted it, "is a respected attorney and long-term participant in open-source legal circles, so IMHO the conspiracy theory can be ignored. Note also that Kevin Wang [founder of FOSSA] and Heather have both offered the clause as text to initiate a discussion, and not something to be wholesale adopted as it stands."
That didn't stop Redis Labs, which is applying Commons Clause on top of the Apache license, to cover five new Redis modules. Redis is doing this, said its co-founder and CTO Yiftach Shoolman in an email, "for two reasons -- to limit the monetization of these advanced capabilities by cloud service providers like AWS and to help enterprise developers whose companies do not work with AGPL licenses."
On the Redis Labs site, the company now explains in more detail that cloud providers are taking advantage of open-source companies by repackaging their programs into competitive, proprietary-service offerings. These providers contribute very little -- if anything -- back to those open-source projects. Instead, they use their monopolistic nature to derive hundreds of millions of dollars in revenues from them.
Redis Labs contends that "most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis Labs is leading and financing the development of open source Redis and deserves to enjoy the fruits of these efforts." Shoolman insisted that "Redis is open source and will remain under a BSD license."
Salvatore Sanfilippo, Redis' creator, added the change just "means that basically certain enterprise add-ons, instead of being completely closed source as they could be, will be available with a more permissive license," Commons Clauses with Apache.
Software Freedom Conservancy executive director Karen Sandler isn't so sure. Sandler emailed that Commons Clause "highlights the fundamental problems connected to the wide adoption of non-copyleft licenses, but I think it doesn't really solve the problem that it seeks to solve. What we really need is strong copyleft licenses where the copyrights are held diversely by individuals and functional charities to make sure that software remains free and that societally we have the rights we need to have confidence in our software in the long run."
In an email, Wang defended Commons Clause as "mostly used to temporarily transition enterprise offering counterparts of open-source software projects to source-available". Wang continued: "Open-source software projects are mainly funded by a proprietary offering/service counterparts. Anything to help this layer monetize is good -- the fate of the OSS is directly funded by it.
"The world has changed a lot and the open-source software/cloud ecosystem has a lot too," Wang added. "The Open Source Definition is an immensely [valuable] set of ideals, but maybe it's outdated to the modern state of the world. ... Licensing follows intent, and I certainly don't think the clause inspires people to close their source. But sometimes people need to change their license."
Be that as it may, Updegrove wrote Commons Clause is "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."
But, "adding the Commons Clause to an open-source license makes it no longer an open-source license," Updegrove added. And, were the Commons Clause to catch 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, it's 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."
That's a big reason, Updegrove wrote, why "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 20 years -- an eternity, in open-source history."
Therefore, Updegrove sees Commons Clause as 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."
The result? Companies and programmers veering away from using any Commons Clause licensed software. That was not its creators' intent, but it's a realistic concern.
Updegrove adds, "Speaking as a lawyer, the fact that someone can still charge for a product that includes Commons Clause software so long as the value does not 'derive[s], entirely or substantially, from the functionality of the software' is certain to invite disputes. The most obvious is what does 'substantially' [mean]? There is no bright-line for guidance."
Georg Greve, co-founder and president at Vereign, a blockchain-secured communication company and founder of Free Software Foundation Europe, also worried, "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."
Still, Updegrove thinks Commons Clause may be "a useful addition to the licensing menu, but not one that will be appropriate for use in all situations. ... Developers should be clear in advance what their goals are when they're put their fingers to their keys. Commons Clause-licensed software is not likely to get the same amount of reuse as might otherwise be the case."