Hi, On Sat, 31 May 2025 13:56:22 +0300 Adrian Bunk <bunk@debian.org> wrote: > On Fri, May 30, 2025 at 06:00:14PM -0700, Chris Lamb wrote: > > Adrian Bunk wrote: > > > > > Easiest for security support would be keeping Redis/trixie with > > > identical licence (and with a closer codebase) to Valkey, and > > > then treat Valkey as upstream for Redis/trixie security support. > > > > I see your point. I think we are simply comparing the subjective > > difference between being able to apply the same patch for Valkey for > > both Valkey and against the (old) version of Redis in trixie, versus > > applying a Valkey patch against Valkey and a Redis patch against Redis. > > The most important difference is whether it will be legal to apply the > Redis/trixie patch against Redis/bookworm. > > Until mid-2026 Debian does support bookworm, and Redis DSAs will usually > cover both. > > Can a person who has seen the Redis/trixie fix work on fixing Redis/bookworm > if Redis/trixie gets upgraded to 8.0? > That's a tricky legal question. Indeed, it is tricky. But from my (limited) understanding, legally, for Debian, it would not be a problem, since BSD 3-clause (redis 7) is compatible with AGPLv3 (redis 8). So backporting patches from redis 8 to redis 7 should be OK. The problem is that we will be dual licensing the software once we do that, and users may not be happy with this type of change in a stable release. For instance, if a hypothetical user applies non-free/private patches on top of the package and they receive an update which is dual licensed as mentioned, they would likely need to open their patches. Some companies have strict rules about using GPL and its variations (AGPLv3) in their products, we shouldn't blind side them and change licensing like that. I am not sure if there is any previous occurrence of a case like this before. If there is, please let us know what was the course of action. Apart from the legal side, I totally agree with Chris that maintaining redis 8 will be better for the maintainers and the users, who will have a newer version of the software available. I hope we can manage to introduce this new version in time for trixie! Otherwise, we will postpone this very same problem to the next release. Cheers, Lucas Kanashiro.
Attachment:
signature.asc
Description: This is a digitally signed message part