I only run redis myself but wouldn't immediately place blame on Valkey if that happened.
RDS is now gone. It's on a couple of EC2 instances with replication, hourly EBS snapshots and daily shipping to S3.
I'm loathed to use AWS's "encapsulated" services for anything since.
Where as, Redis/Valkey’s ecosystem exists mainly as advocacy and happy users. It might be central to an architecture, sure, but using a previously open sourced version was unlikely to cause considerable problems.
Contrast to potential huge changes to the BUSL’d terraform that create incompatibility with existing providers would lock you in to HashiCorp’s new, unfavorable, terms.
It was never in danger, the providers remained under MPL and were explicitly excluded from the licensing change, with a good associated explanation (most of them were developed by and with partners and the community, unlike Terraform core which was almost entirely HashiCorp).
Additionally, HashiCorp changed the terms of service on the registry, making it only acceptable to use the official terraform binaries to download modules or providers.
Now, the providers are mostly open source, so, it was never impossible to recreate the thing—just work. But the point here is that Hashicorp took steps that caused the community of terraform users to recognize that closing off the ecosystem would have a tremendous impact on devops.
That’s why there was so much outrage and immediate action taken.
Why would HashiCorp provide free hosting of providers and modules for projects competing, using HashiCorp's own code at that? Multiple entire companies exist doing little more than providing wrappers around stuff HashiCorp develops. HashiCorp has no obligation to give them everything so they have an easier time at undercutting them (because they don't have to actually develop the main stuff).
> But the point here is that Hashicorp took steps that caused the community of terraform users to recognize that closing off the ecosystem would have a tremendous impact on devops.
The community of people using alternative products off HashiCorp's efforts, code, and money. Terraform Community Edition is still free and usable for anyone as long as you don't sell it to compete with HashiCorp.
If you recall, my point is that “providers were in danger,” and this is a reason in support of that. HashiCorp, of course, has no obligation to host providers for competitors. But, this is one more reason OpenTofu succeeded!
> Terraform Community Edition is still free and usable for anyone as long as you don't sell it to compete with HashiCorp.
Except, it’s rather unclear what “compete with HashiCorp” means, and there’s very little assurance that if you stick with terraform community edition you won’t get screwed over and be forced to pay in 6 months.
You can make all the arguments about “needing to make money”, “free loaders”, etc. HashiCorp is not unique in changing licenses and getting backlash.
But, as someone who joined HashiCorp, in part, because of our open source strategy, and hearing over and over, for years, how it was the reason we were so successful…
You seem to be completely out of the loop. Valkey is backed by AWS, Google Cloud, Oracle, etc. If I recall correctly, a principal engineer from AWS was spearheading the project.
Only AWS and the hyperscalers deserve to make millions from Redis. Screw the Redis authors and maintainers.
Lesson to all DB startups: fair source your license. Put in anti-hyperscaler clauses into your licenses to preserve your ability to make money and be sustainable.
You can let your customers have unlimited access to your code, but stamp out the ability for AWS or Google to offer managed versions. They need to pay you.
Don't be Redis or Elasticsearch. For them it's too late. They went uber permissive and now their fate is sealed. They're hundred million dollar cash cows for the giants, and the main committers see none of that.
We have issue with people not respecting software freedoms.
You seem to be intentionally conflating the two things.
Why make source available at all if you are just going to release proprietary software? It’s open source cosplay at that point. Just make commercial proprietary software like a normal software company; don’t pretend you are open source just because your source code is readable on GitHub.
Because there's years between one decision and the other, and in that time it turned out that because the software was open source they were structurally disadvantaged versus large cloud providers in being able to make money from it.
It seems disingenuous to suggest that the open sourcing was in bad faith given it happened years and paradigms apart from the closed sourcing, even though I don't agree with the decision either.
The problem here is that their actions are indistinguishable from an entity that is acting in bad faith. "Get loads of free labour, then claim ownership of it and try to monetize" is a business strategy.
If that means that the package is now named Valkey this is totally fine.
What a spin. Extortion following licensing rug pulls goes way beyond earning a living. Trying to blame victims by framing them as "monopolies" is somewhere between laughable and disingenuous. It's bold of you to make these claims in a time where everyone can verify both the licensing changes and how the whole developer community unanimously reacted to it.
> Only AWS and the hyperscalers deserve to make millions from Redis. Screw the Redis authors and maintainers.
If you pay attention, you will realize that all major Linux distros rushed to replace Redis with ValKey. Quite bold of you to claim that this licensing rug pull only affected villains.
Enough with the nonsense. If you try to abuse your users and treat everyone as a fool, don't clutch your pearls when they just drop you without a second thought.
It's an ironic take for a comment that uses words like "disingenuous" and "clutching pearls".
Pick a lane: either emotive arguments are in, or out. Don't accuse someone of speaking nonsense in the same comment where you claim that ceasing to provide free updates to a free product is "abuse". It's one or the other.
Anyone subjected to a bait-and-switch is a victim. It means nothing if the bait was free.
What about the third party dev who contributed to the code on the basis it was open source?
Original GPs comment was justifiable if you allow emotive hyperbole. “Spin”. Op disagreed with the point made by GP but addressed the form in which it was made, over the actual content, while themselves using the same style. That’s not fair. Be consistent: are we being hyperbolic or are we being literal?
I’m not even taking sides on the actual redis issue. “Trust was breached”? Can’t argue with that: licenses don’t cover trust and implicit agreements. But then say that, don’t say “you’re wrong for spinning things, but also <spin>”.
No. Everyone deserves to, including AWS and the other hyperscalers. That is exactly what was decided by releasing it under the BSD license.
then apparently the community quickly found an Uno reverse card somewhere. (so the question has become moot.)
I don't get the anti-capitalist stance here. If you want to contribute to redis, Redis Inc. will require you to sign a contributor license agreement: https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
They'll be happy to take your work but the right to exploit it commercially is exclusive to them. That agreement (should you choose to sign it) gives them the right to take your contributions and re-license them under a proprietary license, or any license of their choosing. There's also no commitment that the code base will stay AGPL. That agreement gives them the right to do whatever. Agreements like that are very common with AGPL because it doesn't make much commercial sense to use that license without one.
> Put in anti-hyperscaler clauses into your licenses to preserve your ability to make money and be sustainable.
.. and permanently alienate the rest of the open source community from providing contributions to your project. That raises the question why you are open sourcing at all? Why would you cripple a community like that? Permissive licenses are successful because, well, they are permissive. It's why there are a lot of decades old OSS projects where the original developers and companies have long moved on, or in some cases, passed away. It doesn't matter. Because they have diverse communities that survive such things.
Bottom line: the company that own the brand of any open source project and receive money from support or features may not be constituted of the original authors nor is necessarily comprised of all the dev who have put a significant amount of work into it.
This whole "but we wanted to do a cloud offering, it's not fair that AWS/Azure/GCE make one with our software and everyone is using theirs" is just so stupid to me.
You wanted people to adopt your software. You used permissive licenses to convince people. People adopted your software probably because of the free nature of the software. Now you want to change that. Well that is just stupid.
I think that is especially true for Redis. Redis is a good software. Many integrated it but it is not irreplaceble. The idea of a KV store is not that novel.
If so, is it too little, too late, to turn back the tide? I remember Node.js almost fell apart after the short-lived Io.js fork era, but the community patched up.
Is the same possible with Redis? I used to use it a lot, but haven't for the past few years, so I'm not able to get the same perspective on the community around these two projects.
I think so too. At least to me the Redis rug pull forced Redis to be completely out of the picture, and moving forward valkey is the default option.
Fool me once, shame on you.
Even when using test services, using docker works best since all the Devs will be on the same version instead of splitting between Debian, fedora, and brew versions.
I don't think this opinion is realistic or grounded in reality. Any company goes through license reviews when discussing which project to adopt. You may not care what software you run on a weekend project, but everyone working in a professional setting goes through a long bureaucratic song and dance act with legal representatives to verify if they can or cannot use a dependency.
It's simple: supporting a business without getting paid sucks ass. The second a project excludes commercial work they get 100x my attention.
This stance is interesting to me because it reminds me of psychological experiments about utility versus fairness. I'd like to ask you a question in that spirit.
If you could choose one of the following, which would you choose?
1. Noncommercial users gain 3× on some comprehensive metric of useful software with the source available (imagine the metric includes code quality, features, hardware support, choice, etc.), but businesses gain 10×
2. Noncommercial users gain 2×, and businesses gain 2×
3. Noncommercial users gain 1.1×, and businesses gain nothing
4. Noncommercial users gain nothing, and businesses gain nothing
5. Noncommercial users lose 3×, but businesses lose 10×
Edit: Added option 3 and renumbered the options after.
It will be interesting to see where the developer community goes but these forks have a way of becoming permanent. If you look at the Valkey Github, you'll see a lot of activity. Lots of contributors contributing lots of changes. All signs of a healthy open source community. And as the article shows, there have been some non trivial changes made to the code base that, at least temporarily, give it a bit of a lead in terms of performance. That indicates to me that there is a momentum of people maintaining it that seem to know what they are doing.
It will be interesting to see if Redis Inc. will be able to keep up/recover from this. My impression is that the community around that shrunk to basically employees of Redis Inc. when they closed source and that the rest of the community jumped ship to Valkey. Maybe some of them will go back now that they switched to AGPL. But I think Valkey is where the cloud sponsored money and action is. And there is of course more than a bit of broken trust here as well. And while AGPL is open source, I think signing agreements to give Redis Inc. the permission to re-license your contributions as they want is not something any serious open source contributor would consider.
The Redis licensing rug pull affects the whole community, not just strawmen villains. Random weekend warriors who occasionally spin up a container might not care. Anyone who trusted a FLOSS project to play a key role in their company's infrastructure will unavoidable have risk mitigation meetings where the name Redis is brought up.
We learned this from X11 and the Unix wars, and history repeats itself in the countless free-core-but-proprietary-enterprise-features projects that never really expand beyond their parent corporation.
This is why trillion dollar corporations must not have special rules and the playing field must be even to any use, despite how unintuitive it may feel. Someone tried to codify it early as the first of the four software freedoms (the keyword being "anyone").
Why is it so unacceptable that they choose to collaborate on something completely Open Source instead (Valkey)?
There's only so much manpower to go around and much of it is otherwise preoccupied now.
From a business perspective Redis falls into this really awkward niche where its does like 50 different things but most people only use 5% of that and have no desire to use the fancy stuff like Sentinel and Streams. What's worse: when any software tool wants to start charging money for their product, the options for users are not just "stop using Redis" or "start paying". There are also the options "switch to a competitor", "rewrite it yourself with just the functionality you need" and (for OSS projects) "fork the last open source version then maintain it yourself so you don't have to pay the overhead of the OSS company". It seems to me Redis sits in a super awkward spot where forking or rolling your own is preferable to many business users. Much more so than (say) postgres, because the cheap-and-dirty version of redis is "just" a hashmap with a network interface.
That sounds like a high amount of effort for something that is probably non-core for that business’s users (i.e. the company is not an infra/platform company). Paying money can easily be worth the time and distraction of maintenance.
Similar to AWS. Many companies _could_ rent rackspace or linode or even ec2 instances and run on top. Services built on top like ECS and RDS are so much simpler to manage. That time, money, and focus goes elsewhere: building for users.
However, this article is a bit misleading:
>Antirez’s emphasis on a shared nothing architecture has been foundational for Redis. Nevertheless, as early as 2020, Redis added support for I/O threads. Unfortunately, they did not offer drastic improvement until recently. If you have previously tried and discarded I/O threads, it is time to evaluate again!
Please note that is that same Antirez that implemented I/O threading in 2020, exactly because it does not violate the same reasons why I believe in shared nothing.
<technical background>
What I/O threading does, is, when we return from the event loop, to recognized that write(2) / read(2) syscalls are very slow, and in that moment we have zero contention, so what about parallelizing in N threads just that I/O, and returning single threaded immediately after? So I implemented this system, and the ValKey folks did the awesome job of making it better (thanks again).
</technical background>
But it is not true that the system didn't work back then, even if now it was improved, as you can see from the graph in the article itself... I wonder if those posts are payed by somebody or what. There are similar non-sensical posts in the Redis side as well, and they suck likewise, blabling about random things. WTF... What a disservice is this kind of journalism.
Anyway, one reason why these stuff are interesting mostly for Redis the company itself, Amazon, Google, and only marginally for normal Redis users, that is in turn the reason why the feature is not so used, is that if you don't have many users in the same machine or you don't see extremely high loads in specific circumstances, you usually don't need to enable it. Many users of Redis, even big users (I remember the numbers of a few very popular social networks) have their Redis CPU usages low enough to don't bother.
Btw about threads, there are times when they simply fit. If you see my latest work at Redis, the new vector set data type, well, queries are threaded by default, and you can even use VADD (so writing to a vector set) in a threaded way. Why I changed my mind? Because HNSWs are the first data structures with huge constant times, Redis never had something like that, and this changed the design space that was worth considering. So in 2020 I was already positive about threads, in the past I already had implemented the threaded support for moduels operation, and now vector sets are threaded. It is not about being pro or against, it depends.
Not any random ensemble of "Valkey contributors" that did async IO but AWS: One of those cloud providers Redis moved away from FOSS for.
One year later, Valkey hasn't just survived – it's thriving! The Async I/O Threading model contribution from AWS unlocked 3x+ throughput by fundamentally changing how I/O threads work inside Redis.
... those open source companies that still harbor magical beliefs ... cloud services providers are emphatically not going to license your proprietary software. I mean, you knew that, right?
... The cloud services providers are currently re-proprietarizing all of computing – they are making their own CPUs for crying out loud! – reimplementing the bits of your software that they need in the name of the service that their customers want (and will pay for!) won't even move the needle in terms of their effort.
https://www.theregister.com/2025/05/01/redis_returns_to_open...
"Trollope later justified the shift by saying the SSPL license only really "applies to Amazon and Google" – fellow cloud provider Microsoft has agreed commercial terms with Redis."
The latest AGPL shift is great and should have been the default for open source since 2010.
While I agree with your technical points, the constant criticism seems less about the specifics and more rooted in either a tendency to go after the incredibly successful, or classic tall poppy syndrome [0].
While we can't control how others react, reframing these kinds of posts as an indirect acknowledgment of your work's significance might be a healthier approach.
P.S. Appreciate the LinkedIn connection.
We use Redis all over on GCP both via MemoryStore and on custom machines. We use both classic Redis and Redis Cluster.
The official C library is sadly quite deficient if you want to use Redis Cluster and then TLS. We have to use an unofficial hiredis-cluster client [0]. It's a real pain for us. We're considering moving to Scylla.
GCP's Memorystore is a joke too.
It is maintained by many of the same people who have maintained hiredis and hiredis-cluster.
bhouston•1d ago
yjftsjthsd-h•1d ago
Hasnep•1d ago
kijin•1d ago
Getting your software into the default package managers is not necessarily the best choice for a new and fast-moving project. You'll be stuck answering bug reports for an ancient version and monkey-patching it for the life of the LTS release. It's much more ergonomic, both for maintainers and users, to run your own PPA or repo with the latest version.
bbarnett•1d ago
If you want stable, you want a non-changing branch with security fixes only. No surprises, no api changes, no config file changes.
And you don't want to be stuck on a non-security fix version. You cannot sit on the same version without tracking security, while you slowly retool and recode for breaking api/behaviour changes.
Debian stable has redis, and others, and will see backported security updates for the life of the support window.
This isn't just about redis. If you're doing this with anything, you must track secuirty updates, must stay up to date, or you are negligent. And tracking changes for infra stuff like redis, and other backend stuff is a waste of resources with typically zero benefit.
I won't touch core daemons like redis, if it isn't distro maintained. I have better things to do. More important things to worry about.
kijin•23h ago
Case in point: there are known vulnerabilities in the version of Redis shipped with Ubuntu 22.04 LTS, which a lot of people would assume is still maintained. But Redis is in universe, so patches are only available for those with an Ubuntu Pro subscription.
bbarnett•20h ago
kijin•2h ago
Ubuntu throws 90% of its packages in universe and doesn't even bother to pull security fixes from Debian. It's absolutely irresponsible and not comparable to Debian at all.
motorest•1d ago
That sounds like a GitHub Actions problem. GitHub Actions only offers a very limited set of container images, and for Ubuntu they just go with the LTS version that shipped before Valkey even existed.
https://docs.github.com/en/actions/writing-workflows/workflo...
Kwpolska•1d ago
skywhopper•1d ago
LukeShu•1d ago
jdmarble•1d ago
hnarn•14h ago