オープンソースを取り巻く2026年の話題｜ライセンスと持続可能性

2026年、OSSライセンスはなぜ再び注目されているのか

オープンソースソフトウェア（OSS）は今やインフラの根幹ですが、2026年時点でそのライセンス体系は静かな転換期を迎えています。きっかけは数年前からの動きですが、現場への影響が本格化しているのはまさにこの時期です。

2023〜2024年にかけて、HashiCorpがTerraformをBusiness Source License（BSL）へ変更し、Redis Labsが一部コンポーネントをSSPL（Server Side Public License）に移行するなど、著名プロジェクトが相次いで「伝統的なOSSライセンス」から独自路線へ舵を切りました。これらの変更は、クラウドプロバイダーによる「コードの利用・改変は自由だが収益化はしない」という非対称な関係への対抗措置として語られることが多く、背景にある経済的な緊張感は現在も解消されていません。

2026年現在、こうした動きは一過性ではなく、OSSエコシステム全体の構造問題として認識されるようになっています。ライセンスの選択が「思想」だけでなく「持続可能なビジネスモデル」と表裏一体であることは、もはや避けて通れない現実です。

ライセンス変更の潮流：SSPL・BSL・Commons Clauseの実態

非伝統的ライセンスの代表格として、現場でよく参照されるのが以下の3つです。

SSPL（Server Side Public License）

MongoDBが起草し、Elastic・Redis（一部）が採用したSSPLは、ソフトウェアをサービスとして提供する場合にソースコード全体の公開を求めます。OSI（Open Source Initiative）はこれをオープンソースと認定していないため、「OSSに見えるが法的にはそうではない」という点で組織の調達ポリシーに影響を与えます。2026年時点でも、大手クラウドベンダーはSSPL採用プロジェクトのマネージドサービス提供を避けるか、フォーク版を独自に維持する方針を継続しています。

BSL（Business Source License）

HashiCorpが採用したBSLは、一定期間（通常4年）経過後にApache 2.0などの伝統的OSSライセンスへ自動転換する仕組みです。商用利用に制限がかかる期間中も、本番環境での非競合利用は許容される設計のため、SSPLよりも「グレーゾーンが広い」とも言われます。TerraformのフォークであるOpenTofuは、このBSL移行に反発したコミュニティが主導してCNCFの傘下に設立されたプロジェクトであり、2026年現在も活発に開発が続いています。

Commons Clause

既存のOSSライセンスにアドオンとして付加する形式で、ソフトウェアそのものを「販売」することを制限します。既存ライセンスと組み合わせるため解釈の揺れが生じやすく、法務担当者からは扱いの難しい選択肢として認識されています。

運用担当者として注意が必要なのは、これらのライセンスが「使用できない」を意味しないケースも多い点です。自社がサードパーティにソフトウェアをサービスとして提供していなければ、多くの制限は実質的に適用外です。一方で、SaaSや内部プラットフォームの提供形態によっては法的リスクが生じるため、導入前に法務・調達部門との確認ステップを組み込むことが2026年のベストプラクティスとなっています。

持続可能性の課題：誰がOSSを維持するのか

ライセンス変更の根底にあるのは、OSSの持続可能性という普遍的な問題です。広く使われながら少人数の無償貢献に依存しているプロジェクトは数多く存在し、2021年のLog4Shell脆弱性はその脆弱さを世界的に可視化するきっかけとなりました。

2026年時点で、この問題への対処として注目されている取り組みをいくつか挙げます。

• Sovereign Tech Fund（ドイツ政府出資）：重要なOSSインフラへの公的資金投入モデルとして先進的な事例とされ、他国の政策立案者からも参照されています。
• OpenSSF（Open Source Security Foundation）：Linux Foundation傘下で、依存関係のセキュリティ評価（Scorecard）や脆弱性対応基盤の整備を進めています。大企業の参加が増え、資金規模が拡大している点は2024年以降の大きな変化です。
• OSPO（Open Source Program Office）の普及：社内でOSS貢献・管理を組織的に行う部署を設ける動きが、中規模の企業にも広がっています。単なるコンプライアンス管理にとどまらず、戦略的貢献によって上流プロジェクトに影響力を持つことを目的とするケースが増えています。

一方で、個人メンテナーの疲弊・燃え尽き問題は依然として解決されていません。大企業が依存するコアライブラリを一人か二人のボランティアが維持しているという構造は、資金が入り始めた現在も多くのプロジェクトで変わっていません。現場で使用しているOSSの依存ツリーを把握し、重要なプロジェクトへの組織的な貢献（コードレビュー・バグ報告・スポンサーシップ）を検討することは、リスク管理の一環として意味を持つようになっています。

AI時代のOSSとライセンス：新たな論点

2026年の特徴的なトピックとして見逃せないのが、AIとOSSの交差点で生まれている新しいライセンス問題です。

大規模言語モデル（LLM）の学習データにOSSコードが含まれていることは広く知られており、「コードをオープンに公開することで、意図せず商業AIモデルの学習材料になる」という問題意識がコミュニティで高まっています。これに対し、一部のプロジェクトはAIによる学習利用を制限する条項を追加し始めており、OSIはこれを伝統的なOSDに照らして非OSSと分類しています。

また、AIが生成したコードをOSSプロジェクトにマージする際の著作権・ライセンス帰属の問題も未解決のままです。コントリビューターが生成AIを利用してパッチを書いた場合、そのコードの著作権は誰に帰属するか——各国の法整備はまだ追いついておらず、大規模プロジェクトのメンテナーはCLA（Contributor License Agreement）の更新や、生成AIコード受け入れポリシーの策定を迫られています。

「オープンモデル」という概念もこの文脈で注目されています。LLMの重みを公開するだけが「オープン」なのか、学習データ・コード・推論インフラすべての透明性が必要なのかという議論は、2024年にOSIが「Open Source AI Definition」の草案を公開したことで具体化し、2026年現在も改訂と議論が続いています。

運用担当者として今押さえておくべき実務的な視点

ライセンス・持続可能性の議論は抽象的に見えますが、インフラ・プラットフォーム運用の現場には具体的な影響が生じています。以下は、2026年現在の実務で意識しておくべきポイントです。

依存関係のライセンス監査を定期化する

SBOMScanやFOSSology、あるいはGitHub Dependency Reviewなどのツールを使い、プロダクションで使用しているパッケージのライセンスを定期的に棚卸しする体制を整えることが推奨されます。特に、以前はApache 2.0だったが静かにBSL/SSPLへ変更されたパッケージを見逃すケースがあるため、変更検知の自動化が有効です。

フォークプロジェクトの成熟度を評価する

ライセンス変更への反発から生まれたフォーク（OpenTofu、Valkey、ElasticSearchのOpenSearch等）は、2026年時点でそれぞれ異なる成熟度に達しています。コミュニティの活発さ・リリース頻度・スポンサー企業の構成を確認したうえで、移行コストと長期的なリスクを比較することが重要です。短期的なコスト節約のためだけにライセンス問題のあるパッケージを使い続けることは、後の調達・法務コストを増大させる可能性があります。

上流コントリビューションをリスク管理として捉える

重要な依存プロジェクトへの貢献は、エンジニアリングコストを伴いますが、プロジェクトの方向性に影響を持ち、メンテナーとの関係構築にもつながります。少なくとも、GitHubスポンサーや各種オープンソース財団へのスポンサーシップを組織的な予算として計上することは、リスク分散として現実的な選択肢です。

「オープンソース」という言葉の定義を組織内で揃える

SSPLやBSLがOSIのオープンソース定義を満たさないという事実は、調達ポリシーや社内ガイドラインが「OSS採用は自由」と定めている場合に問題になり得ます。法務・調達・エンジニアリングの三者が「オープンソース」をどう定義しているかを揃えておくことは、トラブルの芽を早期に摘む実務的な取り組みです。

OSSを取り巻く状況は、コードの自由という理念と、持続可能なエコシステムという現実の間で揺れ続けています。2026年はその揺れが制度・法・商慣習のレベルで具体的な形を取り始めた年として記録されるかもしれません。動向を追いながら、自組織のポジションを定期的に見直すことが、中長期的な安定運用につながります。