Redis 'returns' to open source with AGPL license Redis, the company behind the popular value-key database of the same name, has returned its main system to an open source license, although the move failed to satisfy some critics. people choose crossing on road Majority of Redis users considering alternatives after less permissive licensing move READ MORE Adding the GNU …
Yes, I suspect that most Linux distros will package Valkey instead of Redis, and most users will simply use Valkey unless they have an especially compelling reason to use Redis. I have doubts about the Redis company being able to provide that compelling reason, so I think they'll just fade away.
Yep, just went through the transition from redis to valkey on Arch providing the server cache backend for Nextcloud. Valkey is essentially a drop-in replacement for redis (a few config file name changes, and the Unix socket name), and it worked without a hitch. (okay, without any technical hitch, there was the self-inflected hitch of failing to restart php-fpm that left me scratching my head for a while...).
Trust is something hard won in open-source. After forcing distros to drop redis and adopt valkey due to the March license change by redis, the relicensing as AGPL strikes me as a bit too little to late and something that falls well short of restoring trust going forward.
Same here, except on FreeBSD.
- Install the Valkey Port
- Copy the contents of /usr/local/etc/redis.conf into /usr/local/etc/valkey.conf
- Change /etc/rc.conf to load valkey on boot instead of redis
- Shut down the redis service and start the valkey service
Everything worked just fine.
I think the outcome is still yet to be seen - as time goes on and they diverge in features and effectively protocol, what will happen?
Mongo already has some new shiney features (some good ones) that AWS DocumentDB doesn't support.
Also, AWS just isn't really updating DocumentDB anyway.
If they don't continue to give it love, and just give it the same "meh, we forked it" treatment, then opinion may eventually loop back around.
Success in software is all luck. There are many examples of rubbish winning, and many stories we will never know of great produts that nobody will ever find.
Since its all luck, its th ebutterfly effect, who knows they might have never hit their success if they started with different license.
Luck is stumbing across something you never knew existed.
Poor judgement is finding a gun with an attached note that says "caution, point away from you before pulling the trigger", aiming it at your foot and pulling the trigger. Redis may argue that the didn't know that a gun called "changing licensing models" would hurt so much but its hard to make those arguments when your customers are walking away and Redis can only limp after them owing to the damage done to their feet...
I say luck because there are many factors that no software product has any control or influence.
Is FB really the best social platform ? Did it really win based on merit ?
Of course not, there have been. many others that are just as good or better but they are dead.
Is Insta really the best from a technical or user perspective ?
Of course not, its more luck they got popular.
Of course there are many factors that members of the company and its reps that contribute to success or failure.
My point is there are many factors such as the public that may or may not select a product or service that no company can change.
Take FB and MySpace, it was just luck how one died and then the other took over or how the public selected both. Feel free to suggest that either reached their zenith because of technical excellence or being better in some way than others.
Because Redis was clearly looking for the most restrictive license that is open source. They think earning the open source flag back is all they need to do to get developers and customers back. I'm not sure if they're right, but I doubt it, and it's not because AGPL is a problem. Spending a long time not being open source is going to cause problems no matter what license is used when you come out of that. If they're still using a CLA, people who don't want to risk that happening again probably won't write code for them. I don't know for sure that they've killed their chances, as there are places that may pick that back up from name recognition alone, but it's a possibility.
Along with many other such vendors, they were sick to see AWS and others charging for the service but without contributing to the maintenance and development. Note to the VC investors – going for scale by being free and open and then changing the licence has not proven to be very successful. At the base of many open source projects and, in my view, the strongest argument for permissive licensing, is the realisation that pretty much anyone could have written the code, greatly reducing the value proposition for software licences.
What do we generally all agree to pay for is the service that packages the software for us to use. But, again, this implies that added value is low, which is why we see synthetic barriers to swapping vendors through, er, egregious "egress" prices, amongst other things.
> Along with many other such vendors, they were sick to see AWS and others charging for the service but without contributing to the maintenance and development.
This sounds like exactly the sort of problem that GPLv3 was designed for; people using GPL'd code to provide, for example, a web service. Since they're not distributing the code they're not required to abide by the conditions of GPLv2 and get to use the code without giving back.
Unfortunately we dont live in a perfect world. OSS also implies a contract based on good will. Its not really that one side writes a great product, and everyone takes them for a ride and gives nothing back. There has to be a balance the problem is in todays world everything is extremes.
Look at the orange one, everything he does is extreme. Extreme labels, everything is the best, the most, they are the worst, and so on.
The GPLv3 was designed as a direct upgrade to strengthen the freedoms granted by the GPLv2. The biggest challenge it aims to tackle is Tivoization, where a device manufacturer bundles GPL'd code with the device but does not provide a means of changing the code running on the device (or actively employs DRM technologies to prevent you from running your own version of that code). The other big change is about patents, and I'm not diving into that. Either way, it has nothing to do with what you're claiming.
The AGPLv3 (Affero GNU Public License) is the thing that you're thinking of. It's basically just the GPLv3, except with an additional clause that give users interacting with AGPL-licensed software over a network the right to acquire the source for that software.
I hope Redis wins back some traction because I'm still more strongly aligned with the Free Software crowd than the Open Source one.
Lets hypothectically say,
I have a surprisingly successful SAAS thing, that has a requirement for a redis-alike thing
There is no direct user interaction with the redis-alike thing, since it is there purely to support my thinga-doo-dad that some businesses see fit to pay fot. I have no intention of opensourcing my frontend and my lovingly hand-crafted frontend built in a surprisingly workable C++ servlet engine (that was purely to get some hackles up).
Now, does the AGPL affect me in the sense that "users are interacting with redis via a network"...
If you're not a lawyer, I pobably don't give a shit what your answer is, I'm not touching that with a barge pole, I'll just use valkey thanks.
I am not a lawyer, so you are free to ignore me, but in case you or anyone else wants to know the answer, here it is:
You're using Redis under the AGPL3 with the conditions you described. Here's what you have to do.
1. Your code: nothing. It interacts with Redis through its normal channels. You don't need to change licenses or distribute it.
2. Redis code: if you changed it and made a custom version of Redis, you have to distribute that to anyone who wants and you have to use the AGPL3 to do so.
3. Attribution: Somewhere in an about screen or documentation, you have to say you're using Redis which is AGPL3 licensed and refer people to copies of those, but you can use Redis-hosted versions.
Feel free to get a lawyer to verify this. They cost more, though.
The software is part of that infrastructure. I don't begrudge it, I think it's a logical consequence of our economic model, but it's clear that there are several instances where the cloud providers have gone head-to-head with the original developers. That's a poor business model in my view and I'm happy to see VCs go down with it. But we do also need to think about financing development for some projects. Personally, I think things have improved but competition with vendors and potentially the idea of liability could help.
Instead of trying to see this as an argument and picking a side, consider the pragmatic point they're talking about. If you run a project with users and you change the license of that project, some users will face legal consequences, which may reduce your user count even among those who don't object to the new one. This is something for creators of projects to think about when deciding what they want to do with their licensing. Often, if they choose one license and stick with it, they are more popular than if they change it. That is even true for things that start out as proprietary. Many, including me, are completely fine with proprietary code but much less happy about open source code that suddenly switches to proprietary.
AGPL is fine. If you host AGPL softwate to the public, you jeed to share your changes, no big deal. It was tailor made for Redis and Elastic and whoever else has gone "source available" since then.
I see it as a litmus test of sorts. Does a company want to actively be a member of the commons or just profit? In the latter case, yes, you will find reasons to reject the AGPL.
Anyone using Redis v8 under the AGPLv3 license will have to release their changes to the code, but it will not guarantee that any changes would make it back into the primary Redis source tree.
This is becase Redis is now a tri-license RSALv2/SSPLv1/AGPLv3 and if code is just released back due to AGPLv3, it would not be able to be merged back into the Redis tree.
I get it that a wide range of similar licenses is not a good thing, but the article and the commenters here are acting like it was a closed source license.
If anything, it was a more free (in the sense of freeing source code) license than the similar AGPL:
"Wikipedia: It includes most of the text and provisions of the GNU Affero General Public License version 3 (AGPL v3),[4] but modifies its provisions for software that is conveyed over a network—requiring that anyone who offers the functionality of SSPL-licensed software to third-parties as a service must release the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL. In contrast, the AGPL v3's equivalent provision covers only the licensed work itself."
Of course, if other parts of your setup use proprietary software or for other reasons, this may make it impossible to use this software, so there are additional restrictions, but it's still "open source" in the literal sense, even if OSI won't rubber-stamp it as such.
The SSPL is neither free software nor open source. The SSPL license explicitly violates parts of the OSI's definition* and arguably removes one or two of the four freedoms that are core to the FSF's philosophy**. That's why we have a problem with it. Oh, and it's deliberately doing this to be impossible to comply with so that you pay the copyright owner to get out of it, meaning that they're not even doing this for ideological reasons. The other license they used, the RSAL, is even farther from open.
* The OSD is quite clear. The SSPL clearly does not qualify because it violates rule 9 and, to a lesser extent, rule 6. The text explains how with sufficient clarity that I don't have to go into more details.
** I will go into more details about the four freedoms of the FSF's definition, though. They are not as clearly defined, but the way they have been applied makes it clear that the SSPL removes freedom number zero, the freedom to run the software as you want to. Normal free software licenses impose terms on those who make derivative works from them, whether those are slight modifications or massive additions, but they don't do that on anyone who installs it. The SSPL does. Depending on exactly what you want to do with it, those terms may not be important, but unlike actual free software licenses, they're still there. The nondiscrimination element that is so explicit in the OSD may not appear to be there, but it is often included in freedom number zero, itself considered so obvious a requirement that the FSF didn't think it needed to be listed for a while. Of course, we could argue about how much this matters, I think it does, and you might not, but what's more clear is whether the organizations concerned think so. They do, which is why neither of them support the SSPL.
Sure, it fails the OSI definition, but the phrase "open source" existed long before they or the FSF did.
And yeah, the restriction on anyone installing are more severe than just if the code is modified, but both are still restrictions, yet one cannot be called "open" despite all source code being on GitHub, and I can legally download and use it for free.
It's just AGPL+ and that one is considered "open"
I'm not trying to be antagonistic - I respect you and your posts on here.
P.S. Not my downvote - I wish your downvoter had responded to why.
The problem is that, to know whether something is open source, we need a clear definition of what that means. The OSI is not the only place that has a definition, nor do they really get a monopoly on the term. However, I tend not to accept someone else's idea of what it means unless they can provide their own unambiguous definition and apply it consistently. Often, when someone does that, I don't find their alternate definition as convincing or persuasive as the OSI's, which I mostly agree with. This is not for any reverence for the OSI itself. I never check whether the OSI has stamped their seal of approval on a license, and I disagree with them on a lot of things, notably their AI licensing thing which I think is completely wrong. The definition they're using, however, is pretty good.
Most of the faux-open licenses use vagueness to imply that it's basically the same and rely on "it doesn't affect you" to distract from problems. I have a problem with both of those things. A lot of them have their category of people who get extra restrictions if they use the software, a category based on vague conditions like "commercial use", or, in the case of the SSPL, "as part of a service". The licenses do this because the authors want to apply it to certain people, often cloud services. However, it's easy to argue that everything is part of a service unless it's running offline and only used by me personally and everything is commercial use if there's any possibility of money being involved, for example if there's a donation button on the site, even if nobody's ever clicked it. Even if it's only against AWS and Azure today, someone who wants cash could easily change their mind about those terms tomorrow. In all the cases I'm complaining about*, there is already a precedent for this because they just changed their licensing already, so changing their interpretation of "service" is a much smaller change which could cause problems for everyone. That is not a small difference from the AGPL.
* I do not object to someone who writes something from scratch and wants to license it under one of these from the start. I object when someone made their software open source then switches to it, mostly because they are taking the contributions of others to do it, and in some cases, preventing others from using their own contributions without forking.
Surely if those terms changed though, then you wouldn't be bound to them unless you upgraded. I see your point regarding they have form for changing their mind, but that argument has nothing to do with the license, and could happen with any of them.
It's a fair point about the vagueness of the terms though.
I agree it's a larger difference that it would be with the AGPL, but the AGPL still has some restrictions, so where is that line drawn? As for me, I tend to go the BSD license route, but I do see why others would disagree.
However, your final paragraph nails it, and to that I totally agree - **changing** to a more restrictive license is a moral no-no in my book - for exactly the reasons you mention, but again, that could be argued about any license change. Whilst I have committed patches to GPL software with no issue, I'd be annoyed if some stuff I patched under BSD switched to GPL.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
