Redis adds AGPLv3 while Valkey keeps BSD

Redis's decision to add AGPLv3 changes the licensing choice that helped create Valkey, but it does not undo the fork. In today's announcement, Redis offers an OSI-approved open-source option starting with Redis 8. Valkey continues under its own BSD license, with its own maintainers and technical decisions. Understanding the announcement requires keeping license terms separate from the development history of the two servers.

The Redis 8 license file describes a choice among RSALv2, SSPLv1 and AGPLv3. It also says Redis 7.2 and earlier releases retain their BSD terms. This is an additional option for the new release, with a different set of conditions from BSD. Calling it a restoration of the old license would obscure what a recipient can actually choose.

I prefer Valkey when Redis semantics are wanted, in part because it retains the permissive terms around which the ecosystem developed. Redis offering an open-source option is welcome. That change does not remove my reason to care about how a project makes decisions or which license accompanies future contributions.

The fork responded to a specific change

Redis's March 2024 licensing announcement moved future releases to RSALv2 or SSPLv1, starting with Redis 7.4. It explicitly said those alternatives were not OSI-approved. The company connected the decision to commercial use by cloud providers and to combining capabilities previously distributed through Redis Stack with the core server.

Those facts explain why source availability alone did not settle the disagreement. Users could still inspect code, but the conditions for using and providing that code had changed. A project built around permissive redistribution terms had adopted alternatives with different commercial and service-related obligations. The decision affected organizations that distribute or host the server as well as developers who call it.

The Linux Foundation's Valkey launch announcement, published on March 28, 2024, identifies Redis 7.2.4 as the development starting point. It commits to the BSD three-clause license and describes an open governance model. Valkey therefore began with both a code baseline and an institutional choice about continued development.

That baseline is relevant to the meaning of "upstream." Redis remains the original project's name and continues its own releases. Valkey's maintainers are developing an independent project from shared earlier code. A new Redis release does not automatically become Valkey's next release, just as a Redis licensing announcement does not amend Valkey's existing license file.

Open-source licenses can impose different obligations

The BSD terms shipped with Valkey 8.1.1 permit redistribution in source and binary forms, with or without modification. They require retaining the specified notices and disclaimers, and prohibit using copyright-holder or contributor names for endorsement without permission. Those conditions differ from a copyleft license's requirements concerning covered source code.

BSD's short list of conditions is a practical reason an infrastructure component can be easy to redistribute. The license file also includes the inherited Redis copyright notice alongside the Valkey contributors' notice. A fork preserves the obligations attached to the code it received. Adopting a new project name does not discard those notices or the permissions they describe.

The AGPLv3 text adds a network-interaction provision in section 13. When someone modifies the program, the modified version must offer users interacting with it remotely an opportunity to receive its corresponding source, under the conditions stated there. That is a specific obligation tied to a modified covered program and network interaction.

The wording matters because a broad claim that "every application using Redis must become open source" does not follow from that provision alone. The covered work, modifications and corresponding source need to be identified before discussing obligations. A protocol connection and a modification to the database server are different technical relationships, and a useful account of licensing should preserve those distinctions.

Conversely, the label "open source" does not make AGPLv3 interchangeable with BSD. Both can be open-source licenses while setting different conditions on modified works and redistribution. An organization whose distribution model suits BSD may need a separate assessment of AGPLv3. The engineering task is to record which code is being used and under which offered license, so that assessment addresses the actual artifact.

Governance determines how new code arrives

Valkey's governance document assigns oversight of technical and policy matters to its Technical Steering Committee. It identifies major decisions, including changes to core data structures and backward compatibility, as matters requiring a vote. The document also describes consensus and the voting process when consensus is unavailable.

These rules do something different from the license. A license grants permissions concerning code already distributed under its terms. Governance determines who can make project decisions and how those decisions proceed. A permissively licensed project still needs maintainers to choose changes, resolve disagreements and produce releases. Reading only its license cannot establish how that process operates.

The distinction also prevents an exaggerated conclusion about institutional guarantees. A governance document describes a process and allocates authority. It does not prove that every future technical decision will satisfy every user. Its value is that an interested contributor can inspect the decision mechanism and the responsibilities assigned to the people operating it.

The Valkey contribution guide requires a Developer Certificate of Origin sign-off. Contributors certify their right to submit the work under the indicated license or an appropriate permitted license. The guide asks for discussion before major semantic or architectural work begins, which connects contribution practice to the project's decision process.

This is relevant when assessing whether two related codebases can simply exchange changes. A shared ancestor does not establish the right to copy every later contribution under any desired license. The offered terms and the contributor's authority remain part of the process. Even a technically suitable change needs a lawful route into the receiving project and maintainers willing to support it.

Compatibility has a release-specific meaning

Valkey's 8.1 stable release notes describe compatibility with earlier Valkey releases and Redis OSS 7.2.4. That statement identifies a baseline which readers can use. It does not say that every new Redis 8 capability exists in Valkey, and it should not be extended into such a claim.

Compatibility can also refer to different things. An application may rely on command behavior, while an operator depends on persistence files or administrative tooling. Shared history helps explain continuity, but each claim still needs a defined version and behavior. Treating the projects as identical would make it harder to identify where an application begins relying on something developed after their shared baseline.

There is already concrete independent implementation work to consider. Valkey 8.1 includes a new hash table that embeds keys in value objects and preserves incremental rehashing. It changes how the server represents familiar data, with a stated saving for short string keys. Such a change can matter to capacity without creating an application-visible command difference.

That example shows why a comparison based only on a product name or license label misses relevant engineering. Identical command requests can exercise different allocation layouts in related releases. Conversely, a new command can require an application change even when both servers share much of their earlier implementation. Version-specific evidence is necessary for either kind of comparison.

Redis's announcement combines licensing with product changes, including integration of Redis Stack technologies and the introduction of vector sets. Those are Redis 8 decisions. Their presence in the same announcement as AGPLv3 does not distribute their implementation to Valkey under BSD or establish feature parity between the releases.

I see the useful outcome as a broader choice among explicitly different projects. Valkey's appeal remains its compatible starting point, permissive license and independent development process. Redis's additional license option changes the comparison, and it deserves an accurate account on its own terms.

For a deployment decision, the relevant artifact is a particular release with its accompanying license and implemented behavior. Redis 8's three-way choice and Valkey's BSD terms can be recorded separately, alongside the commands and operational facilities the application actually requires. That gives future maintainers enough information to distinguish a change in license selection from a change in server implementation.