Redis and AGPL: the 2025 reversal explained

For years Redis shipped under a permissive open license that placed almost no conditions on use. That made it one of the most widely deployed data tools in production, sitting in caches, queues, and session stores across nearly every industry. When the license changed, the question for enterprises was not abstract. It touched software already running in critical paths. The later addition of the GNU AGPL changed the picture again, which is why a clear timeline matters more than any single headline.

The 2024 move to source available terms

As of March 2024, Redis moved from its permissive open license to a dual model under the Redis Source Available License version 2 and the Server Side Public License. Source available is not the same as open source. The code remained public and readable, but use conditions now sat on top of it, aimed primarily at parties offering Redis as a managed service to others. Neither the Redis Source Available License nor the Server Side Public License is approved by the Open Source Initiative. For most internal deployments the change did not prohibit use, but it ended the era in which Redis carried no license conditions worth tracking, and it prompted a serious reaction from the community.

The Valkey fork and the pressure that followed

The response was swift. Maintainers and cloud providers backed a community fork, Valkey, kept under a permissive open license and governed in the open. Valkey gave teams a way to keep the Redis programming model without accepting the new source available terms, and its momentum made clear that a meaningful part of the user base would not simply follow the relicense. That pressure is the backdrop to what happened next. A project that loses its community to a fork loses the network effects that made it valuable, and the reversal that followed should be read with that dynamic in mind.

The 2025 reversal: adding the GNU AGPL

As of 2025, Redis added the GNU AGPL version 3 as an open license option for new releases, alongside the existing source available terms. This is the reversal. The AGPL is approved by the Open Source Initiative, so the project once again offers a genuine open source path, not only a source available one. For some teams this resolves the core objection to the 2024 change. It is important to be precise about what was added. Redis did not return to its original permissive license. It added a strong copyleft license. An offering can now be taken under the AGPL or under the source available terms, and which one governs a given deployment depends on the version and how it was obtained. Confirm the current terms for your version with the vendor and your counsel, since this remains a fast moving area.

Why the AGPL is not a clean all clear

The AGPL is open source, which is real progress, but it is strong copyleft with a network use provision. That provision extends source disclosure obligations to software made available to users over a network, not only to software that is distributed. For an enterprise running Redis purely as an internal cache, the obligations are usually limited. For a company that offers Redis backed functionality to its own customers over a network, the AGPL can reach further than the permissive license ever did. The trade is therefore not strictly better in every direction. The license posture moved from source available with competitive restrictions to open source with copyleft obligations, and the right read for you depends entirely on how you deploy. For the underlying mechanics, see our glossary entry on what a source available license means.

What to do about Redis and AGPL in your estate

Start by mapping the versions of Redis you run and how each was obtained, because the governing license follows the version, not the project name. Separate internal use from any deployment that exposes Redis functionality to external users over a network, since that distinction drives the AGPL analysis. Then weigh your options deliberately. Staying on an older permissively licensed version, adopting the AGPL release, taking the source available terms, or migrating to Valkey are all on the table, and each carries a different mix of obligation, cost, and operational effort. Bring the genuinely uncertain cases to your counsel before you decide. For the broader pattern, read our pillar on Redis and Elastic database licensing, and for adjacent reading see whether your Elasticsearch use is affected, assessing database license exposure in production, and vector database licensing risk to watch.