license-analysis

ライセンス分析

プロジェクトの依存関係ツリー全体にわたって、オープンソースライセンスの互換性と義務を分析します。このスキルでは、使用中のすべてのライセンスを特定し、互換性の衝突を確認し、コピーレフト感染のリスクを警告するとともに、実行可能な推奨事項を含むコンプライアンスレポートを作成します。許容的ライセンス（MIT、BSD、Apache-2.0）、弱いコピーレフト（LGPL、MPL）、強いコピーレフト（GPL、AGPL）、およびプロプライエタリライセンスや混在ライセンスのシナリオを扱います。

ワークフロー

1. 依存関係をスキャンする — プロジェクトの依存関係マニフェスト（package.json、requirements.txt、go.mod、Cargo.toml、pom.xml など）を解析し、推移的な依存関係ツリー全体を解決します。オプション依存関係、開発依存関係、ピア依存関係も含め、直接依存関係と間接依存関係をすべて特定します。ライセンスが宣言されていない依存関係や、デュアルライセンスを示す SPDX 式が指定された依存関係を記録します。

2. ライセンスを特定する — 各依存関係について、パッケージメタデータの SPDX 識別子、パッケージ内の LICENSE ファイル、またはマニフェストのライセンスフィールドからライセンスを抽出します。ライセンス名を SPDX 識別子に正規化します。ライセンスのないパッケージ（デフォルトでは全著作権留保）、カスタムライセンスやプロプライエタリライセンス、および選択が必要な曖昧な複数ライセンスの宣言にフラグを付けます。

3. 互換性マトリックスを確認する — プロジェクトの想定される配布形態（SaaS、配布バイナリ、オープンソースライブラリ、社内ツール）に基づいて、ライセンスのペアごとの互換性を評価します。許容的ライセンス（MIT、BSD、ISC）は幅広く互換性があります。Apache-2.0 には特許許諾があり、GPLv2 とは競合しますが、GPLv3 とは競合しません。コピーレフトライセンス（GPL、AGPL）は配布義務を課すため、結合した著作物をプロプライエタリライセンスで提供することと競合する場合があります。AGPL では、ネットワーク経由での使用であっても義務が生じます。

4. コピーレフトのリスクにフラグを付ける — GPL、AGPL、LGPL、MPL のいずれかでライセンスされた依存関係を特定し、使用形態（静的リンク、動的リンク、別プロセス、ネットワーク通信）によってコピーレフト義務が発生するかどうかを評価します。プロプライエタリアプリケーションに GPL ライブラリを静的リンクすると、アプリケーション全体を GPL ライセンスにする必要があります。LGPL では、動的リンクであればコピーレフトの感染を回避できます。AGPL はネットワーク通信にもコピーレフトを適用します。

5. コンプライアンスレポートを作成する — ライセンスの一覧表、互換性分析、重大度別のリスクフラグ、必要な帰属表示と通知、および競合を解決するための具体的な推奨事項を含む、構造化されたレポートを作成します。プロジェクトのドキュメントや法務レビューに使用できる部品表も含めます。

使用方法

プロジェクトのライセンスと配布形態を添えて、依存関係マニフェストまたは依存関係の一覧を提示してください。プロジェクトをソース、バイナリ、SaaS、社内限定のどの形態で配布するかを指定してください。

プロンプトの例：

Analyze the licenses in my Node.js project. Here's my package.json dependencies. The project is MIT-licensed and distributed as an npm package. Flag any compatibility issues.

例

例1：Node.js 依存関係ツリーの分析

入力： オープンソースの MIT ライセンスで配布されている Node.js REST API。package.json に記載されている主な依存関係：

{
  "dependencies": {
    "express": "^4.18.2",
    "lodash": "^4.17.21",
    "pg": "^8.11.3",
    "sharp": "^0.33.2",
    "leaflet": "^1.9.4",
    "jsdom": "^24.0.0"
  }
}

出力：

ライセンス一覧

パッケージ	バージョン	ライセンス	カテゴリ	リスク
express	4.18.2	MIT	寛容型	なし
lodash	4.17.21	MIT	寛容型	なし
pg	8.11.3	MIT	寛容型	なし
sharp	0.33.2	Apache-2.0	寛容型	なし
leaflet	1.9.4	BSD-2-Clause	寛容型	なし
jsdom	24.0.0	MIT	寛容型	なし
libvips (sharp ネイティブ)	8.15.1	LGPL-2.1	弱いコピーレフト	中
canvas (jsdom オプション)	2.11.2	MIT	寛容型	なし

推移的依存関係の概要： 合計347パッケージをスキャンしました。MIT が331、Apache-2.0 が8、BSD-2-Clause が4、ISC が2、LGPL-2.1 が1、ライセンスなしが1です。

リスクフラグ：

• LGPL-2.1 — libvips（sharp 経由）、重大度：中 — libvips はネイティブバインディングを介して sharp パッケージに動的リンクされています。LGPL-2.1 では、コピーレフトの波及なしに動的リンクが認められていますが、次の対応が必要です：（1）LGPL-2.1 のライセンス本文を配布物に含める、（2）著作者を明記する、（3）ユーザーが LGPL コンポーネントを改変版に置き換えられるようにする。sharp はビルド済みバイナリを使用するため、この点を NOTICES ファイルに記載してください。

• ライセンスのないパッケージ：[email protected]（debug 経由の推移的依存関係）、重大度：高 — ライセンスファイルも SPDX 識別子も見つかりませんでした。ライセンスがない場合、使用許可は認められません。対応：古いバージョンかどうか確認し（[email protected] は MIT ライセンス）、ライセンスのあるバージョンを固定するか、代替品を探してください。

必要な帰属表示： 347パッケージすべての LICENSE ファイルまたは通知を含めてください。license-checker または legally npm パッケージを使用して、THIRD-PARTY-NOTICES ファイルを自動生成できます。

例2：複数ライセンスの互換性分析

入力： 3つのライブラリ（MIT ライセンスのユーティリティライブラリ、Apache-2.0 のデータパーサー、GPL-3.0 のチャートライブラリ）を組み込みたい、独自の商用デスクトップアプリケーション（ソース非公開）。

出力：

互換性マトリックス

	MIT	Apache-2.0	GPL-3.0	独自（プロジェクト）
MIT	互換性あり	互換性あり	互換性あり（片方向）	互換性あり
Apache-2.0	互換性あり	互換性あり	GPL-3.0 とのみ互換性あり	互換性あり
GPL-3.0	MIT コードを GPL で使用可能	Apache を GPL-3.0 で使用可能	互換性あり	互換性なし
独自	MIT を使用可能	Apache-2.0 を使用可能	互換性なし	—

分析：

• MIT ユーティリティライブラリ → 独自プロジェクト：互換性あり。 MIT は独自ソフトウェアでの使用を認めています。義務：MIT ライセンス本文と著作権表示を配布物に含めてください。

• Apache-2.0 データパーサー → 独自プロジェクト：互換性あり。 Apache-2.0 は独自ソフトウェアでの使用を認めています。義務：Apache-2.0 ライセンスと、存在する場合は NOTICE ファイルを含め、Apache ライセンス対象ファイルに加えた変更を明示してください。特許許諾により、Apache-2.0 の貢献者による特許請求から保護されます。

• GPL-3.0 チャートライブラリ → 独自プロジェクト：互換性なし。 GPL-3.0 では、結合作品を完全なソースコードとともに GPL-3.0 で配布することが求められます。これは独自／ソース非公開での配布と直接矛盾します。このライブラリを含めると、アプリケーション全体が GPL-3.0 の対象になります。

推奨事項：

1. GPL-3.0 のチャートライブラリを置き換える — MIT または Apache-2.0 の代替品を使用してください。選択肢：Chart.js（MIT）、Apache ECharts（Apache-2.0）、Plotly.js（MIT）。
2. GPL ライブラリが不可欠な場合、IPC またはネットワーク API を介して通信する別プロセスに分離できるか検討してください。FSF の見解では、コンポーネントが実質的に別々のプログラムであれば、これによってコピーレフトの波及を避けられる可能性があります。ただし、この解釈には議論があり、法的に検証されていません。
3. 商用ライセンスの購入を検討する — GPL プロジェクトの中には、有償で独自ライセンスを提供するデュアルライセンス方式を採用しているものがあります。

ベストプラクティス

• 直接依存関係だけでなく、推移的な依存関係ツリー全体をスキャンしてください。コピーレフトのリスクは、依存関係グラフの数階層下に隠れていることがよくあります。
• 「ライセンスなし」は「すべての権利を留保」として扱ってください。ライセンスがないからといって許諾が寛容であることを意味するわけではありません。使用、複製、配布に関する法的な許可がないことを意味します。
• 配布モデルを区別してください。SaaS では AGPL が発動しますが、通常 GPL は発動しません。npm パッケージでは下流のユーザーに GPL が適用されます。内部ツールでは、ほとんどのコピーレフト義務は内部使用に適用されません。
• FOSSA、Snyk、WhiteSource、license-checker などのツールを使って、CI/CD でライセンススキャンを自動化し、依存関係の追加に伴う新たな問題を検出してください。
• 事前承認済みのライセンス許可リスト（例：MIT、BSD、Apache-2.0、ISC）を用意し、リストにないライセンスは手動レビューを必須にしてください。
• 配布物に同梱する THIRD-PARTY-NOTICES ファイルに、すべてのライセンス義務を記録してください。

安全上の境界

• 出力は情報提供を目的とした文案作成または問題点の洗い出しとして扱い、法的助言として扱わないでください。
• 適用される法域と関連する発効日を特定し、変更される要件は最新の一次情報源に照らして確認してください。
• 言語が準拠している、執行可能である、または完全であると断言しないでください。不確実性を明示し、重要な判断については有資格の弁護士への相談を推奨してください。
• ユーザーが確認し、明示的に承認しない限り、法的条件を提出、公開、承諾、署名、送信しないでください。

エッジケース

• デュアルライセンスのパッケージ（例：MIT OR Apache-2.0） — パッケージが SPDX の OR 式によって選択肢を提示している場合、最も適合性の高いライセンスを選択できます。選択したライセンスを記録し、そのライセンスの義務のみを適用してください。
• SSPL と Commons Clause — MongoDB の SSPL と Commons Clause は、OSI 承認ライセンスではありません。これらはそれぞれ SaaS の利用と商用利用を制限します。ソースコードが入手可能でも、独自の制限として扱ってください。
• バージョン間でのライセンス変更 — 依存関係は、バージョンによってライセンスが変更される場合があります（例：Elasticsearch は v7.11 で Apache-2.0 から SSPL に移行しました）。ライセンスが確認済みのバージョンに固定し、更新時のライセンス変更を監視してください。
• フォント、画像、非コード資産 — 資産に適用されるクリエイティブ・コモンズ・ライセンスには、ソフトウェアライセンスとは異なる互換性ルールがあります。CC-BY-SA は継承（コピーレフトに類似）を要求し、CC-BY-NC は商用利用を禁止します。コードのライセンススキャンで同梱資産も対象になるとは限りません。
• Stack Overflow または AI 生成コードのスニペット — Stack Overflow のコンテンツには CC-BY-SA 4.0 が適用されます。相当量のコードスニペットをそのままコピーすると、継承義務が生じます。AI 生成コードは出所が不明確な場合があります。独自に作成していないコード部分の出典を記録してください。