14 ms·

Redict 7.3.0, a copyleft fork of Redis, is now available

199 points by drewdevault 3y ago

sgerenser 3y ago
Hopefully they don’t get legal pressure from Redis Labs over name similarity. Didn’t OpenTF have to change to OpenTofu for that reason?
- lolinder 3y ago
  The difference is that TF is a widely-used acronym for Terraform, while Redict is a distinct word. That doesn't mean Redis won't try to put pressure, but it does mean it's not as obvious that they'd win if it came down to it.
zwaps 3y ago
If you have a commercial use-case, there is also a non copyleft fork available here https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community https://www.linuxfoundation.org/press/linux-foundation-launc...
- drewdevault 3y ago
  LGPL is a pretty weak copyleft license and was chosen specifically because it is amenable to almost all present-day commercial use-cases for Redis. You don't have to publish your changes to Redict in most situations, commercial or not. Check out the FAQ here: https://redict.io/docs/license/ https://redict.io/docs/license/
  - zwaps 3y ago
    "Tip: Commercial and non-commercial users of Redict are not required to publish or otherwise “open source” the source code of Redict, including any private modifications they make to the source code" And very next section: "If you compile Redict’s source code into an executable form and distribute this executable form to others you are required to include a copy of the Redict source code and any modifications to it licensed under the LGPL." Let's be real: Especially in the EU, the definition of distribution of derivative works is typically so strong that it's super risky to use any copyleft license and I personally (e.g. consulting for large companies) see huge issues with compliance whenever this happens. In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.
    - drewdevault 3y ago
      Note the careful use of private modifications as not requiring disclosure of the source code. You only have to include source in the very specific situation of building Redict and providing it in compiled form to customers directly. Like, if you give someone the ELF file. If you run it on their behalf as a cloud service or something you have no obligation to provide source, which is the most common commercial use-case of Redis. LGPL is a very well understood license, even in the EU, and is already in use for many projects that are widely depended on commercially. Consider ffmpeg as one prominent example, which is used by virtually all multimedia software in the industry. It is very easy to comply with the LGPL, and your legal department works for you, not the other way around.
      - frant-hartm 3y ago
        > legal department works for you, not the other way around. Not sure what planet you live on. Unless you are one of the execs, Legal (and other compliance departments like HR) work pretty much against you. They exist to protect the company and the exec team.
        drewdevault 3y ago
        They exist to serve the bottom line, and if the bottom line is best served by evaluating and approving the LGPL license (a trivial task, as it is broadly understood and the compliance requirements are negligible for most users), then that's what they will do. And in any case, no one is categorically opposed to the LGPL. Unless you think that no one is using Linux in industry, given that it uses a stronger license (GPL), which is patently absurd.
        dani0854 3y ago
        > And in any case, no one is categorically opposed to the LGPL. That's not exactly true, take android as an example, which has a policy of "no GPL in user space", if I recall correctly. I do however believe that due to drivers and other things, GPL is beneficial in Linux kernel, but that rather an exception. And also Linux is GPLv2, which is a big difference to GPLv3 (and so to LGPLv3).
- tormeh 3y ago
  Most commercial projects can safely use any of the Redis forks, whether Redis itself, Redict or Valkey. For Redict, you have to provide the source code of Redict - and Redict only! - in the case that you distribute it to customers. Redis has harsher terms, but only if you provide Redis-as-a-service. If you aren't a cloud provider and you don't modify the code of your chosen Redis variant, this is all a big nothingburger and neither of the licenses impose any important restrictions on you. We desperately need all open questions regarding AGPL and SSPL to be clarified in court so this fearmongering can stop. It's really really bad for open source.
  - Macha 3y ago
    > If you aren't a cloud provider and you don't modify the code of your chosen Redis variant, Or get hosted redis services from someone other than Redis Labs. That isn't fearmongering about the SSPL, it is literally the point of the SSPL.
    - tormeh 3y ago
      Sure, but that's left for the hosted service providers to figure out. No one can sue you for using AWSs offering.
  - verdverm 3y ago
    Open source seems to be doing fine without the clarity. Even fields that have nothing to do with software are adopting the mindset. The movement only gains in steam
    - yunohn 3y ago
      Most popular OSS projects use Apache and MIT in my experience, precisely because GPLs are problematic for commercial usage and contributions from employed people.
      - drewdevault 3y ago
        This is a common misconception and source of fear/uncertainty/doubt regarding copyleft licenses. It's true that, the stronger the copyleft license, the more obligations it imposes on companies, and the AGPL is perhaps the most onerous of all and thus the least attractive to businesses. But, copyleft exists on a spectrum, and there are thousands of big-ticket FOSS projects that tens of thousands of businesses depend on and make use of that have a copyleft license. Linux itself is GPL, and pretty much everyone depends on it. The license for Redict is one of the weaker copyleft licenses and should not pose any onerous compliance obligations on the most common commercial use-cases for Redict.
CodeNest 3y ago
[dead]
gadders 3y ago
I don't get the point of this - people are upset that Redis is trying to make money from companies like AWS and Google?
- drewdevault 3y ago
  Substantial portions of Redis were written by AWS and Google. People are upset because Redis is a collaborative project with many people working on it and Redis Ltd wants the sole right to commercialize the work of an entire community. LWN has a good overview: https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/ https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/ Redis Ltd is only responsible for about 20% of the work.
  - baq 3y ago
    Perhaps true but besides the point, actually - the same companies will happily take your code and make a saas offering out of it on their oligopolistic infrastructures, making it economically unviable to compete with. ...which, given LGPL, will be worse now as they'll simply not share their modifications because that's the legally safest option.
    - KingOfCoders 3y ago
      And well, why not? That is the idea. It's open source.
  - sotillan 3y ago
    Yeah, I think a key point is that Salvatore Sanfilippo, the original developer, maintainer and principle contributor[1] for 11 years, was not a founder of Redis Labs. He joined as an employee in 2015 but resigned in 2020. Perhaps he has equity in Redis Labs, but it's not clear he stands to profit at all from this switch. [1] https://github.com/redis/redis/graphs/contributors https://github.com/redis/redis/graphs/contributors
  - sanxiyn 3y ago
    AWS and Google contributed those under BSD license, being fully informed that Redis Ltd can commercialize like this. It makes perfect sense for AWS and Google to fork immediately after the switch, but for contributions before the switch, there is no basis for AWS and Google to complain Redis Ltd, either legally or morally.
yurytom 3y ago
What about Valkey? We have 2 big forks now
- dewey 3y ago
  This is directly addressed in the blog post: https://redict.io/posts/2024-04-03-redict-7.3.0-released/#why-redict https://redict.io/posts/2024-04-03-redict-7.3.0-released/#wh...
- JoshTriplett 3y ago
  Valkey has the support of various Redis developers who moved over, keeps the same license as the original Redis did, and stayed on GitHub to keep the workflow that Redis developers and contributors are used to, so I expect it'll end up winning out. GitHub is proprietary and not ideal, but when trying to get developers on board after a fork, using GitHub and using the same license as the original avoids spending innovation tokens / weirdness budget unnecessarily.
  - drewdevault 3y ago
    Codeberg was chosen over other candidates because it has a workflow similar to GitHub, to ease the transition for the existing community. In my opinion, we're going through a big shake-up anyway and there's no better time than now to consider changes like this. We did discuss moving it to GitHub or another platform entirely, but as a community we decided to stay on Codeberg. Changing the license was an absolutely essential requirement, and this is a crucial time to evaluate and commit to that change. As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd, and a fork which doesn't fix that bug isn't addressing the underlying problem.
    - GrumpySloth 3y ago
      > As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd Disclaimer: I don’t have anything against the relicensing to LGPL. I think it’s your right and I root for you. That said, correct me if I’m wrong, but, as far as I understand, what Redis Ltd did, they could do regardless of the license. Copyleft wouldn’t have stopped them, given the CLA. Moreover I wouldn’t call that exploitation. To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis. Would that be exploitation? Are they obliged to provide free work on Redis indefinitely? They can’t retroactively change the licence of previous versions of Redis, so they can’t actually take anything away. The existence of the 2 forks is proof of that.
dewey 3y ago
Time will tell if the version on Codeberg (https://codeberg.org/redict/redict https://codeberg.org/redict/redict) can compete with the fork on Github (https://github.com/valkey-io/valkey https://github.com/valkey-io/valkey) in terms of visibility and contributions.
- forty 3y ago
  Valkey is under the Linux foundation umbrella, and I assume will be developed by the same people who were previously making redis. I could not find who is behind predict.
  - dewey 3y ago
    You can see it here: https://codeberg.org/org/redict/members https://codeberg.org/org/redict/members
  - drewdevault 3y ago
    It's worth noting that the Linux Foundation is a commercial consortium and the companies behind Valkey contribute over $1M to its annual budget.
    - rmbyrro 3y ago
      > contribute over $1M to its annual budget That on top of developer hours dedicated to various projects, which are probably worth multiple millions.
      - deleted 3y ago
        [deleted]
qwertox 3y ago
I mostly use Redis in combination with RedisJSON, and RedisInsight is a nice way to check what data is stored. I'm only using it for a handful of small documents which mirror the state of some devices. These options (Redict, Valkey) don't seem to support JSON as a data type, so I'd like to know if there is some server specifically made for dealing with JSON documents. Something like a very lightweight MongoDB server which can be managed via a browser and where the data can be inserted/updated/removed via HTTP calls.
- drewdevault 3y ago
  Redict is binary compatible with Redis Modules, including RedisJSON, out of the box, so you can keep using it no problem.
- cacois 3y ago
  Lightweight is your problem here, I think, but I've used CouchDB successfully in similar situations. However, its not in-memory like Redis is.
  - nurple 3y ago
    Big fan of couch, wish it was more popular. Its http interface basically removes the whole http translation layer of code most projects put in front of the db. For such a small need, you might also look at PouchDB. Inspired by couch but simplified to allow it to run in-browser.
8organicbits 3y ago
Being copyleft, Redict can merge any contributions to Valkey. However, Valkey cannot merge any of the Redict commits (unless the contributor actively dual licenses them). Being non-open source Redis can merge any contributions made to Valkey but not from Redict. So if you don't want your code to end up in Redis, contribute to Redict. Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.
- reconditerose 3y ago
  As someone who has extensively worked on a Redis fork at AWS and worked with the company for 6 years, I wouldn't worry about Redis merging stuff from Valkey. We believe they refused a huge number of PRs because we believe it would have messed with their internal features. (We can't prove this, because they never discussed it publicly). One of the main reasons I started contributing to Redis was to help my team at AWS get out of the business of merging conflicts. > Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease. It's just a guy from Redis. It's not even one of the three former maintainers (Oran, Yossi, or Itamar). The number of open PRs is also dramatically down (it was around 550 when I last looked before the fork, since I've gotten a lot of notifications from old PRs of people refusing the CLA).
treprinum 3y ago
Why would any startup ever get idealistic again and release their product under open license when big boys can just fork it and destroy their business? I think the dual AGPL/commerical licensing will be the choice of anyone with still some idealism left.
- marcinzm 3y ago
  There's nothing idealistic involved. Startups want users more than they want revenue. Thus they open source it, use VC money to cover the loses and then eventually try to squeeze those users for money. Redis Labs also did not in any way make Redis. They came in later to exploit the already open source project for their own benefit.
  - treprinum 3y ago
    Ok, I was mistaken then. I thought Redis Labs folks created Redis initially.
    - fmajid 3y ago
      No, they didn't, although they misleadingly claimed to be the "Home of Redis" for a number of years. Then they hired Salvatore Sanfilippo (antirez), the author of Redis, and eventually purchased the copyright from him. Very sleazy outfit that fully deserves all the scorn poured on them.
      - danielovichdk 3y ago
        If one sells a copyright to another, how can that be considered sleazy ? Someone made the sell - to make money I presume - and another bought it, to perhaps make more money ? Seems not that out of reach ? I don't understand the bitterness around this debate, it seems most people are frustated that they have to pay for something that was free, but at the same time, they probably made money from what was free. I totally understand, with todays mess of maintainers not getting paid in full, that at some point, someone wants money for their work. Be it a person, a company or you doesn't matter. But right has to be right. I think we will see a lot of this the next 10 years, simply because we cannot afford maintainers not detecting backdoors in a code-review from some bad actor.
Linda231 3y ago
[dead]
Linda231 3y ago
[dead]
rmbyrro 3y ago
I respect their choice of license. Totally agree they shouldn't let Redi$ take their work after what Redi$ have done. But still let any kind of project use it, including cloud vendors. Downside is that Valkey won't be able to use Redict code, though.
endisneigh 3y ago
I read the post and it’s not clear why it’s not MIT licensed. Why not allow attempts to “create proprietary distributions?” That’s what open source would allow, no? I honestly do not see this as being different than Redis. Do BSD or MIT and be done with it. It seems needlessly ideological. Everyone wants to call their stuff open source but have strings attached.
- skywhopper 3y ago
  Do you feel the same way about Linux and Git? Anyway, the Redict team are doing their thing and letting Redis and Valkey be. You’re the one insisting on Redict doing things the way you would like, so who exactly is being ideological?
  - endisneigh 3y ago
    Isn’t Linux GPL? What’s the relevance? Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
    - ksec 3y ago
      Because "Everyone wants to call their stuff open source but have strings attached" implies GPL ( or CopyLeft, Non-BSD / MIT license ) have strings attached. So the parent was asking isn't Linux Open Source but with strings attached? And if so are you happy with Linux? Although I am assume what you meant was that Redis was originally a BSD / MIT, and re-licensing it to LGPL seems ideological. But I could be wrong.
      - endisneigh 3y ago
        Copyleft is a string. The default would be complete permissiveness. If someone gave you something the correct presumption would be that you can do as you like with it, unless - and what follows are strings, like copy left. It isn’t inherently bad, but it is what it is. My happiness with Linux is irrelevant because Linux to my knowledge was not re licensed to be more restrictive.
crabmusket 3y ago
Everyone's discussing the license and the hosting, but I think this is the truly interesting differentiator: > In technical terms, we are focusing on stability and long-term maintenance, and on achieving excellence within our current scope. We believe that Redict is near feature-complete and that it is more valuable to our users if we take a conservative stance to innovation and focus on long-term reliability instead. This is in part a choice we’ve made to distinguish ourselves from Valkey, whose commercial interests are able to invest more resources into developing more radical innovations, but also an acknowledgement of a cultural difference between our projects, in that the folks behind Redict place greater emphasis on software with a finite scope and ambitions towards long-term stability rather than focusing on long-term growth in scope and complexity. It'll be interesting to see what Valkey's future is with the maintainers having some lofty goals, and expressing frustration that they weren't able to move fast enough or be innovative enough under Redis. As a small-time user of Redis I kind of like the idea that I could just have what I've got now, but with a promise that someone's looking after it. I don't feel the need for millions of transactions per second, a timeseries database, etc.
- reconditerose 3y ago
  Hey, I am one of the maintainers of Valkey, I'll try to answer. I think there is a few things I would like to see in the mid to short term. We're trying to make a lot of the core datastructures more efficient (both in terms of memory and performance) as well as the main dictionary. Valkey 8.0 (or whatever first major version we have) will have lower overhead per key-value pair. Multithreading performance is nice, but as you mentioned most people don't need it. It gives folks a lot of runway if they need to scale but don't want to use clustering, and can also be a "quick fix" for certain types of P99 or higher latency spikes. Clustering is also really hard to use today, and a lot of the current folks want to fix that. It's a huge community pain point. Observability is another pain point I would like to improve. (Disclosure, I work at AWS as well) We see a lot of customers ask about "why did we see a performance issue", and Redis really doesn't provide a lot of introspection to diagnose those issues. Another big area, which maybe will work for redict, is we want better integration with other OSS projects, especially CNCF projects like envoy, open-telemetry, K8s. There are a lot of self-developed projects floating around, we're hoping we can pull all of this together to make a more cohesive project for people to use instead of what we see today. I think another big issue will be clients. I'm concerned Redis will try to inject a poison pill into the clients they own to make it so they can only talk to "official" Redis versions. Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open. We will likely passively support redict with our clients, so they'll get that for free. We want to do all the cool feature stuff to (timeseries, JSON, bloom, RAG), but I would like to keep the core pretty clean.
pietroppeter 3y ago
I think what are seeing here is the true power of an open license. There are now two forks with different approaches and two dedicated and competent teams and we will see not only who wins, but if any or both win (for some definition of win).
- Brian_K_White 3y ago
  To me that's the big one, that even you an individual has the ultimate option to define "win" however you want. Not only are you not subject to the conflict of interest between users and sellers in a commercial product, you aren't even subject to the popularity contest tyranny of the majority in a non-commercial product. If someone takes the last open version of something and forks it and never does anything further to it and no one else ever uses it, but it does what they want, they win. They win at life no matter what anyone thinks about that fork.
soygem 3y ago
[flagged]
gigatexal 3y ago
Just to be 100% I can still use Redis for free in my projects in production so long as I don’t sell a hosted version of it right given this new Redis license?
- dartos 3y ago
  To be 100% you should email redis and/or ask a lawyer. Not randos on HN
- drewdevault 3y ago
  I agree with dartos, but I will state for the record that you can use Redict for free in production even if you do sell a hosted version of it.
- Y-bar 3y ago
  That is the stated intent and spirit of the new license terms, but as others have said, ask a lawyer to be 100% certain.
kerkeslager 3y ago
This is all fine and good, but the big question for me personally is when we can expect to see cloud providers (DigitalOcean and AWS are the ones I'm using) provide hosted versions of Redict OR Valkey with some sort of upgrade path from Redis. I'm a good full-stack developer and a mediocre server administrator, so self-managing hosting is usually not something I'd prefer to do.
- hiccuphippo 3y ago
  AWS has ElastiCache, which is compatible with current redis, but I wonder in which direction they'll go.
deleted 3y ago
[deleted]
sitkack 3y ago
I don't see much info on the governance of the project. What is the stance on incorporating Rust into the codebase?
- drewdevault 3y ago
  It's essentially a do-ocracy in practice, though we have discussed the possibility of putting together a foundation to steward it, particularly if we start to get money involved. There are currently five people who have admin rights with respect to their various competencies, and anyone who establishes trust with the community and gets stuff done will also be promoted to their level of competence, as it were. Though I hesitate to describe it like this, I think of "admin" more as a clerical role than an authoritarian one. You're good at code review? Everyone generally trusts you? Then merge rights are just a tool to help you do your work better. I don't think anyone is going to be very excited about introducing Rust unless there's a compelling reason to, but feel free to bring it up on the issue tracker for discussion and see if you can form a consensus on the matter with the rest of the community.
  - sitkack 3y ago
    Great responses! I wish you the best of luck and when I am able to be involved with OSS again, I will gladly help out with Redict. I think the LGPL is a good choice. Areas where I would personally want to see Rust in a project like this, a) parsing and talking with the network b) extension mechanism moved to Wasm (Wasmtime for execution) but that plugins would be moved into a Wasm container. It would also be a nice property if the core of the project maintained a compile to Wasm compatibility so that Redict could be run everywhere.
    - drewdevault 3y ago
      Thanks! It would be great to have your help. I think your Rust/wasm goals are a little bit dramatic for the goals we established among ourselves, but by all means start a conversation about it. Good support for compile-to-wasm is probably something that we'd be down to have upstream, though.
caymanjim 3y ago
What's the track record of other projects that have gone too commercial and had their code forked like this? The only other example I can think of offhand is MySQL and MariaDB. I don't know what the market share of either is now. Do people still use MySQL? Does it generate profit for Oracle? I think Redis Ltd. is vastly overestimating the value of their product. Redis is incredibly popular, but the vast majority of users are just looking for a simple in-memory key-value store for lightweight database use cases, caching, etc. I've used it in some way in just about all my projects for the past ~15 years. The thing is, I don't care that it's Redis. I don't care about most of its features. I could have subbed in memcached or any number of other solutions. It would have been trivial and had no impact on my system. I have no doubt that there are some power users who need advanced features of Redis, but I also have no doubt that Redict will be better, and that there will be companies who provide commercial support for it. I'm just going to use Amazon ElastiCache for big projects, and continue not caring at all about what it is behind the scenes. And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it. I can't imagine a scenario where Redis Ltd. is relevant or profitable 10 years from now. Oracle can afford to lose money on MySQL forever, and treat it as a loss-leader for acquiring new Oracle DB customers or at least new MySQL service contracts. Redis Ltd. has one product and few people need support for it or care much about it vs. alternatives. Edit: Or Valkey instead of Redict; either way, which exemplifies the degree to which I don't care.
- drewdevault 3y ago
  Just passing by with a quick nit to pick: >And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it FYI we're publishing to registry.redict.io, so s:redis:registry.redict.io/redict:g https://redict.io/docs/redis-compat/containers/ https://redict.io/docs/redis-compat/containers/ Not that it detracts from your point in any way :)
  - zvr 3y ago
    THANK YOU, for making images based on scratch, rather than Debian or Alpine. It makes redistribution so much easier from a license compliance perspective. And double thanks for providing an SPDX document for the contents of the image.

199 points by drewdevault 3y ago

Hopefully they don’t get legal pressure from Redis Labs over name similarity. Didn’t OpenTF have to change to OpenTofu for that reason?

lolinder 3y ago
The difference is that TF is a widely-used acronym for Terraform, while Redict is a distinct word. That doesn't mean Redis won't try to put pressure, but it does mean it's not as obvious that they'd win if it came down to it.

zwaps 3y ago

If you have a commercial use-case, there is also a non copyleft fork available here https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community https://www.linuxfoundation.org/press/linux-foundation-launc...

drewdevault 3y ago
LGPL is a pretty weak copyleft license and was chosen specifically because it is amenable to almost all present-day commercial use-cases for Redis. You don't have to publish your changes to Redict in most situations, commercial or not. Check out the FAQ here: https://redict.io/docs/license/ https://redict.io/docs/license/
- zwaps 3y ago
  "Tip: Commercial and non-commercial users of Redict are not required to publish or otherwise “open source” the source code of Redict, including any private modifications they make to the source code" And very next section: "If you compile Redict’s source code into an executable form and distribute this executable form to others you are required to include a copy of the Redict source code and any modifications to it licensed under the LGPL." Let's be real: Especially in the EU, the definition of distribution of derivative works is typically so strong that it's super risky to use any copyleft license and I personally (e.g. consulting for large companies) see huge issues with compliance whenever this happens. In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.
  - drewdevault 3y ago
    Note the careful use of private modifications as not requiring disclosure of the source code. You only have to include source in the very specific situation of building Redict and providing it in compiled form to customers directly. Like, if you give someone the ELF file. If you run it on their behalf as a cloud service or something you have no obligation to provide source, which is the most common commercial use-case of Redis. LGPL is a very well understood license, even in the EU, and is already in use for many projects that are widely depended on commercially. Consider ffmpeg as one prominent example, which is used by virtually all multimedia software in the industry. It is very easy to comply with the LGPL, and your legal department works for you, not the other way around.
    - frant-hartm 3y ago
      > legal department works for you, not the other way around. Not sure what planet you live on. Unless you are one of the execs, Legal (and other compliance departments like HR) work pretty much against you. They exist to protect the company and the exec team.
      - drewdevault 3y ago
        They exist to serve the bottom line, and if the bottom line is best served by evaluating and approving the LGPL license (a trivial task, as it is broadly understood and the compliance requirements are negligible for most users), then that's what they will do. And in any case, no one is categorically opposed to the LGPL. Unless you think that no one is using Linux in industry, given that it uses a stronger license (GPL), which is patently absurd.
        dani0854 3y ago
        > And in any case, no one is categorically opposed to the LGPL. That's not exactly true, take android as an example, which has a policy of "no GPL in user space", if I recall correctly. I do however believe that due to drivers and other things, GPL is beneficial in Linux kernel, but that rather an exception. And also Linux is GPLv2, which is a big difference to GPLv3 (and so to LGPLv3).
tormeh 3y ago
Most commercial projects can safely use any of the Redis forks, whether Redis itself, Redict or Valkey. For Redict, you have to provide the source code of Redict - and Redict only! - in the case that you distribute it to customers. Redis has harsher terms, but only if you provide Redis-as-a-service. If you aren't a cloud provider and you don't modify the code of your chosen Redis variant, this is all a big nothingburger and neither of the licenses impose any important restrictions on you. We desperately need all open questions regarding AGPL and SSPL to be clarified in court so this fearmongering can stop. It's really really bad for open source.
- Macha 3y ago
  > If you aren't a cloud provider and you don't modify the code of your chosen Redis variant, Or get hosted redis services from someone other than Redis Labs. That isn't fearmongering about the SSPL, it is literally the point of the SSPL.
  - tormeh 3y ago
    Sure, but that's left for the hosted service providers to figure out. No one can sue you for using AWSs offering.
- verdverm 3y ago
  Open source seems to be doing fine without the clarity. Even fields that have nothing to do with software are adopting the mindset. The movement only gains in steam
  - yunohn 3y ago
    Most popular OSS projects use Apache and MIT in my experience, precisely because GPLs are problematic for commercial usage and contributions from employed people.
    - drewdevault 3y ago
      This is a common misconception and source of fear/uncertainty/doubt regarding copyleft licenses. It's true that, the stronger the copyleft license, the more obligations it imposes on companies, and the AGPL is perhaps the most onerous of all and thus the least attractive to businesses. But, copyleft exists on a spectrum, and there are thousands of big-ticket FOSS projects that tens of thousands of businesses depend on and make use of that have a copyleft license. Linux itself is GPL, and pretty much everyone depends on it. The license for Redict is one of the weaker copyleft licenses and should not pose any onerous compliance obligations on the most common commercial use-cases for Redict.

CodeNest 3y ago

[dead]

gadders 3y ago

I don't get the point of this - people are upset that Redis is trying to make money from companies like AWS and Google?

drewdevault 3y ago
Substantial portions of Redis were written by AWS and Google. People are upset because Redis is a collaborative project with many people working on it and Redis Ltd wants the sole right to commercialize the work of an entire community. LWN has a good overview: https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/ https://lwn.net/SubscriberLink/966631/8bc9d155d4e2afb3/ Redis Ltd is only responsible for about 20% of the work.
- baq 3y ago
  Perhaps true but besides the point, actually - the same companies will happily take your code and make a saas offering out of it on their oligopolistic infrastructures, making it economically unviable to compete with. ...which, given LGPL, will be worse now as they'll simply not share their modifications because that's the legally safest option.
  - KingOfCoders 3y ago
    And well, why not? That is the idea. It's open source.
- sotillan 3y ago
  Yeah, I think a key point is that Salvatore Sanfilippo, the original developer, maintainer and principle contributor[1] for 11 years, was not a founder of Redis Labs. He joined as an employee in 2015 but resigned in 2020. Perhaps he has equity in Redis Labs, but it's not clear he stands to profit at all from this switch. [1] https://github.com/redis/redis/graphs/contributors https://github.com/redis/redis/graphs/contributors
- sanxiyn 3y ago
  AWS and Google contributed those under BSD license, being fully informed that Redis Ltd can commercialize like this. It makes perfect sense for AWS and Google to fork immediately after the switch, but for contributions before the switch, there is no basis for AWS and Google to complain Redis Ltd, either legally or morally.

yurytom 3y ago

What about Valkey? We have 2 big forks now

dewey 3y ago
This is directly addressed in the blog post: https://redict.io/posts/2024-04-03-redict-7.3.0-released/#why-redict https://redict.io/posts/2024-04-03-redict-7.3.0-released/#wh...
JoshTriplett 3y ago
Valkey has the support of various Redis developers who moved over, keeps the same license as the original Redis did, and stayed on GitHub to keep the workflow that Redis developers and contributors are used to, so I expect it'll end up winning out. GitHub is proprietary and not ideal, but when trying to get developers on board after a fork, using GitHub and using the same license as the original avoids spending innovation tokens / weirdness budget unnecessarily.
- drewdevault 3y ago
  Codeberg was chosen over other candidates because it has a workflow similar to GitHub, to ease the transition for the existing community. In my opinion, we're going through a big shake-up anyway and there's no better time than now to consider changes like this. We did discuss moving it to GitHub or another platform entirely, but as a community we decided to stay on Codeberg. Changing the license was an absolutely essential requirement, and this is a crucial time to evaluate and commit to that change. As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd, and a fork which doesn't fix that bug isn't addressing the underlying problem.
  - GrumpySloth 3y ago
    > As far as we're concerned, not being copyleft was a bug that was exploited by Redis Ltd Disclaimer: I don’t have anything against the relicensing to LGPL. I think it’s your right and I root for you. That said, correct me if I’m wrong, but, as far as I understand, what Redis Ltd did, they could do regardless of the license. Copyleft wouldn’t have stopped them, given the CLA. Moreover I wouldn’t call that exploitation. To people outside of Redis Ltd who don’t want to be Redis Ltd customers this move is indistinguishable from them just closing down business and stopping development of Redis. Would that be exploitation? Are they obliged to provide free work on Redis indefinitely? They can’t retroactively change the licence of previous versions of Redis, so they can’t actually take anything away. The existence of the 2 forks is proof of that.

dewey 3y ago

Time will tell if the version on Codeberg (https://codeberg.org/redict/redict https://codeberg.org/redict/redict) can compete with the fork on Github (https://github.com/valkey-io/valkey https://github.com/valkey-io/valkey) in terms of visibility and contributions.

forty 3y ago
Valkey is under the Linux foundation umbrella, and I assume will be developed by the same people who were previously making redis. I could not find who is behind predict.
- dewey 3y ago
  You can see it here: https://codeberg.org/org/redict/members https://codeberg.org/org/redict/members
- drewdevault 3y ago
  It's worth noting that the Linux Foundation is a commercial consortium and the companies behind Valkey contribute over $1M to its annual budget.
  - rmbyrro 3y ago
    > contribute over $1M to its annual budget That on top of developer hours dedicated to various projects, which are probably worth multiple millions.
    - deleted 3y ago
      [deleted]

qwertox 3y ago

I mostly use Redis in combination with RedisJSON, and RedisInsight is a nice way to check what data is stored. I'm only using it for a handful of small documents which mirror the state of some devices. These options (Redict, Valkey) don't seem to support JSON as a data type, so I'd like to know if there is some server specifically made for dealing with JSON documents. Something like a very lightweight MongoDB server which can be managed via a browser and where the data can be inserted/updated/removed via HTTP calls.

drewdevault 3y ago
Redict is binary compatible with Redis Modules, including RedisJSON, out of the box, so you can keep using it no problem.
cacois 3y ago
Lightweight is your problem here, I think, but I've used CouchDB successfully in similar situations. However, its not in-memory like Redis is.
- nurple 3y ago
  Big fan of couch, wish it was more popular. Its http interface basically removes the whole http translation layer of code most projects put in front of the db. For such a small need, you might also look at PouchDB. Inspired by couch but simplified to allow it to run in-browser.

8organicbits 3y ago

Being copyleft, Redict can merge any contributions to Valkey. However, Valkey cannot merge any of the Redict commits (unless the contributor actively dual licenses them). Being non-open source Redis can merge any contributions made to Valkey but not from Redict. So if you don't want your code to end up in Redis, contribute to Redict. Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease.

reconditerose 3y ago
As someone who has extensively worked on a Redis fork at AWS and worked with the company for 6 years, I wouldn't worry about Redis merging stuff from Valkey. We believe they refused a huge number of PRs because we believe it would have messed with their internal features. (We can't prove this, because they never discussed it publicly). One of the main reasons I started contributing to Redis was to help my team at AWS get out of the business of merging conflicts. > Interestingly, there have only been two commits from a single developer to the Redis repo in the last two weeks since the license change. A huge decrease. It's just a guy from Redis. It's not even one of the three former maintainers (Oran, Yossi, or Itamar). The number of open PRs is also dramatically down (it was around 550 when I last looked before the fork, since I've gotten a lot of notifications from old PRs of people refusing the CLA).

treprinum 3y ago

Why would any startup ever get idealistic again and release their product under open license when big boys can just fork it and destroy their business? I think the dual AGPL/commerical licensing will be the choice of anyone with still some idealism left.

marcinzm 3y ago
There's nothing idealistic involved. Startups want users more than they want revenue. Thus they open source it, use VC money to cover the loses and then eventually try to squeeze those users for money. Redis Labs also did not in any way make Redis. They came in later to exploit the already open source project for their own benefit.
- treprinum 3y ago
  Ok, I was mistaken then. I thought Redis Labs folks created Redis initially.
  - fmajid 3y ago
    No, they didn't, although they misleadingly claimed to be the "Home of Redis" for a number of years. Then they hired Salvatore Sanfilippo (antirez), the author of Redis, and eventually purchased the copyright from him. Very sleazy outfit that fully deserves all the scorn poured on them.
    - danielovichdk 3y ago
      If one sells a copyright to another, how can that be considered sleazy ? Someone made the sell - to make money I presume - and another bought it, to perhaps make more money ? Seems not that out of reach ? I don't understand the bitterness around this debate, it seems most people are frustated that they have to pay for something that was free, but at the same time, they probably made money from what was free. I totally understand, with todays mess of maintainers not getting paid in full, that at some point, someone wants money for their work. Be it a person, a company or you doesn't matter. But right has to be right. I think we will see a lot of this the next 10 years, simply because we cannot afford maintainers not detecting backdoors in a code-review from some bad actor.

Linda231 3y ago

[dead]

Linda231 3y ago

[dead]

rmbyrro 3y ago

I respect their choice of license. Totally agree they shouldn't let Redi$ take their work after what Redi$ have done. But still let any kind of project use it, including cloud vendors. Downside is that Valkey won't be able to use Redict code, though.

endisneigh 3y ago

I read the post and it’s not clear why it’s not MIT licensed. Why not allow attempts to “create proprietary distributions?” That’s what open source would allow, no? I honestly do not see this as being different than Redis. Do BSD or MIT and be done with it. It seems needlessly ideological. Everyone wants to call their stuff open source but have strings attached.

skywhopper 3y ago
Do you feel the same way about Linux and Git? Anyway, the Redict team are doing their thing and letting Redis and Valkey be. You’re the one insisting on Redict doing things the way you would like, so who exactly is being ideological?
- endisneigh 3y ago
  Isn’t Linux GPL? What’s the relevance? Edit: Linux was always GPL, Redis was not, so I don’t see the relevance.
  - ksec 3y ago
    Because "Everyone wants to call their stuff open source but have strings attached" implies GPL ( or CopyLeft, Non-BSD / MIT license ) have strings attached. So the parent was asking isn't Linux Open Source but with strings attached? And if so are you happy with Linux? Although I am assume what you meant was that Redis was originally a BSD / MIT, and re-licensing it to LGPL seems ideological. But I could be wrong.
    - endisneigh 3y ago
      Copyleft is a string. The default would be complete permissiveness. If someone gave you something the correct presumption would be that you can do as you like with it, unless - and what follows are strings, like copy left. It isn’t inherently bad, but it is what it is. My happiness with Linux is irrelevant because Linux to my knowledge was not re licensed to be more restrictive.

crabmusket 3y ago

Everyone's discussing the license and the hosting, but I think this is the truly interesting differentiator: > In technical terms, we are focusing on stability and long-term maintenance, and on achieving excellence within our current scope. We believe that Redict is near feature-complete and that it is more valuable to our users if we take a conservative stance to innovation and focus on long-term reliability instead. This is in part a choice we’ve made to distinguish ourselves from Valkey, whose commercial interests are able to invest more resources into developing more radical innovations, but also an acknowledgement of a cultural difference between our projects, in that the folks behind Redict place greater emphasis on software with a finite scope and ambitions towards long-term stability rather than focusing on long-term growth in scope and complexity. It'll be interesting to see what Valkey's future is with the maintainers having some lofty goals, and expressing frustration that they weren't able to move fast enough or be innovative enough under Redis. As a small-time user of Redis I kind of like the idea that I could just have what I've got now, but with a promise that someone's looking after it. I don't feel the need for millions of transactions per second, a timeseries database, etc.

reconditerose 3y ago
Hey, I am one of the maintainers of Valkey, I'll try to answer. I think there is a few things I would like to see in the mid to short term. We're trying to make a lot of the core datastructures more efficient (both in terms of memory and performance) as well as the main dictionary. Valkey 8.0 (or whatever first major version we have) will have lower overhead per key-value pair. Multithreading performance is nice, but as you mentioned most people don't need it. It gives folks a lot of runway if they need to scale but don't want to use clustering, and can also be a "quick fix" for certain types of P99 or higher latency spikes. Clustering is also really hard to use today, and a lot of the current folks want to fix that. It's a huge community pain point. Observability is another pain point I would like to improve. (Disclosure, I work at AWS as well) We see a lot of customers ask about "why did we see a performance issue", and Redis really doesn't provide a lot of introspection to diagnose those issues. Another big area, which maybe will work for redict, is we want better integration with other OSS projects, especially CNCF projects like envoy, open-telemetry, K8s. There are a lot of self-developed projects floating around, we're hoping we can pull all of this together to make a more cohesive project for people to use instead of what we see today. I think another big issue will be clients. I'm concerned Redis will try to inject a poison pill into the clients they own to make it so they can only talk to "official" Redis versions. Ultimately a small community will struggle to maintain a lot of clients, so I think we need a larger (and likely commercial) investment into keeping clients open. We will likely passively support redict with our clients, so they'll get that for free. We want to do all the cool feature stuff to (timeseries, JSON, bloom, RAG), but I would like to keep the core pretty clean.

pietroppeter 3y ago

I think what are seeing here is the true power of an open license. There are now two forks with different approaches and two dedicated and competent teams and we will see not only who wins, but if any or both win (for some definition of win).

Brian_K_White 3y ago
To me that's the big one, that even you an individual has the ultimate option to define "win" however you want. Not only are you not subject to the conflict of interest between users and sellers in a commercial product, you aren't even subject to the popularity contest tyranny of the majority in a non-commercial product. If someone takes the last open version of something and forks it and never does anything further to it and no one else ever uses it, but it does what they want, they win. They win at life no matter what anyone thinks about that fork.

soygem 3y ago

[flagged]

gigatexal 3y ago

Just to be 100% I can still use Redis for free in my projects in production so long as I don’t sell a hosted version of it right given this new Redis license?

dartos 3y ago
To be 100% you should email redis and/or ask a lawyer. Not randos on HN
drewdevault 3y ago
I agree with dartos, but I will state for the record that you can use Redict for free in production even if you do sell a hosted version of it.
Y-bar 3y ago
That is the stated intent and spirit of the new license terms, but as others have said, ask a lawyer to be 100% certain.

kerkeslager 3y ago

This is all fine and good, but the big question for me personally is when we can expect to see cloud providers (DigitalOcean and AWS are the ones I'm using) provide hosted versions of Redict OR Valkey with some sort of upgrade path from Redis. I'm a good full-stack developer and a mediocre server administrator, so self-managing hosting is usually not something I'd prefer to do.

hiccuphippo 3y ago
AWS has ElastiCache, which is compatible with current redis, but I wonder in which direction they'll go.

deleted 3y ago

[deleted]

sitkack 3y ago

I don't see much info on the governance of the project. What is the stance on incorporating Rust into the codebase?

drewdevault 3y ago
It's essentially a do-ocracy in practice, though we have discussed the possibility of putting together a foundation to steward it, particularly if we start to get money involved. There are currently five people who have admin rights with respect to their various competencies, and anyone who establishes trust with the community and gets stuff done will also be promoted to their level of competence, as it were. Though I hesitate to describe it like this, I think of "admin" more as a clerical role than an authoritarian one. You're good at code review? Everyone generally trusts you? Then merge rights are just a tool to help you do your work better. I don't think anyone is going to be very excited about introducing Rust unless there's a compelling reason to, but feel free to bring it up on the issue tracker for discussion and see if you can form a consensus on the matter with the rest of the community.
- sitkack 3y ago
  Great responses! I wish you the best of luck and when I am able to be involved with OSS again, I will gladly help out with Redict. I think the LGPL is a good choice. Areas where I would personally want to see Rust in a project like this, a) parsing and talking with the network b) extension mechanism moved to Wasm (Wasmtime for execution) but that plugins would be moved into a Wasm container. It would also be a nice property if the core of the project maintained a compile to Wasm compatibility so that Redict could be run everywhere.
  - drewdevault 3y ago
    Thanks! It would be great to have your help. I think your Rust/wasm goals are a little bit dramatic for the goals we established among ourselves, but by all means start a conversation about it. Good support for compile-to-wasm is probably something that we'd be down to have upstream, though.

caymanjim 3y ago

What's the track record of other projects that have gone too commercial and had their code forked like this? The only other example I can think of offhand is MySQL and MariaDB. I don't know what the market share of either is now. Do people still use MySQL? Does it generate profit for Oracle? I think Redis Ltd. is vastly overestimating the value of their product. Redis is incredibly popular, but the vast majority of users are just looking for a simple in-memory key-value store for lightweight database use cases, caching, etc. I've used it in some way in just about all my projects for the past ~15 years. The thing is, I don't care that it's Redis. I don't care about most of its features. I could have subbed in memcached or any number of other solutions. It would have been trivial and had no impact on my system. I have no doubt that there are some power users who need advanced features of Redis, but I also have no doubt that Redict will be better, and that there will be companies who provide commercial support for it. I'm just going to use Amazon ElastiCache for big projects, and continue not caring at all about what it is behind the scenes. And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it. I can't imagine a scenario where Redis Ltd. is relevant or profitable 10 years from now. Oracle can afford to lose money on MySQL forever, and treat it as a loss-leader for acquiring new Oracle DB customers or at least new MySQL service contracts. Redis Ltd. has one product and few people need support for it or care much about it vs. alternatives. Edit: Or Valkey instead of Redict; either way, which exemplifies the degree to which I don't care.

drewdevault 3y ago
Just passing by with a quick nit to pick: >And I'll s/redis/redict in my docker-compose.yml for small/personal projects, and that'll be the end of it FYI we're publishing to registry.redict.io, so s:redis:registry.redict.io/redict:g https://redict.io/docs/redis-compat/containers/ https://redict.io/docs/redis-compat/containers/ Not that it detracts from your point in any way :)
- zvr 3y ago
  THANK YOU, for making images based on scratch, rather than Debian or Alpine. It makes redistribution so much easier from a license compliance perspective. And double thanks for providing an SPDX document for the contents of the image.