オープンソースライセンスとは？主要9種の商用利用可否と義務を条項番号で解説

オープンソースライセンスは、著作権者がソフトウェアの利用・改変・再頒布を一定の条件付きで許諾する契約です。条件を満たさずに配布すれば許諾は失われ、著作権侵害として扱われます。判断を分けるのは「どのライセンスか」ではなく「どの条項に触れる使い方をしたか」です。ここでは主要9ライセンスの義務を条項番号まで降りて整理し、商用利用の可否とソース開示が発生する条件を判定できる形にします。

まとめ：義務の起点は配布、範囲を決めるのは各ライセンスの条項

結論から書きます。GPL系のソース開示義務は「配布（convey）」を伴って初めて発生し、社内サーバーで動かすだけなら生じません。例外はAGPL-3.0で、§13 がネットワーク越しの利用者への提供義務を課すため、SaaSでの改変利用が事実上の配布に相当します。寛容型（MIT・BSD・Apache-2.0）に自社コードの開示義務はなく、求められるのは表示です。ただしApache-2.0だけは改変ファイルへの変更明示とNOTICEの引き継ぎ（§4(b)・§4(d)）が加わります。

組み合わせの可否は一方向で、Apache-2.0のコードをGPL-3.0の成果物に取り込めますが逆はできません。確認は目視ではなくSPDX短縮識別子で機械的に回します。SPDX License List は 3.28.0（2026-02-20リリース）が最新です。以降、ライセンスごとの条項を順に見ていきます。

オープンソースライセンスの仕組みと、コピーレフト強度による3類型

著作権を留保したまま利用を許諾する契約という位置づけ

オープンソースは著作権の放棄ではありません。著作権者は権利を保持したまま、条件付きで利用を許諾します。MITライセンスの本文は「subject to the following conditions」と述べ、続けて条件を1つだけ挙げます。「The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.」著作権表示とライセンス本文を同梱すれば足りる、という意味です。無償で入手できることと、無条件で使えることは別物になります。

OSI（Open Source Initiative）が承認したライセンスは、SPDX License List 3.28.0 で isOsiApproved と記録されているものだけで149件あります。本記事はこのうち実務で遭遇頻度の高い9種に絞り、条項の読み方を扱います。ソフトウェア自体の定義や採用可否の判断はオープンソースソフトウェア（OSS）とは｜ライセンス種別と実装現場での採用判断・リスク管理が担当します。

寛容型・弱いコピーレフト・強いコピーレフトという3つの強度

分類軸はコピーレフトの強度、すなわち派生物にも同じライセンスを課す範囲です。強いコピーレフト（GPL・AGPL）は成果物全体に及び、弱いコピーレフト（LGPL・MPL）は改変部分やファイル単位に限定されてリンクした自社コードまでは及びません。寛容型（MIT・BSD・Apache-2.0）は自社コードの開示を求めません。この強度差が、そのまま自社プロダクトへの組み込み可否の判断軸になります。

主要ライセンス一覧・比較：SPDX識別子と商用利用・ソース開示義務の対応

商用利用の可否列がすべて「可」である点に注目してください。OSIのオープンソースの定義（OSD）第6項「No Discrimination Against Fields of Endeavor」が分野による差別を禁じているため、承認ライセンスは商用利用を制限できません。GPLも例外ではありません。問われるのは利用の可否ではなく、開示義務の範囲です。

商用利用の可否を分ける境界＝社内利用と配布

GPLで開示義務が起動するのは、バイナリまたはソースを第三者に渡したときです。自社サーバーでGPLのソフトウェアを動かし出力だけを顧客に提供する形態は配布に当たりませんが、受託開発の納品物にGPLのコードが結合していれば配布に当たり開示義務が発生します。判定に迷ったら「成果物が自社の管理下から出るか」を先に確認してください。AGPL-3.0だけはこの原則を意図的に崩しているため、後述の §13 を個別に見ます。

GPLとLGPL：コピーレフトが伝播する条件と「GPL汚染」の実態

ソース開示義務が発生する条件（GPL-3.0 §5・§6）

GPL-3.0（OSI承認 2007-09-05）は、改変したソース形態での頒布を §5「Conveying Modified Source Versions」、バイナリなど非ソース形態での頒布を §6「Conveying Non-Source Forms」で規定します。義務の起点はいずれも conveying、すなわち他者への引き渡しです。Linuxカーネルは GPL-2.0 only を採用し、加えて Linux-syscall-note というシステムコール例外を置いています。ユーザー空間APIヘッダには GPL-2.0 WITH Linux-syscall-note という表現が付され、この例外があるからこそGPL非互換のアプリケーションがカーネルヘッダを取り込めます。

GPL-2.0とGPL-3.0の実務上の差分（§6 Installation Information・§11 特許）

両者の差は2点に集約されます。1点目は §6 の Installation Information で、条文は「any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source」と定義してその提供を求めます。User Product は「(1) a “consumer product” … normally used for personal, family, or household purposes」に加え「(2) anything designed or sold for incorporation into a dwelling」を含みます。家庭用機器や住宅設備へGPL-3.0のソフトを組み込んで出荷する場合、署名鍵などで改変版を書き込めない設計は許されません。組み込み機器を作る側には、ここが最大の負担になります。

2点目は特許です。GPL-3.0 §11 は各コントリビューターが「a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims」を許諾すると定めます。GPL-2.0 にこの明文の許諾はありません。GPL-2.0 §7 は、特許侵害の判決や主張によってライセンス条件と矛盾する義務を課されても本ライセンスの条件を免れないと述べるにとどまり、特許権を積極的に与える構造ではありません。特許リスクを下げたい側は GPL-3.0 を、組み込み機器の設計自由度を優先する側は GPL-2.0 を選ぶ、という力学が働きます。

LGPL-3.0 §4が求める再リンク可能性の確保

LGPLは条項の読み違いによる事故が起きやすいライセンスです。§0 は、ライブラリのインターフェースを使うだけの自社コードを Application、それをライブラリと結合したものを Combined Work と定義します。§4 は Combined Work を自社の条件で頒布することを認めますが、(a) ライブラリ使用の明示、(b) GPL本文とLGPL本文の同梱、(c) 実行時の著作権表示への対応、(e) GPL §6 で要求される場合のInstallation Information提供に加え、核心は (d) です。

(d) は2つの選択肢を示します。d)0) は、改変ライブラリの Minimal Corresponding Source をLGPLの下で提供し、あわせて利用者が再結合できる形で Corresponding Application Code を渡す方法です。この Corresponding Application Code は §0 で「The object code and/or source code for the Application」と定義されており、自社アプリ側はオブジェクトコードで足ります。自社ソースの開示までは求められません。

d)1) は共有ライブラリ機構を使う方法ですが、条件が付きます。条文は「A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.」と定めます。利用者の環境に既にあるライブラリを実行時に使うことが前提のため、自社で共有ライブラリを同梱して動的リンクするだけでは (a) を満たすとは限りません。「動的リンクなら大丈夫」という通説は、この2条件を省いた要約です。静的リンクで固めて出荷する場合は d)0) の手当てが要ります。

なお「GPL汚染」は法令用語ではなく、コピーレフトが自社コードへ伝播する現象を指す通称です。伝播は接触ではなく結合と配布によって起きます。社内利用にとどまる限り、GPLのコードを使った事実だけで自社コードの開示義務は生じません。一方、プロセスを分けた別実行ファイルとして連携させる構成が常に安全かは、ライセンス条文だけでは決まりません。どこまでを一体の著作物とみなすかは連携の密度に依存する解釈問題で、条文に明示的な線引きがないため、分離したという一点で判断を打ち切らず法務確認を挟んでください。

AGPL-3.0 §13：SaaS提供が開示義務のトリガーになる仕組み

ネットワーク越しの利用者へのCorresponding Source提供義務

AGPL-3.0（OSI承認 2008-03-03）の §13「Remote Network Interaction; Use with the GNU General Public License」は、GPLとの決定的な差です。条文は「if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge」と定めます。

読み解くべき条件は2つです。改変していること、そしてネットワーク越しに利用者が触れていること。両方を満たすと、バイナリを一切配布していなくてもソース提供義務が発生します。GrafanaやNextcloudはAGPL-3.0を採用しており、これらを改変して自社SaaSに組み込む場合は §13 の射程に入ります。未改変のまま使う分にはこの義務は起動しません。

デュアルライセンスによる回避（PyMuPDF 1.28.0とArtifex）

AGPLの開示を避けたい商用開発者向けに、権利者が商用ライセンスを別途販売する形態が定着しています。PyMuPDF はその代表例で、PyPI のメタデータに「Dual Licensed – GNU AFFERO GPL 3.0 or Artifex Commercial License」と明記されています（1.28.0時点）。オープンソース側の条件を満たせない案件では、Artifexから商用ライセンスを購入して §13 の適用外に置く選択になります。

PythonライブラリをAGPLと知らずに本番投入し、後から法務で差し戻される事故はここで起きます。依存関係を追加する時点でライセンスを確認するほうが、後から差し替えるより安価です。

MITとBSD：表示義務だけで済む寛容型ライセンスの条件

MITの条件は先述のとおり1つだけで、著作権表示とライセンス本文を成果物に同梱すれば要件を満たします。React 19系、Vue、Express、jQuery はいずれもMITです。JavaScriptの依存ツリーはMITの比率が高く、多くの場合は表示の集約だけで処理できます。

LICENSE同梱とNOTICE引き継ぎという表示義務の具体形

表示義務の実装は難しくありません。MITとBSDは、上流のLICENSEファイル（著作権表示とライセンス本文）を成果物へそのまま同梱すれば足ります。ソースを配らずバイナリだけを配る場合は、同じ内容をドキュメントか同梱資料に再掲します。表示義務だけで済む型の実例は、PostgreSQL Licenseの条文と実際にかかる費用を解説した記事で確認できます。

Apache-2.0だけは後述の §4(d) によりNOTICEの引き継ぎが加わります。ライセンス本文が同一でもNOTICEの中身はプロジェクトごとに異なるため、依存ごとの個別収集が必要です。手作業では抜けるので、後述のSPDX識別子とビルド時の自動収集に寄せてください。

BSD 2条項と3条項の唯一の差＝非推奨条項

BSD-2-Clause と BSD-3-Clause は第1条・第2条が同一で、ソース形態・バイナリ形態それぞれでの著作権表示と免責条項の保持を求めます。差は第3条の有無だけです。BSD-3-Clause の第3条は「Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.」と定め、権利者名を推奨・宣伝に使うことを禁じます。

実務上の影響はマーケティング資材に出ます。BSD-3-Clause のライブラリを組み込んだ製品で、元プロジェクトの名前を「◯◯採用」と推薦的に打ち出すと第3条に抵触し得ます。技術文書での事実記載は別ですが、宣伝文脈では事前許諾を取ってください。

混同されがちな広告条項は、これとは別の条項です。旧BSD-4-Clause では第3条が広告条項（「All advertising materials mentioning features or use of this software must display the following acknowledgement」）、第4条が非推奨条項でした。1999年に広告条項が削除され、旧第4条が繰り上がって現在のBSD-3-Clause 第3条になっています。ソースにBSD-4-Clauseの表記が残っている古い依存を見つけたら、広告表示義務が付いてくる点に注意してください。

Apache-2.0：特許報復条項（§3）とNOTICEファイルの再配布義務（§4(d)）

特許訴訟を起こした時点で特許ライセンスが終了する条件

Apache License, Version 2.0（January 2004）は寛容型でありながら特許を明文で扱う点に特徴があります。§3 は特許許諾を与えたうえで、報復条項を置きました。「If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.」訴訟を提起した時点で、その成果物についての特許ライセンスが失われます。

括弧書きの「including a cross-claim or counterclaim in a lawsuit」が実務上効きます。自ら訴訟を起こした場合だけでなく、訴えられた側が反訴・交差請求として特許侵害を主張した場合も引き金になります。特許を保有する企業が自社製品にApache-2.0のコードを組み込む際は、知財戦略と併せて確認すべき条項です。KubernetesはApache-2.0を採用しています。

上流NOTICEを派生物へ引き継ぐ義務（§4(d)）

§4 は再頒布時の条件を (a)〜(d) の4つで定めます。(a) ライセンス本文の同梱、(b)「You must cause any modified files to carry prominent notices stating that You changed the files」＝改変ファイルへの変更明示、(c) ソース形態での著作権・特許・商標・帰属表示の保持、そして (d) が見落とされがちです。「If the Work includes a “NOTICE” text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file」。

LICENSEファイルを同梱しただけでは足りません。上流にNOTICEファイルがあるなら、その中の帰属表示を派生物にも読める形で引き継ぐ必要があります。LICENSEだけを同梱してNOTICEを落とす構成は、§4(d) の見落としとして起こります。

MPL-2.0：ファイル単位コピーレフトとSecondary Licensesとの併存

Modificationsの定義（§1.10）がファイル単位である意味

MPL-2.0の特徴は、コピーレフトの単位がファイルであることです。§1.10 は Modifications を、Covered Software の内容に対する追加・削除・変更から生じたソースコード形態のファイル、または Covered Software を含む新規のソースコードファイルと定義します。§3.1 は「All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License.」と定め、MPLの及ぶ範囲を Covered Software のファイルに限定します。

自社で新規に作成したファイルは、MPLのコードをそのファイルへコピーしない限り Modifications に当たりません。GPLが成果物全体に及ぶのと対照的で、独自コードを閉じたまま既存ファイルの改修だけ還元する運用が成立します。LibreOfficeがMPL-2.0で提供されています。

Larger Work（§3.3）とGPL系との併存条件

§3.3「Distribution of a Larger Work」は「You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software.」と定め、より大きな成果物を任意の条件で頒布することを認めます。加えて、対象のCovered Softwareが「not Incompatible With Secondary Licenses」である場合に限り、その部分をSecondary Licenseの条件でも頒布できます。逆に Exhibit B の非互換告知が付いたファイルは、この併存の対象外です。

Secondary License の範囲は §1.12 で限定されており、GPL 2.0以降・LGPL 2.1以降・AGPL 3.0以降を指します。GPL系一般ではありません。MPL 1.1 で問題となったGPLとの非互換は、2.0のこの設計で解消されました。

バイナリだけを配る場合も、§3.2(a) によりソース形態の入手方法を「at a charge no more than the cost of distribution to the recipient」＝頒布実費を超えない料金で、合理的な方法により速やかに知らせる必要があります。無償提供までは求められない点が、AGPL-3.0 §13 の「at no charge」との違いです。各ファイル冒頭には Exhibit A の告知（「This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0.」で始まる文）を置きます。

ライセンス互換性：Apache-2.0とGPLの一方向互換という制約

互換性は双方向ではありません。Apache Software Foundation 自身が「Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects.」と明言しています。取り込みの向きが逆になった時点で成立しません。

GPL-2.0との関係はさらに厳しく、ASFは「the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license.」と記しています。特許終了条項と補償条項がGPL-2.0にない制約とみなされるためです。Apache-2.0のライブラリを GPL-2.0 only のプロジェクトへ取り込む構成は、この時点で破綻します。逆にAGPLのライブラリを寛容型ライセンスで再配布しようとする構成も同様です。いずれも依存を追加した時点で判定できるため、CIでのライセンススキャンに組み込む価値があります。

SPDX識別子による確認と、Androidアプリでの表示義務の実装

SPDX License List 3.28.0の短縮識別子による機械判定

ライセンス本文を目視で読み比べる運用は規模に耐えません。SPDX License List は、よく使われるライセンスと例外に短縮識別子・正式名称・本文・恒久URLを割り当てた一覧で、3.28.0 が 2026-02-20 にリリースされています。ソースファイルの先頭に識別子を書けば、ツールが機械的に判定できます。

シェルスクリプトやPythonなど # をコメント記号とする言語では、次のように書きます。

# SPDX-License-Identifier: Apache-2.0

CやC++などブロックコメントを使う言語では、Linuxカーネルのユーザー空間APIヘッダが実際に採用している形が参考になります。

/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */

識別子の価値は表記ゆれを潰す点にあります。「GPLv3」「GNU GPL 3」といった揺れは GPL-3.0-only に一意化されます。-only と -or-later の使い分けにより、後継バージョンを選べるかどうかまで機械的に区別できる設計です。依存関係の棚卸しでは、SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で扱うSBOMと組み合わせ、ライセンスと脆弱性を同じ台帳に載せてください。この台帳はサプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位を解説が扱う依存経由の侵害を追う場面でもそのまま流用できます。

oss-licenses-pluginで生成するライセンス表示画面

スマートフォンアプリの設定画面に並ぶ「オープンソースライセンス」は、寛容型ライセンスの表示義務を満たすための実装です。Androidでは Google が Gradle プラグインを提供しています。プラグイン本体は Gradle Plugin Portal ではなく Google Maven にあるため、まず settings.gradle.kts で解決先を指定します。

pluginManagement {
  repositories {
    google()
  }
  resolutionStrategy {
    eachPlugin {
      if (requested.id.id == "com.google.android.gms.oss-licenses-plugin") {
        useModule("com.google.android.gms:oss-licenses-plugin:0.13.0")
      }
    }
  }
}

アプリモジュール側の build.gradle.kts では、バージョンを付けずにプラグインを適用し、ライブラリを依存に追加します。

plugins {
  id("com.google.android.gms.oss-licenses-plugin")
}

dependencies {
  implementation("com.google.android.gms:play-services-oss-licenses:17.5.1")
}

プラグインはビルド時に Maven POM の license 要素を走査し、ライセンス名とリンクをアプリのリソースへ埋め込みます。com.google.android.gms.oss.licenses.v2.OssLicensesMenuActivity を起動すると、組み込まれたライブラリの一覧が表示され、個別のライセンス本文まで辿れます。パッケージに v2 が入る点は、旧パッケージ名の記事を参照すると取り違えやすい箇所です。収集対象は推移的依存を含むため、Google Play services が内部で使うライブラリの表示まで自動で回収されます。手作業でライセンス一覧を維持する運用は、依存が増えた時点で破綻します。

自社ソフトウェアに付けるライセンスの選定基準

採用を広げたいライブラリで寛容型を選ぶ条件

公開側に立つと判断軸は反転します。ライブラリやフレームワークを広く使ってほしいなら、MITかApache-2.0の二択になります。分岐点は特許です。自社が特許を保有し、利用者へ明示的に許諾したい、あるいは §3 の報復条項で保護を得たいならApache-2.0を選びます。特許を持たず、条文の短さと採用障壁の低さを優先するならMITです。ソフトウェア以外の成果物、たとえばドキュメントや画像を同じリポジトリで配る場合は、6種類のクリエイティブ・コモンズ・ライセンスを詳しく紹介で扱うCCライセンスを別途当てる方が条件が噛み合います。

アプリケーションやサービス本体を公開する場合、競合にそのまま再ホストされたくないならAGPL-3.0が機能します。GrafanaとNextcloudの選択がこの型です。

GPL・LGPLを選んで採用を落とす2つの場面

採用すべきでない場面をはっきり書きます。第一に、社内の業務システムをGPL-3.0で公開する判断は不要です。配布しないソフトウェアにコピーレフトを付けても、伝播させる相手が存在せず、将来の商用提供の選択肢だけを狭めます。ライセンス表記を付けるにしても、社内配布の範囲を明記した独自条件で足ります。

第二に、SDKや組み込み向けライブラリをLGPLで出す判断は勧めません。§4(d) の再リンク可能性を利用者側が満たせるかは、利用者の配布形態に依存します。静的リンクが前提の環境では利用者が要件を満たせず、結果として採用を落とします。SDKは寛容型が正解です。なお確認対象はライブラリだけではありません。Oracle JavaとOpenJDKのように同一技術で提供条件が分岐する例もあり、実行環境まで含めた点検が要ります（Java SEとは？JDK・JRE・JVMの違いとOracle Java/OpenJDKのライセンスを最新版で解説）。

よくある質問

依存ライブラリのライセンスは、どこを見れば確認できますか？

優先順位は3段階です。第一に、パッケージのメタデータを見ます。npmなら package.json の license、Pythonなら PyPI のメタデータ、JavaなどのMavenならPOMの license 要素にSPDX識別子または名称が入ります。第二に、リポジトリ直下の LICENSE・COPYING ファイルを確認します。第三に、ソースファイル冒頭の SPDX-License-Identifier 行を見ます。3つが食い違う場合はファイル冒頭の記載が個別ファイルの条件として優先されます。デュアルライセンスの製品ではメタデータに両方が併記されるため、片方だけを読んで判断しないでください。

複数のライセンスが混在する依存ツリーは、どの順で判定すればよいですか？

最も強いコピーレフトから見ます。AGPL、GPL、LGPL・MPL、寛容型の順に依存を分類し、AGPLとGPLが1つでもあれば、そこから成果物全体の条件が決まります。次に配布形態を確認します。社内利用のみなら開示義務は起動せず、判定はほぼ終わります。配布する場合のみ、寛容型の表示義務とApache-2.0のNOTICE引き継ぎを集約し、最後にリンク形態（静的か動的か）でLGPLの §4 要件を確認します。この順序なら、寛容型を先に全部読む無駄が省けます。

GPL-2.0とGPL-3.0の違いは、実務上どこに出ますか？

組み込み機器と特許の2点です。GPL-3.0 §6 は User Product に改変版を書き込むための Installation Information の提供を求めるため、署名鍵で書き換えを封じたハードウェアで出荷する構成が取れません。もう1点は特許で、GPL-3.0 §11 はコントリビューターによる無償の特許許諾を明文化していますが、GPL-2.0にその規定はありません。

AGPLのライブラリをWebサービスで使うと何が起きますか？

そのライブラリを改変していれば、サービス利用者に対し改変版の Corresponding Source を無償で入手できる手段を目立つ形で提示する義務が生じます（§13）。未改変のまま使う場合、この義務は起動しません。改変が避けられず開示もできない案件では、PyMuPDFのようにデュアル提供されるライブラリの商用ライセンスを購入し、§13 の適用を外すのが現実的な解です。

Androidアプリでオープンソースライセンスの表示は必須ですか？

使用しているライブラリのライセンスが表示を求めているなら必須です。MIT・BSD・Apache-2.0はいずれも著作権表示とライセンス本文の同梱を条件とし、Apache-2.0は上流にNOTICEがあれば帰属表示の引き継ぎも要求します。バイナリだけを配ってこれらを省けば条件違反です。実装は oss-licenses-plugin と play-services-oss-licenses を導入し、com.google.android.gms.oss.licenses.v2.OssLicensesMenuActivity を設定画面から起動する形が定番になっています。

関連記事

• オープンソースソフトウェア（OSS）とは｜ライセンス種別と実装現場での採用判断・リスク管理
• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説
• Java SEとは？JDK・JRE・JVMの違いとOracle Java/OpenJDKのライセンスを最新版で解説
• サプライチェーン攻撃とは？起点別3類型と最新事例・対策の優先順位を解説
• 6種類のクリエイティブ・コモンズ・ライセンスを詳しく紹介