Valkeyに見るオープンソースのフォークをめぐる最新動向まとめ

Redis のライセンス変更と Valkey 誕生の経緯

2024年3月、Redis Labs（現Valkey Solutions）はRedisのライセンスを従来のBSD 3条項ライセンスから、商用利用を制限するSSPL（Server Side Public License）とRSAL（Redis Source Available License）のデュアルライセンスへと変更しました。この決定の背景にあるのは、AWS・Google・Microsoftなどのクラウドベンダーがホステッドサービスで利益を得ながらOSSへの還元が少ないという問題意識です。

この変更を受け、Linux Foundationが旗振り役となり、AWSやGoogleを含む主要クラウドベンダーが支援する形でValkeyプロジェクトが発足しました。ValkeyはBSD 3条項ライセンスを維持しており、Redis 7.2.4のコードベースを継承してコミュニティ主導の開発が続いています。フォーク宣言からわずか数週間でLinux Foundationのサンドボックスプロジェクトに採択されるという異例のスピードは、OSSコミュニティの危機感の高さをよく示しています。

近年の主要 OSS フォーク事例との比較

Valkeyの誕生は決して孤立した出来事ではありません。ここ数年でライセンス変更に端を発したフォークは複数起きており、OSSエコシステムにとって定型的なリスクシナリオとして定着しつつあります。

代表的な事例を振り返ると、HashiCorpが2023年にTerraformをMPL 2.0からBSL（Business Source License）に変更したことに対し、OpenTofuがLinux Foundationのもとでフォークされました。Elasticsearchの場合は2021年にElastic社がSSPLへ移行したことに反発したAWSがOpenSearchを立ち上げており、現在もどちらも活発に開発が続いています。MariaDBがMySQLのフォークとして生まれた経緯まで遡れば、このパターンには10年以上の歴史があります。

これらに共通するのは、「商用SaaS事業者への利益還元」を名目としたライセンス強化という構図です。ビジネスモデルの正当性は認めつつも、「それはもはや純粋なOSSではない」としてコミュニティが離反するパターンが繰り返されています。フォーク側が成功するかどうかは、背後に大手クラウドベンダーや中立的な財団がつくかどうかに大きく左右されます。

Valkey の現状と 2026 年時点のエコシステム

2026年7月現在、ValkeyはV8.xシリーズが安定リリースとして提供されています。AWS ElastiCache・Google Cloud Memorystore・Azure Cache for Redisなどの主要マネージドサービスがValkey対応を完了しており、新規クラスタのデフォルトエンジンをValkeyに切り替えているプロバイダも出ています。

パフォーマンス面では、Valkey 8.0からマルチスレッドI/Oがデフォルト有効化され、スループットが従来のRedis 7系と比べて最大30〜40%向上したとするベンチマーク報告がコミュニティから相次いでいます。互換性については、Redis互換プロトコル（RESP3）を維持しており、既存のクライアントライブラリ（redis-py・Jedis・StackExchange.Redis等）がそのまま動作するケースが大多数です。

一方、Redis社はRedis 8.0をSSPLベースで継続開発しており、ACLの改善やモジュールシステムの刷新など独自の機能拡張を行っています。両プロジェクトのコードベースは徐々に乖離しており、機能差は今後さらに広がる見込みです。どちらを選ぶかは、ライセンスの制約だけでなく、必要な機能セットとサポート体制を比較した上で判断することが求められます。

運用現場での移行判断フレームワーク

現在Redisを運用している現場でValkeyへの移行を検討する際、まず確認すべきは利用形態です。マネージドサービスを使っている場合は、プロバイダがすでにValkeyへ移行済みかを確認してください。既存のRedis互換クラスタに対して順次移行オプションが提供されているケースが増えており、多くの場合はコードを変えずに切り替えられます。

セルフホスト環境の場合は以下の観点で評価します。

• ライセンス適合性：社内ポリシーや顧客向けサービスの配信形態がSSPLの制約に抵触しないか確認します。SaaS型でRedisを組み込んでいる場合は特に注意が必要です。
• モジュール依存：RedisSearch・RedisJSON などの公式モジュールを使っている場合、Valkey側の対応状況を事前に確認します。コミュニティ版モジュールへの移行が必要なケースがあります。
• クライアント互換性：プロトコルレベルでの互換性は高いですが、クライアントライブラリのバージョンによっては挙動差が出ることがあります。移行前にステージング環境での検証が必須です。

Valkey への移行手順と検証ポイント

セルフホスト環境でのValkey導入は、パッケージマネージャー経由が最も手軽です。Ubuntu 24.04 LTS / Debian 12 系では公式リポジトリからインストールできます。

# Ubuntu/Debian 系
sudo apt install -y valkey-server

# systemd で起動・自動起動設定
sudo systemctl enable --now valkey-server

# 動作確認
valkey-cli ping
# → PONG

設定ファイルは /etc/valkey/valkey.conf に配置されており、基本的な構成はRedisの redis.conf と互換性があります。既存の設定ファイルを流用する場合は、requirepass・bind・maxmemory 等の主要パラメータを移植し、マルチスレッドI/O設定（io-threads）など Valkey 固有のオプションを追記する形で対応できます。

稼働中のデータを無停止で移行する場合は、ValkeyノードをRedisの一時的なレプリカとして参加させてから昇格させるシナリオが現場では多く採用されています。

# Valkey ノード側でレプリケーション開始（既存 Redis からデータを引き込む）
valkey-cli REPLICAOF <既存RedisのIP> 6379

# 同期完了を確認
valkey-cli INFO replication | grep master_sync_in_progress
# → master_sync_in_progress:0 になれば同期完了

# レプリケーション解除（Valkeyをプライマリに昇格）
valkey-cli REPLICAOF NO ONE

切り戻しを想定し、移行前に必ずRDBスナップショットを別ストレージへ退避させておきます。valkey-cli BGSAVE で生成される dump.rdb は Redisでそのまま読み込めるため、万一の際は旧Redisを起動してデータを復元できます。

OSS 選定における持続可能性の評価基準

Valkeyをめぐる一連の動きは、「OSSを永続的なインフラとして採用する際のリスク評価」を運用組織に問い直す契機となっています。2026年現在、OSS選定における確認項目として以下が定着しつつあります。

• ライセンスの種類と変更履歴：Copyleft（GPL/LGPL/AGPL）・Permissive（MIT/BSD/Apache 2.0）・Source Available（SSPL/BUSL）を区別し、過去に変更があったかを確認します。
• コントリビューター集中度：特定企業1社がコミット数の大部分を占めるプロジェクトは、その企業の方針転換の影響を直接受けやすい傾向があります。
• 財団への移管状況：Linux Foundation・Apache Software Foundation・CNCFなど中立的な財団の傘下にあるかが、長期的な持続性の目安になります。
• SBOM（ソフトウェア部品表）の整備：EUのサイバーレジリエンス法（CRA）施行を受け、OSSコンポーネントのライセンス追跡が規制上の要件になりつつあります。大規模組織では依存関係のライセンス自動チェックをCI/CDに組み込む動きが広がっています。

Valkeyの事例が示すのは、「ライセンス問題は起きてから対処するのでは遅い」という教訓です。採用時点でフォーク可能性や代替手段を想定しておくこと、そして主要コンポーネントのライセンス変更を定期的にウォッチする体制を持つことが、持続可能な運用の基盤となります。OSSは無償で使えるからこそ、その持続性を支えるガバナンスへの目配りが運用組織にとっての責任になっています。