Problem
On March 20, 2024, Redis announced that, starting with Redis 7.4, they will no longer be releasing Redis under the 3clause BSD license but they would be rather be dual licensing under the Redis Source Available License and the Server Side Public License. The details are in https://redis.com/blog/redis-adopts-dual-source-available-licensing/
Neither of the 2 licenses above are Open Source licenses as per the OSI definition. In case it isn't obvious, in Redis they are acutely aware of that and even the naming of the licenses reflects that. The OSI has very clearly stated it for SSPL in https://opensource.org/blog/the-sspl-is-not-an-open-source-license and RSALv2 is in the same spirit anyway
Given the "Freedom and Open Source" Guiding Principle as stated in https://foundation.wikimedia.org/wiki/Resolution:Wikimedia_Foundation_Guiding_Principles
we need to figure out how to react/respond to this license change.
Timeline
We got time, even Debian sid has Redis 7.2 right now (https://packages.debian.org/sid/redis), which is released under the 3 clause BSD license. My expectation is that they will eventually drop Redis from the distribution though. A very rough estimation says anything between 2 and 4 years before we have to urgently deal with the problem.
Current usages
Production Realm
Currently there are apparently 3 main use cases of Redis in production
- Gitlab
- Redis Misc
- changeprop
- jobqueue
- api-gateway
- redisLockManager
- Netbox
- docker-registry
- Arc Lamp
- Wikimedia IDM (Bitu)
- Fr-tech queues
WMCS Realm
- Toolforge offers a Redis service
- Quarry
- redisLockManager in Beta cluster
Possible directions forward
Disclaimer
This task has been filed on the day following the announcement. As such, there are no clear paths forward and we need first to do some investigation. That being said, it isn't that difficult to discern the rough shape of the possible directions. I am not currently advocating for any, this is just a list and not even exhaustive.
Fork of Redis
We either expect someone to fork redis or fork it ourselves.
In the former case, this would be just a repetition of what happened with Elasticsearch and Opensearch and a path we 've been down before.
The latter case is a lot more involved and would require substantial investment on our side. This will be exacerbated by the fact that we would be, de facto, assuming that role of for a lot of people on the globe.
Emerging forks
- https://github.com/Snapchat/KeyDB - Multi-threaded fork of Redis based on Redis 6. BSD-3-Clause. Owned by Snapchat.
- https://codeberg.org/redict/redict - Based on the last open source version of Redis 7.2.4. LGPL-3.0-only. Started by Drew DeVault. Packaged in Debian: https://tracker.debian.org/pkg/redict
- https://github.com/valkey-io/valkey - Based on the last open source version of Redis 7.2.4. BSD-3-Clause. Started by former Redis contributor(s) and AWS employees. Supported by Linux Foundation.
Stop using Redis altogether
In this scenario, we evaluate all usages of Redis one-by-one, figuring out replacement solutions and eventually stop using Redis before the need to use versions past (and including) 7.4. There's many details on this one as some of the tools and code paths using Redis aren't controlled by the Movement (see Gitlab), others are abandoned and others are properly maintained.
Continue using Redis, accepting it's not Open Source anymore
This is arguably possible under the Guiding Principle per
As an organization, we strive to use open source tools over proprietary ones, although we use proprietary or closed tools (such as software, operating systems, etc.) where there is currently no open-source tool that will effectively meet our needs.
However, this includes the burden of proving that no open source tool that effectively meets our needs exists. It also includes the burden of avoiding critical dependencies on proprietary code or services for maintaining a largely functionally equivalent fork. which is expressively stated a paragraph above the quoted one.
I should note that in the case that a fork of Redis happens after we decide to go down some path that follows under this direction, we are effectively forced to fallback to scenarios that fall under the "Fork of Redis" direction.
Investigation
Before any plans are made to follow any of the rough directions outlined above, we 'll need to perform an evaluation of our usages of Redis.