クラウドにOSSを「持っていかれる」問題：Elastic、Redis、HashiCorpから考えるAGPL

「ソースコードを公開すれば、利用者が増え、改善が返ってきて、みんなが得をする」

OSSにはそんな理想があります。しかし、実際にプロジェクトが成功すると、別の光景が現れることがあります。巨大クラウド事業者がOSSをマネージドサービスとして提供し、運用の手軽さと販売網を武器に大きな売上を得る。一方、最初にソフトウェアを作った企業には、その売上が直接還元されるとは限りません。

しかも、Apache License 2.0やBSDのような寛容なライセンスを選んだ以上、これは原則としてライセンス違反ではありません。OSSは商用利用も再販売も認めるからです。

では、「ルール上は正しいが、このままでは開発を続けられない」と感じたOSS企業はどう動いたのでしょうか。本記事では、ElasticとAWS、MongoDBとAmazon DocumentDB、RedisとValkey、HashiCorpとOpenTofu、Confluent、CockroachDB、Sentry、そしてGrafanaの事例をたどりながら、現在開発中のBIツール「Papillon」でAGPLを選んだ理由を考えます。

なお、本記事は2026年7月23日時点の公開情報をもとに、各社の主張を区別して整理したものです。特定企業の行為を違法・不当と断定するものではなく、法的助言でもありません。

Elastic対AWS：「Amazon: NOT OK」までの衝突

この問題を象徴するのが、Elasticsearchを開発するElasticとAWSの対立です。

ElasticsearchとKibanaはApache License 2.0で公開され、検索・ログ分析基盤として急速に普及しました。AWSは2015年に「Amazon Elasticsearch Service」を開始し、ElasticsearchをAWS上で運用できるマネージドサービスとして提供しました。

利用者にとっては便利です。クラスター構築、障害対応、スケーリングをAWSに任せられるからです。一方、Elasticから見れば、自社が中心となって開発した製品の名称と機能を、巨大な販売網を持つAWSがサービス化している構図でした。

2021年、Elastic創業者のShay Banon氏は、公式ブログにそのまま「Amazon: NOT OK」と題した記事を公開しました。Elastic側は、AWSが2015年以降行ってきたことを問題視し、ライセンス変更は「ElasticsearchとKibanaを、協業せずにそのままサービスとして提供する企業」を止めるためだと説明しています。

ElasticはElasticsearch 7.11以降、Apache-2.0での提供をやめ、SSPLとElastic Licenseのデュアルライセンスへ移行しました。SSPLを選ぶと、サービスとして提供する事業者は、管理・運用レイヤーを含むサービスのソースコードを公開する必要があります。

しかし、AWS側の説明は正反対です。AWSは公式ブログで、Elasticの新しいライセンスはオープンソースではないと批判しました。また、AWSはElasticsearchや基盤となるApache Luceneへ貢献してきたと主張しています。

そしてAWSは、最後のApache-2.0版であるElasticsearch 7.10.2とKibana 7.10.2をフォークし、OpenSearchを立ち上げました。Amazon Elasticsearch Serviceも、後にAmazon OpenSearch Serviceへ改称されます。

ここで重要なのは、どちらか一方だけが単純な悪役ではないことです。

Elastic側：開発投資を負担してきた企業が、クラウド事業者に価値を吸収されると開発を継続できない
AWS側：Apache-2.0が許した利用を後から制限すれば、利用者の自由とライセンスへの信頼を損なう

どちらの主張にも論理があります。寛容なOSSライセンスが生んだ成功が、開発企業とクラウド事業者の利害を衝突させ、最終的にプロジェクトを二つへ分岐させました。

さらに興味深いことに、Elasticは2024年、SSPLとElastic Licenseに加えて、OSI承認のAGPLv3を選択肢として追加しました。対立の末に完全なプロプライエタリ化へ進んだのではなく、ネットワーク利用にもコピーレフトが及ぶOSSライセンスへ戻る道を選んだのです。

MongoDB：「クラウドの厨房も公開せよ」というSSPL

Elasticが採用したSSPLは、もともとMongoDBが2018年に作ったライセンスです。

MongoDBは、それ以前はAGPLでCommunity Serverを提供していました。しかし同社は、クラウド事業者がAGPLの境界を試し、人気OSSの価値を取り込みながらコミュニティへ何も返さない状況が起きていると主張しました。

MongoDBのSSPL FAQは、その問題意識をかなり率直に記しています。

SSPLの特徴は、MongoDB本体への変更だけでなく、MongoDBをサービスとして提供するために使う管理ソフトウェア、ユーザーインターフェース、API、自動化、監視、バックアップ、ストレージなどを含む「Service Source Code」の公開を求めることです。

料理にたとえるなら、「レシピを改変したら公開してください」だけでなく、その料理をクラウド店舗で売るなら、厨房設備と店舗運営の仕組みも公開してくださいという条件です。

これはクラウド事業者には非常に重い条件です。サービス運営基盤そのものが競争力だからです。そのためSSPLはソースコードを読めるライセンスではありますが、OSI承認のオープンソースライセンスではありません。

そして、このライセンス変更には意外な続きがあります。MongoDBがSSPLを導入した約3か月後の2019年1月、AWSはAmazon DocumentDB（with MongoDB compatibility）を公開しました。

AWSの発表によると、DocumentDBはMongoDBそのものをホストしたサービスではありません。MongoDB 3.6のAPIを、AWSが独自のストレージエンジン上で再実装し、MongoDBクライアントが期待する応答をエミュレートする別製品です。

つまり、MongoDBが「私たちのコードをクラウドサービスにするなら、運用基盤も公開してください」とライセンスで防御したところ、AWSはコードを使わず、互換APIを実装する方向へ進みました。

ライセンスは著作権で保護されるコードの利用を制御できますが、一般にアイデアやAPI互換性のすべてを独占できるわけではありません。強いライセンスへ変更しても、資本と技術力を持つ競合が互換製品をゼロから作る可能性までは消せないのです。

MongoDBの事例は、「AGPLだけではクラウド事業者への防御として足りない」と考える企業が、OSSの定義から外れるほど強い条件を選ぶ場合があることを示しました。

Redis：ライセンスを変えたら、コミュニティがフォークした

Redisの事例は、ライセンス変更が一度起こす分岐を、後から元に戻すことの難しさを示しています。

Redisは長年、非常に寛容なBSD-3-Clauseで公開されていました。AWS、Google Cloud、Microsoft Azureを含む多くの事業者が、Redis互換のマネージドサービスを提供してきました。

2024年、Redis Ltd.はRedis 7.4以降のライセンスを、RSALv2またはSSPLv1へ変更しました。どちらもOSI承認のOSSライセンスではなく、競合するクラウドサービスの提供を制限する意図がありました。

すると、コミュニティとクラウド事業者は、最後のBSD版であるRedis 7.2.4をフォークしました。それがLinux Foundation傘下のValkeyです。AWS、Google Cloud、Oracle、Ericssonなどが参加し、BSDライセンスのまま開発を継続しました。

その後、Redisは方針を再び変えます。2024年11月、Redisの生みの親であるSalvatore Sanfilippo氏（antirez）がプロジェクトへ復帰しました。同氏は後に、社内で続いていたAGPL採用の議論を後押ししたと自身のブログで振り返っています。

Redis CEOも公式発表で、SSPLへの変更はAWSとGoogleが独自フォークを維持するという目的を達成した一方、Redisコミュニティとの関係を傷つけたと率直に認めています。企業の公式発表としては、かなり踏み込んだ総括です。

Redis 8ではRSALv2、SSPLv1に加え、OSI承認のAGPLv3を選べるようになりました。さらに、それまでRedis Stack側にあったJSON、時系列、確率的データ構造、検索エンジンなどもコアへ統合されました。現在のRedis公式ライセンスページでは、7.2以前はBSD、7.4はRSALv2/SSPLv1、8以降はAGPLv3を含む三つの選択肢という履歴を確認できます。

しかし、AGPLを追加してもValkeyが消えるわけではありません。フォークには既に独自のガバナンス、参加企業、ロードマップ、利用者が生まれているからです。

この事例から得られる教訓は明確です。ライセンスは後から変更できますが、一度失ったコミュニティの予測可能性は、ライセンスを戻すだけでは回復しないということです。

Terraform：HashiCorpの防衛がOpenTofuを生んだ

HashiCorpのTerraformにも似た展開が起きました。

TerraformはInfrastructure as Codeの事実上の標準として普及し、多数のクラウド事業者、SaaS企業、コンサルティング企業が周辺エコシステムを作りました。もともとはOSI承認のMPL 2.0で公開されていました。

2023年、HashiCorpは将来のリリースをBusiness Source License（BSL）1.1へ変更しました。HashiCorpの発表では、競合する商用サービスによる利用を制限し、コミュニティと製品への投資を継続するための変更だと説明されています。

これに対して、企業と開発者のグループが最後のMPL版をフォークし、OpenTofuを設立しました。OpenTofuのManifestoは、単一企業の判断で再びライセンスが変更されないよう、Linux Foundationによる中立的な管理を選んだと説明しています。

ここでは、ソースコードの公開範囲だけでなく、誰がプロジェクトの未来を決められるのかが争点になりました。

企業主体のOSSでは、著作権を集約することで迅速なライセンス変更やデュアルライセンスが可能になります。一方、利用者から見れば、昨日までOSSだった基盤が明日も同じ条件とは限りません。中立的な財団のガバナンスには、将来の一方的な変更を防ぐ保険としての価値があります。

しかも、フォーク後の緊張はライセンス変更だけでは終わりませんでした。2024年4月、HashiCorpはOpenTofuに対し、BSLで提供したTerraformのコードを不正に取り込んだとして停止要求書を送りました。

OpenTofu側は公式回答で疑惑を全面的に否定し、問題とされた実装は過去のMPL-2.0版コードから派生したもので、BSL版をコピーしたものではないという詳細なコード来歴を公開しました。

この一件は、フォークを作れば自由になれるわけではないことを示しています。フォーク側は、旧ライセンスで合法的に利用できるコードと、変更後のライセンスで公開されたコードを厳密に隔離し、すべての実装について出所を説明できなければなりません。ライセンス変更は、二つの開発チームの間に長期的な「見えない壁」を作ります。

Confluent：Kafka本体は変更できない。だから周辺を守った

すべての企業が、中心となるOSSのライセンスを自由に変更できるわけではありません。Apache Kafkaを中心に事業を展開するConfluentがその例です。

KafkaはConfluent単独の所有物ではなく、Apache Software Foundationのプロジェクトです。Confluentの創業者たちがKafkaの開発者であっても、同社の判断だけでApache-2.0から別のライセンスへ変更することはできません。

そこでConfluentは2018年、Kafka本体はApache-2.0のまま維持し、自社が開発するSchema Registry、REST Proxy、ksqlDB、一部のConnectorなどをConfluent Community Licenseへ変更しました。

Confluentの説明は、クラウド事業者を一方的に非難せず、「各社はライセンスの範囲内で商業的利益に従っている」と認めたうえで、周辺コンポーネントを競合SaaSとして提供することだけを禁止しています。

これはオープンコアの境界設計として興味深い事例です。

中立的な財団にあるKafka本体は、誰でもサービス化できる
ConfluentはKafkaへの貢献を続ける
自社だけが権利を持つ周辺機能で、競合サービスを制限する
企業顧客には、周辺機能と運用を統合した商用価値を販売する

AWSはAmazon MSKとしてマネージドKafkaを提供できます。しかし、Confluent固有の周辺製品までそのままサービス化できるわけではありません。コードのライセンスだけでなく、どのコードを財団へ置き、どのコードを企業が保有するかが、その後のビジネスモデルを決めています。

CockroachDBとSentry：「いずれOSSになる」という第三の道

クラウドへの防御方法は、AGPLと商用ライセンスの二択ではありません。一定期間だけ競合利用を制限し、その後OSSライセンスへ自動的に移行する方法もあります。

分散SQLデータベースのCockroachDBは2019年、Apache-2.0からBusiness Source License（BSL）へ移行しました。BSLでは新しいバージョンを競合サービスとして提供することを制限する一方、一定期間が過ぎると指定したOSSライセンスへ切り替わります。

これは、最新バージョンの商業的優位を開発企業が一定期間確保しながら、古いバージョンは最終的にOSSへ戻す設計です。ただしCockroach Labsは2024年、さらにCockroachDB Software Licenseへ移行し、現在は年間売上1,000万ドル未満の企業などに無償枠を設けたプロプライエタリ製品となっています。ライセンスは一度決めて終わりではなく、事業状況によって段階的に閉じていく場合もあります。

エラー監視サービスのSentryは、この時限式モデルをさらに定型化したFunctional Source License（FSL）を作りました。Sentryの説明では、公開から2年間は競合製品・サービスへの利用を制限し、その後はApache-2.0またはMITへ自動的に移行します。

FSLもBSLも、制限期間中はOSIの定義するOSSではなく、source-availableです。しかし「永遠に閉じる」のではなく、開発費を回収する時間だけを確保し、後から全員へ自由を渡すという発想は、AGPLとは異なる持続可能性の実験です。

Grafana：AWSを敵ではなく商用パートナーにした例

対立やフォークだけが結末ではありません。

Grafana Labsは2021年、Grafana、Loki、TempoのライセンスをApache-2.0からAGPLv3へ変更しました。SSPLも検討したものの、コミュニティとの関係を重視してOSI承認ライセンスに残る判断をしたとCEOのQ&Aで説明しています。

同じ時期、AWSにはAmazon Managed Service for Grafanaがありました。それでもOpenSearchのようなフォークには至りませんでした。Grafana Labsによれば、AWSとは商用契約を含む戦略的パートナー関係があり、AWSのサービスはライセンス変更の影響を受けませんでした。

これは興味深い落としどころです。

コミュニティにはOSI承認のAGPLでコードを公開する
改変を非公開でサービス提供したい事業者には商用ライセンスを用意する
大手クラウドとは敵対ではなく、契約によって価値を分配する

AGPLはクラウド利用を禁止するライセンスではありません。クラウド事業者に「改変を公開する」か「商用契約を結ぶ」かという交渉の入口を作ります。Grafanaの事例は、その入口からパートナーシップへ進める可能性を示しています。

結局、「コントリビューションしないクラウド」が悪いのか

感情的には、長年かけて作ったOSSを巨大企業がサービス化し、開発元より大きな売上を得れば、「ただ乗り」に見えます。

しかし、Apache-2.0、MIT、BSDを選んだプロジェクトでは、商用利用、再配布、サービス化はライセンスが明示的に認めた自由です。コードを利用した企業に、売上の分配やupstreamへの貢献を強制する条項はありません。

したがって、問題は「クラウド事業者がルールを破ったか」だけではありません。より本質的には、プロジェクトが期待した互恵関係と、実際に選んだライセンスの間にずれがなかったかという設計の問題です。

もちろん、コード以外の問題は別です。商標による利用者の混同、互換性の表示、コミュニティへの説明、upstreamとの協力姿勢は、ライセンスに違反しなくても信頼を左右します。ElasticとAWSの対立でも、コード利用だけでなく「Elasticsearch」という名称をめぐる商標問題が大きな争点になりました。

OSS企業は、善意のコントリビューションだけを収益モデルにしてはいけません。一方、クラウド事業者も、ライセンス上可能であることと、コミュニティにとって持続可能であることを同一視すべきではないでしょう。

Papillonで最初からAGPLを選んだ理由

Convergence Lab.が開発しているBIツールPapillonでは、OSSコアをAGPL-3.0、Enterpriseコンポーネントを商用ライセンスとする構成を採用しています。

PapillonはデスクトップBIですが、将来的には共有やサーバー実行へ広がる可能性があります。もし最初にApache-2.0を選び、利用が広がった後でクラウド事業者との競合を理由にライセンスを変更すれば、Elastic、Redis、HashiCorpと同じように、利用者との約束を途中で変えることになります。

そこで、最初から次の条件を明確にすることにしました。

個人や開発者は、実用的なコア機能をOSSとして利用・改変できる
改変版を配布・ネットワーク提供する場合は、AGPLの条件に従ってソースを提供する
ソースを非公開にしたい組織には、商用ライセンスという選択肢を用意する
SSO、監査ログ、ガバナンスなどの組織運用機能はEnterprise領域で開発する

これは「クラウド事業者を締め出す」ためだけの選択ではありません。後からルールを変えず、コミュニティ版と商用版の関係を最初から説明するための選択です。

もちろん、AGPLにも代償があります。法務ポリシー上AGPLを採用できない企業は少なくありません。利用者やコントリビューターが、MITやApache-2.0のプロジェクトより増えにくい可能性もあります。ライセンスを強くすれば、自動的に事業が成功するわけでもありません。

PapillonにとってAGPLが最適解かどうかは、まだ検証の途中です。ただ、過去のOSS企業が経験した衝突を見れば、成功してからライセンスを考えるのでは遅いことだけは明らかです。

OSSビジネスで本当に設計すべきもの

これらの事例から、ライセンスだけでなく四つの要素を同時に設計する必要があると考えています。

1. ライセンス

どの利用を自由にし、どの場面でソース公開または商用契約を求めるのか。普及を最優先するならMITやApache-2.0、ネットワークサービスからの還元も重視するならAGPLが候補になります。

2. ガバナンス

ライセンスを誰が変更できるのか、ロードマップを誰が決めるのか。企業主体と財団主体には、それぞれ速度と予測可能性のトレードオフがあります。

3. 商標

コードを自由に使えても、公式製品と誤認させる名称利用まで自由とは限りません。プロジェクト名とロゴの扱いを明確にしなければ、利用者の混同が対立へ発展します。

4. お金を払う理由

「OSSを使わせない」ことを商用版の価値にしてはいけません。SSO、監査、サポート、SLA、導入支援、運用代行など、組織が対価を払う積極的な理由が必要です。

まとめ

Elastic、MongoDB、Redis、HashiCorp、Confluent、CockroachDB、Sentryのライセンス変更は、単なる法務上の判断ではありませんでした。OSSで広く普及させたいという理想と、その開発費を回収したいという現実が、クラウド時代に正面衝突した結果です。

寛容なライセンスを選べば、クラウド事業者による商用サービス化も自由の一部です。後から制限を加えれば、フォークが生まれ、コミュニティが分裂する可能性があります。コードを強く保護すればAmazon DocumentDBのような互換実装が生まれることもあります。一方で、GrafanaのようにAGPLと商用契約を組み合わせ、クラウド事業者をパートナーにする道もあります。

OSSを公開する時点では、まだ誰にも使われていないため、将来の「成功しすぎた問題」は現実味がありません。しかし、ライセンスはまさに、その成功した未来に誰が何をできるかを決めるものです。

Papillonでも、コードを公開すること自体を目的にせず、利用者、コントリビューター、開発を続ける企業、そして将来のクラウドパートナーが持続できる形を探していきます。