「自社の製品に、どんなOSSライセンスが入っているのか分からない」——配布前や取引先からの要求で、最初に必要になるのが依存ライブラリのライセンス一覧化です。多くは無料ツールで出せます。言語別に具体的な方法をまとめます。

なぜ確認が必要か

ソフトを配布（製品・パッケージ・受託納品・組込み機器）する瞬間に、含まれるOSSのライセンス義務（表示義務・ソース開示など）が発生します。取引先からのSBOM要求やEU CRA等の規制対応でも、まずこの一覧が出発点になります。

まず依存を「固定」する

正確なライセンス確認には、実際に使われているバージョンが要ります。package-lock.json・requirements.txt（バージョン固定）・go.sum・pom.xml などのロックファイルを用意しましょう。

言語別・ライセンス一覧の出し方（無料ツール例）

言語 / エコシステム代表的な無料ツール（例）
Node.js（npm）license-checker（npx license-checker --summary）
Python（pip）pip-licenses
Gogo-licenses（go-licenses report ./...）
Java（Maven）license-maven-plugin（third-party レポート）
Rust（Cargo）cargo-license / cargo-deny

いずれも「使っている依存の宣言ライセンスを一覧化」してくれます。まずはこれで全体像を掴みます。

一覧が出たら見るポイント

ライセンス名が並んだら、性質ごとに仕分けします。

  • コピーレフト（GPL / AGPL / LGPL）：配布や結合の形態によって、ソース開示などの義務が及ぶことがある（GPLとは / LGPLと動的リンク / AGPLとSaaS）。
  • 表示義務（MIT / BSD / Apache-2.0）：著作権表示やライセンス全文を製品に同梱する必要がある（ライセンス早見表 / ApacheのNOTICE）。
  • 不明・独自ライセンス：自動判定できないものは、個別に原文確認が必要。

ツールの「限界」を知っておく

無料ツールは便利ですが、次は拾えません。ここを過信すると事故になります。

  • 宣言ベースの限界：パッケージが宣言するライセンスと、内部に同梱された別ライセンスのコード（例外条項・デュアル）は別物。
  • 自社コードへの混入：コピペ／vendoring された断片は、依存一覧には出ません（ファイル単位のスキャンが必要）。
  • 義務の”判断”はしない：ツールは「ライセンス名」を出すだけ。「この配布形態でソース開示が要るか」「表示はどう書くか」という判断は人の仕事です。

詳しくは SBOMの先にある実務 / 取引先からSBOMを求められたら もご覧ください。

検出の「先」を、人が伴走します

ライセンスの検出はツールで出せます。難しいのはその先——義務の整理・配布可否の判断・取引先や規制への対応です。OSSClear は、どのツールの結果でも受け取り、大手SIerでのOSSコンプライアンス実務の知見をもとに「1枚のクリアランスレポート」に整理して、社内説明と顧問弁護士への相談にそのまま使える形でお渡しします。