Redis module: new default package, which fork to adopt?

Development
1

While in NixOS 24.05 we can still stick to the BSD-licensed Redis 7.2, this will be the last Redis release track licensed under a FLOSS license.

So for the next NixOS release we should switch the Redis module default package to one of its compatible forks. I’d like to discuss here which of them we want to adopt as the recommended (thus default) one.

There are mainly 3 contestants, all of them claiming to be drop-in replacements for Redis at least at the connection API level:

Valkey

https://valkey.io/

main perk: backed by the Linux foundation and several large companies from the industry

Redict

main perk: relicensed under Copyleft to make the scenario that happened to Redis impossible, focus on stability

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, […]
We will happily pull useful changes from software with permissive licenses, such as Valkey, to improve Redict; such is the value of permissive software and the key advantage of free software generally. However, we will do so at a more conservative pace

source

KeyDB

main perk: higher performance due to multi-threading

There’s already a nixpkgs issue proposing to switch the Redis module default package to Valkey, but I’d like to discuss the alternatives first before doing that switch.

After all, there’s also still the possibility of defining no default at all and require users to explicitly make a decision, as we do for the mysql module.

Personally, I am really intrigued by the license-backed attempt of sustainable development that Redict has adopted. But by not having not too much insight into the technical inner workings of Redis so far, I lack the expertise for making a well-versed decision in these aspects and welcome any substantial opinions and considerations on which default to adopt.

7 Likes
2

At this time I’m also slightly leaning towards Valkey, since it seems to be the most alive continuation of the original Redis code base. The redict repo hasn’t seen any activity in the last month, which probably makes it the weakest choice.

Keydb sounds interesting, but it is a different implementation and people would have to test if it is really a drop-in replacement as claimed.

3 Likes
3

I would want to look at where the Valkey project wants to be in the near future. Forks, especially ambitious ones, diverge faster from the original than fork which focus on stability, like Redict does.
I haven’t looked into Valkey much, so my somewhat uninformed opinion would be: Use Redict as the default package for the Redis module, because it will stay close to what Redis was when it was still FOSS.
Package Valkey separately with it’s own module and the explicit intend of deprecating the Redis module should it not prove useful / necessary in the foreseeable future.

2 Likes
4

I like the general sentiment, but for the case of Valkey I have neither found any existing plans to deviate from Redis compatibility for now, but also no explicit promises or compatibility roadmaps. So I don’t see the imminent danger of Valkey becoming incompatible soon – but also no guarantees in the opposite direction.

Both Valkey and redict for now strieve for compatibility with the Redis branch they’ve forked off, 7.2.4.
Redict explicitly stresses

Redict is broadly compatible with Redis®1 OSS 7.2.4 and earlier, and functions as a drop-in replacement. Redict is not compatible with any changes from Redis® SAL 7.3.0 and later.

So the interesting thing will be whether the changes in proprietary Redis from 7.3 on will be significant, whether applications using Redis are going to rely on this (unlikely for FLOSS, but developers of proprietary applications might just not care too much), and whether one of the fork will try to incorporate these changes as well.

5

Shouldn’t redis module default still be redis?

That is what people expect when using the “redis” module.

If other implementations forked of 7.2.4 differ from redis, I would rather think that a new module is a better option.

3 Likes
6

fwiw libmysqlclient is actually mariadb and mysql is an alias that points to pkgs.mariadb, so this is nothing new with forks.

2 Likes
7

From UX perspective: I would agree.
From fork perspective: we don’t give appropriate value to the fork.
From legal perspective: hope Redis Corp won’t sue us for installing whatever as Redis, as Mozilla did with Debian.

8

Disclaimer: IANAL and certainly not a trademark lawyer (though I heard it pays well)

Redis has a trademark and a policy for it: Redis TRADEMARK GUIDELINES - Redis Documentation

Here are the interesting sections for us:

For avoidance of any doubt, the open source Redis software combined with, or integrated into, any other software program, including but not limited to automation software for offering Redis as a cloud service or orchestration software for offering Redis in containers is considered “modified” Redis software and does not entitle you to use the Mark or the Logo, except in a case of nominative use, as described below.

This is relevant for NixOS as I could see it classified as both “automation software for offering Redis as a cloud service” and “orchestration software for offering Redis in containers” (nixos-containers).

In Nixpkgs, we do slightly modify it using two patches, so that might also count as a “modified” version. It might count as modified anyways because we’re building from source.

Continuing on to nominative use which would be the only thing allowing us to use the TM:

  • c. Nominative Use: Trademark law permits third parties the use of a mark to identify the trademark holder’s product or service so long as such use is not likely to cause unnecessary consumer or public confusion. This is referred to as a nominative or fair use. When you distribute, or offer an altered, modified or combined copy of the Software, such as in the case of a cloud service or a container service, you may engage in “nominative use” of the Mark, but this does not allow you to use the Logo.

I don’t think we’re currently causing any grand confusion as we distribute and orchestrate a rather plain Redis.

We’re now venturing into territory where we might cause confusion and could therefore be infringing on Redis’ trademark though.

A simple alias of i.e. pkgs.redis = pkgs.valkey would be confusing enough to infringe on the TM IMHO. We should not do that.

Same with the module; simply making service.redis use some other Redis API implementation could infringe on their TM. We might be able to get away with making it an alias but with a warning (i.e. mkRenamedOptionModule).

There are further details on using the term “Redis” we should take note of when writing descriptions of the new packages and modules’ APIs:

  • d. Examples of Nominative Use:
  • i. Offering an XYZ software, which is an altered, modified or combined copy of the open source Redis software, including but not limited to offering Redis as a cloud service or as a container service, and while fully complying with the open source Redis API - you may only name it “XYZ for Redis™” or state that “XYZ software is compatible with the Redis™ API” No other term or description of your software is allowed.
  • ii. Offering an ABC application, which uses an altered, modified or combined copy of the open source Redis software as a data source, including but not limited to using Redis as a cloud service or a container service, and while the modified Redis fully complies with the open source Redis API - you may only state that “ABC application is using XYZ for Redis™”, or “ABC application is using a software which is compatible with the Redis™ API”. No other term or description of your application is allowed.

There’s also this though which is a bit trickier:

  • iii. If, however, the offered XYZ software, or service based thereof, or application ABC uses an altered, modified or combined copy of the open source Redis software that does not fully comply with the open source Redis API - you may not use the Mark and Logo at all.

This excludes implementations of subsets of the Redis API but I’m not sure whether it excludes supersets such as KeyDB. A module with services.redis.package = pkgs.keydb might infringe.
Other implementations may also become incompatible with the Redis API in the future too though.

Also note that all of this may change now that Redis’ enshittification has set in.

I think the safest option would be to create a new generic module for all the redis-compatible services that has a generic name and accepts all of the redis-compatible packages.

The Redis package itself should remain as-is and merely be marked as problematic (knownVulns etc.) as soon as it smells sufficiently dead. Perhaps the unfree version could be packaged too.

9 Likes