Valkey, the Redis fork and the BSD licence in practice

Valkey, the Redis fork and the BSD licence in practice

Valkey is a fork of Redis made in spring 2024 from the last release under the BSD licence, and it now runs under the Linux Foundation. The current version is 9.1.1, the licence file is called COPYING and sits on the unstable branch, and the server still reports a redis_version:7.2.4 field to clients. That last detail settles more than everything else combined.

Where Valkey came from

The story starts with a decision by the owner of Redis. The LICENSE.txt file at tag 7.4.0 in the redis/redis repository opens with a sentence saying that from 20 March 2024 the project moves to a dual licensing model for version 7.4 and subsequent releases: a choice between the Redis Source Available License v2 and the Server Side Public License v1. Neither is recognised as an open source licence by the body that issues such assessments.

The fork was taken from the last state before that change, meaning Redis OSS 7.2.4. That is not a guess but a value still written into the code. In src/version.h at tag 9.1.1 the constant REDIS_VERSION is set to 7.2.4 with a comment saying the value should never exceed 7.2.x. The first Valkey release carried the number 7.2.5 and its tag was created on 16 April 2024, less than a month after the Redis announcement.

The rest of the major release chronology runs as follows: 8.0.0 on 15 September 2024, 9.0.0 on 21 October 2025, 9.1.0 on 19 May 2026 and the patch release 9.1.1 tagged on 21 July 2026. The cadence is real rather than symbolic.

One thing surprises people on first contact with the repository. The project inherited the Redis branch naming convention: development happens on the unstable branch and there simply is no main. The address raw.githubusercontent.com/valkey-io/valkey/main/LICENSE returns 404 and that is correct behaviour rather than a failure.

The Valkey licence from three sources

Checking the licence from a single place leads you astray here, so I walked through three independent sources.

# Source 1: the file in the repository. Name and branch variants matter.
curl -sL -o /dev/null -w "%{http_code}\n" \
  https://raw.githubusercontent.com/valkey-io/valkey/main/LICENSE      # 404
curl -sL -o /dev/null -w "%{http_code}\n" \
  https://raw.githubusercontent.com/valkey-io/valkey/unstable/LICENSE  # 404
curl -sL -o /dev/null -w "%{http_code}\n" \
  https://raw.githubusercontent.com/valkey-io/valkey/unstable/COPYING  # 200

# Source 3: the artefact you actually download
curl -sL -o valkey.tar.gz \
  https://github.com/valkey-io/valkey/archive/refs/tags/9.1.1.tar.gz
tar tzf valkey.tar.gz | grep -iE "COPYING|LICEN"
tar xzOf valkey.tar.gz valkey-9.1.1/COPYING | head -5

The first source gives an unambiguous answer, provided you guess the file name. On the unstable branch the COPYING file holds thirty lines: a single BSD 3-Clause text with two copyright notices, one for Valkey contributors from 2024 onward and one for Redis Ltd covering 2006 to 2020. The names LICENSE, LICENSE.txt and LICENSE.md do not exist on any branch I checked.

The second source, the license field in a package registry, does not exist for the server, because Valkey is a C program and appears neither in npm nor in PyPI. The registries do cover the client libraries, and this is where something easy to miss during an audit shows up: the family does not share one licence. The iovalkey package at version 0.4.0 declares MIT, the valkey package from PyPI at version 6.1.1 also declares MIT, while @valkey/valkey-glide at version 2.5.1 and valkey-glide from PyPI declare Apache 2.0. The server itself is BSD 3-Clause. Three different licences in one ecosystem, all permissive, but with different obligations on distribution.

The third source, the contents of the distributed artefact, confirms the declarations and adds a detail. The archive of tag 9.1.1 weighs 4,391,242 bytes, contains 143 .c files under src, so actual code, and carries COPYING at the root. That file under the tag looks different from the one on the unstable branch: it consists of two sections headed # License 1 and # License 2, where the first carries an explicit SPDX-License-Identifier: BSD-3-Clause and the Valkey notice, and the second is the same BSD text with the Redis Ltd notice. The legal content is identical in both variants, only the layout differs. Beyond that, the archive holds separate licence files for bundled dependencies: deps/jemalloc/COPYING, deps/libvalkey/COPYING, deps/hdr_histogram/LICENSE.txt, deps/fpconv/LICENSE.txt and deps/gtest-parallel/LICENSE. In a compliance audit those, not the top level file, generate most of the work.

Two caveats. The official address download.valkey.io/releases/valkey-9.1.1.tar.gz answered with code 403 to a plain curl request, so I fetched the artefact from the tag archive on GitHub. I did not compare checksums of the two packages.

What is happening to Redis

This part of the story has three stages and mixing them up leads to bad conclusions in a conversation with your legal department.

The first stage is March 2024 and the dual model. The second is the Redis 8 release, which added a third option. The LICENSE.txt file on the unstable branch in redis/redis opens today with a sentence about a tri-licensing model and names RSALv2, SSPLv1 and the GNU Affero General Public License v3 explicitly. The same sentence stands in the file at tag 8.0.0, so AGPL arrived with version 8 rather than later. The same file adds that Redis Open Source 7.2 and prior releases remain under BSD 3-Clause.

The state today: the newest release on the list is 8.10.1 from 17 August 2026, and the REDIS_VERSION constant on the unstable branch reads 8.9.241, a development marker. The first page of the release list contains only version 8 lines: 8.10.1, 8.8.2, 8.6.6, 8.4.6 and 8.2.9. No release from the 7.2 line appears there.

What that means for someone running Redis in production today. If you sit on 7.2 or earlier, that particular code stays on BSD forever and nobody can take it away, but new releases on that line are not appearing. If you upgrade to 8.x, you accept one of three licences of your own choosing. AGPLv3 is recognised as an open licence and for most uses changes nothing: the obligations fire when you make a modified server available to others, not when your application talks to it over a network socket. Trouble starts in two arrangements. The first is a company with a rule rejecting the entire copyleft family without examining details, because then you are left with RSALv2 or SSPLv1, terms even harder to accept. The second is when you want to sell a managed service built on that code yourself, which RSALv2 forbids outright.

Valkey sidesteps both arrangements, because BSD 3-Clause imposes no such conditions. That is the real reason it exists, rather than any performance argument.

Protocol, client and data file compatibility

Now to the practical question: is migration an address change in a config file, or a week of work.

valkey-cli INFO server | head -6
# server_name:valkey
# valkey_version:9.1.1
# redis_version:7.2.4

The server prints three fields. redis_version with the value 7.2.4 exists so that existing client libraries, which check the version before enabling a given feature, do not fall over at startup. The consequence cuts both ways: a Redis client will work, but any tool inferring server capabilities from that field sees seven years of development less than it actually gets. The Valkey version is read from valkey_version, and the engine kind from server_name.

At the installation level compatibility is even more literal. The src/Makefile sets USE_REDIS_SYMLINKS?=yes, so make install creates symbolic links under the old names by default for the server, the redis-cli shell, the redis-benchmark tool, both file checking tools and the sentinel mode. The Makefile also honours the REDIS_CFLAGS and REDIS_LDFLAGS variables. The src directory carries a redismodule.h header, so modules written against the old API compile without name changes.

Data files are more involved and this is the one place where migration can hurt.

/* src/rdb.h in Valkey 9.1.1 */
#define RDB_VERSION 80

static const int RDB_VERSION_MAP[][2] = {
    {11, 0x070200},
    {80, 0x090000},
};

#define RDB_FOREIGN_VERSION_MIN 12
#define RDB_FOREIGN_VERSION_MAX 79

The comment above that block states the intent plainly: RDB 11 is the last open source Redis format, used by Valkey 7.x and 8.x, and numbers from 12 to 79 are reserved for Redis formats incompatible with Valkey. From version 9.0 Valkey began numbering at 80 to avoid collisions. Redis meanwhile reached RDB 15 on the unstable branch, while Redis 7.2.5 still wrote RDB 11.

The row with the dependency needs explaining. The valkey.conf file carries an option rdb-version-check strict with permitted values strict and relaxed. The default strict mode rejects both formats in the foreign range and versions higher than its own. The relaxed mode lets it attempt to load such a file on a best effort basis, aborting the moment unknown information appears. The setting also applies to replication and the RESTORE command. That last note matters, because the payload returned by DUMP carries the format version number without a magic string, so moving data with those two commands falls under the same rules as loading a file.

The practical conclusion runs like this. Moving from Redis 7.2 to Valkey is painless in both directions, because both sides speak RDB 11. Moving from Redis 8.x to Valkey 9.x requires a conscious decision about relaxed mode or a data transfer at the application level. Going back from Valkey 9.x to Redis through an RDB file will not work, because Redis does not know format 80. That is not a closed door, but it is a door you come back through differently from how you went in.

What Valkey added after the fork

After two years the divergence is visible in the configuration file itself.

# valkey.conf, selected options absent from Redis 7.2
dual-channel-replication-enabled no
hide-user-data-from-log yes
rdb-version-check strict
# io-threads 4
# availability-zone "zone-name"
# import-mode no
# rdma-port 6379
# rdma-rx-size 1048576

dual-channel-replication-enabled splits a replica full sync across two connections, so the child process can send the snapshot without loading the replication buffer on the primary node. availability-zone lets you label the node's availability zone, which matters when steering reads in clusters stretched across zones. hide-user-data-from-log strips user values from crash messages. Options prefixed with rdma support transport over remote direct memory access, a feature with no counterpart in the line the fork came from.

On the command side the clearest addition is atomic slot migration in a cluster, introduced in 9.0.0. The definition files under src/commands give a since field of 9.0.0 for CLUSTER MIGRATESLOTS and CLUSTER GETSLOTMIGRATIONS, and CLUSTER CANCELSLOTMIGRATIONS sits alongside them. Previously moving slots was a sequence of steps driven from outside, so an interruption halfway through left the cluster in an intermediate state.

Commands operating on field lifetimes inside hashes have also diverged. HGETEX and HSETEX carry a since field of 9.0.0 in Valkey, and HGETDEL appeared in 9.1.0. The HEXPIRE family exists in both projects, but names and signatures of newer commands have to be checked per engine rather than assumed common.

Release 9.1.0 additionally brought a cluster bus traffic metric counted in bytes and reduced latency spikes during hash table rehashing through incremental page release. Release 9.1.1 closed three vulnerabilities registered as CVE-2026-23479, CVE-2026-25243 and CVE-2026-23631, covering client unblocking, the RESTORE command and a full sync during script execution respectively.

Where to get Valkey

# container image
docker run --rm valkey/valkey:9.1.1
docker run --rm valkey/valkey:9.1.1-alpine

# Debian and derivatives, version depends on the distribution release
apt-get install valkey-server

# building from source, with the old style symlinks
make && make install
# make install USE_REDIS_SYMLINKS=no  # without the redis-* symlinks

Container images are published under the valkey/valkey repository on Docker Hub, with trixie and alpine variants alongside the default. The project download page currently lists three lines: 9.1.1, 8.1.9 and 7.2.14. Note that this is not an official image in the Docker Hub sense, since the library/valkey namespace does not exist. In practice the difference concerns the review and signing process, not the contents.

In Debian the package is called valkey. The sources.debian.org interface reports version 9.1.1-1 in the unstable branch, 8.1.4+dfsg1-2 in testing, 8.1.1+dfsg1-3+deb13u2 in the stable release and 8.0.1+dfsg1-1~bpo12+1 in backports for the previous stable release. So if you install from a stable distribution repository you get the 8.1 line rather than 9.1, and the RDB format difference described above does not touch you.

On the managed service side the picture is incomplete and I deliberately give no prices. The ElastiCache pricing page at Amazon Web Services does not render without JavaScript: in the raw HTML the places holding numbers contain template markers rather than values. The page copy does mention Valkey and claims a lower price and a lower minimum data threshold compared with the Redis compatible variant, but since the table cannot be read without a browser, I am not reproducing those percentages as confirmed. The MemoryDB description in the same site's navigation speaks of compatibility with Valkey and with Redis OSS. Beyond that, there are Memorystore for Valkey documentation pages in Google Cloud, Valkey database documentation at DigitalOcean and a Valkey product page at Aiven. Check version and region coverage with each provider, because it changes faster than this text.

The same story played out in another category and is worth knowing, because the pattern is identical. OpenBao is a fork of HashiCorp Vault, a secrets management system, created after HashiCorp moved its products to the Business Source License. The resemblance runs down to the detail: the OpenBao licence file opens with the notice "Copyright (c) 2015 HashiCorp, Inc.", exactly as the COPYING file here preserves the Redis Ltd. notice, because the predecessor’s licence requires it. The last Vault release under an open licence was 1.14; from 1.15 the licence file carries a BSL header.

Common mistakes

The first mistake is looking for a LICENSE file on the main branch and concluding from the 404 that the project has no licence. Dependency audit tools that only query canonical names can flag Valkey as unlicensed. The right address is COPYING on the unstable branch or under any release tag.

The second is assuming that because the server is BSD, the whole family is too. The valkey-glide driver is Apache 2.0 in both registries where I checked it, while iovalkey and the Python valkey package are MIT. Each needs its own entry on a dependency licence list.

The third is inferring server capabilities from the redis_version field. The value 7.2.4 is pinned there permanently and will never change, no matter how far development goes. Code that enables newer commands based on that field will never enable them.

The fourth is treating migration as reversible through a data file. Up to Valkey 8.x it is, from Valkey 9.x it is not, because format 80 is out of reach for Redis. Before you switch production, check which Valkey line your package manager actually installs.

The fifth is skipping the licences of bundled dependencies. The source archive contains five separate licence files under deps, and in a formal audit those take most of the time rather than the top level file.

The sixth is rejecting Redis 8 reflexively because of AGPL. For an application that merely connects to the server over the network and does not modify it, that licence imposes no obligations. If you choose Valkey, do it for a reason you can name, such as company policy or your cloud provider's offering, rather than out of general unease.

When Valkey is not worth it

The ecosystem of material is younger. Tutorials, forum posts and answers about a specific error message overwhelmingly concern Redis and have to be translated by hand. File names, default paths and system service names differ enough that copying a command from a guide without reading it ends in a mistake.

Some client libraries and operational tools still assume Redis. They usually work, because the protocol is the same, but messages and metric fields talk about Redis, which makes life harder for whoever is on call at three in the morning. Tools that check the server version before enabling a feature will see 7.2.4.

With managed services the choice is often narrower than for Redis, especially outside the largest providers. If your hosting platform offers a single in memory engine and it is not Valkey, the licence question stops being your problem, because the provider resolves it.

If you are after durable storage rather than an in memory layer, the question is not about this engine at all. For a relational model with transactions you go to PostgreSQL, for columnar analytics to ClickHouse, and for full text search to Elasticsearch. Valkey and Redis solve a different problem: access to data structures in a fraction of a millisecond, accepting that the data fits in working memory.

FAQ

Will an existing Redis client work with Valkey unchanged?

Yes, provided the client does not gate anything on the server version. The protocol is the same, and the redis_version field in the INFO reply holds 7.2.4 precisely so that version checking libraries do not refuse the connection. You change an address in the configuration and nothing else. If your code reads redis_version in order to enable a newer command, though, it will see a value that never rises.

Can I move data from Redis 8 to Valkey 9 through an RDB file?

Not in the default configuration. Redis 8 writes an RDB format in the numbering range Valkey reserves as foreign, and the default rdb-version-check strict setting rejects such files. The relaxed value lets it try, aborting the moment an unknown structure appears. For data that is a cache anyway, starting an empty instance and letting it refill is often simpler.

What licence is Valkey under?

BSD 3-Clause. The text sits in the COPYING file on the unstable branch and under every release tag, with an explicit SPDX-License-Identifier: BSD-3-Clause in the tagged variant. The client libraries carry their own licences, though: valkey-glide is Apache 2.0, while iovalkey and the Python valkey package are MIT.

Has Redis returned to an open licence?

Partly. From Redis 8 the licence is tri-fold and AGPLv3 is among the options, which is recognised as open, so formally that choice exists. It is not a return to BSD, and the two remaining options, RSALv2 and SSPLv1, are not open. Redis 7.2 and earlier stay on BSD.

Is Valkey available as a managed service?

There are product pages and documentation at several providers, including Amazon Web Services, Google Cloud, DigitalOcean and Aiven. I give no prices, because the ElastiCache pricing page does not render without JavaScript and its raw HTML contains template markers instead of numbers. Check available versions and regions directly with the provider.

Is it worth migrating if I run Redis 7.2?

From a licensing standpoint you do not have to, because that version stays on BSD. The reason to move is rather that new releases on that line are not coming out, so security fixes have to be sourced elsewhere. Valkey in the 8.x line writes the same RDB 11 format, so a step in that direction is as technically simple as it gets. If you run the deployment yourself behind a reverse proxy such as Caddy or on a panel like Coolify or Dokploy, the change comes down to swapping an image and a service name.

Primary sources: the valkey-io/valkey repository, the Valkey download page and the LICENSE.txt file in the Redis repository.