For somebody, like you and many others, it was very important to retain an OSI license. But I feel that in general given that the new license is IMHO good for almost every user, from the POV of what they can do with the code, and that the cloud situation was quite self evident, I believe that with better communication, and immediate developments/merges in the core, to counter balance the license switch, many people would understand the license matter.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.
> is IMHO good for almost every user, from the POV of what they can do with the code
I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't. We're trying to figure out our migration path right now and it's almost surely going to be Valkey.
Large vendors were never going to pay up and so it's all loss for everyone involved. I have to do work, every project that works with Redis has to do work to support Valkey now, the eventual divergence will force people to pick a side which will probably also be Valkey for everything other than the client libraries Redis Labs personally develops. It's a mess.
Open core proprietary add-one for new fancy AI features could have avoided the split and gotten you in the door with big cloud vendors willing to sell your add-on in the marketplace with revenue sharing. They did it with Bedrock and Anthropic is making bank off it.
> I think the thing that hurts a lot of folks is the one thing they wanted to do with Redis is use a managed version of it in AWS. And now they can't.
Hum, I have not considered this aspect before - I mean I've realized that AWS probably cannot use Redis [until they pay back], but that users (customers) would be affected...likely I'm biased here cuz not using managed services of that sort, sat having Redis + Sentinel setup of our own.
It sounds like your opinion is that the communication around the relicensing was the issue rather the relicensing itself, but from the standpoint of the people who decided there was enough of an issue to switch away from Redis, is that the case? As an outsider to the Redis community both before and after the schism, I don't know that you're wrong, but I have to imagine that if I were someone concerned enough to consider forking (or switching to a fork), I wouldn't be happy with someone involved in the project making a blanket statement about whether my motivations were actually about the licensing or not. Ironically, this seems like it's exactly the type of communication that could exacerbate concerns around licensing.
How many, outside a few vocal voices, actually cares about the licensing? My company would choose Redis 100/100 times, because it's the known and trusted brand, and not some fork they've never even heard of. And the license change doesn't affect us in any way.
Additionally, I think it's a bit entitled to be so up in arms about a product everyone is using for free. There is a big issue with how open source is unmaintainable to do in our industry, and I applaud Redis' attempt at trying to fix it.
I don't personally have a strong opinion about relicenses to try to prevent competitors from selling cloud-bases services (either in the case of Redis or in general; if anything, having worked at MongoDB at the time when it was relicensed to SSPL biases me a little bit in favor of companies who do relicenses like this). My perception is that there's a non-trivial contingent of users who migrate whenever something like this occurs, but you're not wrong that this might be influenced by a smaller number of louder voices.
I do agree with you about open source developers being within their rights to maintain as they see fit. My personal philosophy is that while open source maintainers have no obligation to maintain in a way that conforms to user expectations, users still have the right to voice their opinions on that (although the maintainers are free to ignore it, per the previous point). To me, the distinction that matters isn't about whether users are "entitled" or not but whether they're voicing opinions about an open source project (including decisions about how to maintain it) versus personal insults at individuals. I don't see anything wrong with someone being vocally upset about a license change; I just also don't see anything wrong with a maintainer choosing not to care about it.
> I do agree with you about open source developers being within their rights to maintain as they see fit.
I used to agree with this, but it now seems a rather narrow view of how open source actually works. Open source projects tend to make a big deal about being a "community," and this is certainly true of many that are backed by commercial vendors. To me the use of community does imply mutual obligations between developers and users or the word has no meaning.
Unless, that is, you think community is just a synonym for "marketing funnel."
One thing is the normal user concerns, that are granted, and I understand and respect them. Another thing is forking, that in the specific case of ValKey was an effort whose impulse was provided by companies having an economic damage because of the license switch. So I think those are two orthogonal questions.
Hmm, I think I see. If I understand correctly, your opinion is that independent of the motivations of the forks, independent users switching to the forks could have been avoided with better communication? I guess that's a fair stance, although I'm not sure I fully agree with it. From what I can tell, there's a fairly large contingent of open source users who won't be happy with a license being changed to something they don't consider open source regardless of the rationale.
I hear you, but at the same time it was badly done. I’ve been referring to Redis as “a proprietary fork of Valkey,” and that message has clearly resonated.
That's like saying Xfree86 is a fork of X.org, MySQL is a fork of MariaDB, or OpenOffice is a fork of LibreOffice. "Forking" is an event that happens in time, so project A cannot be a fork of project B if A existed before B.
Valkey is as much Redis as it is Valkey? Then why isn't it called "Redis"? Clearly there's a distinction or the fork would never have happened. Is Redis also as much Valkey as it is Redis?
Names signal who has control over a project, not anything about its history/implementation/license. Otherwise every piece of software that goes through a rewrite should change its name.
Projects also don’t necessarily change names when control over them changes either. It’s the Ship of Theseus kind of thing. There is no single property that would delimit when software stops being itself. And the name is hardly the most important part.
After all, the identity of ever-changing entities is ephemeral and is only in our heads.
"Valkey" is not called "Redis" because as much as the development is shared by the community, the trademark isn't.
A lot of developers and users are sticking with the community and the license instead of sticking with the trademark holder.
> Names signal who has control over a project
Trademark is a specific form of intellectual property and there are many others. I don't understand how you got to that conclusion to be honest. A restaurant in my neighborhood had to change name recently because it was too similar to a big chain, does that mean it's a different restaurant now?
> But I feel that in general given that the new license is IMHO good for almost every user
That is the nub of the sticking point.
The new is OK for people who only care about getting things done. But for people interested in building and being part of a community, giving as well as taking, not so much
This:
You may not make the functionality of the Software or a Modified version
available to third parties as a service or distribute the Software or a
Modified version in a manner that makes the functionality of the
Software available to third parties.
I care about getting things done but don't want to take on the risk of an encumbered license and the volatility that comes with license changes.
To me, these products are booby traps that are more likely to need replaced in the future when something changes again.
Put another way, it's a sign of an unhealthy ecosystem.
There's so much gray area in these terms you have to keep the lawyers involved not only in the initial indentation but product features in the future to make sure you don't accidentally cross a very poorly defined line.
I'm a vendor of some packaged on-premise solution. We are using a Redis as a cache layer inside. Risk of being forced to GPL out our installer is unacceptable for us.
In your use case, you could not even use the AGPL, basically? Is that what you mean? Thanks. That would be an interesting point, but it goes over the borders of the SSPL itself. Would be more BSD/MIT vs all the rest.
No, we can provide proprietary scripts that install GPLed software (i.e. setup Linux machines), but can't provide proprietary scripts that install AGPL.
We will not win back you as a user, and I respect that. But many, many users that see openness, good features and documentation, the github repository at the center of everything: I believe they will appreciate this, and can decide that Redis is good for them.