A link was sent my way to the Redis Labs “Commons Clause”, which definitely raised my eyebrow. While the Commons Clause, as defined by Redis Labs, does not apply to Redis itself, it is applied to their non-closed source software.
The relevant and interesting text of the “Commons Clause” is as follows:
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 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.
There have been a number of perspectives I have now read from VM Brasseur, Drew DeVault, and Software Freedom Conservancy. Additionally, Redis Labs has responded to many of the concerns and criticisms.
As I was discussing this with my colleague Mo, his questions provided a useful foil for why those who don’t live and breathe the nuance between “open source”, “free software”, and “source-available” should be interested in this discussion around Redis Labs’ “Commons Clause.”
Before we go much further, here’s a quick summary of (generalized) terms which are important for this discussion:
- open source: “you can do whatever you want with this code, but it has to retain my copyright.”
- free software “you can do lots with this code, but any changes you make have to also be made available to whomever you give or sell it to.”
- source available “you can look at this source code, but for the most part don’t expect to be able to give it or sell it to anybody.”
- proprietary “if you somehow get a hold of this code, which we consider a trade secret, we’ll probably sue your pants off.”
From my perspective, there are two significant problems with the Commons Clause which merit more analysis: first the disingenuous logic being used as a justification, and more importantly the apparent attempt to monopolize all value realized in the ecosystem around a piece of software.
Disingenuous Logic
As a long time supporter and contributor to free and open source software, the most fundamental problem with the Commons Clause, from my perspective, is how absolutely disingenuous the justification is. From “Why did Redis Labs adopt it”:
However, today’s cloud providers have repeatedly violated this ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings. Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them. Already, this behavior has damaged open source communities and put some of the companies that support them out of business.
AWS and Azure provide a scalable hosted version of Redis, which is BSD licensed and open source. Redis Labs is changing their other code to “source available”, none of which AWS and Azure (to my knowledge) use, because Redis is open source.
What adds insult to injury is that Redis was not developed by Redis Labs. Significant funding for the development of Redis was provided by Pivotal and VMWare, with additional third-party contributions.
I almost cannot believe the boldness of this position. In response to AWS and Azure making money on providing a service based on open source software, a company, which exists entirely thanks to development of open source software funded by other parties, has decided all subsequent code developed by them shall only be “source available.” The logic doesn’t make any sense to me.
However, Redis Labs is wholly justified to license their software in whatever manner they deem fit.
Let’s just not pretend it’s about Redis, but rather the business’s failure to realize value in these other pieces of software.
Monopoly on realized value
The second problem with the Commons Clause is that it attempts to dictate an absolute monopoly on any value realized from these other pieces of software while masquerading as “open source.”
Based on my read of the following section of the Commons Clause, this dictates a monopoly on any value realized around any of these pieces of 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.
If I am understanding this correctly, an organization which provides any support services for a fee which orient around ReJSON for example, would be in violation of this license. How this would be enforceable is beyond my legal understanding but I presume that Redis Labs would have to prove that the value was derived “substantially” based on ReJSON. Though the license provides no clarity for what potential remedies might exist for my hypothetical ReJSON support company, other than “stop existing.”
I wonder what legal liability I might have if I sold a magazine called “Redis Today” which wrote about ReJSON, Redis Graph, Redisearch, and others, and then sold that through the Kindle store.
The closest potentially related license which comes to mind was the old Trolltech license applied to Qt which forbade distributing the software commercially without a license. Since that involved the act of distribution of somebody else’s (Trolltech’s) code, the license enforceability makes sense to me. Attempting to enforce a monopoly on any and all value associated with a piece of software, regardless of whether the software itself was distributed, seems absurd and borderline malicious.
I have never seen anythinig quite like this before.
A path forward
In my discussion with Mo, he raised a good question which deserves an answer, paraphrased: What should a company, which has invested heavily in open source, do when a vendor like AWs significantly erodes the potential to realize value from that company’s work?
While I don’t think Redis Labs has a leg to stand on in this discussion, I do think Elastic is a perfect example of this. Formerly known as Elasticsearch, Elastic has invested millions of dollars in the development of Elasticsearch which AWS hosts and provides to their customers for a fee, ostensibly with none of that money flowing back to Elastic. In this scenario AWS is not doing anything morally or legally wrong. Elasticsearch is licensed under the Apache license (open source) and has not only seen significant contributions from outside Elastic as a result, but has also seen widespread adoption.
That user adoption may or may not be providing some realization of value for Elastic the company, but it’s hard to tell from an outside perspective. It is safe to say that Elastic receives some value from Elasticsearch, even if others are making money off of it.
Which leads to the most important set of questions:
- Is that fair?
- How much would be fair for Elastic to receive?
- What are fair options for Elastic to receive more value?
I believe it is certainly fair. I don’t buy the “violation of the open source ethos” argument proffered by Redis Labs which is, frankly, bullshit. The open source ethos, or free software ethos, is defined by the licenses we chose when we make our source code available on the internet, or to our customers. On top of that, there are numerous free and open source cultural norms, but those are almost as varied as the number of projects floating around.
With regards to how much would be fair for Elastic to receive, for an Elasticsearch service hosted, supported, and made available by AWS, that gets to be more complex. It would be unfair to AWS in this example to presume that they have not also invested in the development and operation of this service based on Elasticsearch. Therefore AWS is also entitled to realize value from their investment.
While Elasticsearch is open source, I think it would be shrewd for Elastic to utilize their ability to support Elasticsearch and ownership of the trademark to negotiate a deal with a cloud vendor to:
- Ease support burden for the cloud vendor and provide strong levels of custom integration
- Implement a certification program which would require involvement from Elastic to allow the service to be called “Elasticsearch.”
While I’m a supporter of free software, at no point would I suggest re-licensing to a copy-left license like the GPL or AGPL, as neither would help the company realize additional value in my opinion. Copy-left licenses are designed to ensure access to the software by the user and ensure derivative works remain free. They alone are not sufficient to help squeeze more value out of a piece of software from a company like Elastic.
With GPL or AGPL licensed code, there’s also a perspective many smart people seem to have which is that those licenses are not suitable here. As Redis Labs claims: “We received requests from developers at large enterprises to move to a more permissive license, because the use of AGPL was against their company’s policy.” I don’t buy this justification, mainly because of the use of a “Contributor License Agreement” (CLA) with Redis Labs software. I first became aware of CLAs with Trolltech’s Qt, which typically grant the organization copyright thereby allowing the organization to re-license the software as they see fit.
Why even open source?
There are many benefits to producing corporate-supported free or open source software, including:
- It’s good marketing. Companies and developers are more likely to experiment with and adopt the software. Most organizations seem to have become increasing loathe to buy single-vendor pieces of software (SaaS offerings excluded) which follow the traditional proprietary software licensing schemes.
- External contributions become possible allowing the software to improve without the company directly funding that improvement.
- Increased market pressure in the problem domain which discourages others from creating competing products or projects. For example, it’s very difficult to imagine another solution to the problems which Hadoop solves, since Hadoop already exists in the market, and is widely adopted and open source. Thereby providing HortonWorks and Cloudera with a competitive advantage: any new player has to play on their turf.
There are certainly trade-offs with opening source code up, but at the end of the day, if you want to have a monopoly on value realized from the software you create: make it proprietary.
Many companies very successfully do this, likely far more than ones who try to squeeze revenue out of free and open source software.
The Commons Clause is an attempt to maintain all of the perceived benefits of having open source software, and all the benefits of proprietary software, while avoiding some of the potential downsides of going proprietary such as potential forks and the subsequent loss of control.
I don’t think it’s possible to have it both ways here.
I cannot imagine why anybody would bother contributing to any of these pieces of software, The bad taste this move is leaving in the mouths of many has damaged both the Redis Labs, and by proxy, the Redis brand. It is unclear what market value those perceptions hold, but I’m certain they’re non-zero.
Building any business is difficult, all the logistics and challenges of building a product aside, finding product/market fit is difficult. Building a business around free and open source software is also difficult, but in different ways than most seem to appreciate. My employer, CloudBees is one such company endeavoring to build around open source software and we have frequent discussions about what is reasonable for the Jenkins community and what is reasonable for the business. Suffice it to say, there’s always going to be a healthy tension. Some of that healthy tension we discussed in this presentation given by my colleague Liam Newman, worked on by Liam, Kohsuke Kawaguchi, and myself.
Overall I think free and open source software is incredibly important. As a consumer of software, I’m far more likely to adopt it if for no other reason than I know that if a business disappears tomorrow, I will still have something left to work with.
For the businesses which build and support free and open source software, there is no silver bullet but I firmly believe that there is more than enough room in the market building a number of successful businesses around all the different facets of software and its adoption.