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 · 17m 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 only 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.
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
Anyway: thanks for having contributed to Redis :)
revskill · 15m ago
Not quite. Company can easily change license at any time. No string attached.
noshitsherlock · 12m ago
Good decision, I hope the best for Redis!
bobsoap · 11m 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 · 2h 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.
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 · 33m 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 · 26m 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.
KolmogorovComp · 1h ago
You’re confusing open source and open to contribution. Is SQLite not open-source?
tough · 1h ago
Does SQLite try to embrace, extend, and extinguish their competitors?
atonse · 48m 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.
joshstrange · 4m 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.
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 · 40m 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 · 38m ago
LMAO they're so evil its even mildly funny
Alupis · 20m 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 parts of their real backlog tracker, and near-zero discussion happens in Github by Microsoft employees.
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.
munchler · 1h ago
How is that "fake"? There's no requirement that an open source project take contributions from outsiders at all.
justin66 · 53m 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.
dharmab · 20m 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 · 5m 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.
neonsunset · 1h 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.
KomoD · 1h ago
I don't, would you like to explain?
homebrewer · 2h 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.
dharmab · 18m ago
There are good legal reasons to avoid the GPL; there are open legal questions about whether the GPL and its variants are enforceable.
pcthrowaway · 44m 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 · 9m 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 · 1h 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 · 1h ago
It's sad as an open source lover how money fucks it all
echelon · 1h 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 · 56m 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
weinzierl · 1h 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 · 1h ago
> The transitions Redis made are pristine on a legal
Yes, of course.
> and moral level. Feeling betrayed is absolutely uncalled for.
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.
tough · 1h ago
People and companies are allowed to change opinions, why would anyone blame Redis or Elastic instead of Amazon for taking it all?
echoangle · 1h 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 · 58m ago
I'd still trust more antirez than amazon as entities.
Never trust a company.
echoangle · 18m ago
What does trusting antirez help me if he’s working for another company?
orthecreedence · 58m ago
You're not arguing for the honesty of individual companies, you're arguing against the profit mechanism.
simonw · 1h 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
simonw · 44m 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 · 33m 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.
placatedmayhem · 2h 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 · 57m ago
We kept using redis, the license change never affected us. We had no reason to switch.
ketzo · 47m 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!
dharmab · 17m ago
From the blog post it seems like existing users kept using Redis but new users adopted alternatives instead.
ramon156 · 24m ago
Same here. The response from the community was valid, but basically didn't affect us.
ksec · 2h 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 · 2h 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 · 1h 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.
kiitos · 1h ago
Statistically nobody is using valkey.
cyrnel · 1h 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 · 1h 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 · 1h 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 · 52m 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 · 14m ago
LLMs are not a source.
Tostino · 27m ago
Why/how would you expect an LLM to know that info?
jzb · 28m 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?
_msw_ · 1h ago
If you use the latest versions of Redis, you are benefiting from the continued efforts of the Valkey development community. [1]
Yet. It's a drop-in replacement, and both faster and cheaper.
rmsaksida · 1h 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 · 1h ago
Are there usage stats available? How do you know this?
Without sources, it's a "statistically worthless" comment :)
Osiris · 1h ago
My guess is most people are using Redis via cloud providers. Did any cloud providers switch away from Redis?
andenacitelli · 1h ago
AWS supports Valkey for Elasticache, and they actually bill it 33% cheaper. We use it and it works well.
pjm331 · 1h ago
AWS Elasticache gave a nice discount to switch to valkey w/ 1 button click no downtime migration path
aweiher · 1h ago
ValKey is cheaper in AWS than Reddis
echoangle · 1h ago
Wasn’t the whole point (or one of the major ones) of Valkey so that AWS could use it?
shaky-carrousel · 1h ago
Yeah, all the open source distributions and most open source projects switching to valkey must be "nobody".
teaearlgraycold · 1h ago
I don't know about valkey but I got word Nvidia was switching away from Redis.
VWWHFSfQ · 2h ago
I very much doubt that anyone will stick with valkey after the PaaS providers switch back to just offering Redis proper.
md3911027514 · 2h ago
Why would PaaS providers switch back to offering Redis? They've clearly all already invested a lot in Valkey (AWS, GCP, Heroku).
antirez · 2h 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.
lotharcable · 1h 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 · 1h 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 · 1h 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 · 1h 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 · 1h 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 · 1h 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?
kevinsf90 · 34m 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 · 1h 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 · 2h 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 · 35m ago
Redis is in SQLite and Wireguard league of simplicity and elegance.
otterley · 31m 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 · 19m ago
The announcement just happened. I don’t know that we know the results yet.
lolinder · 16m ago
Elastic announced they were switching back a few months ago, we should be able to measure the results by now.
md3911027514 · 2h 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 · 2h ago
Your company invested hundreds of engineering hours switching from Redis to a clean fork of Redis?
cogman10 · 2h 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 · 36m 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 · 11m 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 · 1h ago
I believe it. There are companies that invested hundreds of engineering hours to rename master to main.
brookst · 2h 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 · 1h 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 · 1h 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 · 1h 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 · 14m ago
I doubt having lawyers review your usage is more expensive than spending hundreds of hours of dev time to migrate.
stackskipton · 1h 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 · 2h 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 · 1h 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 · 1h ago
Even the infrastructure switch and testing should take a lot of time, yet the application level tests etc.
edoceo · 2h 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 · 2h 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 · 1h 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?
tuckerman · 2h 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.
poincaredisk · 1h 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.
md3911027514 · 2h 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 · 1h 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.
DetroitThrow · 2h 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.
remram · 2h ago
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 · 1h 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 · 1h 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 · 1h ago
That's a good point, traditional OSS licenses, we can like them or not, but they are "understood".
ibnurasikh · 2h 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 · 1h 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 · 1h 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 · 1h ago
1. The fundamental idea was mine. Ideas can 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_ · 1h 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.
> 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 · 45m ago
Yes, makes sense. Thanks for the reply.
_Wintermute · 40m ago
This comment has inspired me to switch to Valkey, thanks.
antirez · 3m 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.
yjftsjthsd-h · 1h 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 · 1h ago
They aren't really comparable and you know that.
yjftsjthsd-h · 1h ago
They are and you shouldn't claim bad faith without very good reason.
umajho · 21m 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?
> 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.
Sounds like SSPL did not yield the desired outcome.
Glad AGPL is an option now.
ocdtrekkie · 1h ago
It did yield the desired outcome: Google and AWS are no longer using it.
Zambyte · 1h 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.
nchmy · 1h 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 · 55m 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.
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 · 1h 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 you 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.
> 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 · 46m 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.
matesz · 1h ago
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 · 1h 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 share 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 · 1h 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 · 1h 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 · 1h 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.
doctoboggan · 1h ago
I think you are thinking of GPL. Many companies are happy to use AGPL licensed software in their stack.
kstrauser · 1h 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 · 1h 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 · 1h 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.
linotype · 2h ago
No thanks, going to stick with Valkey for all future projects.
dec0dedab0de · 1h 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?
infogulch · 2h 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.
bravetraveler · 2h ago
After what Mullenweg has pulled, in the era of Blogging CEOs I have to be cynical.
Valkey.
kstrauser · 1h 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 · 1h ago
Oh, I agree... I want to be wrong
kstrauser · 1h ago
I hope you are, too. Don't mistake my optimism for complete confidence.
tiffanyh · 2h 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 · 1h ago
That's the license working as intended, isn't it?
WD-42 · 1h ago
So a hyperscaler bans the AGPL? Shocking.
Seems to be working as intended.
jraph · 1h ago
Their loss, at some point…
I'm quite fed up with this GAFAM FUD against the AGPL and the GPLv3.
gray_-_wolf · 47m ago
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?
captn3m0 · 1h ago
- 8.0 - Tri-licensed under RSALv2/SSPLv1/AGPLv3
- 7.4 - Dual licensed under RSALv2/SSPLv1
- 7.2 and earlier - 3BSD
jamessinghal · 2h ago
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 · 1h 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.
createaccount99 · 43m ago
AGPL + selling under other licenses seems to be the way
blotfaba · 1h ago
Hashtag #ThankYouValkey?
revskill · 16m ago
Is it a business decision right ?
eknkc · 2h 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 · 2h ago
Valkey has replaced redis in a few distros
eknkc · 2h ago
It is a fork of the latest oss release right? I thought some completely new implementations were introduced.
reconditerose · 1h 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/.
> 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
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.
ezekg · 2h ago
Also PaaS like Heroku adopted Valkey as a drop-in replacement for Redis.
dbacar · 1h ago
Thanks, maybe this will be exemplary behavior for Elastic and Mongo.
threatofrain · 2h ago
Notably, Redis is about to sue Dragonfly for deliberate trademark confusion.
bk496 · 56m ago
cool, does this means it works on Windows now?
ConanRus · 25m ago
stop clowning around already
immibis · 1h 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 · 1h 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.
detaro · 27m 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 · 57m 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.)
mattl · 2h 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_ · 1h 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).
_msw_ · 16m 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.
jraph · 25m ago
The imbalance _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 · 17m 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.
badmonster · 1h ago
great news
ac130kz · 2h ago
Good luck to them, everyone is moving to Valkey, especially with its major backing and already better performance.
edweis · 1h 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.
nailer · 1h 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:
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.
not_your_vase · 2h 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...
paavohtl · 1h ago
Valkey is a Linux Foundation project. Talking about license changes is just pure irrational FUD.
benatkin · 2h 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 · 1h ago
They were obviously making a tongue in cheek comment instead of seriously suggesting Valkey may go proprietary.
benatkin · 1h 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.
VWWHFSfQ · 2h ago
I'm guessing valkey will be dead now?
detaro · 2h 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 · 2h 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 · 2h 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_ · 27m 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.
nilamo · 2h ago
> 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 · 1h ago
Extra instance and developer overhead.
dijit · 2h 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.
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.
xiphias2 · 2h 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 · 1h 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.
ezekg · 2h ago
Of course it's the AGPL, which is essentially the SSPL in practice.
ndiddy · 2h 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 · 2h ago
Except that it’s actually open source.
ezekg · 2h 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 · 2h 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.
zoogeny · 1h 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.
NetOpWibby · 2h ago
It's a bold strategy, let's see if it works out for them.
Wishing all real-open-source projects best of luck, including valkey, OpenTofu and so on. These are my clear first choice!
DetroitThrow · 1h 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 · 1h 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.
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 only 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
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
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.
I don't know how you can extinguish something that's MIT licensed and has a million copies around the world.
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.
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.
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 parts of their real backlog tracker, and near-zero discussion happens in Github by Microsoft employees.
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.
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.
What is it with .NET that compels you to lie?
Also FOSS and open contribution are different things, as sibling comment notes.
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.
Yes, of course.
> and moral level. Feeling betrayed is absolutely uncalled for.
Er, no, that's an unsubstantiated leap.
It is just that people don't hear what they don't want to hear.
Never trust a company.
> 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
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.
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!
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/
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
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.
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.
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.
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'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.
[^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...
Sounds like SSPL did not yield the desired outcome.
Glad AGPL is an option now.
This is factually untrue. If you want to link an AGPL blob into you 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...
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.
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 share 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.
Edit: Oops, typoed the license names.
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?
Valkey.
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.
> 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.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 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.)
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
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.
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.
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.
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...
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.
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 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...
If you don’t like it, don’t use AGPLv3 software. Those of us who do like it will keep writing AGPLv3 software.
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.
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.
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.
https://www.youtube.com/watch?v=9HVejEB5uVk