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

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

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

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の成果物に取り込めますが逆はできません。違反時の扱いも版で違い、GPL-2.0は違反した時点で権利が終了するのに対し、GPL-3.0には30日・60日の回復規定があります。2023年以降はTerraformやRedisのように、OSSだったプロダクトがOSI非承認のライセンスへ移る例が続いています。SPDX識別子とパッケージのメタデータで確認を自動化し、不明な項目や適用条件は原文を確認します。SPDX License List は3.29.0（2026-09-16リリース）が最新です。

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

著作権法63条の「利用の許諾」という法的な位置づけ

オープンソースは著作権の放棄ではありません。日本の著作権法は第10条第1項第9号で「プログラムの著作物」を著作物に挙げ、第63条第1項で「著作権者は、他人に対し、その著作物の利用を許諾することができる」と定めます。同条第2項は、許諾を得た者が「その許諾に係る利用方法及び条件の範囲内において」利用できるとしています。オープンソースライセンスはこの許諾に当たり、条件を外れた利用は許諾の範囲外です。

同じ第10条の第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.」著作権表示とライセンス本文を同梱すれば足りる、という意味です。無償で入手できることと、無条件で使えることは別物です。ソフトウェア自体の定義や採用可否はオープンソースソフトウェア（OSS）とは｜ライセンス種別と実装現場での採用判断・リスク管理で扱っています。

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

分類軸はコピーレフトの強度、すなわち派生物にも同じライセンスを課す範囲です。強いコピーレフト（GPL・AGPL）は一体の派生著作物に及びます。弱いコピーレフトでは、LGPLはライブラリ側、MPLは対象コードを含むファイルが中心となり、それぞれの条件を満たす限り、リンクした自社コードまでは及びません。寛容型（MIT・BSD・Apache-2.0）は自社コードの開示を求めません。この強度差が、自社プロダクトへ組み込めるかの判断軸になります。

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

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

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」を含みます。家庭用機器や住宅設備への組み込みで§6のInstallation Information提供条件に該当する場合は、署名等で利用者による改変版の導入・実行を妨げてはいけません。ただし、供給者を含め誰も改変版を導入できない場合には提供義務の例外があります。

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

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

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

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

2つ目の 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汚染」は法令用語ではなく、コピーレフトが自社コードへ伝播する現象の通称です。伝播は接触ではなく結合と配布で起き、社内利用にとどまる限り開示義務は生じません。別プロセス・別実行ファイルに分ければ常に安全かは、条文だけでは決まりません。どこまでを一体の著作物とみなすかは連携の密度に依存する解釈問題なので、分離したという一点で判断を打ち切らず法務確認を挟んでください。

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です。Grafana Labsのライセンスページによれば、同社は2021年4月20日に中核プロジェクトをApache-2.0からAGPLv3へ移すと発表し、対象はGrafana 8.0・Loki 2.3・Tempo 1.0以降です。プラグイン・エージェントと一部のライブラリはApache-2.0のまま残りました。改変するつもりのない利用者向けには、AGPL版と同じ機能を持つ無償のEnterpriseバイナリ（プロプライエタリライセンス）が用意されています。つまりGrafanaは商用利用でき、社内監視に未改変で使う限り §13 の義務は生じません。改変版をネットワーク越しに利用させる場合は、社内向けでも§13への対応が必要です。ソース提供義務を避けたい場合は、商用契約の適用範囲を確認します。Nextcloudも同じくAGPL-3.0です。

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

AGPLの開示を避けたい開発者向けに、権利者が商用ライセンスを別途販売する形態が定着しています。PyMuPDF はその代表で、2026年10月19日公開の2.0でもPyPIのLicense欄は「Dual Licensed – GNU AFFERO GPL 3.0 or Artifex Commercial License」です。オープンソース側の条件を満たせない案件では、Artifexから商用ライセンスを購入して §13 の適用外に置く選択になります。PDF処理の実装はPyMuPDF（fitz）とは｜インストールから使い方・ライセンスまで解説【2026年版】で扱っています。

同じ配布元でも、版によってライセンスが変わる点に注意が要ります。PyPIの記録では、レイアウト解析の pymupdf-layout は1.27.2（2026-03-10）と1.28.0（2026-06-29）が「Polyform Noncommercial or Artifex Commercial License」で、PolyForm側は非商用限定、商用利用にはArtifexの商用ライセンスを選ぶ形でした。1.28.2（2026-08-06）からAGPLとの選択制に変わり、2.0ではPyMuPDF本体に統合されています。依存を固定したまま版を上げると、ライセンスの性質ごと入れ替わることがあるわけです。依存を追加する時点だけでなく、版を上げる時点でもライセンスを確かめてください。

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

MITの条件は先述のとおり1つだけで、著作権表示とライセンス本文を同梱すれば要件を満たします。React・Vue・Express・jQuery はいずれもMITですが、これらを採用する場合も、推移的依存を含めてライセンスを確認し、MIT以外の条件が含まれていないか調べます。

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

MITとBSDは、上流のLICENSEファイル（著作権表示とライセンス本文）を成果物へそのまま同梱すれば足ります。バイナリだけを配る場合は、同じ内容をドキュメントか同梱資料に再掲します。表示義務だけで済む型の実例は、PostgreSQLのライセンスと価格：無償の範囲と実際に払う費用・5年総額での判断で確認できます。Apache-2.0だけは §4(d) によりNOTICEの引き継ぎが加わり、NOTICEの中身はプロジェクトごとに異なるため依存ごとの個別収集が必要です。

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-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など）を自社製品に組み込むなら、知財戦略と併せて確認すべき条項です。

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

§4 は再頒布時の条件を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」です。上流のNOTICEにある関連する帰属表示を、派生物のNOTICE、同梱文書、表示画面など§4(d)が認める場所のいずれにも残さなければ違反になります。NOTICEファイル自体の同梱だけが履行方法ではありません。

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 に当たりません。独自コードを閉じたまま、既存ファイルの改修だけを還元する運用が成立します。MPL-2.0は商用利用できますが、実行形式を配布する場合は、改変の有無にかかわらずMPL対象部分のソースを入手可能にし、その入手方法を受領者へ知らせる必要があります。LibreOfficeのほか、身近な例ではPythonの requests が依存する certifi（ルート証明書の束）がMPL-2.0です。HTTPクライアントを入れただけで依存ツリーに弱いコピーレフトが1つ入っている、ということになります。

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.」と定め、より大きな成果物を任意の条件で頒布することを認めます。加えて、Larger WorkがSecondary Licenseの適用作品との組み合わせであり、Covered Softwareが「not Incompatible With Secondary Licenses」である場合に限り、その部分を Secondary License の条件でも頒布できます。Exhibit B の非互換告知が付いたファイルは対象外です。Secondary License の範囲は §1.12 で、GPL 2.0以降・LGPL 2.1以降・AGPL 3.0以降に限られます。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.」と記しています。Apache-2.0のライブラリを GPL-2.0 only のプロジェクトへ取り込む構成は、この時点で破綻します。AGPLのライブラリを寛容型ライセンスで再配布しようとする構成も同様です。どちらも依存を追加した時点で判定できるので、CIのライセンススキャンで止めるのが確実です。

違反したときに失う権利：GPLの終了条項と係争中の訴訟

GPL-2.0 §4の自動終了とGPL-3.0 §8の30日・60日の回復規定

GPL-2.0 §4 は、ライセンスが認める以外の複製・改変・頒布の試みを無効とし、「will automatically terminate your rights under this License」と定めます。回復の規定はありません。ただし違反者からコピーを受け取った第三者は、自らが条件を守っている限りライセンスを失いません。

GPL-3.0 §8 も違反で権利が自動的に終了する点は同じですが、回復の道を2つ用意しています。違反をすべてやめた場合、その著作権者からのライセンスは暫定的に回復し、著作権者が停止から60日以内に合理的な方法で違反を通知しなければ恒久的に回復します。また、その著作権者からの通知が初めてで、受領から30日以内に違反を是正すれば、やはり恒久的に回復します。GPL-3.0の違反が見つかったら直ちに是正してください。通知後30日を経過する前の是正による恒久回復は、その著作権者からのGPL違反通知が初回である場合の規定で、すべての違反に共通する猶予期間ではありません。GPL-2.0の依存ではこの猶予が条文上ありません。

SFC対Vizio：購入者が第三者受益者としてソースを求める訴訟

違反の争われ方として注目されているのが、Software Freedom Conservancy（SFC）がテレビメーカーVizioを訴えた事件です。SFCの事件ページによれば、SFCは2021年10月にカリフォルニア州オレンジ郡上級裁判所へ提訴しました。著作権者としてではなく、GPLv2の第三者受益者（テレビの購入者）として完全な対応ソースの提供を求めている点が従来の訴訟と違います。同ページは2026年2月27日更新の時点で係属中、審理は2026年後半の予定と表示しています。同ページの記録では、2025年12月23日にVizioの2度目の略式裁定申立てを認める命令が出ていますが、訴訟全体の結論はまだ出ていません。組み込み機器メーカーにとっては「権利者が動かなくても購入者から請求され得るか」が争点になっていることは押さえておく価値があります。

ライセンス変更とOSI非承認ライセンス：BUSL・SSPL・FSLの見分け方

OSSとして採用したプロダクトが、後の版からOSI非承認のライセンスへ移る例が2021年以降続いています。以下は各社の公式発表で確認した主な変更です。

HashiCorpの発表は今後のリリースをMPL-2.0からBUSL-1.1へ移すもので、TerraformのLICENSEは Change Date を各版の公開から4年後、Change License をMPL-2.0と定めます。つまり公開から4年たった版はMPL-2.0になりますが、それまでは本文の利用制限に従います。Linux Foundationは2023年9月20日にOpenTofuの発足を発表しました。経緯と移行判断はHashiCorp（ハシコープ）とは？主要製品の違い・IBM買収後の変化・BSLライセンスを解説とOpenTofuとは？Terraformとのライセンス・機能差と移行判断を実装視点で解説にまとめています。

Redisは2024年3月20日にRSALv2とSSPLv1のデュアルライセンスへ移り、2025年5月1日にRedis 8からAGPLv3を選択肢に加えました。Elasticも2024年8月29日にAGPLv3の追加を発表しています。AGPLは追加された選択肢で、既存の許諾を一律に置き換えるものではありません。対象版をAGPLの条件で利用する場合に、改変とネットワーク利用について§13を確認します。分岐側の違いはValkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】とElasticsearchとOpenSearchの違い｜ライセンス・API互換・機能差から移行先を決めるで扱っています。

BUSL・FSLの「一定期間後にOSSへ変わる」仕組み

Sentryが策定したFunctional Source License（FSL）は、FSL-1.1-ALv2 と FSL-1.1-MIT の2種があり、公開から2年後にそれぞれApache-2.0またはMITへ変わります。それまでは「Competing Use」、すなわち同じ機能を競合製品・サービスとして商用提供する用途が除外されます。BUSL-1.1も同じ発想で、変わるまでの期間と変わった後のライセンスを製品ごとに書き込む形式です。

見分け方は機械的にできます。SPDX License List 3.29.0 の機械可読データを2026年10月20日に照合したところ、BUSL-1.1・SSPL-1.0・Elastic-2.0・FSL-1.1-ALv2・FSL-1.1-MIT・PolyForm-Noncommercial-1.0.0 はいずれも isOsiApproved が false でした。同日にGitHub APIのライセンス判定を引くと、redis/redis・elastic/elasticsearch・hashicorp/terraform・getsentry/sentry は「NOASSERTION」（単一のライセンスに判定できない）を返し、分岐側の valkey-io/valkey は BSD-3-Clause、opentofu/opentofu は MPL-2.0 と判定されました。リポジトリのライセンス表示が単一のOSI承認ライセンスにならない時点で、LICENSEを読む対象と判断してください。

オープンソースAIの定義とモデルのライセンス

AIモデルの「オープン」は、ソフトウェアとは別の基準で判定されます。OSIは2024年10月28日にOpen Source AI Definition 1.0を公開し、熟練者が実質的に同等のシステムを構築できるだけのデータ情報（Data Information）、学習と実行に使った完全なコード、重みなどのパラメータを、OSI承認の条件で提供することを求めました。重みをダウンロードできることだけでは要件を満たしません。

代表的な不一致がMetaのLlamaです。OSIは2025年2月18日、Llama 3.xのライセンスは利用者の差別や利用分野の制限があるためオープンソースではないとの見解を出しています。「オープンソースAI一覧」に載っているモデルでも、利用分野や利用者の制限があればOSD第5項・第6項の外なので、商用で組み込む前に配布元のライセンス本文を読んでください。

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

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

ライセンス本文を目視で読み比べる運用は規模に耐えません。SPDX License List は、ライセンスと例外に短縮識別子・正式名称・本文・恒久URLを割り当てた一覧で、3.29.0 が 2026-09-16 にリリースされています。2026年10月20日に機械可読データ（licenses.json）を集計すると識別子は740あり、OSI承認は非推奨の旧識別子を除いて141件でした。

ソースファイルの先頭に識別子を1行書けば、ツールが機械的に判定できます。# をコメント記号とする言語は1行目、C・C++などブロックコメントの言語はLinuxカーネルのユーザー空間APIヘッダの形が参考になります。

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

識別子の価値は表記ゆれを潰す点にあります。「GPLv3」「GNU GPL 3」という表記だけでは、後継版を選べるかが確定しません。権利者の告知に「or any later version」があるかを確認して GPL-3.0-only か GPL-3.0-or-later に当てはめれば、以後はツールが機械的に区別できます。複数のライセンスは AND（すべてに従う）と OR（どれかを選ぶ）で式にします。

Pythonの依存ライセンスをimportlib.metadataで一覧にする手順

Pythonでは、PEP 639 がCore Metadataを2.4へ上げ、SPDX式を入れる License-Expression 欄を設けました。ただし既存パッケージの移行は途中で、旧来の License 欄や分類子（Classifier）しか持たないものが残っています。そこで標準ライブラリの importlib.metadata で両方を読み、どちらから取った値かを並べます。このスクリプトは実行環境にインストールされた全配布物を列挙するため、対象プロジェクト専用の仮想環境で実行してください。

from importlib.metadata import distributions

for dist in sorted(distributions(), key=lambda d: d.metadata["Name"].lower()):
    meta = dist.metadata
    expr = meta.get("License-Expression")
    if expr:
        source = "expression"
    else:
        classifiers = [c.split(" :: ")[-1] for c in meta.get_all("Classifier") or []
                       if c.startswith("License ::")]
        expr = "; ".join(classifiers) or meta.get("License") or "(no license metadata)"
        source = "legacy"
    print(f'{meta["Name"]:<16} {meta["Metadata-Version"]:<4} {source:<10} {expr}')

2026年10月20日に python:3.13-slim（Python 3.13.16）のコンテナで requests・pymupdf・flask を入れて実行すると、依存を含む25パッケージが並び、License-Expression を持っていたのは11件でした。抜粋します。

certifi          2.4  legacy     Mozilla Public License 2.0 (MPL 2.0)
numpy            2.4  expression BSD-3-Clause AND 0BSD AND MIT AND Zlib AND CC0-1.0
packaging        2.4  expression Apache-2.0 OR BSD-2-Clause
pymupdf          2.1  legacy     Dual Licensed - GNU AFFERO GPL 3.0 or Artifex Commercial License
pymupdf4llm      2.1  legacy     (no license metadata)
pymupdf_layout   2.1  legacy     (no license metadata)
requests         2.4  legacy     Apache Software License

読み取れることは3つあります。numpy は同梱部品のライセンスを AND で連ねた式になっており、それぞれの条件を確認します。ただし、0BSDのように表示保持を条件としないライセンスもあるため、識別子の数が表示義務の数になるわけではありません。packaging は OR の選択制で、どちらか一方に従えば足ります。pymupdf4llm と pymupdf_layout はライセンス情報が空で、メタデータだけでは判定できません（pymupdf_layout 2.0 は、METADATA に本体へ統合された後の空パッケージだと書かれています）。空欄や「Dual Licensed」のような自由記述は、スクリプトで拾ったうえで人が配布元を確認する対象として扱ってください。なお同じ pip install pymupdf でも、Python 3.9 の環境では1.26.5が入りました。2.0は Python 3.11 以上を要求するためで、実行環境の版でもライセンスの確認対象は変わります。

この一覧をSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説で扱うSBOMに載せれば、ライセンスと脆弱性を同じ台帳で追えます。ツールの選定はSBOMツールの比較と選び方｜生成・管理・SCAのタイプ別に選定基準を解説、依存経由の侵害への備えはサプライチェーン攻撃とは？起点別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 では、バージョンを付けずにプラグインを適用し、ライブラリを依存に追加します。2026年10月20日時点のGoogle Mavenの最新は、プラグインが0.13.0、ライブラリが17.5.2です。

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

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

プラグインはビルド時に Maven POM の license 要素を走査し、ライセンス名とリンクをアプリのリソースへ埋め込みます。com.google.android.gms.oss.licenses.v2.OssLicensesMenuActivity を起動すると、組み込まれたライブラリの一覧から個別のライセンス本文まで辿れます。パッケージに v2 が入る点は、旧パッケージ名の記事を参照すると取り違えやすい箇所です。POM等から取得できる情報は自動収集できますが、メタデータの欠落、直接同梱したコード、個別の著作権表示やNOTICEは別途確認が必要です。生成画面だけで表示義務をすべて満たせるとは限りません。表示画面を含めたアプリの設計から依頼したい場合は、Androidアプリ開発の支援内容を参照してください。

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

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

公開する側に立つと判断軸は反転します。ライブラリやフレームワークの採用範囲を広げたい場合、本記事ではMITとApache-2.0を第一候補にします。分岐点は特許で、自社が特許を保有し利用者へ明示的に許諾したい、あるいは §3 の報復条項で保護を得たいならApache-2.0、特許を持たず条文の短さを優先するならMITを選びます。ドキュメントや画像を同じリポジトリで配る場合は、クリエイティブ・コモンズとは？CCライセンス6種類の違いと表示例を4.0の条文で解説で扱うCCライセンスを別に当てる方が条件が噛み合います。

アプリケーションの改変版をネットワーク提供する事業者にもソース提供を求めたいなら、AGPL-3.0が候補になります。ただし、競合による未改変版の再ホストや、条件を守った商用提供は禁止できません。競合による商用提供そのものを制限したいときに選ばれるのがBUSLやFSLですが、OSI非承認なので「オープンソース」とは名乗れず、先の表のように分岐を招いた例もあります。

GPL・LGPLで公開する前に確かめる2つの場面

第一に、社内の業務システムにGPL-3.0を付ける判断は急ぐ必要がありません。社外へ提供しない段階では、第三者への許諾条件を決める必要性は限定的です。ただし、自社が必要な権利をすべて持つコードなら、GPLで公開しても別条件で商用提供できます。第三者の寄与や依存を含む場合は、その権利関係を確認します。

第二に、SDKや組み込み向けライブラリをLGPLで出すなら、利用者の配布形態を先に確かめてください。静的リンクでも、§4(d)0)に従ってライブラリ側の対応ソースと再リンクに必要なアプリ側のオブジェクトコード等を提供すれば対応できます。ただ、利用者がアプリ側のオブジェクトコードを渡せない製品に組み込まれるSDKでは、この条件が採用の障害になるため寛容型を選ぶ方が適しています。確認対象はライブラリに限らず、Oracle JavaとOpenJDKのように同じ技術で提供条件が分かれる実行環境もあります（Java SEとは？JDK・JRE・JVMの違いとOracle Java/OpenJDKのライセンス【2026年10月】）。

よくある質問

オープンソースライセンスは商用利用できますか？

OSI承認ライセンスであれば、どれも商用利用できます。OSD第6項が利用分野の差別を禁じているためです。違いは義務の範囲で、MIT・BSDは表示だけ、Apache-2.0は表示とNOTICE、GPLは配布時のソース開示、AGPLは改変版をネットワーク提供したときのソース開示が加わります。BUSL・SSPL・FSL・PolyForm Noncommercial などOSI非承認のライセンスは、商用利用そのものが制限されることがあります。

OSSのライセンス費用はいくらですか？

主要OSSライセンスでは、許諾された権利の行使に追加の利用料は通常かかりません。ただし、OSSのコピーを有償で販売・配布することは認められており、入手費用まで必ず0円という意味ではありません。費用が発生するのは、AGPLなどの義務を避けるために商用ライセンスを買う場合（PyMuPDFのArtifex Commercial Licenseなど）、保守サポート契約を結ぶ場合、Grafana Enterpriseのような有償機能を使う場合です。価格は配布元ごとに個別見積もりのものが多く、公開価格がない製品もあります。

Grafanaは商用利用できますか？

できます。Grafana 8.0以降はAGPL-3.0で、未改変のまま社内監視や顧客向け監視に使う限り、ソース開示の義務は生じません。Grafanaのコードを改変してネットワーク越しに提供する場合は §13 により改変版のソース提供が必要になり、それを避けたいならGrafana Labsとの商用契約を検討します。改変する予定がなければ、同機能の無償のEnterpriseバイナリを使う選択肢もあります。

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

最も強いコピーレフトから見ます。AGPL、GPL、LGPL・MPL、寛容型の順に依存を分類し、AGPLかGPLがあれば、まず自社コードと一体の派生著作物を構成するかを確認します。独立したプログラムの単なる集積では、他の部分にまで同じライセンスが及ぶとは限りません。次に配布とネットワーク利用の形態を確認します。GPLは社内利用だけならソース提供義務は通常生じませんが、AGPLの改変版を社内ネットワークで利用させる場合も、§13の対象になり得ます。配布する場合だけ、寛容型の表示とApache-2.0のNOTICEを集約し、最後にリンク形態でLGPLの §4 要件を確認します。ライセンス情報が空欄の依存は、この順序に乗せる前に配布元で確認してください。

Androidのオープンソースライセンスとは何ですか？

Androidアプリの設定画面などに表示される、アプリが組み込んだライブラリの著作権表示とライセンス本文の一覧です。MIT・BSD・Apache-2.0はいずれも表示を条件としているため、バイナリだけを配るアプリでもこの一覧が必要になります。Googleの oss-licenses-plugin を使えば、ビルド時に依存から自動生成できます。

関連記事

• オープンソースソフトウェア（OSS）とは｜ライセンス種別と実装現場での採用判断・リスク管理
• SBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断を解説
• OpenTofuとは？Terraformとのライセンス・機能差と移行判断を実装視点で解説
• PyMuPDF（fitz）とは｜インストールから使い方・ライセンスまで解説【2026年版】
• SBOMツールの比較と選び方｜生成・管理・SCAのタイプ別に選定基準を解説