Redis AGPLv3 Implications
In May 2025 Redis added AGPLv3 as a third license option, restoring OSI-compliant open source status for Redis 8.0+. The change closed one chapter of the license saga and opened a new question: who can actually use Redis under AGPL, and where does Valkey still fit?
What AGPLv3 actually says
The GNU Affero General Public License version 3 is GPLv3 with an additional section 13 that addresses the "SaaS loophole." Under GPLv3, if you distribute a modified version of GPL software, you must make the source available. But running a modified version on a server and offering access over a network is not "distribution" in the legal sense, so the GPL's source-disclosure requirement does not apply.
AGPLv3 closes that gap. Section 13 says: if you modify the AGPL software and make the modified version available to users over a network, you must offer those users access to the corresponding source code. The mechanism is usually a link in the application's footer or an "About" page pointing to a public repository with the modifications.
Crucially, AGPLv3 only triggers on modification. If you run unmodified AGPL software, you have no source-disclosure obligation because there is no modified source to disclose. The license also has scope limitations: only the AGPL-licensed component itself is covered; if you use AGPL Redis as a backing store for your application, the application code is not "derived from" Redis in the copyleft sense and remains under whatever license you choose.
What it means in practice for Redis
Redis 8.0+ users who pick the AGPLv3 license option can: (1) run unmodified Redis on their own infrastructure for any purpose, including commercial SaaS, with no source-disclosure obligation; (2) modify Redis for internal use without disclosing the modifications, as long as the modified version is not offered to external users over a network; (3) modify Redis and offer the modified version externally, in which case the modifications must be published under AGPLv3.
For 95% of Redis users, the practical obligation is zero. They run stock Redis as their cache or session store, never modify the binary, and the AGPL section 13 clause is dormant. The pip install / brew install / apt install / docker run experience is unchanged from BSD-era Redis.
The 5% of users for whom AGPLv3 has real implications: cloud providers running managed-Redis services where they have made modifications (these companies typically have separate commercial agreements with Redis Inc. anyway), and companies building Redis-derived products. For the latter group, AGPLv3 is uncomfortable: any modifications they ship as part of their product become AGPL-licensed and must be published.
Why corporate legal teams remain wary
Despite the relatively narrow scope of AGPLv3's source-disclosure clause, many corporate legal teams have blanket policies prohibiting AGPL software from the codebase. The reasons are usually about risk, not about specific obligations: AGPL is unfamiliar, the boundaries are uncertain, accidental triggering of the network clause has unclear consequences, and the legal cost of analysing every Redis deployment is higher than just using something else.
This is particularly common in commercial software companies (vendors who ship software products to customers) where any AGPL component in the supply chain raises difficult questions about what derived works look like. The conservative position is to avoid AGPL entirely. Software-as-a-service companies have a marginally easier time because their users do not typically receive software, only API responses, but the policies are usually company-wide rather than service-specific.
The Valkey alternative addresses this concern by being BSD-3 with no copyleft of any flavour. For corporate legal teams that have a blanket no-AGPL policy, Valkey is the cleaner choice and does not require litigating the exact scope of section 13. The trade-off is being on a slightly newer fork (less battle-testing in some specific deployment scenarios) and not getting Redis 8.0 features like vector sets.
The decision rubric
You are probably fine with Redis under AGPLv3 if: you run unmodified Redis from official sources; you use Redis as a backing store for an application that does not embed or redistribute Redis itself; you are willing to publish any modifications you do make to Redis under AGPL; your legal team is comfortable with AGPL in general.
You should use Valkey or accept the SSPL / RSALv2 path if: your legal team has a blanket no-AGPL policy; you are building a commercial software product that embeds Redis; you are operating a managed-Redis service yourself; you cannot rule out future Redis modifications that you would not want to publish; you simply prefer the operational simplicity of a BSD store with no copyleft obligations.
For new projects in 2026 the realistic default is Valkey or managed Redis on a cloud provider where the licensing question is the provider's problem. Self-hosted Redis under AGPL is a legitimate choice for teams that have done the legal analysis and are comfortable with it; for everyone else the path of least resistance avoids the AGPL question entirely.
FAQ
What is AGPLv3?
GNU Affero General Public License version 3, an OSI-approved open source license. It is GPLv3 plus a network clause: if you modify the AGPLv3 software and provide it as a network service, you must make the modified source available to the users of that service. Designed to close the SaaS loophole in GPL.
Can my company use Redis 8.0 under AGPLv3?
Probably yes if you use Redis unmodified as a database for your application. The AGPLv3 network clause only triggers if you modify Redis and offer the modified version as a service. Using stock Redis as a backing store for your SaaS does not trigger it. Many corporate legal teams remain cautious about AGPLv3 for reasons that are more about license unfamiliarity than actual obligation.
What if I do modify Redis?
Then yes, if you offer the modified version as a network service, AGPLv3 requires you publish those modifications. This is the clause that prevents cloud providers from running modified Redis as a paid service without contributing back. For most application teams the question is hypothetical because they do not modify Redis.
Is Redis OSI-approved open source now?
Yes, because AGPLv3 is OSI-approved. The OSI did not recognise SSPL or RSALv2 as open source. With AGPLv3 added as an option in May 2025, Redis can be redistributed under an OSI-approved license again. The other two options (SSPL, RSALv2) remain available for licensees who prefer them.
Why is Valkey still relevant?
AGPLv3 is not BSD. Many commercial product companies have legal-team policies that prohibit AGPL across the codebase entirely, even for non-modified use, because the consequences of accidental triggering of the network-copyleft clause are uncertain. Valkey is BSD-3, full stop, no copyleft, and that simplicity is what some legal teams require.