The Redis protocol uses TCP connections, pretty much the perfect case for AGPL which deals with "interacting with it remotely through a computer network" etc. https://www.gnu.org/licenses/agpl.html

Sure, interpretation varies on what kind of interactions with what software cause what obligations, but imagine how much case law and clarity you can have with a license 10 years younger.

So why aren't they simply re-licensing under AGPL? That's what I would do.

> So why aren't they simply re-licensing under AGPL? That's what I would do.

Because they want money from certain downstream commercial uses (or to block them so that they can monopolize those services), not to force people to release any modifications when they sell, e.g., hosted Redis services.

That why dual licensing exists. AGPL or commercial license. Sidekiq does that [0].

[0]: https://sidekiq.org/products/pro.html

Dual licensing doesn't stop anything that AGPL doesn't stop if downstream users are fine with the AGPL. It only helps monetize those users that are not willing to pay money to get out of AGPL requirements. So, if the problem is big cloud vendors selling services around AGPL software (which it expressly is) while complying with AGPL requirements, AGPL with a proprietary alternative doesn't solve anything.

You need a license which expressly prohibits the use at issue unless a deal involving payment is made, hence, the Commons Clause.

That might make existing users/contributors motivated enough to make fork, with the code before the relicensing. If the major Redis-as-Service providers would stick with that version, it might end up being the defacto standard Redis. This is always a possibility with FOSS, but probably way less likely with this added clause to only some modules.