Redisライセンス変更を徹底解説【SSPLv2 / RSALv2】

By /

Redisライセンス変更を徹底解説【SSPLv2 / RSALv2】

はじめに：世界中の開発者を揺るがしたRedisのライセンス変更

データ構造サーバーとして、キャッシュ、メッセージブローカー、データベースなど、幅広い用途で利用されているRedisは、その高速性、柔軟性、そしてオープンソースとしての自由度から、世界中の開発者や企業に愛されてきました。しかし2024年3月20日、この信頼性の高いインメモリデータストアのライセンスが、従来のBSDライセンスから、より制限の強い2つのライセンス、SSPLv2とRSALv2へ変更されることが発表されました。

この発表は、Redisを基盤とするサービスやシステムを構築・運用している多くの人々にとって、大きな衝撃となりました。オープンソースの代表格の一つであったRedisが、なぜ、どのようなライセンスに変更されたのか、そしてこの変更が私たちの開発やビジネスにどのような影響を与えるのか。この記事では、Redisのライセンス変更について、その背景、新しいライセンスの詳細、そしてユーザーが知っておくべき影響と今後の展望について、約5000語にわたって徹底的に解説します。

Redisのこれまでのライセンス：自由度の高いBSDライセンス

Redisは長らく、3条項BSDライセンス（3-clause BSD License）の下で配布されてきました。BSDライセンスは、非常に自由度の高いオープンソースライセンスの一つとして知られています。その主な特徴は以下の通りです。

  • ソースコードの自由な利用、改変、再配布: 誰でも自由にRedisのソースコードを入手し、使用目的を問わず利用できます。
  • 商用利用の許諾: 営利目的での利用や、製品への組み込みも自由に行えます。
  • バイナリ形式での再配布の許諾: ソースコードだけでなく、コンパイル済みのバイナリ形式で再配布することも可能です。
  • 派生ソフトウェアのライセンスに制限なし: BSDライセンスで配布されているソフトウェアを改変して作成したソフトウェアは、オリジナルのBSDライセンスを引き継ぐ必要がなく、独自のライセンス（プロプライエタリライセンスを含む）で配布することができます。
  • 表示義務: ただし、著作権表示、ライセンス条文、免責事項をソフトウェアまたは関連ドキュメントに含める必要があります。

このBSDライセンスの最大の利点は、その「無保証かつ責任を問わない」という性質と、派生ソフトウェアへのライセンス継承義務がない点にあります。これにより、多くの企業が安心してRedisを自社の製品やサービスに組み込み、商用利用することができました。特に、Cloud ProviderがRedisをマネージドサービスとして提供する上で、BSDライセンスはその自由度の高さから非常に都合の良いものでした。Redisがこれほどまでに普及し、多くの開発者に受け入れられた背景には、このBSDライセンスがもたらす高い自由度が大きく貢献していたことは間違いありません。

Redisの開発者であるSalvatore Sanfilippo氏（別名：antirez）が当初BSDライセンスを選択したのも、ソフトウェアを広く普及させ、多くの人々に利用してもらうことを目指したためです。コミュニティ主導の開発と、オープンなエコシステムの構築に焦点を当てていた時期には、このライセンスは理想的な選択でした。

なぜライセンス変更が必要になったのか：オープンソースの「搾取」問題

では、なぜこれほど成功したBSDライセンスから、より制限の強いライセンスへと変更する必要があったのでしょうか。その最大の理由は、「オープンソースの搾取」という、近年多くのオープンソースプロジェクトが直面している課題に起因します。

「オープンソースの搾取」とは、主に巨大なCloud Providerが、著名なオープンソースソフトウェア（OSS）を、その開発元に対して適切な貢献や対価を支払うことなく、自社のマネージドサービスとして提供し、大きな収益を上げている状況を指します。

Redisの場合、その開発とメンテナンスを主導してきたのは、Redis Ltd.（旧Redis Labs）という営利企業です。Redis Ltd.は、OSS版Redisの開発を進めると同時に、エンタープライズ向けの拡張機能やサポート、そしてRedis Cloudといったマネージドサービスを提供することで収益を上げています。彼らのビジネスモデルは、OSS版Redisを広く普及させることでブランド力を高め、エンタープライズ版やCloud版の有料サービスへとユーザーを誘導するというものでした。

しかし、BSDライセンスの高い自由度により、Amazon Web Services (AWS) のElastiCache for Redis、Google Cloud Platform (GCP) のMemoryStore for Redis、Microsoft AzureのAzure Cache for RedisといったCloud Providerが、OSS版Redisのソースコードをほぼそのまま利用し、自社のインフラ上で高可用性やスケーラビリティといった付加価値を付けて、マネージドサービスとして提供し始めました。これらのサービスは、Redis Ltd.が提供するRedis Cloudと直接競合します。

Cloud Providerは膨大な顧客基盤を持っているため、彼らが提供するマネージドサービスは急速に普及しました。一方で、これらのCloud Providerは、OSS版Redisの核心的な開発に対して、技術的貢献や資金的支援を十分に提供しているわけではありませんでした（もちろん、一部の貢献はあったとしても、彼らが上げる収益規模から見れば微々たるものだ、とRedis Ltd.は主張しています）。つまり、Redis Ltd.が投資して開発・メンテナンスしたOSS版Redisが、競合であるCloud Providerの主要な収益源となってしまっている、という状況が発生していました。

この状況は、Redis Ltd.にとって深刻な問題でした。OSS版の開発には多大なコストがかかりますが、その開発努力が報われず、むしろ競合他社の利益につながってしまうからです。このような状況が続けば、OSS版Redisの開発への投資が減少し、プロジェクト全体の持続性が危ぶまれることになります。Redis Ltd.としては、OSS版Redisの開発を継続し、エコシステム全体を健全に保つためにも、開発コストを回収し、収益を確保する必要がありました。

この問題はRedisに限ったことではありません。MongoDBが2018年にGNU AGPLv3からSSPLにライセンスを変更した件や、Elasticsearchが2021年にApache License 2.0からSSPLとElastic Licenseにライセンスを変更した件も、同様の背景によるものです。Cloud ProviderによるOSSのマネージドサービス提供が、OSS開発企業のビジネスモデルを脅かすという構図は、多くの著名なOSSプロジェクトで顕在化していました。

Redis Ltd.は、この「オープンソースの搾取」問題に対処し、自社のビジネスモデルを保護しつつ、OSS版Redisの開発を持続可能なものとするために、ライセンス変更という大きな決断を下したのです。彼らは、OSS版Redisのソースコードへのアクセスは維持しつつも、その「サービス提供」という特定の利用形態に対して制限を設けることで、Cloud Providerとの競争環境を是正しようと考えました。

新しいライセンス：SSPLv2とRSALv2の詳細

Redis Ltd.がOSS版Redis（バージョン7.4以降）に適用した新しいライセンスは、以下の2種類です。

  1. SSPLv2 (Server Side Public License v2)
  2. RSALv2 (Redis Source Available License v2)

これらのライセンスは、Redisのソースコードリポジトリに含まれるファイルごとに適用されます。具体的には、ほとんどのコアコンポーネントにはSSPLv2が、一部のモジュールや拡張機能にはRSALv2が適用されるようです。

これらのライセンスは、従来のBSDライセンスと比較して、利用や配布、特に「サービス提供」に関する制限が強化されています。それぞれのライセンスについて詳しく見ていきましょう。

SSPLv2 (Server Side Public License v2)

SSPL (Server Side Public License) は、MongoDB社が考案したライセンスであり、GNU AGPLv3（Affero General Public License v3）をベースにしています。SSPLv1はMongoDBが採用しましたが、オープンソースコミュニティからは、OSI（Open Source Initiative）が定めるオープンソースの定義を満たさないとして、公式なオープンソースライセンスとしては認められていません。Redisが採用したのは、その改良版であるSSPLv2です。

SSPLv2の基本的な考え方は、AGPLv3と同様に、「ネットワーク経由で機能を提供するサービスとしてソフトウェアを実行する場合、そのサービスの基盤となるソースコードを公開しなければならない」という点にあります。しかし、SSPLv2はAGPLv3よりも、公開すべきソースコードの範囲を拡大しています。

SSPLv2の主な条項とポイントは以下の通りです。

  • ソースコードの公開義務: ソフトウェアを改変して配布する場合、あるいはネットワーク経由で「Service under the License」として提供する場合、改変後のソフトウェアのソースコード全体を公開する必要があります。
  • 「Service under the License」の定義: ここがSSPLv2の最も重要な、そして論争の的となる部分です。「Service under the License」とは、SSPLv2の下でライセンスされるソフトウェアの機能性を、顧客や他のユーザーに対してネットワーク経由で提供するサービスを指します。SSPLv2の下でライセンスされるソフトウェアを、他のソフトウェアやサービスと組み合わせて提供する場合、その「サービス全体の基盤となるソースコード」を公開する義務が発生します。
  • 公開すべきソースコードの範囲: 「サービス全体の基盤となるソースコード」には、SSPLv2の下でライセンスされるソフトウェア自体だけでなく、それを動かすための管理ソフトウェア、ユーザーインターフェース、API、自動化スクリプト、さらにはバックアップ、ストレージ管理、ホスティング、オーケストレーションに関するソフトウェアなど、サービス提供に必要なすべてのソースコードが含まれる、と解釈される可能性があります。この「すべて」という範囲が非常に広く、Cloud Providerにとっては自社のインフラ全体のソースコードを開示するに等しいと見なされかねないため、大きな障壁となります。
  • 条件を満たせない場合の選択肢: SSPLv2の条件（ソースコード公開義務）を満たせない、または満たしたくない場合、ライセンス違反を避けるためには、開発元であるRedis Ltd.と別途商用ライセンス契約を結ぶ必要があります。

OSIによるオープンソース定義との関連:
SSPLv2は、OSIが定義するオープンソースライセンスの条件（特に、派生ソフトウェアに独自のライセンスを適用できる「派生著作物に対するライセンスの非差別」の条項）を満たさないと広く解釈されており、OSIによってオープンソースライセンスとは認められていません。これは、SSPLv2が「サービス全体の基盤となるソースコードの公開」という、OSS版Redis単体ではない部分にまでライセンスの効力を及ぼそうとしているためです。Redis Ltd.自身も、SSPLv2を「ソース利用可能（Source Available）」なライセンスと位置づけており、「オープンソース」とは明確に区別しています。

SSPLv1からの変更点:
SSPLv2は、SSPLv1で曖昧だったいくつかの点を明確化したり、範囲を調整したりしていますが、根本的な考え方である「サービス提供時のソースコード公開義務」は共通しています。Redis Ltd.は、SSPLv2がより広範な用途をカバーし、Redisの利用形態に適合するように調整されていると説明しています。

RSALv2 (Redis Source Available License v2)

RSALv2は、Redis Ltd.が独自に定義した「ソース利用可能」ライセンスです。SSPLv2と同様に、ソースコードは公開されており誰でも閲覧・学習できますが、利用や配布には特定の制限があります。

RSALv2の主な条項とポイントは以下の通りです。

  • ソースコードの利用・改変の許諾: 個人的な学習や非営利目的での利用、そしてソフトウェア内部での利用については、ソースコードの利用や改変が自由に許諾されます。
  • 「商用利用」の制限: RSALv2の下でライセンスされるソフトウェアを「商用目的」で第三者に提供することは制限されます。RSALv2における「商用目的」の定義は、「サービスとして提供すること」「製品に組み込んで再配布すること」など、収益を得ることを目的とした幅広い形態を含むと考えられます。ただし、自社の内部業務のために利用する分には、「商用利用」には当たらないと解釈されるのが一般的です。
  • 配布の制限: RSALv2の下でライセンスされるソフトウェア（改変版を含む）を第三者に配布する場合、いくつかの制限が付く可能性があります。
  • 条件を満たせない場合の選択肢: RSALv2の条件を満たせない場合、こちらもRedis Ltd.と別途商用ライセンス契約を結ぶ必要があります。

SSPLv2との使い分け:
Redis Ltd.は、OSS版Redisのコア部分にSSPLv2を、一部のモジュールや拡張機能（例えば、RedisSearch, RedisGraph, RedisBloom, RedisTimeSeries, RedisAIなど、これまで別途ライセンスされていたものがOSS版に取り込まれる場合など）にRSALv2を適用すると説明しています。
SSPLv2は主に「サービス提供」という形態に焦点を当てたライセンスであるのに対し、RSALv2はより広範な「商用利用」や「配布」に制限を設けるためのライセンスと言えます。どちらのライセンスも、Cloud Providerによるマネージドサービス提供や、競合他社がOSS版Redisをベースにした製品を開発することを難しくすることを目的としています。

どちらのライセンスも、OSSの定義を満たさない「ソース利用可能」ライセンスであるため、一般的に「プロプライエタリライセンスに近い、ただしソースコードは公開されている」ライセンスと見なされます。

ライセンス変更がユーザーに与える影響

Redisのライセンス変更は、様々な立場のユーザーに異なる影響を与えます。あなたのRedisの利用形態に応じて、どのような影響があるのかを確認しましょう。

1. 直接Redisをデプロイ・運用しているユーザー (自社インフラ、プライベートクラウドなど)

自社インフラ、仮想プライベートクラウド（VPC）、あるいはレンタルサーバー上の仮想マシンなどに、OSS版Redisを直接インストールして運用しているユーザーは、最も注意が必要です。

  • SSPLv2の条件確認: あなたが提供しているサービスが、OSS版Redisを「Service under the License」として提供していると見なされる可能性があるか、慎重に検討する必要があります。例えば、あなたが社内システムの一部としてRedisを利用しているだけであれば、通常は「Service under the License」には該当しないと考えられます。しかし、あなたが外部顧客に対してデータストア機能を提供するクラウドサービスの一部としてRedisを利用している場合などは、該当する可能性があります。
  • 「Service under the License」の解釈の難しさ: 前述の通り、SSPLv2における「Service under the License」の定義、特に「サービス全体の基盤となるソースコード」の範囲は曖昧であり、法的な解釈が必要です。これは、ユーザーにとって最も不確実性の高い部分です。もし、あなたのサービスがこれに該当すると判断された場合、サービス全体のソースコードを公開するか、Redis Ltd.と商用ライセンス契約を結ぶかの選択を迫られます。
  • RSALv2の条件確認: RSALv2が適用されるモジュール等を利用している場合、その利用形態がRSALv2の「商用利用」に該当しないか確認が必要です。例えば、OSS版Redisに同梱されている特定のモジュールを組み込んだ製品を開発し、それを顧客に販売・配布する場合などは、RSALv2の制限に抵触する可能性があります。
  • バージョンアップの方針: ライセンス変更はバージョン7.4から適用されます。ライセンス変更を避けたい場合、バージョン7.2など、変更前の最終バージョンを使い続けるという選択肢があります。ただし、この場合、それ以降に追加された新機能を利用できず、将来的に発見されるセキュリティ脆弱性に対する公式のパッチが提供されないというリスクがあります。セキュリティリスクは運用上非常に重要であるため、慎重な判断が必要です。
  • 公式サポートの可能性: ライセンス変更後のバージョンでSSPLv2またはRSALv2に抵触する利用形態の場合、OSS版の公式サポートは期待できず、Redis Ltd.の有償サポートやEnterprise版への移行を検討する必要が出てくるかもしれません。

2. Cloud Providerが提供するマネージドRedisサービスを利用しているユーザー

AWS ElastiCache for Redis、GCP MemoryStore for Redis、Azure Cache for RedisなどのCloud Providerが提供するマネージドRedisサービスを利用しているユーザーは、直接的なライセンス違反のリスクは低いと考えられます。

  • Cloud Provider側の責任: これらのサービスを提供しているCloud Provider自身が、Redis Ltd.と商用ライセンス契約を結ぶか、SSPLv2やRSALv2の条件を満たす（ただし、現実的にはCloud Providerが自社インフラのソースコードを公開することは考えにくいため、商用ライセンス契約を結ぶ可能性が高い）責任を負います。ユーザーは、Cloud Providerとのサービス利用契約に基づきサービスを利用するため、個々のユーザーがRedisのライセンスを直接遵守する必要はない場合が多いです。
  • 間接的な影響の可能性: ただし、ライセンス変更は間接的な影響を与える可能性があります。
    • 価格変動: Cloud ProviderがRedis Ltd.へのライセンス料支払いをコストとして価格に転嫁する可能性があります。
    • サービス内容の変更: ライセンス変更によって、Cloud Providerが提供できる機能（特にRSALv2が適用されるモジュールなど）に制限が出たり、提供されるバージョンが影響を受けたりする可能性はあります。
    • 代替サービスの提供: Cloud Providerによっては、OSS版Redisから派生した別のデータベース（例: Valkey）を基盤としたマネージドサービスを新たに提供する可能性も考えられます。
  • 各Cloud Providerの対応状況の確認: 各Cloud Providerは、ライセンス変更に対して独自の対応を発表しています（例: AWSとGoogle CloudはLinux Foundationの下でOSS版Redisのフォークプロジェクト「Valkey」を立ち上げを支援）。利用しているCloud Providerの対応状況を注視することが重要です。

3. OSS版Redisをフォークして開発・配布しているユーザー/企業

ライセンス変更後のバージョン（7.4以降）のOSS版Redisをベースに、独自の改変を加えて配布したり、それを基盤としたサービスを提供したりしようと考えている開発者や企業は、新しいライセンスの制約に直接影響を受けます。

  • SSPLv2/RSALv2の適用: フォーク元がバージョン7.4以降であれば、フォークしたソフトウェアにもSSPLv2およびRSALv2が適用されます。
  • ソースコード公開義務: SSPLv2が適用される部分を改変してサービス提供する場合、前述の厳しいソースコード公開義務が発生します。
  • 配布・商用利用の制限: RSALv2が適用される部分を含むソフトウェアを配布したり、商用利用したりする場合、RSALv2の制限を受けます。
  • ライセンス変更前のバージョンをフォーク: ライセンス変更前のバージョン（7.2以前）は引き続きBSDライセンスの下で利用可能です。このため、BSDライセンスの下で開発を続けたい開発者や企業は、バージョン7.2以前のソースコードをフォークするという選択肢があります。実際に、AWS、Google Cloud、Oracle、Ericsson、Snap Inc.などが中心となり、Linux Foundationの下でRedisのフォークプロジェクト「Valkey (発音: val-key)」が立ち上げられました。Valkeyはバージョン7.2をベースとしており、今後もBSDライセンスの下で開発が進められる予定です。
  • フォークプロジェクトへの貢献: BSDライセンスでの開発・利用を続けたい場合は、Valkeyのようなフォークプロジェクトへの貢献や、そちらへの移行を検討するのが現実的な選択肢となるでしょう。

4. Redisクライアントライブラリの開発者/利用者

Redisに接続するためのクライアントライブラリ（例: redis-py, Jedis, go-redisなど）の開発者や利用者は、ライセンス変更による直接的な影響をほとんど受けません。

  • クライアントライブラリの性質: クライアントライブラリは、Redisサーバーと通信するためのソフトウェアであり、Redisサーバー自体のソースコードを含んでいるわけではありません。通常、クライアントライブラリはApache License 2.0やMIT Licenseなど、BSDライセンスと同様に自由度の高いライセンスで配布されています。
  • ライセンスの非関連性: クライアントライブラリが接続するサーバーのライセンスが変更されても、クライアントライブラリ自体のライセンスや利用条件は変わりません。したがって、既存のクライアントライブラリをそのまま利用し続けることができます。

5. 特定のバージョンを利用し続けることの是非

ライセンス変更を避けたいユーザーの中には、ライセンス変更前のバージョン（7.2以前）を使い続けることを検討する人もいるでしょう。これはライセンス上は問題ありません。しかし、技術的なリスクが伴います。

  • セキュリティリスク: 新しいバージョンで発見・修正されたセキュリティ脆弱性に対するパッチが適用されません。これは、システムをセキュリティリスクに晒すことになります。特に本番環境で利用する場合、深刻な問題となり得ます。
  • 新機能の利用不可: 7.4以降で追加された新しい機能やパフォーマンス改善の恩恵を受けられません。
  • コミュニティサポートの縮小: 古いバージョンに関するコミュニティでの活動やサポートは、時間の経過とともに縮小していく傾向があります。
  • 移行コスト: いずれバージョンアップが必要になった場合、古いバージョンから新しいバージョンへの移行には大きなコストがかかる可能性があります。特に、ライセンス変更後の公式版（SSPL/RSAL）への移行か、Valkeyのようなフォーク版への移行かで、考慮すべき点が変わってきます。

これらのリスクを考慮すると、ライセンス変更前のバージョンを使い続けることは、あくまで一時的な回避策と考えるべきでしょう。

Redis Ltd.の戦略と将来展望

Redis Ltd.がライセンス変更に踏み切ったのは、前述の通り、収益を確保し、OSS版Redisの開発を持続可能なものとするためです。この変更は、彼らのビジネス戦略における大きな転換点と言えます。

  • 収益源の保護: SSPLv2とRSALv2を導入することで、Cloud Providerや競合他社がOSS版Redisをベースにしたマネージドサービスや製品で容易に収益を上げることを困難にします。これにより、Redis Ltd.自身の有料サービス（Redis EnterpriseやRedis Cloud）の競争力を高め、収益の確保を目指します。
  • OSS版開発への再投資: ライセンス変更によって得られた収益を、再びOSS版Redisのコア開発に投資し、プロジェクト全体の技術的進歩を加速させることを目標としています。Redis Ltd.は、今後もOSS版Redisの開発を主導していく意向を示しています。
  • エンタープライズ向け機能の強化: OSS版のライセンスを厳格化する一方で、エンタープライズ版やCloud版では、高度なセキュリティ、管理機能、スケーラビリティ、高可用性などを強化し、OSS版では利用できない付加価値の高い機能を提供することで差別化を図ります。
  • コミュニティとの関係性の変化: これまでのような、開発元とオープンなコミュニティが協調して開発を進めるというモデルから、Redis Ltd.が開発の主導権をより強く握り、特定の利用形態に制限を設けるというモデルへとシフトします。これにより、一部のコミュニティメンバーからは反発や懸念の声が上がっており、Valkeyのようなフォークプロジェクトの立ち上げにつながっています。

今後のOSS版Redisの開発は、Redis Ltd.が中心となって進められることになります。SSPLv2とRSALv2の下で開発される新しいバージョンは、Redis Ltd.のビジネス戦略に沿った方向性で進化していくでしょう。ユーザーは、この新しいエコシステムの中で、自身の利用形態に合った選択をする必要があります。公式版（SSPL/RSAL）を利用するのか、それともValkeyのようなフォーク版に移行するのか、あるいは代替技術を検討するのか。

代替となる可能性のある技術とフォークプロジェクト

Redisのライセンス変更を受けて、代替となる技術や、OSS版Redisのフォークプロジェクトが注目されています。

  • Memcached: Redisと同様に高速なインメモリキーバリューストアとして、古くから利用されています。シンプルで高速なキャッシュとして優れていますが、Redisが持つような豊富なデータ構造（リスト、セット、ハッシュ、ソート済みセットなど）や永続化機能、トランザクション機能などは持っていません。用途が限定的であれば有力な代替候補となります。MemcachedはBSDライセンスの下で開発が続けられています。
  • その他のキーバリューストア/インメモリデータベース:
    • Etcd, Apache ZooKeeper: 分散システムにおけるコンフィグレーション管理やサービス発見、分散ロックなどに特化しており、汎用的なキャッシュやデータストアとしての用途は限定的です。
    • RocksDB, LevelDB: オンディスクのキーバリューストアであり、インメモリデータベースであるRedisとは性質が異なります。
    • VoltDB, Apache Ignite: インメモリデータベースですが、リレーショナルデータベースに近い性質を持つものもあり、Redisとはアーキテクチャや用途が異なります。
  • 新しいフォークプロジェクト：Valkey: 前述の通り、AWS、Google Cloud、Oracle、Ericsson、Snap Inc.などが中心となり、Linux Foundationの下で立ち上げられたRedisのフォークプロジェクトです。Redisのバージョン7.2をベースとしており、Apache License 2.0またはBSDライセンスのような、従来のオープンソースライセンスの下で開発を継続することを目指しています（現時点ではライセンスは未定、BSDライセンスが有力視されています）。
    • 目的: Cloud ProviderやRedisのユーザー企業が、ライセンスの制約を受けずにRedis互換のデータストアを利用・開発できるようにすること。Redis Ltd.による開発から独立し、コミュニティ主導で開発を進めること。
    • 互換性: RedisのAPIやデータ構造との高い互換性を維持することを目指しています。これにより、既存のRedisアプリケーションからの移行コストを最小限に抑えることができます。
    • 今後の展望: Valkeyプロジェクトが今後どれだけ活発に開発され、コミュニティの支持を得られるかが、今後のRedis互換データベースのエコシステムを左右する可能性があります。Cloud ProviderがValkeyをベースにしたマネージドサービスを提供する可能性も高いです。

どの代替技術やフォーク版を選択するかは、必要な機能、性能、ライセンスの要件、コミュニティの活動状況などを総合的に考慮して判断する必要があります。

まとめ：ライセンス変更の要点とユーザーが取るべきアクション

Redisのライセンス変更は、その普及度の高さゆえに広範な影響を及ぼす重要な出来事です。今回の変更の要点を改めて整理します。

  • 背景: Cloud ProviderによるOSS版Redisのマネージドサービス提供が、開発元であるRedis Ltd.のビジネスモデルを圧迫しているという「オープンソースの搾取」問題に対処するため。
  • 変更内容: バージョン7.4以降のOSS版Redisのライセンスが、BSDライセンスからSSPLv2およびRSALv2に変更された。
  • 新しいライセンスの性質: SSPLv2とRSALv2は、ソースコードは公開されているものの、特定の利用形態（特に「サービス提供」や「商用利用」）に制限を設ける「ソース利用可能」ライセンスであり、OSIによってオープンソースライセンスとは認められていない。
  • 主な影響:
    • 直接運用ユーザー: サービス提供形態によっては、SSPLv2/RSALv2のライセンス条項（ソースコード公開義務や商用利用制限）に抵触する可能性があり、ライセンス解釈と対応（商用ライセンス契約またはソースコード公開）が必要になる。
    • クラウドマネージドサービスユーザー: 直接的なライセンス違反リスクは低いが、Cloud Provider側の対応（価格変動、サービス内容変更、代替サービス提供など）に影響を受ける可能性がある。
    • フォーク開発者: ライセンス変更後のバージョンをベースとするフォークはSSPLv2/RSALv2の影響を受ける。ライセンス変更前のバージョン（7.2以前）をベースとしたフォーク（例: Valkey）はBSDライセンスで継続される可能性が高い。
    • クライアントライブラリ利用者: ほとんど影響なし。
    • 旧バージョン利用: ライセンス変更前のバージョン利用は可能だが、セキュリティや機能面でのリスクを伴う。

ユーザーが取るべきアクション:

  1. Redisの利用状況の確認: 現在利用しているRedisのバージョン、そしてどのように利用しているか（自社運用かクラウドか、サービスとして提供しているか内部利用か、特定のモジュールを使っているかなど）を正確に把握する。
  2. 新しいライセンス条項の理解: SSPLv2とRSALv2の条項、特に「Service under the License」と「商用利用」の定義が、自身の利用状況にどのように適用される可能性があるかを理解する。
  3. リスク評価: ライセンス違反のリスク、旧バージョンを使い続けるリスク、移行コストなどを評価する。
  4. 今後の利用方針の検討:
    • ライセンス変更後の公式版（SSPLv2/RSALv2）を利用する場合: Redis Ltd.との商用ライセンス契約が必要か、あるいはSSPLv2の条件を満たせるか（現実的ではないことが多い）を検討する。
    • ライセンス変更前のバージョン（7.2以前）を使い続ける場合: セキュリティリスクや機能制限を許容できるか判断する。パッチが提供されない脆弱性への対応策を検討する。
    • フォーク版（Valkeyなど）への移行を検討する場合: フォークプロジェクトのライセンス、開発状況、コミュニティの活動状況を確認し、互換性や移行コストを評価する。
    • 代替技術への移行を検討する場合: 必要な機能、性能、移行コスト、運用負荷などを考慮し、他のデータストアと比較検討する。
    • クラウドマネージドサービスを利用している場合: 利用しているCloud Providerのライセンス変更への対応方針を確認する。
  5. 法的な専門家への相談: 特に「Service under the License」や「商用利用」の定義に関する解釈は複雑であり、自己判断が難しい場合があります。必要に応じて、ソフトウェアライセンスに詳しい弁護士などの専門家に相談することを強く推奨します。

補足と今後の展望

今回のRedisのライセンス変更は、オープンソースソフトウェアのビジネスモデルが直面する課題を改めて浮き彫りにしました。Cloud Providerによるマネージドサービスが成功する一方で、その基盤となるOSSの開発元が収益確保に苦労し、ライセンス変更に踏み切るというケースは、今後も他のOSSプロジェクトで発生する可能性があります。

一方で、Valkeyのようなコミュニティ主導のフォークプロジェクトの立ち上げは、ライセンスの制約を受けずにOSSの開発を続けたいという強いニーズがあることを示しています。今後、Redisエコシステムは、Redis Ltd.が主導するSSPL/RSAL版と、コミュニティ主導のフォーク版という、複数の流れに分岐していく可能性があります。

ユーザーは、自身のビジネスやシステムにとって最適な選択をするために、これらの動向を継続的に注視し、情報収集を怠らないことが重要です。ライセンス変更は一時的な混乱をもたらすかもしれませんが、これを機に、自社のデータストア戦略全体を見直す良い機会と捉えることもできます。

技術選択におけるライセンスの重要性は、今回の件で改めて強調されました。単に機能や性能だけでなく、将来的なライセンスリスクも考慮に入れた上で、賢明な判断を下していくことが、開発者や企業には求められています。

この記事が、Redisライセンス変更に関する皆様の理解を深め、今後の対応を検討する上での一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール