A client was worried about all Redis license fuzz he heard of lately, and asked: Should I replace Redis?
Not an easy question, given that in his products Redis is such a central component, and it is used locally, in private and public cloud infrastructure, and as SaaS (provided by of one of large cloud providers).
What happened?
Since Redis 7.4 the license has changed from a straightforward BSD 3-Clause to a dual licensed (‘pick the one you prefer’) RSALv2 and SSPLv1 license.
Since this is in spite of what they once promised, the motives for this seem to be $$$ (and not ethics) but we have no opinions on that one.. things change, and making money is part of life.
What is more annoying, that their licenses are not Open Source anymore. The huge advantage for many (SME) software companies is that with Open Source, you’re not alone. Though not all questions are testing in every courts and legal system, still there is lots of documentation, background info, case law and other information available, and the license are used by huge numbers of companies across the globe.
So, it’s not Open Source, indicating we are on our own. We better read the license, and assess the impact of the conditions, track its future changes and so on.
REDIS License CHOICE 1: SSPL v1
The SSPLv1 is not Open Source, but it is based on GPLv3, a license that I normally avoid to use in commercial products to avoid legal and due diligence issues, and since most developers make mistakes quite easily with it (though other parties try to convince you differently).
So I suggest not to choose this license for use in commercial environments.
REIDS License CHOICE 2: RSAL v2
The RSALv2 is not Open Source either, but that is mostly because it is blocking large cloud vendors of making huge money with Redis by offering it as-a-service.
The license is non-sublicensable: when your product is published (a.k.a. shipped/released/conveyed/deployed) your license cannot be used for Redis, you must license it also under RSAL v2 to your clients. And since in many software B2B companies the licenses are in the contract, it can even imply a contract update. Not pleasant.
The license is also non-transferable, so the implications of this when selling you company or otherwise are unclear. Not something I would panic about, but unclear.
So .. what to do?
It’s a situation I have advised many customers to stay away from, using non Open Source licenses for free software. Developers and sales do not understand it, and the likelihood of problems after a few years is high.
Not so much I worry in these cases about lawsuits, but I have seen too many examples of using it as a stick to fire people or even use it in price negotiations when selling the company. Or even after the investment, since sometime CEOs are made to sign for joint and several liability on not having license problems.
Replacing Redis is hard, I know (having replaced Hibernate several times in my life out of a product), but with the current knowledge I tend to advise to do this.
But with what?
As far as I can see there are several directions to look at for this.
OPTION 1: Redis commercial license
Ofcourse one can just call Redis, and get a commercial license.
OPTION 2: Redis Fork’ed
Since the main reason for this hassle was to block cloud providers making big bucks by offering Redis-as-a-service whilst not paying Redis anything, a number of them have immediately forked Redis 7.2.4, so before the license change happened, and decided to use that for their cloud services.
Amazon, Google, Oracle and Alibaba have decided to back Valkey, a fork maintained by AWS’s Madelyn Olson and Alibaba Cloud’s Zhou Zhou. They promised to keep it Open Source forever.
For now, Valkey seems the dominant fork , I assume there will be more forks, like Redict (but this particular one is LGPL licensed).
OPTION 3: Redis-as-a-service
Of course the large cloud providers (AWS Elasticache, Azure) immediately switched to a fork to offer their Redis-compatible solutions, and promised to maintain their solution, so short term no problems will occur.
OPTION 4: CONSIDER Alternatives
Though Redis was very dominant in the market of distributed key-value stores, there are alternative, and their license change will enable these and other alternative. Open Source distributed key value stores (Garnet, Kvrocks, Dragonfly).
Depending on the use case, many other alternative solutions can be found, usually at the cost of serious refactoring (though Postgres I would not recommend for proper Redis cases).
ConcluDING…
So there we go again. Using Redis was a no-brainer, but it gives headaches again.
With multiple code bases of ‘Redis’ out there, we expect lock-in strategies, (security) problems, slow fixes, (feature) divergence and license updates to happen, causing all kind of worries trouble. Multi cloud strategy will have one more thing to worry about.
Also the development power that was working on Redis, is now scattered, so maintenance is crucial for any solution.
But the starting question was: Should I replace Redis?
My advice to this client was Yes, replace Redis by Valkey in the next release.
CTO advice:
If you deliver software:
* Commercially licensed, and deploy Redis: call Redis, or consider an alternative.
* Commercially licensed and use Redis-as-a-service and locally: yes, move to the Redis fork your cloud provider uses to stay in synch.
* Under an Open Source license: yes, replace Redis
In all situations, consider the impact on CVE management, licenses/contracts, support, testing, multi-cloud and other NFR’s.
And keep an eye on your invoices.