Redis is open source again
antirez.com
antirez.com
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.
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.
Amazon gets to make millions off of the thing you built.
"Equitable source" licenses with MAU / ARR limits, hyperscaler resale limits, and AGPL-like "entire stack must be open" clauses is the way to go. It's a "fuck you" to Amazon, Google, and Microsoft in particular and leaves you untouched.
Open source today is hyperscaler serfdom. Very few orgs are running Redis on bare metal, and a equitable source license can be made to always support the bare metal case.
If you're okay with that, that's cool. But they'll profit off of your work and labor. And the worst part is that at scale, the advantages of the sum total of open source is used to compete with you and put price pressure on your salary and career options. To rephrase that, the hyperscalers are in a position to leverage open source to take advantage of market opportunities you cannot, and they can use that to compete with your business or competing businesses that might otherwise pay you better.
Open source needs anti-Google/Amazon/Microsoft clauses.
Not everyone thinks infectious copyleft / free software is a problem. But it will mean that if you use AGPL3, every part of your stack has to be open. That doesn't work for everyone.
This is why "equitable source" / "fair source" is gaining traction. You can use a license like Apache and add in clauses with MAU/ARR/Hyperscaler limits that allows practically everyone else to use your software.
AGPL does not and has not prevented hyperscalers from creating managed services for software licensed with it
That’s why mongo created the server side public license, which does require open sourcing the entire stack. MongoDB was AGPL before that
AGPLv3 says, if you modify the software and put it on a network, you have to provide a link for anyone accessing the software to download the modified source. There's numerous drafting and technical problems with this arrangement[0] but the only parts of your stack you have to release are the parts that are actually part of the program covered by AGPLv3.
The "strong copyleft" strategy[1] is to identify a specific freedom-restricting behavior we don't like and prohibit just that. We're not saying "Amazon is not allowed to use this software", we're saying "Anyone who turns this software into a service needs to provide a way to fork the service and get the software back without losing anything". If such a copyleft license happens to scare a company into buying license exceptions, that's a happy accident.
In contrast equitable source doesn't say anything about freedom, it just says "these people need to pay a license fee". That's not FOSS, that's shareware. In FOSS, free-riding is not a bug. The problem with AWS isn't that they aren't paying a license fee, it's that they are building roach motels out of community projects.
[0] I'd link to Hector Martin's incredibly informative Mastodon posts regarding the subject, but he deleted his account after crashing out of LKML. As a substitute for that, I'll summarize my hazy memories:
- The intended compliance mechanism is to make your app a quine; but that only makes sense for webapps written in PHP/Python/etc. Someone actually put AGPLv3 on an Ethernet stack - how do you comply with that?
- It's unclear how license compliance works in a pull request driven Git workflow. If you're running the server locally for testing, and someone accesses it, have you violated the license?
- You can filter out the source offer with an HTTP proxy not covered by AGPLv3. That seems like a very wide loophole which the FSF apparently believes would work.
[1] e.g. AGPL, SSPL, OpenWatcom, etc
And yet somehow people keep making new projects under MIT 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.)
if that's your "good legal reason" to avoid the GPL, then it's just as much a "good legal reason" not to open source your work at all: if the GPL is not enforceable, that would mean you have used a non-copyleft license, which according to you is the thing you want to avoid for good legal reasons.
you said "avoid gpl". reason? "unenforceable". eliminating gpl from consideration, thus you advocate non-copyleft licenses instead.
with me so far?
but gpl's "unenforceability" could only mean it turns into a non-copyleft license, one which you say one should not use, so if one shouldn't use gpl because in reality it is a non-copyleft license, then you must be against non-copyleft licenses.
just to state it again for clarity: "don't use gpl because copyleft is unenforceable so gpl is just MIT underneath, and I repeat, don't use it" is a recommendation not to use MIT license.
Note that I don't agree that GPL and MIT are equivalent, or that GPL becomes a non-copyleft open source license if not enforceable. IANAL but it might revert to the regular copyright law for wherever you publish software, not an open source license.
(also, it is enforceable and has been enforced, but that's a separate topic.)
> there are open legal questions about whether the GPL and its variants are enforceable.
GPL v3 also has a nice clause that allows companies to "repair/cure" their non-compliance.
> Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
The community did not like this one bit, but MongoDB doesn't need to care about what the community thinks because they had CLA'd all their contributors. That is, if you wanted something in MongoDB upstream, you had to give MongoDB full copyright ownership over the software. Which exempts them from copyleft[1]. One of the critical parts of copyleft is the "no further restrictions" rule; otherwise copyleft is just proprietary with extra steps.
[0] I don't remember if they were hosting MongoDB as part of RDS or something else.
[1] As we've seen with the Neo4J lawsuit, copyright licenses cannot tie the hands of the copyright owner. The only way for copyleft to work is to create a Mexican standoff of contributors who will sue each other to death if any one of them decides to relicense without unanimous community consensus.
Because once it was clear that software as a service was a compelling model, it was no longer appealing to give everyone the permissions needed to offer the software as part of a service (as AGPLv3 was always designed to do).
Changing the license seemingly worked, as a partnership was eventually announced [2].
[1] https://github.com/Tencent/CMONGO
[2] https://www.mongodb.com/company/newsroom/press-releases/tenc...
That’s an exaggeration. The vast majority of permissively licensed projects have never “rug pulled” and never will. It might be one possible reason to choose such a license but it’s very far from the only one.
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.
What is it with .NET that compels you to lie?
Also FOSS and open contribution are different things, as sibling comment notes.
If you think otherwise, I suggest checking if there's any aluminium foil on your head.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons..."
Are you actually unaware of this? If so, why? Is it age or have you been sheltered somehow?
MIT license allows this, hence it's not a free software license. Because very large corporations don't like freedom they've poisoned the discourse around software freedom and launched PR campaigns trying to substitute talk about freedom with talk about openness or open source. To some extent they've succeeded, as evidenced by the chatter about it in this thread.
I don't know how you can extinguish something that's MIT licensed and has a million copies around the world.
I wouldn't trust Microsoft near my open source code base in 3 centuries
They can extinguish it by just stealing all the code, and using their bigger marketplace advantage to become the defacto standard.
gestures wildly at the MIT-licenced VSCode codebase
Yes, they are not rug pulling the VSCode source but by locking down the marketplace (and never giving a truly open source VSCode, what developers think of as "VSCode") they are in the processes of locking out forks.
Fair point! good example of an attempt to extinguish.
Like seriously - I haven't heard of them doing it in quite a long time. I know they were atrocious in the 90s and 00s, I'm not disputing that at all. Are there any examples of them continuing this behavior in the last decade though?
Further, a huge percentage of the people making those decisions back then are no longer with the company, different people are in charge, etc. The industry has changed it's relationship with open source - company board rooms aren't scared of the consequences of loading open source onto a server, the legality and liabilities have been hashed out, and MS isn't really even capable of pulling those fear levers anymore. MS itself has repositioned in the industry - their dreams of total computing dominance have been shattered: there's no chance of a windows derivative owning the server market any more, there's no money in browsers or consumer OSes (heck even MS's domination in gaming is showing cracks due the the efforts of valve). Point being - would it even make strategic sense for them to try to EEE anything anymore?
Note: I have almost no ties to MS. I haven't used an MS os or desktop software since before covid (in any capacity, even moving the mouse on a computer running windows). I don't use any of their SaaS products personally or professionally. There are integrations between the products I help build and azure, however those are not a major source of revenue for my employer and I do very little work that even touches that stuff. Point being - I'm pretty non-MS in my life and don't have any sort of loyalty or incentive to defend them. I do abhor their EEE actions back in the 90s and 00s when they were doing them, and those still make me angry... but that's not a reason to assume that different people at a company are going to act the same as the old-school ones.
While it may technically be open source due to it's license and you can literally go look at the source - Microsoft is operating these codebases as-if they are proprietary. Every decision is made out of public - and I would not be surprised to learn they have their own internal tracker for the "real" backlog items. You frequently see command/comments by Microsoft employees which clearly are triggering workflows in their real backlog tracker, and near-zero discussion happens in Github by Microsoft employees, and when it does - it's clearly through a PR filter.
Like I said, beggars can't be choosers and it's better to have this than nothing - but I don't really think Microsoft has grasped the true concept of FOSS as-of yet.
> Is SQLite not open-source?
Not really in my opinion either. There's no way to contribute at all... best you can do it raise hell on the forums about a particular issue you want to see fixed. So while it's Open Source in the strict sense, it's not Open Source in the general sense.
The sibling comments contain some sharper critique of Microsoft if you haven't read them yet.
> best you can do it raise hell on the forums about a particular issue you want to see fixed
Also, do you have any open source projects that you wrote, maintain, and accept contributions?
There seems to be a disconnect here. I agree, demanding someone else make changes for you is in poor taste. The issue is, some of these projects advertise themselves as being open source while having no meaningful way to contribute changes back upstream - ie. the spirit of open source.
If I use your program for free, and encounter a bug, I should be able to fix it and contribute that back upstream so everyone benefits. That's my way of "paying back" and helping the community. Projects that reject contributions, or make contributing difficult are not in the spirit of open source, even if they are technically open source via their license.
That's what I call "fake" open source - you want the positive image of being Open Source only.
I mean, you're not demanding someone else make the changes. You're only demanding that they engage and build a community around their project and all that entails.
As long as the license is reasonable, anybody else could pick up the project and do the community building around it. Apache HTTP Server developed around community patches to NCSA httpd. I don't think hitch (from the people who brought you Varnish) is well know, but it started as stud with community patches. If something like this takes off, the originator will either start taking the community patches too, or not; it's their choice.
In the meantime, as a user, I get the benefit of whatever changes the origin provides and I can patch it as I want, and fix up problems that I see. That works for code dump open source and community open source,.
Not everyone has time for a second or third full-time job.
Am I "fake open source"?
In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
That's not to say you are required to accept all contributions - I'm saying you should be open to contributions that A) save you time B) enhance the codebase or C) fix confirmed bugs.
In Microsoft's case - I don't see a lot of that going on. I see lots of Issues (bug reports), some PR's, but mostly opaque decision making, and complete silence on things the Corporate side of Microsoft doesn't want to comment on yet. Which is the beef - it's a corporate project run like it's proprietary but you can go look at the code. Again, better than nothing, but it's not really what I consider true open source.
I'd say the spirit of open source is that others are free to modify the code and that's it. This requires a good license, the possibility to fork, some documentation and a way to build the project yourself.
But why would accepting contributions be required?
This blog post is legendary (in my mind): "Open Source Maintainers Owe You Nothing" -> https://mikemcquaid.com/open-source-maintainers-owe-you-noth...
It perfectly sums up how this conversation is going.
I disagree. There's nothing about open source or the various open source licenses that require accepting engagement from the community and/or contributions.
Open source means allowing modifications, and sharing those modifications. It's in most licenses that the software is provided as is and without warranty.
> In my opinion, for something to be truly open source, I should be able to fix a bug I ran into, or implement a feature from the backlog and contribute it back upstream. If upstream is just going to ignore my contribution, pretend it doesn't exist, or reject it just because - then that codebase is just pretending to be open source.
A project not accepting outside contributions is still open source, not pretending to be, and the beauty of it is - if you want it to accept outside contributions, you are able to fork it and accept contributions on your own fork, or otherwise share your modifications. But there's absolutely no obligation of the original dev/owner to accept or engage with anything from the community. It's in the license, the software is provided as is and without warranty of any kind.
Maybe it's worthwhile to coin a new term, community software, to specifically make a distinction between projects that are community developed (accept contributions) vs those that don't.
How long after they release their code are the required to keep this up? Do they need to respond to your requests within 5 business days?
If they retire / move on to another project, does the source code stop being open source?
It was about being able to have access to, fork/modify, and redistribute the software. That's the important thing - that the software I use can be modified by me, and if I wish to do so, the license allows me to then redistribute those changes vs. proprietary software, which cannot be modified nor redistributed.
I'm not sure why the zeitgeist went from the above and turned into "all open source must be community software and engage with users and accept contributions" because that was never what it was about. It was a benefit of some projects, sure, but at the end of the day the important thing isn't whether or not the project accepts contributions but whether I have the power and license to modify something to my liking, fork it if I wash, and/or redistribute my changes.
It struggles a bit on certain types of workloads like hot keys, think heavy hitting a single sorted set. It's a cool architecture.
As good as Redis is, modern computers with multiple cores potentially leaves a lot of performance on the table. Garnet seems to be a well designed multithread KV-store (though sadly the benchmark page doesn't list benchmark for more complex objects even if the simple cases looks good).
Nowadays your webapp is often a persistent, multi-threaded web server where you can cache whatever temporary state you want far more efficiently than reaching out to a KV store.
Using postgres and caching common results becomes a non-issue even at scale. The main area where a super fast KV store shines is when you need to share a very large number of keys, where many servers only need to access a random subset and isn't interested in maintaining the full set and getting updates on a bus, where the values often change and needs to be revalidated so caching is ineffective, and where persistence is not needed so a database doesn't matter and a lighter KV store is acceptable.
(I'd imagine implementing mechanisms for resilient storage and larger than memory data sizes would be the hard parts)
EDIT: Weird that being a program from Microsoft (well, it's Microsoft Research, so that probably explains it?) it has no installer and doesn't run as a service on its own.
Yes, of course.
> and moral level. Feeling betrayed is absolutely uncalled for.
Er, no, that's an unsubstantiated leap.
All those people that contributed, did so to the FOSS version. Their contributions live on in all the forks, both FOSS and proprietary (by Amazon & co., and Redis before today). So not sure where "betrayal" supposedly happened. Maybe when Amazon used their contributions too?
Never trust a company.
It is just that people don't hear what they don't want to hear. Every BSD or MIT is a loud and clear statement to deny the guarantee that derivative works will remain free and open.
https://github.com/redis/redis/blob/unstable/CONTRIBUTING.md
I am pretty sure that AGPL makes you distribute your changes to your users, not to Redis.
You need (to open source) (your changes to Redis)
I.e. "you need to open source [your changes (that you have made) to the Redis codebase]"
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).
SSPL is not as bad as the OSS community pretends it is (unless you're a hyperscaler).
Neither company has built in a legal safety mechanism to prevent themselves from pulling the rug again later and both companies have shown themselves to be untrustworthy stewards. They came groveling back when it turned out that community goodwill really did matter after all, but this is definitely a "fool me twice, shame on me" situation.
Unless of course you are an AI startup.
I think it's more "they are no longer piggybacking off our work for free".
I also think what they actually wanted was that plus "...and they paid us".
1. People put a lot of work into building databases. The license choice is OSS / FOSS.
2. Some people in the community (original authors, community leads) make a company around the database and continue developing it for years on end. They sometimes raise venture capital to expand the business.
3. Amazon / Google / Microsoft offer managed versions of the database and make bank on it. Easily millions in revenue. Original creator / company doesn't get anything, and the hyperscaler isn't obliged to pay.
4. The company decides to change the license to force Amazon / Google / Microsoft to pitch in and pay a fee.
5. Amazon / Google / Microsoft fork the database. The community revolts. Sometimes the people revolting are employees of the hyperscalers, other times these are just FOSS fans that hate "source available" licenses or relicensing.
6. Database company is forced to walk back the changes. Still no revenue.
---
The solution is clear: start your new database with an "equitable source / source available" license from day one. Nobody will complain about a relicense since your license will handle the hyperscalers right off the bat.
Basically your license needs one of a few things if you want to prevent Amazon from walking off with your money:
- A hyperscaler clause such that any managed offering has to (1) be fully open source, (2) has to pay a fee, or (3) is prevented outright.
- A MAU / ARR clause such that hyperscalers are in the blast radius. Note that this also hits your customers.
which is sort of funny because the term "Open Source" was itself coined to make it possible for people to seek funding to build companies based on the (crazy?) idea of producing software, then giving away its source code
20 years later, the structure of the industry has now changed, and now "Open Source" exists to feed Amazon, Microsoft and Google
if it's not possible to alter the definition to include licenses that include terms that allow sustainable value creation for businesses other than the hyperscalers, then the term is no longer fit for purpose, and we need a new one
"Fair Software"?
That's the term most frequently used! I've seen a number of different efforts start to coalesce around this.
This was also a really nice license:
We need licenses like these to combat Amazon, Google, and Microsoft. "Open Source" is their grift now.
Both the OSI and the FSF are agreed that Source Available with bans on specific use cases is not FOSS. When you've got freaking Richard Stallman opposing you you really have to do better than just scream "corporate capture". Engage with his idea of Freedom, don't set up straw men.
> Both the OSI and the FSF are agreed that Source Available with bans on specific use cases is not FOSS.
well... yes, because they decide the definition of the terms
> When you've got freaking Richard Stallman opposing you you really have to do better than just scream "corporate capture". Engage with his idea of Freedom, don't set up straw men.
Stallman has a very particular view of Freedom (itself a multifaceted term)
and he rather famously completely rejects the term "Open Source"
the situation we're finding ourselves in is one where three increasingly malevolent entities control and capture 100% of the value generated by writing and selling software with source code
if you're an employee of these entities, great for you
for the rest of us, this is a bad situation to be in
and certainly not one that could produce another Red Hat
As for Stallman... his idea of freedom is very narrowly-scoped. In particular, it makes no distinction between hobbyists and megacorps, and is completely blind with respect to economics.
By lumping hobbyists with companies, it makes the category error of extending human rights to corporations. This of course, is nothing new in America, and hasn't been since the infamous 1886 Santa Clara County vs Southern Pacific Railroad court case, that established corporate "personhood".
I never said corps shouldn't be allowed to use free software.
But I do think corps should not be allowed to be economic free riders of any software.
I'm not sure this is true. The OSI's definition of open source doesn't seem to have changed since ~2001 [1] - before AWS was founded - and it'd been around in various forms since ~1997.
This was the era of Microsoft's 2001-era "Shared Source license" which was deliberately GPL-incompatible; Bruce Perens, author of the definition, wrote "Microsoft's Shared Source program recognizes that there are many benefits to the openness, community involvement, and innovation of the Open Source model. But the most important component of that model, the one that makes all of the others work, is freedom." [2] (Perens also judged the first version of the "Apple Public Source License" insufficiently free [3])
They've kinda always been about not just being able to view the source, but also modify it, and redistribute the modified version, merge it into other software projects, make commercial use of it, etc etc
It just so happens that this stance, adopted well before AWS existed, works extremely well for AWS.
[1] https://web.archive.org/web/20020126171934/http://opensource... [2] https://web.archive.org/web/20010813210224/http://perens.com... [3] https://web.archive.org/web/20010430042835/http://www.perens...
In a lot of ways things like AWS are what the OSI set out to create when they set out to sell Free Software as an idea to corporations. This was the pitch.
This predates the OSI definition. The philosophy is about what empowers the user. Business models (or their challenges) have nothing to do with it.
It just so happens that empowering the user also empowers competitors.
The landscape has changed. Google, Amazon, and microsoft are actively trying to destroy open source business models. Don’t let the leopards eat your face because you were too attached to your ideology.
You're conflating ideologies. User-focused ideology doesn't care about business models. Leopards aren't eating their faces. They're perfectly fine where they are.
Business model focused ideology might care, but the AGPL exists and meets Debian's requirements. Those who care can choose to use it, or not, as they wish.
IMHO copyleft licences are better for the user and permissive licences are better for competitors. Still people keep going with permissive licences.
And in this case it means that it's not AGPL, but proprietary. Which kind of proves my point: they are apparently paying Grafana Labs to avoid the constraints of AGPL. If Grafana was permissive, they would surely not pay.
Amazon hosting Grafana means it's not only "permissive licences are better for competitors".
Copyleft licenses don't present obstacle to competitors that people seem to believe.
Thank you for pointing that out.
This is something I have noticed in the last decade:
A lot of fake, captured organisations have popup around open source. I once went down the rabbit hole to try to make a list and quickly found dozen of them. It is always very hard to understand what they do and employ a bunch of people who usually never wrote a single line of code.
One example found on the Fedora website is the "Digital Public Goods Alliance" [0]
Yes, this would be the honest thing to do, but people don't do it because using a non-FOSS license loses you adoption. The step you're missing in your little timeline is that the only reason the project takes off at all and becomes big enough that anyone is making money off of it is because it's Open Source. Proprietary databases, programming languages, and similar have lost big time and that's not changing any time soon.
So what's really happening is that these FOSS companies want to have their cake and eat it too. They want to release code for free so that other devs will use it and then make money from the project while somehow banning other companies from also making money off it.
If this true, than we need something else.
Otherwise, expect to see a hell of a lot less new FOSS in the next decade, which will be a pyrrhic victory.
If FOSS can't meet the demands of the time, it needs to be updated or replaced.
What a weird reality, seems hyperscalers have truly won and OSS is dead at the same time
talk about kicking down. So no harsh words about the big dogs who, while contributing nothing, and just due to sheer size and scale advantage, are capturing the lion's share of the enterprise value?
This is a line that gets thrown around very casually, but every assessment I've heard says that the big dogs are quite prolific contributors to these projects.
> capturing the lion's share of the enterprise value?
Ah, here's the Matt Mullenweg logic creeping in again [0]! This is basically his taunt towards DHH (though at least you're using it to cry foul rather than tease!): "although he has invented about half a trillion dollars worth of good ideas, most of the value has been captured by others."
And this is where I think most of this aggression towards cloud providers is actually coming from: a significant number of these companies have bought into the idea that they're a failure if they fail to capture the majority of the value from their Open Source project. Which is understandable when you make a VC-funded business out of it, but makes no sense given that FOSS has always been about advancing the collective good, not raking it in.
[0] http://web.archive.org/web/20241014235025/https://ma.tt/2024...
ok sure, but there's contributing and contributing.
> a significant number of these companies have bought into the idea that they're a failure ...
ok, fair enough. But in that equilibrium you're painting, _only_ companies like AWS will ever be able to monetize open source, especially since software delivery and SAAS are essentially equivalent in 2025, and SAAS is a margin's play which small fry cannot compete with.
VC-funding is also the lever that allows for open source software to find deep and quick penetration in the industry. it's not aws driving it. So when a practitioner benefits from the mature tooling and such a wide userbase of say Redis or ElasticSearch, it is not only because it was cheap (open source), but also because it was lavishly supported (VC).
> I think most of this aggression towards cloud providers is actually coming from ...
I mean, you're certainly right about that, wouldn't call it aggression necessarily.
The software platform is different now than it was 20 years ago. If we want a thriving open source ecosystem, we will need a answer to the fact that big tech can hover up the spoils before the upstarts - that both spearhead the project _and_ fund its expansion - have a chance.
With copyleft being effectively banned in most companies, it means that there is no viable FOSS business model.
Reality is that for now, many FOSS contributors do it for free in their spare time. Comically critical pieces of infrastructure rely on such goodwill development. But as cozy salaries decline and job security does, less people will have time to work for free. We will have less Foss, less innovation, less new viable projects compared to if there were no hyperscalers.
How does this advancing the public good?
Licence freedoms don't have to be all or nothing, or apply to everyone in the world. It can be open source and have restrictions. Anything else turns open source into a religion.
However I think Postgres is a bit different. It's a bigger market and more widely used. There's a need for tuning services no matter which platform provides the database servers, so there's a level to make money above cloud hosting.
See Llama's license: if it can be Open Source while having restrictions, then having an Acceptable Use Policy is okay, right? So Redis could create a license that bans its use if you host adult content, Star Wars fan fiction, or documents containing the letter R?
If Open Source doesn't mean a license that indiscriminately grants a set of specific freedoms then it's pretty useless as a term—all I know on hearing it is that a project's source code is available. Which reminds me, we already have a term for that: Source Available.
Open source means exactly what people say it means and what they want to understand by it
I've written code in the past that I put under GPL that today, I'd probably use a different license for (BSD 3-clause has my preference these days, although I'd just prefer a generic non-commercial license instead). I don't really bother relicensing cuz... it just doesn't matter in the end, these projects are super niche anyway. I picked the GPL since "everyone uses it".
There's always this backlash to demonize anyone daring to move away from the GPL when the simple fact is... maybe some products just don't work in the modern market with the GPL. The hyperscaler thing is a pretty massive issue and the fact that GPL proponents can only give platitudes of "it's working as intended"/"fuck your greed" instead of y'know, accepting that maybe the GPL doesn't work in these environments is... not great.
That isn't a defense of the SSPL or anything like that (it's quite the bad license), but there's a reason that these entities keep writing new licenses instead of going "all rights reserved, we publish source as a courtesy, you can't use it for anything" (even if they effectively close all contributions, they still want to try a permissive license.
Basically the thought that goes into picking the license often isn't nearly as complicated as you may think. It can literally just be "if everyone is doing it, maybe what they're doing is right". Not so much "the GPL gets you more contributors".
In spirit the AGPL is what is needed but in practice it kills any corporate adoption sadly.
A license that singles out hyperscalers or goes by revenue is probably a better bet.
Maybe a license that is more clear canbe written, maybe not.
This is the heart of all of these stupid takes. There is no "your money" for anyone else to walk off with. Nothing was stolen.
If you want to sell software, or rent access to software, then just do that honestly forom the outset. And good luck to you on that. I will not consume it unless I have no other choice, and I will not contribute to it at all period, even tertially by for instance developing things that use it or help people work out how to solve problems with it etc. In other words just generally not invest in it, in all the different ways one might invest in something. But hey maybe you will make something indispensible and do it better than anyone else can, and maybe you will get a bunch of other customers.
If you want to benefit from the adoption and goodwill and army of free work that comes with open source, then do that.
The honest reason to work on open source is because you yourself have recognized how much utility you have been given fo free because of it, and wish to pay it forward and basically add to humanity as a whole. What you get back out of it is the same thing everyone else does, the use of the software itself, plus your name being on it.
But if you license something open source, and then care the TINIEST BIT what someone else does with it beyond adhering to the attribution and share-alike terms, then you have missed the point of open source. You are bent about being "robbed" of something that was never yours in the first place. You have no right to Amazon's billions, even the part of it that they made by hosting a copy of some oss software you happened to have written. Amazon is not selling your property, they are selling a managed hosting service. You have no right to the revenue from that. The software being hosted is a community resource there for everyone to use like the air or water, only even better since unlike Nestle taking the water from everyone else, everyone else still has the software.
If anything the supposed injured party in all of these cases are the bad community members because they are often only OSS disingenuously in the first place. They start off with MIT/BSD style licenses because they know a lot of companies are allergic to GPL. But WHY are they so intolerant of GPL? Because GPL doesn't allow them to steal, but MIT allows them to steal. So they start with an MIT-type license because it's "commercial friendly" and then later cry that someone "stole" their B S freaking D licensed software.
People that do that were never writing open source for the purpose of adding to the community pool in the first place. It's either dishonest or at best, possibly honest but in that case just unbelievably incompetent and ignorant.
Yeah, it’d be great if everything was open source and everyone was happy.
But that’s not really what happens. Redis and Elastic are popular exactly because there’s entire companies behind it constantly maintaining it, securing it, and adding features.
If you want use open source software at your job that’s a hard requirement. No, you can’t use “MySillyKeyValueCache” that Timmy develops in his free time with no security or compatibility concerns.
Companies cost money to run. Google and AWS exploit open source work for profit, and don’t contribute back enough to ensure its support. This is what you should be really mad about. The internet giants are literally killing open source.
If they have their way you’ll be stuck with their proprietary software. In practice AWS is already there.
If you don't understand it such that you think it's a fantasy (despite the ocean of existing software as proof that is produced, and countless published manifestos from people who do it describing why they do), well that's a you problem not a me or anyone else problem.
You don't get it, that's fine, then simply don't get it, and don't participate in this activity you think is insane.
You are free to have any opinion you want about what constitutes a rational use of your time and effort.
But don't pretend you understand something that the participants do not understand. We're all eating non-fantasy food just fine, somehow.
Do whatever you want but it's no one else's problem if you can't figure out what.
Ya got no argument here.
If you want a business, build a business. One key aspect of building a business is understanding what your IP and trade secrets are, how they affect your bottom line, and then controlling them appropriately.
I’m guessing you don’t want that either, so come up with a way to make sure Redis has the financial support it needs to hire engineers to do the full time work that part time contributors like us don’t want to.
It is not true that if redis didn't exist then I'd be using some MS or Oracle product. I might, if it was practical. Or someone might have invented redis, or I might if that was a space that still needed filling and somehow no one else did it.
It's like saying if linux didn't exist we'd all be using NT.
That's completely ridiculous. No we would not. BSD already existed and if not that then a minix clone or someone else would have started some other unix clone. There were several small unix clones and other full OS's made by completely small developer teams by then, even single people, commercially. If a single guy can do it at all (regardles that they were doing it to sell), it means the job is not infinitely big and so perfectly doable by a few self-motivated volunteers, especially given how that kind of work has no deadline.
Except "volunteer" is the wrong word because they aren't some kind of weird saint doing something just for you or me. They are doing it for themselves, and you get to have it too.
Everything is like that. Redis is no different. There is nothing magic about redis. Things exactly like that get created when the need for them arises every day. If redis didn't exist is a nonsense invalid premis because 12 redis-alikes will always exist any time the need for it exists. It doesn't matter that I didn't already do it muyself, and I don't have to now either, and that is not just beacause redis happens to exist.
In reality, that’s not how it works. If to use Redis your company had to assign someone to do maintenance work then you just wouldn’t be allowed to use Redis. And yes, you would be using MS Redis, because none of the clones would be secure and supported enough for you to feel good using them.
They would have to publish their changes if those projects used copyleft licences. Copyleft licences don't force to "contribute back", but they force disclosing the changes, that the community can then benefit from.
But they don’t solve the problem of cloud providers pulling the rug out from under companies based on open source companies.
So TooBigTech can build a service upon a copyleft project, but they have to distribute their changes, which means that the community can benefit from them. One example I learned about here is Grafana: AWS did not want to use their AGPL version so apparently they pay Grafana to get a commercial licence. That's of course possible only because Grafana own the copyright of the whole codebase. It wouldn't be possible with Linux, for instance, where nobody has the power to give a commercial licence and therefore it is GPLv2 for everybody.
It doesn't prevent TooBigTech from competing by serving the open source project, but that is more of an antitrust issue, I think.
I didn’t know about Grafana. That sounds awesome.
Maybe you’re right about this being an antitrust issue though.
I mean the intend of apgl is exactly right, but in practice it means you can never ever use it in a company even if you really do not even want to change it or sell it or host it in isolation in any way.
That is really frustrating. Most internal licensing tools i have seen just literally blacklist any direct copyleft imports
Do you really mean copyleft, or do you mean the GPL family?
What about MPL and EUPL? I have heard the legal issues with GPL, never for MPL and EUPL.
As a a consequence there are a numbers of legal options on the matter and as a consequence to that, it is a very hard no from most compliance deps i have seen
When I try to make a business hosting copies of an http server, I am not pulling the rug out from under nginx who actually wrote the http server.
And when AWS does that better and than me, they are not pulling any rug out from under me, or at least not in any way that is special to any of the software involved, just plain old bigger businesses vs little businesses, no different than say Safelite vs Joe the Glass Guy.
Now you can say that this itself is already a misunderstanding and maybe you are right, but I think you forget also that software reality has changed and indeed there was a time when oss fulltime was viable.
Now the reality is that there is no business model other than closed source or oss with some inevitable rug pull of some sort.
And that is not what should be
Some people are wrong. It's easy to say that because it has always been true for everything in the world. This topic is no different.
If you want to suggest that you are not wrong, or that I am, you have to present an argument that holds water for that, not anything else.
No one owes anyone a business selling OSS, not even the author of said OSS. If you write something that you want to make money selling, then you are not interested in participating in OSS. That's it. Full stop.
Sell your software honestly.
"But I can't if it's not..." So what? Ok then don't sell it. It's no one else's problem that you have a misguided notion of why OSS exists and what it is good for and why one should spend any time or effort contributing to it.
All the other wailing and crying stems from bullshit you never had any right to in the first place. Not just legally or technically but morally and common-sensely.
Interestingly, when it's coming from TooBigTech, apparently they're happy to say "But we can't make viable LLMs if we don't abuse copyright" (yes, they said it). And apparently it works.
Not that I disagree with your point, though: nobody is owed a business selling OSS.
I don’t understand this take, if Google/AWS/Microsoft decide to host your service and some vulnerabilities are discovered then you got free Security Research done, your product would either have remained vulnerable or someone else would have filed the same bug.
You own the code so you can decide only certain people can commit PRs and can choose to close any feature requests issues.
If one of the cloud providers decided to use your product it’s because they deemed it reasonable as is or they can fork / contribute upstream.
That is what OSS is, by definition.
Hell you can post the code with a license like MIT and then never touch it again, and if someone else can monitise that code kudos to them.
If you are an existing company and open sourced your code, Facebook/react, then you presumably already make enough money to support development yourself or intend to stop development.
If you open source code that is your core business and somebody “steals your lunch” your learnt an important lesson and hopefully won’t make the same mistake twice. If you then decide to relicense and the community abandons you and causes uproar on the internet you are reaping the rewards of your actions, accept them.
However, I think OSS is a net positive to the industry, and would like to see it remain that way.
The classic way to monetize OSS has been to provide hosting and support for a price.
Now the internet giants are taking that entire pie for themselves.
If we agree that we want OSS to be a viable option going forward, and we agree that you need money to hire devs to maintain a successful large scale OSS project, then what do you suggest be done?
Therein lies our disagreement, you don’t need to. If you are amazon and upstream is willing to accept requests then amazon can hire devs, and if someone eats their cake then those devs will eventually migrate to the new location.
As someone who did the initial work for OSS I put the code out there, if I dislike the direction a fork is taking I can ignore said fork and keep working on my own version, why do I need to use the version they are using.
It boils down to why did you even start an OSS project, if the intention was to make money or hire other employees you fundamentally misunderstood the assignment.
If you made a project that serves your own need, decide someone else may benefit so you publish it as FOSS online and it gets massive traction how does that change your need, you probably have no reason to make it commercially viable, it is still serving the same need it always has for you.
Now if it gets forked and the fork proves to be of better quality and still serves your need then switch to the fork for your own personal need and now someone else is doing the maintenance, so you end up being the “freeloader”.
And I’ve already discussed the “burden on the maintainer”, if it’s such an issue close access to issues and pull requests. No more burden.
This goes back to my original point. You’re living in fantasy land.
In fact it's the other way around. Expecting to enjoy both the benefits of OSS and the benefits of collecting rent at the same time for the same thing is the fantasyland.
This of course means that you should never use permissive licensing since it doesn’t provide many key benefits of what people thought oss would do. You could use copyleft but i guess with llms it kinda amounts to the same
And if you use copyleft, nobody uses your product (or asks flr a commercial non FOSS license)
Any sort of proprietary product (be it fully closed source, source-available, or "open source with limitations") is always a risk. You were happily using database X, but they got acquired by Broadcom and now their product costs 100x what it was before. What do you do now?
That's why it is much safer to adopt open source - worst case is the company goes under, but you still keep using last released version indefinitely, and hope new entity (maybe even hyperscaler!) forks the code. Or make an in-house fork if you have enough resources.
"equitable source" license means it's not an option. That new product should really be much, much better than open-source alternatives to even be considered.
But it's not always the worst case, is it? If the licence is permissive, an hyperscaler can just take is and make a proprietary product out of it.
Hence copyleft licences without a CLA. Nobody could make Linux proprietary because the copyright is shared between so many people/companies.
Copyleft is always the best for the customer. Copyleft says "the customer has rights". Permissive says "do whatever you want, as long as you keep my name somewhere in the attributions".
The usual worst case for the supplier is that they give the product but don't get paid, and the usual worst case for the customer is that they give the money but don't get the product.
With copyleft specifically, the supplier is much more likely to not get paid, but the customer receives the benefit of being allowed to continue the maintenance of the software themselves if the supplier goes out of business. The supplier hopes this will help them acquire and keep customers, many of whom will pay, and keep them in business.
I understand what a supplier is. I don't understand how it relates to what I said.
> With copyleft specifically, the supplier is much more likely to not get paid
That doesn't make any sense. Whether the supplier open sources their code as permissive or copyleft doesn't have any impact on the likelihood of getting paid.
But if they distribute it as permissive, a competitor can just make a proprietary fork. Possibly continuously importing the new improvements from upstream and focusing on differentiating. Whereas if they distribute it as copyleft, a competitor has to share their changes, that upstream can benefit from.
So for the supplier, if that's how you want to call it, it's better to licence code as copyleft. Except if the whole idea is to be adopted by corporations, but in that case don't whine when they take your code and build a proprietary product without contributing anything back.
The original company went under, they no longer exist, so they obviously don't care.
The software user does not care either. OK, someone made a proprietary fork, and that "someone" is a hyperscaler... so what? The last released version is still out there and still can be used-as is / maintained by you / maintained by other 3rd party.
The new maintainers / fork authors should not care too. They base off the last released version, and their fork is not affected in any shape by what some hyperscalers do.
(I guess you can make an argument that proprietary fork might pull users/resources from the open-source one... but I don't think it's a big issue. If the users chose open-source version to begin with, why would they switch to proprietary fork?)
Open source succeeded because it created shared public infrastructure. But hyperscalers turned it into extraction infrastructure: mine the code, skip the stewardship.
The result? We’ve confused “open” with “free-for-the-powerful.”
It’s time to stop pretending licenses are enough. This is about incentives, governance, and resilience. The next generation of “open” has to bake in counterpower — or it’s just a feeding trough for monopolies.
https://lwn.net/Articles/1019686/#CommAnchor1019710
> Grafana's a great example of this. AWS and Azure _could_ have sold the unmodified AGPL Grafana as a service or published their modified versions, but instead, they both struck proprietary licensing and co-marketing agreements with Grafana Labs.
The phrasings stick out to me as super GPT-like.
A copyleft licence (not necessarily GPL, there is also MPL and EUPL) from the beginning on would result in (1), no need for a new license.
But people "don't want strings attached" and are happier with permissive licences, and then they complain.
But the reality is that current copyleft licenses means immediate blacklist by most companies legal department.
Which is why almost all cooyleft companies offer copyleft plus some corporate licensing even though in 99 percent of the cases it has nothing to do with the spirit of copyleft as companies just want to import and use the damn package in some completely unrelated internal project or whatever
The combination of unclear legal precedent and corporate governance means that copyleft in it’s current state exactly does not work as most people want
Because they always manage to find permissively-licenced alternatives! There are many different copyleft licences (not only the GPL family, take e.g. MPL or EUPL) that can be used and that are not "viral".
> The combination of unclear legal precedent and corporate governance means that copyleft in it’s current state exactly does not work as most people want
This is wrong. What it means is that corporate governance doesn't handle it correctly, because they don't need to.
If a project goes permissive because they want to please corporations, they shouldn't whine when they do. Otherwise they should just use a copyleft licence and teach the smaller companies that they can actually totally use that!
This isn't what is happening. A company called Garantia Data renamed themselves to Redis Labs and acquired the Redis trademark. They're not the original company, and they used a naming trick to present as if they are official (they are now, and nothing they did was illegal).
https://news.ycombinator.com/item?id=42256757
https://www.gomomento.com/blog/rip-redis-how-garantia-data-p...
Could you put a clause in the license that calls out those specific companies that you're concerned about and makes them pay, as well as any of their subsidiaries, a list that can be changed later?
That way, smaller businesses around the software can still exist, nobody gets concerned with the license too much because it calls out specific hyperscalers (no love lost on them in the community) and you still get them to pay their fair share.
Why do people try to ruin everything by SSPL that's overly restrictive and catches everyone else in the blast area, or try to write some clever license that would apply in all cases? Just call out the exact companies that are eating your lunch!
Hyperscaler Anti-Freeloading License (HAFL): If you belong to any of the following companies, or are a subsidiary of them, or operate any of the given cloud platforms and want to offer the service there, pay up: Amazon Web Services (Amazon), Google Cloud Platform (Google), Microsoft Azure (Microsoft), Alibaba Cloud (Alibaba Group), IBM Cloud (IBM), Oracle Cloud Infrastructure (Oracle), Tencent Cloud (Tencent), SAP Cloud Platform (SAP). This list can be changed at our discretion.No legal department will ever approve using software under a license like that. Who wants to risk being the next addition to that list?
In terms of antitrust, I believe that if you could prove that Amazon forked and offered the service with the intent to crush the competition, it would be downright illegal. A current case is Meta: back then, Zuckerberg was happily writing (internally) that Facebook needed to buy WhatsApp and Instagram and Snapchat to prevent them from ever competing. This is anti-competitive.
This post explains it well: https://pluralistic.net/2025/04/18/chatty-zucky/#is-you-taki...
They can only copy what they're explicitly legally allowed to.
Elastic explicitly allowed AWS to copy and use their source code, then whined about it.
As in, they can build an alternative to an open source project, offer it for free (i.e. at a loss) for years until they capture the market, and then start enshittifying. This is an antitrust problem.
> Elastic explicitly allowed AWS to copy and use their source code, then whined about it.
Yeah at the very least they should have started with a copyleft licence.
Open sourcing your product is a risky investment, and as with all risky investments, it might pay out, or it might not.
Still, there is an antitrust question (that is slightly orthogonal): if TooBigTech can offer a similar product at a loss (e.g. for free) until they capture the market, then that's a problem. And they can only do it because they are too big, and that is an antitrust issue IMO.
Can you elaborate on what exactly Amazon did to Elastic? I read all of their blog posts and the only thing I really got out of it was "they sell hosted Elastic cheaper than we can", which is hardly surprising given that Elastic really just packages up AWS/GCP/Azure cloud infra. That doesn't have to be AWS selling at a loss, AWS just doesn't need to pay itself.
And by all accounts I've read Amazon did contribute back to Elastic development up until Elastic switched the license on them. At that point they forked, but it's hard to blame them when they were deliberately locked out of the original project.
Most of the arguments I've seen against Amazon with regard to Elastic have tended to be very vibe-based. Amazon bullied Elastic because that's always what Amazon does! It's plausible, but it's also plausible that Elastic thought they could use Amazon's terrible reputation as a weapon against it without there being any substance.
Either the product is donated to a foundation, or the parent company dies.
While amazon technically wasn't doing anything "wrong", they're effectively squeezing the oxygen out of the ecosystem.
The parameters of the problem are relatively new. SAAS - which is now the norm for how software should be delivered, and opensource - which is old - just don't mix, the incentive structure is completely misaligned. Companies are prodding to see how to get out of this conundrum. Mongodb set the tone with the SSPL, and other midcap just kind of followed suit, what else was there to do, what other approaches could have been taken? Now, as the fallout starts to become clear, there's just a lot more information now on what works and doesn't, and companies are pivoting.
There's no vibes about it, it's brutal reality out there, big tech is strangling the market, and the small guys are figuring a way out, first trying one way, now another.
It is hard to get customers, especially businesses, to pay for something which is being given away for free.
Also from https://en.wikipedia.org/wiki/OpenSearch_(software):
> On September 16, 2024, the Linux Foundation and Amazon Web Services announced the creation of the OpenSearch Software Foundation.[15][16] Ownership of OpenSearch software was transferred from Amazon to OpenSearch Software Foundation, which is organized as an open technical project within the Linux Foundation.
OpenSearch is Apache License 2.0. You can do whatever you want to/with it. How are Elastic the good guys in your mind?
And they were using an open source piece of software, but scaling it with closed source secret sauce on top of that. The license was saying they'd have to open up their secret sauce or pay, and their response was to leave the table instead.
OpenSearch still lacks tons of really basic functionality from Elastisearch, and watching how far ahead Elasticsearch got as a product shows how much free lunch Amazon was getting... and how much they actually cared about the product when it was time for them to put their money where their mouth was (despite AWS pulling Elastic's yearly revenue every 4 days).
Elasticsearch has generally matured like it has a passionate builder with a vision. They pushed on two major fronts (LLMs and Observability) and managed to execute effectively without letting product quality slip.
Meanwhile OpenSearch is still the place where tickets requesting 3+ year old ES functionality go to die.
-
I'm honestly on the opposite side: how is the hyperscaler offering a strictly inferior product with closed extensions and still managing to eat the main developers' lunches for the sole reason they already have sales pipelines established not the bad guy?
I guess I'm not really someone who believes in infinite scaling rules: something that can work at the individual scale doesn't have to work when hyperscalers do it (like selling hosted clusters)
Irrelevant.
Elastic decided to release software to the public with a license that granted everyone under the sun the right to use it how they saw fit. This included also selling services.
That became a big part of their business model as it drove up it's adoption rates and popularity. If Elastic kept things like Elasticsearch proprietary, they would hardly have the same adoption rates.
You can't have it both ways. Why do you think people drop these projects the moment these corporations decide to pull the rug from under their userbase?
I believe that antitrust laws should prevent TooBigTech from being in that position in the first place.
The problem is not the open source licence, but rather the fact that TooBigTech can screw the competition whenever they feel like it.
Irrelevant. If you grant a right to everyone under the sun, you do not get to retroactively pull those rights from someone you decided to target.
When there are issues like this ("we made a successful product and someone forked it and it's killing us"), the "someone" is generally a BigTech, not 3 students in a garage. Then people complain about open source working/not working, and forget that the root problem is the monopoly that is screwing them.
AWS only gets to compete using their source code because they opened it in the first place. The competition was explicitly invited.
It's more fundamental that that. It's this idea that a corporation can arbitrarily change licensing terms already granted to end-users to extort them.
This is not limited to any managed service provided by a random cloud provider. The core reasoning is a corporation identifying end-users who are profiting from a service that directly or indirectly involves a project they release to the public under a FLOSS license. They see people getting paid, and retroactively change terms to coerce them into paying them. The same argument they throw at AWS providing a managed service also applies to any company using their project. How does this make any sense?
If contributors refused to sign CLAs, then corporations would either not get contributions or not be able to arbitrarily change the licence. It's also the contributor's fault if they contribute to a permissive project and give up their copyright. Is it extortion if they agreed to it?
And then those contributors come whining because the corporation does whatever they want. Too bad, don't sign a CLA. And don't contribute to permissively-licenced projects if you don't want your code to end in proprietary products.
Large companies using their dominant position to compete is not a feature of capitalism. Antitrust laws prevent that. It's just that the US ignores them.
> AWS only gets to compete using their source code because they opened it in the first place. The competition was explicitly invited.
This part I agree with: if you build a permissively-licenced project, you don't get to whine when competitors use it in their own proprietary alternatives.
No, it is irrelevant. Try to think about it for a second. You release a project under a license that grants everyone the right to use it as they see fit, including building a business on it. Everyone starts using the project as they see fit.
Do you believe you now have the right to retroactively pull the license on a whim?
No, you do not.
Yes, it is relevant.
Try to think about it for a second: multiple problems can exist in parallel:
1. Some company uses a permissive licence, sees a competitor making a proprietary product from their base, and starts whining. Too bad, they should have used a copyleft licence from the beginning on.
2. Some company makes a nice product. TooBigTech sees it and builds an alternative (be it a fork or from scratch, I don't care). TooBigTech offers it for free (because they can, because they are too big) and capture the market. The original smaller company dies, because they can't offer their product for free. Now TooBigTech can start enshittifying because they own the market, again.
> Do you believe you now have the right to retroactively pull the license on a whim?
If you own the copyright to the whole codebase, of course you can. All those contributors who signed a CLA and are now whining should think about that.
I don't think that word means what you think it means.
The original licensing decision was made well before the formation of Elastic the company. Maybe Shay didn't quite give it the full consideration. I don't know him super well, but like most developers starting open source projects, I don't think he has a legal background. I confess to a certain about of naivety, thinking that contributors would adhere to the spirit of contribution rather than the absolute letter of the license. I don't think it's unreasonable to have societal expectations above and beyond the legal requirements.
I've been doing open source for ~25 years and it appears to me there's been a distinct shift in how companies approach open source. I feel like what I started with was almost a eutopic ideal and now I'm expected to just do free support work for companies that don't want to pay anything to anyone. I don't see any problem with devs realizing their mistake or changing their mind and updating the license accordingly. For my part, I used to use ASLv2 for everything and now I default to AGPL.
> You can't have it both ways. Why do you think people drop these projects the moment these corporations decide to pull the rug from under their userbase?
Just like you have no legal obligations above what the license says, they have no legal obligations to make their work available under the license you want. It's open source, so feel free to take the commit from version before the license change. Of course, it turns out it's quite a bit messier to have two incompatible versions floating around, but as long as we're limiting ourselves to legal requirements that's a non-issue.
The most obvious reason these projects get dropped after a license change is because they now use a license that needs to be reviewed. It's a lot easier to justify spending on a new AWS service than it is getting a new license approved. But, that was more or less happening anyway. If you're already on AWS it's easier to add a new service than pay for hosting a service with a third party. I don't particularly fault Elastic for not wanting to be Amazon's R & D arm and support team.
We have a lot of systems and infrastructure in place that only mostly work because both parties hold up their own end of an unspoken agreement. Large tech companies have decided they can save money by breaking breaking away from that and just sticking to the letter of the license text. Legally, they have that right, but the other parties have predictably responded. I think what it really shows is our licenses don't fit all scenarios. Maybe I'm okay with individuals and companies with a market cap < $1T using the software under terms akin to open source but don't want to be a de facto employee for a large company reselling my software. We're well past the point of open source being about software freedom.
Most of these projects start off as a developer choosing a license without having the legal background to truly assess it and then they run into an 800 lbs. gorilla with loads of in-house counsel. Blaming them for not thinking it all the way through or realizing the implication of their license choice seems to me counter-productive. Okay, so they made a mistake. What now? They don't want to continue working under the framework where they feel being taken advantage of. I don't think they should be obligated to continue doing so because all of the non-Amazon folks don't want to incur the headache of forking. I'd love to see some of that ire aimed at the company willing to break the illusion to make some extra money than the folks that have freely given away their work for years.
Yes. Those are the terms the software has been distributed with from the inception.
No corporation has the right to pull those rights from end-users, no matter how profitable your shakedown scheme would be.
No, they do not. They can release new versions with some other license if they get all contributors to agree. They absolutely cannot pull the FLOSS licenses from existing releases.
Contributors must sign a Contributor License Agreement (CLA) before a contribution will be merged. The CLA signers gave Elastic the right to change licenses, among others, when they signed the agreement. Consequently, Elastic doesn't need to get individual sign-off from each contributor before changing the project license. The code wasn't based on copyleft license, so there's no compulsion to continue using the same licensing terms for all future distributions. That's a motivating factor for many CLAs. If you made a contribution prior to the introduction of the CLA then things get murkier.
I don't think elastic would've tried the license change because of competition using the open source.
The problem is Amazon, not elastic that's trying to survive.
What absurd, twisted logic. No, it does not affect open source. What are you talking about?
> The problem is Amazon, not elastic that's trying to survive.
No, the problem is Elastic trying to coerce end-users to pay them for using FLOSS projects. It makes absolutely no difference if AWS provides a managed service or if I run Elasticsearch in a AWS EC2 instance I pay for.
If a corporation wants to build a business model around FLOSS, it's their responsibility to figure out how to do that. What they cannot do is abuse FLOSS licenses to pull bait-and-switch on their userbase to coerce them to meet their revenue targets.
See what I did there?
Which ones, specifically?
You keep spamming this to anyone who replies to you: maybe your take is the irrelevant since it didn't stop them from pulling the rug in the first place?
> people drop these projects the moment
Noisy people always proclaim that they will, and hyperscalers gleefully market their forks... meanwhile it's mostly hyperscaler customers that they weren't going to get in the first place that actually move.
Elasticsearch was source available for 4 years and still saw massive growth.
People tried to spin Redis db-engine rankings dropping as being due to Valkey, but their trendline doesn't seem to have been affected at all by the change: https://db-engines.com/en/ranking_trend/system/Redis
-
But to be more direct, I'm honestly unimpressed with this brand of reductionism.
It's super easy to keep yelling IRRELEVANT THEY WERE RUNNING AN OPEN LIBRARY AND SHOULD HAVE EXPECTED SOMEONE TO SHOW UP WITH A HAULER TO TAKE ALL THE BOOKS, but it's not useful.
I'd also rather have a software ecosystem that uses targeted defenses to counter hyperscalers (which are more like an invasive species) than one that throws up its hands at them.
For anything that isn't Linux-scale, the alternative is that most of the well funded development ends up being from hyperscalers and that just concentrates their power.
Is this sarcasm?
: I don't know of any open source license ones that don't allow someone to sell hosted cluster. Even AGPL, which is copyleft, allows it; so long as the hosted version is either: the same as the open-source version, or it's version is also open-sourced.
If you want corporate adoption except AWS, you still cannot use AGPL.
I feel like there should be a license that doesn’t allow hyperscalers alone to fork without releasing source while being palatable to smaller companies
The problem here is that Amazon is in a position where they can fork and sell it for a loss in order to crush the competition.
That would be the point of antitrust, I guess? I mean if regulations were actually enforced.
This risk has always existed. It existed when they chose to open source it in the first place.
Time and time again we see the lesson being learned the hard way that "if your business value is your codebase, it's hard to build a business whilst literally giving it away".
perhaps then it comes as no surprise that some very outspoken open-source proponents do not open-source their core business components. I can understand they do it in order to exist as a company, as busineses, but I don't understand why they have to endure being shamed for staying closed-source, while all their stack is open. many such companies exist.
and let's add to this all the fact that everything released in 2025 as open-source gets slurped by LLMs for training. so, essentially, you feed bro's models breakfast with your open-source, like it or not. in the very near future we'll be able to perhaps prompt a 'retell' of Redis which is both the same software, but written so that it is not.
in essence there seems to be now little reason to open-source anything at all, and particularly if this is a core-business logic. open-source if you can outpace everybody else (with tech), or else you shouldn't care about the revenue.
I mostly see it as a problem for copyleft licences. Permissive don't protect the users in the first place, so...
Feels like we're pretty much screwed. Doesn't mean it's not a problem.
Unless there's a specific copyright claim over a specific piece of code that was copied and published, it's hard to see how the GPL has any relevance.
"My clipboard learned the code, just like a human would. So it should be fine to copy-paste anything and call it my own".
"How is killing a human any different to killing a computer?"
"If humans can vote, why couldn't computers vote as well?"
Can we start at "humans are not computers", maybe?
Sure. So it stands to reason that "computers" are not bound by human laws. So an LLM that finds a piece of copyright data out there on the internet, downloads it, and republishes it has not broken any law? It certainly can't be prosecuted.
My original point was that copyright protections are about (amongst other things) protecting distribution and derivative works rights. I'm not seeing a coherent argument that feeding a copyrighted work (that you obtained legally) into a machine is breaching anyone's copyright.
Are you even trying? A gun that kills a person has not broken any law? It certainly can't be prosecuted.
> I'm not seeing a coherent argument that feeding a copyrighted work (that you obtained legally) into a machine is breaching anyone's copyright.
So you don't see how having an automated blackbox that takes copyrighted material as an input and provides a competing alternative that can't be proven to come from the input goes against the idea of copyright protections?
Yeah dude…its an inanimate object.
Semantically, this is the same as a human reading all of Tom Clancy and then writing a fast-paced action/war/tension novel.
Is that in breach of copyright?
Copyright protects the expression of an idea. Not the idea.
Copyright laws were written before LLMs. Because a new technology can completely bypass the law doesn't mean that it is okay.
If I write a novel, I deserve credit for it and I deserve the right to sell it and to prevent somebody else from selling it in their name. If I was allowed to just copy any book and sell it, I could sell it for much cheaper because I didn't spend a year writing it. And the author would be screwed because people would buy my version (cheaper) and would possibly never even hear of the original author (say if my process of copying everything is good enough and I make a "Netflix of stolen books").
Now if I take the book, have it automatically translated by a program and sell it in my name, that's also illegal, right? Even though it may be harder to detect: say I translate a Spanish book to Mandarin, someone would need to realise that I "stole" the Spanish book. But we wouldn't want this to be legal, would we?
An LLM does that in a way that is much harder to detect. In the era of LLMs, if I write a technical blog, nobody will ever see it because they will get the information from the LLM that trained on my blog. If I open source code, nobody will ever see it if they can just ask their LLM to write an entire program that does the same thing. But chances are that the LLM couldn't have done it without having trained on my code. So the LLM is "stealing" my work.
You could say "the solution is to not open source anything", but that's not enough: art (movie, books, paintings, ...) fundamentally has to be shown and can therefore be trained on. LLMs bring us towards a point where open source, source available or proprietary, none of those concepts will matter: if you manage to train your LLM on that code (even proprietary code that was illegally leaked), you'll have essentially stolen it in a way that may be impossible to detect.
How in the world does it sound like it is a desirable future?
Why do you believe this is a problem? I mean, to believe that you first need to believe that having access to the source code is somehow a problem.
> I mostly see it as a problem for copyleft licences.
Nonsense.
At most, the problem lies in people ignoring what rights a FLOSS license grants to end users, and then feigning surprise when end users use their software just as the FLOSS license intended.
Also a telltale sign is the fact that these blind criticisms single out very precise corporations. Apparently they have absolutely no issue if any other cloud provider sells managed services. They single out AWS but completely ignore the fact that the organization behind ValKey includes the likes of Google, Ericsson, and even Oracle of all things. Somehow only AWS is the problem.
How in the world did you get there from what I said? Open source code has a licence that says what the copyright owner allows or not. LLMs are laundering machine in the sense that they allow anybody to just ignore licences and copyright in all code (even proprietary code: if you manage to train on the code of Windows without getting caught, you're good).
> At most, the problem lies in people ignoring what rights a FLOSS license grants to end users
Once it's been used to train an LLM, there is no right anymore. The licence, copyright, all that is worthless.
> Also a telltale sign is the fact that these blind criticisms [...]
No clue what you are talking about here.
No. Having access to the code does that. You only need a single determined engineer to do that. I mean, do you believe that until the inception of LLMs the world was completely unaware of the whole concept of reverse engineering stuff?
> Once it's been used to train an LLM, there is no right anymore.
Nonsense. You do not lose your rights to your work just because someone used a glorified template engine to write something similar. In fact, your whole blend of comment conveys a complete lack of experience using LLMs in coding applications, because all major assistant coding services do enforce copyright filters even when asking questions.
The scale makes all the difference! A single determined engineer, in their whole life, cannot remotely read all the code that goes into the training phase. How in the world can you believe it is the same thing?
> Nonsense. You do not lose your rights to your work just because [...]
It is only nonsense if you don't try to understand what I'm saying. What I am saying is that if it is impossible to prove that the LLM was trained with copyrighted material, then the copyright doesn't matter.
But maybe your single determined engineer can reverse engineer any trained LLM and extract the copyright code that was used in the training?
As such, code available is as much a boon to them as open source.
You need one agent that can write a complete specification of any piece of software, either just by using it and inferring how it works, or by reverse engineering if not prohibited by the license. You then have a lawyer in the middle (human or LLM) review it, removing any bits that are copyrighted. You then need another agent that can re-implement that spec. You just made a perfectly legal clone.
Cleanroom design is a well-established precedent in the US, and has been used before, just with teams of humans instead of LLMs.
I think some companies will be completely unaffected by this, as either the behavior of their code can't easily be infered just from API calls, or because their value actually lies in users / data / business relationships, not the code directly. Stripe would be my go-to example, you can't just reverse-engineer all their optimizations and antifraud models just by getting a developer API key and calling their API endpoints. They also have a lot of relationships with banks and other institutions, which are arguably just as important to their business as their code. Instagram, Uber or Amazon also fall into this bucket somewhat.
Doesn't mean it was not a problem.
This isn't complicated. It's trade secrets 101.
I'm being disingenuous though. Of course the bait-and-switch merchants know this, they're just banking on getting enough product momentum off the free labour of others before they cash in. That's the plan all along.
I choose to believe that both of these sub-communities of the larger FOSS community are principled in their beliefs. I don’t see whining from FreeBSD folks about competitors, or for-profit companies using all the permissions they give with their choice of license.
Sure! Then that's all good! I have nothing against the use of permissive licences (though I am on the copyleft camp too, obviously). Or put it in the public domain.
My problem is with those who do and then whine about it.
It especially bugs me when company blogs call out “abuse” when they only exist as a company because others gave them the permissions needed to build a business on software they did not author themselves!
The costing model does allow losses to be incurred in the initial years because building the thing is more expensive at first but then it should settle down and revenue should outpace expenses.
What can happen with these open source products being launched as a service is that that initial cost can be cut down by as much as 50-75% but rarely more than that because you still need to build all the surrounding infrastructure, documentation, UI. It still gives AWS an advantage by relying on an existing body of work they can start with where many problems have been thought through and solved. Also you will likely get a good product roadmap skeleton ready to be prioritized which otherwise can be a huge time sink.
In a nutshell, no. AWS won’t sell a service at a loss (there are exceptions of course) but there is room to incur a loss at the beginning but it is priced to eventually turn a profit. Whether that happens for every service in reality is a different story.
They can afford to maintain a better branch of Elastic Search or Redis or so on, an drive those companies out of business by the virtue of efficient free market competition. At which point they'll make sure their branch is only useful on their servers, perhaps by adding dependencies on all their internal microservices - so technically they released the code but you can only run it if you're Amazon.
Can you think of any examples where they've done that? They certainly could, but I can't think of any times they have actually rug-pulled like that, and the motive to do so seems tenuous too. In order for Amazon to do something like this they would need established market dominance, as well as a belief that some new player will hurt their market share enough to justify alienating the FOSS community.
What I wanted to say is that AWS using a permissively-licenced project is fine. The project should have thought about the licence beforehand and started with copyleft from the beginning on. Their problem now.
But a more general problem I see is that even if you use a copyleft license for your project, you have the risk to be crushed by anti-competitive behaviours coming from TooBigTech. It's not rare, they do that all the time and the US doesn't enforce anything. And when others (like the EU) try to do it, the US put pressure because they defend their US TooBigTech.
The latter is not a model or licencing issue, it's an antitrust issue. Now Amazon could compete with Redis without doing it illegaly, but they can only because they are so big. And the fact that they are so big is related to the lack of antitrust enforcement (it's documented, TooBigTech have all abused their dominance forever).
Everyone can fork any FLOSS project. That's by design. There are also no restrictions on random people selling services directly or indirectly using said FLOSS projects.
If a corporation changes their mind and decide it was a mistake for them to release software as FLOSS, they have the right to do what Redis just did. What they can't do is feign ignorance or do a bait-and-switch to try to coerce their userbase to cough up licensing fees for FLOSS projects.
But everyone is not in a position where they can put a ton of resources into a project in order to crush the competition and maintain their monopoly.
Which is why I said that the problem is the fact that Amazon is in this position, not the licence.
Selling at a loss isn’t bad. Selling at a loss to build marketshare or kill competition usually is.
The issue is that previous companies usually use this aspect to build marketshare, so there is no other way to compete. Other tactics include lobbying, patent bullying, etc.
Shoot, as bad as Uber is, just look at how taxis in major cities were formed.
Then look at labor laws in other countries.
Under the current legal/political structure for any modern country, there is no winning without exploitation, which is why I refuse to start my own business.
That's specious reasoning at best.
The whole point of FLOSS is that anyone is free to use it how they see fit. Whether it's a hobbyist doing a pet project or a FANG using it as their core infrastructure, they are granted the right to use it how they see fit.
That's exactly why they started to use it to begin with. Isn't it?
When a random corporation decides to pull the rug on the established user base expecting to profit from the pain of migrating existing services, it is not the user base who is the bad actor.
So if you are only saying it is their right, well, as per know CLA it is well within the oss companies right to change license for new version
You also knew this when you started using it. Why do you call it a rug pull now when you knew it could happen?
That’s the whole idea, is it not?
Previous versions are still available under the original license, right? So if you don't want to use it with a new license, you're in the same situation as if company went out of business or stopped support and development for any other reason. There are no safety mechanisms for that either.
If you do need constant updates, you may trust forks more not to switch license, but forks tend to disappear at about the same rate that originals switch license, so why does it matter? Such is the nature of relying on free stuff - you're at the mercy of the one who hands it out.
How does this work legally? You write some code, contribute it under a certain license... and... a company can just re-license your code under any license they like?
[0] https://redis.io/legal/redis-software-grant-and-contributor-...
CyanogenMod required a CLA to assign them copyright to Cyanogen Inc, only for them to basically kill the project. They forked it as LineageOS only to still require a CLA.
Don't contribute to projects with CLAs people without reading them carefully and understanding what can happen! Then you won't be surprised if a project is relicensed because you know you signed an agreement to let them do that.
Companies have to pay people to work on it. Hell, they are even entitled to profit from it. A world with commerically viable Open Source is way better than without it. Ditching OSS companies for trying to survive 90% of revenues going to $1T cloud vendors is counter productive.
Then there was talk of turning the project into an actual business, and myself and a few of the original contributers were offered extremely poor paying jobs. That no one took. Then they got a CEO, investors and we were basically forced out of the project unless we joined the company.
I distinctly remember being in a call where we were told they would be relicensing it eventually and launching a SaaS. To protect our work from being used by large companies. I laughed and pointed out the irony in that call that you were doing the same thing.
After that they changed their policy such they do not accept outside PR's. It has killed any interest in supporting open source projects outside personal stuff.
They ended up switching to a terrible model with a previous release where if you were a business or in anyway making money you now needed to pay for licenses and it was comically expensive.
The reality is I could have forked it but I don't have the time and patience to deal with everything that comes from a massive project.
I think we should celebrate this anyway. It's a smart decision, it's what the community wanted to happen and it would be great if other companies with janky licenses could see "Redis relicensed to open source and had a great boost out of it", not 'Redis relicensed to open source and it didn't help them at all".
I'm delighted. Thank you, team Redis.
So sure, let's celebrate, but celebrate the community, not those who tried to pull the rug out from under them.
When AWS and Co did provide hosting and provided it better than these guys could, now it's suddenly AWS who are the bad guys for using the FOSS software the way the license always said they could. Now we're suddenly supposed to ignore the terms on which FOSS has always been released and pick up our pitchforks against the big mean cloud provider.
Instead of sticking to the fundamental principles of FOSS (principles which they won business by openly espousing) and adapting their business to the fact that Elastic and Redis lost in the competition they knowingly set up, they fixated on hosting (on top of AWS and Co, no less!) as the business model and changed the licenses to give themselves a monopoly on it.
If the companies had made a bad call in structuring their business and owned up to it I think we'd be having a very different conversation than we are. We're here because they failed to own up to it and instead tried to get people to raise pitchforks against AWS. Never mind that their intended model was the obviously doomed model of reselling AWS's hosting with a commission on top, and never mind that it was the trade-off they chose when they chose to release their software as FOSS and get the boost in adoption that comes with.
I do fully agree with antirez above that we need a new plan for funding FOSS. But I think that's a poor justification for the rug pulling and vilifying that the existing companies did.
Open source companies with SaaS offerings need to have plans to differentiate themselves on hosting quality, not features. Yes, you can do better at hosting your own product than Amazon in many cases with customized, closed-source optimizations (that are unrelated to feature parity and does not intentionally limit the open-source/self-hosted form), support, etc.
That is true in a literal sense but (anecdotally) from the point of view of an engineer deploying ie; Redis, there is no real space for that angle of competition when the choice is between having to go through procurement hurdles to sign a contract with Redis Labs versus say; spinning up Redis on AWS which has zero hurdles because there is already an organization wide agreement in place for example.
The competition there isn't a level playing field as the deck is kind of stacked for most businesses where engineers don't have free reign to procurement what might be objectively the best hosting solution?
I've never really thought through this in any depth before now so don't consider this a great fleshed out argument, just an observation from my personal experience.
And that's not an appeal to authority: there just so genuinely and obviously is no such guarantee in enterprise that quality will ensure success that explaining it feels like trying to break down an elementary element.
"Impossible to compete" is hyperbolic (you can almost always compete), but from a business fundamentals perspective it is not a level playing field and odds of success in that arena are very very low. And as my sibling comment points out, this is massively compounded by the fact that (by their very nature), hyperscalers are also hosting other infra for you, whereas Redis Cloud is only going to be offering hosted Redis. So even if the DX/UX is much better for Redis Cloud, it is still an uphill battle to convince corpos and even SMEs to split up their hosting like that.
They will pay Microsoft and Amazon, not you, the author of the software to use your software.
That's not a fair representation of the objection. The thing under contention here is a behemoth freeloading for substantial profit. The reason it's viewed as bad is because that behavior undermines the community at large. Participants need to contribute back proportional to their benefit when realistically able lest the community decline over time.
It's conceptually similar to the disapproval employers with poor workplaces are subjected to. Even if they technically obey all the labor laws, by prioritizing their profits over worker health and well being they garner a bad reputation. "But we didn't do anything illegal" isn't going to get them out of it.
Why? No one has been able to articulate this for me. Why does Amazon using the software cause the community to decline? Doesn't it make the software more popular with broader reach?
When you give software away for free, you've given it away for free. You're producing it with the intention of it being used. Why does that suddenly become a problem when it gets used on a large scale?
It doesn't - at least directly.
> You're producing it with the intention of it being used. Why does that suddenly become a problem when it gets used on a large scale?
You're setting up a cause and effect here that I never put forward. It isn't the use itself that suddenly becomes problematic.
The behavior is the issue. If everyone else pitches in and you don't, you come out ahead. It's the game theory behind cooperative behavior. If only you abstain the community isn't necessarily worse off, but if everyone abstains then it is (ie compared to if they all contributed). The optimal outcome for the group as a whole is for everyone to pitch in.
I do get where you're coming from. Legally speaking it's quite silly for someone investing money not to proactively prevent this from the beginning.
This isn't about the legality though. It's about social responsibilities. Entities with more resources - individuals, corporations, and even governments - are generally held to higher standards in the public eye. The legal system alone is not sufficient to make society a nice place to live.
Cute. Can I have a check for my redis contributions now please?
Free Software won, as you ended up adopting the AGPL.
It’s an important distinction.
And every time someone talks about Open Source licensing, we'll remember how Redis was BSD and that became a shitshow so bad (everybody was fleeing to Valkey) they had to relicense it to AGPL (Free Software).
If this isn't losing...
If the other companies can't figure out that adopting a janky license and alienating the community is the self-inflicted problem, then they are beyond help. Relicensing to open source not helping the company may serve as a cautionary tale for other companies and may prevent them from repeating the same mistake. As an open source enthusiast, the worst case scenario is companies switching licenses tactically and frequently to test the waters and walking back with no consequences; I'd prefer the cost of such actions to be swift and severe.
Oh good. There is still hope of it returning to the original BSD license. ( I am still using good old Memcached )
> 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:
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
> Following our license change, in November of 2024 Salvatore Sanfillipo (antirez) decided to rejoin Redis as a developer evangelist. Collaborating with Salvatore on new capabilities, company strategy and community engagement has been a true privilege that has made a major impact that will pay dividends into the future.
If it's a true privilege, you should earn it by not misspelling his name. Actions speak louder than words.
Pink Floyd has a song about this:
Well, I've always had a deep respect and I mean that most sincere
The band is just fantastic, that is really what I think
Oh, by the way, which one's Pink?
And did we tell you the name of the game, boy?
We call it riding the gravy train
We're just knocked out, we heard about the sell-out
You gotta get an album out, you owe it to the people
We're so happy we can hardly count
Everybody else is just green, have you seen the chart?
It's a hell of a start, it could be made into a monster
If we all pull together as a team.
Edit: Regardless, thank you and the rest of the folks inside Redis for pushing to bring this back to OSS!
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/
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?
I have no idea what the actual stats are. But no, I don't find your "statistically 0%" to be self-evident, especially in light of the other comments and links in this thread, and what I've heard elsewhere.
I was hoping, since you presented it so confidently, that you had something more than "trust me". In another comment you say you have evidence of marketshare, maybe you could post that?
>My 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...
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
https://trends.shodan.io/search?query=valkey_version+port%3A...
Here's a chart of all Redis-compatible services (~55,000):
https://trends.shodan.io/search?query=port%3A6379+redis_vers...
What evidence did you find?
This is Open Source working well.
Unfortunately, the reverse flow does not work.
Did they maintain the author's copyright notice as required by BSD-3?
It was pretty easy, a small config change and some performance testing to make sure it worked well at scale.
Maybe nobody is talking about it online but some people have definitely switched.
Between that and the licensing, I would never consider dealing with them.
Not to say it’s not an important discussion!
Several major linux distros transparently switched to Valkey and the users are none-the-wiser. On Fedora, for example, doing `sudo dnf install redis` just installs Valkey.
It is much worse for my package manager to install a totally different software, than for my package manager to install a new version of the software I asked for that now has a different license. Also as an aside, SSPL is not closed-source.
If the distro wants to do something, they can throw a warning up saying "this package is now licensed with the SSPL, would you still like to install? Try installing valkey for a BSD-licensed alternative". But installing software I didn't ask for is bad, actually.
No, you don't just randomly have a different package installed one day, at least on major distros. The next distro release will include the new package. If for any reason you care, you can always go install the other one you want instead as well, it just won't be part of the default package repos.
Generally, the replacement packages are 1:1 with the one they are replacing, and/or compatibility shims are included during the install. Its seamless. Also, generally the package manager does tell you what it's installing.
The major Linux distros are very careful about this stuff. The two largest have huge enterprise user bases, and it's never been a problem.
Many of the Linux distros are extremely opinionated on what goes into their default package repositories - it's a major reason why you choose certain distros. You are delegating all of this concern about packages, compatibility, bug/security fixes, and licenses and whatever to the maintainers of the distro. They are very careful not to break existing systems, and aren't going to surprise you one day with a major disruptive change. For them to replace Redis, for instance, with Valkey, it's going to be on the next major os release, it'll be a drop in replacement (all Redis commands continue to work, etc), and you'll have an opportunity to see this change while installing packages. This isn't "shoot from the hip" npm style stuff...
Except it's a fork, so it is what you asked for. The name changed, sure, and there's a different governance arrangement. But pretty much the entire point of using a distro is offloading decisions such as which developers and repositories to trust onto the maintainers.
If you want to make those decisions for yourself then you should obviously be cloning and building from source. I'm not just saying that - I myself do exactly that in cases where it matters to me.
If you don't care about license purity then perhaps don't use a distro that explicitly filters on that?
It's also not a free and open source software license. This is disqualifies software using it from being in the main repos for various distros.
Seems like some sort of user prompting could be acceptable, though.
Second, I don't know about you, but continuing to function in the same way is my primary need for systems I am managing. When my provisioning system installs a package by name, i expect it to work in the same way as before. Switching binary names breaks that promise.
My setup has scripts that do things like check that a process named "redis" is running... this will break if the process is now called "valkey"
I feel like all the commenters live in some kind of crazy alternate world where purity of license matters more than stability of systems.
But where do you put the blame?
The distro for making that change, or the redis company for breaking your software stack?
For me and my company, though, it just doesn't matter. We don't use redis in a way that would ever come into conflict with the license, so it really doesn't affect me. Redis didn't break my software stack with the license change. I am sorry, but I just can't get up the energy to care that much about which license they choose. If it helps them make money, fine go for it. I can't root that hard for the side Amazon is on.
Using a distro that handles things your way is your privilege. I assume most people who install packages care about the functionality they provide, not the brand name - so it seems like a fair default for distros that aim to appeal to broad user bases imo.
This is an amusing example of "the duality of man," having just finished reading a bunch of comments to the effect of "the user should have the ultimate say as to what apps they can install from the App Store" in the Apple thread.
I use a distro because I don't have the time or energy to do all of that for myself. It's a purely voluntary arrangement unlike the iOS/Android duopoly that modern society is increasingly built on top of.
Also, what happens if functionality drifts?
You're thinking of it as if upstream is primary. Actually, when you use a distribution package, the distribution has the final say over the contents of the package.
1: https://github.com/redis/redis/commit/0b34396924eca4edc52446...
Redis user since it appeared and I switched my servers (~15) to Valkey - partially because of the shenanigans, partially because Arch is moving Redis to archive.
Redis is a threat to the compagny and the licence change was taken very seriously, as all legal-related threat.
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.
Sounds like a huge disadvantage in your company’s choice of software architecture to me.
The pro being that every service is an island that can be independently updated and managed when needs be. Scaling is also somewhat nicer as you only need to scale the services under heavy load rather than larger services.
It also makes for better separation of systems. The foo system gets a foo database and when both are under load we only have to discuss increasing hardware for the foo system/database and not the everything database.
The cons are that it's more complex and consistency is nearly impossible (though we are mostly consistent). It also means that if we need a system wide replacement of a service like redis, you have to visit our 100+ services to see who depends on it. That rarely comes up as most companies don't do what redis did.
Sometimes large companies acquire smaller companies and keep the lights on in the old system for a while. They may not even use a similar tech stack!
Sometimes they want to cleanly incorporate the acquired systems into the existing architecture but that might take years of development time.
Sometimes having a distributed system can be beneficial. Pros / cons.
and sometimes it’s just a big company with many people working in parallel, where it’s hard to deploy everything as a single web app in a single pipeline.
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.
After that, it is just updating version numbers. Lawyers don't sign off on version upgrades, why would I bring this to them?
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.
>This achieved our goal—AWS and Google now maintain their own fork
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?
But the person you replied to was talking about Redis's goal, and I don't think it's likely their goal had anything to do with having a competitor to themselves around. Even if they did want that, they could've just bankrolled (or engineered) a fork; changing a license to one that causes your largest users to do the work themselves is a rather roundabout way to do it.
I can almost kind of see the large users needing to work together on a replacement, meaning that replacement might as well be open-source, meaning Redis can get future improvements that were funded by the fork users (who Redis was upset wasn't paying them) as a semi-vindictive, semi-useful goal. But it's still roundabout. If that was really the plan, it could've been articulated better in this postmortem to make it clear the "goal" bit hadn't just been BS'd.
I've seen workloads perform better without caching at all at 30ms
Presumably some of the things being worked on in Valkey, etc can be upstreamed back to Redis in some form (not entirely straightforward since it is a hard fork with a diff license, but concepts can be borrowed back too).
e.g. apparently Valkey has introduced some performance improvements. Redis can implement similar if it seems worthwhile. Without the fork those performance ideas might have never surfaced.
That is not true. Companies like AWS had paid staff working as OSS Redis core maintainers before the licencing schism. This talk of "achieving their goals" is just bluster serving no reason other than damage control.
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.
Why not? Is it because only one company can make proprietary fork?
Would you rather contribute to MIT software where everyone can make proprietary fork? Or AGPL without CLA where nobody can make proprietary fork?
In my case that is it.
I'm totally fine with people taking my MIT licensed code in a MIT licensed project and running with it.
However, working for free on someone elses code base knowing that they can always go commercial with it or do whatever they want while I and the rest of the community is stuck with AGPL, that is something I'd rather avoid, if possible.
Depending of the motivation for your contribution, you get what you want, eg, the feeling of contributing to an open source project presumably used by many people, or having that entity to maintain your patch "for free".
You can keep your change in a fork if you like, but the likelihood that your fork is getting used is not that big, and mean more work from your side to rebase the change.
"I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer."
I'm glad Antirez was seeing his art losing it's beauty and now, is reclaiming it!
That was the very moment Redis®* died for me—I’ve never encountered a tech company that was so aloof about how tech works.
Hopefully that damage is undone.
—
*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.
It's not black and white. They'll get some trust back at least.
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: https://news.ycombinator.com/item?id=41394797
Yeah, that future had come, and Redis is free again!
Thanks antirez and to all the team behind Redis.
_________________
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 don't understand why so many people think that it's impossible to have open source in your heart while working for a big company in your day job.
Because a big company like Amazon has produced almost no open source work(yes some random collection of repos and 2 PRs here and there is not the same thing) compared to how much it has benefited from open source. (I know I know OSS allows for all that so not claiming anything wrong). But it does show what the company policy must be towards open source (Consume all you can, contribute only when absolutely essential for the company barring exceptional circumstances).
> I don't understand why people who have dedicated a lot of their time and emotional energy to keep open source ways alive and help build a community effort are attacked because they work for a company that needs to be made the villain in the narrative.
Antirez is not attacking anyone above. English is not his first language and he is just putting out some of his thoughts (which people are free to disagree with but those are what he thinks), like how you casually slipped that you didn't get credit for one commit copied from valkey (where the copier is giving due credit in the PR by linking the source PR and the authors inline). So they copied a PR from valkey, and the redis blog post should give lots and lots of credits? If that was the standard, so many of AWS services will spend all their reinvent time giving credits to their source OSS projects.
This may have been true a decade ago, but things are quite different now.
> compared to how much it has benefited from open source.
This is the nature of digital public goods. We are all going to disproportionately benefit from digital public goods relative to what can be produced as new digital public goods. No one will ever, EVER be able to "contribute proportionately" given the endless bounty of software made freely available for all to use.
> If that was the standard, so many of AWS services will spend all their reinvent time giving credits to their source OSS projects.
The observant should notice a change in this over the years. For example, the announcement for Amazon Q Code Transformation [1] acknowledged that OpenRewrite was used under the covers, even though it was an implementation detail that didn't have to be disclosed...
Of course these disclosures and good-faith intentions to engage on open-source community terms under long-established community norms don't always work out the way we hope. [2]
[1] https://aws.amazon.com/blogs/aws/upgrade-your-java-applicati...
[2] https://github.com/spring-projects/spring-tools/issues/1443
so it sounds like we need a license mechanism that enforces this, fairly, based on potential ability to contribute
idea: a benchmark to give a required level of contributions, maybe a logistic function of revenue generated/company size and time since initial usage
and if you fall beneath it, your license is terminated
carefully calibrated such that a burden is only placed on very large companies
There are plenty of licenses around, lack of alternatives isn't why people use MIT or Apache.
The employment contract you signed.
There are many actions and behaviours in life that are not illegal but actively worsen society at large if you do them. That companies that are the main contributors to OSS are forced to take drastic measures is just consequence of AWS not being a team player, you should have at least the decency of not commenting here.
PS. I don't have a horse in the race, I'm not a Redis user, I'm just appalled by your behavior.
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.
Sounds like SSPL did not yield the desired outcome.
Glad AGPL is an option now.
But I doubt that was the outcome that they hoped for. They created a large and successful competitor that by nature of being a fork does exactly the same thing. It's pretty hard to compete with yourself and the differentiate from your own product.
Honestly, I think Redis Inc. was better off when there was just one code base. AGPL just marginalizes them further. It's not an acceptable license for many corporate legal departments. So, it would necessitate buying a commercial license for such companies. I.e. Fortune 500 companies, public companies, and pretty much anything with a legal department worthy of the name. Note how Redis advertises AGPLv3 as "one" of the available licenses. The whole point of that license is selling commercial licenses.
Valkey is at this point stable and supported and a drop in replacement. It's pretty much the default choice for anyone not interested in buying a commercial license. That genie isn't going back in the bottle with this license choice.
More importantly, Valkey is a pretty active Github project with dozens of contributors in the last month. More than double those in Redis. Those commits aren't going to Redis. And Redis still requires the right to re-license your commits if you try to contribute. That's how they were able to pull this stunt to begin with. I doubt a lot of the Valkey contributors will be moving back to that status quo.
- https://news.ycombinator.com/item?id=43829008
- https://github.com/cncf/toc/issues/1632
- https://github.com/nats-io/nats-server/issues/6832
I also built a lot on NATS Jetstream, and I'm questioning my decision in light of the threatened license change.
You said "I also built a lot" Are you making money off those projects or get paid for your services for that use?
[^1]: https://github.com/minio/minio/issues/13308#issuecomment-929...
I'm no lawyer, but unless the software in question makes an exception for the particular API, I wouldn't feel confident.
Or what is the distinction here?
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...
Making changes is fine too, so long as those changes are also distributed. "The source come with the binaries" is the general rule. You don't even have to open your whole stack (that is FUD), only the parts under the AGPL that you changed and only when you distribute it. Companies can and always have used these projects internally without risk.
1. To monetize a project, it must first gain wide adoption.
2. To gain wide adoption, it must have a permissive license.
3. To successfully monetize (after gaining wide adoption), it must have a restrictive license.
4. Changing a project's license to be more restrictive will alienate the community and hurt adoption.
I see no solution to this dilemma.
s/can't/choose not to/
s/'re forced to//Edit: Doubled checked with gpt, no cases of “infection” yet, there has also been many talks about this license being very good
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.
It matters a lot. A company could potentially make choice that saves them a lot of money, so they better base their decisions on accurate information rather than rumours.
(Note also that big tech have different incentives)
The more aggressive a license you pick, the more likely a corporation won't want to use it. But that's by design. They're allowed to use it, even commercially - they just have to give the source code back. If the software is useful enough, they will. We should make software useful enough for corporations to consider the be benefits of using it to outweigh the cost of having to share their source code. (Also the more source you make them share, the less likely this is. The Linux kernel succeeded at this.
SSPL is controversial and untested (and goes against the business interests of the OSI so will never be box-tick certified compliant) and likely counterproductive if it means you have to share things like Windows. AGPL is the normal "aggressively free" license. GPL is mostly for those who haven't discovered AGPL yet and MIT is for those who don't agree in the goal of source code freedom to begin with.
And notice the OSI's objection actually makes no sense and could apply to any copyleft license! By the same reasoning, AGPL isn't open source. Yet they say it is.
That's not quite true. Per https://en.wikipedia.org/wiki/Server_Side_Public_License , Debian did explicitly reject it (in addition to listing OSI and Red Hat likewise), citing https://web.archive.org/web/20240226231216/https://bugs.debi... -
However, the SSPL is clearly not in the sprit of the DFSG, yet alone
complimentary to the Debian's goals of promoting software or user
freedom.
In light of this, the Project does not consider that software licensed
under the SSPL to be suitable for inclusion in the Debian archive.what? why would you ask an LLM to generate some random text instead of looking up the actual answer?
Edit: Oops, typoed the license names.
This is factually untrue. If you want to link an AGPL blob into your app and ship it to customers, sure. In the vastly more common case where you're using a permissive client library[0] to connect to an AGPL server, there's no risk whatsoever.
At most, you might need to make your local changes to that server available to clients if they connect to it directly, as opposed to hosting a cloud SaaS setup where everything is internal to you. However, that's not the worst thing in the world. "Oh no, we improved a Free server our company depends on, and we have to share those improvements so that the person who gave us the server for free can also benefit from them" is pretty hard for me to sympathize with.
This is vastly more business-friendly than the non-FOSS SSPL.
[0]https://github.com/redis-rb/redis-client/blob/master/LICENSE...
Yeah, this is BS.
If you simply use AGPL software, it doesn't "infect" anything. If you *change* the AGPL software, you have to release the changes. It forces the big clouds to open source their Redis improvements.
Most of the readers of HN make their living from closed source software. You know well enough that non-hostile open source is just a market entry strategy and the type of copyright-driven maximally selfish capitalist markets just force open source to be not viable for a single company to thrive. Projects like Linux kernel are exceptional infrastructure projects that external companies support not build businesses just to ship.
This is completely, factually, unequivocally, incorrect.
You can connect to Redis using their first-party, MIT-licensed client library. You can write proprietary software using that library with no requirement whatsoever to release your software under any particular license (although of course you still have to comply with the MIT license's attribution requirements).
If all software connecting to the AGPL'd service runs internally, you're not obligated to share your local changes to that service. This covers the vast majority of use cases. Using WordPress with a Redis cache? This doesn't affect you.
If you host an AGPL'd version of a Redis server and your customers connect to it from their own networks, then the only obligation you have over the tried-and-true GPL is that you have to share changes you've made to your Redis server with users. If you use Redis packages as-is like almost everyone does, this doesn't affect you.
So literally the only people who have to care about Redis being under the AGPL now are those who don't want to pay Redis for a commercial license, who expose their Redis server to customers, and who've made local changes to their Redis server. Everyone else gets to keep using it like they always had.
Stop lying. This is FUD. It must be disregarded with extreme prejudice. The AGPL must remain free, and anyone interacting with it over the network must receive the opportunity to obtain the original or modified versions of the AGPL'd software and that's it. Nobody said anything about opening up the entire network stack. That is SSPL territory.
This is a lie. It's FUD. And it should be disregarded with extreme prejudice. Stop it.
First and foremost, AGPL'd software must remain free. They could use it in their stack. The rule is they must point to the sources of the AGPL'd software. If they make a change to the AGPL'd software and users interact with that (even over a network) then they must disclose the changes to the AGPL'd software. That's it. They don't have to open their whole stack. That's SSPL, so stop spreading this FUD.
Second, it's not their IP. They didn't write the AGPL'd software. They must abide by its terms.
Third, even if they chose (emphasize on "chose" and not "forced") to use AGPL'd software, they could simply disclose the changes they made to it. There is little to no excuse not to. The fact is that if the software meets their needs, they have little reason not to. The AGPL exists to protect Software Freedom so if they find that objectionable it can only be concluded that they intend to harm Free Software.
Valkey.
/s in case I haven't piled it on thick enough to make an impact.
Read the last link of TFA [0], the last time this came up [1] (noting the timespan), and extrapolate as necessary.
0: https://redis.io/blog/agplv3/ (CEO)
1: https://redis.io/blog/redis-license-bsd-will-remain-bsd/ (CTO)
Or don't, I don't care. Point/fix has been made.
Except... the CEO forgot. Here's a lesson about AGPL and the Big Bad Cloud. Give me a break or I'll take one.
At risk of confusing things further: YouTube is leaking, is kind of my point. Apologies again for not exhaustively phrasing my criticism. s/ging CEOs/gers/; better?
One last try: I'm happy for the evangelism, I'm less happy about the repeat license discussion. The blogs from all of the employees add a frustrating element. It's a trend now spanning businesses.
With what Mullenweg did, another conveniently forgetful CEO, I'm (admittedly, excessively) cynical.
How you thought I was saying antirez is the CEO is utterly baffling. I have a hard time thinking this is genuine, but rather, a troll. Entirely non-sequitur/failure of compound reasoning.
~ $ curl -s 'https://news.ycombinator.com/user?id=fastball'
[...]
I used to argue on the internet too much.<p>Co-founder and tinkerer at supernotes.app
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?
Probably why many companies find AGPL toxic.
I wish it were common for projects to explain in common language how they expect the license to work, with examples of how it applies to their project.
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.
However, I do not want any hyperscalers to fork and close source the project. I want sny benefit to continue to be available.
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.
With permissive licensing it seems a rug pull is inevitable to be able to do it full time.
What to do?
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.
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 ?
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 ?
Does it make sense ?
- 7.4 - Dual licensed under RSALv2/SSPLv1
- 7.2 and earlier - 3BSD
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...
Stop lying. This is FUD. It must be disregarded with extreme prejudice. It is completely, factually, unequivocally, incorrect.
You can connect to Redis using their first-party, MIT-licensed client library. You can write proprietary software using that library with no requirement whatsoever to release your software under any particular license (although of course you still have to comply with the MIT license's attribution requirements). Heck, you can even serve this software to your users. The only condition being that you you distribute the original source or your modified changes of the AGPL'd part of the software in your stack to your users under the terms of the AGPL license. Nobody said you have to open up your whole stack. That's SSPL territory.
They went to SSPL, which isn't open source. (Whether it's copyleft is an interesting exercise left to the reader. I genuinely don't know, I'd have to stare at definitions for a bit to form an opinion.)
> 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.
Er, I'm not a lawyer, but why wouldn't you be able to use it in a private work? AFAIK the viral parts of AGPL/GPL only say you have to share source with users of the software; if your only user is you then it's immaterial.
> Isn’t AGPL even WORSE than what they switched from? Wouldn’t “open source again” imply going back to BSD?
Worse/better is somewhat subjective, but AGPL is a (Free and) Open Source license. It was open source (BSD), then it wasn't (SSPL), then it was open source (AGPL).
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...
It’s a good trade-off though. Grafana does the same and they’re doing just fine.
I hope redis gets to live a long life now that’s more open than ever (essentially it’s free software now) :)
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.
Can't say that I feel sorry for them though.
[1] I am assuming this because valkey comes under the Linux Foundation umbrella.
"Inebriated aliens might as well have beamed it down from space as a kind of practical joke..."
"It’s not just hard for lawyers, who have the legal picture and can parse the whole license very carefully without passing out...It’s also hard for hackers, even those familiar with free software lore, who lack the legal side of the picture and a sense of what other ways things might have been said. Imagine how people who don’t know software, law, legal drafting, software architecture, hacker culture, or the self-styled 'philosophical' musings of one Richard M. Stallman feel."
https://writing.kemitchell.com/2021/01/24/Reading-AGPL
As Mitchell implies folks who want network copyleft should look into the more straightforward OSL3, IMO.
But it's something, and it's not my call to make because I didn't write the code, so properly I can only be grateful.
I'm bad at licenses, and I admit I don't completely get it. At first glance, it seems like a simpler more readable license that tries to accomplish something similar to AGPL. I think the "license terminates when you sue me for patent infringement" clause is nifty.
But it says that an "external deployment" counts as "distribution" (ok, fair), which means you must OSL-license your changes too (ok, fair too).
But how does that in practice prevent AWS and GCP from cloud-hosting your software without giving back? Seems to me that if Redis went OSL3, GCP could host it fine so long as they'd OSL3-distribute any changes they made.
it doesn't. but neither does the AGPL. the only reason companies avoid the AGPL is because the AGPL stipulates that anything that the software is integrated with must be distributed as well. they are avoiding the GPL for the same reason. i don't know if the OSL does that too. if it doesn't then it would be less protective than the AGPL.
the AGPL works to prevent competition because companies are scared of it, but that was not its intention. none of the GPL licenses are intended to prevent competition without giving back.
and that is the real problem that redis and other companies are facing: how can we share source with our users without allowing well funded competitors to eat our lunch.
there are several experimental licenses that are trying to address that problem, among others, FUTO is working on that, as is bruce perens. but so far no clear choice has emerged. and unfortunately many see the idea of limiting competition as against the spirit of FOSS. personally, i think that needs to change.
What is your definition of “giving back?” To me that means open sourcing your changes, which as you note is what the license requires.
I was merely saying OSL is better than agpl as a license (imo). It’s very clear. But lack of clarity can have strategic value.
if you are fussing about the details which code you need to share and which not then you are not following the spirit of Free Software. it's as simple as that.
also, consider that the AGPL is trying to be compatible to the GPL. that forces it to be more complicated. the OSL doesn't have that problem, and the OSL is also not compatible with the GPL, which is only ok if you don't want to integrate any other GPL software. although i suppose since the GPL doesn't require distribution on network access, this may not be an issue. but i don't know, i am not a lawyer. and so to be sure, i'll prefer the AGPL.
Kyle’s point is pretty clear: it’s really hard to tell what agpl actually requires. So it’s a bad, unclear license whatever your position is - whether you think your code should virally make everything that links it open source, or if you expressly don’t want that and only want the library itself network copyleft. What does agpl actually require? Even lawyers are stumped.
one could argue that a complicated license reduces the attraction of my software, but again, if i am not out to become popular, i would not care about that. and for my paying customers they should not care either, because they are still getting more than they would from proprietary software, or they are paying me to get an exception.
so if the license for my software is to complicated for you, tough luck. it's not my job to accommodate that.
That’s only true if you also don’t care what other people are required to do with your code. People who want copyleft enforced for their contributions will care if the license actually enforces it, and how.
> if the license for my software is to complicated for you, tough luck
Sure, fine. My whole point in the last comment is that it’s complicated for the /creator/. Wasn’t talking about the user. A badly written license cuts both ways.
and the difficulty to enforce i already addressed in my first comment: if you have to defend the license against an abuser then the AGPL is challenging. so i do accept that.
Has there been a consensus on one? Is there a winner?
I love redis and will probably keep using it. Just curious.
There are the commit histories, the GitHub contribution graphs. Everything is public. The current code base was written for the majority by a few single folks, for another small amount of the sum of all random people in the community, for a smaller part by people that now work at ValKey.
> It is also hard to reconcile the claims that cloud providers do not contribute with the actual commits to the Redis repository. A quick examination of the commits since the 7.0.0 release using gitdm shows 967 commits over that time period:
Top changeset contributions by employer
(Unknown) 331 34.2%
Tencent 240 24.8%
Redis 189 19.5%
Alibaba 65 6.7%
Huawei 50 5.2%
Amazon.com 50 5.2%
Bytedance 19 2.0%
NetEase 13 1.3%
This is likely some partial data of some specific fork or alike.
As is typical for software projects, early authors will be disproportionately represented in revision histories. I am still the #4 contributor to the Anaconda installer [1] originally used by Red Hat Linux, then RHEL, then Fedora, and others, despite not contributing to the code base for two decades.
[1] https://github.com/rhinstaller/anaconda/graphs/contributors
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.
So either they relicense, or they can't take code from Redis but Redis can take code from Valkey.
However, if the intention was the other way (to allow valkey to take code from redis), valkey should just go for AGPL as well, there is little reason to pick GPL if the code sharing would be the motivation for the license change.
In theory, one would not be able to offer a combined program under other licenses (in particular, RSALv2 and SSPLv1), as those licenses have conflicts with GPL obligations.
Direct contributions to the Redis project avoid this issue via a separate Contributor License Agreement. It would only mean that Redis developers could not unilaterally copy code from Valkey.
I'm not saying that the Valkey community should do this. Personally, I think it's better off as a BSD-3 licensed project, with the community fulfilling the promise made by others that it would always be that way.
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.
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.
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.
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.
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.
AGPL is pretty much a non-starter for any commercial development.
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.
So, before everyone but amazon could use it for commercial purposes, now no one can.
2) you only have to share what you change. You don’t have to change it to provide it as a service, but if you do, you have to share the code. That doesn’t seem particularly harsh and certainly doesn’t prevent providing it commercially.
But more important, AGPL software is banned at many large corporations. It's simply not an option.
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
Personally, I think it is better just to call a spade a spade and release things with commercial licenses. Let all companies with < 1T market cap use your stuff for free. Companies that are making money will want a managed service or support anyway. Companies that want to host your stuff in their environment fall into the > $1T category.
The above is a bit of a strawman but what we really want is for valuable projects to continue to exist.
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.
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.
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.
My impression is that:
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.
2. People prioritize their own short-term interests too much.
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.
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.
I don't see any exploitation happening. As DHH said, the main reason engineers open source their work is to give a gift to the world.
Open source and free software licenses are basically the same (there are a few exceptions). For me, the difference is the focus. Free software cares about user freedom first.
This sentence does a shortcut that's worth expanding on, because it can give the impression that permissive licenses don't respect user rights, and because it doesn't cleanly apply to every situations.
User freedom is full with a permissive license. If I get software under MIT, my freedom is fully respected.
But it is true that forcing downstream developers to respect the freedom of their users through copyleft licenses is one of the strategies to improve user freedom overall (Personally, that's why I prefer the (A)GPL - I'm not keen on helping).
There still are some situations where you might be better off using a more permissive license, when your code is small enough or would strongly benefit from the network effect, for instance if it's a codec, or if there already are alternatives that proprietary software can use [1,2].
[1] https://www.gnu.org/licenses/license-recommendations.html
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...
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 wrote more about the issue here: https://keygen.sh/blog/whither-open-source/
The fact that the FSF wants a EULA but can’t have a EULA without violating Freedom 0 doesn’t make the AGPL suddenly logically sound.
marcan has written about it in more detail than I care to: https://news.ycombinator.com/item?id=30044019
Stop using the AGPL. It violates the basic principles of free software.
The ability to run a SaaS company with free software is a feature, not a bug.
What do you think is nonfree about AGPL?
The AGPL, in its quest to be a EULA, violates free software Freedom 0 ("The freedom to run the program as you wish, for any purpose").
https://www.gnu.org/philosophy/free-sw.en.html
The AGPL literally demands specific functionality be present in the software that cannot be removed without breaking the license. The anticapitalist FSF zealots got so in love with the idea of closing what they call "the ASP loophole" that they wrote themselves a EULA.
I can do this with AGPL software just fine. Which purposes are not allowed under AGPL?
I suggest that you read the actual text of the AGPL. It's madness. They wanted a EULA so badly.
That's not true. You only need to provide the modified source code somewhere.
You might want to read it again :-) It seems like you have a wrong idea of what the AGPL does.
edit: I see an immediate downvote. If whoever did this thinks I'm wrong, please share the exact AGPL excerpt that mandates actually building a feature to provide the source code currently in use in the network program itself.
> if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source
The application does not have to directly provide its own exact source code, but it must advertise where to find it.
And it's quite unclear what exactly counts here. For a web application it's somewhat obvious how one might do that (although how many AGPL applications are prepared for it as a simple config option vs require you to do additional patching to add it), but for other applications its not.
E.g. you interact with redis over a custom protocol thats self-described as being human-readable. Does that mean I need to inject the offer there somewhere? What if it is a much more opaque protocol? If you ask 5 lawyers, how many opinions on that do you get?
Put it on your website if redis does not support HTTP. The license clearly covers this.
The GNU Affero General Public License (GNU AGPL) is a free, copyleft license published by the Free Software Foundation.
https://en.m.wikipedia.org/wiki/GNU_Affero_General_Public_Li...
And for my personal usage, 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.
If you don’t like it, don’t use AGPLv3 software. Those of us who do like it will keep writing AGPLv3 software.
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...
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.
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...
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.)
Not saying the mods of HN are conspiring to bury these comments. But the fish rots from the head in upvote-ordered comment trees
The OSI and the FSF are still extremely popular organizations despite their very big issues, I fully expect to upset some people when I bring this up. ;)
The reason people are such sticklers about that particular definition is because the term carries a lot of weight due to the history behind it. Permitting any drift in the ideology enables things that don't match the history to ride on the coattails of the projects that came before.
It's worth noting that if the SSPL is really so beneficial with zero or near zero drawbacks then there's no need to become embroiled in debates over the ideology to begin with. Plainly state that it isn't "open source", make clear what the difference is, and no one will have any room to complain. You can even coin a new term to make room for license variants. If it's a beneficial arrangement then people will naturally use the license.
The “all linked modules” thing does not appear in the text of the GPL as first released or any subsequent version (it is in some versions of the GPL FAQ, but arguably is contradictory to the text of the corresponding license in view of copyright law.)
But that at least was tied to a (even if actually wrong) remotely defensible as good faith interpretation of the boundary of a single work under copyright, and not an attempt to impose licensing terms on unrelated works that merely happened to be used together. And, also, was restricted to a document that purported to interpret the license in th context of the law, even if it arguably did so incorrectly, and not part of the license itself.
I think I agree with your analogy. It does sort of seem like SSPL is closing a loophole in the AGPL (which was itself arguably closing a loophole in the GPL). At the same time I don't inherently see an issue with drawing a line about what the ideology does and doesn't include.
One way of interpreting it is that it's a choice that the ideological tenants can include users directly interacting with your program via the network but can't extend to backend network interactions.
Another way of interpreting it is that backend network interactions aren't the issue but rather constraints based around the interpretation of the purpose of a program. The GPL and AGPL arguably regulate based on technical distinctions - is the functional unit constructed using a specific component, is the functional unit what's driving the user interaction. The SSPL on the other hand (specifically the final version that was proposed before being withdrawn [0]) contains the phrases "the primary purpose or features of such Software As A Service" and "the value of the software component of such Software As A Service".
Yet another way of interpreting it is that the current religious leaders just don't want to poke that particular hornets nest right now. That pragmatically speaking the SSPL appears to have a disproportionate impact on an awfully specific business model whereas the existing licenses are much closer to neutral (at least in that regard).
If the boundary is truly being drawn in the wrong place presumably that will be corrected if the error is clearly demonstrated. If the SSPL or something substantially similar becomes widely adopted and ends up facilitating the goals of the ideology in practice then people might be convinced to update their opinions. Even if they don't, as long as user needs are being met I'm not sure it matters what the OSI or FSF or whoever else puts on their list. False negatives (ie omissions) don't seem particularly important here while false positives (ie erroneous inclusions) do.
[0] https://lists.opensource.org/pipermail/license-review_lists....
Also, you're wrong. The FSF's position is basically that software that is non-free is immoral, so any license which forces additional software to be released with a free license is inherently moral. A very copyleft license like the SSPL should be the peak of the FSF's goals.
The OSI wrote some nonsense that implies copyleft licenses cannot be open source, and the FSF hasn't yet taken any position at all.
https://www.mongodb.com/legal/licensing/server-side-public-l...
See section 13, "Offering the Program as a Service". To comply with that you need to release all software used "to make the Program or modified version available as a service" under the SSPL.
For something like redis this includes: redis itself, the os you are using to host redis, the drivers and firmware for the hardware you are using to host redis, and more. Also your whole deployment stack up to and including the mouse drivers you use to click on the "deploy" button.
It is an absurd condition that effectively makes section 13 say "you can't offer a hosted version" and the OSI and FSF are right to reject that fig leaf of "it is like the agpl, but more".