Impact of Redis licence change on KeyDB

[dceravigupta]

Just saw that Redis is moving to different licence starting version 7.4 and wondering what would be the impact of it on future releases of KeyDB?

https://redis.com/blog/redis-adopts-dual-source-available-licensing/

[JohnSully]

This project will remain with its original licensing.

KeyDB is currently based off Redis 6 primarily because of a lack of features that we needed from 7. However if we have enough time I do want to sync to the last true open source release of Redis.

[JohnSully]

As a followup there is renewed interest in the project given the license change.

KeyDB is used heavily at Snap serving >100 million QPS workloads. However we use the project primarily for set/get in cluster mode so most of my work is focussed on this. We are doing new work in FLASH and getting that to production readiness, that work is ongoing in the async_flash branch. A new release will be posted when that work is finished.

We have obviously fallen behind in dealing with the issue count here and would welcome community support in tackling this if anyone is interested in contributing.

[vwbusguy]

However if we have enough time I do want to sync to the last true open source release of Redis.

This is definitely a concern as Fedora ships redis-7, so the migration from redis to KeyDB would be a downgrade.

This development list discussion for Fedora is relevant: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/XVFFKU2NYB2Q3BQUYNANSDNE4VCJQ6KF/

[JohnSully]

@vwbusguy The Fedora community should understand that Redis labs was a unicorn company dedicated solely to Redis. While Snap is quite large as well they are obviously primarily focussed on the snapchat app not KeyDB. If the community wants to replace packages of Redis with KeyDB they need to understand this.

When I first joined Snap I thought I was going to be able to handle everything the same as before which was naive. It led to broken promises, so this time around I want to be very upfront with the community. As mentioned here and elsewhere I do welcome more maintainers if anyone else is willing to give their time to help support this.

[vwbusguy]

When I first joined Snap I thought I was going to be able to handle everything the same as before which was naive. It led to broken promises, so this time around I want to be very upfront with the community. As mentioned here and elsewhere I do welcome more maintainers if anyone else is willing to give their time to help support this.

Absolutely. I want to be clear that I'm also not speaking on behalf of the entire Fedora community here. That said, I appreciate your candor here and it's very relatable. I'm certainly happy to ask around Fedora about pitching in on this. I'm sure there are other OSS groups and Linux distros that might be willing to engage as well.

To that end, there's ongoing work right now to get KeyDB into Fedora and EPEL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2270592

[dceravigupta]

Seems like Amazon is going down the path of forking Redis and a placeholder repo is already in place.

Another Redis fork created by one of the core member of Redis.

https://twitter.com/reconditerose/status/1771037984001032224?t=OE3tXhO0TfXE3NwvAJbpJA&s=19

Repo:
https://github.com/madolson/placeholderkv

[vwbusguy]

It's not as much a problem of having a v7 upstream to rebase to, as I understand it, but rather the actual rebasing work that needs to be done. As in, someone brave/willing enough to rebase it on a BSD licensed v7 source and submit a Pull Request for it.

[JohnSully]

I am in discussions to potentially add maintainers and better align the code base to Redis 7.

If this bears fruit I will post updates here.

[Hisoka-J]

I am in discussions to potentially add maintainers and better align the code base to Redis 7.

If this bears fruit I will post updates here.

I'm concerned about whether KeyDB will continue to maintain compatibility with Redis 7.4 and later versions at the API level, such as user commands and management commands. I believe this is a crucial issue for me to continue using KeyDB. Because if there's incompatibility at the API level, it would increase the development complexity for our R&D personnel.

[JohnSully]

We definitely won't have direct source level compatibility anymore, since the upstream code is license incompatible.

This is a good thing because we had to make a ton of contortions to keep the code mergeable. Even then merges were bug prone and painful.

I can't promise we will reimplement every Redis proprietary feature but we will ensure we don't wantonly break compatibility. Most people use pre existing Redis clients and we would expect to maintain compatibility with those clients.

[vwbusguy]

This is a pretty common story right now - forgejo breaking with gitea, opensearch (formerly opendistro) with elastic, etc. Never underestimate the power of the open source community when driven by spite from a company that's done them wrong 😄. If we want KeyDB to continue to work with Nextcloud, web frameworks, chatbots, etc., we'll make it work. I am grateful for the work done here in KeyDB am looking forward to better things to come from it than redis 7.4+ cross-compatibility, in ways that both benefit SnapChat and the rest of the world. Thanks, John et al!

[5455230]

We definitely won't have direct source level compatibility anymore, since the upstream code is license incompatible.

This is a good thing because we had to make a ton of contortions to keep the code mergeable. Even then merges were bug prone and painful.

I can't promise we will reimplement every Redis proprietary feature but we will ensure we don't wantonly break compatibility. Most people use pre existing Redis clients and we would expect to maintain compatibility with those clients.

历史的包袱不应该过于沉重,走出自己的路很重要.