[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1106871: unblock: redis/5:8.0.0-2



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


Reply to: