Redis & Open Source — The PR Perspective
As you might have heard, the popular in-memory data store Redis is currently dealing with some controversial licensing discussions. This started after Redis Labs announced that they would change the license of some of their previously AGPL-licensed Redis modules to Apache + Commons Clause. This license, quote, “does not grant to you, the right to Sell the Software”, which is its fundamental difference from licenses such as the liberal (and Open Source) BSD license, or from AGPL.
However, Redis itself, maintained by antirez and sponsored by Redis Labs, will remain BSD-licensed.
As to the why of the modules’ licensing changes, Redis Labs explain the motivation behind the recent licensing move with the following:
Today’s cloud providers have repeatedly violated this [open source] ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings. […] Already, this behavior has damaged open source communities and put some of the companies that support them out of business.
So this makes it quite clear—Redis Labs, as a company, want to ensure their own profitability. This is a natural thing for them to do. And arguably, it also ensures long-term financing of further Redis development.
Of course, the announcement was shared to Hacker News, and the fact that Redis itself remains FOSS was buried among heated discussions about general FOSS licensing issues. All in all, it seems like Redis Labs’ message did not reach many people the way it should have.
Because of that, this post is not supposed to be about the changes itself. You are free to like or not like them. But in any case, I think that we can learn a lot about communicating important changes like these. Following the events, I observed three major points concerning communication:
1. Clarity of initial announcement
While people reading the whole initial announcement (version from August 21 on archive.org) would probably have understood it correctly, many others likely just skimmed it and missed this quote hidden in the third paragraph:
The Redis core is, and always will remain, an open source BSD license.
And in the paragraph above, Redis Labs wrote the following:
Today, 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’ permissive BSD open source license allows them to do so legally, but this must be changed. […] Consequently, we decided to add Commons Clause to certain components of open source Redis. Cloud providers will no longer be able to use these components as part of their Redis-as-a-Service offerings, but all other users will be unaffected by this change.
The highlighted sentence very much reads like the license of Redis itself was going to be changed, and I can imagine many readers angrily going back to Hacker News after reading this sentence. Moreover, “certain components of open source Redis” leaves the reader unsure about what kind of components this refers to (for example, redis-cli could be thought of as a Redis component as well).
In fact, if you check the diff between the inital announcement and the updated page as of August 25, 2018, you can see that it was extended and some wording was changed. Notably, the page now states that “Redis is open source, BSD license.” in its first sentence. Furthermore, the problematic paragraph was replaced with the following:
Redis is and will always remain open source BSD license, but we decided to prevent cloud providers from creating managed services from certain add-ons on top of Redis (e.g. RediSearch, Redis Graph, ReJSON, Redis-ML, Rebloom). These are licensed Apache 2.0 modified with Commons Clause.
This is clearly a much better statement, as the term “add-on” by definition separates itself from the Redis core, avoiding any confusion.
2. Response to controversy
Realizing that some people were reacting negatively, Redis Labs/antirez decided to act quickly and clear up the misunderstanding. On August 23, 2018, antirez published the blog post “Redis will remain BSD licensed”.
Additionally, Yiftach Shoolman, CTO of Redis Labs, left a comment on Hacker News reassuring that “Redis remains and always will remain, open source, BSD license” and offering further explanation for choosing the Commons Clause.
This was, in my opinion, the best they could do in that situation—correcting the false reception of their message as quickly as possible. However, one line stood out in antirez’s post, and has been edited since:
In the fake news era my attempts to provide the correct information failed
As antirez anticipated later, this wording is dangerous, as it politicizes the post and can lead to hostile reactions. But that is not the only reason: It also shifts blame on the reader. Of course, technically, everyone could have read and understood the whole post, and then there would have been no problem.
However, as pointed out above, the initial announcement was not the most fortunate one in some parts, so that makes it difficult to justify this part of the response. And in general, alas, most people online are expected not to have the attention span to read every sentence in detail.
3. Additional Response
On August 25, 2018, antirez published yet another post called Redis is not “open core”. In that post, he argues that Redis is not Open Core as Redis Labs do not own Redis, and furthermore:
In an open core business model around an open source system it is *fundamental* that you take something useful out of the free software part.
In contrary, Redis modules only offer “things similar to Redis but outside the Redis scope” according to antirez, so that’s another reason why it should not be called Open Core.
In my opinion, those are valid arguments, and if the core maintainer provides good reasons for their project not to be called Open Core, then so be it.
Still, from a project PR perspective, this seems like a non-essential detail at the moment. While clearing up misunderstandings and giving a solid explanation to the project’s users is crucial, too much defense can be risky as it might add fuel to the fire.
What I learned from this
Successful communication is important not only for companies, but also for Open Source projects. After all, even if you do great work that serves the public (which I’m sure the Redis contributors do, as it’s an amazing piece of software), people can still get mad at you in a matter of hours.
Thus, I hope my attempt to sum up the events will provide some help for maintainers to avoid getting into such a situation in the future!
About the author: I’m Patrick, a computer science student currently in Stockholm, Sweden. I’m also working at Jodel as a Backend Developer. If you’d like to get in touch, please consider following me on Twitter (or Facebook/LinkedIn)!
