Skip to content
Published on

オープンソースライセンス大転換 2026 — BSLの波: Elastic / Redis / HashiCorp / Sentry / Valkey / OpenTofu 徹底解説

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 2026年、我々はどうやってここまで来たのか

2026年5月現在、「これって本当にオープンソースですか？」という問いが、エンジニアリングチームのSlackで週に一度は飛び交う。Elastic、Redis、HashiCorp、MongoDB、Sentry、Cockroach、Confluent、MariaDB、n8n — 我々が毎日使っているツールの相当数が、もはやOSI（Open Source Initiative）が承認するライセンスでは配布されていない。

過去7年間に起きたことを一文に圧縮するとこうなる。「クラウド会社（とりわけAWS）が我々のコードでマネージドサービスを売り、我々より多くの収益を上げる」という認識と、それに対抗するOSS企業のライセンス変更。 その結果、OSI定義に該当しない「source-available」ライセンスが続々と登場し、そのたびにコミュニティフォークが生まれた。

本記事ではその7年史を整理する。誰がいつ何を変え、なぜそうしたのか、どのフォークが生き残ったのか、そして2026年現在、自社がどう判断すべきかを見ていく。12章、約65分の分量である。

主要な変化を3つ先に挙げる。

  • BSLが事実上の標準となった。 2018年MongoDBがSSPLを生み出し、2023年HashiCorpがTerraform/Vault/ConsulをBSLに移し、2024年Redis・Sentry・Cockroachが次々と続いた。新規インフラOSSの半分以上がBSLまたはその派生で始まる。
  • フォークは必ず起こる。 Elastic → OpenSearch（AWS, 2021）、Terraform → OpenTofu（LF, 2023）、Vault → OpenBao（LF, 2024）、Redis → Valkey（LF, 2024）。Linux Foundationが事実上「フォークのインキュベーター」の役割を果たしている。
  • OSI定義が揺れている。 「source-availableもオープンソースとして認めて欲しい」という圧力と、「OSI定義は壊れている」という批判が同時に存在する。2024–2025年、OSIはAIモデル向けのOSAID（Open Source AI Definition）を作成し、再び論争の中心に立った。

1章 · 2026年のオープンソースライセンス — なぜ皆が非-OSIへ向かうのか

まず「非-OSIライセンス」とは何かを定義しよう。OSIは1998年に設立された非営利団体で、「オープンソース」という言葉の定義（Open Source Definition, OSD）を管理している。OSDには10の条項があるが、最も頻繁に衝突するのは第6条（差別禁止：「特定の事業分野での利用を制限してはならない」）である。

BSL・SSPL・RSALv2・FSL・ELv2 — 本記事で扱うライセンスの大半は第6条に違反する。マネージドサービスとしての販売を禁じるか、一定の収益を超える企業には別の扱いをするか、一定期間後に Apache に変わるか、のいずれかである。

なぜ企業は非-OSIへ向かうのか。 理由は3つに集約できる。

  1. AWS・Google・MSのマネージドサービス競争。 Amazon ES（2015）、Amazon RDS、Amazon DocumentDB（MongoDB API 互換）、Amazon MemoryDB（Redis 互換）、Amazon EMR（Hadoop・Spark） — AWSがOSSを取り込みマネージドとして売るパターンが繰り返された。OSSを作った企業のトラフィックはAWSへ流れ、企業の収益は停滞する。

  2. VCからの圧力。 OSS企業の多くがシリーズB/C段階で収益が伸び悩む。2020–2023年のZIRP（ゼロ金利政策）が終わり、VCは「どうマネタイズするのか」をより強く問うようになった。ライセンス変更はその最も直接的な回答である。

  3. 模倣の加速。 MongoDBが2018年SSPLへ移行してうまくいった（株価は一度下落したが完全に回復した）。Elasticが2021年SSPL/ELv2へ、HashiCorpが2023年BSLへ続いた。「前例がある、市場が受け入れた」というメッセージが、次の企業の判断を容易にする。

非-OSIライセンスの種類。

ライセンス発祥主要な制約OSI承認？
SSPL (Server Side Public License)MongoDB (2018)サービス提供時、SaaSスタック全体をSSPLで公開する義務いいえ
BSL (Business Source License)MariaDB (2013)4年（または設定期間）後にApache 2.0へ自動転換、その間はproduction利用制限いいえ
ELv2 (Elastic License v2)Elastic (2021)マネージドサービスとしての提供・迂回を禁止いいえ
RSALv2 (Redis Source Available License v2)Redis (2024)マネージドサービスとしての提供を禁止いいえ
FSL (Functional Source License)Sentry (2023)2年後にApache 2.0またはMITへ転換、その間は競合禁止いいえ
Sustainable Use Licensen8n (2022)内部利用・組込は可、ホスティング販売は禁止いいえ
AGPL v3FSF (2007)ネットワーク経由で提供してもソース公開義務ありはい（OSI承認）

2024年8月のElasticのAGPL復帰により、AGPLは「BSLの代替」として再評価された。AGPLはOSI承認の本物のオープンソースでありながら、「AWSがマネージドで販売するなら自社コードも公開せよ」という効果があり、企業側からするとSSPLよりすっきりしている。

2章 · OSI定義 vs 「Source-Available」論争

OSI定義（OSD）は10条からなる。そのうちBSL・SSPLが違反するとOSIが明言した条項は以下の通り。

  • OSD #5（個人・グループへの差別禁止）： SSPLは「SaaS企業であれば異なる扱いとなる」という差別を行うという解釈。
  • OSD #6（利用分野への差別禁止）： BSLは「production利用禁止」という分野制限を設ける。
  • OSD #9（他ソフトウェアへの差別禁止）： SSPLが「このコードと一緒にバンドルされる全ソフトウェアもSSPLで公開せよ」という条項を置くことで、他ソフトウェアへの差別を生むという解釈。

2019年、OSIはSSPLがOSDに該当しないと公式声明した。MongoDBがOSIにSSPL承認を申請して撤回した出来事である。それ以降、BSL・ELv2・RSALv2・FSLも同様の理由でOSI承認に至っていない。

「Source-Available」という用語。 OSI承認を得られなかったライセンスは自身を「source-available」と呼ぶ。コードは公開されている（読めるしフォークもできる）が、一定用途では使えない、という意味だ。

問題は一般の開発者がその区別を知らないことである。GitHubページに「BSL」または「FSL」のラベルが貼られていても、「オープンソースだから自由に使えるだろう」と考えてproductionに導入する。1年後、法務が「これはBSLだからproduction利用はライセンス違反です」と言えば、その会社は次の2択をする — (a) ライセンス購入、(b) 他のOSSへ移行。

「オープンソースという言葉を奪うな」。 非-OSI陣営の反論は「OSI定義は1998年に作られ、クラウドマネージドサービスという現実を反映していない」というものだ。HashiCorpのArmon Dadgar、MongoDBのEliot Horowitz、SentryのDavid Cramerが似た主張をしている。「我々が作ったコードを我々がどうライセンスするかを決める権利がある」。

OSIの立場。 OSIは「もちろん企業は自社コードを好きにライセンスできる。しかし『オープンソース』という言葉はOSDに該当するライセンスにのみ使って欲しい」と一貫している。2025年、OSI事務局長のStefano Maffulliは「BSLをオープンソースと呼ぶのは、ベジバーガーを牛肉と呼ぶようなものだ」と発言した。

この論争は終わらない。2026年現在もOSI定義はそのままだが、「source-availableを何と呼ぶか」という新たなラベル戦争となっている。Fair Source、Sustainable Source、Functional Source — 新しい呼称が毎年一つずつ増える。

3章 · Elastic 2021（SSPL+ELv2）→ OpenSearch（AWS）→ Elastic AGPL復帰（2024.8）

ElasticのライセンスジャーニーはBSLの波の最も象徴的なケースだ。2010年にShay Banonが作ったElasticsearchのライセンスは Apache 2.0だった。2015年にAWSがAmazon Elasticsearch Serviceをローンチし、そこから7年にわたる緊張が始まった。

2018–2020年: 最初の衝突。 Elasticは2018年に「X-Pack（セキュリティ・モニタリング）」コードの一部を公開したが、ライセンスはElastic Licenseのままだった。AWSはX-PackをクローンしたOpen Distro for Elasticsearchを発表（2019）。両陣営が互いを「fork hostile」と非難した。

2021年1月: SSPL+ELv2へ移行。 ElasticはElasticsearchとKibanaをApache 2.0からSSPLまたはElastic License v2のデュアルライセンスへと移すと発表した。ユーザーはどちらかを選ぶ必要があり、どちらもOSI承認ではない。

AWSの反応は即座だった。OpenSearchフォーク発表（2021年4月）。 Elastic 7.10（最後のApacheライセンス版）をベースにOpenSearchを作り、Apache 2.0を維持。同年Amazon ESはAmazon OpenSearch Serviceに改称された。

2021–2024年: 並行宇宙。 2つのプロジェクトは別々に進化した。ElasticsearchはElasticの商用機能を素早く統合し、OpenSearchはAWS・Logz.io・Aivenらのコンソーシアムによって発展した。機能的には似ているがAPIとクライアントが微妙に乖離した。どちらへの移行も「コード少し + 運用ノウハウ大量」の変更を求めた。

2024年8月: ElasticのAGPL復帰。 Shay Banonが自らブログで「We are back open source」と書いた。ElasticsearchとKibanaにAGPL v3オプションを追加し、SSPL/ELv2/AGPLのトライアルライセンスとなった。AGPLはOSI承認なので、再び「本物のオープンソース」と言えるようになった。

なぜ戻ったのか。 Banonの説明は2点。(1)「AWSとの関係が良くなった」 — Amazon OpenSearch Serviceが定着し、AWSがもはやElasticを脅威と見なしていない。(2)「オープンソースコミュニティの信頼を取り戻したい」 — SSPLは批判を受け過ぎた。

2026年現在の景色。 ElasticsearchとOpenSearchは双方とも生き残った。AWSはOpenSearchを2024年Linux Foundationに寄贈し、OpenSearch Software Foundationを設立した。OpenSearchはもはや「AWSのもの」ではなく、本物のLFプロジェクトだ。Elasticsearchは自社SaaS（Elastic Cloud）とセルフホスティングライセンスで収益を作る。両陣営とも「勝った」と言える状態にある。

教訓。 Elasticのケースは「ライセンス変更は片道ではない」ことを示している。非-OSIへ行ってOSIへ戻った最初の大型プロジェクトだ。ただしその3年の間にOpenSearchという本物のフォークが定着し、そのフォークは消えない。

4章 · HashiCorp 2023 BSL → IBM買収（2024）→ OpenTofu（Terraform）＋ OpenBao（Vault）

HashiCorpはTerraform・Vault・Consul・Nomad・Packer・Vagrant・Boundary・WaypointなどインフラOSSラインナップで有名だ。2014年創業後、ほぼ全てのツールがMPL 2.0（Mozilla Public License）または類似のOSI承認ライセンスだった。

2023年8月: BSLへ移行。 HashiCorpは主要製品（Terraform・Vault・Consul・Nomad・Packer・Boundary・Waypoint）の全てをMPL 2.0からBSL v1.1へ移すと発表した。Change Dateは4年、Change LicenseはMPL 2.0。その期間は「競合製品としての利用禁止」条項がある。

理由は明確だった。Spacelift、env0、ScalrといったSaaS企業がTerraform Cloud（HashiCorpのSaaS）と直接競合するSaaSを構築していた。HashiCorpの立場からすると「我々が作ったツールで我々と競合するのは不公正」というものだった。

OpenTofu フォーク（2023年9月）。 BSL発表の1ヶ月後、Spacelift・env0・Harness・Gruntwork・ScalrなどTerraformエコシステム企業が集まり、Terraformフォークを発表した。最初の名前はOpenTFだったがすぐにOpenTofuに改名された。2024年1月、Linux Foundation傘下のプロジェクトとして正式発足し、Apache 2.0ライセンスを維持する。

OpenTofuは急速に成長した。2024年1.6 GA、2024年5月1.7（state encryption機能を追加 — 本家Terraformにはない機能）、2026年現在v1.10系まで進んでいる。本家Terraformとほぼ互換だが、徐々に独自機能が増えている。

2024年4月: IBMがHashiCorp買収を発表。 IBMが64億ドルでHashiCorpを買収すると発表した。2024年末のEU・UKの規制承認を経て、2025年2月に買収が完了した。HashiCorpはIBM Red Hat配下の一事業部となった。

買収後もHashiCorpのライセンスポリシーは一貫している。BSLをそのまま継続し、一部製品はIBMの他ライン（Red Hat OpenShiftなど）と統合される形だ。一部の懐疑論者は「IBMが入ったから再びオープンソースに戻るだろう」と見たが、2026年現在そのような動きはない。

OpenBao フォーク（2024年4月）。 VaultフォークはOpenTofuより少し遅れて出た。IBM発表と近い時期に、Linux FoundationがOpenBaoプロジェクトを発表した。Mozilla Public License 2.0（Vaultの元のライセンス）を維持し、GitLab・1Password・SUSEらが参加する。

OpenBaoはOpenTofuほど速く成長していない。Vaultは利用パターンがより複雑（「HCP Vault」のようなマネージドサービスが定着）で、フォークの即時的価値が見えにくい。それでも2025年v2.0リリースで正式GAとなった。

2026年の景色。 TerraformとOpenTofuは並行進化中だ。小さなチームとOSSフレンドリーな組織はOpenTofuへ、エンタープライズとIBM/Red Hatエコシステムにある組織はTerraform/HCPへ向かう。VaultとOpenBaoも似た分岐が進行中だ。会社が「どちらを使うか」を決める際、ライセンス以外に「チームにIBMコントラクトがあるか、1Passwordを使っているか」のようなコンテキストが影響する。

5章 · Redis 2024 SSPL+RSALv2 → Valkey（Linux Foundation）

Redisは2009年Salvatore Sanfilippoが作ったインメモリデータストアだ。ライセンスはBSD 3-Clauseで始まり、2010年代後半にRedis Labs（現Redis, Inc.）が会社を作り商用化した。コアRedisはBSDを継続したが、モジュール（RediSearch・RedisGraph・RedisJSON・RedisTimeSeries）は2018年からRedis Source Available License（RSAL）へ移った。

2024年3月: コアRedisもSSPL/RSALv2へ。 RedisはRedis 7.4からBSDを離れ、SSPLv1とRedis Source Available License v2（RSALv2）のデュアルライセンスへ移ると発表した。中核モチベーションは同じだった — AWS ElastiCache・Google Memorystore・Azure Cache for RedisがRedisの上でマネージドサービスを売るが、Redis Incは直接収益を得られない。

Valkey フォーク（2024年3月、同週）。 ライセンス発表の1週間も経たないうちに、AWS・Google・Oracle・Ericsson・SnapらがLinux Foundation傘下のValkeyプロジェクトを発表した。Redis 7.2.4（最後のBSD版）をベースに、BSD 3-Clauseを維持する。Madelyn Olson（元々Redisコアメンテナーの一人、AWS所属）らが核となるメンテナーとして移った。

Valkeyは素早く定着した。2024年4月v7.2.5（Redis互換）、2024年9月v8.0（独自機能開始 — マルチスレッドI/Oの改善）、2025年v8.1、2026年5月現在v9.x まで来ている。AWS ElastiCache for Valkeyが正式ローンチ（2024年10月）、Google MemorystoreもValkeyオプションを追加（2025年）。

Redis Incの応答。 RedisはRedis 7.4・8.0を素早くリリースし、Vector Search・JSONなどのモジュール機能をコアに統合して差別化を図った。また自社SaaSであるRedis Cloudの価格を簡素化。2025年、Redisはもう一度ライセンス調整を行った — Redis 8.0からAGPL v3をオプションとして追加し、トライアルライセンスとなった（SSPLv1 / RSALv2 / AGPLv3）。Elasticが歩んだ道に似ている。

2026年の景色。 Redis vs Valkeyは最も活発なフォーク競争の一つだ。Valkeyは「本物のOSS、クラウドフレンドリー」として、Redisは「より速い新機能 + エンタープライズ」としてポジショニングしている。小さなチームがValkeyに移る速度は速い — コード互換性がほぼ100%なので移行コストが低いからだ。

技術的差異が生まれ始めている。 Valkey 8.0のマルチスレッドI/Oは単一ノードのスループットを2–3倍引き上げた。Redis 8.0も似た機能を入れたが実装が違う。2026年現在、両者は「同じプロトコル、異なる内部」へと分岐中だ。1–2年後にはライブラリ・ツールが片方だけ対応する状況が増えるだろう。

6章 · MongoDB 2018 SSPL — BSLの本家

この一連の物語の起点はMongoDBである。MongoDBは2009年10gen（現MongoDB Inc）が作ったドキュメントDBで、当初はAGPL v3ライセンスだった。2010年代半ば、AWSがAmazon DocumentDBを発表するより前から、MongoDBはマネージドホスティング事業者との緊張を抱えていた。

2018年10月: SSPL発表。 MongoDBはAGPL v3を離れてServer Side Public License v1（SSPL）へ移ると発表した。SSPLはAGPL v3をベースにしているが、「サービスとして提供する場合、そのサービスのスタック全体（管理ツール、バックアップツール、モニタリング、インターフェース等）をSSPLで公開する義務」を追加している。

この条項は事実上「AWSはMongoDBをマネージドで売るな」を意味した。AWSがECS・EC2・IAMコードをSSPLで公開するはずがないからだ。

OSIのSSPL拒否（2019）。 MongoDBはSSPLをOSIに承認申請したが撤回した。OSIは「SSPLがOSD #5、#6、#9に違反する」と明示した。それ以降、SSPLは「オープンソースではない source-available ライセンス」に分類される。

Amazon DocumentDB ローンチ（2019年1月）。 SSPL発表3ヶ月後、AWSはAmazon DocumentDBをローンチした。MongoDB API互換だが、実際には別エンジン（Aurora ベース）。MongoDBは「Mongo互換を迂回したクローン」と批判したが、コードを直接使わない限りはライセンス違反ではない。

MongoDBへのビジネスインパクト。 興味深いことに、MongoDBの株価はSSPL発表直後に下落したが素早く回復し、2020–2021年に急騰した。MongoDB Atlas（マネージドサービス）が急成長したためだ。2026年現在、MongoDB AtlasはMongoDBの収益の70%超を占め、企業の時価総額は200億ドル台だ。

MongoDBケースの意味。 MongoDBは2つのことを証明した。(1)ライセンスを変えても企業は生き残る。 SSPLは死のキスではなかった。(2)しかしコミュニティの信頼は失う。 MongoDBが「オープンソース企業」と自称することを、多くの開発者がもはや受け入れない。GitHubでMongoDBにPRを送る外部コントリビューターはSSPL以降激減した。

その後の全てのBSL判断 — Elastic、HashiCorp、Redis、Sentry — はMongoDBの前例を参照した。「MongoDBがやったから我々もできる」という心理的障壁除去効果が大きかった。

7章 · Sentry 2024 FSL（Functional Source License）

Sentryは2008年に始まったエラートラッキングツールだ。長らくBSD 3-Clauseで配布され、2019年にBusiness Source Licenseへ移った経緯がある。2024年には自社定義のFSL（Functional Source License）を発表し、再びライセンス論争の中心に立った。

FSLの定義。 Functional Source Licenseは以下2つの主要条項を持つ。

  1. Non-compete 期間： 公開日から2年間、「Sentryの競合製品を作るために」このコードを使えない。「内部利用」「組込」「修正の上で自社利用」は全てOK。
  2. 自動OSS転換： 2年後、コードは自動的にApache 2.0（またはMIT、選択可）へ転換される。だから「現時点の2年前のバージョン」は本物のオープンソースである。

なぜFSLを作ったのか。 Sentry CEOのDavid Cramerはブログでこう書いた。「BSLは曖昧過ぎる、SSPLは強すぎる。我々が望むのはシンプルだ — 競合が我々のコードで我々と競合することは防ぐ、だが2年後には解放する」。

FSLはBSLと比べて2点が異なる。(a)non-compete期間がより短い — BSLは4年、FSLは2年。(b)production利用は最初からOK — BSLはproduction利用そのものを制限するが、FSLは「競合製品としての利用」だけを禁じる。

Fair Source 運動。 SentryはFSLを「Fair Source」というより大きな運動の一部として位置付けた。fair.io というサイトを作り、FSLを採用した企業のリストを管理している。2025年現在、30社程度がFSLを採用 — PowerSync、GitButler、Keygen、Bytebase など。

OSIの立場。 OSIはFSLもOSDに該当しないと見た（同じ差別禁止条項）。だからFSLは「source-available ライセンス」カテゴリに入る。ただし「2年後の自動OSS転換」というメカニズム自体は、OSIも肯定的に評価した。

2026年現在。 SentryはFSLを積極的に広めている。fair.ioのマニュアル・テンプレートライセンスを使い、新規OSSプロジェクトが最初からFSLでスタートするケースが増えている。ただし大型インフラOSS（データベース・メッセージキュー等）は依然BSL/SSPLを好む — FSLが2年後に自動転換されるのは企業側からすると負担だ。

評価。 FSLは「BSLのソフトバージョン」または「Apacheへの時差ライセンス」と捉えられる。小さなOSS企業には合理的な中間案だが、大型インフラでは採用が遅い。

8章 · Cockroach Labs 2024 変更

CockroachDBは分散SQLデータベースで、2015年Cockroach Labsが始めた。最初はApache 2.0だったが、2019年にBSL 1.1へ移行（Change Date 3年、Change License Apache 2.0）。コアはBSL、エンタープライズ機能は別途 commercial ライセンスだった。

2024年8月: CockroachDB Community Licenseへ転換。 Cockroach LabsはCockroachDB v24.3 からBSLを離れ、自社定義の「CockroachDB Community License」（CCL）へ移ると発表した。主要変化は2点。

  1. 無料利用枠が縮小。 「non-production」または「年間収益1千万ドル未満の企業」のみ無料利用可能。それ以上はcommercialライセンスが必要。
  2. 全機能が1ライセンスに。 以前は「OSSコア + エンタープライズ」だったが、今は1パッケージに全て入り、ライセンスが利用コンテキストで分かれる。

コミュニティの反応。 Cockroach Labsの変更は他のBSLケースより強い反応を呼んだ。「事実上、商用ソフトウェアを無料体験版のように出している」という批判があった。小さなスタートアップが枠を超えた瞬間、突然高額なライセンスを買わなければならない構造だからだ。

フォークは起きたか。 興味深いことに、CockroachDBフォークは大規模には起きていない。理由は2つ。(1)分散SQLは運用複雑性が高過ぎる。 Redis・Terraform程度のフォークは運用チームが直接運用できるが、CockroachDBのような分散システムをフォークして維持するにはコアエンジニア10名以上が必要。(2)代替が既に存在する。 YugabyteDBが類似の分散SQLをApache 2.0で提供しており、わざわざフォークしなくても移行オプションがある。

2026年現在。 CockroachDBは商用収益に集中し、大型エンタープライズ顧客へ向かっている。小さなチームはPostgres + Citus、YugabyteDB、TiDBのような代替へ移行中。Cockroach Labsはライセンス変更の「フォーク免疫」ケースだが、同時に「コミュニティ縮小」ケースでもある。

9章 · n8n Sustainable Use License — Fair Source 運動のもう一つの分岐

n8nはワークフロー自動化ツールで、2019年ドイツで始まった。Zapier・Makeのセルフホスティング代替として地位を築いた。ライセンスが興味深いのは、最初から「non-OSI」ライセンスを自社で定義して使ってきた点だ。

Sustainable Use Licenseの中核。 n8nのライセンスは以下を許容する。

  • 内部利用： 企業内のワークフロー自動化は無料。
  • 組込： n8nを自社製品の中に組み込んで利用 — ただし「n8nをホスティングサービスとして再販」は禁止。
  • 修正・貢献： コード修正とPRは歓迎。

禁止するのはただ一つ — 「n8nをマネージドSaaSとして売るな」。n8n Incが直接運営するn8n Cloudと競合するなということだ。

なぜSULか。 n8n CEOのJan Oberhauserは「MITやApacheへ行けば、Zapierが我々のコードを取りZapier内に組み込むだろう。AGPLへ行けば同じことが起きてもコード公開義務があり、我々に若干の保護にはなるが、ユーザー側からすると強過ぎる。その中間が必要だった」と説明した。

Fair Source 運動の一員。 n8nはSentryのfair.io運動に参加する。SULはFSLとは異なるが、精神は似ている — 「我々が作ったツールを我々がどうマネタイズするかをコントロールできるライセンスだが、ユーザーには最大限の自由を与える」。

2026年現在。 n8nは急成長中だ。2025年シリーズBファンディング（約7,000万ドル、Highland Europe ら）を獲得し、AIワークフロー自動化分野でZapier・Makeと本格競争中。SULライセンスは「オープンソースではない」ことへの不満が一部あるが、n8nのセルフホスティングユーザーベースは増え続けている。

Fair Source の他事例。 PowerSync（DB sync）、GitButler（Git GUI）、Keygen（ライセンス管理）、Bytebase（DB DevOps） — 全てfair.ioのメンバーでSULまたはFSLを採用。小さなOSS企業が最初からcommercial-friendly source-availableでスタートする傾向が強まっている。

10章 · AWS「strip-mining」言説 — どこまで真実か

過去8年間のBSLの波を説明する最も一般的な単語は「strip-mining」だ。「AWSがOSSの価値を『鉱山のように掘り尽くし』自社マネージドサービスとして売る」というイメージである。MongoDB・Elastic・HashiCorp・Redisが皆、この言説を明示的あるいは暗示的にライセンス変更の正当化に用いた。

どこまで真実か。 部分的に真実だが、単純化された面もある。

真実な部分:

  • AWSはOSSを取り込みマネージドで売るパターンを繰り返した。Amazon ES（2015）→ MongoDB API クローンDocumentDB（2019）→ MemoryDB（Redis互換, 2021）。
  • AWSのOSSマネージドサービス収益は数百億ドル台だ。OSSを作った企業の収益と直接比較すると差は大きい。
  • AWSがOSSプロジェクトにコード貢献する比率は（過去基準で）極めて低かった。「取るだけで与えない」という批判があった。

単純化された部分:

  • AWSがOSS企業の直接収益を奪ったという単純なモデルは不正確だ。AWSマネージドサービスはOSSの知名度を高める効果もある。Elasticsearchの世界中のユーザーベースはAWS Elasticsearch Serviceのおかげで爆発的に成長した。
  • 2020年以降AWSのOSS貢献は増えた。Valkey・OpenSearch・OpenTelemetry・Karpenter・Bottlerocket・Firecracker などは全てAWSが作るか主導するOSSだ。
  • 「AWSが我々の収益を奪う」という認識は、しばしば「我々がエンタープライズsalesをできず収益が停滞している」の代替説明でもある。AWSはエンタープライズ顧客をマネージドで取るが、マネージドを使わない企業はOSS企業のエンタープライズライセンスを買う可能性の方が高い。

クラウド3社比較。

クラウドOSSマネージド戦略OSS貢献
AWS「OSS取りマネージドで」 — Elasticsearch、MongoDB API、Redis、PostgresOpenSearch・Valkey・Karpenter・Firecracker 主導。2020年以降積極的。
Google Cloud「OSSマネージド + 主要貢献者」 — BigQuery、Spanner、Anthos、KnativeTensorFlow・Kubernetes・gRPC・Istio・Go 主導。最も積極的。
Microsoft Azure「OSSマネージド + GitHub保有」 — Azure DB for PostgreSQL/MySQL、Azure Cache for RedisVSCode・TypeScript・.NET オープンソース化。GitHub 自体を運営。

GCPのOSS貢献が最も強いという評価が一般的で、AWSは2020年以降速く追いついている。「AWSがstrip-miningだけする」という単純な絵は2026年基準ではもはや正確ではない。

それでも残る真実。 マネージドサービス収益の大部分はクラウド3社が取る。OSSを作った企業は「Open Core」モデルで収益を作るが限界がある。その格差がBSLの波の根本動力である。

11章 · OSI定義の未来 — どう進化するか

OSI定義（OSD）は1998年に作られて以降ほぼ変わっていない。2026年現在、定義を変えるべきという圧力が複数の方向から来る。

圧力の方向1: source-availableの承認。 「BSL・FSLのようなライセンスも何らかの形でOSIが認めるべき」という圧力。理由は「現実（クラウドマネージドの脅威）に適応すべき」というもの。だがOSIは一貫して「オープンソースの定義は利用の自由を制限しないこと」と答える。

圧力の方向2: OSAID（Open Source AI Definition）。 2024年、OSIはAIモデル向けの「Open Source AI Definition」v1.0を発表した。コードだけでなく学習データ・重み・プロセスへの公開基準を定義する。MetaのLlamaは重みは公開するが学習データを公開しないためOSAIDに該当しない — Metaは「open weights」ではあるが「open source」ではないとOSIが明示した。

この判断は大きな論争を呼んだ。Metaは「事実上 open と見ても良い」という立場、OSIは「open source という言葉を軽く使うな」という立場。2026年現在OSAID v1.0は定着したが、「MetaのLlamaを何と呼ぶか」は依然不明瞭だ。

圧力の方向3: 非ソフトウェアへの拡張。 Creative Commons・Open Dataのような他領域との協力。OSIがソフトウェア外領域（データ、モデル、コンテンツ）へ影響力を広げている。

OSI自体の変化。 OSIは2023–2025年にリーダーシップとガバナンスが大きく変わった。Stefano Maffulliが事務局長に任命され、政策決定をより透明にするためのboard改編が行われた。資金源も多様化（GitHub・Bloomberg・Sloan Foundation等のスポンサー）。

OSI定義が壊れているという批判。 一部は「OSI定義がクラウド時代に合っていない」と見る。だがOSI定義が変われば定義が弱くなり、「オープンソース」という言葉自体が曖昧になる。だからOSIは定義を守る側を選び、新カテゴリ（例: OSAID for AI）を作って時代の変化に対応する。

2026年のバランス。 OSI定義はそのまま生き残った。BSL・SSPL・FSLはsource-availableカテゴリに居場所を持った。両陣営は並行宇宙のように共存する。新規OSSプロジェクトが始まる際「MIT/Apacheで行くか、BSL/FSLで行くか」を選ぶのが標準フローになった。

12章 · 韓国 / 日本企業のスタンス — カカオ、ネイバー、NTT、楽天

韓国・日本企業のBSLの波への反応は米国企業と異なる。

韓国: カカオのfork-friendlyポリシー。 カカオはOSS利用に対して「利用時にforkが可能なライセンスを優先」のポリシーを明示的に持っている。カカオエンタープライズ、カカオバンク、カカオペイは皆、新規インフラ選択の際「BSL/SSPLはなるべく避け、fork済みのOSIライセンス版があるならそちらを優先」というガイドラインがある。

実際、カカオはRedisライセンス変更後Valkeyへ素早くレビューを移し、2025年から一部サービスがValkeyへ移行した。OpenTofuはカカオクラウド内部インフラ自動化に使用され、ElasticsearchはOpenSearchと並行運用する。

韓国: ネイバーD2の均衡のとれたスタンス。 ネイバーはD2（開発者コミュニティブランド）を通じてOSS活動を行う。BSLライセンスへの立場は「長期的にはOSIライセンスを優先するが、短期的にはビジネスニーズに応じてBSLも利用可能」という実利的スタンスだ。

ネイバークラウドはElasticsearchマネージドとOpenSearchマネージドの両方を提供する。ユーザーに選ばせる形だ。Naver Pay・Naver Searchのような内部システムは、利用頻度が最も高いツールをライセンス影響と合わせて定期レビューする。

日本: NTTの保守的スタンス。 NTTグループ（NTT Communications、NTT Data等）はOSSライセンスに対して極めて保守的だ。BSL/SSPLをproductionに入れる前に法務レビューが長く入り、可能ならOSI承認またはcommercialライセンスを明示的に購入する。

NTT DataはHashiCorp買収後もTerraform Enterpriseを正規ライセンスで使い続ける。ElasticはElastic Cloudのenterprise contractで利用する。日本大企業の「法務リスク回避」文化がOSSライセンス選択に強い影響を与える。

日本: 楽天のマルチクラウドスタンス。 楽天は自社クラウド（楽天クラウド）とAWSを並行運用する。OSSライセンスに対しては比較的開かれたスタンス — OSIライセンスを優先するがBSLもビジネスニーズに応じて採用する。楽天モバイルはOpenStack・KubernetesのようなOSIライセンスインフラを深く利用する。

韓国・日本共通パターン。 (1) マネージドサービスへの好みが高い。ライセンス複雑性を企業が抱えるよりクラウド企業に任せる傾向。(2) 法務レビューサイクルが長いため、ライセンス変更への反応が米国より遅い。(3) フォーク済みのOSIライセンス版（OpenSearch・Valkey・OpenTofu）への信頼が急速に高まっている。

13章 · ライセンスが変わったOSSを使っているなら — 移行戦略

自社がElasticsearch・Terraform・Redis・MongoDBを使っており、ライセンス変更の影響が気になるなら、何をすべきか。4ステップフレームを提示する。

ステップ1: 影響評価。 以下の質問に答える。

  • 我々が利用しているバージョンはOSIライセンスか、source-availableか？（例: Elasticsearch 7.10 まではApache、7.11からはSSPL/ELv2）
  • 我々の利用形態はライセンス違反の可能性があるか？（例: 我々が作るSaaSの中に組み込んで売っているか？）
  • 我々はマネージドを使っているか、セルフホスティングか？（マネージドはライセンス負担をクラウドが背負う）

ステップ2: オプションの特定。 以下のオプションを比較する。

オプションコスト移行負荷長期リスク
維持 + commercial ライセンス購入ライセンス費用低いベンダーロックイン
フォーク済みOSSへ移行（OpenSearch・Valkey・OpenTofu）インフラ運用費用中フォークの活性度に依存
マネージドサービスへ転換（AWS・GCP・Azure）マネージド費用中クラウドロックイン
完全に別のOSSへ置き換え（例: Redis → KeyDB/DragonflyDB）移行高い新OSSの安定性

ステップ3: パイロット適用。 会社で最も影響の少ない環境（staging、非中核サービス）に代替を1–3ヶ月運用する。性能・運用性・チームの学習曲線を計測する。

ステップ4: 段階的ロールアウト。 パイロットで通った選択肢を、利用量の少ないサービスから移す。中核サービスは最後に移す。移行はデータ移行 + モニタリング + バックアップ検証の3段階で行う。

具体的な移行ケース。

  • Elasticsearch → OpenSearch. API互換性が90%以上ある。7.10以下ならほぼ無停止可能。8.xへ行くにはマイグレーションツール（OpenSearch Migration Assistant）を使う。
  • Terraform → OpenTofu. 1.6以下の .tf ファイルはほぼ互換。provider/module 互換性確認が必要。CI/CDでterraformバイナリをtofuに置き換える程度。
  • Redis → Valkey. v7.2.4まで100%互換。v8.0以降は新機能の利用有無で異なる。クライアントライブラリはほぼ全て互換。
  • Vault → OpenBao. データ移行ツール（Vault → OpenBao migrator）があるが安定性はOpenTofuほどではない。小さなsecretバックエンドから試す。
  • HashiCorp Vault Enterprise → 1Password Secrets Automation または AWS Secrets Manager. ライセンス + 運用負荷を一度に減らす方法。

うまく移行した企業事例。 GitLabはVaultからOpenBaoへ早期移行した大型ケースの一つ。1Passwordは最初からOpenBaoと正式パートナーシップを結び統合を強化した。AWS・Google・SnapはValkey発表から積極的に採用し、自社インフラを移した。

14章 · 自社がライセンスを変えなければならないなら — 意思決定ガイド

逆のシナリオ — 自社がOSSを作っており収益が停滞している場合。「ライセンスを変えるべきか」をどう判断するか。

最初に答える5つの質問。

  1. 我々の収益停滞の原因は本当にライセンスか？ AWSが本当に収益を奪っているのか、それともエンタープライズsalesインフラが弱いのか？マーケティングが弱いのか？収益停滞の本当の原因を診断しないと、ライセンス変更は効かない。

  2. フォークが起こる可能性は？ 我々のOSSの運用複雑度はどの程度か？Redis・Terraform程度なら容易にフォークされる。CockroachDB・MongoDB程度ならフォークが難しい。Kafka・Elasticsearchは中間。

  3. コミュニティの信頼喪失を吸収できるか？ 外部PRの急減可能性、GitHub star 増加の鈍化、「オープンソース企業」ブランドの弱化 — このコストを会社の収益増が相殺できるか？

  4. どのライセンスへ移るか？ BSL（4年後Apache）、SSPL（厳格）、FSL（2年後Apache）、Sustainable Use License（自由 + non-compete） — それぞれ異なるトレードオフ。

  5. 移行経路をどう提供するか？ 既存ユーザーが新ライセンスを拒否した場合どうするか？最後のOSS版をメンテナンスモードで残すか、完全に切るか？

意思決定マトリクス。

状況推奨ライセンス
小規模OSS、セルフホスティング利用が多くマネージドは少ないOSIライセンス維持（MIT/Apache/AGPL）
中規模OSS、クラウドマネージドが収益を脅かすAGPL または FSL を試す
大規模OSS、明確なクラウドプロバイダー脅威BSL（HashiCorpモデル）または SSPL（MongoDBモデル）
SaaS本業 + セルフホスティングも一部提供Sustainable Use License（n8nモデル）
AI / モデル領域OSAID準拠ライセンスまたは独自定義

コミュニケーションが重要。 ライセンス変更の成功/失敗は、変更そのものよりコミュニケーションで分かれる。ElasticのSSPL発表は唐突で、外部批判が大きかった。一方Redisは事前にコミュニティに影響可能性を知らせ、一部モジュールのライセンスを先に整理しておいた（完璧ではなかったがソフトだった）。

ライセンス変更の前に他のオプションも試せ。 (a) Open Coreモデルの強化（エンタープライズ機能をcommercialに分離）、(b) マネージドサービスの自社ローンチ（Elastic Cloud、MongoDB Atlas、Redis Cloud）、(c) クラウド企業とのパートナーシップ（Snowflake と dbt Labs の関係のような）、(d) コンソーシアム結成（CNCF・LF等）。ライセンス変更は最後の手段であるべきだ。

取り戻せる判断か。 Elasticは3年でAGPLへ戻った。Redisも2025年にAGPL追加オプションで部分復帰した。ライセンス変更は永続的ではないが、変更後に戻す過程の信頼喪失は永続的になりうる。

エピローグ — 2026年の結論、そして次の7年

2026年5月現在、「オープンソースとは何か」への答えは明確ではない。OSI定義は生きているが、一部の大型OSS企業はその定義の外にいる。AWS・Google・MSはOSSの最大の消費者であり、徐々に最大の貢献者にもなりつつある。韓国・日本企業はその間で実利的なバランスを取っている。

過去7年のBSLの波が示したことは3つ。

  1. ライセンスはビジネスモデルである。 技術的判断というよりビジネス判断だ。だから企業の収益構造が変わればライセンスも変わる（ElasticのAGPL復帰のように）。

  2. フォークは常に起こる。 運用複雑度が高過ぎないOSSは、ライセンスを変えればフォークされる。Linux Foundationがそのフォークのインキュベーターの役割を担い、クラウド企業が資金と人員を出す。

  3. コミュニティの信頼は再び買えない。 SSPL/BSLへ行って戻ってきた企業も、外部コントリビューターの信頼を100%取り戻すのは難しい。だからライセンスの判断は慎重でなければならない。

次の7年に起こること。 いくつかの推測。

  • AIモデルライセンスが主流の論点になる。 OSAID、Llama ライセンス、モデル重み公開 — 我々が「オープンソースモデル」と呼ぶ時、正確に何を言っているのかがより重要になる。
  • クラウド企業のOSS貢献がより大きくなる。 AWS・GCP・Azureが自社OSS（Karpenter・Knative・OpenTelemetry）にさらに投資することで、「OSS企業 vs クラウド」という単純な対立構造が弱くなる。
  • Source-available カテゴリが成熟する。 FSL・SULのようなライセンスが標準化し、新規OSS企業が最初からsource-availableで始める比率が増える。
  • OSI定義は生き残る。 だが新カテゴリ（OSAID、Open Data等）を作って進化する。

本記事が自社の次のライセンス判断（使う側であれ作る側であれ）に小さな助けとなることを願う。オープンソースの次の章は、依然として我々皆が書いている。

参考 / References

Discuss on Twitter • View on GitHub