OSSライセンス早見表 — 商用利用前に知っておくべき「アカン」理由
社内システムやプロダクトにOSSを組み込む前に、ライセンスの「罠」を把握しておかないと法務案件に発展することがある。
本記事では主要ライセンスごとに、企業・商用利用目線での「アカン」ポイントを整理する。
ライセンス一覧
| ライセンス | 種別 | コピーレフト | 商用利用 | 感染リスク |
|---|---|---|---|---|
| GPL v2 / v3 | 強コピーレフト | 強 | △ | 最高 |
| AGPL v3 | 強コピーレフト（SaaS封鎖） | 強 | △ | 最高 |
| LGPL v2.1 / v3 | 弱コピーレフト | 弱 | △ | 中 |
| MPL 2.0 | 弱コピーレフト | ファイル単位 | ○ | 低〜中 |
| Apache 2.0 | 許容的 | なし | ○ | 低 |
| MIT / BSD | 許容的 | なし | ○ | 低 |
| BUSL 1.1 | 非OSI認定 | なし | △ | 競合禁止 |
| EUPL 1.2 | 弱コピーレフト | 弱 | △ | 中 |
各ライセンスの詳細
GPL v2 / v3（GNU General Public License）
代表的なOSS： Linux kernel、GCC、MySQL（dual）、WordPress
アカン理由
- GPLコードを 1行でも組み込んだら、製品全体のソースを同じGPLで公開する義務が生じる
- バイナリ配布時もソース提供が必要
- v3はさらに特許条項・TiVo条項が付加されており、ハードウェアへの組み込みにも制約がある
- GPLv2とApache 2.0はライセンス非互換（GPLv3はApache 2.0と互換）
プロプライエタリ製品やクローズドなソースコードベースへの組み込みは事実上不可。
AGPL v3（Affero GPL）
代表的なOSS： MongoDB、Grafana OSS、Nextcloud、Mastodon
アカン理由
- GPLの「配布」問題を SaaSに拡張 したライセンス
- ネットワーク越しにユーザーへサービスを提供するだけでもソース開示義務が発生
- クラウドサービスに組み込むとサービス全体のソースを公開しなければならない
- AGPLのGrafanaをSaaSダッシュボードとして提供する場合も対象
「配布しないからOK」が通用しない。SaaS提供するなら商用ライセンスか代替製品の選択が必要。
これはDatadogのようなSaaS型監視ツールを採用する根拠の一つにもなりうる。
LGPL v2.1 / v3（Lesser GPL）
代表的なOSS： GNU libc、Qt（LGPLオプション）、FFmpeg（一部）
アカン理由
- 動的リンクはOKだが、静的リンクや改変したコードは感染対象
- 組み込み機器など「ユーザーが自分で再リンクできない」環境では LGPL v3が使えない
- GPLと混在させると上位のGPL準拠が必要になる
動的リンク（.so / .dll）→ OK（著作権表示のみ）
静的リンク / 改変 → ソース公開義務
MPL 2.0（Mozilla Public License）
代表的なOSS： Firefox、Terraform（旧バージョン）、LibreOffice
アカン理由
- ファイル単位のコピーレフト：MPLファイルを変更したら同ライセンスで公開が必要
- 他ファイルへの感染はないが、変更ファイルの追跡・管理が複雑になる
- GPL/LGPLとは「互換あり」「互換なし」が混在するため、組み合わせ時は要確認
HashiCorpがTerraformをMPL 2.0 → BUSL 1.1に変更したことで、OpenTofuへのフォークが発生した。
Apache 2.0
代表的なOSS： Kubernetes、Apache Spark、Kafka、Hadoop
アカン理由
- 商用利用・改変はほぼ自由だが、特許条項が付いている
- 貢献者の特許ライセンスが自動的に付与される
- 逆に、訴訟を起こすと付与された特許ライセンスが自動失効する
- GPLv2との組み合わせは非互換（GPLv3はOK）
Apache 2.0 + GPLv2 → 非互換（配布不可）
Apache 2.0 + GPLv3 → 互換（配布可）
MIT / BSD
代表的なOSS： React（MIT）、Node.js（MIT）、Ruby（BSD系）、Rails（MIT）
アカン理由
- ほぼ何でも許可されているが、著作権表示の義務がある
- 特許権は付与されないため、特許トロール対策にならない
- BSD-4-Clause（旧BSD）には広告条項があり実質的に問題になるケースもある（現在は多くがBSD-2/3に移行済み）
MIT/BSDが最も制約が少ないが、著作権表示の漏れに注意。社内のLICENSEファイル管理は必須。
BUSL 1.1（Business Source License）
代表的なOSS（？）： Terraform（1.6以降）、Vault、Consul（いずれもHashiCorp製品の現行バージョン）
アカン理由
- 一定期間（通常4年）は競合製品への利用禁止という制限がある
- OSIのOSD（Open Source Definition）に非準拠のため、厳密にはOSSとは言えない
- HashiCorpがTerraformをMPL 2.0 → BUSL 1.1に変更したことで大騒動になり、OpenTofuのフォークが生まれた
Terraform <= 1.5.x → MPL 2.0（OSSライセンス）
Terraform >= 1.6.0 → BUSL 1.1（非OSI認定）
OpenTofu → MPL 2.0（フォーク・継続開発中）
BUSLの「競合製品への利用禁止」は、Managed Terraformサービス（Spacelift、Scalr等）が主ターゲット。
ただし「競合」の定義が曖昧なため、社内でコンサルティングやサービス提供している場合は法務確認が必要。
EUPL 1.2（EU Public Licence）
代表的なOSS： EU委員会が公開するソフトウェア群
アカン理由
- コピーレフト付きライセンスだが、EU法に準拠した22言語で法的効力を持つ特殊な構造
- 国内法との解釈差異が生じやすく、グローバルな製品開発では法務コストが増大する
- 日本国内での利用実績・判例が少なく、法的リスクの評価が難しい
企業目線のリスクサマリー
| ライセンス | 主なリスク | 対処方針 |
|---|---|---|
| GPL / AGPL | ソースコード公開義務・SaaS感染 | 組み込み禁止 or 商用ライセンス購入 |
| BUSL 1.1 | 競合用途禁止・非OSI認定 | 用途確認・OpenTofuへの移行検討 |
| LGPL v3 | 静的リンク・組み込み機器での制約 | 動的リンクの徹底・v2.1への固定 |
| MPL 2.0 | 変更ファイルの公開管理 | 変更箇所の追跡・公開フローの整備 |
| Apache 2.0 | GPLv2非互換・特許条項 | GPLv2との混在を避ける |
| MIT / BSD | 著作権表示漏れ・特許権なし | LICENSEファイル管理の自動化 |
よくある実務トラブルパターン
パターン1：Dockerfileでの意図しないGPL感染
FROM ubuntu:22.04
RUN apt-get install -y some-gpl-package
GPLパッケージを含むコンテナイメージをクライアントに配布した場合、GPL感染の可能性がある。
社内利用のみであればリスクは低いが、イメージを外部提供する際は構成管理が必要。
パターン2：LGPLライブラリの静的バンドル
MavenやWebpackでLGPLライブラリを静的バンドル（fat jar、webpack bundle等）すると、動的リンク扱いにならずLGPLの義務が生じる可能性がある。
パターン3：AGPLソフトをSaaSに組み込む
GrafanaのOSS版（AGPL）をSaaSダッシュボードとして顧客提供すると、サービス全体のソース公開義務が発生しうる。
この問題を避けるために、商用版Grafana EnterpriseやDatadogのようなSaaS型代替品が選ばれるケースがある。
パターン4：TerraformのBUSL移行への対応
# 現状確認
terraform version # 1.6以降はBUSL
# 対応選択肢
1. HashiCorp商用ライセンス（HCP Terraform）を契約
2. OpenTofuへ移行（MPL 2.0・OSI認定）
3. Terraform 1.5系にバージョンを固定（MPL 2.0のまま維持）
まとめ
- MIT / Apache 2.0：商用利用に最も適している。著作権表示とGPLv2との混在に注意
- GPL / AGPL：OSS製品には最適だが、プロプライエタリ製品やSaaSへの組み込みは基本NG
- LGPL / MPL：使えるが条件あり。静的リンクと変更管理に気をつける
- BUSL：OSSではないと理解した上で用途を確認する
社内でOSSを採用する際は、SBOM（Software Bill of Materials）を整備してライセンス管理を自動化することが現実的な対策となる。