I contributed a minor (but imho still neat :p) improvement to Redis under its original license, and personally moved to using redict when the unexpected license change to SSPL was announced - and I was feeling betrayed as a contributor to a properly-FOSS-codebase. (Had they switched to AGPL right away, I'd have been perfectly fine with that change from a moral perspective, ftr.)
I have a great deal of respect for antirez and recgnize him as a kind and benevolent member of the FOSS community, but no matter what Redis, Inc. announced or does, they have lost my trust for good, and I will continue to use Redis forks for as long as they exist.
Yeah, we just did this whole ride with Elastic [0]: company changes the license out from under the community, community revolts, company gives up and changes it back. Both companies even pulled the same "it worked" excuse ("while it was painful, it worked", "this achieved our goal").
Neither company has built in a legal safety mechanism to prevent themselves from pulling the rug again later and both companies have shown themselves to be untrustworthy stewards. They came groveling back when it turned out that community goodwill really did matter after all, but this is definitely a "fool me twice, shame on me" situation.
Dunno about Redis, but for Elastic I still feel sorry for them being thrown around like a rag doll by Amazon. On principal I will not use the Amazon fork, because I don’t want to support a company that would prefer to fork a project rather than fork over some cash. Amazon is more than willing to sell you their Elasticsearch fork at a loss as long as they can eventually recoup the losses when Elastic inevitably dies. At which point they will naturally abandon the open sources side of their fork and continue development in private, at a much slower rate, while doubling the price of the AWS service. At which point you’ll have no choice but the pay up, cause there aren’t any competitors left.
1. People put a lot of work into building databases. The license choice is OSS / FOSS.
2. Some people in the community (original authors, community leads) make a company around the database and continue developing it for years on end. They sometimes raise venture capital to expand the business.
3. Amazon / Google / Microsoft offer managed versions of the database and make bank on it. Easily millions in revenue. Original creator / company doesn't get anything, and the hyperscaler isn't obliged to pay.
4. The company decides to change the license to force Amazon / Google / Microsoft to pitch in and pay a fee.
5. Amazon / Google / Microsoft fork the database. The community revolts. Sometimes the people revolting are employees of the hyperscalers, other times these are just FOSS fans that hate "source available" licenses or relicensing.
6. Database company is forced to walk back the changes. Still no revenue.
---
The solution is clear: start your new database with an "equitable source / source available" license from day one. Nobody will complain about a relicense since your license will handle the hyperscalers right off the bat.
Basically your license needs one of a few things if you want to prevent Amazon from walking off with your money:
- A hyperscaler clause such that any managed offering has to (1) be fully open source, (2) has to pay a fee, or (3) is prevented outright.
- A MAU / ARR clause such that hyperscalers are in the blast radius. Note that this also hits your customers.
NATS almost ended up doing it recently, too. Fortunately they caved in just today, after the CNCF and the community protested. [1] While the outcome is great, it was a bunch of drama for nothing, and their reputation has been harmed.
Interestingly their CEO states that AWS an Google forking redis and maintaining it separately was their "goal" all along. Because fragmentation is apparently good?
> Neither company has built in a legal safety mechanism to prevent themselves from pulling the rug again later
Previous versions are still available under the original license, right? So if you don't want to use it with a new license, you're in the same situation as if company went out of business or stopped support and development for any other reason. There are no safety mechanisms for that either.
The legal safety mechanism is the license. They gave you software under a certain license and you're in the clear as long as you follow it. You don't have to delete it if they give different software under a different license.
If you do need constant updates, you may trust forks more not to switch license, but forks tend to disappear at about the same rate that originals switch license, so why does it matter? Such is the nature of relying on free stuff - you're at the mercy of the one who hands it out.
I contributed heavily to a project during its early days and spent almost 2.5 years helping it grow. For awhile i was one of the most active contributors.
Then there was talk of turning the project into an actual business, and myself and a few of the original contributers were offered extremely poor paying jobs. That no one took. Then they got a CEO, investors and we were basically forced out of the project unless we joined the company.
I distinctly remember being in a call where we were told they would be relicensing it eventually and launching a SaaS. To protect our work from being used by large companies. I laughed and pointed out the irony in that call that you were doing the same thing.
After that they changed their policy such they do not accept outside PR's. It has killed any interest in supporting open source projects outside personal stuff.
Did you sign a Contributor License Agreement?
If not, then I'm pretty sure it's illegal to keep your changes while relicensing, without obtaining your consent.
Likewise. Respect for antirez and all of that he is doing, but his hiring back feels like just trying to lure developers back after ridiculous move by the Redis corporation.
Given there are viable alternatives out there, I see no reason why someone should invest any time in Redis (we are using Valkey as a replacement).
Nothing wrong in checking other alternatives, but Redis the company didn't call me to rejoin. I approached them to do something like an evangelist and bring back some kind of community vision inside. Then... if you can code, you end coding often times, and instead of doing the evangelist I wrote the Vector Set data type :D Just to clarify that me rejoining was not some kind of "winning back the community plan". I wrote at large about all that, even clearly stating that even the paycheck is modest (to avoid that kind of conflict of interest of the economical motivation).
I agree. That ship has sailed, at least for the foreseeable future. We switched to Valkey and it's our choice for a couple upcoming projects as well. To switch back now after this whole ordeal would make no sense at all.
Microsoft made one called Garnet, I wouldn't say its a fork though, its basically compatible with Redis and implemented mostly in C#. It supports the RESP wire protocol from Redis for ease of compatibility.
Garnet fascinates me. Their benchmarks even claim that it is better than Redis and also Dragonfly. Are there any papers or write ups explaining what makes Garnet fast? (I do know its based on FASTER)
Nice. I've been using Memurai (https://www.memurai.com/) for development on Windows (native, no WSL or Docker - for reasons), but this looks much better.
EDIT: Weird that being a program from Microsoft (well, it's Microsoft Research, so that probably explains it?) it has no installer and doesn't run as a service on its own.
I get the feeling. I also live in the real world and know that nobody except for a few (most notably RedHat) have figured out how to make sustainable money in open source. These closed licenses didn’t come out of nowhere. They came in response to places like AWS using the open source license to make a mint with a project — and doing so legally (it’s there in the license to do so) — but then the project suffers. So the license change is done to prevent that so the project — ostensibly — can survive. It makes sense. And so does wanting to live up to the promises of open source. It’s a tough situation for sure.
The only real reason to use non-copyleft licenses for these kinds of projects is to be able to do the rug pull, so you should have expected it instead of feeling betrayed.
I imagine they will now require copyright assignment or something like that for external contributors to be able to relicense new code under a commercial license.
A copyleft license like the AGPL didn't stop MongoDB from rugpulling. I'd argue that the AGPL, and the copyright assignment that tends to go with it, makes it easier to rugpull because forking entities would be at an extreme disadvantage in keeping the lights on compared to the closed-sourcing company. A non-copyleft license, on the other hand, makes it much easier for a forking company to cover all the same niches as the original company, making a rugpull that much more difficult.
> The only real reason to use non-copyleft licenses for these kinds of projects is to be able to do the rug pull
That’s an exaggeration. The vast majority of permissively licensed projects have never “rug pulled” and never will. It might be one possible reason to choose such a license but it’s very far from the only one.
All advantage accrues to hyperscaler "managed" versions. That's so much more fucked than a rug pull.
Amazon gets to make millions off of the thing you built.
"Equitable source" licenses with MAU / ARR limits, hyperscaler resale limits, and AGPL-like "entire stack must be open" clauses is the way to go. It's a "fuck you" to Amazon, Google, and Microsoft in particular and leaves you untouched.
Open source today is hyperscaler serfdom. Very few orgs are running Redis on bare metal, and a equitable source license can be made to always support the bare metal case.
> contributed a minor improvement to Redis under its original license [...] feeling betrayed as a contributor to a properly-FOSS-codebase
How does this work legally? You write some code, contribute it under a certain license... and... a company can just re-license your code under any license they like?
They require a Contributor License Agreement [0] whereby you grant them the copyright to your contribution. Which means they become the ultimate decision-maker for all contributions and can relicense however and whenever they wish.
If anyone betrayed the spirit of Open Source, it is those who were trying to siphon off the entire commericial value of these projects while contributing little back to the project.
Companies have to pay people to work on it. Hell, they are even entitled to profit from it. A world with commerically viable Open Source is way better than without it. Ditching OSS companies for trying to survive 90% of revenues going to $1T cloud vendors is counter productive.
Due to license rug pull, I started an org wide movement from Redis to Valkey early this year and now there’s no turning back. It also does not help Redis that Valkey is cheaper offering by AWS (at least through Elasticache).
I think we need to get back to state where we take software licenses serious in letter and in spirit. The transitions Redis made are pristine on a legal and moral level. Feeling betrayed is absolutely uncalled for.
Lots of cynical takes in this thread - and I get it, there isn't a guarantee they won't relicense again in the future (they have a CLA that would let them) and people feel betrayed by the last license change.
I think we should celebrate this anyway. It's a smart decision, it's what the community wanted to happen and it would be great if other companies with janky licenses could see "Redis relicensed to open source and had a great boost out of it", not 'Redis relicensed to open source and it didn't help them at all".
Thank you, Simon. I believe that cases like Elastic and Redis returning back to an open source license is like writing on the rock: "open source won", at least in the system software space. Companies get created, prosper and fail over time, but this message is here to stay with us for a long time, and shapes the society of tomorrow. It's a win of the software community itself.
It's a win for the community over and against the corporations that are Redis and Elastic. They're not the good guys for giving in to the pressure. They tried to ride FOSS to prominence and then extract wealth on the backs of the community and found that the community mattered more than they did.
So sure, let's celebrate, but celebrate the community, not those who tried to pull the rug out from under them.
> it would be great if other companies with janky licenses could see "Redis relicensed to open source and had a great boost out of it", not 'Redis relicensed to open source and it didn't help them at all".
If the other companies can't figure out that adopting a janky license and alienating the community is the self-inflicted problem, then they are beyond help. Relicensing to open source not helping the company may serve as a cautionary tale for other companies and may prevent them from repeating the same mistake. As an open source enthusiast, the worst case scenario is companies switching licenses tactically and frequently to test the waters and walking back with no consequences; I'd prefer the cost of such actions to be swift and severe.
It could be cynical, but I think it is important to show severe consequences for breaking trust between a company and its community. Anyone that saw their history and contributes to it must be aware they are doing unpaid work for a company.
I don't want companies to see, "re-licensing to janky licenses is risk-free, because we can always go back to the old license if people react too negatively". I would like them to see, "re-licensing to janky licenses is a death sentence which immediately makes your product almost completely irrelevant and causes the community to switch to a fork and never switch back".
>Lots of cynical takes in this thread - and I get it, there isn't a guarantee they won't relicense again in the future (they have a CLA that would let them) and people feel betrayed by the last license change.
Oh good. There is still hope of it returning to the original BSD license.
( I am still using good old Memcached )
I also appreciate this perspective because you never know what's going on in the board room. I have seen some morally upstanding leaders make questionable decisions that were totally out of character for them, all for the sake of appeasing a narrow-minded investor.
From this post on the Redis blog https://redis.io/blog/agplv3/ it looks like they've made a bunch of new features available under the new AGPL license too:
> Integrating Redis Stack technologies, including JSON, Time Series, probabilistic data types, Redis Query Engine and more into core Redis 8 under AGPL
Redis Query Engine is new-to-me (I stopped following Redis closely after the license change) - it looks like an in-memory alternative to a lot of the things you might do with Elasticsearch: https://redis.io/docs/latest/develop/interact/search-and-que...
(This is a smart move in terms of answering the question "Why would I switch back to Redis if I've moved to Valkey" - Redis just grew a bunch of new interesting features.)
Dismayingly, the CEO misspelled antirez's last name in this press release, https://redis.io/blog/agplv3/. That's so incredibly disrespectful:
> Following our license change, in November of 2024 Salvatore Sanfillipo (antirez) decided to rejoin Redis as a developer evangelist. Collaborating with Salvatore on new capabilities, company strategy and community engagement has been a true privilege that has made a major impact that will pay dividends into the future.
If it's a true privilege, you should earn it by not misspelling his name. Actions speak louder than words.
Pink Floyd has a song about this:
Well, I've always had a deep respect and I mean that most sincere
The band is just fantastic, that is really what I think
Oh, by the way, which one's Pink?
And did we tell you the name of the game, boy?
We call it riding the gravy train
We're just knocked out, we heard about the sell-out
You gotta get an album out, you owe it to the people
We're so happy we can hardly count
Everybody else is just green, have you seen the chart?
It's a hell of a start, it could be made into a monster
I'm curious whether the community will trust Redis-the-company again after this, or if they'll choose to stick with Valkey. The other concern is at least some big company legal departments are wary of AGPL software, which makes Valkey, still BSD, more attractive to them.
Edit: Regardless, thank you and the rest of the folks inside Redis for pushing to bring this back to OSS!
All of this aside, Redis-the-company has some of the least tactful salespeople I've come across in my long stint in this industry. Used car sales level tactics.
Between that and the licensing, I would never consider dealing with them.
We switched to Valkey on our Elasticache instances and immediately noticed a performance improvement in our usecase that allowed us to reduce number of instances. Not really interested in moving back to Redis at this point.
Yeah, there has been a lot of stuff like performance [1] and efficiency improvements [2]. A lot of the contributors, that didn't work for Redis labs but worked on Redis OSS before the fork, moved to Valkey and they continued to contribute.
Amazon really encourages valkey in the elasticache dashboard. There's a banner advertising lower prices and it's listed first in the dropdown when you go to create one. Default settings do have power.
I've been using Valkey simply because after I updated to the latest Fedora version, it dropped redis and pointed me to Valkey instead. I assume as more distros do this and more people update their systems, the Valkey user base will grow. But perhaps with the AGPL redis that will no longer be the case.
That kind of assertion really needs some backup or it's just noise. I'll be honest and say that I have no idea what the usage stats for Valkey are -- and it may be that it's a drop in the bucket compared to Redis. But I don't know. Can you back this up or is this just your gut feeling?
what do you mean? i work at a FAANG-adjacent company and our entire engineering org was told to switch to valkey, with an internal deadline from ops. My team supports a public facing service and we made the switch 2 months ago.
It was pretty easy, a small config change and some performance testing to make sure it worked well at scale.
Maybe nobody is talking about it online but some people have definitely switched.
One of the big things I love about Redis is that it’s become this tool for me to learn new techniques and explore data. Like, the new vector sets feature has let me really explore dense vectors and custom search and taxonomy mapping and all sorts of areas that seemed like a high barrier to entry for me, but now I’m just streaming stuff into llama.cpp with an embedding model and storing it in Redis and being able to do mappings between different data sets super efficiently.
A big part of that is API design - I can’t think of another system that is as well thought out as the Redis API - it’s deceptively simple and because of that I didn’t have to wait for client libraries to incorporate the new Redis features - they just work cause they all speak RESP and I can just send raw commands.
All of this is to say that I was really happy to hear Antirez was back working on Redis and it’s paying off in more ways than I could have imagined. People can use valkey or whatever they want as an alternative - but I like Redis because it’s always pushing forward and letting me explore new things that otherwise wouldn’t feel as “at my fingertips” as it does in Redis.
Thank you so much for your kind words! I tried hard, with Vector Sets, to follow exactly the "wave" you are referring here, I hope I was able to. Thanks.
Could you please link any blog post which goes into what you are talking about, I feel I am also at the high barrier to enter situation about this stuff
Our company made the switch over to Valkey, and we've invested hundreds of engineering hours into it already. I don't see us switching back at this point especially when it's clear Redis could easily pull the bait-and-switch again.
While it's likely an easy process to drop in valkey, creating the new instances, migrating apps to those new instances, and making sure there's not some hidden regression (even though it's "drop in") all takes time.
At a minimum, 1 or 2 hours per app optimistically.
My company has hundreds of apps (hurray microservices). That's where "hundreds of hours" seems pretty reasonable to me.
We don't have a lot of redis use in the company, but if we did it'd have taken a bit of time to switch over.
Edit: Dead before I could respond but I figured it was worthwhile to respond.
> It's literally just redis with a different name, what is there to test?
I've seen this happen quite a bit in opensource where a "x just named y" also happens to include tiny changes that actually conflict with the way we use it. For example, maybe some api doesn't guarantee order but our app (in a silly manor) relied on the order anyways. A bug on us, for sure, but not something that would surface until an update of redis or this switch over.
It can also be the case that we were relying on an older version of redis, the switchover to valkey necessitates that we now bring in the new changes to redis that we may not have tested.
These things certainly are unlikely (which is why 1 or 2 hours as an estimate, it'd take more if these are more common problems). Yet, they do and have happened to me with other dependency updates.
At a minimum, simply making sure someone didn't fat finger the new valkey addresses or mess up the terraform for the deployment will take time to test and verify.
At the very least you have to validate everything that touches redis, which means finding everything that touches redis. Internal tools and docs need to be updated.
And who knows if someone adopted post-fork features?
If this is a production system that supports the core business, hundreds of hours seems pretty reasonable. For a small operation that can afford to YOLO it, sure, it should be pretty easy.
Why did you not pay Redis for a licence instead? I'm genuinely curious. Did you feel uncomfortable being tied to a license fee that might increase in the future, or was it just too expensive?
how does it take hundreds of hours to swap out a back end when you're using a trivial protocol like redis?
did you switch out the client or something? maybe the problem is not using pluggable adapters? is your business logic coupled to the particular database client API? oof.
I know the cluster clients are different (been there, done that) but hundreds of hours, seriously? or was that just hyperbole?
I think you might underestimate how little time hundreds of hours is. It's very, very easy to reach your first hundred hours in a task, e.g. taking a 40 hour week, 3 engineers = 120 hours.
If valkey is working, why spend that time reverting to redis, when you could be spending it on things that are actually going to provide value?
Hundreds could be 200 which, at 10 hours a day 5 days a week, is like a week and a half for a team of 3. It seems quite possible if you had to do testing/benchmarking, config changes, deploy the system, watch metrics, etc.
My company is relatively small. With probably 6 separate redis instances deployed in various places (k8s, bare metal, staging and prod environments) and dozens of (micro)services using them it's probably at least 40 hours (one person-week) to migrate everything at this point. Also there are things like documentation, legacy apps that keep working but nobody wants to spend time updating them, naming problems everywhere (renaming "redis" everywhere with zero downtime would be a huge pain), outdated documentation, possibly updates in CI, CD, and e2e tests, and probably more problems that ight become apparent in scale.
And we're honestly not large. For a mid size company, hundreds hours sound reasonable. For a big company the amount of work must be truly staggering.
By switch I mean that all new projects use Valkey instead of Redis, and we've invested hundreds of hours into those new projects. We've also tried stuff with the Valkey Glide client.
>This achieved our goal—AWS and Google now maintain their own fork
Was this really the goal though? Forcing your biggest users to fork your software and maintain their own divergent version is not really good for anyone. Sure, Amazon and Google (or AWS and GCP - type confusion in the source material) now have to contribute some more engineering hours to the open fork, but why would anyone still want to use Redis now that there's a permissively licensed alternative maintained by the same cloud hyperscalers who will end up running it for you?
Yeah this take kind of surprised me, you really wanted Valkey to be the default option for cloud customers ensuring they'll have no migration path to your own offering? I just don't get it. You were getting $0 and now you're getting $0.
Isn't it though? They weren't contributing before and they weren't paying Redis corp before, now they are at least contributing to a fork (and still not paying Redis corp).
Presumably some of the things being worked on in Valkey, etc can be upstreamed back to Redis in some form (not entirely straightforward since it is a hard fork with a diff license, but concepts can be borrowed back too).
e.g. apparently Valkey has introduced some performance improvements. Redis can implement similar if it seems worthwhile. Without the fork those performance ideas might have never surfaced.
That is not true. Companies like AWS had paid staff working as OSS Redis core maintainers before the licencing schism. This talk of "achieving their goals" is just bluster serving no reason other than damage control.
But the person you replied to was talking about Redis's goal, and I don't think it's likely their goal had anything to do with having a competitor to themselves around. Even if they did want that, they could've just bankrolled (or engineered) a fork; changing a license to one that causes your largest users to do the work themselves is a rather roundabout way to do it.
I can almost kind of see the large users needing to work together on a replacement, meaning that replacement might as well be open-source, meaning Redis can get future improvements that were funded by the fork users (who Redis was upset wasn't paying them) as a semi-vindictive, semi-useful goal. But it's still roundabout. If that was really the plan, it could've been articulated better in this postmortem to make it clear the "goal" bit hadn't just been BS'd.
That's sort of fine. As a personal user, someone could fork and maintain redis in that case, which wasn't true in the SSPL era.
Now AGPL+CLA is not a license I'd contribute under, but also Redis is so far down my priorities that it wasn't a project I was going to be issuing PRs for anyway.
Readit News
I have a great deal of respect for antirez and recgnize him as a kind and benevolent member of the FOSS community, but no matter what Redis, Inc. announced or does, they have lost my trust for good, and I will continue to use Redis forks for as long as they exist.
Neither company has built in a legal safety mechanism to prevent themselves from pulling the rug again later and both companies have shown themselves to be untrustworthy stewards. They came groveling back when it turned out that community goodwill really did matter after all, but this is definitely a "fool me twice, shame on me" situation.
[0] https://news.ycombinator.com/item?id=41394797
1. People put a lot of work into building databases. The license choice is OSS / FOSS.
2. Some people in the community (original authors, community leads) make a company around the database and continue developing it for years on end. They sometimes raise venture capital to expand the business.
3. Amazon / Google / Microsoft offer managed versions of the database and make bank on it. Easily millions in revenue. Original creator / company doesn't get anything, and the hyperscaler isn't obliged to pay.
4. The company decides to change the license to force Amazon / Google / Microsoft to pitch in and pay a fee.
5. Amazon / Google / Microsoft fork the database. The community revolts. Sometimes the people revolting are employees of the hyperscalers, other times these are just FOSS fans that hate "source available" licenses or relicensing.
6. Database company is forced to walk back the changes. Still no revenue.
---
The solution is clear: start your new database with an "equitable source / source available" license from day one. Nobody will complain about a relicense since your license will handle the hyperscalers right off the bat.
Basically your license needs one of a few things if you want to prevent Amazon from walking off with your money:
- A hyperscaler clause such that any managed offering has to (1) be fully open source, (2) has to pay a fee, or (3) is prevented outright.
- A MAU / ARR clause such that hyperscalers are in the blast radius. Note that this also hits your customers.
[1] https://news.ycombinator.com/item?id=43863721
Previous versions are still available under the original license, right? So if you don't want to use it with a new license, you're in the same situation as if company went out of business or stopped support and development for any other reason. There are no safety mechanisms for that either.
If you do need constant updates, you may trust forks more not to switch license, but forks tend to disappear at about the same rate that originals switch license, so why does it matter? Such is the nature of relying on free stuff - you're at the mercy of the one who hands it out.
Unless of course you are an AI startup.
Then there was talk of turning the project into an actual business, and myself and a few of the original contributers were offered extremely poor paying jobs. That no one took. Then they got a CEO, investors and we were basically forced out of the project unless we joined the company.
I distinctly remember being in a call where we were told they would be relicensing it eventually and launching a SaaS. To protect our work from being used by large companies. I laughed and pointed out the irony in that call that you were doing the same thing.
After that they changed their policy such they do not accept outside PR's. It has killed any interest in supporting open source projects outside personal stuff.
Given there are viable alternatives out there, I see no reason why someone should invest any time in Redis (we are using Valkey as a replacement).
SSPL is not as bad as the OSS community pretends it is (unless you're a hyperscaler).
https://github.com/microsoft/garnet
EDIT: Weird that being a program from Microsoft (well, it's Microsoft Research, so that probably explains it?) it has no installer and doesn't run as a service on its own.
Deleted Comment
I imagine they will now require copyright assignment or something like that for external contributors to be able to relicense new code under a commercial license.
That’s an exaggeration. The vast majority of permissively licensed projects have never “rug pulled” and never will. It might be one possible reason to choose such a license but it’s very far from the only one.
Dead Comment
Amazon gets to make millions off of the thing you built.
"Equitable source" licenses with MAU / ARR limits, hyperscaler resale limits, and AGPL-like "entire stack must be open" clauses is the way to go. It's a "fuck you" to Amazon, Google, and Microsoft in particular and leaves you untouched.
Open source today is hyperscaler serfdom. Very few orgs are running Redis on bare metal, and a equitable source license can be made to always support the bare metal case.
How does this work legally? You write some code, contribute it under a certain license... and... a company can just re-license your code under any license they like?
[0] https://redis.io/legal/redis-software-grant-and-contributor-...
Companies have to pay people to work on it. Hell, they are even entitled to profit from it. A world with commerically viable Open Source is way better than without it. Ditching OSS companies for trying to survive 90% of revenues going to $1T cloud vendors is counter productive.
Deleted Comment
Yes, of course.
> and moral level. Feeling betrayed is absolutely uncalled for.
Er, no, that's an unsubstantiated leap.
I think we should celebrate this anyway. It's a smart decision, it's what the community wanted to happen and it would be great if other companies with janky licenses could see "Redis relicensed to open source and had a great boost out of it", not 'Redis relicensed to open source and it didn't help them at all".
I'm delighted. Thank you, team Redis.
So sure, let's celebrate, but celebrate the community, not those who tried to pull the rug out from under them.
Free Software won, as you ended up adopting the AGPL.
It’s an important distinction.
If the other companies can't figure out that adopting a janky license and alienating the community is the self-inflicted problem, then they are beyond help. Relicensing to open source not helping the company may serve as a cautionary tale for other companies and may prevent them from repeating the same mistake. As an open source enthusiast, the worst case scenario is companies switching licenses tactically and frequently to test the waters and walking back with no consequences; I'd prefer the cost of such actions to be swift and severe.
Oh good. There is still hope of it returning to the original BSD license. ( I am still using good old Memcached )
> Integrating Redis Stack technologies, including JSON, Time Series, probabilistic data types, Redis Query Engine and more into core Redis 8 under AGPL
Redis Query Engine is new-to-me (I stopped following Redis closely after the license change) - it looks like an in-memory alternative to a lot of the things you might do with Elasticsearch: https://redis.io/docs/latest/develop/interact/search-and-que...
With syntax that looks something like this:
(This is a smart move in terms of answering the question "Why would I switch back to Redis if I've moved to Valkey" - Redis just grew a bunch of new interesting features.)> Following our license change, in November of 2024 Salvatore Sanfillipo (antirez) decided to rejoin Redis as a developer evangelist. Collaborating with Salvatore on new capabilities, company strategy and community engagement has been a true privilege that has made a major impact that will pay dividends into the future.
If it's a true privilege, you should earn it by not misspelling his name. Actions speak louder than words.
Pink Floyd has a song about this:
Well, I've always had a deep respect and I mean that most sincere
The band is just fantastic, that is really what I think
Oh, by the way, which one's Pink?
And did we tell you the name of the game, boy?
We call it riding the gravy train
We're just knocked out, we heard about the sell-out
You gotta get an album out, you owe it to the people
We're so happy we can hardly count
Everybody else is just green, have you seen the chart?
It's a hell of a start, it could be made into a monster
If we all pull together as a team.
Deleted Comment
Dead Comment
Edit: Regardless, thank you and the rest of the folks inside Redis for pushing to bring this back to OSS!
Not to say it’s not an important discussion!
Between that and the licensing, I would never consider dealing with them.
Although I haven't checked if ValKey any substantial development since the fork.
[1] https://valkey.io/blog/unlock-one-million-rps-part2/ [2] https://valkey.io/blog/new-hash-table/
https://github.com/valkey-io/valkey
https://github.com/redis/redis
Deleted Comment
This is Open Source working well.
Unfortunately, the reverse flow does not work.
[1] https://github.com/redis/redis/pull/13638
It was pretty easy, a small config change and some performance testing to make sure it worked well at scale.
Maybe nobody is talking about it online but some people have definitely switched.
A big part of that is API design - I can’t think of another system that is as well thought out as the Redis API - it’s deceptively simple and because of that I didn’t have to wait for client libraries to incorporate the new Redis features - they just work cause they all speak RESP and I can just send raw commands.
All of this is to say that I was really happy to hear Antirez was back working on Redis and it’s paying off in more ways than I could have imagined. People can use valkey or whatever they want as an alternative - but I like Redis because it’s always pushing forward and letting me explore new things that otherwise wouldn’t feel as “at my fingertips” as it does in Redis.
While it's likely an easy process to drop in valkey, creating the new instances, migrating apps to those new instances, and making sure there's not some hidden regression (even though it's "drop in") all takes time.
At a minimum, 1 or 2 hours per app optimistically.
My company has hundreds of apps (hurray microservices). That's where "hundreds of hours" seems pretty reasonable to me.
We don't have a lot of redis use in the company, but if we did it'd have taken a bit of time to switch over.
Edit: Dead before I could respond but I figured it was worthwhile to respond.
> It's literally just redis with a different name, what is there to test?
I've seen this happen quite a bit in opensource where a "x just named y" also happens to include tiny changes that actually conflict with the way we use it. For example, maybe some api doesn't guarantee order but our app (in a silly manor) relied on the order anyways. A bug on us, for sure, but not something that would surface until an update of redis or this switch over.
It can also be the case that we were relying on an older version of redis, the switchover to valkey necessitates that we now bring in the new changes to redis that we may not have tested.
These things certainly are unlikely (which is why 1 or 2 hours as an estimate, it'd take more if these are more common problems). Yet, they do and have happened to me with other dependency updates.
At a minimum, simply making sure someone didn't fat finger the new valkey addresses or mess up the terraform for the deployment will take time to test and verify.
And who knows if someone adopted post-fork features?
If this is a production system that supports the core business, hundreds of hours seems pretty reasonable. For a small operation that can afford to YOLO it, sure, it should be pretty easy.
Now consider a no-down-time migration. How long do you think that'll take to engineer and execute?
did you switch out the client or something? maybe the problem is not using pluggable adapters? is your business logic coupled to the particular database client API? oof.
I know the cluster clients are different (been there, done that) but hundreds of hours, seriously? or was that just hyperbole?
If valkey is working, why spend that time reverting to redis, when you could be spending it on things that are actually going to provide value?
And we're honestly not large. For a mid size company, hundreds hours sound reasonable. For a big company the amount of work must be truly staggering.
>This achieved our goal—AWS and Google now maintain their own fork
Was this really the goal though? Forcing your biggest users to fork your software and maintain their own divergent version is not really good for anyone. Sure, Amazon and Google (or AWS and GCP - type confusion in the source material) now have to contribute some more engineering hours to the open fork, but why would anyone still want to use Redis now that there's a permissively licensed alternative maintained by the same cloud hyperscalers who will end up running it for you?
Presumably some of the things being worked on in Valkey, etc can be upstreamed back to Redis in some form (not entirely straightforward since it is a hard fork with a diff license, but concepts can be borrowed back too).
e.g. apparently Valkey has introduced some performance improvements. Redis can implement similar if it seems worthwhile. Without the fork those performance ideas might have never surfaced.
That is not true. Companies like AWS had paid staff working as OSS Redis core maintainers before the licencing schism. This talk of "achieving their goals" is just bluster serving no reason other than damage control.
But the person you replied to was talking about Redis's goal, and I don't think it's likely their goal had anything to do with having a competitor to themselves around. Even if they did want that, they could've just bankrolled (or engineered) a fork; changing a license to one that causes your largest users to do the work themselves is a rather roundabout way to do it.
I can almost kind of see the large users needing to work together on a replacement, meaning that replacement might as well be open-source, meaning Redis can get future improvements that were funded by the fork users (who Redis was upset wasn't paying them) as a semi-vindictive, semi-useful goal. But it's still roundabout. If that was really the plan, it could've been articulated better in this postmortem to make it clear the "goal" bit hadn't just been BS'd.
The only way this remains open source forever is to accept AGPL-only licensed patches.
[1]: https://github.com/redis/redis/blob/d65102861f51af48241f607a...
Now AGPL+CLA is not a license I'd contribute under, but also Redis is so far down my priorities that it wasn't a project I was going to be issuing PRs for anyway.
Why not? Is it because only one company can make proprietary fork?
Would you rather contribute to MIT software where everyone can make proprietary fork? Or AGPL without CLA where nobody can make proprietary fork?