Valkey, fork Redisa i praktyka licencji BSD

Valkey, fork Redisa i praktyka licencji BSD

Valkey to rozwidlenie Redisa wykonane wiosną 2024 roku z ostatniego wydania na licencji BSD, prowadzone dziś pod skrzydłami Linux Foundation. Bieżąca wersja to 9.1.1, plik licencyjny nazywa się COPYING i leży na gałęzi unstable, a serwer wciąż raportuje klientom pole redis_version:7.2.4. Ten ostatni szczegół rozstrzyga więcej niż cała reszta.

Skąd wziął się Valkey

Historia zaczyna się od decyzji właściciela Redisa. Plik LICENSE.txt pod tagiem 7.4.0 w repozytorium redis/redis otwiera się zdaniem, że od 20 marca 2024 roku projekt przechodzi na model podwójnego licencjonowania dla wersji 7.4 i późniejszych: do wyboru Redis Source Available License v2 albo Server Side Public License v1. Żadna z nich nie jest uznawana za licencję otwartego oprogramowania przez organizację, która takie oceny wydaje.

Fork powstał z ostatniego stanu sprzed tej zmiany, czyli z Redisa OSS 7.2.4. To nie jest domysł, tylko wartość zapisana w kodzie do dziś. W pliku src/version.h pod tagiem 9.1.1 stoi stała REDIS_VERSION ustawiona na 7.2.4 z komentarzem mówiącym, że ta wartość nigdy nie powinna przekroczyć 7.2.x. Pierwsze wydanie Valkeya nosiło numer 7.2.5 i tag powstał 16 kwietnia 2024 roku, niecały miesiąc po ogłoszeniu Redisa.

Dalsza chronologia wydań głównych wygląda tak: 8.0.0 z 15 września 2024 roku, 9.0.0 z 21 października 2025 roku, 9.1.0 z 19 maja 2026 roku i poprawkowe 9.1.1 z tagiem z 21 lipca 2026 roku. Tempo jest więc realne, a nie symboliczne.

Jedna rzecz zaskakuje przy pierwszym kontakcie z repozytorium. Projekt odziedziczył po Redisie konwencję nazewnictwa gałęzi: rozwój idzie na gałęzi unstable, gałęzi main po prostu nie ma. Adres raw.githubusercontent.com/valkey-io/valkey/main/LICENSE zwraca 404 i to jest poprawne zachowanie, a nie awaria.

Licencja Valkeya z trzech źródeł

Sprawdzenie licencji z jednego miejsca prowadzi tu na manowce, więc przeszedłem przez trzy niezależne źródła.

# Źródło 1: plik w repozytorium. Warianty nazwy i gałęzi mają znaczenie.
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

# Źródło 3: artefakt, który realnie pobierasz
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

Źródło pierwsze daje jednoznaczną odpowiedź, o ile trafisz w nazwę pliku. Na gałęzi unstable plik COPYING zawiera trzydzieści linii: pojedynczy tekst BSD 3-Clause z dwiema notami autorskimi, jedną dla współtwórców Valkeya od 2024 roku i drugą dla Redis Ltd za lata 2006 do 2020. Nazwy LICENSE, LICENSE.txt i LICENSE.md nie istnieją na żadnej ze sprawdzonych gałęzi.

Źródło drugie, czyli pole license w rejestrze pakietów, w przypadku serwera nie istnieje, bo Valkey jest programem w C i nie ma go ani w npm, ani w PyPI. Rejestry mówią natomiast o bibliotekach klienckich i tu pojawia się rzecz, którą łatwo przeoczyć przy audycie: rodzina nie ma jednej licencji. Pakiet iovalkey w wersji 0.4.0 deklaruje MIT, pakiet valkey z PyPI w wersji 6.1.1 również MIT, natomiast @valkey/valkey-glide w wersji 2.5.1 oraz valkey-glide z PyPI deklarują Apache 2.0. Sam serwer jest na BSD 3-Clause. Trzy różne licencje w jednym ekosystemie, wszystkie permisywne, ale o różnych obowiązkach przy dystrybucji.

Źródło trzecie, czyli zawartość dystrybuowanego artefaktu, potwierdza deklaracje i dorzuca szczegół. Archiwum tagu 9.1.1 waży 4 391 242 bajty, zawiera 143 pliki .c w katalogu src, a więc realny kod, i ma COPYING w katalogu głównym. Ten plik pod tagiem wygląda inaczej niż na gałęzi unstable: składa się z dwóch sekcji zatytułowanych # License 1 i # License 2, przy czym pierwsza ma jawny identyfikator SPDX-License-Identifier: BSD-3-Clause i notę Valkeya, a druga to ten sam tekst BSD z notą Redis Ltd. Treść prawna jest identyczna w obu wariantach, różni się układ. Poza tym w archiwum leżą osobne pliki licencyjne zależności wbudowanych: deps/jemalloc/COPYING, deps/libvalkey/COPYING, deps/hdr_histogram/LICENSE.txt, deps/fpconv/LICENSE.txt oraz deps/gtest-parallel/LICENSE. Przy audycie zgodności to one, a nie plik główny, generują większość pracy.

Dwa zastrzeżenia. Oficjalny adres download.valkey.io/releases/valkey-9.1.1.tar.gz odpowiedział kodem 403 na zwykłe zapytanie curl, więc artefakt pobrałem z archiwum tagu na GitHubie. Nie porównywałem sum kontrolnych obu paczek.

Co dzieje się z Redisem

Ta część historii ma trzy etapy i pomylenie ich prowadzi do złych wniosków przy rozmowie z działem prawnym.

Pierwszy etap to marzec 2024 i model podwójny. Drugi to wydanie Redisa 8, w którym doszła trzecia opcja. Plik LICENSE.txt na gałęzi unstable w redis/redis otwiera się dziś zdaniem o modelu potrójnym i wylicza wprost RSALv2, SSPLv1 oraz GNU Affero General Public License v3. To samo zdanie stoi w pliku pod tagiem 8.0.0, więc AGPL pojawiła się razem z ósemką, a nie później. Ten sam plik dodaje, że Redis Open Source w wersji 7.2 i wcześniejszych pozostaje na BSD 3-Clause.

Stan na dziś: najnowsze wydanie na liście to 8.10.1 z 17 sierpnia 2026 roku, a stała REDIS_VERSION na gałęzi unstable ma wartość 8.9.241, czyli oznaczenie stanu rozwojowego. Pierwsza strona listy wydań zawiera wyłącznie linie ósemkowe: 8.10.1, 8.8.2, 8.6.6, 8.4.6 i 8.2.9. Nie widać tam wydania z linii 7.2.

Co to znaczy dla kogoś, kto ma dziś Redisa w produkcji. Jeśli stoisz na 7.2 lub starszym, ten konkretny kod zostaje na BSD na zawsze i nikt Ci tego nie odbierze, ale nowych wydań na tej linii nie widać. Jeśli aktualizujesz do 8.x, przyjmujesz jedną z trzech licencji według własnego wyboru. AGPLv3 jest uznawana za licencję otwartą i dla większości zastosowań nie zmienia niczego: obowiązki uruchamiają się wtedy, gdy udostępniasz zmodyfikowaną wersję serwera innym, a nie wtedy, gdy Twoja aplikacja łączy się z nim przez gniazdo sieciowe. Problem zaczyna się w dwóch układach. Pierwszy to firma z regułą odrzucającą całą rodzinę licencji copyleft bez wnikania w szczegóły, bo wtedy zostają Ci RSALv2 albo SSPLv1, czyli warunki jeszcze trudniejsze do przyjęcia. Drugi to sytuacja, w której sam chcesz sprzedawać usługę zarządzaną opartą o ten kod, bo RSALv2 tego zabrania wprost.

Valkey omija oba te układy, bo BSD 3-Clause nie stawia takich warunków. To jest realny powód jego istnienia, a nie kwestia wydajności.

Zgodność protokołu, klientów i plików danych

Tu przechodzimy do pytania praktycznego: czy migracja to zmiana adresu w konfiguracji, czy projekt na tydzień.

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

Serwer wypisuje trzy pola. redis_version z wartością 7.2.4 istnieje po to, żeby istniejące biblioteki klienckie, które sprawdzają wersję przed włączeniem danej funkcji, nie wywróciły się na starcie. Konsekwencja jest dwustronna: klient Redisa zadziała, ale każde narzędzie wnioskujące o możliwościach serwera z tego pola zobaczy siedem lat rozwoju mniej, niż faktycznie dostaje. Wersję Valkeya czyta się z pola valkey_version, a rodzaj silnika z pola server_name.

Na poziomie instalacji zgodność jest jeszcze bardziej dosłowna. W pliku src/Makefile stoi USE_REDIS_SYMLINKS?=yes, więc make install domyślnie tworzy dowiązania symboliczne o dawnych nazwach dla serwera, powłoki redis-cli, narzędzia redis-benchmark, obu narzędzi sprawdzających pliki oraz dla trybu sentinel. Makefile honoruje też zmienne REDIS_CFLAGS i REDIS_LDFLAGS. W katalogu src leży plik nagłówkowy redismodule.h, więc moduły pisane pod dawne API kompilują się bez zmian nazw.

Z plikami danych sprawa jest bardziej złożona i to jedyne miejsce, gdzie migracja potrafi zaboleć.

/* src/rdb.h w 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

Komentarz nad tym blokiem tłumaczy zamiar wprost: RDB 11 to ostatni format Redisa na licencji otwartej, używany przez Valkeya 7.x i 8.x, a numery od 12 do 79 są zarezerwowane dla formatów Redisa niezgodnych z Valkeyem. Od wersji 9.0 Valkey zaczął numerować od 80, żeby uniknąć kolizji. Redis w tym czasie doszedł do RDB 15 na gałęzi unstable, przy czym Redis 7.2.5 pisał jeszcze RDB 11.

Wiersz z zależnością wymaga wyjaśnienia. W pliku valkey.conf stoi opcja rdb-version-check strict z dopuszczalnymi wartościami strict i relaxed. Domyślny tryb strict odrzuca zarówno formaty z zakresu obcego, jak i wersje wyższe od własnej. Tryb relaxed pozwala spróbować wczytać taki plik na zasadzie najlepszych starań, przy czym wczytywanie przerywa się w momencie napotkania nieznanej informacji. Ustawienie dotyczy również replikacji i polecenia RESTORE. Ta ostatnia uwaga jest istotna, bo ładunek zwracany przez DUMP niesie numer wersji formatu bez łańcucha magicznego, więc przenoszenie danych parami poleceń podlega tym samym regułom co wczytanie pliku.

Praktyczny wniosek brzmi tak. Przejście z Redisa 7.2 na Valkeya jest bezbolesne w obie strony, bo obie strony mówią RDB 11. Przejście z Redisa 8.x na Valkeya 9.x wymaga świadomej decyzji o trybie relaxed albo przeniesienia danych na poziomie aplikacji. Powrót z Valkeya 9.x do Redisa przez plik RDB nie zadziała, bo Redis nie zna formatu 80. To nie jest zamknięte drzwi, ale to jest drzwi, przez które wraca się inaczej, niż się weszło.

Co Valkey dołożył po rozwidleniu

Po dwóch latach rozejście się funkcji jest już widoczne w pliku konfiguracyjnym.

# valkey.conf, wybrane opcje nieobecne w Redisie 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 rozdziela pełną synchronizację repliki na dwa połączenia, dzięki czemu proces potomny może wysyłać migawkę bez obciążania bufora replikacji na węźle nadrzędnym. availability-zone pozwala oznaczyć strefę dostępności węzła, co ma znaczenie przy kierowaniu odczytów w klastrach rozciągniętych między strefami. hide-user-data-from-log usuwa wartości użytkownika z komunikatów awaryjnych. Opcje z przedrostkiem rdma obsługują transport przez bezpośredni dostęp do pamięci zdalnej, co jest funkcją bez odpowiednika w linii, z której fork wyszedł.

Po stronie poleceń najwyraźniejszym dodatkiem jest atomowa migracja slotów w klastrze, wprowadzona w 9.0.0. Pliki definicji w katalogu src/commands podają pole since równe 9.0.0 dla CLUSTER MIGRATESLOTS i CLUSTER GETSLOTMIGRATIONS, a obok leży CLUSTER CANCELSLOTMIGRATIONS. Wcześniej przenoszenie slotów było sekwencją kroków sterowaną z zewnątrz, więc przerwanie w połowie zostawiało klaster w stanie pośrednim.

Polecenia operujące na czasie życia pól w mapach mieszających też się rozjechały. HGETEX i HSETEX mają w Valkeyu pole since równe 9.0.0, a HGETDEL pojawił się w 9.1.0. Rodzina HEXPIRE istnieje w obu projektach, ale nazwy i sygnatury nowszych poleceń trzeba sprawdzać osobno dla każdego silnika, zamiast zakładać, że są wspólne.

Wydanie 9.1.0 przyniosło poza tym metrykę ruchu magistrali klastra liczoną w bajtach oraz ograniczenie skoków opóźnień podczas przebudowy tablicy mieszającej przez przyrostowe zwalnianie stron. Wydanie 9.1.1 domknęło trzy podatności zarejestrowane jako CVE-2026-23479, CVE-2026-25243 i CVE-2026-23631, dotyczące odpowiednio odblokowywania klienta, polecenia RESTORE oraz pełnej synchronizacji w trakcie wykonywania skryptu.

Skąd wziąć Valkeya

# obraz kontenera
docker run --rm valkey/valkey:9.1.1
docker run --rm valkey/valkey:9.1.1-alpine

# Debian i pochodne, wersja zależy od wydania dystrybucji
apt-get install valkey-server

# kompilacja ze źródeł, z dowiązaniami o dawnych nazwach
make && make install
# make install USE_REDIS_SYMLINKS=no  # bez dowiązań redis-*

Obrazy kontenerów są publikowane w repozytorium valkey/valkey na Docker Hubie, z wariantami trixie i alpine obok domyślnego. Strona pobrania projektu wymienia dziś trzy linie: 9.1.1, 8.1.9 oraz 7.2.14. Warto odnotować, że nie jest to obraz oficjalny w rozumieniu Docker Huba, bo przestrzeń library/valkey nie istnieje. W praktyce różnica dotyczy procesu przeglądu i podpisu, a nie zawartości.

W Debianie pakiet nazywa się valkey. Interfejs sources.debian.org podaje wersję 9.1.1-1 w gałęzi niestabilnej, 8.1.4+dfsg1-2 w gałęzi testowej, 8.1.1+dfsg1-3+deb13u2 w wydaniu stabilnym oraz 8.0.1+dfsg1-1~bpo12+1 w portach wstecznych dla poprzedniego wydania stabilnego. Jeśli więc instalujesz z repozytorium dystrybucji stabilnej, dostaniesz linię 8.1, a nie 9.1, i różnica formatu RDB opisana wyżej Cię nie dotknie.

Po stronie usług zarządzanych obraz jest niepełny i celowo nie podaję tu cen. Strona cennika ElastiCache w Amazon Web Services nie renderuje się bez JavaScriptu: w surowym HTML w miejscach z liczbami stoją znaczniki szablonu, a nie wartości. Sam tekst tej strony wymienia Valkeya i deklaruje niższą cenę oraz niższy próg minimalnej ilości danych względem wariantu zgodnego z Redisem, ale skoro tabeli nie da się odczytać bez przeglądarki, nie przepisuję tych procentów jako potwierdzonych. Opis usługi MemoryDB w nawigacji tej samej witryny mówi o zgodności z Valkeyem i z Redisem OSS. Poza tym istnieją strony dokumentacji Memorystore dla Valkeya w Google Cloud, dokumentacja bazy Valkey w DigitalOcean oraz strona produktowa Valkeya w Aiven. Zakres wersji i regionów u każdego dostawcy sprawdź u niego, bo zmienia się szybciej niż ten tekst.

Ta sama historia rozegrała się w innej kategorii i warto ją znać, bo wzorzec jest identyczny. OpenBao to rozwidlenie HashiCorp Vaulta, systemu zarządzania sekretami, utworzone po tym, jak HashiCorp przeniósł swoje produkty na Business Source License. Podobieństwo idzie aż do szczegółu: plik licencyjny OpenBao zaczyna się od noty „Copyright (c) 2015 HashiCorp, Inc.", dokładnie tak jak tutejszy COPYING zachowuje notę Redis Ltd., bo licencja poprzednika tego wymaga. Ostatnim wydaniem Vaulta na otwartej licencji było 1.14; od 1.15 plik licencyjny nosi już nagłówek BSL.

Typowe błędy

Pierwszy błąd to szukanie pliku LICENSE na gałęzi main i wyciąganie z kodu 404 wniosku, że projekt nie ma licencji. Narzędzia do audytu zależności, które odpytują tylko o nazwy kanoniczne, potrafią oznaczyć Valkeya jako projekt bez licencji. Właściwy adres to COPYING na gałęzi unstable albo dowolny tag wydania.

Drugi to założenie, że skoro serwer jest na BSD, to cała rodzina też. Sterownik valkey-glide jest na Apache 2.0 w obu rejestrach, w których go sprawdziłem, a iovalkey i pythonowy valkey na MIT. Na liście licencji zależności trzeba wpisać każdy z nich osobno.

Trzeci to wnioskowanie o możliwościach serwera z pola redis_version. Wartość 7.2.4 jest tam przypięta na stałe i nie zmieni się nigdy, niezależnie od tego, jak daleko zajdzie rozwój. Kod, który włącza obsługę nowszych poleceń na podstawie tego pola, nigdy ich nie włączy.

Czwarty to traktowanie migracji jako operacji odwracalnej przez plik danych. Do Valkeya 8.x tak jest, od Valkeya 9.x już nie, bo format 80 jest poza zasięgiem Redisa. Zanim przełączysz produkcję, sprawdź, jaką linię Valkeya faktycznie instaluje Twój menedżer pakietów.

Piąty to pomijanie licencji zależności wbudowanych. Archiwum źródeł zawiera pięć osobnych plików licencyjnych w katalogu deps i przy formalnym audycie to one, a nie plik główny, zajmują większość czasu.

Szósty to odrzucanie Redisa 8 odruchowo z powodu AGPL. Dla aplikacji, która po prostu łączy się z serwerem przez sieć i go nie modyfikuje, ta licencja nie nakłada żadnych obowiązków. Jeśli decydujesz się na Valkeya, zrób to z powodu, który potrafisz nazwać, na przykład polityki firmy albo oferty dostawcy chmurowego, a nie z ogólnego niepokoju.

Kiedy Valkey się nie opłaca

Ekosystem materiałów jest młodszy. Poradniki, wpisy na forach i odpowiedzi na pytania o konkretny komunikat błędu dotyczą w przeważającej większości Redisa i trzeba je przekładać samodzielnie. Nazwy plików, ścieżki domyślne i nazwy usług systemowych różnią się na tyle, że kopiowanie polecenia z poradnika bez czytania kończy się pomyłką.

Część bibliotek klienckich i narzędzi operacyjnych nadal zakłada Redisa. Zwykle działają, bo protokół jest ten sam, ale komunikaty i pola metryk mówią o Redisie, co utrudnia pracę osobie dyżurnej o trzeciej w nocy. Narzędzia sprawdzające wersję serwera przed uruchomieniem funkcji zobaczą 7.2.4.

Przy usługach zarządzanych wybór bywa węższy niż dla Redisa, zwłaszcza poza największymi dostawcami. Jeśli Twoja platforma hostingowa oferuje jeden silnik w pamięci i nie jest nim Valkey, kwestia licencji przestaje być Twoim problemem, bo rozwiązuje ją dostawca.

Jeśli szukasz trwałego magazynu, a nie warstwy w pamięci, to pytanie w ogóle nie o ten silnik. Do relacyjnego modelu z transakcjami idzie się do PostgreSQL, do analityki kolumnowej do ClickHouse, a do wyszukiwania pełnotekstowego do Elasticsearch. Valkey i Redis rozwiązują inny problem: dostęp do struktur danych w ułamku milisekundy, z akceptacją tego, że dane mieszczą się w pamięci operacyjnej.

FAQ

Czy istniejący klient Redisa zadziała z Valkeyem bez zmian?

Tak, o ile klient nie warunkuje niczego wersją serwera. Protokół jest ten sam, a pole redis_version w odpowiedzi INFO ma wartość 7.2.4 właśnie po to, żeby biblioteki sprawdzające wersję nie odmawiały połączenia. Zmienia się adres w konfiguracji, nic więcej. Jeśli natomiast Twój kod czyta redis_version, żeby włączyć nowsze polecenie, zobaczy tam wartość, która nigdy nie wzrośnie.

Czy mogę przenieść dane z Redisa 8 do Valkeya 9 przez plik RDB?

Nie w konfiguracji domyślnej. Redis 8 pisze format RDB w numeracji z zakresu zarezerwowanego przez Valkeya jako obcy, a domyślne ustawienie rdb-version-check strict takie pliki odrzuca. Wartość relaxed pozwala spróbować, z przerwaniem w chwili napotkania nieznanej struktury. Przy danych, które i tak są buforem podręcznym, prostsze bywa uruchomienie pustej instancji i pozwolenie na ponowne zapełnienie.

Na jakiej licencji jest Valkey?

BSD 3-Clause. Tekst leży w pliku COPYING na gałęzi unstable i pod każdym tagiem wydania, z jawnym identyfikatorem SPDX-License-Identifier: BSD-3-Clause w wariancie z tagu. Biblioteki klienckie mają jednak własne licencje: valkey-glide jest na Apache 2.0, a iovalkey i pythonowy valkey na MIT.

Czy Redis wrócił do licencji otwartej?

Częściowo. Od Redisa 8 licencja jest potrójna i wśród opcji jest AGPLv3, która jest uznawana za otwartą, więc formalnie wybór taki istnieje. Nie jest to jednak powrót do BSD, a dwie pozostałe opcje, RSALv2 i SSPLv1, otwarte nie są. Redis 7.2 i wcześniejsze pozostają na BSD.

Czy Valkey jest dostępny jako usługa zarządzana?

Istnieją strony produktowe i dokumentacja u kilku dostawców, w tym Amazon Web Services, Google Cloud, DigitalOcean i Aiven. Cen nie podaję, bo cennik ElastiCache nie renderuje się bez JavaScriptu i w surowym HTML zawiera znaczniki szablonu zamiast liczb. Dostępne wersje i regiony sprawdź bezpośrednio u dostawcy.

Czy warto migrować, jeśli mam Redisa 7.2?

Z punktu widzenia licencji nie musisz, bo ta wersja pozostaje na BSD. Powodem do ruchu jest raczej to, że nowe wydania na tej linii nie wychodzą, więc poprawki bezpieczeństwa trzeba szukać gdzie indziej. Valkey w linii 8.x zapisuje ten sam format RDB 11, więc krok w tę stronę jest technicznie najprostszy z możliwych. Jeśli sam prowadzisz wdrożenie za odwrotnym pośrednikiem takim jak Caddy albo na panelu w rodzaju Coolify czy Dokploy, zmiana sprowadza się do podmiany obrazu i nazwy usługi.

Źródła podstawowe: repozytorium valkey-io/valkey, strona pobrania Valkeya oraz plik LICENSE.txt w repozytorium Redisa.