Redis Ltd. broke the social contract. They decided that the short-term profitability of the company was more important than the project as a whole, the community which had grown around Redis and the future of the software. Probably a wise decision from a business perspective, but that doesn't make it any less of a rug pull from a community perspective.
You're right that no pre-relicense code was lost. People could and did fork. But something far more valuable was lost: the community's trust. First they relicensed the code solely for their own benefit, now they tried to take over third-party libraries and started behaving in a hostile way towards the community forks. Why would anyone volunteer their time and effort when it is mainly going to benefit a company which is so openly antagonistic against its volunteers? After all, what's the next shady move going to be?
I think op was talking about contributors, who essentially gifted back. One might take offense if they were exchanging gifts with someone, and they open a pop-up store and sell what was gifted.
Also, it's also a tiny bit hypocritical to expect revenue sharing with Amazon without doing the same for contributors.
https://redis.io/legal/redis-software-grant-and-contributor-...
That's just a microcosm of the larger issue, isn't it? Contributors : Redis :: Redis : AWS - Redis gave Amazon the permission to host and make money off of Redis, but Redis was evidently salty about the state of affairs. I think contributors have reason to be salty too.
Nothing could be construed in such a way, because such a reneging is not possible.
Honestly to me you can see the tensions that led to the license change in that post. It’s largely consistent with what antirez has said in the post and in this thread.
You are absolutely right—context! matters, especially when we are talking about something from so long ago. It does seem like the post reflects the confusion and tensions of that time, which may have influenced the eventual license change.
Looking back, it is interesting how the decisions align with what he has shared, both back then and here in this thread. It really gives perspective on how things evolved.
Thanks for pointing that out!
It's a post from 2018, about a specific license confusion situation that occurred in 2018. Context matters.
You can try to be a smartass and add random caveats but that's not how language works.
Imagine if everyone thought like you did: "Sure I promise to do X" (not saying that I mean for the next 5 minutes and will then ignore my past promise)
The post title in its original context is clearly referring to the confusion discussed in the very first sentence: "Today a page about the new Common Clause license in the Redis Labs web site was interpreted as if Redis itself switched license." The title is saying that Redis core's license was not switched to Common Clause at that time in 2018. That's all. It is not titled "I promise that Redis will remain open source forever".
True, he doesn't explicitly say for how long, but I don't think it is unreasonable to read "will remain" as "will remain indefinitely" and not as "will remain so until we change our minds".
That's a reasonable interpretation. But it involves an assumption on behalf of the reader, of words that are not there. I think it's a stretch to consider that specific post a "literal promise" by Antirez.
That said, I just did more research and must admit I am completely wrong with regards to the bigger picture there. My genuine apologies. In the HN commentary on that same post [1], the cofounder/CTO of Redis Labs (Yiftach) apparently made a much more direct statement that "Redis remains and always will remain, open source, BSD license". Due to use of the word "always", that I think can unambiguously be called a literal promise that was broken by the Redis company.
antirez gave
community gave
most people assume that this create a new thing, a group, which has a shared past and value .. and should continue (i would agree to that personally)
"pure" open source advocacy would claim "nothing is ever to be expected in any future" (i can understand that too but find it a bit sad)
1. Redis Inc creates a fork of Redis and names it say RedisNext or anything else(xyz) without a reference to Redis name at all.
2. Announces that, xyz is a fully compatible next gen version of Redis with enterprise features but it is only available under SSPL license.
3. Also announces that original Redis software is feature complete and will be under maintenance with only critical bug fixes.
This will be them playing by the same rules as any other third-party.
Will the community still manage to find fault with Redis Inc?
Will it feel entitled to continued updates or the Redis brand demanding a project handover to a different "group"?
Anything else just complicates things, like we see today, where Valkey and others are referenced as being Redis compatible (at least as far as RESP is concerned), and we either have specific clients (such as valkey-go), or existing Redis clients, that seem to want to maintain compatibility with most (all?) of them.
I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
It's honestly pretty horrible that a group of people can take centuries of man hours away from the community and tell the community to kick rocks when the software they're stealing would NEVER NEVER NEVER have had the traction it has if it were not OPEN SOURCE SOFTWARE TO BEGIN WITH.
There is a rash of thefts going on in broad daylight, and I think people need to start litigating. Its obscene and soulless and doesn't belong as an acceptable thing to do in society.
> NEVER NEVER NEVER have had the traction
There is plenty of even closed source software which has traction in many domains, let alone software released under a license which as anti-rez points out allows the users to freely run their websites on redis, modify and redistribute code etc.(with the exception of running hosting services like Amazon).
For instance, it would be amazing and a great improvement if there was a top-quality CAD program with a similar license to Redis.
> I feel like once a software is open sourced the name of that software should also be required to remain open sourced as well, and any closing of the source must come with a requirement of forking the software and changing the name.
Who should enforce such a requirement, and under what mechanism?
Open source licenses are copyright licenses, whereas product names are trademarks. These are separate legal concepts. Meanwhile "the community" isn't even a legal entity at all. As I understand it, there's nothing to "start litigating" here, and no one to litigate it.
Are you proposing that the OSI should change the OSD such that open source licenses must include mandatory trademark assignment to an independent nonprofit foundation? That's a rather extreme view if so.
It's not that the company shouldn't have the code as open source. The company shouldn't exist in the first place and we're all suffering for it.
[1] aptly named if you think about the nuclear power analogy :)
I don't think the jury is out. If you look at nginx, you won't see a lot of complains over nginx plus. The nginx brand still has a lot of goodwill and a few open source projects seem to be peacefully building upon it without any issue.
Certainly, but if you exchange gifts with someone every christmas, have been doing so for a decade, and they suddenly stop giving you one, or give you an unpolished one where they previously cleaned it to a shine, you are perfectly within your rights to be a bit miffed at that, and withold your own.
People can say the new license is reasonable (and by all reasonable measures it probably is) but that’s not how it feels, and that’s the important part.
And sure, you can say "just do the bug fixes yourself". But if I knew that was going to be the case, I'd never have bothered to contribute.
It sounds like you also have an assumption that the maintainers will spend the effort to maintain your contribution forever, after already spending the initial effort to review and integrate your contribution. This all takes time and money, which has to come from somewhere.
You're asking "Do you not see any value in bug fixes? Do you think software never needs to be updated?" from the contributors' and users' point of view. But the same exact issue exists from the maintainers' point of view.
A lot of people in this thread are commenting as if an open source contribution is a purely altruistic act by the contributor which then solely benefits the maintainers. That's far from the case in reality. Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Correct, that's generally how open source works. You make a contribution, they merge it, and then the assumption is that it is maintained by the maintainers. You seem to act like this is an odd assumption, even though it is and has been the reality for pretty much every open source project ever.
> But the same exact issue exists from the maintainers' point of view.
Right, it's their "job". Maintaining the software. It's pretty much in the name. That's what happens when you accept contributions. They get merged into the software project, and then you (the maintainer) are responsible for maintaining it, or removing the functionality in a subsequent release. That's why code review happens where you consider the maintenance burden, and features sometimes don't get merged.
If this doesn't sound appealing then don't become the maintainer of an open source project.
> Many third party contributors are writing their contributions as part of their day job (meaning they're paid to do it), and the contribution directly benefits themselves and/or their employer by fixing some problem they encountered or adding some feature that they needed.
Sure, and they could've kept it private so it only benefits them and/or their employer. But instead they chose to open source it in the hopes that
1) The maintainers will maintain it
2) It might benefit someone else
That's the whole deal. You're essentially trading your contributions for future maintenance.
As you said above, maintainers don't have to accept your contribution, and if they do, they always have the option of removing it in a future release. And if the maintainers use a CLA or other copyright assignment mechanism, they also have the option of changing the license for future releases. So why are you assuming you can keep using future versions of the product forever if you contribute to it and sign a CLA?
> Sure, and they could've kept it private so it only benefits them and/or their employer
But that doesn't actually provide a net "benefit" to the contributor, because then they have to take on the massive burden of maintaining a private fork.
My point in all this is that contributing to open source often benefits the contributor more than the maintainer, and yet people act like it primarily is an altruistic gift from the contributor which solely benefits the maintainer / product owner.
Well yeah, that's the point. Trading contributions vs maintenance burden.
> My point in all this is that contributing to open source often benefits the contributor more than the maintainer
And yet they choose to do it... Why?
As long as the contributor isn't a cloud provider, they can continue to use the software unimpeded under the new license. Their contribution continues to be maintained by the maintainers. The contributor hasn't been "fucked over" in any way.
If the contributor is a cloud provider, they can choose to enter into a commercial licensing / revenue share agreement and continue to use the software unimpeded. Or they can decline and use/create a fork, in which case any so-called fucking-over is clearly mutual, because the contributor wants to profit from the software explicitly without making its ongoing development financially sustainable for its original maintainers. That's parasitic behavior.
I must ask, have you contributed to Redis? Or are you just expressing outrage on behalf of other people who actually contributed to Redis and may not actually even share in said outrage?
If the latter, why are you so emotionally invested in this topic? And have you ever been on the other side of the coin, maintaining a widely-used open source project?
I'm not sure that the developers contributing code from outside the company see it that way. An easy way to tell if contributors see a license change as a rug pull is if the forks that happen after the rug pull get traction.
> The new license seems perfectly reasonable, given how much companies like Amazon have exploited the gift economy to the point where it threatens these startups survival.
Most of the time, though, open source limits growth - and doesn't threaten the original author's startup. This is a really important distinction because there is a trade-off in choosing open source as a marketing strategy - you do potentially face competition from other contributors, users and parasites that will moderate growth.
Or please explain.
One simply can't admit that they both were doing a valid thing
Truly odd.
Adding constraints later is a non-fallacious slippery slope. The restrictions Redis added aren't directly onerous to 99.999% of users, but now the world is divided into people who are allowed to use it at will, and people who can only use it in certain ways (or not at all). That's an enormous change from a FOSS license. And if they change it today specifically to lock out Amazon, will they change it again tomorrow to lock out my startup? The thing is, now that they've established precedent, there's no way of knowing what'll happen later.
Again, I know I can use GPL or MIT or BSD software for anything I want as long as I play by the exact same rules as everyone else. There's nothing that says you can use it but I can't. The difference between Free to non-Free is vast, even when I'm not affected (yet).
Well, Id say in that case youve got waaaay bigger problems than a license.
>Adding constraints later is a non-fallacious slippery slope.
No, it's very much a fallacious slippery slope. Constraints are the very essence of licenses and contracts.
But before that the community turned its back on Redis Ltd., when it let those cloud offerings from others thrive. Once the “community” got that going, these consequences were inevitable.
Funny how when these license changes started happening people said the exact opposite - that the license is the license and if they didn’t want to be Jeff’d they should have used a difference license.
Get Lost
Who would promise perpetual maintenance for nothing? What organization would sign up to be the only one that can't change terms for improvements?
I don't think "social contract" makes sense here. There's no sovereign power involved. In the sense used, "social contract" essentially means "not in the contract"---as in not in the terms. It's a back door for saying things that were never put down ought to be treated like they were in the license file, just because one side really wants them and doesn't want to DIY or pay for them.
If there are disappointed expectations, that's another thing. But being even very disappointed, and being able to find other like-minded people who would prefer no disruption and new freebies forever, doesn't make unfounded expectations enforceable, nor should it.
I'd be extremely careful speaking of any singular "community". And of assuming that everyone in it expected Redis or another similar project to work just like Linux or other exceptional projects. Most devs dealing with open source have a project relicense---among many others than simply grind to a halt---at some point in their career. For some devs, Redis may have been the first. Others "adopted" Redis knowing the risk and accepting it.
Says who? I completely disagree. A license only applies to the current work done. It does not compel someone to keep dedicating time to a project for free because they also did that in the past. People are allowed to change, even if they once released some code under a different license.
Is the old code still available under the same license ? That’s the only contract I care about , both legal and social.
I am just as much a member of this FLOSS community as others , and I never got the memo about this social contract story. I don’t think it’s true. My trust hasn’t been affected at all.
I understand your point I just get annoyed being lumped into it. Not everyone feels that way.
(But of course my opinion does matter less than actual contributors to Redis ! That’s totally fair.)
You gave us a bunch of stuff for free. You are now putting some conditions on that for new stuff you do. And that makes me sad.
I get the "feelings" part of this. When the world changes, even for the better, it can make us sad.
Equally this license better supports the stuff I am getting for free, and penalizes some giant corporation with buckets of money. And I keep getting stuff for free. So (frankly) I'm happy.
So meh. Is trust broken? Is the community harmed? Should we expect more moves along these lines? Do I see all decisions as clearly black and white - good or evil? Or is there more nuance?
For those upset at AWS no longer getting Redis for free, you can of course fork it and carry on developing for AWS. Those who don't like new redis can carry on running the old one. Those who want new redis can, well, download and use it.
Frankly they didn't hurt my feelings. They're developing. I still get it. I'm happy, not sad.
Thing is, this sentence could equally be applied to the big cloud free riders.
Why should anyone, business or volunteer, write software that benefits FAANGs that don't pay their fair share?
Folks like to cite MongoDB as some great example, but Redis had significant community contributions in recent years. And AWS never used any Mongo code.
It is wonderful thing though, with Open Source, people can band together and "pull Valkey" to create well maintained fork based on all those past contributions
Code in which a vulnerability is discovered is in the same position. It's developed a susceptibility to a new force malevolent to its purpose. It doesn't have to change to rot, it suffices for the world to change around it.
I wish you success in Redis Labs and thanks for Redis. In my other comment I said I never considered using Redis under the new license, but I didn’t say that I never would consider it, and I think I would if I found myself on a project that needs a key value database with enterprise support or more bells and whistles. I think it has its place, and to me it is an awful lot like postgres and EnterpriseDB, especially if Redis Labs gives its blessing, directly or tacitly, to adding this new vector type to valkey.
https://blog.tidelift.com/what-i-learned-from-the-server-sid... https://opensource.stackexchange.com/questions/11291/how-to-...
What it isn't close to is the original license, which is a permissive open source license.
The license switch-up is why a fork was needed. Matrix did a similar thing with the AGPL which alas, doesn't have a major fork. https://element.io/blog/element-to-adopt-agplv3/ Although it's technically still open source, they didn't do right by the contributors to it.
Even Stallman would agree that nothing can be open source if the freedom 0, freedom to use software for any purpose, is not provided. SSPL does not grant this freedom.
> Industry participants, including Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. are supporting Valkey.
The community rallied behind the project that ensures the software they care about remains free and open and available to all without the risk of being blind-sided.
LevelDB is a key-value storage library that writes to disk. It's the sort of thing you could use as the storage layer for a relational database.
On the other hand, Redis is an in-memory key-value database server.
That is one side of the coin: value never gets lost!
The other side is that the BSD license is very clear what it allows. It's a good thing that there are licenses that allow what Redis did. It is also a good thing that there are other licenses which can help prevent what Redis did.
It is our choice as developers and we should never blame others for exercising the rights we granted them.
The government identity then distributes those monies to the artists according to playlists collected from said venues.
It works for big acts, for small acts the overhead tends to consume the payouts.
You can do this without fucking over past contributors. Just... Don't change the license. Then still do all that other stuff. They're not contradictory.
I can understand that, but the thing about the BSD license is that such value never gets lost. People are able to fork, and after a fork for the original project to still lead will be require to put something more on the table. Inside Redis it was tried very hard to don't change license. For years it was some kind of "dogma", something one could not even speak about. Then after all the kind of attempts, and following the experiences of MongoDB and others, finally this choice was made. (Disclaimer: I saw the switch as an outsider, so my information is not complete about the final decisions -- I for sure know how this was always considered to avoid if other setups were possible).
However now I see that there is the case for giving the community something in exchange to the license change: a lot of good things in the core, a very good attitude towards the community, and so forth.