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.)<p>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.
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.<p>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".<p>I'm delighted. Thank you, team Redis.
From this post on the Redis blog <a href="https://redis.io/blog/agplv3/" rel="nofollow">https://redis.io/blog/agplv3/</a> it looks like they've made a bunch of new features available under the new AGPL license too:<p>> Integrating Redis Stack technologies, including JSON, Time Series, probabilistic data types, Redis Query Engine and more into core Redis 8 under AGPL<p>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: <a href="https://redis.io/docs/latest/develop/interact/search-and-query/" rel="nofollow">https://redis.io/docs/latest/develop/interact/search-and-que...</a><p>With syntax that looks something like this:<p><pre><code> FT.SEARCH places "museum @city:(san francisco|oakland) @shape:[CONTAINS $poly]" PARAMS 2 poly 'POLYGON((-122.5 37.7, -122.5 37.8, -122.4 37.8, -122.4 37.7, -122.5 37.7))' DIALECT 3
</code></pre>
(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.)
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.<p>Edit: Regardless, thank you and the rest of the folks inside Redis for pushing to bring this back to OSS!
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.<p>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.<p>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.
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.
From the CEO blog post - <a href="https://redis.io/blog/agplv3/" rel="nofollow">https://redis.io/blog/agplv3/</a><p>>This achieved our goal—AWS and Google now maintain their own fork<p>Was this really the goal though? Forcing your biggest users to fork your software and maintain their own divergent version is not really good for anyone. Sure, Amazon and Google (or AWS and GCP - type confusion in the source material) now have to contribute some more engineering hours to the open fork, but why would anyone still want to use Redis now that there's a permissively licensed alternative maintained by the same cloud hyperscalers who will end up running it for you?
They still require a CLA [1] so there's nothing stopping them from doing another relicense to a proprietary license tomorrow.<p>The only way this remains open source forever is to accept AGPL-only licensed patches.<p>[1]: <a href="https://github.com/redis/redis/blob/d65102861f51af48241f607afa678c4c2a0f894c/CONTRIBUTING.md">https://github.com/redis/redis/blob/d65102861f51af48241f607a...</a>
When Antirez left Redis, he wrote an amazing blog post I go back to often [0]. In there he said:<p>"I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer."<p>I'm glad Antirez was seeing his art losing it's beauty and now, is reclaiming it!<p>0. <a href="https://antirez.com/news/133" rel="nofollow">https://antirez.com/news/133</a>
I got a really stupid email from Redis®* a year ago that wanted me to put a disclaimer on the “first page” where Redis®* appeared on a website, as if it was a paper legal document.<p>That was the very moment Redis®* died for me—I’ve never encountered a tech company that was so aloof about how tech works.<p>Hopefully that damage is undone.<p>—<p>*Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Brad Gessler is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Brad Gessler.
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.
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.
Ironically, when Redis changed their license a couple of months ago, I commented back then [1]:<p><i>But who knows what the future holds? Maybe the Redis team will change their mind and revert back the decision like Elastic Search did a few weeks ago: <a href="https://news.ycombinator.com/item?id=41394797">https://news.ycombinator.com/item?id=41394797</a></i><p>Yeah, that future had come, and Redis is free again!<p>Thanks antirez and to all the team behind Redis.<p>_________________<p>1. <a href="https://news.ycombinator.com/item?id=41611636#41612750">https://news.ycombinator.com/item?id=41611636#41612750</a>
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.<p>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.<p>Thanks for fighting for this. Hopefully this shows more companies stuck on source-available that you can achieve similar goals with OSS licenses.
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.<p>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...
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.
A bit more info from CEO: <a href="https://redis.io/blog/agplv3/" rel="nofollow">https://redis.io/blog/agplv3/</a><p>Sounds like SSPL did not yield the desired outcome.<p>Glad AGPL is an option now.
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.
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?<p>[^1]: <a href="https://github.com/minio/minio/issues/13308#issuecomment-929254690">https://github.com/minio/minio/issues/13308#issuecomment-929...</a>
Why I will never try to monetize my own project:<p>1. To monetize a project, it must first gain wide adoption.<p>2. To gain wide adoption, it must have a permissive license.<p>3. To successfully monetize (after gaining wide adoption), it must have a restrictive license.<p>4. Changing a project's license to be more restrictive will alienate the community and hurt adoption.<p>I see no solution to this dilemma.
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.
Genuine question: i want to start a project which fundamentally i would line to open source. I want people and in particular people working in companies to use my project.<p>However i also want to be able to make a living from it if it takes off ie build a business on it. I guess if that business has competition purely from hosted copies, that is also fine.<p>However, I do not want any hyperscalers to fork and close source the project. I want sny benefit to continue to be available.<p>So it seems I should choose Agpl. But i know that in most companies this leads to being blacklisted, especially in the EU where its legally unclear what the AGPL entails. Without corporate adootion i do not see the project gaining traction so i would only do it for myself.<p>With permissive licensing it seems a rug pull is inevitable to be able to do it full time.<p>What to do?
So with redis being AGPL, who counts as a user?<p>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?
As noted by others, this is irrelevant unless Redis actually uses AGPL as the primary license for the software (that is, in an inbound=outbound fashion).
<a href="https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/" rel="nofollow">https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/</a>
Some of these open source licenses are somewhat flawed when it comes to building a business on things that are "free".<p>Wouldn't it be possible to add a clause to some of these licenses that if you are using open source software and generate a certain amount of revenue from it, something has to be given back to the project.<p>I totally understand that the software is meant to be free but isn't there a balance here, where at some point it must be enforced that some the money it generates in a business, must flow back to its contributors/project ?<p>I have worked plenty of places where Redis was a thing that served at least some backbone for success for a business. Those places could pay a fee for generating revenue based on free software ?<p>Does it make sense ?
I would love to see Amazon offer a Redis service, comply with the AGPLv3 instead of using the other Redis licensing options and do revenue sharing to incentivise more commercial source-available projects to go that route.
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?
Great to see this. 12 years ago I wrote <a href="https://github.com/rcarmo/miniredis">https://github.com/rcarmo/miniredis</a> during a very slow weekend where I both wanted to get a feel for the internals of how Redis worked and have a little PubSub server I could call my own.<p>I spent the entire weekend poring over the C code and found it some of the most beautiful C I'd ever read (ever since the heady years of SunOS), and now I feel I should at least go and update miniredis to asyncio/Python 3--for kicks...
Not seen any mention of KeyDB... Maybe I miss something obvious, but it solved my small use case that would stretch to the other side of Redis pay wall. I'm very happy with KeyDB.
I'm happy to see the news after having a chance to look at sources more closely (for unrelated reasons). The Redis geohash/gis related implementation is such a pleasure to read.
AGPL: Uselessly open-source. Anyone who wants to make money with it, even if it's just one of many components in your tech stack, would have to open-source everything. This drives people to adopt the paid versions of the same software over the open-source version, and that's no doubt the point. Adopting the AGPL is a cold, calculated move.
Again? Didn’t it go from BSD to some infectious copyleft thing? Doesn’t seem “open source again” to me if we can’t use it in private work projects without being forced to open source our project. Isn’t AGPL even WORSE than what they switched from? Wouldn’t “open source again” imply going back to BSD?
"We heard from some customers that it is easier for them to operate under an OSI-approved license, so we’ve added that option." ROFL.<p>Yeah, translation. We got the biggest backlash ever from the license change, the community HATED us so much for this. THIS is why we backpedaled.<p>Valkey was created and already took over Linux distro package distributions with easy AF drop in replacements installs. I installed Valkey on my VPS for a WordPress Object Cache and I just installed the package, did not even need to edit any file or anything, just runs and works and the WP plugins for Redis just thinks it's Redis. Besides the name as an end user, literally nothing changed. Valkey got a massive interest and if clearly became obvious that it made zero sense, and it was the wrong decision.
Similar move to Elasticsearch, tacking on AGPL with their existing source available licenses. [1]<p>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.<p>[1] <a href="https://ir.elastic.co/news/news-details/2024/Elastic-Announces-Open-Source-License-for-Elasticsearch-and-Kibana-Source-Code/default.aspx" rel="nofollow">https://ir.elastic.co/news/news-details/2024/Elastic-Announc...</a>
Nah, as much as I loved the original Redis, they dropped the ball with the license change. To me it looks like they realized way too late. There was a window for them to turn back, but now it looks like they are bleeding some way or another and just trying to recuperate. In the meantime, other drop-in solutions took over.<p>Can't say that I feel sorry for them though.
The post is a bit misleading as the agpl is a licensing <i>option</i> but not <i>the</i> license.<p>It’s a good trade-off though. Grafana does the same and they’re doing just fine.<p>I hope redis gets to live a long life now that’s more open than ever (essentially it’s free software now) :)<p>After the redis troubles I hope more people start to realise that the GPL license is the way really, and that other licenses (like the BSD that Redis used to use) are really just too risky.
I ask this as a scrub end user. What are the implications of forking when it comes to a Redis? Specifically, what I am wondering about whether forks like valkey which are worked on by competent programmers[1] continue to be good choices or does Redis Inc. having founded redis give it a distict advantage?<p>[1] I am assuming this because valkey comes under the Linux Foundation umbrella.
I wonder whether they did deals with AWS and Google behinds the scenes. Something like "you poured money into Valkey, how about you give that kind of money to us instead and we'll switch to AGPL and you can stop confusing two customers with two practically identical but differently priced options". Could that ever work? (I have no idea)
Engineering/ Designing applications with Apache Foundation's software's might be the first option, less pain. It is extremely stressful to change the base architecture. As, AGPL threatening commercial apps to open source their code. It is unfair changing the license after getting popular.
I'm always grateful for open source code, but on AGPL I can only quote the lawyer Kyle Mitchell:<p>"Inebriated aliens might as well have beamed it down from space as a kind of practical joke..."<p>"It’s not just hard for lawyers, who have the legal picture and can parse the whole license very carefully without passing out...It’s also hard for hackers, even those familiar with free software lore, who lack the legal side of the picture and a sense of what other ways things might have been said. Imagine how people who don’t know software, law, legal drafting, software architecture, hacker culture, or the self-styled 'philosophical' musings of one Richard M. Stallman feel."<p><a href="https://writing.kemitchell.com/2021/01/24/Reading-AGPL" rel="nofollow">https://writing.kemitchell.com/2021/01/24/Reading-AGPL</a><p>As Mitchell implies folks who want network copyleft should look into the more straightforward OSL3, IMO.<p>But it's something, and it's not my call to make because I didn't write the code, so properly I can only be grateful.
In time, I built this - <a href="https://github.com/hsnice16/golang_learning/tree/main/One2N/in-mem">https://github.com/hsnice16/golang_learning/tree/main/One2N/...</a>
During this time I believe a lot of alternatives (mostly protocol compatible to redis so they would be drop in replacements) came into light.<p>Has there been a consensus on one? Is there a winner?<p>I love redis and will probably keep using it. Just curious.
Redis should step up and fund an independent foundation now and encourage Valkey to contribute where relevant.<p>Some code under a 3 clause BSD and some under AGPLv3 could be interesting.
They can seriously screw themselves with the rugpull they made. I reported so many bugs and helped diagnose them in the sentinel module. Seriously fuck them.
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`.<p>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.<p>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.<p>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.
The increased use of AGPL is a good sign. Hopefully more people start to realise copyleft licences are what is good for us (people, communities). Permissive licences are for big corporations.<p>Looking at the comments it's amazing how much damage Ballmer/Microsoft did to free software with their "infection" rhetoric. Amazing that people would choose something that's good for Microsoft. Hint: if Microsoft likes something then you (a person) almost certainly want the complete opposite.
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:<p><a href="https://github.com/meta-llama/llama3/issues/156">https://github.com/meta-llama/llama3/issues/156</a>
While I applaud the effort to repair developer trust, do note that many organizations prohibit the use of AGPL.<p>Linked below is Google's own stance on why AGPL is banned:<p><a href="https://opensource.google/documentation/reference/using/agpl-policy" rel="nofollow">https://opensource.google/documentation/reference/using/agpl...</a>
Doesn't AGPL give you LESS rights? (fewer?)<p>AGPL is pretty much a non-starter for any commercial development.<p>The RSALv2 let you use Redis, unless you were a service provider. Now, you can't use it for anything (EVERYTHING is accessed over a network now) without sharing your source.<p>So, before everyone but amazon could use it for commercial purposes, now no one can.
Note AGPL license is in completely different class compared to BSD. Where BSD was level playing field allowing anyone to do commercial derivatives, now only Redis can do it.<p>I also question whenever this decision comes from the pure change of heart rather than threat of Valkey... and if so what else should we expect in the future
I think a project has to be Linux or Postgres big to really operate as open source. Why? Because cloud providers can easily sell your product and contribute nothing back. So, for anything < Postgres in size you need to create a new license to allow you to run a managed service. The problem is, with something like AGPL, companies that aren't selling your stuff (just using it), now need to release their stuff as AGPL as well. With so many things using Redis, it seems that millions of companies will now be in violation of the license agreement upon a given update in the future.<p>Personally, I think it is better just to call a spade a spade and release things with commercial licenses. Let all companies with < 1T market cap use your stuff for free. Companies that are making money will want a managed service or support anyway. Companies that want to host your stuff in their environment fall into the > $1T category.<p>The above is a bit of a strawman but what we really want is for valuable projects to continue to exist.
Cloud vendors have been strip-mining open source for years, yet judging by user and contributor sentiment on forums such as HN, and the lack of OSI-approved licensing innovation, there’s been no meaningful progress toward a solution. If anything, I get the feeling that the community is effectively more on the side of cloud vendors than on the side of authors. It seems the community at large doesn't care about authors' businesses suffering. Meanwhile, they largely don't oppose cloud vendors forking the latest open source version either.<p>AGPL protects better against cloud strip-mining than most opens source licenses, but doesn't solve the fundamental problem of big cloud vendors easily outcompeting authors' businesses. AGPL only compels source sharing when the software is modified and offered over a network. But cloud providers can sidestep that by hosting the unmodified version. They excel at operations at scale and sales. Most open source consumers seem to care more about benefiting from this than about the authors' struggles.<p>Fair source licenses — such as SSPL and Elastic License — while not OSI-compliant, are designed thoughtfully to balance authors' business and user needs, and don’t impact the vast majority of users. They often only restrict cloud-scale commercial hosting, not self-hosting or local use. Yet they trigger disproportionate outrage.<p>This is part of a broader problem: the community’s lack of empathy for authors. It is unsustainable. Open source maintainer burnout has been going on for a long time now. The "indie" open source author community is aging. Meanwhile, many big open source projects come from large coporations who use open source as a loss leader.<p>My impression is that:<p>1. the community at large is too stuck in ideological purity, in an age where the original FOSS ideology is a bad fit. Permissive licenses made sense when open source was a grassroots movement fighting for adoption — not when it’s powering trillion-dollar clouds.<p>2. People prioritize their own short-term interests too much.<p>Companies are doing open source because of the momentum we built over the past few decades. This momentum is being eroded by maintainer burnout, fragmented ecosystems, and declining trust between authors and users. Yet the open source consumer and authorities such as FSF and OSI effectively neglect indie author health. This is going to collapse one day.<p>If we want open source to survive as more than just free labor for cloud providers, we need a new movement—one that defends both user freedom and author sustainability.
was honestly waiting for something like this, but that trust hit doesn't really fade for me - you think companies ever recover from stuff like this or do folks just move on for good?
This is disappointing. The AGPL is a nonfree (and nonsensical) license.<p>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.<p>marcan has written about it in more detail than I care to: <a href="https://news.ycombinator.com/item?id=30044019">https://news.ycombinator.com/item?id=30044019</a><p>Stop using the AGPL. It violates the basic principles of free software.<p>The ability to run a SaaS company with free software is a feature, not a bug.
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.
,,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?''<p>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.
This will be very relevant when Valkey decides to go closed source.<p>It's better than the previous state of course, but it would have been even better if the previous license change didn't happen.<p>As the french people say: fool me once, shame on you...
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.<p>And for my personal usage, Rails 8 has moved Redis functionality into the database by default, which works fine.
It's a bold strategy, let's see if it works out for them.<p><a href="https://www.youtube.com/watch?v=9HVejEB5uVk" rel="nofollow">https://www.youtube.com/watch?v=9HVejEB5uVk</a>
Flagged for misleading headline. SSPL is open source. It's just not the open source you want.<p>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.<p>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.<p>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.