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.
lolinder · 2h ago
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.
This seems to be accelerating. I guess the era of lighting investment money on fire and pretending that the flames equal success is coming to an end.
Unless of course you are an AI startup.
antirez · 3h ago
Anyway: thanks for having contributed to Redis :)
noshitsherlock · 2h ago
Good decision, I hope the best for Redis!
revskill · 2h ago
Not quite. Company can easily change license at any time. No string attached.
osigurdson · 28m ago
I believe AGPL + time + contributors makes that very difficult. It also means that if you have a commercial product that uses Redis you need to open source your stuff though, so not net better imu. Please correct me if I am wrong.
gkbrk · 12m ago
Nope, looks like they still require a CLA for code contributions, which means they can release it under whatever license they want.
It all depends on if they have a CLA or not. Have CLA == continued easy rug pull, No CLA == rug pull gets harder over time.
elAhmo · 2h ago
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).
antirez · 1h ago
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).
bobsoap · 2h ago
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.
giancarlostoro · 4h ago
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.
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.
yyyk · 50m ago
The readytorun zip includes a service exe, it does need 'sc create binpath= ' etc. to be ran as a service.
avinassh · 3h ago
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)
reconditerose · 2h ago
The tl;dr is it's just a lockless hashmap attached to a TCP server with a log. Simple Get/Set operations are highly optimized, so with high batching they are able to efficiently fetch a lot of data efficiently. The architectures scales very well when you add threads and data access that is uniform.
It struggles a bit on certain types of workloads like hot keys, think heavy hitting a single sorted set. It's a cool architecture.
arghwhat · 2h ago
That's... Pretty much exactly what you'd expect from a KV store. It's a hashmap on the network.
Microsoft has a habit of "fake" open source. Particularly on Github.
By "fake", I mean Microsoft largely treats their Open Source codebases like they are closed-source, in-house proprietary codebases that they happen to let members of the public look at.
They'll accept a PR once in a while, but mostly it appears Issues and PR's are used as a free alternative to UserVoice.
Every decision is made behind closed doors (probably a MS Teams call actually), and you'll notice how top-heavy their staff is on these projects (half a dozen employees with "Manager" in their title on any given repo).
Beggars can't be choosers, and I'm glad they are dipping their toes into the FOSS water... but I don't really get FOSS vibes from their projects on Github.
bigstrat2003 · 1h ago
Open source does not mean you accept contributions from others. It means that the source code is available, and that people are free to take it and modify it themselves. You are using a definition which is... not exactly incorrect, because definitions are what they are, but certainly not what everyone else uses.
KolmogorovComp · 3h ago
You’re confusing open source and open to contribution. Is SQLite not open-source?
Alupis · 2h ago
Perhaps... when I look at an Open Source codebase, I expect there to not just be source you can read, but also a way to contribute and engage with the codebase creators, beyond just bug reporting (aka. Github Issues).
While it may technically be open source due to it's license and you can literally go look at the source - Microsoft is operating these codebases as-if they are proprietary. Every decision is made out of public - and I would not be surprised to learn they have their own internal tracker for the "real" backlog items. You frequently see command/comments by Microsoft employees which clearly are triggering workflows in their real backlog tracker, and near-zero discussion happens in Github by Microsoft employees, and when it does - it's clearly through a PR filter.
Like I said, beggars can't be choosers and it's better to have this than nothing - but I don't really think Microsoft has grasped the true concept of FOSS as-of yet.
> Is SQLite not open-source?
Not really in my opinion either. There's no way to contribute at all... best you can do it raise hell on the forums about a particular issue you want to see fixed. So while it's Open Source in the strict sense, it's not Open Source in the general sense.
MaxBarraclough · 16m ago
The terminology for this is the cathedral model and the bazaar model. Under the former model, code is released from 'on high'. Under the latter, it's developed in the open and with cooperation with the community. Both count as Free and Open Source software though, provided of course that a FOSS licence is used.
Whether a project is developed by a community or by a single entity holding all keys is completely orthogonal to being Open Source/Free Software. There's nothing wrong in putting one kind of projects above the other, but you may want to revise "your opinion" if you want to stay communicative, because terms and definitions are only useful when people agree on what they mean.
burnished · 1h ago
I think most projects are genuinely like this though, even ones that accept outside contributions more earnestly. I understand why you'd associate open to contributions with open source but I think its a mistake to treat the relationship as required rather than common.
The sibling comments contain some sharper critique of Microsoft if you haven't read them yet.
tough · 3h ago
Does SQLite try to embrace, extend, and extinguish their competitors?
atonse · 2h ago
Embrace, Extend, Extinguish is from an era where Open Source wasn't the default for infrastructure.
I don't know how you can extinguish something that's MIT licensed and has a million copies around the world.
I wouldn't trust Microsoft near my open source code base in 3 centuries
They can extinguish it by just stealing all the code, and using their bigger marketplace advantage to become the defacto standard.
Alupis · 2h ago
I'm fairly impressed Microsoft managed not to name their Redis competitor "Cache", just to pollute the keyspace like they do with so many of their other products.
tough · 2h ago
LMAO they're so evil its even mildly funny
joshstrange · 2h ago
I guess it will depend on your definition of "extinguish" and a few other things but:
gestures wildly at the MIT-licenced VSCode codebase
Yes, they are not rug pulling the VSCode source but by locking down the marketplace (and never giving a truly open source VSCode, what developers think of as "VSCode") they are in the processes of locking out forks.
atonse · 1h ago
Ah so this is like how Android being open source was (almost) always bullshit. You had to play all kinds of google dances to get the google apps on them.
Fair point! good example of an attempt to extinguish.
Like seriously - I haven't heard of them doing it in quite a long time. I know they were atrocious in the 90s and 00s, I'm not disputing that at all. Are there any examples of them continuing this behavior in the last decade though?
Further, a huge percentage of the people making those decisions back then are no longer with the company, different people are in charge, etc. The industry has changed it's relationship with open source - company board rooms aren't scared of the consequences of loading open source onto a server, the legality and liabilities have been hashed out, and MS isn't really even capable of pulling those fear levers anymore. MS itself has repositioned in the industry - their dreams of total computing dominance have been shattered: there's no chance of a windows derivative owning the server market any more, there's no money in browsers or consumer OSes (heck even MS's domination in gaming is showing cracks due the the efforts of valve). Point being - would it even make strategic sense for them to try to EEE anything anymore?
Note: I have almost no ties to MS. I haven't used an MS os or desktop software since before covid (in any capacity, even moving the mouse on a computer running windows). I don't use any of their SaaS products personally or professionally. There are integrations between the products I help build and azure, however those are not a major source of revenue for my employer and I do very little work that even touches that stuff. Point being - I'm pretty non-MS in my life and don't have any sort of loyalty or incentive to defend them. I do abhor their EEE actions back in the 90s and 00s when they were doing them, and those still make me angry... but that's not a reason to assume that different people at a company are going to act the same as the old-school ones.
dharmab · 2h ago
I make an open source, MIT licensed piece of software. I don't accept unsolicited contributions, but I document that people are free to fork the code and provide instructions on how to develop, test and build on your machine.
Am I "fake open source"?
Alupis · 2h ago
In my opinion, the spirit of open source goes beyond just tossing code over a wall for people to look at. In my opinion, it means accepting engagement from your users, their inputs and their contributions when/where warranted.
In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
That's not to say you are required to accept all contributions - I'm saying you should be open to contributions that A) save you time B) enhance the codebase or C) fix confirmed bugs.
In Microsoft's case - I don't see a lot of that going on. I see lots of Issues (bug reports), some PR's, but mostly opaque decision making, and complete silence on things the Corporate side of Microsoft doesn't want to comment on yet. Which is the beef - it's a corporate project run like it's proprietary but you can go look at the code. Again, better than nothing, but it's not really what I consider true open source.
thewebguyd · 25m ago
> In my opinion, the spirit of open source goes beyond just tossing code over a wall for people to look at. In my opinion, it means accepting engagement from your users, their inputs and their contributions when/where warranted.
I disagree. There's nothing about open source or the various open source licenses that require accepting engagement from the community and/or contributions.
Open source means allowing modifications, and sharing those modifications. It's in most licenses that the software is provided as is and without warranty.
> In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
A project not accepting outside contributions is still open source, not pretending to be, and the beauty of it is - if you want it to accept outside contributions, you are able to fork it and accept contributions on your own fork, or otherwise share your modifications. But there's absolutely no obligation of the original dev/owner to accept or engage with anything from the community. It's in the license, the software is provided as is and without warranty of any kind.
Maybe it's worthwhile to coin a new term, community software, to specifically make a distinction between projects that are community developed (accept contributions) vs those that don't.
krab · 46m ago
Wow, that's stretching it a bit, isn't it?
I'd say the spirit of open source is that others are free to modify the code and that's it. This requires a good license, the possibility to fork, some documentation and a way to build the project yourself.
But why would accepting contributions be required?
NewsaHackO · 15m ago
A lot of people are very entitled. They think that an open-source project gives the right to make request/demand of the project. Even if they are willing to write the contribution themselves, they still think they have the right to have their pull request accepted. They forget that 1) it may be outside the scope of the project, and 2) the project owners are going to be the ones that have to actually maintain the code they commit. Crazy stuff.
neongreen · 1h ago
I have the same feeling. I got used to infrastructure being run as a democracy, not merely “source available under GPL/BSD/MIT”. (It’s a big thing to want, sure, but I don’t mind wanting big things.)
thewebguyd · 30m ago
IMO, no. The open source definition says nothing about requiring outside contributions, and IMO the spirit of it in the beginning was never about that.
It was about being able to have access to, fork/modify, and redistribute the software. That's the important thing - that the software I use can be modified by me, and if I wish to do so, the license allows me to then redistribute those changes vs. proprietary software, which cannot be modified nor redistributed.
I'm not sure why the zeitgeist went from the above and turned into "all open source must be community software and engage with users and accept contributions" because that was never what it was about. It was a benefit of some projects, sure, but at the end of the day the important thing isn't whether or not the project accepts contributions but whether I have the power and license to modify something to my liking, fork it if I wash, and/or redistribute my changes.
cess11 · 20m ago
No, but you've deliberately chosen to not make it free software.
munchler · 3h ago
How is that "fake"? There's no requirement that an open source project take contributions from outsiders at all.
justin66 · 3h ago
This notion that open source projects aren't really open source unless they welcome all contributions is one of the dumber ideas in the world.
glenngillen · 1h ago
Having worked a few places that have major open source projects, it was eye opening to see how pervasive this seems to have become. It feels like over my lifetime I've watched the value/expectations/demands/definition of OSS shift from "source is available, and I can make changes to my own copy/fork of of it if required" to "source is available, and I will demand you make changes to it for me"
Alupis · 1h ago
> source is available, and I will demand you make changes to it for me
There seems to be a disconnect here. I agree, demanding someone else make changes for you is in poor taste. The issue is, some of these projects advertise themselves as being open source while having no meaningful way to contribute changes back upstream - ie. the spirit of open source.
If I use your program for free, and encounter a bug, I should be able to fix it and contribute that back upstream so everyone benefits. That's my way of "paying back" and helping the community. Projects that reject contributions, or make contributing difficult are not in the spirit of open source, even if they are technically open source via their license.
That's what I call "fake" open source - you want the positive image of being Open Source only.
toast0 · 21m ago
> There seems to be a disconnect here. I agree, demanding someone else make changes for you is in poor taste. The issue is, some of these projects advertise themselves as being open source while having no meaningful way to contribute changes back upstream - ie. the spirit of open source.
I mean, you're not demanding someone else make the changes. You're only demanding that they engage and build a community around their project and all that entails.
As long as the license is reasonable, anybody else could pick up the project and do the community building around it. Apache HTTP Server developed around community patches to NCSA httpd. I don't think hitch (from the people who brought you Varnish) is well know, but it started as stud with community patches. If something like this takes off, the originator will either start taking the community patches too, or not; it's their choice.
In the meantime, as a user, I get the benefit of whatever changes the origin provides and I can patch it as I want, and fix up problems that I see. That works for code dump open source and community open source,.
neonsunset · 3h ago
Garnet has a discord server and has been actively accepting community PRs, so I don’t know what kind of nonsense you are on about.
What is it with .NET that compels you to lie?
Also FOSS and open contribution are different things, as sibling comment notes.
cess11 · 21m ago
MIT license is not FOSS, it's OSS at best.
neonsunset · 9m ago
MIT is one of the least restrictive licenses.
If you think otherwise, I suggest checking if there's any aluminium foil on your head.
ipaddr · 1h ago
What stops them from doing the exact same thing
KomoD · 3h ago
I don't, would you like to explain?
cess11 · 23m ago
It's controlled by an even larger and much, much nastier corporation.
andix · 8m ago
If you contributed before the license change/fork, you've also contributed to valkey and redict ;)
homebrewer · 4h ago
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.
KZerda · 1h ago
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.
NewsaHackO · 2m ago
? How did MongoDB rug pull?
pcthrowaway · 2h ago
You do realize the owners of the copyright can relicense it under any terms they want, even if it's a copyleft license like GPL, right?
arghwhat · 2h ago
Unless a CLA transfers copyright to the project owner, the copyright owners are every historical contributor to the project. Each contribution is owned by the contributor alone and they alone are able to grant rights to it.
A CLA often tries to mitigate this by making contributors give the project owners special rights at the time of contribution.
(Note that even if relicensed, this itself can never revoke licenses granted for prior versions unless that license specifically had revocation written into it.)
echelon · 3h ago
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.
tough · 3h ago
It's sad as an open source lover how money fucks it all
echelon · 3h ago
If you open source something, the rich trillion dollar companies just steal it.
If you're okay with that, that's cool. But they'll profit off of your work and labor. And the worst part is that at scale, the advantages of the sum total of open source is used to compete with you and put price pressure on your salary and career options. To rephrase that, the hyperscalers are in a position to leverage open source to take advantage of market opportunities you cannot, and they can use that to compete with your business or competing businesses that might otherwise pay you better.
Open source needs anti-Google/Amazon/Microsoft clauses.
tough · 3h ago
doesn't the Affero GPL v3 cover this? have seen some projects use it, I think it limits the server run parts of the software etc
echelon · 1h ago
Yes, it does! The "problem" with AGPL3 is that it has no carve-out for companies smaller than Amazon, Microsoft, or Google. If you use AGPL, you have to open source your entire stack.
Not everyone thinks infectious copyleft / free software is a problem. But it will mean that if you use AGPL3, every part of your stack has to be open. That doesn't work for everyone.
This is why "equitable source" / "fair source" is gaining traction. You can use a license like Apache and add in clauses with MAU/ARR/Hyperscaler limits that allows practically everyone else to use your software.
papashell · 1h ago
AGPL doesn’t require you to open source the entire stack. Only the changes you made to the AGPL software if you interact with over a network
AGPL does not and has not prevented hyperscalers from creating managed services for software licensed with it
That’s why mongo created the server side public license, which does require open sourcing the entire stack. MongoDB was AGPL before that
dharmab · 2h ago
There are good legal reasons to avoid the GPL; there are open legal questions about whether the GPL and its variants are enforceable.
tasuki · 1h ago
> 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?
lolinder · 1h ago
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.
A contributor license agreement that does anything besides put your code under the project's standard OSS license is a huge red flag.
assassinator42 · 3m ago
I took a bit of umbrage with LineageOS for this.
CyanogenMod required a CLA to assign them copyright to Cyanogen Inc, only for them to basically kill the project. They forked it as LineageOS only to still require a CLA.
weinzierl · 4h ago
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.
yjftsjthsd-h · 3h ago
> The transitions Redis made are pristine on a legal
Yes, of course.
> and moral level. Feeling betrayed is absolutely uncalled for.
Er, no, that's an unsubstantiated leap.
bornfreddy · 1h ago
Not sure why Redis is blamed for the "rug pull". They didn't relicense the old versions. They just said "sorry guys, we don't want to support this project under those terms anymore". They are under no obligation to do that, legal or moral. Don't like it? No problem, fork it and maintain it yourself (as many did). But don't demand of others to continue to support the project under those terms if they do not want to. This is FOSS working as intended.
All those people that contributed, did so to the FOSS version. Their contributions live on in all the forks, both FOSS and proprietary (by Amazon & co., and Redis before today). So not sure where "betrayal" supposedly happened. Maybe when Amazon used their contributions too?
They already had made a strong statement by choosing BSD when GPL was at their disposal. That is a much stronger statement than some blog post that reflects a momentary snapshot of their plans.
It is just that people don't hear what they don't want to hear. Every BSD or MIT is a loud and clear statement to deny the guarantee that derivative works will remain free and open.
tough · 3h ago
People and companies are allowed to change opinions, why would anyone blame Redis or Elastic instead of Amazon for taking it all?
echoangle · 3h ago
Because Redis said they would never do something and then changed their mind (which makes the whole concept of saying you will never do something useless), while Amazon never said they wouldn’t use open source software for free (which is their right).
tough · 3h ago
I'd still trust more antirez than amazon as entities.
Never trust a company.
echoangle · 2h ago
What does trusting antirez help me if he’s working for another company?
orthecreedence · 3h ago
You're not arguing for the honesty of individual companies, you're arguing against the profit mechanism.
simonw · 2h ago
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".
I'm delighted. Thank you, team Redis.
antirez · 2h ago
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.
lolinder · 2h ago
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.
antirez · 1h ago
I said exactly that's a win of the community. But money are needed to pay the folks that work at open source software, and the companies that went for the SSPL were trying to protect their business (and, as a side effect, wanted or not, the ability to pay for such work). I believe the software world failed to protect open source software in the cloud era, but in general the environment that we collectively created made the open source software won.
lolinder · 1h ago
I don't buy that justification. These two companies (and the others like them) set up a model for funding their business knowing full well that they would have to compete with others who were able to provide the same service they were. That's always been baked into FOSS—you can't plan around a monopoly when you're releasing your code for free, that's part of the trade-off you make.
When AWS and Co did provide hosting and provided it better than these guys could, now it's suddenly AWS who are the bad guys for using the FOSS software the way the license always said they could. Now we're suddenly supposed to ignore the terms on which FOSS has always been released and pick up our pitchforks against the big mean cloud provider.
Instead of sticking to the fundamental principles of FOSS (principles which they won business by openly espousing) and adapting their business to the fact that Elastic and Redis lost in the competition they knowingly set up, they fixated on hosting (on top of AWS and Co, no less!) as the business model and changed the licenses to give themselves a monopoly on it.
jimbokun · 30m ago
There is no possible way to compete against someone else who doesn't need to fund the development of the software but can still take in all the revenues and profits from deploying it as a service.
lolinder · 28m ago
But that has always been true, from the beginning. It's baked in to the FOSS model and always has been.
If the companies had made a bad call in structuring their business and owned up to it I think we'd be having a very different conversation than we are. We're here because they failed to own up to it and instead tried to get people to raise pitchforks against AWS. Never mind that their intended model was the obviously doomed model of reselling AWS's hosting with a commission on top, and never mind that it was the trade-off they chose when they chose to release their software as FOSS and get the boost in adoption that comes with.
I do fully agree with antirez above that we need a new plan for funding FOSS. But I think that's a poor justification for the rug pulling and vilifying that the existing companies did.
primitivesuave · 38m ago
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.
simonw · 3h ago
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.)
No comments yet
placatedmayhem · 4h ago
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!
cortesoft · 3h ago
We kept using redis, the license change never affected us. We had no reason to switch.
ketzo · 2h ago
I imagine there is quite a large, quiet fraction (majority) of users who were the same way.
Not to say it’s not an important discussion!
Alupis · 1h ago
Many people switched to Valkey and didn't even know it. A lot like how many users are using MariaDB but think they are using MySQL.
Several major linux distros transparently switched to Valkey and the users are none-the-wiser. On Fedora, for example, doing `sudo dnf install redis` just installs Valkey.
sigzero · 1h ago
Well that's a reason not to use a distro right? If I type `sudo dnf install redis`, I want to install redis not valkey.
Xunjin · 56m ago
I understand your point, but that's how distros handles mostly licence issues. And I do believe that's the right way, we should strive for OSS projects in a distro that literally focuses on it.
gkbrk · 1h ago
If I update my packages and suddenly an open-source software is replaced with a closed-source one, I would blame my distro. It's totally normal for distros to replace packages like this with the best replacement they have.
Alupis · 1h ago
I disagree probably because I'm just used to it. Most of your major distros do this, including Fedora and Debian (the two largest). Usually this is due to license issues.
dharmab · 2h ago
From the blog post it seems like existing users kept using Redis but new users adopted alternatives instead.
zimpenfish · 49m ago
> it seems like existing users kept using Redis
Redis user since it appeared and I switched my servers (~15) to Valkey - partially because of the shenanigans, partially because Arch is moving Redis to archive.
ramon156 · 2h ago
Same here. The response from the community was valid, but basically didn't affect us.
ksec · 4h ago
I am thinking the same that going to AGPL may actually push more people to Valkey.
Although I haven't checked if ValKey any substantial development since the fork.
reconditerose · 4h ago
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.
Valkey has RDMA support, which offers significant performance improvements.
seneca · 3h ago
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.
antirez · 1h ago
The team of sales was, AFAIK, rebuilt from scratch recently. Please if this happened recently tell me, and I'll make sure to report back. Thanks.
kiitos · 4h ago
Statistically nobody is using valkey.
cyrnel · 3h ago
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.
kiitos · 3h ago
Sure, but the impact of new customers and their decisions take a long time before they impact net statistics. All evidence I can find, regardless of domain or context, suggests Redis vs. valkey marketshare is something around a 99%/1% difference.
rustc · 3h ago
> All evidence I can find, regardless of domain or context, suggests Redis vs. valkey marketshare is something around a 99%/1% difference.
What evidence did you find?
kiitos · 2h ago
Ask the LLM of your choice the following question: "Among the top cloud service providers, for product offerings that can be implemented by Redis or valkey, based on all available evidence, what is the relative market share and/or usage of Redis vs. valkey?"
foobarchu · 2h ago
LLMs are not a source.
Tostino · 2h ago
Why/how would you expect an LLM to know that info?
_msw_ · 3h ago
If you use the latest versions of Redis, you are benefiting from the continued efforts of the Valkey development community. [1]
I wonder how that works legally with CLA. If the person who originally wrote the code is not the one who signs off the PR. I assume the lawyers have signed off on it.
Did they maintain the author's copyright notice as required by BSD-3?
darkwater · 44m ago
Well, now that Redis is once again Open Source and even Free Software, that should change.
jzb · 2h ago
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?
rmsaksida · 3h ago
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.
echoangle · 3h ago
Are there usage stats available? How do you know this?
achillean · 23m ago
Based on Internet-accessible services the number of Valkey servers is low (~120):
Without sources, it's a "statistically worthless" comment :)
Osiris · 3h ago
My guess is most people are using Redis via cloud providers. Did any cloud providers switch away from Redis?
andenacitelli · 3h ago
AWS supports Valkey for Elasticache, and they actually bill it 33% cheaper. We use it and it works well.
pjm331 · 3h ago
AWS Elasticache gave a nice discount to switch to valkey w/ 1 button click no downtime migration path
aweiher · 3h ago
ValKey is cheaper in AWS than Reddis
echoangle · 3h ago
Wasn’t the whole point (or one of the major ones) of Valkey so that AWS could use it?
oweiler · 2h ago
Yet. It's a drop-in replacement, and both faster and cheaper.
shaky-carrousel · 3h ago
Yeah, all the open source distributions and most open source projects switching to valkey must be "nobody".
teaearlgraycold · 3h ago
I don't know about valkey but I got word Nvidia was switching away from Redis.
VWWHFSfQ · 4h ago
I very much doubt that anyone will stick with valkey after the PaaS providers switch back to just offering Redis proper.
md3911027514 · 4h ago
Why would PaaS providers switch back to offering Redis? They've clearly all already invested a lot in Valkey (AWS, GCP, Heroku).
antirez · 4h ago
AWS, GCP, surely are invested: they paid for ValKey, they forked to avoid doing revenue sharing with Redis in any way :D IMHO it's a matter of what the community does, and it, in turn, this depends on how well we are able to develop Redis.
It's not just licensing and hyper-scalers, it's also a matter of development quality and direction. For instance, now in Redis you can find substantial more stuff not available in ValKey, including hash items expires, Vector Sets that are very useful for a number of things, the probabilistic data structures just introduced with Redis 8, and so forth.
No comments yet
lotharcable · 4h ago
If Redis is superior then sticking with Valkey would just be throwing good money after bad. Hopefully those companies are competent enough to understand the concept of sunk costs.
Maybe Valkey has served its purpose in pressuring Redis into playing ball.
Just answering "why would". Whether or not Redis is better then Valkey or if it would be worth it to switch back is not something I know.
kiitos · 3h ago
AWS and GCP offer valkey-based versions of products that are typically based on Redis, but those versions are currently, generally, preview-grade, and statistically zero customers are using them. They still offer the original, Redis-based versions of those products, which, statistically, 100% of their customers are using.
reconditerose · 3h ago
Do you have data to back up your claims? I see a lot of customer claims for Valkey here, https://aws.amazon.com/elasticache/customers/. Neither of the AWS or GCP offerings are in preview.
ziddoap · 3h ago
>and statistically zero customers are using them
You've said this twice now, but not provided any data or even a hand-wave to a possible source so that others could go get the data and look at it.
If it's statistically something, where are the stats?
kiitos · 3h ago
valkey was introduced as an opt-in alternative to Redis as an implementation choice for specific products offered by the the major cloud providers approximately 9 months ago. Generally valkey is shown as a preview or beta or whatever option. Nobody has performed any kind of automatic or default transition from Redis to valkey for existing customers.
My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
ziddoap · 3h ago
>My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
I have no idea what the actual stats are. But no, I don't find your "statistically 0%" to be self-evident, especially in light of the other comments and links in this thread, and what I've heard elsewhere.
I was hoping, since you presented it so confidently, that you had something more than "trust me". In another comment you say you have evidence of marketshare, maybe you could post that?
My stats are not "I asked an LLM", that was a response I gave to a specific comment, go away
ziddoap · 1h ago
If your stats aren't from "trust me" or an LLM, can you please just post where you are getting your market share stats from?
kevinsf90 · 2h ago
I recently moved on to a new company, but my prior company had a pretty large scale Elasticache Redis deployment in production (over 50 large clusters in us-east-1), and were in the middle of a complete migration to Valkey due cost savings, improved performance, and reduction in memory usage.
We've already completed migrating several large production clusters and I can confidently say that the migration had been pretty smooth and seamless.
Valkey is certainly production ready (at least on AWS it is). The team is looking forward to expedite and complete the migration
AustinWentz · 3h ago
>Nobody has performed any kind of automatic or default transition from Redis to valkey for existing customers.
>My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
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.
antirez · 4h ago
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.
wg0 · 2h ago
Redis is in SQLite and Wireguard league of simplicity and elegance.
md3911027514 · 4h ago
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.
benwilber0 · 4h ago
Your company invested hundreds of engineering hours switching from Redis to a clean fork of Redis?
cogman10 · 4h ago
I can easily see this for a midsize company.
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.
JamesSwift · 2h ago
My understanding is that Valkey was forked directly from redis. So assuming you migrate at the forks point-in-time, then it literally is the same code.
terminalbraid · 2h ago
Yes, but not the same infrastructure and configuration and documentation. Any reasonable operation will also do validation and assurance. That adds up if you have a sizable operation. "Hundreds of hours" is also not some enormous scale for operations that, say, have lots of employees, lots of data, and lots of instances.
The part you are thinking of is not the time consuming part.
txcwg002 · 3h ago
I believe it. There are companies that invested hundreds of engineering hours to rename master to main.
brookst · 4h ago
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.
benwilber0 · 3h ago
But why are they spending any time switching away from Redis at all unless they are a hosting provider offering Redis-as-a-service?
I wasn't aware the license had any negative affect on private internal use.
twoodfin · 3h ago
The negative effect is that you have to bring the lawyers back in, and they tend to take an extremely conservative position on what might be litigated as offering “Redis-as-a-service”.
ukuina · 3h ago
Many legal departments cannot afford nuance when a newsworthy license change occurs. The kneejerk reaction is to switch away to mitigate any business risk.
freeAgent · 2h ago
I doubt having lawyers review your usage is more expensive than spending hundreds of hours of dev time to migrate.
stackskipton · 3h ago
Our lawyers looked at SSPL since we do host software for customers and it does use Redis and went "Eh, this is as clear as mud." so Valkey it is!
md3911027514 · 4h ago
By switch I mean that all new projects use Valkey instead of Redis, and we've invested hundreds of hours into those new projects.
mperham · 3h ago
There are companies using many thousands of Redis instances storing petabytes of data with millions of users.
Now consider a no-down-time migration. How long do you think that'll take to engineer and execute?
dbacar · 3h ago
Even the infrastructure switch and testing should take a lot of time, yet the application level tests etc.
edoceo · 4h ago
What? Isn't Valkey a "drop in" replacement? I switched a couple of deployment, it "just worked" but maybe I'm just too simple.
tinix · 4h ago
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?
Twirrim · 3h ago
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?
poincaredisk · 3h ago
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.
tuckerman · 4h ago
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.
md3911027514 · 4h ago
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.
rustc · 3h ago
They still require a CLA [1] so there's nothing stopping them from doing another relicense to a proprietary license tomorrow.
The only way this remains open source forever is to accept AGPL-only licensed patches.
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.
otterley · 2h ago
If there's a lesson to be learned from this drama, it's that changing a software license from a liberal open-source one to a anti-competitive one (even if the source is still available and open to contribution) is a one-way door and loses trust. Once done, even if you recognize your error and revert the license, you're not getting that trust back.
freeAgent · 2h ago
The announcement just happened. I don’t know that we know the results yet.
lolinder · 2h ago
Elastic announced they were switching back a few months ago, we should be able to measure the results by now.
DetroitThrow · 4h ago
I think the big drop in trust was the change in licensing away from permissive in the first place, but AGPL-today is a much better choice than SSPL-forever.
You probably can't recover from a loss of trust in low single digit years unfortunately, but this is a good first step towards the project rebuilding the OSS community that existed around redis initially.
Thanks for fighting for this. Hopefully this shows more companies stuck on source-available that you can achieve similar goals with OSS licenses.
theturtletalks · 1h ago
When Antirez left Redis, he wrote an amazing blog post I go back to often [0]. In there he said:
"I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer."
I'm glad Antirez was seeing his art losing it's beauty and now, is reclaiming it!
This doesn't solve anything, Redis has proved that it is willing to do a rug pull, and how much they are willing to hurt the community when they do (taking over client libraries, etc). I don't see a reason to go back from valkey. Again and again, Redis Labs has been the worst thing about Redis, I'm glad we now have an other option.
rdtsc · 3h ago
That's great news. I never liked the newly sprung up licenses. I understand the background but always felt a burden having to read and understand them, and wonder how they'd hold up in practice. GPL licenses have been around for decades and is something people, including legal teams, know more about.
And when I say "know", I don't mean "like": it could be that this will just make it easier for a particular team to decide that it doesn't want to deal with the AGPL, and they should go find something else, but at least it's clear what it is. As opposed to some BSSXYZWL license that you never heard of, which kind sounds like it's open source but kind of isn't...
tombert · 3h ago
I fairly recently dodge a bullet; I rewrote a large chunk of code I was working on using Akka because my idea lent itself fairly well to an actor system. I got it working fine with Akka on my local machine, I was about to make a PR for it at work, and then saw that it was using BUSL instead of Apache, which I had assumed it was using (since a lot of stuff in the Java world seems to use Apache).
I did get my stuff working with Pekko (the Apache fork of Akka), and it did work, but I was so pissed off at the entirety of this that I ended up rewriting the entire thing again using Vert.x, which I double checked the license for before doing more work.
I do understand why Akka feels like they have to use something like BUSL, it's hard to make money as a smaller software company, doubly so for open source software, and I also realize me complaining that "this free product made with free labor isn't free enough for me" is pretty entitled, but fundamentally I really don't think that the BUSL (and its similar licenses) are the right way forward. Whether or not it's fair, stuff like Akka does have competition from stuff that has more OSS-friendly stuff, and fundamentally I'm just going to use those, and if they're not up to snuff I'll augment them myself.
antirez · 3h ago
That's a good point, traditional OSS licenses, we can like them or not, but they are "understood".
Sounds like SSPL did not yield the desired outcome.
Glad AGPL is an option now.
ocdtrekkie · 3h ago
It did yield the desired outcome: Google and AWS are no longer using it.
jillesvangurp · 1h ago
If by desired outcome you mean split the developer community and then chase them away to a newly forked competitor that is now widely used by all the cloud providers and users that prefer open source; complete success!
But I doubt that was the outcome that they hoped for. They created a large and successful competitor that by nature of being a fork does exactly the same thing. It's pretty hard to compete with yourself and the differentiate from your own product.
Honestly, I think Redis Inc. was better off when there was just one code base. AGPL just marginalizes them further. It's not an acceptable license for many corporate legal departments. So, it would necessitate buying a commercial license for such companies. I.e. Fortune 500 companies, public companies, and pretty much anything with a legal department worthy of the name. Note how Redis advertises AGPLv3 as "one" of the available licenses. The whole point of that license is selling commercial licenses.
Valkey is at this point stable and supported and a drop in replacement. It's pretty much the default choice for anyone not interested in buying a commercial license. That genie isn't going back in the bottle with this license choice.
More importantly, Valkey is a pretty active Github project with dozens of contributors in the last month. More than double those in Redis. Those commits aren't going to Redis. And Redis still requires the right to re-license your commits if you try to contribute. That's how they were able to pull this stunt to begin with. I doubt a lot of the Valkey contributors will be moving back to that status quo.
ibnurasikh · 4h ago
Gladly, Valkey has other benefits besides its more permissive license compared to Redis. One of them is multi-threading support, which makes it pretty easy for someone like me—who has a bit of a skill issue with DevOps—to actually utilize all CPU cores for my caching layer.
antirez · 4h ago
The I/O threading was initially implemented by myself, when I was still working on the core before rejoining, and is also available in Redis. So this is actually another case of the benefits ValKey got for being able to clone Redis, receiving money from the hyper-scalers that just want to maximize their revenues...
They made certain improvements later, but Redis 8 (see the release notes in my blog post if you are curious) improved this stuff a lot, too.
Also, Redis 8 contains a new data structure, Vector Sets, that allows to do many useful things, together with more probabilistic data structures, single hash fields expires, and many other stuff. It is not factually correct that ValKey has any features edge over Redis I believe. We will see in the next year which project takes the best development path: this is what really matters.
reconditerose · 3h ago
The Valkey implementation of multi-threading is fundamentally different than what existed in Redis. The history dates back to work done in ElastiCache that was released as "Enhanced IO", https://aws.amazon.com/about-aws/whats-new/2019/03/amazon-el.... The version released in Redis could only do about 350k RPS because of poor memory locality of operations, the inability to do command processing while handling I/O, and the inability to offload much of the TCP read path. The new version in Valkey can achieve 1.2M RPS.
"They made certain improvements later", should be "we threw away the old implementation and built a better one."
antirez · 3h ago
1. The fundamental idea was mine. Ideas can be improved, of course, and that's good. That was my point. However, allow me to say that Redis is fundamentally a "software of ideas" than anything else. Technologically it is far from impressive (Redis, ValKey, all the forks).
2. Redis 8 improves the same idea, too, released today.
3. If you claim [in a different comment here] you provided a lot of code to Redis, why you didn't send a pull request for that? So, you are practically saying you were using, at Amazon, all the BSD code we provided, but could not provide an important part of the code to us? You see how broken such model was? At least stop defending it.
4. We can now copy the implementation: the parts are reversed (the irony!), and your code is BSD as our was for 15 years. When we avoid doing things like that, is because we have issues with how certain things were made.
5. I don't understand the motivations of you and other AWS people commenting here today. You work for a company that is creating issues to the OSS ecosystem: this is hard to deny. You cloned (and, yes, the license allowed for it) the code of Redis, and work on it so that hyperscalers can continued to do what they used to do. We bring Redis back to AGPL, and you are here to do the interests of Amazon in the comments. Did you see me commenting your stuff, when you release your things, with comments like "ah! But this is unfair"?
There is to make choices. I understand that it was cool to continue to work at a Redis fork, and part of the incredible thing open source is, is that forks survive in the hands of different teams (but design ideas can be misunderstood and projects may turn into other projects). So if you are happy to hack on ValKey, I hope you'll have the best experience out of it. But there is to make choices on how/when to interact.
_msw_ · 3h ago
This exchange makes me sad. I know we can do better.
I don't understand why so many people think that it's impossible to have open source in your heart while working for a big company in your day job. I don't understand why people who have dedicated a lot of their time and emotional energy to keep open source ways alive and help build a community effort are attacked because they work for a company that needs to be made the villain in the narrative.
Of course Redis is free to copy BSD licensed code that Valkey contributors add to the project [1]. I only wish that the blog post about this advancement in Redis would give some credit, rather than claiming "We also improved the performance of CRC64 calculations" [2].
We can all do better, and engage with one another with mutual respect and admiration for what has been freely given.
> I don't understand why so many people think that it's impossible to have open source in your heart while working for a big company in your day job.
Because a big company like Amazon has produced almost no open source work(yes some random collection of repos and 2 PRs here and there is not the same thing) compared to how much it has benefited from open source. (I know I know OSS allows for all that so not claiming anything wrong). But it does show what the company policy must be towards open source (Consume all you can, contribute only when absolutely essential for the company barring exceptional circumstances).
> I don't understand why people who have dedicated a lot of their time and emotional energy to keep open source ways alive and help build a community effort are attacked because they work for a company that needs to be made the villain in the narrative.
Antirez is not attacking anyone above. English is not his first language and he is just putting out some of his thoughts (which people are free to disagree with but those are what he thinks), like how you casually slipped that you didn't get credit for one commit copied from valkey (where the copier is giving due credit in the PR by linking the source PR and the authors inline). So they copied a PR from valkey, and the redis blog post should give lots and lots of credits? If that was the standard, so many of AWS services will spend all their reinvent time giving credits to their source OSS projects.
jimbokun · 25m ago
> I don't understand why so many people think that it's impossible to have open source in your heart while working for a big company in your day job.
The employment contract you signed.
reconditerose · 2h ago
> So, you are practically saying you were using, at Amazon, all the BSD code we provided, provide an important part of the code to us? You see how broken such model was? At least stop defending it.
I'm not defending it, I'm trying to fix it. I want Amazon to contribute back. That's what I spend most of my time doing, but I can't just sit in a meeting and tell people we should give away code. It takes time to convince people that we should collaborate on the core and just compete on what we want to differentiate on. It takes time to convince people that building open-source in a vendor neutral space makes software that is better for everyone.
I hope that makes sense.
antirez · 2h ago
Yes, makes sense. Thanks for the reply.
_Wintermute · 2h ago
This comment has inspired me to switch to Valkey, thanks.
antirez · 2h ago
You have all the rights. Usually I do my best to avoid confrontations of that kind, and to respect the work of others. But I see certain communication patterns that are, for me, too much, and I needed to tell it. I think go on HN, and comment in an aggressive way the work of competitors, during announcements days, is something fundamentally wrong.
crop_rotation · 25m ago
On the contrary it has made me appreciate antirez even more not just as a developer but as a true champion of open source who really wants open source to prosper and is willing to voice his opinions whenever required.
yjftsjthsd-h · 3h ago
> So this is actually another case of the benefits ValKey got for being able to clone Redis, receiving money from the hyper-scalers that just want to maximize their revenues...
I don't think you want to sling that mud, unless Redis switched to being a nonprofit when I wasn't looking.
WD-42 · 3h ago
They aren't really comparable and you know that.
yjftsjthsd-h · 3h ago
They are and you shouldn't claim bad faith without very good reason.
Zambyte · 4h ago
Very interesting that this is happening at the same time that NATS is going proprietary. Obviously Redis is way more well known, but as someone who has built a bunch on NATS over the last few years, this makes Redis an interesting choice to migrate to again.
I also built a lot on NATS Jetstream, and I'm questioning my decision in light of the threatened license change.
nchmy · 3h ago
apparently synadia is working with the linux foundation now to find a better way forward, and will release a joint statement soon. (CEO mentioned in their slack)
Zambyte · 3h ago
Cool, I'm definitely hoping for a sensible outcome. NATS has been a great tool to work with, and Synadia has also been great to work with.
linotype · 4h ago
No thanks, going to stick with Valkey for all future projects.
After what Mullenweg has pulled, in the era of Blogging CEOs I have to be cynical.
Valkey.
kstrauser · 3h ago
Heh! While I appreciate what you're saying, I see this as the opposite of WordPress. It's basically a CEO saying oops, we messed up, let's fix this, which is fundamentally different than doubling down and ending up in court.
bravetraveler · 3h ago
Oh, I agree... I want to be wrong
kstrauser · 3h ago
I hope you are, too. Don't mistake my optimism for complete confidence.
mmaunder · 4h ago
Here's the play: Open source with AGPL, then offer an enterprise license. You get two wins. The OSS community applauds your adoption of an agressive OSS license. Enterprise customers can't use software under AGPL because it risks infecting their IP, so they're forced to buy an enterprise license.
kstrauser · 3h ago
> Enterprise customers can't use software under AGPL because it risks infecting their IP
This is factually untrue. If you want to link an AGPL blob into your app and ship it to customers, sure. In the vastly more common case where you're using a permissive client library[0] to connect to an AGPL server, there's no risk whatsoever.
At most, you might need to make your local changes to that server available to clients if they connect to it directly, as opposed to hosting a cloud SaaS setup where everything is internal to you. However, that's not the worst thing in the world. "Oh no, we improved a Free server our company depends on, and we have to share those improvements so that the person who gave us the server for free can also benefit from them" is pretty hard for me to sympathize with.
This is vastly more business-friendly than the non-FOSS SSPL.
Wait, AGPL is a good license for enterprise, they don’t need to buy unless they want to modify source without releasing, am I wrong about this?
Edit: Doubled checked with gpt, no cases of “infection” yet, there has also been many talks about this license being very good
immibis · 3h ago
The goal of free software (noting that "open source" is a watered down version of "free software") is for everyone to share their sohrce code. To that end, licenses that require sharing of source code are used. LGPL says, roughly, you must share the source code of this software to anyone you shared the binary to. GPL is more extensive: anyone you shared the binary or the binary of something built on this software to. AGPL is even more aggressive: anyone you shared it to or gave access to it over a network. And SSPL is currently the most aggressive: you have to share the whole thing you built, not just what's linked with this software.
The more aggressive a license you pick, the more likely a corporation won't want to use it. But that's by design. They're allowed to use it, even commercially - they just have to give the source code back. If the software is useful enough, they will. We should make software useful enough for corporations to consider the be benefits of using it to outweigh the cost of having to share their source code. (Also the more source you make them share, the less likely this is. The Linux kernel succeeded at this.
SSPL is controversial and untested (and goes against the business interests of the OSI so will never be box-tick certified compliant) and likely counterproductive if it means you have to share things like Windows. AGPL is the normal "aggressively free" license. GPL is mostly for those who haven't discovered AGPL yet and MIT is for those who don't agree in the goal of source code freedom to begin with.
kstrauser · 3h ago
SSPL isn't recognized as either open source or free software. I don't think it earns being discussed in the same context.
bananapub · 3h ago
> Edit: Doubled checked with gpt, no cases of “infection” yet, there has also been many talks about this license being very good
what? why would you ask an LLM to generate some random text instead of looking up the actual answer?
umbra07 · 3h ago
the alternative is/was BSD.
enterprise hates AGPL. AGPL is generally not a serious alternative to BSD/MIT in corpoland, because something something (A)GPL-poisoning.
whether it's true or not doesn't matter. what matters is whether big tech considers AGPL infectious - which they do.
mperham · 3h ago
> Enterprise customers can't use software under AGPL because it risks infecting their IP
Yeah, this is BS.
If you simply use AGPL software, it doesn't "infect" anything. If you *change* the AGPL software, you have to release the changes. It forces the big clouds to open source their Redis improvements.
okanat · 2h ago
For the type of software that Redis is intended for, integration over network is a must. Hence "just using it" isn't a viable option. AGPL isn't LGPL, it infects anything that uses it over a network. If Redis was AGPL when it was released, nobody would touch it.
Most of the readers of HN make their living from closed source software. You know well enough that non-hostile open source is just a market entry strategy and the type of copyright-driven maximally selfish capitalist markets just force open source to be not viable for a single company to thrive. Projects like Linux kernel are exceptional infrastructure projects that external companies support not build businesses just to ship.
kstrauser · 1h ago
> Hence "just using it" isn't a viable option. AGPL isn't LGPL, it infects anything that uses it over a network.
This is completely, factually, unequivocally, incorrect.
You can connect to Redis using their first-party, MIT-licensed client library. You can write proprietary software using that library with no requirement whatsoever to release your software under any particular license (although of course you still have to comply with the MIT license's attribution requirements).
If all software connecting to the AGPL'd service runs internally, you're not obligated to share your local changes to that service. This covers the vast majority of use cases. Using WordPress with a Redis cache? This doesn't affect you.
If you host an AGPL'd version of a Redis server and your customers connect to it from their own networks, then the only obligation you have over the tried-and-true GPL is that you have to share changes you've made to your Redis server with users. If you use Redis packages as-is like almost everyone does, this doesn't affect you.
So literally the only people who have to care about Redis being under the AGPL now are those who don't want to pay Redis for a commercial license, who expose their Redis server to customers, and who've made local changes to their Redis server. Everyone else gets to keep using it like they always had.
doctoboggan · 3h ago
I think you are thinking of GPL. Many companies are happy to use AGPL licensed software in their stack.
kstrauser · 3h ago
I think you're thinking of the LGPL. The AGPL is basically GPL plus some additional requirements. I could see a company being OK with ~AGPL~ GPL but not ~GPL~ AGPL. I can't imagine the opposite.
Edit: Oops, typoed the license names.
mindB · 3h ago
I think you have a typo mixing up AGPL and GPL. I agree that it would be hard to imagine a company being okay with the AGPL but not the GPL. On the off-chance that it isn't a typo, could you explain why a company might be okay with AGPL but not GPL?
kstrauser · 3h ago
Oops, you're right. Yes. I could see them approving the GPL but not the AGPL. I can't imagine any company approving the AGPL but not the GPL.
infogulch · 4h ago
Congrats antirez! I'm sure this was a huge effort internally, and I hope the Redis team can be successful releasing software under SSPL+AGPL.
I am bit confused by the comments here. Sure, it remains to be seen whether Redis Ltd. can be trusted again, but cannot we just be a happy for a bit that we (again) have a good software under a free license?
rcarmo · 1h ago
Great to see this. 12 years ago I wrote https://github.com/rcarmo/miniredis during a very slow weekend where I both wanted to get a feel for the internals of how Redis worked and have a little PubSub server I could call my own.
I spent the entire weekend poring over the C code and found it some of the most beautiful C I'd ever read (ever since the heady years of SunOS), and now I feel I should at least go and update miniredis to asyncio/Python 3--for kicks...
eGQjxkKF6fif · 16m ago
Do it. I'm thinking of making one for node.
martinsnow · 1h ago
They can seriously screw themselves with the rugpull they made. I reported so many bugs and helped diagnose them in the sentinel module. Seriously fuck them.
foobarian · 1h ago
I'm happy to see the news after having a chance to look at sources more closely (for unrelated reasons). The Redis geohash/gis related implementation is such a pleasure to read.
umajho · 2h ago
MinIO also switched to AGPLv3 a while back, and they stated that “the AGPL license requires that all software connecting with MinIO be 100% open source for you/your users not to be in violation of the license.”[^1] Since Redis and MinIO are somewhat similar, (Both can be used to store and retrieve data. Redis uses a custom protocol, and MinIO uses an S3-compatible API.) Should I assume that this statement also applies to Redis?
I believe the AGPL doesn't actually require this, even though MinIO may think it does. I hope someone gets sued over this some day so we may find out
merb · 1h ago
It would not even make sense. Since you do not even always know what license the thing has you are connecting to. And not even the fsf sees it that way.
preisschild · 2h ago
> Should I assume that this statement also applies to Redis?
I dont think it applies to clients using the API at all. It just specifies that the modified source should be offered to clients connecting over the API, but not that the client itself has to be open source.
I think a project has to be Linux or Postgres big to really operate as open source. Why? Because cloud providers can easily sell your product and contribute nothing back. So, for anything < Postgres in size you need to create a new license to allow you to run a managed service. The problem is, with something like AGPL, companies that aren't selling your stuff (just using it), now need to release their stuff as AGPL as well. With so many things using Redis, it seems that millions of companies will now be in violation of the license agreement upon a given update in the future.
Personally, I think it is better just to call a spade a spade and release things with commercial licenses. Let all companies with < 1T market cap use your stuff for free. Companies that are making money will want a managed service or support anyway. Companies that want to host your stuff in their environment fall into the > $1T category.
The above is a bit of a strawman but what we really want is for valuable projects to continue to exist.
dec0dedab0de · 3h ago
So with redis being AGPL, who counts as a user?
If you have a webapp that uses redis on the backend for a task queue, do the users of the webapp count as users of redis, and you then have to provide source to redis? Is there a chance that you might have to release your apps code to be compliant?
skrebbel · 1h ago
I wonder whether they did deals with AWS and Google behinds the scenes. Something like "you poured money into Valkey, how about you give that kind of money to us instead and we'll switch to AGPL and you can stop confusing two customers with two practically identical but differently priced options". Could that ever work? (I have no idea)
Oh nice! Smart move then. Makes me wonder why they went with SSPL in the first place.
ksynwa · 2h ago
I ask this as a scrub end user. What are the implications of forking when it comes to a Redis? Specifically, what I am wondering about whether forks like valkey which are worked on by competent programmers[1] continue to be good choices or does Redis Inc. having founded redis give it a distict advantage?
[1] I am assuming this because valkey comes under the Linux Foundation umbrella.
tiffanyh · 4h ago
While I applaud the effort to repair developer trust, do note that many organizations prohibit the use of AGPL.
Linked below is Google's own stance on why AGPL is banned:
My personal opinion: we shouldn't let Google's bad policy poison our brains. The people who wrote that policy had their reasons for taking this position. It might have been the right thing for Google at the time the policy was written.
That doesn't mean it's the right position for you, or for every situation. Many organizations with a higher levels of maturity in open source matters will take a more nuanced approach when it comes to AGPLv3 licensed software.
vvillena · 3h ago
That's the license working as intended, isn't it?
WD-42 · 3h ago
So a hyperscaler bans the AGPL? Shocking.
Seems to be working as intended.
jraph · 3h ago
Their loss, at some point…
I'm quite fed up with this GAFAM FUD against the AGPL and the GPLv3.
Similar move to Elasticsearch, tacking on AGPL with their existing source available licenses. [1]
The products (commercialized open source) that are often chosen by and championed by developers as opposed to executives see the harm that a bait and switch has on their popularity. With their competitors being more permissive, I don't see many devs moving back unless Valkey loses significant feature parity.
Sure, but the damage is done already, and it's AGPL too.
MrFurious · 3h ago
I can understand problems with SSPL license, but i cannot understand the problems with AGPL. If you use software for your SAAS service for free, and made changes in it, you should share the changes with others. Is free software, not a gift for your business.
tonyhart7 · 1h ago
they realize that they dont have a "moat" and if entire industry try hard enough to replace them then its over for them
createaccount99 · 2h ago
AGPL + selling under other licenses seems to be the way
radium3d · 1h ago
Wow I chose to start using redis in the right week :)
eknkc · 4h ago
During this time I believe a lot of alternatives (mostly protocol compatible to redis so they would be drop in replacements) came into light.
Has there been a consensus on one? Is there a winner?
I love redis and will probably keep using it. Just curious.
DeepYogurt · 4h ago
Valkey has replaced redis in a few distros
ezekg · 4h ago
Also PaaS like Heroku adopted Valkey as a drop-in replacement for Redis.
eknkc · 4h ago
It is a fork of the latest oss release right? I thought some completely new implementations were introduced.
reconditerose · 4h ago
It's not just a fork, there have been two releases on Valkey that improved performance and memory efficiency. There is a lie that Redis likes to spread that only their own employees were working on the core engine at the time of the fork, but most of the engineers on Valkey came directly from having worked on Redis OSS. A recent example is we modernized the hash table a bit: https://valkey.io/blog/new-hash-table/.
antirez · 3h ago
Nobody wants to deny that Redis got from contribution from external developers. But it is fundamentally true that for like 8 years almost every substantial contribution was created by people working for Redis, and that later we got something that was still a small part compared to the total.
There are the commit histories, the GitHub contribution graphs. Everything is public. The current code base was written for the majority by a few single folks, for another small amount of the sum of all random people in the community, for a smaller part by people that now work at ValKey.
> It is also hard to reconcile the claims that cloud providers do not contribute with the actual commits to the Redis repository. A quick examination of the commits since the 7.0.0 release using gitdm shows 967 commits over that time period:
> Binbin Zhu, of Tencent, is responsible for nearly 25% of the commits to the project. Some of the contributors without a readily identifiable employer surely are Redis employees, but it's clear that the company has not been working alone.
antirez · 1h ago
If you go into the GitHub of any of the forks, and check the contribution page, you will see this data is not correct. Probably all my commits are into this "unknown", since I push with @gmail.com account without being part of any organization for most of the time.
This is likely some partial data of some specific fork or alike.
_msw_ · 17m ago
The LWN article is examining the 976 commits made after the 7.0.0 release. I don't think you had any commits during that time?
As is typical for software projects, early authors will be disproportionately represented in revision histories. I am still the #4 contributor to the Anaconda installer [1] originally used by Red Hat Linux, then RHEL, then Fedora, and others, despite not contributing to the code base for two decades.
Thanks, maybe this will be exemplary behavior for Elastic and Mongo.
eduction · 1h ago
I'm always grateful for open source code, but on AGPL I can only quote the lawyer Kyle Mitchell:
"Inebriated aliens might as well have beamed it down from space as a kind of practical joke..."
"It’s not just hard for lawyers, who have the legal picture and can parse the whole license very carefully without passing out...It’s also hard for hackers, even those familiar with free software lore, who lack the legal side of the picture and a sense of what other ways things might have been said. Imagine how people who don’t know software, law, legal drafting, software architecture, hacker culture, or the self-styled 'philosophical' musings of one Richard M. Stallman feel."
I'm bad at licenses, and I admit I don't completely get it. At first glance, it seems like a simpler more readable license that tries to accomplish something similar to AGPL. I think the "license terminates when you sue me for patent infringement" clause is nifty.
But it says that an "external deployment" counts as "distribution" (ok, fair), which means you must OSL-license your changes too (ok, fair too).
But how does that in practice prevent AWS and GCP from cloud-hosting your software without giving back? Seems to me that if Redis went OSL3, GCP could host it fine so long as they'd OSL3-distribute any changes they made.
threatofrain · 4h ago
Notably, Redis is about to sue Dragonfly for deliberate trademark confusion.
blotfaba · 4h ago
Hashtag #ThankYouValkey?
zoogeny · 3h ago
I am starting a new web app project and I wanted an in-memory store for session data. I just defaulted to Redis, literally yesterday doing the `npm install`.
I mean, I remembered the whole Valkey saga after the license switch. I guess I'm just not as ideological as some here? I just thought "I need a fast in memory object store" and went with Redis as my default. I treat it like an appliance within my infrastructure.
I also vaguely recall antirez going back to Redis (the company) during the AI boom to work on vector extensions to Redis. I believe he is a big part of why Redis is such a rock-solid piece of tech. I am more confident in this product with him influencing the trajectory.
I also have the decision on license in the back of my mind. As I said, I am not an OSS zealot, but I do like the idea of an OSS license that has some protection against someone completely ripping off the code with no recourse. AGPL might be a decent compromise, especially with a dual license.
bk496 · 3h ago
cool, does this means it works on Windows now?
revskill · 2h ago
Is it a business decision right ?
ezekg · 4h ago
Of course it's the AGPL, which is essentially the SSPL in practice.
ndiddy · 4h ago
The difference is how compliance is handled for cloud providers. Complying with the AGPL requires releasing the source code for the program you're hosting as a service. Complying with the SSPL requires releasing the source code for "all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software" under the terms of the SSPL. This is effectively impossible for any cloud provider to comply with (it would require a massive engineering effort to rewrite every single piece of software used to convey the service), which is why the OSI didn't approve it as an open source license.
kstrauser · 4h ago
Except that it’s actually open source.
ezekg · 4h ago
In word, but not in deed. I'll say it over and over again: COSS startups don't adopt the AGPL because they want to prioritize user freedom, they adopt it as a means of defense.
happymellon · 4h ago
Absolutely in deed.
Just because they don't have the same motives as you, doesn't stop it being a user freedom. Anything that shares the changes and improvements is a user improvement.
anticorporate · 1h ago
I don't really care why they adopt it, only that they do. AGPL is a license I can use, SSPL is not.
badmonster · 3h ago
great news
ingen0s · 1h ago
amen
mattl · 4h ago
Redis should step up and fund an independent foundation now and encourage Valkey to contribute where relevant.
Some code under a 3 clause BSD and some under AGPLv3 could be interesting.
_msw_ · 3h ago
Why? They can already just copy the code they want from Valkey, since Valkey is 3 clause BSD...
But maybe Valkey should switch to GPLv3 instead to correct this imbalance.
I am not sure what that would achieve? Combining programs under GPLv3 and AGPLv3 is possible (the resulting work is under AGPLv3).
jraph · 2h ago
The imbalance I think _msw_ refers to is the fact that Valkey couldn't both take code from a GPL-licenced Redis and keep its license.
So either they relicense, or they can't take code from Redis but Redis can take code from Valkey.
gray_-_wolf · 2h ago
I see, I misunderstood that. I have read it as an attempt to prevent redis taking the code from valkey.
However, if the intention was the other way (to allow valkey to take code from redis), valkey should just go for AGPL as well, there is little reason to pick GPL if the code sharing would be the motivation for the license change.
_msw_ · 2h ago
Disclaimer: I am not a lawyer, this is not legal advice.
In theory, one would not be able to offer a combined program under other licenses (in particular, RSALv2 and SSPLv1), as those licenses have conflicts with GPL obligations.
Direct contributions to the Redis project avoid this issue via a separate Contributor License Agreement. It would only mean that Redis developers could not unilaterally copy code from Valkey.
I'm not saying that the Valkey community should do this. Personally, I think it's better off as a BSD-3 licensed project, with the community fulfilling the promise made by others that it would always be that way.
edweis · 3h ago
Mesmerizing number of views. I must admin I refreshed the page multiple times to see the count increase. If I increased the view count several times, I must admin I did not read the article multiple times.
not_your_vase · 4h ago
This will be very relevant when Valkey decides to go closed source.
It's better than the previous state of course, but it would have been even better if the previous license change didn't happen.
As the french people say: fool me once, shame on you...
benatkin · 4h ago
fool me can't get fooled again
But in seriousness, the chances of valkey going closed source are low. It's run by Linux Foundation. It would be like suggesting that Node.js might go closed source...
Zambyte · 4h ago
They were obviously making a tongue in cheek comment instead of seriously suggesting Valkey may go proprietary.
benatkin · 3h ago
And it was so absurd that it didn't land with me, even though most of the time I notice these sorts of things. Ah well.
paavohtl · 4h ago
Valkey is a Linux Foundation project. Talking about license changes is just pure irrational FUD.
nailer · 3h ago
If you care about open source, and would like Llama 3 to also be open source (instead of the current license which, like Redis' SSPL, isn't, depite Meta saying it is), you might want to add your vote to:
The AGPL literally demands specific functionality be present in the software that cannot be removed without breaking the license. The anticapitalist FSF zealots got so in love with the idea of closing what they call "the ASP loophole" that they wrote themselves a EULA.
VWWHFSfQ · 4h ago
I'm guessing valkey will be dead now?
detaro · 4h ago
why? The investment into it has already been done, and quite a few places will be happier with its license still. I think enough has happened/too much time passed that its not a given everyone will just quietly move back to Redis.
dismalaf · 4h ago
AGPL is cancer. Valkey already exists, people already switched, it's already landed in a bunch of distros. I don't see anyone moving back, especially when Valkey has some big corporate support.
And for my personal usage, Rails 8 has moved Redis functionality into the database by default, which works fine.
antirez · 4h ago
RMS was enough of a genius to understand the potential of open source software, and basically gave us, with GPL and his evangelism (and his code! plenty of it), and the free software movement, the software world we are living now. AGPL reflects the fact that he understood before everybody else that something was happening with software as a service.
I love the BSD license, but now who says that AGPL is a cancer is making a big favor to the few huge companies that want to abuse the original dream that spawned modern and open software. Times changes, the best license to use change with times.
_msw_ · 2h ago
RMS was not convinced that the Affero clause was a good idea as a general rule, though he approved the Affero-sponsored fork of the GPL that created AGPLv1. Hence, he did not support the addition of network copyleft obligations in GPLv3 during its drafting.
RMS has long expressed concerns about "Service as a Software Substitute" [1], and I think he hesitated to endorse the AGPL because it would conflict with his philosophy on the dangers of "Service as a Software Substitute".
Henry Poole should be given credit for raising the concern; Bradley M. Kuhn and Eben Moglen should be given the credit for advancing the license to address the concern.
It took a long time for the Free Software Foundation to accept Affero versions of the GPL under their stewardship with the release of AGPLv3.
So, perhaps he did understand before many people that services posed some challenges for his social movement. But it's my belief that he favored self-reliance and maximum "freedom" by running computer programs on hardware you own yourself as the remedy, rather than extending copyleft obligations to reach over the network.
Good, you can think it is cancer and stay away from it. You don't like it, don't use it. It's like those bright colored poisonous frogs from the Amazon. That's better than some newly made up license that's different than anything else, and you have to wonder how it would hold up in practice.
dijit · 4h ago
AGPL is cancer[0] in exactly the same way GPL is cancer, in that it's intentionally designed to *BE* cancer (or, congenital at least).
If you modify GPL code you are expected to open source the changes, AGPL adapts that to the networked world, if you modify AGPL code to serve something, you should open source those changes too, otherwise you're violating the original spirit of GPL which was designed in a time that was not as perpetually internet (and SaaS) driven as today.
If you want a true free license, BSD or MIT have you covered, but then you shouldn't expect corporations to give back.
A good example of what happens if companies don't give back is Linux VS the various BSD's. BSD is a lot more popular in appliances than you might otherwise believe but the popularity is starting to wane as Linux (despite GPL) has improved so much with companies giving back that the "free license" BSD is no longer being seen as good enough in some cases. People do not tend to give back to the BSD's.
> Rails 8 has moved Redis functionality into the database by default, which works fine.
Databases could always do what redis did. Redis doesn't bring functionality to the table, it brings speed. If database caching, pub/sub, and streams are good enough for your use case, there was never a reason to pay for an extra instance just to stand up redis.
anonzzzies · 3h ago
Extra instance and developer overhead.
mattl · 4h ago
AGPL isn’t cancer. It’s a license that exists to solve a particular problem: the proliferation of free software in a world of network services.
If you don’t like it, don’t use AGPLv3 software. Those of us who do like it will keep writing AGPLv3 software.
immibis · 3h ago
Flagged for misleading headline. SSPL is open source. It's just not the open source you want.
It meets all the criteria and the only difference from AGPL is how much source code you have to release and when - which is also the difference between GPL and AGPL. It has problems, but being closed source isn't one of them.
The OSI will never certify it, of course, because that would go against the business interests of the OSI members. The OSI is a consortium of companies who receive free labour from permissively licensed projects and to a lesser extent GPL projects, and it would like that to continue, which it cannot in practice under SSPL. The OSI article linked in a reply does not make a single point against the open-sourceness of the SSPL, and essentially just says they don't like it, and that some companies won't be able to comply, which is true of every free software license.
The FSF, Debian, etc haven't decided one way or another because it's not a very widespread license and they can just use valkey instead of wasting the effort.
kstrauser · 3h ago
This is not a widely accepted claim. I do not see SSPL as open source, and neither do OSI[0] or FSF[1] or Debian[2].
We need to stop taking the OSI or FSF's positions on anything as particularly valuable.
The OSI is captured entirely by corporate sponsors. Amazon was paying a full-time salary a year to the OSI when the SSPL issue happened, the OSI had no ability to take a moral pro-labor stance without crippling their own operations. They still do not meaningfully answer to individual users: The OSI recently refused to disclose who won their board election and installed their preferred candidates.
And it will be inherently unethical to even consider the position of the FSF as long as it lacks the moral fortitude to permanently punt RMS from the board.
If the OSI wasn't owned by corporate interests, and had rightfully declared SSPL as a copyleft license... nobody would argue it isn't. The problem is we've let an extremely problematic organization "define" something in a way that does not serve our interests.
merb · 1h ago
The OSI and FSF make sense by prohibiting stuff like the sspl. Open source should express freedom and by putting restrictions on certain users no matter how evil they are wont express freedom at all
ocdtrekkie · 1h ago
You seem to be opposed to software freedom. The SSPL is a viral copyleft open source license, it merely requires users to open source things. The SSPL is only restrictive in the same way as the GPL is, it requires granting users software freedom.
detaro · 2h ago
Many people came to the same conclusion about SSPL just by reading it when it was released, before any OSI position on it.
kstrauser · 3h ago
Which part of their explanation for rejecting it do you specifically disagree with?
The OSI then strays into a lot of nonsense that demonstrates just how bought and paid for they are, such as "the understanding that their work was going towards the greater good", like apparently... being used by a company which does not open source it's platform and treats its employees so poorly they have to pee in bottles. And of course, they immediately claim that "now... contributions are embedded in a proprietary product" because of course, the OSI believes they own the term and definition of open source, and that everything they don't agree with is inherently "proprietary".
And then of course, they suggest "relicensing is not evidence of any failure of the open source licensing model" even though it is very clear that businesses being unable to survive producing open source is kinda big flaw in the goal of promoting the public software commons. (Taking it a step further, if the FSF argues free software is a moral imperative, not fixing this is outright immoral.)
xiphias2 · 4h ago
,,for companies rooted in open source, it has posed a fundamental challenge: how do you keep innovating and investing in OSS projects when cloud providers reap the profits and control the infrastructure without proportional contributions back to the projects that they exploit?''
I don't see any exploitation happening. As DHH said, the main reason engineers open source their work is to give a gift to the world.
immibis · 3h ago
Open source is a gift to everyone (including Jeffrey Bezos); free software is a sharing economy. The difference is whether the sharing is reciprocal. With open source it's a one way gift from you to Jeffrey. He could have paid you for that. At the very least you can make him pay with reciprocal sharing.
jraph · 1h ago
I think you are not describing the difference between open source and free software but the difference between copyleft and permissive license.
Open source and free software licenses are basically the same (there are a few exceptions). For me, the difference is the focus. Free software cares about user freedom first.
liviux · 4h ago
Wishing all real-open-source projects best of luck, including valkey, OpenTofu and so on. These are my clear first choice!
DetroitThrow · 4h ago
Copyleft does not mean fake-open-source, I'd not consider Linux fake-open-source for example. Though plenty of reason to use permissive licenses instead of copyleft and vice versa depending on your situation.
immibis · 3h ago
Copyleft is Free Software, free as in freedom. Pushover licenses (such as MIT) are working for free for Amazon, Google and Oracle. Which is fine if your boss is paying you money to work for free for Amazon, Google and Oracle - it's their money. If it's your own spare time, you might not like it as much.
NetOpWibby · 4h ago
It's a bold strategy, let's see if it works out for them.
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
Unless of course you are an AI startup.
https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
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).
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.
It struggles a bit on certain types of workloads like hot keys, think heavy hitting a single sorted set. It's a cool architecture.
(I'd imagine implementing mechanisms for resilient storage and larger than memory data sizes would be the hard parts)
https://github.com/microsoft/garnet/blob/main/LICENSE
It's MIT licensed?
By "fake", I mean Microsoft largely treats their Open Source codebases like they are closed-source, in-house proprietary codebases that they happen to let members of the public look at.
They'll accept a PR once in a while, but mostly it appears Issues and PR's are used as a free alternative to UserVoice.
Every decision is made behind closed doors (probably a MS Teams call actually), and you'll notice how top-heavy their staff is on these projects (half a dozen employees with "Manager" in their title on any given repo).
Beggars can't be choosers, and I'm glad they are dipping their toes into the FOSS water... but I don't really get FOSS vibes from their projects on Github.
While it may technically be open source due to it's license and you can literally go look at the source - Microsoft is operating these codebases as-if they are proprietary. Every decision is made out of public - and I would not be surprised to learn they have their own internal tracker for the "real" backlog items. You frequently see command/comments by Microsoft employees which clearly are triggering workflows in their real backlog tracker, and near-zero discussion happens in Github by Microsoft employees, and when it does - it's clearly through a PR filter.
Like I said, beggars can't be choosers and it's better to have this than nothing - but I don't really think Microsoft has grasped the true concept of FOSS as-of yet.
> Is SQLite not open-source?
Not really in my opinion either. There's no way to contribute at all... best you can do it raise hell on the forums about a particular issue you want to see fixed. So while it's Open Source in the strict sense, it's not Open Source in the general sense.
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
The sibling comments contain some sharper critique of Microsoft if you haven't read them yet.
I don't know how you can extinguish something that's MIT licensed and has a million copies around the world.
I wouldn't trust Microsoft near my open source code base in 3 centuries
They can extinguish it by just stealing all the code, and using their bigger marketplace advantage to become the defacto standard.
gestures wildly at the MIT-licenced VSCode codebase
Yes, they are not rug pulling the VSCode source but by locking down the marketplace (and never giving a truly open source VSCode, what developers think of as "VSCode") they are in the processes of locking out forks.
Fair point! good example of an attempt to extinguish.
Like seriously - I haven't heard of them doing it in quite a long time. I know they were atrocious in the 90s and 00s, I'm not disputing that at all. Are there any examples of them continuing this behavior in the last decade though?
Further, a huge percentage of the people making those decisions back then are no longer with the company, different people are in charge, etc. The industry has changed it's relationship with open source - company board rooms aren't scared of the consequences of loading open source onto a server, the legality and liabilities have been hashed out, and MS isn't really even capable of pulling those fear levers anymore. MS itself has repositioned in the industry - their dreams of total computing dominance have been shattered: there's no chance of a windows derivative owning the server market any more, there's no money in browsers or consumer OSes (heck even MS's domination in gaming is showing cracks due the the efforts of valve). Point being - would it even make strategic sense for them to try to EEE anything anymore?
Note: I have almost no ties to MS. I haven't used an MS os or desktop software since before covid (in any capacity, even moving the mouse on a computer running windows). I don't use any of their SaaS products personally or professionally. There are integrations between the products I help build and azure, however those are not a major source of revenue for my employer and I do very little work that even touches that stuff. Point being - I'm pretty non-MS in my life and don't have any sort of loyalty or incentive to defend them. I do abhor their EEE actions back in the 90s and 00s when they were doing them, and those still make me angry... but that's not a reason to assume that different people at a company are going to act the same as the old-school ones.
Am I "fake open source"?
In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
That's not to say you are required to accept all contributions - I'm saying you should be open to contributions that A) save you time B) enhance the codebase or C) fix confirmed bugs.
In Microsoft's case - I don't see a lot of that going on. I see lots of Issues (bug reports), some PR's, but mostly opaque decision making, and complete silence on things the Corporate side of Microsoft doesn't want to comment on yet. Which is the beef - it's a corporate project run like it's proprietary but you can go look at the code. Again, better than nothing, but it's not really what I consider true open source.
I disagree. There's nothing about open source or the various open source licenses that require accepting engagement from the community and/or contributions.
Open source means allowing modifications, and sharing those modifications. It's in most licenses that the software is provided as is and without warranty.
> In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
A project not accepting outside contributions is still open source, not pretending to be, and the beauty of it is - if you want it to accept outside contributions, you are able to fork it and accept contributions on your own fork, or otherwise share your modifications. But there's absolutely no obligation of the original dev/owner to accept or engage with anything from the community. It's in the license, the software is provided as is and without warranty of any kind.
Maybe it's worthwhile to coin a new term, community software, to specifically make a distinction between projects that are community developed (accept contributions) vs those that don't.
I'd say the spirit of open source is that others are free to modify the code and that's it. This requires a good license, the possibility to fork, some documentation and a way to build the project yourself.
But why would accepting contributions be required?
It was about being able to have access to, fork/modify, and redistribute the software. That's the important thing - that the software I use can be modified by me, and if I wish to do so, the license allows me to then redistribute those changes vs. proprietary software, which cannot be modified nor redistributed.
I'm not sure why the zeitgeist went from the above and turned into "all open source must be community software and engage with users and accept contributions" because that was never what it was about. It was a benefit of some projects, sure, but at the end of the day the important thing isn't whether or not the project accepts contributions but whether I have the power and license to modify something to my liking, fork it if I wash, and/or redistribute my changes.
There seems to be a disconnect here. I agree, demanding someone else make changes for you is in poor taste. The issue is, some of these projects advertise themselves as being open source while having no meaningful way to contribute changes back upstream - ie. the spirit of open source.
If I use your program for free, and encounter a bug, I should be able to fix it and contribute that back upstream so everyone benefits. That's my way of "paying back" and helping the community. Projects that reject contributions, or make contributing difficult are not in the spirit of open source, even if they are technically open source via their license.
That's what I call "fake" open source - you want the positive image of being Open Source only.
I mean, you're not demanding someone else make the changes. You're only demanding that they engage and build a community around their project and all that entails.
As long as the license is reasonable, anybody else could pick up the project and do the community building around it. Apache HTTP Server developed around community patches to NCSA httpd. I don't think hitch (from the people who brought you Varnish) is well know, but it started as stud with community patches. If something like this takes off, the originator will either start taking the community patches too, or not; it's their choice.
In the meantime, as a user, I get the benefit of whatever changes the origin provides and I can patch it as I want, and fix up problems that I see. That works for code dump open source and community open source,.
What is it with .NET that compels you to lie?
Also FOSS and open contribution are different things, as sibling comment notes.
If you think otherwise, I suggest checking if there's any aluminium foil on your head.
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 CLA often tries to mitigate this by making contributors give the project owners special rights at the time of contribution.
(Note that even if relicensed, this itself can never revoke licenses granted for prior versions unless that license specifically had revocation written into it.)
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.
If you're okay with that, that's cool. But they'll profit off of your work and labor. And the worst part is that at scale, the advantages of the sum total of open source is used to compete with you and put price pressure on your salary and career options. To rephrase that, the hyperscalers are in a position to leverage open source to take advantage of market opportunities you cannot, and they can use that to compete with your business or competing businesses that might otherwise pay you better.
Open source needs anti-Google/Amazon/Microsoft clauses.
Not everyone thinks infectious copyleft / free software is a problem. But it will mean that if you use AGPL3, every part of your stack has to be open. That doesn't work for everyone.
This is why "equitable source" / "fair source" is gaining traction. You can use a license like Apache and add in clauses with MAU/ARR/Hyperscaler limits that allows practically everyone else to use your software.
AGPL does not and has not prevented hyperscalers from creating managed services for software licensed with it
That’s why mongo created the server side public license, which does require open sourcing the entire stack. MongoDB was AGPL before that
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-...
CyanogenMod required a CLA to assign them copyright to Cyanogen Inc, only for them to basically kill the project. They forked it as LineageOS only to still require a CLA.
Yes, of course.
> and moral level. Feeling betrayed is absolutely uncalled for.
Er, no, that's an unsubstantiated leap.
All those people that contributed, did so to the FOSS version. Their contributions live on in all the forks, both FOSS and proprietary (by Amazon & co., and Redis before today). So not sure where "betrayal" supposedly happened. Maybe when Amazon used their contributions too?
It is just that people don't hear what they don't want to hear. Every BSD or MIT is a loud and clear statement to deny the guarantee that derivative works will remain free and open.
Never trust a company.
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.
When AWS and Co did provide hosting and provided it better than these guys could, now it's suddenly AWS who are the bad guys for using the FOSS software the way the license always said they could. Now we're suddenly supposed to ignore the terms on which FOSS has always been released and pick up our pitchforks against the big mean cloud provider.
Instead of sticking to the fundamental principles of FOSS (principles which they won business by openly espousing) and adapting their business to the fact that Elastic and Redis lost in the competition they knowingly set up, they fixated on hosting (on top of AWS and Co, no less!) as the business model and changed the licenses to give themselves a monopoly on it.
If the companies had made a bad call in structuring their business and owned up to it I think we'd be having a very different conversation than we are. We're here because they failed to own up to it and instead tried to get people to raise pitchforks against AWS. Never mind that their intended model was the obviously doomed model of reselling AWS's hosting with a commission on top, and never mind that it was the trade-off they chose when they chose to release their software as FOSS and get the boost in adoption that comes with.
I do fully agree with antirez above that we need a new plan for funding FOSS. But I think that's a poor justification for the rug pulling and vilifying that the existing companies did.
> 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.)No comments yet
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!
Several major linux distros transparently switched to Valkey and the users are none-the-wiser. On Fedora, for example, doing `sudo dnf install redis` just installs Valkey.
Redis user since it appeared and I switched my servers (~15) to Valkey - partially because of the shenanigans, partially because Arch is moving Redis to archive.
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
Between that and the licensing, I would never consider dealing with them.
What evidence did you find?
This is Open Source working well.
Unfortunately, the reverse flow does not work.
[1] https://github.com/redis/redis/pull/13638
Did they maintain the author's copyright notice as required by BSD-3?
https://trends.shodan.io/search?query=valkey_version+port%3A...
Here's a chart of all Redis-compatible services (~55,000):
https://trends.shodan.io/search?query=port%3A6379+redis_vers...
It's not just licensing and hyper-scalers, it's also a matter of development quality and direction. For instance, now in Redis you can find substantial more stuff not available in ValKey, including hash items expires, Vector Sets that are very useful for a number of things, the probabilistic data structures just introduced with Redis 8, and so forth.
No comments yet
Maybe Valkey has served its purpose in pressuring Redis into playing ball.
Just answering "why would". Whether or not Redis is better then Valkey or if it would be worth it to switch back is not something I know.
You've said this twice now, but not provided any data or even a hand-wave to a possible source so that others could go get the data and look at it.
If it's statistically something, where are the stats?
My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
I have no idea what the actual stats are. But no, I don't find your "statistically 0%" to be self-evident, especially in light of the other comments and links in this thread, and what I've heard elsewhere.
I was hoping, since you presented it so confidently, that you had something more than "trust me". In another comment you say you have evidence of marketshare, maybe you could post that?
We've already completed migrating several large production clusters and I can confidently say that the migration had been pretty smooth and seamless.
Valkey is certainly production ready (at least on AWS it is). The team is looking forward to expedite and complete the migration
>My claim that statistically zero (cloud provider) customers are using valkey should, I sincerely hope, be self-evident.
This is simply not true. For example, Aiven (a cloud provider) completely ended support for Redis at the end of March and migrated existing users to Valkey. https://aiven.io/docs/platform/reference/end-of-life#aiven-f...
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.
The part you are thinking of is not the time consuming part.
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.
I wasn't aware the license had any negative affect on private internal use.
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.
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.
You probably can't recover from a loss of trust in low single digit years unfortunately, but this is a good first step towards the project rebuilding the OSS community that existed around redis initially.
Thanks for fighting for this. Hopefully this shows more companies stuck on source-available that you can achieve similar goals with OSS licenses.
"I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer."
I'm glad Antirez was seeing his art losing it's beauty and now, is reclaiming it!
0. https://antirez.com/news/133
And when I say "know", I don't mean "like": it could be that this will just make it easier for a particular team to decide that it doesn't want to deal with the AGPL, and they should go find something else, but at least it's clear what it is. As opposed to some BSSXYZWL license that you never heard of, which kind sounds like it's open source but kind of isn't...
I did get my stuff working with Pekko (the Apache fork of Akka), and it did work, but I was so pissed off at the entirety of this that I ended up rewriting the entire thing again using Vert.x, which I double checked the license for before doing more work.
I do understand why Akka feels like they have to use something like BUSL, it's hard to make money as a smaller software company, doubly so for open source software, and I also realize me complaining that "this free product made with free labor isn't free enough for me" is pretty entitled, but fundamentally I really don't think that the BUSL (and its similar licenses) are the right way forward. Whether or not it's fair, stuff like Akka does have competition from stuff that has more OSS-friendly stuff, and fundamentally I'm just going to use those, and if they're not up to snuff I'll augment them myself.
Sounds like SSPL did not yield the desired outcome.
Glad AGPL is an option now.
But I doubt that was the outcome that they hoped for. They created a large and successful competitor that by nature of being a fork does exactly the same thing. It's pretty hard to compete with yourself and the differentiate from your own product.
Honestly, I think Redis Inc. was better off when there was just one code base. AGPL just marginalizes them further. It's not an acceptable license for many corporate legal departments. So, it would necessitate buying a commercial license for such companies. I.e. Fortune 500 companies, public companies, and pretty much anything with a legal department worthy of the name. Note how Redis advertises AGPLv3 as "one" of the available licenses. The whole point of that license is selling commercial licenses.
Valkey is at this point stable and supported and a drop in replacement. It's pretty much the default choice for anyone not interested in buying a commercial license. That genie isn't going back in the bottle with this license choice.
More importantly, Valkey is a pretty active Github project with dozens of contributors in the last month. More than double those in Redis. Those commits aren't going to Redis. And Redis still requires the right to re-license your commits if you try to contribute. That's how they were able to pull this stunt to begin with. I doubt a lot of the Valkey contributors will be moving back to that status quo.
They made certain improvements later, but Redis 8 (see the release notes in my blog post if you are curious) improved this stuff a lot, too.
Also, Redis 8 contains a new data structure, Vector Sets, that allows to do many useful things, together with more probabilistic data structures, single hash fields expires, and many other stuff. It is not factually correct that ValKey has any features edge over Redis I believe. We will see in the next year which project takes the best development path: this is what really matters.
"They made certain improvements later", should be "we threw away the old implementation and built a better one."
2. Redis 8 improves the same idea, too, released today.
3. If you claim [in a different comment here] you provided a lot of code to Redis, why you didn't send a pull request for that? So, you are practically saying you were using, at Amazon, all the BSD code we provided, but could not provide an important part of the code to us? You see how broken such model was? At least stop defending it.
4. We can now copy the implementation: the parts are reversed (the irony!), and your code is BSD as our was for 15 years. When we avoid doing things like that, is because we have issues with how certain things were made.
5. I don't understand the motivations of you and other AWS people commenting here today. You work for a company that is creating issues to the OSS ecosystem: this is hard to deny. You cloned (and, yes, the license allowed for it) the code of Redis, and work on it so that hyperscalers can continued to do what they used to do. We bring Redis back to AGPL, and you are here to do the interests of Amazon in the comments. Did you see me commenting your stuff, when you release your things, with comments like "ah! But this is unfair"?
There is to make choices. I understand that it was cool to continue to work at a Redis fork, and part of the incredible thing open source is, is that forks survive in the hands of different teams (but design ideas can be misunderstood and projects may turn into other projects). So if you are happy to hack on ValKey, I hope you'll have the best experience out of it. But there is to make choices on how/when to interact.
I don't understand why so many people think that it's impossible to have open source in your heart while working for a big company in your day job. I don't understand why people who have dedicated a lot of their time and emotional energy to keep open source ways alive and help build a community effort are attacked because they work for a company that needs to be made the villain in the narrative.
Of course Redis is free to copy BSD licensed code that Valkey contributors add to the project [1]. I only wish that the blog post about this advancement in Redis would give some credit, rather than claiming "We also improved the performance of CRC64 calculations" [2].
We can all do better, and engage with one another with mutual respect and admiration for what has been freely given.
[1] https://github.com/redis/redis/pull/13638
[2] https://redis.io/blog/redis-8-0-m03-is-out-even-more-perform...
> I don't understand why so many people think that it's impossible to have open source in your heart while working for a big company in your day job.
Because a big company like Amazon has produced almost no open source work(yes some random collection of repos and 2 PRs here and there is not the same thing) compared to how much it has benefited from open source. (I know I know OSS allows for all that so not claiming anything wrong). But it does show what the company policy must be towards open source (Consume all you can, contribute only when absolutely essential for the company barring exceptional circumstances).
> I don't understand why people who have dedicated a lot of their time and emotional energy to keep open source ways alive and help build a community effort are attacked because they work for a company that needs to be made the villain in the narrative.
Antirez is not attacking anyone above. English is not his first language and he is just putting out some of his thoughts (which people are free to disagree with but those are what he thinks), like how you casually slipped that you didn't get credit for one commit copied from valkey (where the copier is giving due credit in the PR by linking the source PR and the authors inline). So they copied a PR from valkey, and the redis blog post should give lots and lots of credits? If that was the standard, so many of AWS services will spend all their reinvent time giving credits to their source OSS projects.
The employment contract you signed.
I'm not defending it, I'm trying to fix it. I want Amazon to contribute back. That's what I spend most of my time doing, but I can't just sit in a meeting and tell people we should give away code. It takes time to convince people that we should collaborate on the core and just compete on what we want to differentiate on. It takes time to convince people that building open-source in a vendor neutral space makes software that is better for everyone.
I hope that makes sense.
I don't think you want to sling that mud, unless Redis switched to being a nonprofit when I wasn't looking.
- https://news.ycombinator.com/item?id=43829008
- https://github.com/cncf/toc/issues/1632
- https://github.com/nats-io/nats-server/issues/6832
I also built a lot on NATS Jetstream, and I'm questioning my decision in light of the threatened license change.
Valkey.
This is factually untrue. If you want to link an AGPL blob into your app and ship it to customers, sure. In the vastly more common case where you're using a permissive client library[0] to connect to an AGPL server, there's no risk whatsoever.
At most, you might need to make your local changes to that server available to clients if they connect to it directly, as opposed to hosting a cloud SaaS setup where everything is internal to you. However, that's not the worst thing in the world. "Oh no, we improved a Free server our company depends on, and we have to share those improvements so that the person who gave us the server for free can also benefit from them" is pretty hard for me to sympathize with.
This is vastly more business-friendly than the non-FOSS SSPL.
[0]https://github.com/redis-rb/redis-client/blob/master/LICENSE...
Edit: Doubled checked with gpt, no cases of “infection” yet, there has also been many talks about this license being very good
The more aggressive a license you pick, the more likely a corporation won't want to use it. But that's by design. They're allowed to use it, even commercially - they just have to give the source code back. If the software is useful enough, they will. We should make software useful enough for corporations to consider the be benefits of using it to outweigh the cost of having to share their source code. (Also the more source you make them share, the less likely this is. The Linux kernel succeeded at this.
SSPL is controversial and untested (and goes against the business interests of the OSI so will never be box-tick certified compliant) and likely counterproductive if it means you have to share things like Windows. AGPL is the normal "aggressively free" license. GPL is mostly for those who haven't discovered AGPL yet and MIT is for those who don't agree in the goal of source code freedom to begin with.
what? why would you ask an LLM to generate some random text instead of looking up the actual answer?
enterprise hates AGPL. AGPL is generally not a serious alternative to BSD/MIT in corpoland, because something something (A)GPL-poisoning.
whether it's true or not doesn't matter. what matters is whether big tech considers AGPL infectious - which they do.
Yeah, this is BS.
If you simply use AGPL software, it doesn't "infect" anything. If you *change* the AGPL software, you have to release the changes. It forces the big clouds to open source their Redis improvements.
Most of the readers of HN make their living from closed source software. You know well enough that non-hostile open source is just a market entry strategy and the type of copyright-driven maximally selfish capitalist markets just force open source to be not viable for a single company to thrive. Projects like Linux kernel are exceptional infrastructure projects that external companies support not build businesses just to ship.
This is completely, factually, unequivocally, incorrect.
You can connect to Redis using their first-party, MIT-licensed client library. You can write proprietary software using that library with no requirement whatsoever to release your software under any particular license (although of course you still have to comply with the MIT license's attribution requirements).
If all software connecting to the AGPL'd service runs internally, you're not obligated to share your local changes to that service. This covers the vast majority of use cases. Using WordPress with a Redis cache? This doesn't affect you.
If you host an AGPL'd version of a Redis server and your customers connect to it from their own networks, then the only obligation you have over the tried-and-true GPL is that you have to share changes you've made to your Redis server with users. If you use Redis packages as-is like almost everyone does, this doesn't affect you.
So literally the only people who have to care about Redis being under the AGPL now are those who don't want to pay Redis for a commercial license, who expose their Redis server to customers, and who've made local changes to their Redis server. Everyone else gets to keep using it like they always had.
Edit: Oops, typoed the license names.
I spent the entire weekend poring over the C code and found it some of the most beautiful C I'd ever read (ever since the heady years of SunOS), and now I feel I should at least go and update miniredis to asyncio/Python 3--for kicks...
[^1]: https://github.com/minio/minio/issues/13308#issuecomment-929...
I dont think it applies to clients using the API at all. It just specifies that the modified source should be offered to clients connecting over the API, but not that the client itself has to be open source.
https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
Personally, I think it is better just to call a spade a spade and release things with commercial licenses. Let all companies with < 1T market cap use your stuff for free. Companies that are making money will want a managed service or support anyway. Companies that want to host your stuff in their environment fall into the > $1T category.
The above is a bit of a strawman but what we really want is for valuable projects to continue to exist.
If you have a webapp that uses redis on the backend for a task queue, do the users of the webapp count as users of redis, and you then have to provide source to redis? Is there a chance that you might have to release your apps code to be compliant?
[1] I am assuming this because valkey comes under the Linux Foundation umbrella.
Linked below is Google's own stance on why AGPL is banned:
https://opensource.google/documentation/reference/using/agpl...
That doesn't mean it's the right position for you, or for every situation. Many organizations with a higher levels of maturity in open source matters will take a more nuanced approach when it comes to AGPLv3 licensed software.
I'm quite fed up with this GAFAM FUD against the AGPL and the GPLv3.
- 7.4 - Dual licensed under RSALv2/SSPLv1
- 7.2 and earlier - 3BSD
The products (commercialized open source) that are often chosen by and championed by developers as opposed to executives see the harm that a bait and switch has on their popularity. With their competitors being more permissive, I don't see many devs moving back unless Valkey loses significant feature parity.
[1] https://ir.elastic.co/news/news-details/2024/Elastic-Announc...
Has there been a consensus on one? Is there a winner?
I love redis and will probably keep using it. Just curious.
There are the commit histories, the GitHub contribution graphs. Everything is public. The current code base was written for the majority by a few single folks, for another small amount of the sum of all random people in the community, for a smaller part by people that now work at ValKey.
> It is also hard to reconcile the claims that cloud providers do not contribute with the actual commits to the Redis repository. A quick examination of the commits since the 7.0.0 release using gitdm shows 967 commits over that time period:
> Binbin Zhu, of Tencent, is responsible for nearly 25% of the commits to the project. Some of the contributors without a readily identifiable employer surely are Redis employees, but it's clear that the company has not been working alone.This is likely some partial data of some specific fork or alike.
As is typical for software projects, early authors will be disproportionately represented in revision histories. I am still the #4 contributor to the Anaconda installer [1] originally used by Red Hat Linux, then RHEL, then Fedora, and others, despite not contributing to the code base for two decades.
[1] https://github.com/rhinstaller/anaconda/graphs/contributors
"Inebriated aliens might as well have beamed it down from space as a kind of practical joke..."
"It’s not just hard for lawyers, who have the legal picture and can parse the whole license very carefully without passing out...It’s also hard for hackers, even those familiar with free software lore, who lack the legal side of the picture and a sense of what other ways things might have been said. Imagine how people who don’t know software, law, legal drafting, software architecture, hacker culture, or the self-styled 'philosophical' musings of one Richard M. Stallman feel."
https://writing.kemitchell.com/2021/01/24/Reading-AGPL
As Mitchell implies folks who want network copyleft should look into the more straightforward OSL3, IMO.
But it's something, and it's not my call to make because I didn't write the code, so properly I can only be grateful.
I'm bad at licenses, and I admit I don't completely get it. At first glance, it seems like a simpler more readable license that tries to accomplish something similar to AGPL. I think the "license terminates when you sue me for patent infringement" clause is nifty.
But it says that an "external deployment" counts as "distribution" (ok, fair), which means you must OSL-license your changes too (ok, fair too).
But how does that in practice prevent AWS and GCP from cloud-hosting your software without giving back? Seems to me that if Redis went OSL3, GCP could host it fine so long as they'd OSL3-distribute any changes they made.
I mean, I remembered the whole Valkey saga after the license switch. I guess I'm just not as ideological as some here? I just thought "I need a fast in memory object store" and went with Redis as my default. I treat it like an appliance within my infrastructure.
I also vaguely recall antirez going back to Redis (the company) during the AI boom to work on vector extensions to Redis. I believe he is a big part of why Redis is such a rock-solid piece of tech. I am more confident in this product with him influencing the trajectory.
I also have the decision on license in the back of my mind. As I said, I am not an OSS zealot, but I do like the idea of an OSS license that has some protection against someone completely ripping off the code with no recourse. AGPL might be a decent compromise, especially with a dual license.
Just because they don't have the same motives as you, doesn't stop it being a user freedom. Anything that shares the changes and improvements is a user improvement.
Some code under a 3 clause BSD and some under AGPLv3 could be interesting.
But maybe Valkey should switch to GPLv3 instead to correct this imbalance.
https://github.com/redis/redis/pull/13638
So either they relicense, or they can't take code from Redis but Redis can take code from Valkey.
However, if the intention was the other way (to allow valkey to take code from redis), valkey should just go for AGPL as well, there is little reason to pick GPL if the code sharing would be the motivation for the license change.
In theory, one would not be able to offer a combined program under other licenses (in particular, RSALv2 and SSPLv1), as those licenses have conflicts with GPL obligations.
Direct contributions to the Redis project avoid this issue via a separate Contributor License Agreement. It would only mean that Redis developers could not unilaterally copy code from Valkey.
I'm not saying that the Valkey community should do this. Personally, I think it's better off as a BSD-3 licensed project, with the community fulfilling the promise made by others that it would always be that way.
It's better than the previous state of course, but it would have been even better if the previous license change didn't happen.
As the french people say: fool me once, shame on you...
But in seriousness, the chances of valkey going closed source are low. It's run by Linux Foundation. It would be like suggesting that Node.js might go closed source...
https://github.com/meta-llama/llama3/issues/156
The fact that the FSF wants a EULA but can’t have a EULA without violating Freedom 0 doesn’t make the AGPL suddenly logically sound.
marcan has written about it in more detail than I care to: https://news.ycombinator.com/item?id=30044019
Stop using the AGPL. It violates the basic principles of free software.
The ability to run a SaaS company with free software is a feature, not a bug.
What do you think is nonfree about AGPL?
The AGPL, in its quest to be a EULA, violates free software Freedom 0 ("The freedom to run the program as you wish, for any purpose").
https://www.gnu.org/philosophy/free-sw.en.html
The AGPL literally demands specific functionality be present in the software that cannot be removed without breaking the license. The anticapitalist FSF zealots got so in love with the idea of closing what they call "the ASP loophole" that they wrote themselves a EULA.
And for my personal usage, Rails 8 has moved Redis functionality into the database by default, which works fine.
I love the BSD license, but now who says that AGPL is a cancer is making a big favor to the few huge companies that want to abuse the original dream that spawned modern and open software. Times changes, the best license to use change with times.
RMS has long expressed concerns about "Service as a Software Substitute" [1], and I think he hesitated to endorse the AGPL because it would conflict with his philosophy on the dangers of "Service as a Software Substitute".
Henry Poole should be given credit for raising the concern; Bradley M. Kuhn and Eben Moglen should be given the credit for advancing the license to address the concern.
It took a long time for the Free Software Foundation to accept Affero versions of the GPL under their stewardship with the release of AGPLv3.
So, perhaps he did understand before many people that services posed some challenges for his social movement. But it's my belief that he favored self-reliance and maximum "freedom" by running computer programs on hardware you own yourself as the remedy, rather than extending copyleft obligations to reach over the network.
[1] https://www.gnu.org/philosophy/who-does-that-server-really-s...
Good, you can think it is cancer and stay away from it. You don't like it, don't use it. It's like those bright colored poisonous frogs from the Amazon. That's better than some newly made up license that's different than anything else, and you have to wonder how it would hold up in practice.
If you modify GPL code you are expected to open source the changes, AGPL adapts that to the networked world, if you modify AGPL code to serve something, you should open source those changes too, otherwise you're violating the original spirit of GPL which was designed in a time that was not as perpetually internet (and SaaS) driven as today.
If you want a true free license, BSD or MIT have you covered, but then you shouldn't expect corporations to give back.
A good example of what happens if companies don't give back is Linux VS the various BSD's. BSD is a lot more popular in appliances than you might otherwise believe but the popularity is starting to wane as Linux (despite GPL) has improved so much with companies giving back that the "free license" BSD is no longer being seen as good enough in some cases. People do not tend to give back to the BSD's.
[0]: https://blog.jamesbayley.com/2014/01/17/gpl-living-with-canc...
Databases could always do what redis did. Redis doesn't bring functionality to the table, it brings speed. If database caching, pub/sub, and streams are good enough for your use case, there was never a reason to pay for an extra instance just to stand up redis.
If you don’t like it, don’t use AGPLv3 software. Those of us who do like it will keep writing AGPLv3 software.
It meets all the criteria and the only difference from AGPL is how much source code you have to release and when - which is also the difference between GPL and AGPL. It has problems, but being closed source isn't one of them.
The OSI will never certify it, of course, because that would go against the business interests of the OSI members. The OSI is a consortium of companies who receive free labour from permissively licensed projects and to a lesser extent GPL projects, and it would like that to continue, which it cannot in practice under SSPL. The OSI article linked in a reply does not make a single point against the open-sourceness of the SSPL, and essentially just says they don't like it, and that some companies won't be able to comply, which is true of every free software license.
The FSF, Debian, etc haven't decided one way or another because it's not a very widespread license and they can just use valkey instead of wasting the effort.
[0]https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
[1]https://www.gnu.org/licenses/license-list.en.html
[2]https://www.debian.org/legal/licenses/
The OSI is captured entirely by corporate sponsors. Amazon was paying a full-time salary a year to the OSI when the SSPL issue happened, the OSI had no ability to take a moral pro-labor stance without crippling their own operations. They still do not meaningfully answer to individual users: The OSI recently refused to disclose who won their board election and installed their preferred candidates.
And it will be inherently unethical to even consider the position of the FSF as long as it lacks the moral fortitude to permanently punt RMS from the board.
If the OSI wasn't owned by corporate interests, and had rightfully declared SSPL as a copyleft license... nobody would argue it isn't. The problem is we've let an extremely problematic organization "define" something in a way that does not serve our interests.
The OSI then strays into a lot of nonsense that demonstrates just how bought and paid for they are, such as "the understanding that their work was going towards the greater good", like apparently... being used by a company which does not open source it's platform and treats its employees so poorly they have to pee in bottles. And of course, they immediately claim that "now... contributions are embedded in a proprietary product" because of course, the OSI believes they own the term and definition of open source, and that everything they don't agree with is inherently "proprietary".
And then of course, they suggest "relicensing is not evidence of any failure of the open source licensing model" even though it is very clear that businesses being unable to survive producing open source is kinda big flaw in the goal of promoting the public software commons. (Taking it a step further, if the FSF argues free software is a moral imperative, not fixing this is outright immoral.)
I don't see any exploitation happening. As DHH said, the main reason engineers open source their work is to give a gift to the world.
Open source and free software licenses are basically the same (there are a few exceptions). For me, the difference is the focus. Free software cares about user freedom first.
https://www.youtube.com/watch?v=9HVejEB5uVk