■ 1. 問題の背景
- OSSが成功すると、巨大クラウド事業者がマネージドサービスとして提供し、大きな売上を得る
- 開発元企業には売上が直接還元されない
- Apache-2.0やBSDなど寛容なライセンスでは、商用利用・再販売はライセンス上認められた自由であり、原則として違反ではない
- 「ルール上は正しいが、開発を続けられない」と感じたOSS企業が、ライセンス変更や防衛戦略をとるケースが相次いだ
■ 2. Elastic と AWS の衝突
- ElasticsearchとKibanaはApache License 2.0で公開され、AWSは2015年にAmazon Elasticsearch Serviceを開始
- 2021年、Elastic創業者Shay Banon氏が「Amazon: NOT OK」と題したブログを公開し、AWSによる商業的利用を問題視
- Elasticは Elasticsearch 7.11以降、Apache-2.0からSSPLとElastic Licenseのデュアルライセンスへ移行
- SSPLを選択すると、サービス提供者は管理・運用レイヤーを含むソースコードの公開が必要
- AWSはApache-2.0版のElasticsearch 7.10.2をフォークし、OpenSearchを立ち上げた
- 両者の主張:
- Elastic側: 開発投資を負担してきた企業がクラウド事業者に価値を吸収されると開発継続が困難
- AWS側: Apache-2.0が許した利用を後から制限すれば、利用者の自由とライセンスへの信頼を損なう
- 2024年、ElasticはSSPL・Elastic Licenseに加えてAGPLv3を選択肢として追加
■ 3. MongoDB と SSPL
- MongoDBはもともとAGPLでCommunity Serverを提供していたが、2018年にSSPLを新たに作成
- SSPLの特徴: MongoDB本体への変更だけでなく、サービス提供に使う管理ソフトウェア、UI、API、自動化、監視、バックアップ、ストレージなど「Service Source Code」全体の公開を要求
- SSPLはOSI承認のオープンソースライセンスではなく、ソースコードを閲覧可能だが制限が強い
- SSPL導入約3か月後の2019年1月、AWSはAmazon DocumentDB（with MongoDB compatibility）を公開
- MongoDBのコードをホストするのではなく、MongoDB 3.6のAPIをAWS独自のストレージエンジン上で再実装した別製品
- 強いライセンスへ変更しても、資本と技術力を持つ競合が互換製品をゼロから作る可能性は排除できない
■ 4. Redis のライセンス変更とフォーク
- Redisは長年BSD-3-Clauseで公開されていたが、2024年にRedis 7.4以降をRSALv2またはSSPLv1へ変更
- ライセンス変更を受け、コミュニティとクラウド事業者が最後のBSD版Redis 7.2.4をフォークし、Linux Foundation傘下のValkeyを設立
- AWS、Google Cloud、Oracle、Ericssonなどが参加し、BSDライセンスで開発継続
- その後の方針変更:
- 2024年11月、Redisの生みの親Salvatore Sanfilippo氏（antirez）がプロジェクトへ復帰
- Redis CEOが公式発表で、SSPLへの変更はフォーク設立という目的をクラウド事業者が達成した一方、コミュニティとの関係を傷つけたと認めた
- Redis 8でRSALv2、SSPLv1に加えOSI承認のAGPLv3を追加
- 教訓: ライセンスは後から変更できるが、一度失ったコミュニティの予測可能性はライセンスを戻すだけでは回復しない
■ 5. HashiCorp と OpenTofu
- TerraformはInfrastructure as Codeの事実上の標準として普及し、OSI承認のMPL 2.0で公開されていた
- 2023年、HashiCorpは将来のリリースをBusiness Source License（BSL）1.1へ変更
- 競合する商用サービスによる利用を制限する目的
- これに対し、企業と開発者のグループが最後のMPL版をフォークし、OpenTofuを設立
- OpenTofuはLinux Foundationによる中立的な管理を選択し、単一企業による再ライセンス変更を防止する設計
- フォーク後も緊張は続いた:
- 2024年4月、HashiCorpがOpenTofuに対しBSLコードの不正取り込みを主張し停止要求書を送付
- OpenTofu側は疑惑を否定し、問題とされた実装は過去のMPL-2.0版コードから派生したものだと詳細なコード来歴を公開
- フォーク側は旧ライセンスで合法的に利用できるコードと変更後のライセンスのコードを厳密に隔離し、実装の出所を説明できる必要がある
■ 6. Confluent の戦略
- Apache KafkaはApache Software Foundationのプロジェクトであり、Confluent単独ではApache-2.0からの変更は不可能
- 2018年、ConfluentはKafka本体はApache-2.0のまま維持し、自社が開発する周辺コンポーネント（Schema Registry、REST Proxy、ksqlDB、一部のConnector等）をConfluent Community Licenseへ変更
- Confluentの戦略構造:
- 中立的な財団にあるKafka本体は誰でもサービス化可能
- ConfluentはKafkaへ継続的に貢献
- 自社のみが権利を持つ周辺機能で競合サービスを制限
- 企業顧客には周辺機能と運用を統合した商用価値を販売
- コードのライセンスだけでなく、どのコードを財団へ置きどのコードを企業が保有するかが、ビジネスモデルを決定する
■ 7. CockroachDB と Sentry: 時限式ライセンスの試み
- CockroachDBの取り組み:
- 2019年、Apache-2.0からBusiness Source License（BSL）へ移行
- BSLでは新バージョンの競合サービス提供を制限しつつ、一定期間後に指定OSSライセンスへ自動移行
- 2024年、さらにCockroachDB Software Licenseへ移行し、現在は年間売上1,000万ドル未満の企業などに無償枠を設けたプロプライエタリ製品となっている
- Sentryの取り組み:
- 時限式モデルを定型化したFunctional Source License（FSL）を作成
- 公開から2年間は競合製品・サービスへの利用を制限し、その後Apache-2.0またはMITへ自動移行
- FSL・BSLは制限期間中はsource-availableでありOSI定義のOSSではないが、開発費回収後に全員へ自由を渡すという設計
■ 8. Grafana: AGPLと商用契約によるパートナーシップ
- 2021年、Grafana LabsはGrafana、Loki、TempoのライセンスをApache-2.0からAGPLv3へ変更
- SSPLも検討したが、コミュニティとの関係を重視してOSI承認ライセンスにとどまる判断をした
- AWSはAmazon Managed Service for Grafanaを持ちながらも、OpenSearchのようなフォークには至らなかった
- AWSとは商用契約を含む戦略的パートナー関係があり、AWSのサービスはライセンス変更の影響を受けなかった
- Grafanaの構造:
- コミュニティにはOSI承認のAGPLでコードを公開
- 改変を非公開でサービス提供したい事業者には商用ライセンスを用意
- 大手クラウドとは敵対ではなく、契約によって価値を分配
- AGPLはクラウド事業者に「改変を公開する」か「商用契約を結ぶ」かという交渉の入口を作り、パートナーシップへ進める可能性がある
■ 9. クラウド事業者と OSS の関係性の本質
- Apache-2.0、MIT、BSDを選んだプロジェクトでは、商用利用・再配布・サービス化はライセンスが明示的に認めた自由であり、コントリビューションの強制条項はない
- 問題の本質は「クラウド事業者がルールを破ったか」だけではなく、プロジェクトが期待した互恵関係と実際に選んだライセンスの間のずれという設計上の問題
- コード利用以外の問題も存在する:
- 商標による利用者の混同
- 互換性の表示
- コミュニティへの説明
- upstreamとの協力姿勢
- Elastic vs AWSの対立でも「Elasticsearch」という名称の商標問題が大きな争点となった
- OSS企業は善意のコントリビューションだけを収益モデルにすべきではなく、クラウド事業者もライセンス上可能であることと、コミュニティにとって持続可能であることを同一視すべきではない
■ 10. Papillon での AGPL 選択理由
- Convergence Lab.が開発するBIツールPapillonでは、OSSコアをAGPL-3.0、Enterpriseコンポーネントを商用ライセンスとする構成を採用
- AGPLを最初から選んだ理由:
- 最初にApache-2.0を選び後でライセンス変更すれば、Elastic・Redis・HashiCorpと同様に利用者との約束を途中で変えることになる
- 最初から条件を明確にすることで、後からルールを変えず、コミュニティ版と商用版の関係を説明できる
- Papillonでの条件設計:
- 個人や開発者は実用的なコア機能をOSSとして利用・改変できる
- 改変版を配布・ネットワーク提供する場合はAGPLの条件に従いソースを提供
- ソースを非公開にしたい組織には商用ライセンスという選択肢を用意
- SSO、監査ログ、ガバナンスなどの組織運用機能はEnterprise領域で開発
- AGPLの代償も認識している:
- 法務ポリシー上AGPLを採用できない企業が少なくない
- MITやApache-2.0のプロジェクトより利用者・コントリビューターが増えにくい可能性がある
- ライセンスを強くしても自動的に事業が成功するわけではない
■ 11. OSSビジネスで設計すべき4要素
- ライセンス:
- どの利用を自由にし、どの場面でソース公開または商用契約を求めるかを決定
- 普及最優先ならMITやApache-2.0、ネットワークサービスからの還元も重視するならAGPLが候補
- ガバナンス:
- ライセンスを誰が変更できるか、ロードマップを誰が決めるかを設計
- 企業主体と財団主体にはそれぞれ速度と予測可能性のトレードオフがある
- 商標:
- コードを自由に使えても、公式製品と誤認させる名称利用まで自由とは限らない
- プロジェクト名とロゴの扱いを明確にしなければ、利用者の混同が対立へ発展する
- お金を払う理由:
- 「OSSを使わせない」ことを商用版の価値にしてはいけない
- SSO、監査、サポート、SLA、導入支援、運用代行など、組織が対価を払う積極的な理由が必要