Redisの新しいライセンスRSAL/SSPLとは？影響と選び方

Redisの新しいライセンス RSAL/SSPLとは？影響と選び方

はじめに

Redisは、その卓越したパフォーマンス、柔軟性、そして使いやすさから、世界中の開発者や企業に愛用されているインメモリデータ構造ストアです。キャッシュ、メッセージブローカー、セッションストア、リアルタイム分析など、多岐にわたるユースケースでその真価を発揮してきました。Redisの成功は、長年にわたりBSDライセンスという非常に寛容なオープンソースライセンスの下で提供されてきたことと無関係ではありません。この自由なライセンスのおかげで、誰でも自由にRedisを利用、改変、配布、そして商用サービスとして提供することが可能でした。

しかし、2024年3月20日、Redisの開発元であるRedis Ltd.は、将来のRedisバージョンに対するライセンスモデルを大幅に変更することを発表しました。従来のBSDライセンスから、RSAL v2 (Redis Source Available License v2) と SSPL v1 (Server Side Public License v1) という、より制限的なライセンスに移行するというのです。この発表は、特にRedisを自社サービスの一部として提供している企業やクラウドプロバイダーの間で大きな波紋を呼びました。

なぜこのようなライセンス変更が行われたのでしょうか？そして、この変更はRedisのユーザー、特に企業にとってどのような影響をもたらすのでしょうか？さらに、新しいライセンスの下でRedisを利用するにあたり、どのような選択肢があり、どのように判断すべきなのでしょうか？

この記事では、Redisの新しいライセンスであるRSAL v2とSSPL v1の詳細、ライセンス変更の背景、ユーザー企業が直面する影響、そして今後のRedisとの付き合い方、具体的な選択肢と選び方について、約5000語にわたって詳細に解説します。Redisを利用しているすべての方々が、このライセンス変更を正しく理解し、自身のビジネスやプロジェクトにとって最適な判断を下せるようになることを目指します。

Redisライセンスの歴史と変更点

過去のライセンス：BSDライセンス

長らく、Redisは修正BSDライセンス（3条項BSDライセンス）の下で提供されてきました。このライセンスは、オープンソースライセンスの中でも非常に自由度の高いものです。主な特徴は以下の通りです。

利用の自由: ソースコードを自由に利用、複製、配布することができます。
改変の自由: ソースコードを自由に改変し、派生物を作成することができます。
商用利用の自由: 改変または未改変のソフトウェアを、商用目的で利用、配布、サービス提供することができます。
制限の少なさ: 著作権表示、ライセンス条文、免責事項を含めること以外の特別な義務（例えば、派生物のソースコード公開義務など）はほとんどありませんでした。

この寛容なライセンスのおかげで、多くの企業がRedisを自身の製品に組み込んだり、マネージドサービスとして提供したりすることが容易でした。これはRedisの普及に大きく貢献しましたが、同時に開発元であるRedis Ltd.にとっては、自社で開発・メンテナンスしているRedisの「上に構築された」ビジネスから、十分な収益を上げる上での課題も生じさせました。特に、大規模なクラウドプロバイダーがRedisのオープンソース版を基盤としたマネージドサービスを提供し、その収益の一部がRedisの開発・メンテナンスに直接還元されにくいという状況が指摘されていました。

ライセンス変更の背景：オープンソースの持続可能性と収益化

Redis Ltd.がライセンス変更に踏み切った主な理由は、オープンソースプロジェクトの持続可能性を確保しつつ、開発元としての収益モデルを確立・強化することにあります。前述のように、寛容なBSDライセンスの下では、Redis Ltd.以外の企業も容易にRedisを利用したビジネスを展開できました。これによりRedisの普及は進みましたが、プロジェクトの中核的な開発やメンテナンスを担うRedis Ltd.が、その貢献に見合う経済的な利益を得ることは難しくなっていました。特に、クラウドプロバイダーが提供するRedis互換サービスは、Redis Ltd.が提供する商用サービスと競合するにもかかわらず、Redis Ltd.の開発投資に直接的に貢献しない構造になっていました。

このような状況は、Redisに限らず、多くの人気オープンソースプロジェクトが直面している課題です。開発を主導する企業が、自身の投資に見合う収益をオープンソースソフトウェア自体から得るのではなく、それに関連するサポートや付加価値サービスで賄おうとしても、オープンソース版の無料利用や第三者によるサービス提供がそのモデルを難しくすることがあります。

Redis Ltd.は、新しいライセンスを導入することで、主に「Redisをマネージドサービスとして提供する」というビジネスモデルに対して制限を設け、開発元がその活動からより直接的な経済的利益を得られるようにすることを目指しました。これにより、Redisの中核的な開発に安定的に投資できる体制を築き、プロジェクトの長期的な持続可能性を確保したいという意図があります。

BSDからRSAL v2 / SSPL v1への具体的な変更点

ライセンス変更の最も重要なポイントは、「Redisをサービスとして提供する場合の条件が厳しくなった」という点です。BSDライセンスではサービス提供に制限はありませんでしたが、RSAL v2とSSPL v1では、この行為に対する明確な制約または義務が課されます。

具体的には、将来のRedisのバージョン（バージョン7.4以降）は、コアとなるRedisコードと、Redis Stackの一部のモジュールに対して、以下のいずれかのライセンスが適用されます。

RSAL v2 (Redis Source Available License v2)
SSPL v1 (Server Side Public License v1)

これらのライセンスは、OSI (Open Source Initiative) が定義する「オープンソース」の基準を満たしていません（特にSSPLは過去にOSIから認められなかった経緯があります）。そのため、Redisは厳密な意味での「オープンソースソフトウェア」ではなく、「ソースコードが入手可能なソフトウェア (Source-Available Software)」という位置づけになります。

これにより、バージョン7.2以前のRedis（およびそれらを基にした既存のフォークなど）は引き続きBSDライセンスの下で利用可能ですが、バージョン7.4以降の新しい機能や改善、バグ修正はRSAL v2またはSSPL v1の下でのみ提供されることになります。これが、既存ユーザーが将来のバージョンアップを検討する際に直面する大きな変化点です。

新しいライセンスの詳細

ここでは、新しく採用されたRSAL v2とSSPL v1の具体的な内容について詳しく見ていきます。それぞれのライセンスが何を目的にしており、どのような行為が許可され、どのような行為が制限されるのかを理解することが、今後の利用方針を決定する上で不可欠です。

RSAL v2 (Redis Source Available License v2)

RSAL (Redis Source Available License) は、Redis Ltd.が独自に策定したソースアベイラブルライセンスです。バージョン1が存在しますが、今回発表されたのはバージョン2です。

目的: RSAL v2は、主にRedisの内部利用や限定的な商用利用を許可しつつ、Redisを独立した「サービス」として提供することに制限を設けることを目的としています。開発元の意図としては、自社のサービス提供ビジネスを保護しつつ、多くのユーザーが引き続きRedisを自身の目的のために利用できるバランスをとることにあります。
許可される行為:
- ソースコードの閲覧、学習。
- ソフトウェアの複製、配布（ライセンス条文の添付が必要）。
- ソフトウェアの改変、派生物の作成。
- ソフトウェアの内部利用: これは最も一般的な利用形態であり、完全に許可されています。企業が自身のシステム内でRedisをキャッシュ、セッションストア、キューなどとして利用する場合、RSAL v2の下でも無制限かつ無料で利用できます。
- ソフトウェアの外部利用（ただし「サービス提供」に当たらない範囲）: これはRSAL v2の解釈において重要な点です。例えば、自身の開発したアプリケーションの一部としてRedisをバンドル・配布する、または顧客にデプロイするシステムの一部としてRedisを利用する場合などが考えられます。ただし、この利用が「サービス提供」に当たるかどうかは、契約条件や提供形態によって判断が分かれる可能性があります。
制限される行為:
- ソフトウェアを「サービス」として提供すること: RSAL v2の下で最も明確に制限される行為は、第三者に対してネットワーク経由でRedisの機能性を「サービス」として提供し、その利用に対して対価を得る、またはそれに類する経済的な利益を得る行為です。クラウドプロバイダーがRedisのマネージドサービスを提供する場合などがこれに該当します。
- ただし、RSAL v2では「サービス」の定義について、いくらかの例外やグレーゾーンが残る可能性があります。例えば、自身のSaaSアプリケーションのバックエンドとしてRedisを利用し、そのSaaS利用料の一部がRedisの利用コストと関連付けられる場合など、解釈が難しいケースも想定されます。ライセンス条文を詳細に確認する必要がありますが、一般的には、Redis自体を主要な機能として提供し、その利用に対して直接的な対価を得るようなビジネスモデルを制限するためのライセンスと言えます。
ソースコードの公開義務: RSAL v2には、派生物やサービス提供時にソースコードを公開する義務はありません。これはSSPLとの大きな違いです。ソースコードは公開されていますが、改変したりサービスを提供したりしても、そのコードを一般に公開する義務は生じません（ただし、サービス提供自体が制限されています）。
主なユーザー層: RSAL v2は、主に以下のようなユーザーに適しています。
- Redisを内部インフラとして利用する企業: 企業のIT部門が自社のアプリケーションのためにRedisをデプロイ・運用する場合など。
- Redisを自身のソフトウェア製品の一部としてバンドル・配布するベンダー: ただし、この形態が「サービス提供」と見なされないかの確認は必要かもしれません。
- 開発、テスト、ステージングなどの非本番環境での利用:

RSAL v2は、従来のBSDライセンスよりは制限的ですが、SSPL v1に比べれば比較的自由度が高いと言えます。特に内部利用においては、実質的にBSDライセンス時代と変わらない自由度で利用できると解釈できます。

SSPL v1 (Server Side Public License v1)

SSPL (Server Side Public License) は、もともとMongoDBによって開発されたライセンスです。バージョン1が OSI によってオープンソースライセンスとして承認されなかったという経緯があります。Redis Ltd.は、MongoDBがオープンソース版のライセンスとして採用していたSSPL v1を、将来のRedisの一部に適用することを選択しました。

目的: SSPL v1は、ソフトウェアを「サービス」として提供する場合に、そのサービス全体に関連するソースコードを公開する義務を課すことで、サービス提供ビジネスを制限することを目的としています。これは、開発元がサービス提供ビジネスを保護するための、非常に強力な手段です。
許可される行為:
- ソースコードの閲覧、学習。
- ソフトウェアの複製、配布（ライセンス条文の添付が必要）。
- ソフトウェアの改変、派生物の作成。
- ソフトウェアの内部利用: RSAL v2と同様に、SSPL v1の下でもソフトウェアの内部利用は完全に許可されています。
- ソフトウェアを「サービス」として提供すること（ただし、SSPLの条件を満たす場合）: SSPL v1の下でもソフトウェアをサービスとして提供することは可能ですが、その場合に非常に厳しい条件が課されます。
制限される行為と課される義務:
- ソフトウェアを「サービス」として提供する場合: SSPL v1で最も重要な条項は、ソフトウェアの機能性を第三者がネットワーク経由で利用できるようにする場合（つまり、サービスとして提供する場合）に適用される義務です。この義務は、ソフトウェアだけでなく、「サービスを提供するために使用する、ネットワーク上で利用可能なプログラム」のソースコード全体を、SSPLまたは互換性のあるライセンスの下で公開しなければならない、というものです。
- 「サービスを提供するために使用する、ネットワーク上で利用可能なプログラム」の定義は非常に広範に解釈される可能性があります。例えば、SSPL版のRedisをバックエンドとして利用するSaaSアプリケーションを提供する場合、SSPLの厳格な解釈では、そのSaaSアプリケーション全体のソースコードをSSPLの下で公開する必要が生じる可能性も否定できません。これは、多くの企業にとって受け入れがたい条件となります。
- この義務を回避するためには、Redis Ltd.と別途商用ライセンス契約を結ぶ必要があります。
ソースコードの公開義務: SSPL v1の最大の義務は、サービス提供時に発生する広範なソースコード公開義務です。これはAGPL (Affero General Public License) に似ていますが、AGPLが派生物のソースコード公開を求めるのに対し、SSPLは「サービス全体のソースコード」という、より広範な範囲を対象とする点で異なります。
OSIによる非承認: 前述の通り、SSPLはOSIによってオープンソースライセンスとして承認されていません。これは、SSPLが課すソースコード公開義務が、特定の利用形態（サービス提供）を意図的に制限しており、「特定分野における利用を制限しない」というオープンソースの定義に反すると判断されたためです。したがって、SSPLは「ソースアベイラブル」ライセンスとして分類されます。
主なユーザー層: SSPL v1は、主に以下のようなユーザーに適しています。
- Redisを内部インフラとして利用する企業: RSAL v2と同様、内部利用は無制限です。
- SSPLの条件（サービス全体のソースコード公開）を受け入れることができるサービス提供者: これは非常に稀なケースでしょう。
- Redis Ltd.と商用ライセンス契約を結ぶことを前提に、新しいバージョンを利用したいサービス提供者:

SSPL v1は、サービス提供を行う企業にとってはRSAL v2よりもはるかに制限的で、実質的にオープンソース版の利用を困難にするライセンスと言えます。

新しいライセンスがもたらす影響

Redisのライセンス変更は、様々な立場のユーザーや関係者に大きな影響を与えます。ここでは、主な影響について詳しく見ていきます。

ユーザー企業への影響

Redisを業務で利用しているほとんどの企業が、何らかの影響を受けます。影響の度合いは、Redisの利用目的（内部利用か、製品組み込みか、サービス提供か）、利用形態（自社運用か、クラウドマネージドサービスか）、そして現在利用しているRedisのバージョンによって異なります。

内部利用: 企業が自身のアプリケーションのバックエンドとしてRedisを利用する場合（キャッシュ、セッションストア、キューなど）、これは「内部利用」に該当します。RSAL v2、SSPL v1ともに、内部利用は無制限かつ無料で許可されています。したがって、既存の内部利用ユーザーは、新しいライセンスの下でもバージョン7.4以降のRedisを無償で利用し続けることができます。ただし、将来的に外部サービスとして提供する可能性がないか、利用形態が内部利用に限定されているかの確認は重要です。
製品への組み込み: 自身のソフトウェア製品の一部としてRedisを組み込み、顧客に販売または提供する場合、その形態がRSALまたはSSPLにおける「サービス提供」に該当するかどうかの判断が必要です。一般的には、ソフトウェアパッケージの一部として提供し、顧客が自身のインフラ上で運用する場合、これは「サービス提供」に当たらない可能性が高いですが、契約形態によっては判断が分かれることもあります。ライセンス条項の厳密な解釈と、必要に応じて法務部門や専門家への相談が推奨されます。もし「サービス提供」に当たらないと判断できれば、RSAL v2の下で無償利用できる可能性が高いです。
自社サービスとしての提供: 自身が開発・提供するSaaSやプラットフォームのバックエンドとしてRedisを利用し、そのSaaS/プラットフォームの機能の一部としてRedisの機能性を提供する場合、これはRSALやSSPLにおける「サービス提供」に該当する可能性が極めて高いです。
- RSAL v2の下では、この形態でのRedisの利用は基本的に制限されます。
- SSPL v1の下では、この形態での利用は可能ですが、サービス全体に関連するソースコードをSSPLの下で公開する義務が発生します。これは多くの企業にとって現実的な選択肢ではありません。
- したがって、自社サービスとしてRedisを提供する企業が、バージョン7.4以降のRedisを利用したい場合は、Redis Ltd.と別途商用ライセンス契約を締結する必要が生じます。商用ライセンスの条件や費用は、Redis Ltd.との交渉によります。
既存のBSD版Redisからの移行問題: バージョン7.2以前のRedisは引き続きBSDライセンスの下で利用可能ですが、これらのバージョンは将来的にサポートやセキュリティアップデートが終了する可能性があります。新しい機能やパフォーマンス改善は、RSAL/SSPL版にのみ追加されていくでしょう。したがって、最新の機能を利用したい、あるいは長期的なサポートを重視する企業は、新しいライセンス版への移行を検討する必要がありますが、その際に前述のライセンス上の制約が影響します。
ライセンス遵守のための法的レビューの必要性: 特にRedisを外部に提供する可能性がある企業は、新しいライセンス条項を正確に理解し、自社の利用形態がライセンスに違反しないか、あるいはどのようなライセンス契約が必要になるかを、法務部門や外部の法律専門家を交えて詳細にレビューする必要があります。ライセンス違反は、損害賠償請求などの重大なリスクにつながる可能性があります。

クラウドプロバイダーへの影響

Redisのライセンス変更は、特にRedisのマネージドサービスを提供しているクラウドプロバイダーに最も大きな影響を与えます。

Redisサービス提供の制限: RSAL v2とSSPL v1は、Redisを「サービスとして提供する」行為を制限することを主な目的としています。したがって、Amazon ElastiCache for Redis, Google Cloud Memorystore for Redis, Azure Cache for Redisといった、オープンソース版のRedisを基盤としたマネージドサービスは、バージョン7.4以降のRSAL/SSPL版Redisをそのまま利用して提供することが、ライセンス上困難になります。
代替ソリューションへの移行またはフォークの利用: クラウドプロバイダーは、以下のいずれかの対応を迫られる可能性があります。
- バージョン7.2以前のBSD版Redisを利用し続ける（ただし、将来的なサポート問題あり）。
- Redis Ltd.と商用ライセンス契約を結び、有償で新しいRedisバージョンをサービスに利用する。
- Redisの代替となる他のインメモリデータベース（Memcachedなど）や、Redis互換のオープンソースプロジェクト（後述のValkeyなど）を利用・提供する。
- 独自のRedis互換サービスを開発する（既にDragonflyなどが存在します）。
Redis Enterprise Cloudとの競合: Redis Ltd.は、自身もマネージドサービス「Redis Enterprise Cloud」を提供しています。今回のライセンス変更は、サードパーティのクラウドプロバイダーによるオープンソース版ベースのサービス提供を制限することで、Redis Ltd.自身の商用サービスへの誘導を強化する側面があります。

コミュニティへの影響

オープンソースライセンスからソースアベイラブルライセンスへの変更は、活発なコミュニティにとって必ずしも歓迎されるものではありません。

フォークの可能性: ライセンス変更を受けて、バージョン7.2以前のBSD版Redisを基にしたコミュニティ主導のフォークプロジェクトが立ち上がる可能性が高いです。実際に、Linux Foundationは「Valkey (ヴァルキー)」という名称で、BSDライセンスのRedis 7.2をベースとした新しいプロジェクトを開始することを発表しました。このようなフォークは、ライセンス変更に反対する開発者や企業にとって、BSDライセンスのまま開発が続けられる代替選択肢となります。
コミュニティ活動の分裂: 開発リソースや貢献者が、Redis Ltd.が主導するRSAL/SSPL版と、コミュニティ主導のフォーク版（Valkeyなど）に分散し、コミュニティの活動が分裂する可能性があります。これは、一方または両方のプロジェクトの進化速度や安定性に影響を与えるかもしれません。
オープンソースエコシステム全体への示唆: Redisのような著名なプロジェクトがライセンス変更を行うことは、他のオープンソースプロジェクトにも影響を与え、同様の動きを検討するきっかけになる可能性があります。これは、ソフトウェアの「オープンソース性」やその経済モデルについて、改めて議論を喚起することにもつながります。

ユーザー企業が取るべき対応と選び方

Redisのユーザー企業は、このライセンス変更を受けて、自身のRedis利用について見直しを行い、今後の戦略を検討する必要があります。取るべき対応と、新しいライセンスの下での選択肢、そしてその選び方について具体的に解説します。

現在の利用状況の把握

まず最初に行うべきことは、現状を正確に把握することです。

利用しているRedisのバージョン確認: 現在利用しているRedisのバージョンを確認します。バージョン7.2以前であればBSDライセンス、バージョン7.4以降であればRSAL/SSPLライセンスが適用されます。redis-server --version コマンドなどで確認できます。
Redisの利用目的の特定: Redisを何のために利用していますか？
- 社内システムでのキャッシュ、セッションストア、キューなど（内部利用）。
- 自社製品に組み込んで顧客に販売/提供（製品組み込み）。
- SaaSやプラットフォームのバックエンドとして利用し、顧客がその恩恵を受ける（サービス提供）。
- 開発、テスト、個人利用など。
商用利用か非商用利用か: 利用が直接的または間接的に収益に結びついているかを確認します。内部利用でも企業の事業活動の一環であれば実質的な商用利用と言えますが、ライセンス条項における「商用利用」や「サービス提供」の定義に注意が必要です。
利用形態: クラウドプロバイダーが提供するマネージドサービス（ElastiCacheなど）を利用しているか、自社のインフラ上でRedisを運用しているか。マネージドサービスを利用している場合、サービス提供元がどのバージョンのRedisを使い続け、どのようなライセンスに対応するかが重要になります。

これらの情報を整理することで、自身がどのライセンスの影響を最も強く受けるか、そしてどのような選択肢が現実的かが見えてきます。

新しいライセンスの下での選択肢

現在の利用状況と今後の計画に基づき、新しいライセンスの下でRedisを利用する、あるいは代替手段に移行するために、いくつかの選択肢が考えられます。

BSDライセンスの最終バージョン（7.0.xまたは7.2.x）を利用し続ける:
- 概要: BSDライセンスが適用される最終バージョン（現時点では7.2.x系が最新のBSD版）を、今後も利用し続けるという選択肢です。これは最も手軽な選択肢であり、既存のライセンスリスクを回避できます。
- メリット: ライセンス上の制約が最も少ないBSDライセンスの下で利用できるため、既存の利用形態を維持しやすい。追加費用が発生しない。
- デメリット: 将来的にRedis Ltd.からの公式なサポート（バグ修正、セキュリティアップデートなど）が終了する可能性があります。新しい機能やパフォーマンス改善の恩恵を受けられません。長期的な利用には、セキュリティリスクや技術的な陳腐化のリスクが伴います。
- 適しているケース:
  - Redisの利用が限定的で、最新の機能や手厚いサポートを必要としない。
  - 既存のシステムが安定しており、大幅な変更のリスクを取りたくない。
  - セキュリティリスクを許容できる、または自社でバックポートなどの対応が可能。
  - 主に内部利用であり、新しいライセンスの制約を気にしなくてもよいが、将来的なバージョンアップの可能性も低い場合。
Redis Ltd.提供のRSAL/SSPL版を利用する:
- 概要: バージョン7.4以降のRedisを、提供元のRedis Ltd.が定めたRSAL v2またはSSPL v1ライセンスの下で利用する選択肢です。
- メリット: 最新の機能、パフォーマンス改善、バグ修正、セキュリティアップデートを利用できます。Redisの開発を主導する公式版であり、安定性や信頼性が期待できます。
- デメリット:
  - サービス提供を行う場合: SSPLの広範なソースコード公開義務を受け入れるか、Redis Ltd.と商用ライセンス契約を結ぶ必要があります。多くの企業にとって、商用ライセンス契約が現実的な唯一の選択肢となり、コストが発生します。
  - 内部利用や限定的な利用の場合: RSAL v2またはSSPL v1の下で無償利用可能ですが、将来的に利用形態が変化した場合にライセンス違反にならないか、注意が必要です。ライセンス条項の正確な理解が不可欠です。
- 適しているケース:
  - 内部利用や製品組み込みの場合: ライセンス上の制約（サービス提供の禁止/制限）に抵触しない利用形態であれば、最新版を無償で利用できます。
  - サービス提供を行う場合: SSPLのソースコード公開義務を受け入れることができる（稀）、またはRedis Ltd.との商用ライセンス契約による有償利用が可能・許容できる。
  - 最新の機能や公式サポートを最も重視する。
コミュニティによるフォークプロジェクトを利用する:
- 概要: RedisのBSDライセンス版を基に、コミュニティが開発を引き継ぐフォークプロジェクトを利用する選択肢です。最も注目されているのは、Linux Foundationが発表した「Valkey」プロジェクトです。ValkeyはBSDライセンス版Redis 7.2を基盤としており、Apache License 2.0などのより寛容なオープンソースライセンスの下で開発が進められる可能性が高いです（最終的なライセンスはコミュニティの決定によります）。
- メリット: BSDライセンスまたはそれに類する寛容なオープンソースライセンスの下で利用できる可能性が高く、ライセンス上の制約を気にせずに内部利用、製品組み込み、サービス提供が可能です。コミュニティ主導のため、特定の営利企業の意向に左右されにくい点が魅力です。
- デメリット: プロジェクトの立ち上げ段階では、安定性、機能開発速度、コミュニティの活発さ、長期的な持続可能性などが未知数です。公式のRedisと完全に互換性が維持されるかは保証されません。サポート体制も、コミュニティの貢献に依存します。
- 適しているケース:
  - BSDライセンスまたは同様の寛容なライセンスでの利用を強く希望する（特にサービス提供を行いたい企業）。
  - コミュニティ主導の開発モデルを支持し、貢献する意向がある。
  - 新しいプロジェクトのリスク（安定性、将来性など）を受け入れることができる。
  - Redis Ltd.との商用契約を避けたいが、BSD版の古いバージョンを使い続けるリスクも避けたい。
その他のフォークやRedis互換データベースを利用する:
- 概要: Valkey以外にも、Redis互換を目指すオープンソースプロジェクトや商用データベースが存在します。例えば、DragonflyはRedisプロトコル互換の高性能なインメモリデータストアで、独自のライセンス（BSDライセンスなど）の下で提供されています。また、Memcachedやetcd、ZooKeeperなど、ユースケースによってはRedisの代替となりうる他のデータベースを選択する道もあります。
- メリット: Redisとは異なるライセンスモデルで利用でき、特定の機能やパフォーマンスに優れている場合があります。Redisのライセンス変更の影響を直接受けません。
- デメリット: Redisとの互換性が完全ではない場合があります（特にモジュールや高度な機能）。移行コストが発生します。コミュニティの規模やエコシステムがRedisほど成熟していない場合があります。
- 適しているケース:
  - Redisのライセンス変更を機に、より自社のニーズに合ったデータベースを検討したい。
  - 特定の性能要件（マルチコア活用など）がRedisよりも重要な場合（Dragonflyなど）。
  - 移行コストを許容できる。
  - Redis互換性は必須ではない、または代替データベースのプロトコルで問題ない場合（Memcachedなど）。

ライセンスの選択基準と判断フロー

上記の選択肢を踏まえ、自身の状況に合わせてどのようにライセンスや利用するRedis/互換データベースを選択すべきか、以下の基準とフローチャート（テキスト表現）を参考に判断してください。

主要な判断基準:

今後のRedisの利用目的: 内部利用のみか、製品組み込みか、サービス提供か。これが最も重要な分水嶺です。
サービス提供の有無: もしサービス提供を行う場合、SSPLのソースコード公開義務を受け入れられるか、Redis Ltd.との商用契約を許容できるか、あるいはBSDライセンスまたは寛容なライセンスを持つフォークや代替データベースを必須とするか。
最新機能・サポートの必要性: 最新バージョンでなければならないか、古いバージョンでも許容できるか。開発元による公式サポートが必要か、コミュニティサポートや自社対応で十分か。
ライセンスリスクへの許容度: ライセンス違反のリスクをどの程度回避したいか。法務部門との連携の必要性。
移行コストとリスク: 現在のシステムから別のバージョンや他のデータベースに移行する際の人的・時間的コスト、およびシステム停止などのリスクをどの程度許容できるか。
コミュニティへの関与: コミュニティ活動に貢献したい、あるいはコミュニティ主導のプロジェクトを支持したい意向があるか。

簡単な判断フロー（テキスト）:

“`
[スタート]

あなたはRedisを「サービス」として第三者に提供しますか？
-> はい
-> SSPL v1 の条件（サービス全体に関連するソースコードを SSPL 下で公開）を現実的に受け入れられますか？
-> はい : SSPL 版 Redis を検討（稀なケース）
-> いいえ:
-> Redis Ltd. と商用ライセンス契約を結ぶ予算・意向はありますか？
-> はい : Redis Ltd. の商用版 Redis を検討
-> いいえ:
-> BSD ライセンスまたは寛容なオープンソースライセンスを持つ代替手段を探す
-> コミュニティフォーク (Valkey など) を検討
-> その他の Redis 互換データベース (Dragonfly など) を検討
-> BSD ライセンス最終版 Redis を利用し続ける (非推奨だが選択肢)
-> Redis 以外の種類のデータベースを検討

-> いいえ (内部利用、製品組み込みなど)
-> 最新の機能、パフォーマンス改善、公式サポートは必要ですか？
-> はい : Redis Ltd. 提供の RSAL v2 版 Redis を検討 (利用条件に注意、サービス提供に該当しないか要確認)
-> いいえ:
-> BSD ライセンス最終版 Redis を利用し続ける
-> コミュニティフォーク (Valkey など) を検討 (将来的な代替として)

[エンド]
“`

このフローチャートはあくまで一般的な指針です。特に「サービス提供」の定義や「製品組み込み」がそれに該当するかどうかは、個別のケースによって判断が分かれる可能性があるため、必ず詳細なライセンス条項を確認し、法務部門やライセンス専門家と相談してください。

法務部門や専門家への相談

Redisのライセンス変更は、特に企業にとっては法的なリスクを伴う可能性があります。自身の利用形態が新しいライセンスに適合しているか、どのような契約が必要になるかといった判断は、技術的な知見だけでなく、法律的な専門知識も必要とします。

RSAL v2およびSSPL v1のライセンス条項を詳細に入手し、社内の法務部門にレビューを依頼してください。
もし社内に専門家がいない場合は、外部のソフトウェアライセンスに関する法律に詳しい弁護士やコンサルタントに相談することを強く推奨します。
特に、Redisを自社サービスの一部として提供している場合、SSPLの解釈によってはビジネス継続に重大な影響が出る可能性があるため、迅速かつ慎重な対応が必要です。Redis Ltd.への問い合わせや商用ライセンスに関する情報収集も並行して行いましょう。

ライセンス変更の背景にあるオープンソースの課題

Redisのライセンス変更は、個別のプロジェクトの問題に留まらず、現代のオープンソースエコシステムが直面している構造的な課題を浮き彫りにしています。

クラウドプロバイダーによるオープンソースプロジェクトの「搾取」: Redis Ltd.のような開発元企業の視点からは、自身が多大な投資を行って開発・メンテナンスしているオープンソースソフトウェアを、クラウドプロバイダーが無料で利用して収益性の高いマネージドサービスを提供し、その利益が開発元に十分に還元されない状況は「搾取」と映ります。これは、多くの人気オープンソースプロジェクトが直面している問題であり、開発元がライセンスを変更してサービス提供を制限する動き（MongoDBのSSPL採用、Elasticsearch/KibanaのElastic License採用など）が相次いでいます。
開発元の収益化とプロジェクトの持続可能性: オープンソースプロジェクトの継続的な開発・メンテナンスには、人件費やインフラコストといった費用がかかります。これをどのように賄い、プロジェクトの持続可能性を確保するかは大きな課題です。商用サポート、コンサルティング、付加価値機能を持つ商用版の提供などが従来のモデルでしたが、クラウドベンダーによる無料版ベースのサービス提供が、これらの収益源を圧迫する場合があります。ライセンス変更は、この課題に対する開発元の回答の一つと言えます。
「オープンソース」の定義に関する議論: SSPLがOSIによってオープンソースと認められなかったように、サービス提供に対する制限を設けるライセンスは、伝統的なオープンソースの定義から逸脱すると見なされます。「特定分野での利用を制限しない」というオープンソースの原則と、開発元の経済的合理性の間で揺れが生じています。これにより、オープンソースソフトウェアの新しい分類（ソースアベイラブルなど）や、その役割・期待について、コミュニティ内で議論が深まっています。
コミュニティ主導のフォーク（Valkey）の意義: Redisのライセンス変更を受けてValkeyのようなフォークプロジェクトが立ち上がったことは、コミュニティが、特定の企業のコントロールから離れてソフトウェアのオープン性を維持しようとする動きの表れです。これは、オープンソースの精神を体現するものであり、ライセンス変更によって生じたエコシステムの分裂を補う可能性を秘めています。ユーザーにとっては、公式版Redisとは別の、コミュニセンス主導の選択肢が生まれることになります。

これらの課題は複雑であり、簡単な解決策はありません。Redisのライセンス変更は、この広範な議論の一部として捉えるべきであり、ユーザー企業は自身のビジネスに与える直接的な影響だけでなく、オープンソースエコシステム全体の動向にも目を配ることが重要です。

まとめ

Redisの新しいライセンス、RSAL v2とSSPL v1の導入は、長年BSDライセンスという非常に寛容な条件の下で普及してきたRedisにとって、大きな転換点となります。この変更は、主にRedisを「サービスとして提供する」企業、特にクラウドプロバイダーに対して強い制限を課すことを目的としています。開発元であるRedis Ltd.が、オープンソースプロジェクトの持続可能性を確保し、自社の開発投資に見合う収益を得るための戦略の一環です。

要点をまとめると:

バージョン7.2以前のRedisは引き続きBSDライセンスで利用可能ですが、バージョン7.4以降はRSAL v2またはSSPL v1が適用されます。
RSAL v2は、主に内部利用や限定的な商用利用を許可しつつ、「サービス提供」を制限します。ソースコード公開義務はありません。
SSPL v1は、ソフトウェアを「サービス」として提供する場合に、サービス全体に関連する広範なソースコード公開義務を課します。これは多くの企業にとって現実的な選択肢ではなく、実質的に商用ライセンスが必要となります。SSPLはOSI定義のオープンソースライセンスではありません。
この変更は、Redisを自社サービスとして提供する企業に最も大きな影響を与え、RSAL/SSPL版を利用する場合は商用契約が必要になる可能性が高いです。
内部利用が主なユーザーは、RSAL/SSPL版を無償で利用できますが、利用形態の確認とライセンス条項の理解が必要です。
クラウドプロバイダーは、バージョン7.4以降の公式Redisをマネージドサービスに利用することが困難になります。
コミュニティ主導のフォークプロジェクト（Valkeyなど）が登場しており、BSDライセンスまたはそれに類する寛容なライセンスで利用できる代替選択肢となる可能性があります。

ユーザー企業は、自身のRedisの利用状況（バージョン、利用目的、利用形態）を正確に把握し、新しいライセンス条項を詳細に確認する必要があります。その上で、BSD版の古いバージョンを使い続けるか、RSAL/SSPL版Redisを（無償または有償で）利用するか、コミュニティフォーク（Valkeyなど）に移行するか、あるいは他のデータベースに移行するかを慎重に判断しなければなりません。

特に、Redisをサービスとして提供している企業や、将来的に提供する可能性のある企業は、法務部門や外部の法律専門家と連携し、ライセンス上のリスクを評価し、適切な対応（商用契約の締結、代替ソリューションへの移行など）を検討することが不可欠です。

今回のライセンス変更は、オープンソースの経済モデルや定義に関する広範な課題の一部であり、今後も様々なプロジェクトで同様の動きが見られる可能性があります。Redisのユーザーは、自身のビジネスへの影響を最小限に抑えつつ、この変化に適応していく必要があります。情報収集を怠らず、不確実な点については専門家の助言を求めることが、賢明な判断を下すための鍵となります。

Redisの進化は続きますが、その基盤となるライセンスが変更された今、私たちは新しいルールの下で、この素晴らしいデータベースとどのように向き合っていくのか、真剣に考える時期を迎えています。