Redis、デュアル・ソースアベイラブル・ライセンスを採用
(redis.com)- Redisは Redis 7.4 からBSD 3-Clauseでの配布を終了し、今後Redisを RSALv2 または SSPLv1 で提供することで、ライセンスの境界を大きく変更する
- ソースコードはRedis Community Editionとして引き続き無料で提供されるが、新しいライセンスは OSI定義のオープンソース には該当しない
- RedisはCoreとStackを統合し、検索、JSON、ベクター、確率的データ構造、時系列データモデルを1つの無料パッケージにまとめる計画
- 内部・個人利用、クライアントライブラリ、統合パートナー、既存のRedis Enterprise顧客は影響を受けないが、競合するマネージドサービス は新しいRedisソースコードを無料では使えない
- Redis 8からRedis Stackの機能がRedis本体に含まれる予定で、その後、別個の Redis Stackビルドのサポート終了 が進められる
Redisのライセンス変更範囲
- Redisは今後リリースされるすべてのRedisバージョンを ソースアベイラブル・ライセンス で配布する
- Redis 7.4からRedis Coreソフトウェアは Redis Source Available License v2 または Server Side Public License v1 のいずれかで利用できる
- 今後は BSD 3-Clause ライセンスでは配布されない
- Redisのソースコードは Redis GitHubリポジトリ を通じてRedis Community Editionとして引き続き無料提供される
- RSALv2とSSPLv1はいずれも OSI承認ライセンスではなく、それぞれ利用制限がある
Redis Stackの統合と製品構成の変化
- 今後のソースアベイラブル・リリースではRedis Coreと Redis Stack を統合する
- 統合対象は検索、JSON、ベクター、確率的データ構造、時系列データモデル
- 1つの無料ダウンロードパッケージとして提供され、Redisは次の用途に利用できる
- 高性能な キー/バリューストア
- ドキュメントストア
- クエリエンジン
- 生成AIアプリケーション向けの低レイテンシな ベクターデータベース
- Redis 8から、従来Redis StackでRSALv2またはSSPLv1として提供されていた新しいデータ型と処理エンジンが標準提供項目に含まれる予定
- Redis 8の提供後は別個のRedis Stackビルドが不要になり、Redis Stackのサポート終了 が進められる
変更の背景とRedisの立場
- RedisはRedis Stackディストリビューションの高度なRedisモジュールにすでに デュアルライセンス を適用しており、Redis 6以降、redis.ioからのダウンロードの50%以上がRedis Stackによるものだったとしている
- 複数のディストリビューションを同時に維持する構造が、Redisの今後の開発推進と衝突すると見ている
- オープンソースディストリビューション
- ソースアベイラブルディストリビューション
- オンプレミスおよびクラウドプラットフォームに最適化された商用ソフトウェア
- Redisは、主要クラウドサービスプロバイダーがRedisの投資とオープンソースコミュニティを商品化していると見ている
- 今回の変更は、機能豊富な無料ソフトウェアとエンタープライズ製品へ投資を継続するために 商用利用を管理 しようとする措置
- この変更により、Redisはもはや OSI定義 上のオープンソースではない
ユーザーとパートナーへの影響
- Redisの既存オープンソース版や新しいデュアルライセンスリリースを 内部・個人用途 で使うエンドユーザーは影響を受けない
- Redisと連携するクライアントライブラリやその他の統合を作成したパートナーにも変更はない
- Redisが責任を持つすべてのRedisクライアントライブラリは オープンソースライセンス を維持する
- 既存のRedis Enterprise顧客は、個別に交渉されたライセンス条件で技術提供を受けるため影響はない
- Redis Community EditionまたはEnterpriseを非競合の形で活用する統合およびマネージドサービスパートナーは、Redisとのパートナーシップを通じて引き続きソリューションを構築・運用・提供できる
- Partner Programは今後、Redisの技術、機能、リリースへの独占的アクセスを提供する
クラウドサービスと競合製品の制限
- 新しいライセンスの下でRedisホスティングサービスを提供する クラウドサービスプロバイダー は、Redisのソースコードを無料で利用できない
- たとえばクラウドサービスプロバイダーは、RedisコードのメンテナーであるRedisとライセンス条件に合意した後でなければRedis 7.4を提供できない
- Redisの「競合する提供」とは、Redisコードベースから派生し、Redis商用製品の機能と大きく重なり、第三者に販売される製品を指す
- 有償サポート契約を通じた販売も含まれる
- Redis Enterprise SoftwareまたはRedis Cloudと競合して販売されるソリューションの中でRedisをホストまたは組み込む場合が例に挙げられる
- Redisを活用していても、Redis自体と具体的に競合しないソリューションには影響しない
- 特定のユースケースに関する問い合わせは redis_licensing@redis.com に案内されている
RSALv2とSSPLv1の条件
- RSALv2 は非コピーレフト性のパーミッシブなライセンスで、ソフトウェアの使用、コピー、配布、提供、派生著作物の作成権を認める
- RSALv2の主な制限は2つ
- ソフトウェアを商用化したり、マネージドサービスとして他者に提供したりできない
- ライセンス、著作権、その他の告知を削除または隠すことができない
- SSPLv1 はAGPLをベースとしており、サービスとして提供する場合、サービス全体のソースコードをSSPLで公開しなければならない
- 管理ソフトウェア、ユーザーインターフェース、API、自動化ソフトウェア、監視、バックアップ、ストレージ、ホスティングソフトウェアが含まれる
- MongoDBがこのライセンスの発行者
- SSPLでライセンスされたソフトウェアを修正したバージョンは、別のライセンスで再配布できない
- デュアルライセンスでRSALv2を選択した場合、第三者にサービスとして機能を提供しないなど、RSALv2の制限を守る範囲で修正と再配布が可能
既存BSD版とセキュリティパッチ
- ライセンス変更は 遡及適用されない
- 変更前のすべてのソースコードとリリースはBSD 3-Clauseライセンスの下に残る
- ユーザーはそのライセンス条件を守る限り、既存のBSD版を無期限に継続利用できる
- RedisはRedis Community Editionが提供されるまで、現行の セキュリティポリシー に従い、当該リリースのセキュリティアップデートと重要な不具合修正を引き続き提供する計画
- 既存のBSD 3-Clause版に対する重要なセキュリティパッチのバックポートはRedis Community Edition 9.0のリリース前まで提供され、それ以降のパッチは新しいデュアルライセンスで提供される
名称、貢献、コード混在条件
- Redis 7.2以前のリリースは引き続き Redis OSS と呼ばれる
- Redis 7.4から公開され無料で提供されるバージョンは Redis Community Edition と呼ばれる
- 製品名には今後「Redis」または「for Redis」を使用できないが、製品説明でRedis互換またはlegacy-Redisベースであると明記することはできる
- コミュニティからの貢献は引き続き受け付けるが、貢献のレビューには Contributor License Agreement への同意が必要
- RSALv2またはSSPLv1のコードと他ライセンスのコードは、各コンポーネントが自身のライセンスを維持し、GPLのような強いコピーレフトコードと混在させない条件で併用できる
- 組織内部でRedisをサービスとしてホストすることは許可され、組織には関連会社と子会社が含まれる
1件のコメント
Hacker News の意見
これは Hashicorp が追い詰められて売却先を探すことになったのと同じように、Redis Labs も壊してしまう可能性が高く、Redis Labs をまねようとする側を止めることもできなさそうです。
本当に被害を受けるのは、法的な面倒なしに Redis キャッシュを使いたい小さなスタートアップです。AWS は Redis をフォークできますし、むしろそのフォークをパーミッシブライセンスで出せば、Redis Labs 側のほうがライセンス面でより悪い選択肢になりかねません。
難しい選択ではありますが、コードをプロプライエタリに保つか、Apache または MIT を貫くほうがよいと思います。途中でライセンスを変えるのは本当にいただけず、逆効果になる運命に見えます。
オープンソースとは、ユーザーがソフトウェアを所有できるようにするものです。お金を稼ぐために法的な抜け道でこれを迂回しようとすると、大企業のチームではなくユーザーが傷つきます。Redis は常にパーミッシブなオープンソースプロジェクトであり、まさにその点によって成功しました。その条件を変えれば、今後の計算式も変わり、関係者全員に悪い結果を予告することになります。
PostgreSQL のような財団が所有するソフトウェアと、企業が所有するオープンソースの違いを、もっと明確に見るべきです。「株主価値の最大化」に焦点を合わせると、ユーザーの自由を守るという目標は結局後回しにされるしかありません。
Redis コミュニティの立場では、Antirez が雇用関係とプロジェクトの所有権を切り離し、非営利側に委ねるほうがはるかによかったはずです。Apache Redis のような形のほうがコミュニティにとってよく、Redis Labs もその周辺でプロプライエタリな拡張やクラウド事業を作れたはずです。
企業がコアソフトウェアをパーミッシブライセンスで公開すると、より大きな競合がやって来て、そのソフトウェアを再配布するソリューションを売ってしまう事例を何度も見てきました。
企業の中心的な目標が利益であれば、これは存続を脅かす脅威です。逆に企業の目標が、非営利の管理者としてソフトウェアが存続し続けるようにすることであれば、これは大成功です。
コア製品ではない補助ソフトウェア、たとえば直接販売して収益を得る対象ではないものの、開発中に作った有用なツールには、この論理は当てはまりません。
今回のライセンス変更はまさにその問題、つまりクラウドのハイパースケーラーがただ乗りできないようにするためのものです。
私には、より良い AGPL のように聞こえます。哲学的なニュアンスや OSI の承認リストには関心がなく、結局のところ AGPL よりはるかに制限が少ないです。ソースコードがあり、ローカルで動かせ、自分のプロジェクトでも商用プロジェクトでも、職場でも、ベアメタル、VM、Docker、k8s、Azure でも同じように使えます。
Microsoft がすでに受け取っているプレミアムの一部を分け合わなければならないという事実は、私には関係ありません。むしろ持続可能なビジネスモデルを見つけた点は称賛に値します。
OSS 開発者は著作権を保持しています。パブリックドメインを除けば、ライセンスや条件を変更できるのは作者だけです。ユーザーはソフトウェアとコードでさまざまなことを行えるライセンスを受けるのであって、所有権を得るわけではありません。
完全に同意しますし、Cory Doctorow の主張にまた一つ事例が加わったように感じます。
今ごろはすでにフォークが進行中なのだと思う。会社が自らの開発者コミュニティと自分から断絶していく姿を見るのは少し悲しい
なぜそうするのかは理解できるが、長期的にうまくいくとは思わない
Redisユーザーの大半は、その背後にいる会社に一銭も払ったことがないし、自分も同じだ。お金を稼ぐためにこうするのは理解できるが、私の行動は変わらない。単にフォークを使うだけだ。他の大多数のRedisユーザー、外部コントリビューター、Redisを商用提供していたすべてのクラウド事業者もそうするだろうし、時間がたてば現在のRedis社員のかなりの数もそちらへ移るかもしれない
商用ユーザーやクラウド事業者が多いので、彼らが組織化するのに時間はかからないと思う。すでに有料ユーザーが多いのだから、実質的にそうならざるを得ない
Terraform、Elasticsearch、Red Hatなどでも、すでに似た前例がある。対象ユーザーと潜在顧客の相当数がオープンソースのフォークに依存するように仕向けるのは、事業戦略として間違った方向に見える
OracleがSunのオープンソースプロジェクト、たとえばmysql、hudson、openofficeなどを引き継いだときも、支配力の大半をすぐに失った。Oracleのクローズド製品を使うよう説得しようとした試みは、あまり成果がなかった。Javaでさえ最終的にはある程度後退し、今の中心はopenjdkだ。いくつかの銀行を除けば、Oracle JDKを使う人はほとんどいない。そうする必要がないし、Oracleもずいぶん前に利点があるふりをやめた。すべての開発はOpenJDKで行われ、認定ビルドを提供する会社も複数ある
個人的にElasticsearchとOpensearchのコンサルティングをしているが、最近の顧客の大半はOpensearchをデフォルトにしている。自然にそう流れている。みな無料でオープンソースの選択肢を選ぶ
結論は一つしかない。現在のRedisユーザーの大多数が使うことになるRedisフォークが作られるだろう
[1] https://www.microsoft.com/en-us/research/blog/introducing-ga...
企業としては、完全に移行しないために、あるいは短期的にマイグレーションする間、値上げを受け入れることがあり得る
短期的な離脱を防ぐために、提供者が「時間を買う」形で価格を低く保ち、プロジェクトがフォークと十分に異なって移行がはるかに難しくなった後で値上げすることもできる
いずれにせよ長期的には、さまざまな規模の多くの会社を支援し続けるより、少数の企業から大きな収益を得られる。気に入らないが、機能し得るようには見える
MySQLコミュニティを分断し、利用と外部開発を萎縮させ、プロジェクト全体の速度を落とすだけでも、十分な投資収益率を得られた可能性がある
こうしたプロジェクトの大きな原動力は引き続きホスティング収益であり、だからライセンス変更が起きる
流れを見ると、プロジェクトを所有する会社に合うオープンソースはライブラリだけのように思える。プログラム、たとえばデータベースのようなサーバーソフトウェアなら、ソース公開型になるか、財団の下にあるべきだ。難しく、答えが何なのかは分からない
複雑なプログラムにも寛容なオープンソースライセンスを再び戻せるモデルを見てみたいが、まだ実行可能な方法は見えない。商標権の執行とオープンソースコード、そしてライセンス済みビルドだけを提供する方式かもしれない
いずれにせよ今後も、人気オープンソースソフトウェアの興隆と衰退、あるいはライセンス変更を見続けることになるだろう。開発者や会社が最初にオープンソースで始めるメリットは大きすぎるし、後から変更しようとする圧力も大きすぎる
少なくともRedisが世界に与えた価値は、持ち去った価値よりはるかに大きかったと認めたい。本当に圧倒的な差だ
フォークがどれほど早く出て成功するのか、そして5年後にRedisという会社の売上成長曲線がどうなっているのかは興味深い
ライセンスのことはよく分からないが、基盤技術を作った中小規模の会社が寡占的なクラウド巨人にコモディティ化され、高い価格で再販される状況には大いに共感する。むしろ、ここまで時間がかかったことに驚く
企業とオープンソースの両方が健全なエコシステムを望むとして、ライセンス変更以外にどんな代替案があるのか気になる
単一の会社が財団の外へ実質的に「フォーク」して抜け出すと決めた事例は多く、コミュニティは結局同じ結果を迎える
https://spdx.org/licenses/AGPL-3.0-or-later.html
作業道具を作る人たちにも請求書の支払いがある
ある意味では、FOSSの夢が失敗したことについて開発者自身にも責任がある
ゆっくりとパブリックドメインとシェアウェアの時代に戻りつつある
オープンソースで収益を得るモデルはサポートサービスだと、人々はいつも言っていた。たとえば、ある会社が Postgres を使うなら、オンプレミス構成で専門家が支援し、障害対応をしてくれる、というような形だ。
しかし「クラウド」の時代には、企業は Amazon、Microsoft、Google などが提供するマネージドサービスをそのまま使うだけになり、プロジェクトのメンテナーや周辺の人々の金銭的機会は事実上消えてしまった。OSS で必死に働いた結果、AWS が何も還元しないまま数百万ドルを稼いでいくのを見たい人はいない。
Madelyn Olson は AWS に雇用されながら、数年にわたって大変な仕事をこなし、他の Redis コア開発者たちの信頼を得てコアメンテナーになった。彼女や他の AWS 開発者たちは Redis のコアエンジンに多く貢献してきた。彼らもまた Redis コミュニティのために懸命に働いてきたと言える。
関連する貢献については、こちらでさらに読める: https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
より多くのオープンソースプロジェクトは SSPL を採用するか、Llama 2 のように無料利用できる企業規模に制限を設ける方式を試すべきだ。たとえば、オープンソースではあるが、数十億ドル規模のクラウド巨大企業には適用しない、という形だ。
個人開発者が貢献したのは、AWS のただ乗りを可能にするためではなかった。
プロジェクトがより制限的なライセンスへ向かう最大の理由は AWS だ。AWS がすべきだった正しいことは、元の作者や企業の仕事を尊重し、元の開発者が支援する製品を後押しすることだった。代わりに AWS は、OSS 製品が成功するのを見ると競合製品を作る。より密接な統合とマーケティング力のため、サードパーティベンダーに勝ち目はない。
さらに Amazon と AWS は、オープンソースの大きな、もしかすると最大の受益者でありながら、ほとんど還元していない。Google、Microsoft、さらには Oracle でさえ、Amazon より多くオープンソースに貢献している。
CLA のあるプロジェクトに貢献したことはないし、雇用主が報酬を払わない限り、今後もそのつもりはない。
しかし FOSS の長期的な存続可能性のためには、FOSS 開発者を事実上搾取する巨大企業から自分たちを守るための制限が必要かもしれない。
Redis、Mongo、ES、HashiCorp 製品群、ビッグデータエコシステム全体が、AWS による提供を通じてより広く知られるようになった。AWS や他の大手クラウドプロバイダーが後押ししていないため、何年も開発されているのにいまだに人々に知られていない無名のデータベースも数多くある。
また、自由なライセンスのおかげで利用と人気が伸び、多くのプロジェクトがバグ報告、PR、パッチといった貢献を受けている。SSPL や BSL 系のライセンスが付いたものには、あまり貢献したくない。あとで自由に使えないものに時間を無駄にしたくないからだ。
Redis が Llama 2 と似た制限を付けて登場していたら、最初から失敗していただろう。主な利用者は企業であり、Llama 2 が人気を得た主な理由は、個人が個人用途で使える高品質な LLM を早い段階で提供したからだ。
RESP と互換性のあるキー・バリューストアは、特別にすごいものではない。Microsoft もつい先ほど、MIT ライセンスで独自実装の garnet を公開した。Redis の価値は常に、無料でオープンソースであることと、それを支えてきたコミュニティにあった。いまや Redis を使う最大の理由を捨てたことになる。
しかし私が知っているのは事実上その事例だけで、MongoDB、Redis、Memcached、MySQL、PgSQL など、ほぼすべての他のケースではそうではない。
Redis Inc. は https://github.com/redis/redis/ プロジェクトを、3条項 BSD ライセンスから、OSI 承認を受けていない2つのライセンスによるデュアルライセンスへ移行している。
以前には「Redis core license は 3-Clause-BSD でライセンスされており、今後も常にそうである」と述べていた。(https://redis.com/blog/redis-labs-modules-license-changes/)
サポート終了が心配なら、Redis 7.4が新ライセンス下での最初のリリースになり、7.2が旧ライセンスでの最後のリリースになる
Redisは特定の時点で追加の2リリースをサポートする: latest major.(minor-1), (major-1).(last-minor)
大まかには、8.0が出ると6.2のサポートが終了し、7.6または8.0が出ると7.2のサポートが終了するという意味
過去のリリースを見ると、8.0は2025年3〜5月ごろに出ると予想される。したがって 3BSDライセンス 下のRedisに依存しているなら、それに合わせて計画する必要がある
Ubuntuはredisを
universeリポジトリでパッケージ化しているため、セキュリティアップグレードはUbuntu Proの顧客にのみ提供される。したがってUbuntu 20.04では、Ubuntu ProのESMユーザーを除けば、2024年4月にredisのアップグレードが止まるDebian 11/12はRedis 6.0/7.0を追随しているため、7.2のパッチをバックポートする責任がある。7.2がセキュリティアップデートを受けず、7.4ブランチでのみ提供される場合、これがどうなるかははっきりしない
直接の利用形態が新ライセンスに合っていても、間接的に影響を受ける可能性がある。ディストリビューションが次のリリースで公式リポジトリからredisを除外する可能性が高いため、次のディストリビューションのアップグレード周期でこれを考慮する必要がある
(https://endoflife.date/redisをメンテナンスしているので、サポート終了とサポートにどのような影響があるのか明確に分かる人がいれば、PRをマージできる)
新ライセンスであるSSPLは、少なくとも利用分野の制限のため、オープンソースではない可能性が高い: https://opensource.stackexchange.com/questions/7522/sspl-and... https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
https://opensource.org/definition-annotated#6
オープンソース、そしてある意味では自由ソフトウェアの核心がまさにこの点。コピーレフトライセンスには制限があるが、その制限に従えば、そのソフトウェアで望むものを作れる。SSPL、FSL、BUSLライセンスは、特定の商業的な形での競争を完全に妨げる
ほとんどのビジネスモデルがコピーレフトに従いたがらないからといって、それがオープンソースでないことにはならない。単にそのビジネスモデルに合わないだけ
SSPL、BSL、FSLのような新ライセンスはますます人気を得ており、それには相応の理由もある。20年前にはAWSがFOSSを世界中に再販売する状況はなかったので、条件は今とは大きく違っていた
制限があるため「オープンソース」ではないが、次に近い用語である「ソース公開型」も現実をうまく反映していない。ソースコードが技術的にどこかにあるだけ、という意味に近いからだ
ElasticSearch、Sentryなどは今でも公開の場で開発されており、プロジェクトと無関係な人もPRを送ることができ、プロジェクトの背後にある会社と公然と競争しようとしているのでなければ、誰でも望むことができる
同時にMicrosoftがGarnetを公開した: https://github.com/microsoft/garnet
タイミングがよい
その論理は、MSは餌をまいて、必要になったらライセンスを変えるだろうから、常にオープンソースライセンスを維持するRedisのほうがよい、というものだった。すごい予測だった
RedisとHashicorpの技術創業者たちは、それぞれの会社がFOSSから離れて大きな嵐に見舞われる前に退いたことになる。時系列が間違っていなければ、という話だ
彼らがこのことを事前に知っていて反対したのか、知っていたが評判への打撃を避けたかったのか気になる。この動きに同意するかどうかにかかわらず、評判の毀損はある。それとも、彼らが去ったからこそ変更を押し進められたのだろうか
完全に推測だが、Hashiで見たことがRedisでも繰り返されているように見えて目につく
Hashiとの類似性は自分も見逃さなかった