Redis Licensing History and the Valkey Fork

Understand a piece of Redis history that has nothing to do with commands or data structures but that changes which binary you should actually install: Redis was BSD-licensed open source from its 2009 creation through 2023 (the era both source books in this module were written in); Redis Inc. relicensed it to a source-available dual license in March 2024, over cloud providers monetizing Redis without contributing back; the Linux Foundation launched a permissively-licensed fork called Valkey within eight days, backed by AWS, Google Cloud, and Oracle among others; and in May 2025 Redis Inc. reversed course and added the OSI-approved AGPLv3 as a licensing option for Redis 8. This concept has no book source at all — it is a licensing and governance history, not a technical mechanism, and every date and quote below is verified directly against Redis Inc.'s own blog posts, the Linux Foundation's own press release, and Valkey's own governance document rather than assumed from training knowledge, because getting a legal-history date wrong is worse than getting a command flag wrong.

• Choosing which binary to docker pull or apt install for a new project. "Redis" and "Valkey" are two different, protocol-compatible projects with two different licenses today, and the choice has to be made once, deliberately, rather than defaulted into by whichever tutorial was searched first.
• Explaining to a legal or procurement team why "Redis" shows up under two different license names in a dependency audit. A codebase built before March 2024 references BSD-licensed Redis; one built between March 2024 and May 2025 may reference RSALv2/SSPLv1-licensed Redis; one built since May 2025 can reference AGPLv3-licensed Redis — three different answers to "what license governs this dependency" depending on exactly when it was pulled in.
• Evaluating a managed Redis/Valkey offering from a cloud provider. Knowing that AWS ElastiCache, Google Cloud Memorystore, and Oracle's offerings moved toward Valkey specifically because of the 2024 relicensing explains why a given provider's "Redis-compatible" service is sometimes literally running Valkey under the hood.
• Deciding whether AGPLv3's network-copyleft terms are compatible with a product that embeds Redis and exposes it as part of a hosted service — a real question for anyone building a SaaS product on top of Redis 8 today, not a solved one.

2009-2023: BSD 3-Clause, the era both source books describe

Redis was created in 2009 by Salvatore Sanfilippo ("antirez") and released under the permissive BSD 3-Clause license from the start. That is the licensing reality both of this module's source books (2013 and 2015) were written against, and it is why neither book has anything to say about licensing at all — for the first fifteen years of Redis's existence, "open source" and "the license Redis ships under" were simply the same question with one answer. Redis Inc.'s own March 2024 announcement confirms the license and its own end date precisely: "Consequently, Redis will no longer be distributed under the three-clause Berkeley Software Distribution (BSD)," starting with Redis 7.4. Every release from 1.0 through 7.2 stayed BSD, and — per that same announcement's FAQ — "the license change is not retroactive," so all pre-7.4 source and releases remain BSD-licensed permanently, usable indefinitely under the original terms.

March 20, 2024: the move to dual RSALv2/SSPLv1

On March 20, 2024, Redis Inc. announced that Redis 7.4 and all future releases would ship under a dual license — the Redis Source Available License v2 (RSALv2) or the Server Side Public License v1 (SSPLv1) — instead of BSD. Redis Inc.'s own blog post is explicit that this is a deliberate exit from OSI-approved open source, not a rebrand: "we openly acknowledge that this change means Redis is no longer open source under the [OSI definition]," and the FAQ spells out the mechanics of the new restriction plainly: "RSALv2 is a permissive non-copyleft license... [that has] only two primary limitations. Under RSALv2, you may not: Commercialize the software or provide it to others as a managed service; and Remove or obscure any licensing, copyright, or other notices." SSPLv1, "based on the GNU Affero General Public License (AGPL)... requires that those making SSPL-licensed software available to third-parties... as part of a 'service' must release the source code for the entirety of the service."

Redis Inc.'s own stated rationale is squarely about cloud providers extracting value without reinvesting: "the majority of Redis' commercial sales are channeled through the largest cloud service providers, who commoditize Redis' investments and its open source community... Under the new license, cloud service providers hosting Redis offerings will no longer be permitted to use the source code of Redis free of charge." Rowan Trollope, Redis Inc.'s CEO, made the same point again a year later, in the blog post announcing the eventual reversal: "how do you keep innovating and investing in OSS projects when cloud providers reap the profits and control the infrastructure without proportional contributions back to the projects that they exploit?" — the identical complaint, restated as the reason the 2024 change happened in the first place.

The community reaction was immediate and negative enough that Redis Inc. itself later described the fallout in its own words: "This achieved our goal — AWS and Google now maintain their own fork — but the change hurt our relationship with the Redis community. SSPL is not truly open source because the Open Source Initiative clarified it lacks the requisites to be an OSI-approved license." That admission — from Redis Inc.'s own CEO, in Redis Inc.'s own blog — is as direct a confirmation of the community backlash as any third-party commentary could offer.

March 28, 2024: the Linux Foundation launches Valkey

Eight days after the relicensing announcement, on March 28, 2024, the Linux Foundation announced it would host Valkey, a permissively-licensed continuation of the pre-relicensing Redis codebase, forked from Redis 7.2.4 — the last BSD-licensed release. The Linux Foundation's own announcement states the license choice directly: Valkey would "keep the project available for use and distribution under the open source Berkeley Software Distribution (BSD) 3-clause license," and names its founding backers as Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson, and Snap Inc. — with more than fifty additional companies, including Alibaba, Tencent, Huawei, ByteDance, Percona, and Canonical, joining within weeks.

Valkey's governance is deliberately multi-vendor rather than single-company, by explicit written rule. Its GOVERNANCE.md states that "the TSC is responsible for oversight of all technical, project, approval, and policy matters for Valkey," and caps any one company's influence over that body directly: "At any time, no more than one third (1/3) of the TSC members may be employees, contractors, or representatives of the same organization or affiliated organizations." As of this writing, TSC members include representatives from Amazon, Google, Oracle, Tencent, Alibaba, and Ericsson — the same coalition of cloud and infrastructure companies that backed the fork at launch, now formally sharing technical control of it under Linux Foundation governance rather than any one vendor holding it.

May 2025: Redis Inc. adds AGPLv3 back

On May 1, 2025, Redis Inc. — again via a Rowan Trollope-authored blog post, timed to the Redis 8 general-availability release — announced that Redis would add the OSI-approved AGPLv3 license as a third licensing option alongside RSALv2 and SSPLv1, effective with Redis 8: "Adding the OSI-approved AGPL as an additional licensing option for Redis, starting with Redis 8 (available now)." The post ties the reversal to two concrete developments the company names outright. First, personnel: "Following our license change, in November of 2024 Salvatore Sanfillipo (antirez) decided to rejoin Redis as a developer evangelist... With guidance from Salvatore, our CTO, Benjamin Renaud, and our core developers, we have made some key decisions to improve Redis going forward" — crediting the original Redis author's return with driving the licensing reversal. Second, an implicit but clear acknowledgment of the fork's success: the same post that announces AGPLv3 also announces folding the formerly RSALv2/SSPLv1-only Redis Stack modules (JSON, Time Series, the Query Engine, probabilistic types, and the new Vector Sets type) directly into core Redis 8 under AGPLv3 — closing, in one release, both the licensing gap that drove the community to Valkey and the feature-fragmentation gap that had made "Redis" and "Redis Stack" two different downloads. The pattern — competitive pressure from a well-backed, protocol-compatible fork gaining real cloud-provider adoption, followed by a reversal that hands back the exact OSI-approved property the fork was created to guarantee — is the throughline connecting all three dates.

Note precisely what did not happen: Redis did not drop RSALv2/SSPLv1 and return to BSD. AGPLv3 was added as a third option; RSALv2 and SSPLv1 remain available choices for anyone who wants them. AGPLv3 is a strong copyleft, network-use-triggers-disclosure license — a materially different set of obligations than either BSD's near-total permissiveness or RSALv2's narrower anti-competitive restriction — so "Redis is open source again" is true in the OSI sense but does not mean "Redis is back to its original, most-permissive terms."

The decision this history creates, today

Two actively maintained, protocol-compatible, drop-in-compatible-with-each-other projects now exist, and picking between them is a genuine, still-live decision rather than one with an obviously correct answer:

• Redis, from Redis Inc., now licensed under a choice of AGPLv3 (OSI-approved), RSALv2, or SSPLv1. It is the project Salvatore Sanfilippo is directly involved with again, and it ships new capabilities first — Redis 8's Vector Sets data type, the folded-in Query Engine/JSON/Time Series/probabilistic modules, and the performance work described in the sibling redis-8-stack-in-core-json-search-vectorsets-timeseries concept all landed in Redis before any equivalent existed in Valkey.
• Valkey, from the Linux Foundation, licensed under permissive BSD 3-Clause, governed by a multi-vendor Technical Steering Committee with a hard one-third cap on any single company's representation, and backed operationally by the cloud providers most likely to run it at scale — AWS, Google Cloud, and Oracle chief among them. It trails Redis on the newest features by design: it is a continuation of the pre-relicensing codebase plus its own independent development, not a real-time mirror of everything Redis Inc. ships.

Neither answer is "correct" independent of context. An organization that cares primarily about license permissiveness, wants governance spread across multiple vendors instead of concentrated in one company, or is already running on a cloud provider's managed Valkey-based service has a straightforward case for Valkey. An organization that wants the newest data types and performance work on day one, or has commercial support needs that point toward Redis Inc. directly, has an equally straightforward case for Redis. The AGPLv3 option narrows the licensing gap between the two — both are now realistically describable as "open source" in the OSI sense — but it does not erase the governance difference (single company vs. multi-vendor TSC) or the feature-timing difference (first vs. following), and those two differences are what actually separates the two projects today.

• AGPLv3 is not a return to BSD, and the obligations differ in kind, not just degree. BSD 3-Clause imposes almost no conditions beyond attribution. AGPLv3 is a strong copyleft license whose distinguishing feature — network use counts as distribution — means offering AGPLv3-licensed Redis as part of a hosted service can trigger source-disclosure obligations that never applied under the original BSD terms. Treating "Redis added AGPLv3" as "Redis is permissive again" is a real, avoidable misreading of what changed.
• RSALv2 and SSPLv1 are still live options, not deprecated ones. Redis Inc.'s May 2025 announcement added AGPLv3; it did not remove the other two. A team consuming Redis today can still end up under RSALv2 or SSPLv1 depending on which license option a distributor or packager chose, so "Redis is open source now" needs a follow-up question — under which of the three licenses, specifically.
• Valkey trails Redis on features by structural design, not by accident. Redis Inc. controls Redis's roadmap and ships new capabilities into its own codebase first; Valkey's Technical Steering Committee — deliberately capped so no single company (including any of its cloud-provider backers) can dominate it — has to independently build or port equivalent functionality. Vector Sets, the newest native data type discussed in the sibling redis-8-stack-in-core-json-search-vectorsets-timeseries concept, is a concrete example of a Redis-first capability that a Valkey adopter should expect to wait for, if it arrives at all.
• "Drop-in compatible" is a moving target, not a permanent guarantee. Valkey forked from Redis 7.2.4 and has tracked protocol compatibility closely since, but the two codebases have now diverged for well over a year under independent governance. Compatibility that held at fork time is not a standing contract; it has to be re-verified against the specific versions actually in use, especially for newer Redis 8 features that Valkey may implement differently, later, or not at all.
• This is a fast-moving, adversarial-feeling history where today's snapshot can be tomorrow's outdated fact. Three licensing changes in fourteen months (BSD to dual-license in March 2024, the Valkey fork eight days later, AGPLv3 added in May 2025) is an unusually high rate of change for something as normally-static as a software license. Anyone making a Redis-vs-Valkey decision for a new project should re-check both projects' current license and roadmap status directly rather than relying on this history as a permanently frozen answer.