Change Details

# 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](https://opensource.org/osd). 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](https://wikitech.wikimedia.org/wiki/Redis#Cluster_redis_gitlab) * [Redis Misc](https://wikitech.wikimedia.org/wiki/Redis) ** changeprop ** jobqueue ** api-gateway ** redisLockManager ** Netbox ** docker-registry * [Arc Lamp](https://wikitech.wikimedia.org/wiki/Arc_Lamp) ## WMCS Realm TBD # 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. ## 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.

# 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](https://opensource.org/osd). 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](https://wikitech.wikimedia.org/wiki/Redis#Cluster_redis_gitlab) * [Redis Misc](https://wikitech.wikimedia.org/wiki/Redis) ** changeprop ** jobqueue ** api-gateway ** redisLockManager ** Netbox ** docker-registry * [Arc Lamp](https://wikitech.wikimedia.org/wiki/Arc_Lamp) * Wikimedia IDM (Bitu) ## WMCS Realm TBD # 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. ## 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.