オープンソースライセンス 2026 — BSL・SSPL・FSL、クラウドへの 8 年間の反乱を読み解く徹底解説 (2026)

プロローグ — 「AWS が私のデータベースをホスティングしている」
1. パーミッシブの土台 — OSS の 9 割は今でも MIT と Apache 2.0
2. AWS の strip-mining 問題 — 2010 年代後半の発見
3. MongoDB と SSPL の誕生(2018)
- 3.1 OSI の反応 — 「これはオープンソースではない」
- 3.2 MongoDB の結末 — 市場では生き残った
4. 反乱のタイムライン — 8 年を一目で
5. Elastic のアーク — Apache 2.0 → SSPL → AGPL の 4 年
6. Redis のアーク — 2024 年のデジャブ
7. HashiCorp と OpenTofu — IaC 陣営の分裂
8. Sentry と FSL — 「2 年後に Apache 2.0」
9. その他のライセンス — CockroachDB、Confluent、FUTO
10. OSI 定義をめぐる戦い — 「オープンソース」は誰の言葉か
11. ライセンス対権利マトリクス(2026)
12. 意味 — 誰にどう影響するか
13. ライセンス決定木(スタートアップ/メンテナ用)
14. アンチパターン — こうしてはいけない
エピローグ — 8 年後、私たちは何を学んだか
- 意思決定チェックリスト — OSS 導入時
- 次回予告
参考 / References

プロローグ — 「AWS が私のデータベースをホスティングしている」

2018 年秋、MongoDB の CTO だった Eliot Horowitz がブログに一文を投稿した。

"We have made the difficult decision to relicense MongoDB Server."

表面上の理由は短かったが、その下には 8 年に渡る紛争の種があった。クラウド事業者が OSS をそのままホスティングサービスとして売り、そのソフトウェアを作った会社にはほぼ何も還元しない構造。 MongoDB はこれを "strip-mining" と呼んだ。鉱山をまるごと掘り出すように、AWS が OSS の価値をごっそり持っていく、という比喩だ。

この診断が正しかったかどうかは別として、MongoDB の決定は導火線になった。SSPL — Server Side Public License。 名称こそ "Public License" だったが、OSI はこれをオープンソースとは認めなかった。その後、Elastic、Redis、Confluent、CockroachDB、MariaDB、HashiCorp、Sentry が、それぞれ同種の決定をくだしていく。皆「AWS への自衛」を旗印に掲げた。

2026 年現在、私たちはこの反乱の終わり近くにいる。Elastic は 2024 年 8 月に AGPLv3 をオプションに加えて OSI 認定 OSS に戻った。Redis は 2025 年 5 月にそれに続いた。 HashiCorp は IBM に買収され、その間に OpenTofu が CNCF プロジェクトとして地位を固めた。Sentry は FSL(Functional Source License)を発明し、「2 年後に Apache 2.0 へ自動転換」という折衷案を出した。FUTO は「Source First」という新名称を作った。

本記事はこの 8 年のライセンス戦争を — 何が起き、なぜ起き、そして 2026 年にあなたがデータベースを 1 つ選ぶときにそのライセンスの一行がなぜ重要なのか — 一気に整理する。擁護でも非難でもなく、判断のための道具を渡すことが目的だ。

1. パーミッシブの土台 — OSS の 9 割は今でも MIT と Apache 2.0

ライセンス戦争を語る前に風景を整理しよう。2026 年時点で GitHub の公開リポジトリのライセンス分布はおおむね次の通り(Synopsys Black Duck OSS Audit 2026 基準)。

MIT — 約 45 ~ 50%
Apache 2.0 — 約 20 ~ 25%
BSD-3-Clause / BSD-2-Clause — 約 5%
GPL ファミリ(GPL/LGPL/AGPL) — 約 15%
MPL 2.0、EPL、ISC、その他 OSI 認定 — 約 5%
Source-available(BSL、SSPL、FSL、ELv2、RSAL、Confluent CL、FUTO 等) — 合計 1% 未満

つまり、本記事で扱うライセンス反乱のドラマはすべて市場の 1% の内側で起きている。 残りの 99% は今でも平穏に MIT か Apache 2.0 だ。この事実を覚えておきたい。BSL・SSPL・FSL は市場全体を揺るがしているのではなく、単一ベンダーが作る基盤的なコンポーネント(データベース、検索エンジン、IaC ツール、モニタリング SaaS の OSS 部分)に集中している。

1.1 MIT — 自由の 21 行

MIT ライセンスの本文は英語で約 170 語。一行にまとめれば 「無料で持っていって何でもしてよい。ただし著作権表示は残し、責任は問わないこと」。

商用利用 OK
改変 OK
再配布 OK
プロプライエタリ・ライセンスで再パッケージ OK
コピーレフト義務なし

React、Rails、Express、Vue、Node.js のコア、Prettier、Bun — 私たちが毎日使うツールの大半が MIT だ。MIT の長所はシンプルさで、短所も同じシンプルさだ。 AWS が React をブランドだけ替えて売っても止める手段は法的に無い。幸い(?)React はそういうビジネスにはならない。

1.2 Apache 2.0 — MIT + 特許保護

Apache 2.0 は MIT の自由に 2 つを足したライセンスだ。

特許ライセンスの明示 — コントリビュータは自分の特許権を一緒に譲渡する。すなわち、コントリビュータが後から自分の特許でユーザを攻撃できない。
商標除外 — ライセンスが商標利用権を与えないことを明示する。

Kubernetes、Kafka、Spark、TensorFlow、Terraform(BSL 以前)、Cassandra — クラウドネイティブ時代の大型プロジェクトが Apache 2.0 を選んだ理由はここにある。特許リスクからの安全弁が企業採用を可能にした。

1.3 GPL ファミリ — コピーレフトの最後の砦

GPL/LGPL/AGPL はコピーレフト・ライセンスだ。形は同じで、このコードを改変して配布するなら、改変版も同じライセンスで公開しなければならない。 いわば伝染性がある。

GPL v2 / v3 — バイナリ配布時にソース公開義務。Linux カーネルは GPLv2。
LGPL — ライブラリ限定の GPL。静的/動的リンクの違いでコピーレフトの及ぶ範囲が変わる。
AGPL — GPL の SaaS 穴を塞いだ版。ネットワーク経由のサービス提供でもソース公開義務。 Bruce Perens が起草し、2007 年に OSI 承認。

AGPL の最後の条項が決め手だ。通常の GPL は「バイナリを配布したとき」のみソース公開を要求する。だが SaaS はバイナリを配布しない — ホスティングして API で提供するだけだ。AWS が MongoDB を AGPL で受けてホスティングするなら、改変版のソースも公開しなければならない。 MongoDB が最初に AGPL を採用した理由でもあり、後に SSPL に移った理由でもある。AWS は AGPL でもクリーンルーム実装(DocumentDB)を作って迂回できたからだ。

2. AWS の strip-mining 問題 — 2010 年代後半の発見

2015 年頃から 1 つのパターンが明確になった。単一ベンダーが作る OSS インフラ・コンポーネントはクラウド時代にビジネスモデルが崩壊する。 理由は単純だった。

AWS/GCP/Azure はあらゆる OSS を即座にホスティングサービスとして出せる。 インフラ・マーケティング・営業チャネルがすべて揃っている。
ベンダー自身がクラウドを運営することは可能だが、AWS のユーザ規模と価格に勝てない。 AWS は同じ OSS をより安く、より統合され、より信頼性高く提供する。
AWS のコード貢献はほぼゼロ。 OSS 会社が R&D コストを負担し、AWS が売上を取る。

このパターンが最も露骨に現れたのが MongoDB → AWS DocumentDB(2019 年 1 月) だった。MongoDB が 2018 年に SSPL に移った直後、AWS は「MongoDB 互換 API」を謳う DocumentDB をローンチした。SSPL コードを使わず、ゼロから書き直したクリーンルーム実装で迂回した。MongoDB の CTO Mark Porter は後に「DocumentDB は MongoDB と 34% しか互換性がない」と公に発言したが、AWS はその 34% だけで十分な市場を取った。

似た事件が続いた。

Elasticsearch → AWS Open Distro for Elasticsearch(2019 年 3 月) — AWS は Elastic の X-Pack 有料機能の一部(セキュリティ・アラート・SQL)を OSS として再実装し撒いた。Elastic が 2021 年に SSPL に移ると、AWS はさらにフォークして OpenSearch を作った。
Redis → AWS ElastiCache — AWS は長年 Redis OSS を ElastiCache としてホスティングし、大きな売上を作っていた。2024 年に Redis がライセンスを変えると、AWS は Linux Foundation 後援の Valkey フォーク に移行した。

OSS 会社の苛立ちは結局同じ一文だった。「私たちが作ったものを AWS が売り、私たちは死につつある。」 この診断が精緻かどうかは議論の余地がある(Red Hat は同じ環境で 340 億ドルの売上を作った)。しかし、その感情がライセンス戦争の政治的燃料になった。

3. MongoDB と SSPL の誕生(2018)

2018 年 10 月 16 日、MongoDB Inc は Server Side Public License v1 を発表した。核心は AGPL を一段押し進めたものだ。

SSPL 核心条項(意訳):
「このソフトウェアを第三者にサービスとして提供する場合、
 そのサービス全体のソースコードを公開しなければならない。
 — 管理ツール、モニタリング、バックアップ、
   ロードバランサ、ユーザ認証を含むすべて。」

AGPL は「改変された OSS 本体のソース」を要求する。SSPL は 「OSS を取り巻く運用インフラ全体のソース」 を要求する。AWS から見れば実質的に使用不能だ — DocumentDB を出すために AWS 内部の運用システムまで公開する必要が出る、という意味になるからだ。

3.1 OSI の反応 — 「これはオープンソースではない」

MongoDB は SSPL を OSI に承認申請した。2021 年 1 月、OSI は明確に却下した。

「SSPL は OSI オープンソース定義(OSD)の第 6 項 — 'No Discrimination Against Fields of Endeavor' — に違反する。特定の事業領域(クラウドホスティング)を差別しているからだ。」

この判定が決定的だった。SSPL はそれ以降「source-available」と呼ばれ、オープンソースではない別カテゴリに置かれた。 これは単なる用語論争ではない。多くの企業のコンプライアンス・ポリシーは「OSI 承認 OSS のみ許可」を規定しているからだ。

3.2 MongoDB の結末 — 市場では生き残った

論争は激しかったが、MongoDB のビジネスは崩れなかった。むしろ SSPL 移行後、MongoDB Atlas の比重が継続的に上がり、2026 年時点で MongoDB 全体売上の 70% 以上が Atlas から来ている。 ライセンスがビジネスを直接救ったわけではないが — 少なくとも殺しもしなかった。

4. 反乱のタイムライン — 8 年を一目で

2010 ────────────────────────────────────────────────────────────── 2026
       パーミッシブの黄金期               反乱期と正常化

2010    Redis リリース(BSD 3-Clause)
2011    HashiCorp 創業、Terraform は MPL 2.0
2012    Elasticsearch 1.0(Apache 2.0)
2018-10 MongoDB → SSPL  AWS DocumentDB ローンチ直前
2019-01 AWS DocumentDB ローンチ
2019-03 AWS Open Distro for Elasticsearch
2021-01 Elastic → SSPL + ELv2  Apache 2.0 を放棄
2021-04 AWS が OpenSearch にフォーク
2021-01 OSI: SSPL は OSS ではない(正式判定)
2023-08 HashiCorp → BSL 1.1  Terraform、Vault、Consul、Nomad
2023-09 OpenTofu(Terraform フォーク)発表、Linux Foundation 加入
2023-11 Sentry → FSL を発明、2 年後 Apache 2.0 自動転換
2024-01 OpenTofu 1.6 GA
2024-03 Redis → SSPL + RSALv2  AWS ElastiCache へのけん制
2024-03 Linux Foundation が Valkey フォーク(Redis OSS の後継)
2024-08 Elastic → AGPLv3 オプション追加  OSI OSS へ復帰
2025-02 IBM が HashiCorp 買収完了
2025-04 OpenTofu、CNCF インキュベーション・プロジェクトへ
2025-05 Redis → AGPLv3 オプション追加  OSI OSS へ復帰
2025-11 Salvatore Sanfilippo、Redis に復帰(developer evangelist)
2026-05 現在:反乱の結末、部分的な揺り戻し

このタイムラインを見ると 共通パターン が見えてくる。(1) 単一ベンダー OSS が (2) AWS のホスティング・ローンチを経験し (3) 非 OSI ライセンスに移り (4) コミュニティ・フォークが現れ (5) 一部は OSI ライセンスに戻る。私たちはこのパターンを 「ライセンスの振り子(license pendulum)」 と呼ぶことができる。

5. Elastic のアーク — Apache 2.0 → SSPL → AGPL の 4 年

5.1 2021 年 1 月の衝撃

Elastic の CEO Shay Banon がブログに記事を投稿したとき、検索・ロギング業界は一瞬止まった。Elasticsearch と Kibana が Apache 2.0 から SSPL + ELv2(Elastic License v2) デュアル・ライセンスへ移行する、という内容だった。

Banon の名分は見慣れたものだった。

"We're forking ourselves so that nobody else needs to fork us."

AWS が Open Distro for Elasticsearch というフォークを運営している状況への答えだった。しかし OSS コミュニティの反応は冷たかった。 「10 年間 Apache 2.0 と約束したうえで貢献してきた人々への裏切り」という批判が噴出した。

5.2 AWS の答え — OpenSearch フォーク(2021 年 4 月)

3 ヶ月後、AWS は最後の Apache 2.0 バージョン(7.10.2)からフォークした OpenSearch を発表した。2026 年現在 OpenSearch は Linux Foundation 配下のプロジェクトになっており、AWS のほか Aiven、Logz.io、Bonsai などがコア・コントリビュータだ。Elastic が懸念した「検索市場の分裂」が現実に起きた。

5.3 2024 年 8 月 — AGPL への復帰

3 年半後、Elastic は再度ライセンスを変える。AGPLv3 を SSPL と ELv2 の隣に追加し、トリプル・ライセンスに切り替えた。 Banon はブログに「We are now an Open Source Initiative-approved open source company again」と書いた。

背景には 2 つの計算があった。

評判の修復: Elastic が受けた信頼の損失は大きかった。OSI 承認ライセンスへの復帰はその一部でも取り戻すための試みだった。
OpenSearch との差を詰める: OpenSearch が育つにつれ、Elastic は OSS コミュニティのマインドシェアを再び取り戻す必要があった。

AGPL は SSPL より弱いコピーレフトだが OSI 承認だ。 AWS は AGPL コードをそのままホスティング・サービスとして売れる(ただし改変分を公開すれば)。すなわち Elastic は AWS へのけん制力を一部手放し、OSI バッジを取り戻したのだ。利他的な選択ではなく、ビジネス計算だ。

6. Redis のアーク — 2024 年のデジャブ

6.1 2024 年 3 月の衝撃

2024 年 3 月 20 日、Redis Inc は Redis 7.4 からライセンスを SSPL + RSALv2(Redis Source Available License v2) のデュアルに変えると発表した。名分は Elastic と同じく「AWS、GCP、Azure が Redis OSS をそのままホスティング事業にしている」だった。

6.2 Valkey フォーク — 6 日後の答え

発表 6 日後、Linux Foundation は Valkey という Redis フォークを発表した。 AWS、Google Cloud、Oracle、Ericsson、Snap が創立メンバーだった。最後の BSD 3-Clause バージョンである Redis 7.2.4 から出発した。6 ヶ月で Valkey 8.0 が出て、2026 年現在、多くのクラウド事業者は Redis ではなく Valkey をホスティングしている。

注目すべきは Redis の生みの親 Salvatore Sanfilippo(antirez) の動向だった。彼は 2024 年時点で Redis を離れていたが、2024 年 11 月、developer evangelist として Redis Inc に復帰すると発表した。 この決定が次の展開を形作った。

6.3 2025 年 5 月 — AGPL の追加

Salvatore の復帰のおよそ 6 ヶ月後、Redis は Redis 8 から AGPLv3 を 3 番目のライセンス・オプションに追加した。 今やユーザは RSALv2、SSPLv1、AGPLv3 のいずれかを選べる。Elastic のパターンをほぼなぞった。

Redis 側のコメントは明確だった。

"We made a mistake. We are returning to OSI-approved open source — but on our terms, with AGPLv3."

コミュニティの反応は分かれた。Percona の Vadim Tkachenko は「歓迎するが、本質的にはマーケティング的な動き」と評した。Valkey はすでに十分なモメンタムを得ていて、多くのクラウド事業者は Redis に戻るインセンティブを失っていた。 ライセンスは戻せるが、信頼は戻せない。

7. HashiCorp と OpenTofu — IaC 陣営の分裂

7.1 2023 年 8 月の BSL 移行

HashiCorp は 2023 年 8 月 10 日、Terraform・Vault・Consul・Nomad・Boundary・Waypoint・Packer を一気に MPL 2.0 から BSL 1.1(Business Source License) に移した。MariaDB が作った BSL の構造はこうだ。

ソース公開: OK、誰でも見れる。
利用制限: 明示された「Additional Use Grant」の範囲を外れる場合は商用利用不可。HashiCorp の場合「HashiCorp の製品と競合する商品/サービスを提供すること」が制限対象。
4 年後の自動転換: 4 年経つと自動的に MPL 2.0 などのオープンソース・ライセンスに転換される。

表面的には「4 年待てば OSS に戻る」点で SSPL より柔らかい。しかし核心は その 4 年間、クラウド事業者が Terraform Cloud のようなホスティング・サービスを作れなくする ことだった。

7.2 OpenTofu — 1 ヶ月後のフォーク

発表 1 ヶ月後の 2023 年 9 月、OpenTF Manifesto が公開 された。Gruntwork、Spacelift、env0、Scalr、Harness といった Terraform エコシステム企業が集まり共同で出した宣言文だった。要求はシンプルだった。

HashiCorp は Terraform を MPL 2.0 に戻すこと。
さもなければ我々はフォークする。
フォークは Linux Foundation 配下に置く。

HashiCorp は拒否した。9 月 20 日に OpenTF Foundation が発足 し、11 月に OpenTofu という名前が与えられた(商標衝突を回避)。2024 年 1 月に OpenTofu 1.6.0 GA がリリースされた。

7.3 2026 年現在の風景

OpenTofu 1.9(2026 年 5 月) — for_each キーの分離、ステートの暗号化、動的プロバイダなど Terraform に無い機能を先行リリース。
CNCF インキュベーション — 2025 年 4 月に正式採択。マルチベンダー・ガバナンスが安定化。
IBM の HashiCorp 買収 — 2025 年 2 月完了。Terraform は IBM クラウド・ツール群の一角になった。

OpenTofu と Terraform は 2026 年時点でコアが分岐している。 Terraform 1.6 以後の機能のうち OpenTofu が追随しないものがあり、逆に OpenTofu の新機能を Terraform が取り込まないものがある。ステートファイル・フォーマットも微妙に分岐している。実質的に 2 つの別のツールになった。

スタートアップの判断軸は明確だ。

IBM/HashiCorp のエンタープライズ・サポートが必要 → Terraform
ベンダー・ロックイン無しの OSS を貫きたい → OpenTofu
AWS/Azure/GCP を等しく自由に使いたい → OpenTofu が安全

8. Sentry と FSL — 「2 年後に Apache 2.0」

8.1 BSL への批判

BSL の 4 年という転換期間は長かった。「4 年後に OSS」は、ある意味「今は OSS ではない」と等価だった。また BSL の「Additional Use Grant」はテキストが長く曖昧で、コンプライアンス・チームが解釈に苦労した。

8.2 FSL の発明(2023 年 11 月)

Sentry の CEO David Cramer と Heather Meeker(BSL の起草弁護士)が協力し、Functional Source License(FSL) を作った。核心は BSL をよりシンプルかつ短く整えたものだ。

FSL の核心:
- 「Permitted Purpose」: 何でも OK、ただし「Competing Use」は除く
- 「Competing Use」: ライセンサーと直接競合する商品の提供
- 2 年後に自動転換: Apache 2.0 または MIT のいずれか
- Sentry は Apache 2.0 を選択

BSL との違いは 2 点だ。

転換期間の短縮: 4 年 → 2 年。これが決め手だ。2 年なら技術サイクル上「ほぼ同世代」だ。
言語の簡素化: BSL の「Additional Use Grant」の場所が「Permitted Purpose / Competing Use」の 2 語に縮められた。

8.3 Sentry の決定 — 揺り戻し

興味深いことに Sentry 自身は 2024 年末に FSL から再び BUSL に戻した(セルフホスト Sentry と Codecov のホスティング領域で)。理由は「Competing Use」の定義が狭すぎる、というものだった。すなわち FSL は生き残ったが、発明者自身は別の道を行った。

FSL を引き継いだ会社はある。

Convex(リアルタイム・データベース)
Keygen(ライセンス管理)
そのほか多くの SaaS コンポーネントの OSS 化

FSL は BSL の「より誠実なバージョン」として定着している。「我々は OSS の真似をするのではない。2 年後には本当に OSS になる。」 この約束のほうが信頼性高く聞こえたのだ。

9. その他のライセンス — CockroachDB、Confluent、FUTO

9.1 CockroachDB → BSL → エンタープライズ

Cockroach Labs は 2019 年に BSL に移り、2024 年にはコア部分を完全に 専有ライセンス(CockroachDB Enterprise License) にした。すなわち、もう無料セルフホスティングは不可能だ。最も強硬な経路をとったケースだ。

スタートアップが CockroachDB を導入するときはこの点を知っておく必要がある。 「OSS DB」のイメージで始まったが、2026 年現在では実質的にエンタープライズ・ライセンスが必要な商用製品だ。

9.2 Confluent Kafka — Confluent Community License

Apache Kafka 自体は Apache 2.0 だ。しかし Confluent が作った付随コンポーネント(KSQL、Schema Registry の一部、Kafka Connect コネクタの多く)は Confluent Community License(CCL) という独自ライセンスだ。

CCL の核心制約: 「Kafka SaaS を提供する事業」での利用不可。 AWS MSK(Managed Streaming for Kafka)は Confluent の付随コンポーネントを使えない、ということだ。結果として AWS MSK は KSQL や Schema Registry のようなツールを自力で再実装した。

9.3 FUTO と「Source First」

Eron Wolf が作った FUTO は 2024 年に独自の FUTO License を発表した。核心条項は「非商用利用は自由、商用利用は明示的な許諾が必要」だ。OSI 定義では明らかに非 OSS だ。

興味深いのは FUTO 側の修辞 だ。彼らは「オープンソース」ではなく「Source First」という新しい用語を使う。OSI 定義に挑むのではなく、「OSS の社会的機能(透明性、学習可能性、自由な改変)は提供するが、OSI の定義には従わない」 と明示的に分離するのだ。

OSI はこの動きを快く思っていない。「open source」という言葉の定義そのものへの挑戦だからだ。しかし、2026 年時点で「source-available」「fair-code」「source-first」のような新カテゴリが事実上定着 している。OSS の単一定義は崩れつつある。

10. OSI 定義をめぐる戦い — 「オープンソース」は誰の言葉か

10.1 OSD — 10 の条項

OSI(Open Source Initiative)は 1998 年設立で、Open Source Definition(OSD) の 10 条項を維持している。核心となるものを抜き出す。

自由再配布(Free Redistribution) — 誰でも自由に再配布可能。
ソースコード(Source Code) — ソースコードの同梱または無償アクセス可能。
派生物(Derived Works) — 改変・派生物が許可される。
作者ソースの完全性(Integrity of The Author's Source Code) — 改変をパッチ形式で配布させる方式を許容。
個人/グループへの差別禁止(No Discrimination Against Persons or Groups)。
使用分野の差別禁止(No Discrimination Against Fields of Endeavor) — この条項が SSPL を阻んだ。
ライセンスの配布(Distribution of License)。
製品固有禁止(License Must Not Be Specific to a Product)。
他ソフトウェアへの制限禁止(License Must Not Restrict Other Software)。
技術中立(License Must Be Technology-Neutral)。

10.2 第 6 条項の重み

第 6 条 — 「使用分野の差別禁止」。これが要だ。SSPL、BSL、FSL、CCL、FUTO 全てが共通点を 1 つ持つ — クラウドホスティング事業という特定の事業領域に制限をかける。 これは第 6 条違反だ。

OSI の立場は一貫している。「ライセンスが誰かの利用を阻むなら、それはオープンソースではない。」これは単なる用語の問題ではない。GPL から MIT まで、全 OSI 承認ライセンスが第 6 条を守っている。 それが OSS エコシステムの信頼基盤だ。

10.3 「source-available」陣営の反論

ベンダー側の反論も明確だ。

「OSI 定義は 1998 年に作られた。その時代の敵はマイクロソフトのプロプライエタリ・ライセンスだった。2026 年の敵は違う — AWS の無限の資本を持ったクラウド・ホスティングだ。1998 年の定義では 2026 年の脅威を防げない。」

この論争は決着していない。OSI は「open source」という言葉を守り、ベンダーは「source-available」という新しい言葉を受け入れる — 一種の住み分けが起きた。 その向こうには大きな問いがある。「オープンソース会社はビジネスとして生き残れるのか?」この問いに明確な答えを持つ者はまだいない。

11. ライセンス対権利マトリクス(2026)

ライセンス別にユーザが得る権利をマトリクスで比較する。Y は許可、N は不可、C は条件付き。

権利	MIT	Apache 2.0	GPL v3	AGPL v3	BSL 1.1	SSPL v1	FSL 1.1	ELv2	RSALv2	CCL
ソース閲覧	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
内部での改変・利用	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
プロプライエタリで再配布	Y	Y	N	N	C	C	C	C	C	C
コピーレフト義務	N	N	Y	Y(ネット)	N	Y(強)	N	N	N	N
特許ライセンスの明示	N	Y	Y	Y	N	Y	N	N	N	N
ホスティング事業として運営	Y	Y	Y	Y(ソース公開時)	N(条件付き)	C(全体公開)	N(2 年間)	N	N	N
OSI 承認	Y	Y	Y	Y	N	N	N	N	N	N
時間経過で OSS 化	-	-	-	-	4 年後	-	2 年後	-	-	-

このマトリクスが判断の助けになる。OSI バッジが必要なら GPL ファミリかパーミッシブしかない。 クラウド事業をけん制したいなら SSPL/BSL/FSL/ELv2 のいずれかだ。時間が答え(いつかは OSS)なら FSL が最も早い(2 年)。

12. 意味 — 誰にどう影響するか

12.1 スタートアップ:OSS DB/コンポーネントを選ぶとき

核となる問い — 「このライセンスの変更リスクはどれくらい大きいか?」

スタートアップがデータ・インフラに依存するとき、ライセンス変更は直撃弾だ。だから次の順序で評価する。

ベンダー・ロックイン・リスク — 単一企業が支配する OSS か、マルチベンダー・ガバナンス(CNCF、Linux Foundation、Apache Foundation)か?
パーミッシブ vs コピーレフト — 我々のコードがその OSS を埋め込むのか、別プロセスで分離するのか?
ホスティング事業の可能性 — 我々のサービスは実質的に「その OSS のホスティング・サービス」になりうるか?
長期依存度 — 5 年後もこのコンポーネントが必要か?

12.2 クラウドベンダー:ホスティング事業

AWS・GCP・Azure の視点ではライセンス風景は次第に複雑になる。2026 年時点の対応パターン。

フォーク + 自社運営: OpenSearch、Valkey。AWS が直接フォークしてホスティング。
クリーンルーム再実装: DocumentDB。SSPL コードを使わず互換 API のみ提供。
収益分配契約: 一部の OSS 会社と直接の収益分配。Confluent ↔ AWS、MongoDB ↔ AWS の一部協業。
買収: HashiCorp → IBM、GitLab → 試み、など。

12.3 OSS プロジェクト:持続可能性

OSS プロジェクトのメンテナの立場で言えば、ライセンス決定はすなわちビジネスモデル決定だ。2026 年に合意されつつあるパターンがあるとすれば、これだ。

純 OSS の単一ベンダーは難しい — Red Hat モデルは例外的な規模とタイミングでしか通じない。
クラウド事業者との真正面衝突は自滅 — AWS と直接競合するホスティング事業で勝つのはほぼ不可能。
Open Core が最も現実的 — コアは OSS、付加機能はプロプライエタリ。
財団への移管が信頼を作る — CNCF、Linux Foundation、Apache 配下に行った瞬間、ライセンス変更リスクが消える。

13. ライセンス決定木(スタートアップ/メンテナ用)

新しい OSS プロジェクトのライセンスを決めるとき、次の順序で問う。

[1] このプロジェクトは単一企業が主導するか?
    ├─ Yes → [2]
    └─ No(財団/マルチベンダー基盤) → Apache 2.0 推奨。終わり。

[2] 5 年以内に SaaS/ホスティング事業にする意図はあるか?
    ├─ Yes → [3]
    └─ No(純 OSS、コンサル/サポート・モデル) → MIT または Apache 2.0。終わり。

[3] ホスティング事業の直接の競合(AWS/GCP/Azure)は脅威か?
    ├─ Yes → [4]
    └─ No(社内ツール、B2B SaaS 中心) → Apache 2.0 + 商標保護強化。終わり。

[4] OSI 承認バッジはコンプライアンス上必須か?
    ├─ Yes → AGPLv3。終わり。(Elastic、Redis が選んだ経路)
    └─ No → [5]

[5] 「いつか OSS に返す」約束を明示したいか?
    ├─ Yes、2 年 → FSL 1.1
    ├─ Yes、4 年 → BSL 1.1
    └─ No、永続専有 → ELv2 または独自ライセンス(Codeium モデル)

この木は絶対的なものではない。しかし自分がどのノードでどう答えたかを明示的に追跡しておけば、将来ライセンスを変える必要が出たとき、その変更の正当性を外部に説明できる。Elastic と Redis がライセンスを変えた後に受けた非難の少なくない部分は、「なぜそう決めたのかを最初に言わなかったから」だった。

14. アンチパターン — こうしてはいけない

ライセンス決定でよく見る失敗を整理する。

14.1 「オープンソース」という言葉の誤用

非 OSI ライセンスを「open source」と呼んだ瞬間、OSI と衝突し、コンプライアンス・チームが導入を止める。2026 年時点で正確な用語は「source-available」だ。 これを明確にしておく。

14.2 突然のライセンス変更

Elastic と Redis が最も高くついた部分だ。ライセンス変更は最低 6 ヶ月前から予告し、名分とデータを併せて公開せよ。 「突然」はほぼ常に信頼を壊す。

14.3 CLA(Contributor License Agreement)無しのデュアル・ライセンス開始

コントリビュータが自分のコードの著作権を保持したままだと、企業はライセンスを自由に変えられない。商用化の意図があるなら最初から CLA または DCO + 著作権譲渡を取るべきだ。 Redis がライセンスを変えられたのも、コントリビュータ・コードの著作権が全て Redis Inc にあったからだ。

14.4 「AWS が脅威」という誤った名分

ほとんどの OSS プロジェクトにとって AWS は脅威ではない。AWS にホスティングされるほど大きい OSS はごく少数だ。自分のプロジェクトがその少数に入らないなら、AWS けん制を名目にした BSL/SSPL は自分の足に斧を振り下ろすことに等しい。 採用速度を落とすだけだ。

14.5 4 重ライセンスの罠

Elastic は現在 AGPLv3 + SSPLv1 + ELv2 の 3 つを同時提供する。「ユーザが選べ」という親切ではあるが、コンプライアンス・チームには悪夢だ。 どのライセンスを適用するかを明示的に選ばねばならず、その選択を依存コンポーネント全体に整合的に反映する必要がある。

エピローグ — 8 年後、私たちは何を学んだか

2018 年の MongoDB の SSPL 発表から 2025 年の Redis の AGPL 復帰まで — 8 年だった。その間に学んだことをまとめると短い。

ライセンスはビジネスモデルの表現であって、ビジネスモデルそのものではない。 ライセンスを変えても売上は増えない。
クラウド事業者をライセンスで防げるという発想は部分的にしか正しくない。 AWS はほぼ常にクリーンルーム実装(DocumentDB)やフォーク(OpenSearch、Valkey)で応答する。
OSI バッジの価値は大きい。 コンプライアンス、採用、PR — すべての側面に効く。だから Elastic と Redis は結局 AGPL に戻った。
財団への移管は信頼の最終形だ。 CNCF・Linux Foundation 配下のプロジェクトはライセンス変更リスクが事実上ゼロだ。
8 年の振り子運動の結果、市場は正常化に向かいつつある。 SSPL/BSL は生き残ったが極めて狭い領域に限定され、多くの企業が AGPL や Open Core に揺り戻した。

この記事を読むあなたが 2026 年に OSS コンポーネントを 1 つ選ぶなら、最後のチェックリストはこうだ。

意思決定チェックリスト — OSS 導入時

この OSS のライセンスは OSI 承認か? (MIT、Apache 2.0、BSD、GPL、AGPL、MPL、EPL)
単一企業が支配しているか、財団(CNCF/LF/ASF)が支配しているか?
直近 5 年にライセンス変更があったか?今後の変更可能性は?
フォーク版が存在するか?メインに対する採用率は? (OpenSearch、Valkey、OpenTofu など)
我々の利用パターンが AGPL のコピーレフトを発動するか? (ネットワーク経由で外部ユーザに公開)
コンプライアンス・ポリシーは SSPL/BSL/FSL を許容するか?
5 年後もこのコンポーネントが必要な可能性があるか?その場合の移行経路は?

次回予告

次回は 2026 年のオープンソース・ガバナンスのマクロ風景 — 財団(CNCF、Linux Foundation、Apache、Eclipse)の役割の変化、政府規制(EU CRA、米国行政命令)が OSS に及ぼす影響、AI モデルの重みはオープンソースなのかという未解決の問い — を扱う。ライセンスが一行の文字なら、ガバナンスはその文字が息づく政治構造だ。