4 ms·

I'm really interested in this bit: "the fracture with the community is not about licensing, or at least it’s not mainly about licensing" I wish he'd elaborated

I'm really interested in this bit: "the fracture with the community is not about licensing, or at least it’s not mainly about licensing" I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?

antirez 2y ago
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.
- collingreen 2y ago
  Thanks for directly expanding on this.
- worik 2y ago
  > 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.
  - nijave 2y ago
    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.
    - worik 2y ago
      > I care about getting things done Yes. But you care about more than just that....
- QuinnyPig 2y ago
  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.
  - tommica 2y ago
    Isn't that just lying?
    - progbits 2y ago
      Why? The original opensource lineage is valkey, it just changed the name. Redis is where the oss history forks and turns proprietary.
      - matt_kantor 2y ago
        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.
        LudwigNagasena 2y ago
        They both were the same project with the same codebase and the same contributors before they split. It was as much project A as it was project B.
        matt_kantor 2y ago
        > It was as much project A as it was project 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.
- Spivak 2y ago
  > 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.
  - CoolCold 2y ago
    > 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.
- saghm 2y ago
  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.
  - antirez 2y ago
    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.
    - saghm 2y ago
      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.
  - matsemann 2y ago
    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.
- leosarev 2y ago
  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.
  - antirez 2y ago
    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.
    - leosarev 2y ago
      No, we can provide proprietary scripts that install GPLed software (i.e. setup Linux machines), but can't provide proprietary scripts that install AGPL.
jrochkind1 2y ago
Yeah, I have the same question, I wasn't sure if he had said what he does think the fracture was mainly about and I missed it.
JamesSwift 2y ago
Yeah, even if the split isnt entirely about licensing (and I do think it mainly is), the rest is a result of the licensing changes as well in terms of the implications and side-effects. Its the way people felt rug pulled and eroding the trust, which is now forever lost.
nikolayasdf123 2y ago
you can see there is shift from roots in redis. original over-the-write protocol was human-redable by design. now more and more over last couple years API and instrumentation, docs, gets non-human readable at all (mix of ASCII and hex binary encoding, say in FT.SEARCH, speaking of FT.SEARCH it is barely readable even when in non-binary form...)
nikolayasdf123 2y ago
also, lack of japanese and korean support... and non-willingness to integrate this when developers native speakers even want to and volunteer to improve it. something is off in redis execution hope with this guy comes back it improves!
alecco 2y ago
Techbros and large corporations still have the original source code they built their business on. What they want is free community updates and support forever while they give almost nothing back. So it's not a licensing problem. It's not a free software problem. It's a "free as in beer" support problem. AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.
- nijave 2y ago
  That's not been my experience. My limited experience at a large corporation was "throw money at vendors for enterprise support" The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.

antirez 2y ago

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.

collingreen 2y ago
Thanks for directly expanding on this.
worik 2y ago
> 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.
- nijave 2y ago
  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.
  - worik 2y ago
    > I care about getting things done Yes. But you care about more than just that....
QuinnyPig 2y ago
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.
- tommica 2y ago
  Isn't that just lying?
  - progbits 2y ago
    Why? The original opensource lineage is valkey, it just changed the name. Redis is where the oss history forks and turns proprietary.
    - matt_kantor 2y ago
      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.
      - LudwigNagasena 2y ago
        They both were the same project with the same codebase and the same contributors before they split. It was as much project A as it was project B.
        matt_kantor 2y ago
        > It was as much project A as it was project 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.
Spivak 2y ago
> 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.
- CoolCold 2y ago
  > 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.
saghm 2y ago
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.
- antirez 2y ago
  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.
  - saghm 2y ago
    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.
- matsemann 2y ago
  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.
leosarev 2y ago
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.
- antirez 2y ago
  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.
  - leosarev 2y ago
    No, we can provide proprietary scripts that install GPLed software (i.e. setup Linux machines), but can't provide proprietary scripts that install AGPL.

jrochkind1 2y ago

Yeah, I have the same question, I wasn't sure if he had said what he does think the fracture was mainly about and I missed it.

JamesSwift 2y ago

Yeah, even if the split isnt entirely about licensing (and I do think it mainly is), the rest is a result of the licensing changes as well in terms of the implications and side-effects. Its the way people felt rug pulled and eroding the trust, which is now forever lost.

nikolayasdf123 2y ago

you can see there is shift from roots in redis. original over-the-write protocol was human-redable by design. now more and more over last couple years API and instrumentation, docs, gets non-human readable at all (mix of ASCII and hex binary encoding, say in FT.SEARCH, speaking of FT.SEARCH it is barely readable even when in non-binary form...)

nikolayasdf123 2y ago

also, lack of japanese and korean support... and non-willingness to integrate this when developers native speakers even want to and volunteer to improve it. something is off in redis execution hope with this guy comes back it improves!

alecco 2y ago

Techbros and large corporations still have the original source code they built their business on. What they want is free community updates and support forever while they give almost nothing back. So it's not a licensing problem. It's not a free software problem. It's a "free as in beer" support problem. AGPL only slightly prevents this by forcing them to share their changes to the source. And usually this is not very useful to the community, anyway. And very little effort. And the same people scream it's an evil license. They want free (as in beer) stuff forever and it's not just the source code. It's very ungrateful of them.

nijave 2y ago
That's not been my experience. My limited experience at a large corporation was "throw money at vendors for enterprise support" The bigger issue was startups and small/medium sized companies with limited technical support and limited money to buy enterprise support or in-house experts. These are the same companies heavily leaning on managed services from vendors like AWS.