オープンソース哲学の実体：大企業のただ乗りを守る信念体系

SSPLが登場するたびにコミュニティは憤慨する。「オープンソースの哲学を裏切った」「OSI認定も受けていないライセンスだ」「本物のオープンソースじゃない」。しかし、この憤りが実際に守っているものは何か。

SSPL — Server Side Public License

MongoDBが2018年に制定したライセンスだ。¹ 核心条項はただ一つ：ソフトウェアをサービスとして提供するなら、そのサービスを構成するスタック全体（インフラ、管理ツール、監視システムを含む）をオープンソースとして公開しなければならない。AWSのように他者のオープンソースをそのままクラウドサービスとして販売しながら何も返さない構造を防ぐ意図で設計された。OSI（Open Source Initiative）は「過度に制限的」としてオープンソースと認定しない。²

Redisの騒動：誰が何を盗んだのか

RedisはBSDライセンスで長年公開されていた。世界中の開発者がコードを貢献し、バグを修正し、ドキュメントを書いた。そしてAWSはそれをそのまま持っていき、ElastiCacheという名前の管理型サービスとして販売した。

AWSはRedisに公式メンテナー（Madelyn Olson）を置き、TLSサポートやフェイルオーバー機能などを貢献した。³ まったく貢献がなかったわけではない。しかし問題は貢献対比の収益の不均衡だ。SSPL転換前の基準で、外部の非従業員コントリビューターがコミットの54%を担当していた。にもかかわらず、Redis Ltdに還元される収益はなかった。AWSがRedisのトラフィックの相当部分を吸収し、Redisを作った開発者たちはサーバー費用とメンテナンスコストに苦しんでいた。

オープンソースはあの頃、無法地帯の知識の宝庫だった。誰でも持っていけて、持っていっても何の義務もなかった。AWSはその宝庫を丸ごと持ち去り、自分の店で販売した。元の開発チームや開発者には何の価値も返ってこなかった。

Redis LtdがSSPLにライセンスを変更したのはこういう背景だ。⁴ 変更されたライセンスはRSALv2とSSPLv1のデュアルライセンスだ。SSPLの核心条項はシンプルだ：「クラウドサービスとして提供するなら、スタック全体をオープンソースとして公開せよ」。AWSはこれを受け入れる代わりに、2024年3月28日、AWS・Google・Oracle・Ericsson・SnapがLinux Foundation傘下にValkey を共同設立した。⁵ 悠々と逃げ出したのだ。

法の抜け穴：設計された略奪

オープンソースライセンスはクラウド時代を想定していなかった。

GPLが作られた当時の「商業的利用」は、ソフトウェアを改変して配布する行為だった。「配布時にソースを公開せよ」という条項はこのシナリオを前提とする。しかしAWSがやったことはソフトウェアを配布することではない。サーバーで実行してAPIで販売した。配布がないのでライセンス条項が発動しない。完全に合法的な略奪だ。

Note

この抜け穴を業界では ASPの抜け穴（ASP Loophole） または SaaSの抜け穴と呼ぶ。GPL、LGPL、BSD、MITはすべて「配布（distribution）」を義務発動のトリガーとする。しかしサーバーでソフトウェアを実行してネットワーク経由で結果だけを返す方式は、法的に配布ではない。ユーザーにバイナリを渡さないのでGPL条項がまったく発動しない。2000年代初頭に登場したASP（Application Service Provider）モデルで初めて問題となり、クラウド時代に規模が爆発した。

AGPL（GNU Affero GPL）はこの抜け穴を防ぐために登場した。「ネットワークでサービスしても、ソースを公開せよ」という条項を追加したのだ。SSPLはその延長線上で、AGPLより要求範囲をサービスのスタック全体に拡張した。技術的進化に対応したライセンスの進化だ。

「オープンソース純粋主義者」の実態

SSPLが発表されるたびにHacker NewsとRedditが沸き立つ。「オープンソース原則違反」「OSIが認定していない」「コミュニティを裏切った」。私自身もRedisのライセンス変更の知らせを、背景のわからない刺激的なタイトルで初めて目にした。「ライセンス変更」という結果はあったが、なぜ変えたのかはなかった。AWSが何年にもわたって何を持っていっていたかはなかった。メディアはその論争を材料に収益を上げただけで、構造的な説明も反論も提示しなかった。傍観者だった。

OSI（Open Source Initiative）の財政構造を見るとさらに明確になる。⁶ OSIのPlatinumスポンサーにはGoogle、Microsoftが含まれている。SSPLを「オープンソースではない」と拒否した機関の運営資金を、SSPLで制限を受ける企業たちが出しているのだ。

Note

OSI認定は法的強制力を持たない。誰でもどんなライセンスでも作れる。OSIが「これはオープンソースではない」と宣言しても、そのライセンスの使用を止めることはできない。しかしOSI認定は事実上の業界標準マークとして機能する。企業の調達ポリシー、公開ソフトウェアリスト、開発者コミュニティの判断基準がOSI認定の有無を基準にするからだ。OSIが「ではない」と宣言した瞬間、コミュニティ全体がそのライセンスを排斥する構造が作られる。

メカニズムはこうだ：

大企業が直接「SSPL反対」と叫べば → 叩かれる
           ↓
OSIを通じて「オープンソース定義に違反」と宣言
           ↓
コミュニティ開発者たちが信念のように従う
           ↓
大企業は裏で既存の構造を維持する

「オープンソース哲学の守護」という名目で、実質的に大企業のただ乗り券を守っているのだ。「オープンソースの裏切り」「コミュニティの分裂」「ライセンス戦争」——そんな見出しはビューを稼ぐ。RedisやHashiCorpの騒動のたびに、メディアはこのゴシップを忠実に消費した。怒りがどこへ向かうべきかを説明しなくてもよかった。コミュニティの怒りは実際の権力構造を変えられず、コンテンツ消費として使い果たされた。

真の被害者が搾取構造を守るという逆説

最も苦い地点がここだ。SSPLに憤る人々の多くは、小規模会社の開発者や個人開発者だ。

実際にSSPLが彼らに与える影響を考えてみると：

セルフホスティングユーザー → 内部で動かすならSSPLでも何の制限もない
小規模サービス開発者 → 「クラウドサービスとして提供」しなければ同様に無関係
大企業の社内開発者 → 社内法務チームが「SSPLはNG」と判定 → 指針に従って反対

最後のケースが核心だ。個人の信念ではなく、会社の指針に従って反対意見をコミュニティに広める構造だ。そしてその会社がまさにSSPLで制限を受けるAWS、Google、Microsoftだ。

それでもOSIが「これはオープンソースではない」と宣言すれば、個人開発者たちもその判断を宗教のように従う。Hacker NewsでSSPLを批判するコメントの多くは、なぜ反対なのかを論理的に説明できない。「OSI認定じゃないじゃないですか」がすべてだ。

本当の被害者であるオープンソースメンテナーたちが、自分たちの搾取構造を守るという逆説だ。

繰り返されるパターン

HashiCorp（Terraform → BSL）、Redis（→ RSALv2 + SSPLv1）、MongoDB（→ SSPL）、Elastic（→ SSPL + Elastic License v2、後にAGPLv3追加）。ライセンス選択の方向は異なっていた——BSLは「競合サービスは使うな」であり、SSPLは「使うならスタック全体を公開せよ」だ。しかしビジネスのパターンは同じだ：

MIT/BSDでコミュニティ形成
       ↓
VC投資誘致
       ↓
収益化圧力
       ↓
ライセンス変更
       ↓
コミュニティの怒り → 「裏切り者」
       ↓
大企業はフォークまたは別のプロジェクトへ移動

これは裏切りではない。MIT/BSDがクラウド時代に持続可能なビジネスモデルになり得ないという繰り返された証拠だ。毎回同じ結末が出るのに「今回は違うはずだ」と信じる方がむしろ非論理的だ。

好循環が搾取構造へと変わった世界

オープンソースが最初に作られた時には好循環があった。開発者がコードを公開すると他の開発者が使って楽になり、その成果がまたコミュニティへ戻ってくる構造。その構造のおかげで無数のライブラリを無料で使いながら開発できた。明確な借りだ。

しかし今は違う。その好循環の受益者が開発者コミュニティではなく、クラウドプラットフォームになった。AWS、Google Cloud、Azureがオープンソースエコシステム全体を吸収し、利益はプラットフォームが独占する。開発者は依然として無償で貢献し、プラットフォームはそれで数兆円を稼ぐ。

オープンソースの哲学が間違っているのではない。その哲学が想定していた世界がもはや存在しないのだ。クラウドがなかった時代に作られた概念を、クラウドがすべてを吸い込む時代にそのまま適用すれば、搾取が合法化される。そしてその合法性を「オープンソースの精神」という名前で守っているのがOSIであり、コミュニティであり、今日もアップされるゴシップコンテンツだ。

SSPLは完璧な答えではないかもしれない。しかしこの構造的問題に実質的に対応する試みだ。これを「哲学違反」と烙印を押して拒否することは、意図的であれなかれ、搾取を守る側に立つことだ。この進化を「裏切り」と呼ぶ人たちが誰の利益を代弁しているのか、一度は正直に問い直してみるべきことだ。

MongoDB、SSPL v1全文（2018年）。OSI公開審査スレッド：License-reviewメーリングリスト ↩
OSI、SSPL審査結果 — 「オープンソース定義に適合しない」と結論 ↩
Redis創設者Salvatore Sanfilippo（antirez）は2019年のブログで、クラウドプロバイダーが貢献よりはるかに多くの収益を持っていくという不満を表明した。SSPL転換前の基準で外部の非従業員コントリビューターがコミットの54%を担当していたというデータは、CHAOSSのデータサイエンスディレクターDawn FosterがMonki Grasで発表した内容だ（コード追加の12%、削除の15%に相当）。AWSにメンテナーがいたにもかかわらず、収益還元の構造がまったくなかったことが核心だ。出典：devclass.com — ライセンス変更1年後の分析、AWS Open Source Blog ↩
Redis Ltd.、Redisライセンス変更発表（2024年3月）。変更されたライセンスはRSALv2（Redis Source Available License v2）とSSPLv1のデュアルライセンスだ。SSPL単独ではないことに注意。 ↩
Linux Foundation、Valkeyプロジェクト公式設立（2024年3月28日）— 設立当初はAWS、Google Cloud、Oracle、Ericsson、Snap の5社が参加。その後Alibaba Cloud、Huawei、Canonicalなどに拡大。 ↩
OSIのスポンサー状況はOSIスポンサーページで確認可能。2024〜2026年基準のPlatinumスポンサーはGoogle、Microsoft。理事会は主にオープンソース財団出身者で構成され、ビッグテックはスポンサー関係で財政支援をしている。 ↩