redis: 7.2.7 -> 7.4.2

[ghost]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[Ma27]

Needs an update of the license metadata, 7.4 seems to be using SSPL already, making the package unfree.

[Ma27]

AFAIU bsd3 was replaced with sspl(&rsal): https://redis.io/blog/redis-adopts-dual-source-available-licensing/

[ghost]

there is no rsal
https://github.com/NixOS/nixpkgs/blob/7850571d67c4ccfb0a34598480cc002276b3c72e/lib/licenses.nix

[NickCao]

Shall we also switch to valkey, as other distributions have done.

[Ma27]

Personally, I'd be in favor. But then again, I don't maintain either.

[ghost]

Valkey already exists as a package and it's not redis if it's supposed to be a hard fork. Switching to a less maintained fork doesn't sound like the best idea to me, but maybe that's because I don't see a problem with their licensing. Big companies should not be able to just profit off of FLOSS software and not give back anything.
Will rebase this after #400776

[Ma27]

I think the idea would be to drop redis and do redis = valkey; basically.
Btw, is valkey (still) a drop-in replacement? I.e. can I continue to use data dumped to disk?

Anyways, prior art: https://lists.archlinux.org/archives/list/[email protected]/thread/3XYVFXCBFJPEMLAOAGPRUPLJX7UQ3QB4/
regarding sspl: https://ssplisbad.com/

Keep in mind that SSPL is a non-free license, so there's no way around having to build Redis by yourself (instead of Hydra) from 7.4.

Switching to a less maintained fork

Also, valkey is backed by the Linux foundation. What makes you think it's less maintained?

Anyways, CCing @berdario @globin

[ghost]

Keep in mind that SSPL is a non-free license, so there's no way around having to build Redis by yourself

That's fine

valkey is backed by the Linux foundation. What makes you think it's less maintained?

We'll have to see how maintained it stays. Look at freenginx, openbao, yuzu and such projects. They never get the momentum to be a viable fork and be developed as the original project.

regarding sspl: https://ssplisbad.com/

hmmm, maybe sfl would have been a better choice, but who can talk to the redis developers to reconsider their licensing...

[Ma27]

We'll have to see how maintained it stays

To be clear, this is nothing new: the entire thing happened >a year ago, we just stayed on Redis 7.2 with the old license so far.
And since then, these forks exist.
See also https://discourse.nixos.org/t/redis-module-new-default-package-which-fork-to-adopt/45395

[Foxboron]

They never get the momentum to be a viable fork and be developed as the original project.

Fwiw, until antirez was back on board, valkey was far more active and had a more diverse community then the redis project. The comparisons to the other recent switcharoo-forks are not really apt. Just look at the insights month-by-month on each project.

[dtomvan]

There's an open RFC addressing this exact point: NixOS/rfcs#185

They even mention another SSPL software, MongoDB. You might want to check it out amd/or give your two cents.

[ghost]

So how does it work now?
https://redis.io/blog/agplv3/
https://github.com/redis/redis/blob/d65102861f51af48241f607afa678c4c2a0f894c/LICENSE.txt
Do we put all three or just AGPLv3?

[dtomvan]

Wow, that took a turn. I guess they saw the userbase leaking out...

In the agplv3 PR, "your choice of [RSAL/SSPL/AGPLv3]" is constantly mentioned. However, in licenses.nix it is said that SSPL is just an unfree variant of AGPL. So I think it's fine to just call it AGPLv3, since it's an OR relation with the other licenses. They do however still have a CLA: https://cla-assistant.io/redis/redis so that should probably be kept in mind.

We cannot do that yet though, as apparently 8.0 isn't out yet.

[ghost]

Force pushing without the commits to later add new ones closes the PR automatically without an option to re-open.
Too bad you can't rebase on github web.

[Ma27]

In redis/redis#13997, "your choice of [RSAL/SSPL/AGPLv3]" is constantly mentioned. However, in licenses.nix it is said that SSPL is just an unfree variant of AGPL

I agree with this: AGPL is considered to be open-source (and apart from the discrimination thing, SSPL's added clause leaves up too much legal uncertainty). So, fine by me to keep Redis and upgrade to 8.0.

[wolfgangwalther]

Force pushing without the commits to later add new ones closes the PR automatically without an option to re-open.

That only happens when you close the PR first, then force-push to the branch. Then you can't re-open. Just don't close the PR, but force-push to it anyway.