oss-review

/oss-review

~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md に記載された業務プロファイルに基づき、オープンソースライセンスのコンプライアンスチェックを実施します。依存関係をライセンスの種類ごとに分類し、導入モデルに応じて義務を整理し、ライセンス不明のパッケージや、オープンソースを装った非OSI準拠のパッケージにフラグを立て、対応策（遵守、置き換え、削除、法務レビューの依頼、商用ライセンスの取得）を提案します。

手順

1. ~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md を読み込みます。 プレースホルダーがある場合は作業を中止し、次のように促します：「まず /ip-legal:cold-start-interview を実行してください。レビューを行う前に、業務プロファイル（およびOSSポリシーがあればその内容）を確認する必要があります。」業務プロファイルにアップロード済みのOSSポリシーが記載されている場合は、それも読み込みます。チームで受け入れ可能、要レビュー、または禁止するライセンスの判断基準として、そのポリシーを優先します。

2. 対象範囲を確認します。 依存関係の一覧（package.json、requirements.txt、go.mod、Gemfile、Cargo.toml、pom.xml、SBOM）、単一のライブラリ、またはチームがオープンソースとして公開する準備をしているコードのいずれかです。ユーザーがパスを指定した場合はファイルから推定し、指定していない場合は質問します。

3. 義務を分類する前に、導入モデルを確認します。 SaaS、配布バイナリ、社内利用のみ、または組み込みのいずれかです。同じ依存関係一覧でも、導入モデルによって義務が異なります。

4. 以下のワークフローに従います。 特に、次の点に留意してください。

   • メタデータだけでなく、実際のライセンステキストを読みます。LICENSE ファイルが誤っている場合や、パッケージのメタデータが古い場合があります。
   • 各パッケージを、パーミッシブ／弱いコピーレフト／強いコピーレフト／パブリックドメイン／非OSI準拠／不明に分類します。
   • ライセンス不明の場合は、デフォルトでパーミッシブとせず、「要レビュー」としてフラグを立てます。
   • OSI準拠ではないソース公開型ライセンス（SSPL、BUSL、Commons Clause、Elastic License、fair-source）にフラグを立てます。これらはオープンソースではありません。
   • 外部公開するコードについては、選択した公開ライセンスが、組み込まれるすべての依存関係と互換性があるか確認します。

5. 以下のテンプレートに従ってメモを作成します。 成果物ヘッダーを先頭に置き、その後に結論、メモ冒頭のフラグ、重大度ごとにグループ化したパッケージ別ブロック、管轄区域に関する注記（該当する場合）、公開時の確認事項（該当する場合）、承認の依頼先を記載します。

6. 判断方針を守ります。 コピーレフトの適用判断が争点のある解釈に左右される場合（AGPL の「ネットワーク経由のインタラクション」、GPL-3.0 の「伝達」、LGPL のリンク範囲）は、弁護士によるレビューが必要であることを明示し、双方の判断を支持する要素を示します。強いコピーレフトまたはライセンス不明としてフラグを立てたものは、依存関係の導入またはコードの公開前に、必ず弁護士に確認してもらいます。

例

/ip-legal:oss-review ~/code/my-project/package.json
/ip-legal:oss-review ~/code/my-project/requirements.txt
/ip-legal:oss-review redis
/ip-legal:oss-review ~/code/my-project  # repo root — scan all manifests

---

接続すると、さらに便利になります

OSSのクリアランス依頼は通常、チケット管理システム経由で届きます。Jira、Linear、Asana に接続すると、このスキルでは、届いたOSS依頼の監視、チケット内での直接的なガイダンスの提供（情報不足の指摘、リポジトリのリンクの確認、ライセンスの種類の分類結果の返却）、依頼ごとのクリアランス状況の追跡ができます。

コネクターがない場合は、チケットを貼り付けるか、依頼内容を説明してください。1件ずつ対応します。チケット管理コネクターの追加方法については、リポジトリのルートにある CONNECTORS.md を参照してください。

案件のコンテキスト

案件のコンテキスト。 業務レベルの CLAUDE.md で ## Matter workspaces を確認します。Enabled が ✗（社内法務ユーザー向けのデフォルト）の場合、この段落の残りはスキップしてください。スキルは業務レベルのコンテキストを使用し、案件管理の仕組みは表示されません。有効になっていて、アクティブな案件がない場合は、「どの案件についてですか？ /ip-legal:matter-workspace switch <slug> を実行するか、practice-level と入力してください。」と尋ねます。案件固有のコンテキストや上書き設定を確認するため、アクティブな案件の matter.md を読み込みます。出力は ~/.claude/plugins/config/claude-for-legal/ip-legal/matters/<matter-slug>/ に保存します。Cross-matter context が on でない限り、他の案件のファイルは読み込まないでください。

---

目的

依存関係ツリーに含まれるライセンス、そのコードのデプロイ方法によって発生するライセンス上の義務、および各ライセンスへの対応方法をユーザーに伝えます。出力は、弁護士（または弁護士に相談できるエンジニア）が対応できるメモです。対応には、義務を履行する、置き換える、削除する、法務レビューを依頼する、商用ライセンスを取得する、といった方法があります。

これは初回の分類です。 コピーレフトの分析は、デプロイモデル、リンクの程度、管轄区域、場合によっては裁判で判断されたことのない法的問題（特に、AGPLの「ネットワークを介したやり取り」やGPL-3.0の特許条項）に左右されます。強いコピーレフトまたはライセンス不明に分類されるものについては、依存関係を組み込んだ製品を出荷する前、またはコードをリリースする前に、弁護士の評価を受けてください。このスキルは調査結果を報告しますが、対応を決めるのは弁護士です。

前提条件：実務プロファイルを読み込む

依存関係をスキャンする前に、~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.mdを読んでください。 ファイルが存在しない、またはプレースホルダーが残っている場合は、処理を中止し、/ip-legal:cold-start-interviewを実行してください。実務プロファイルには、次の情報が記載されています。

• このチームでオープンソースレビューを担当する人（多くの場合、法務の承認を受けるエンジニアリングチーム）
• コピーレフトに関する義務のエスカレーション先
• 先頭に付ける業務成果物のヘッダー

実務プロファイルにオープンソースポリシーがアップロードされている場合は、それも読んでください。チームが受け入れるライセンス、レビューの対象となるライセンス、禁止されているライセンスを判断する際の基準になります。

ワークフロー

ステップ 1：対象範囲は？

ユーザーに質問するか、提供された情報から推測します。

何をレビューしますか？

1. 依存関係リスト — package.json、requirements.txt、go.mod、Gemfile、Cargo.toml、pom.xml、SBOM（SPDX／CycloneDX）、ロックファイル
2. 単一のライブラリ — 追加を検討している特定のパッケージ
3. 自社のコード — オープンソース化を予定しており、組み込まれているものを確認する必要があるコード

分析方法は対象によって異なります。

• 依存関係リスト → 各項目を分類し、義務を集約します
• 単一のライブラリ → 1つのパッケージを分類し、可能であれば推移的依存関係も確認します
• 外部公開するコード → 組み込まれているもの（直接依存と推移的依存）を確認し、選択した公開用ライセンスがすべての組み込みライセンスと両立するかを確認し、LICENSE／NOTICEファイルが適切であることを確認します

ステップ 2：デプロイモデルは？

ライセンス一覧の次に重要な入力情報です。同じライブラリでも、ソフトウェアの提供方法によって義務が異なります。次のように質問してください。

どのようにデプロイしますか？

1. SaaS／ホステッドサービス — ユーザーはネットワーク経由でアクセスし、ユーザーには何も配布しません
2. バイナリ配布 — コンパイル済みコードをユーザーに配布します（デスクトップアプリ、モバイルアプリ、オンプレミスサーバー、CLI ツール）
3. 社内利用のみ — 社内でのみ使用し、社外には配布しません
4. 組み込み／ファームウェア — ハードウェアに組み込むか、クローズドシステムのファームウェアとして出荷します

デプロイ	実質的に重要なライセンス
SaaS	AGPL（ネットワーク経由での利用による発動）、UI における許諾条件の緩いライセンスの帰属表示、競合サービスとして再利用する場合の SSPL／BUSL／Elastic
バイナリ配布	GPL、LGPL、MPL、EPL（いずれも配布によって義務が発生）、許諾条件の緩いライセンスの帰属表示
社内利用のみ	配布がないため、ほとんどのコピーレフトライセンスの義務は発生しません。許諾条件の緩いライセンスの帰属表示は、引き続き適切な慣行です。社外のユーザーがネットワーク経由でやり取りする場合、AGPL の義務は発生します。
組み込み／ファームウェア	ここでは GPL への準拠が特に困難です（場合によっては、ソースコードの開示、再現可能なビルド、インストール情報が必要です）。出荷後ではなく、出荷前に計画してください。

出力メモにはデプロイモデルを明記してください。同じ依存関係リストでも、「SaaS」と「バイナリ配布」では、確認される義務が異なります。

ステップ 3: 各依存関係を分類する

各パッケージのライセンスを特定します。メタデータだけでなく、実際のライセンス文を確認してください。LICENSE ファイルが間違っていることもあります（ファイルには MIT と書かれているのに、ヘッダーには GPL と記載されている、README では Apache と主張しているのにライセンスファイルがない、など）。パッケージマネージャーのメタデータが古くなっている場合もあります。

分類	例	主な義務
寛容型	MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0、ISC、Zlib、Unlicense	帰属表示、ライセンス文の保持。Apache-2.0 では特許許諾と NOTICE 要件が追加されます
弱いコピーレフト	LGPL-2.1、LGPL-3.0、MPL-2.0、EPL-1.0、EPL-2.0、CDDL	ファイル単位またはライブラリ単位でのソース開示。リンクに関するルールはライセンスによって異なります
強いコピーレフト	GPL-2.0、GPL-3.0、AGPL-3.0、OSL、EUPL（バージョンによる）	広範なソース開示。AGPL ではネットワーク経由の利用にも適用されます
パブリックドメイン／権利放棄	CC0、Unlicense、WTFPL	通常、義務はありませんが、パブリックドメインへの権利放棄を認めない法域では、異議が唱えられるものもあります
OSI 非準拠のソース公開ライセンス	SSPL、BUSL、Commons Clause、Elastic License、Confluent Community、fair-source 系	オープンソースではありません。商用利用、競合サービスでの利用、またはその両方を制限します。個別のライセンスを確認してください。
その他／独自／不明	ベンダー固有、プロプライエタリ、ライセンスファイルの欠落、ファイルとヘッダーの間でライセンスが不一致	作業を止めてください。デフォルトで寛容型として扱ってはいけません

次の項目に注意してください。

• デュアルライセンスのパッケージ — どのライセンスを使用していますか？選択によって義務が変わる場合があります。
• 非推奨のパッケージ — パッケージはメンテナンスされなくなっています。サポートされている代替品はありますか？
• 依存ツリーにコピーレフトの依存関係を含むパッケージ — トップレベルのライセンスは寛容型でも、推移的な依存関係がコピーレフトの場合があります。
• 最近ライセンスが変更されたパッケージ — Redis、MongoDB、Elastic、HashiCorp など。固定したバージョンが、想定しているライセンスの下で提供されていることを確認してください。

ステップ 4：義務をデプロイモデルに照らして判断する

分類した依存関係ごとに、デプロイモデルによって何が発生するかを明記します。

### [package@version] — [License]

**Classification:** [Permissive / Weak copyleft / Strong copyleft / Public domain / Non-OSI / Unknown]

**Obligations for our deployment ([SaaS / binary / internal / embedded]):**

- [ ] [Specific obligation — e.g., "Include attribution in a NOTICES file shipped with the app"]
- [ ] [e.g., "If we modify and distribute, publish source of our modifications"]
- [ ] [e.g., "AGPL network trigger — if users access our modified version over a network, source must be offered to them"]

**Risk:** 🔴 Critical | 🟠 High | 🟡 Medium | 🟢 Low

**Recommendation:** [Comply with obligations | Replace with [alternative] | Remove | Attorney review before shipping | Seek commercial license from [vendor]]

コピーレフトの依存関係はどのように利用されていますか？ リンクの形態によって、コピーレフトが実際に適用されるかどうかが決まります。次の点を確認または判断してください。

• 静的リンク／一括コンパイル： 各著作物が 1 つのバイナリに結合されます。コピーレフトが適用される強い根拠になります（LGPL の「ライブラリを基にした著作物」、GPL の派生著作物）。
• 動的リンク／共有ライブラリ： 実行時に各著作物は分離されたままです。LGPL では明示的に許可されています（「ライブラリを利用する著作物」）。GPL の見解については異論があります（FSF は派生著作物とし、異なる見解を示す人もいます）。
• ヘッダーのインクルード／インライン関数： インクルードする範囲によっては、派生著作物となる場合があります。
• サブプロセス／IPC： 明確に定義されたインターフェースを介して通信する別々のプロセスです。通常は派生著作物ではありません。
• ネットワーク API 呼び出し： ほとんどのライセンスでは該当しません。ただし、AGPL ではネットワーク対話に関する条項により、ソフトウェアをネットワーク経由で提供することが頒布に該当します。マイクロサービスアーキテクチャでは、API の背後にある AGPL コンポーネントにも適用されます。
• ファイル単位のコピーレフト（MPL）： コピーレフトが適用されるのは変更したファイルのみで、著作物全体ではありません。コピーレフト対象のファイルを変更したか確認してください。

重大度の評価は、これに左右されます。 リンク形態の分析をせずに「LGPL — 弱いコピーレフト。リンクのルールはさまざま」と答えると、エンジニアが訴えられる事態になりかねません。プロプライエタリ製品で LGPL を静的リンクする場合は 🔴 Critical です。LGPL を動的リンクする場合は 🟢 Low です。同じライセンスでも、評価は正反対になります。

重大度の目安：

レベル	意味
🔴 Critical	適用されるデプロイメントでの強いコピーレフト（例：配布バイナリでの GPL、SaaS での AGPL）。実際のビジネスモデルと相反する非 OSI ライセンス（例：マネージドサービスの構築中に SSPL が適用される場合）。ライセンスを特定できず、そのパッケージが不可欠である場合。
🟠 High	チームがまだ対応を整えていない義務がある弱いコピーレフト（ファイル単位の開示、NOTICE の要件）。選択したライセンスが曖昧なデュアルライセンス。ライセンスファイルの記載とヘッダーの記載が異なる場合。
🟡 Medium	帰属表示の義務がある寛容型ライセンスで、ビルドにまだ組み込まれていない場合（NOTICES ファイルの不足、配布物に LICENSE がない場合）。ライブラリの利用方法によって適用されるかどうかが変わり得る位置にある、推移的なコピーレフト。
🟢 Low	義務をすでに満たしている寛容型ライセンス。適用されないデプロイモデルにおけるコピーレフト（例：再配布せず、GPL ライブラリを内部でのみ使用する場合）。

ステップ 5：問題につながる要因を明示する

次のいずれかに該当する場合は、メモの冒頭にあるセクションで指摘します。

• ライセンスが不明： 寛容型として扱わず、「要確認」に分類します。未分類の依存関係がある場合、リリース判断を止めるべきであり、見過ごしてはいけません。
• ライセンスファイルとファイルヘッダーの記載が不一致： 両方を確認し、不一致を報告します。
• 互換性のない組み合わせ： GPL-2.0 only と Apache-2.0 は、歴史的に既知の非互換の組み合わせです。MPL／EPL／GPL の組み合わせは慎重に確認してください。
• オープンソースを装う非 OSI ライセンス： SSPL、BUSL、Commons Clause、Elastic License、Confluent Community。ライセンスを読み、GitHub の「オープンソース」バッジに頼らないでください。
• ライセンスの変更： 以前のバージョンが寛容型で、現在のバージョンがソース公開型である場合は、固定したバージョンが重要です。

ステップ 6：外部公開前の確認（自社コードをオープンソース化する前にレビューする場合）

ユーザーがコードのオープンソース化を準備している場合：

• 選択した外部公開用ライセンスが、組み込まれているすべての依存関係のライセンスと互換性があることを確認します（例：GPL のコードを組み込んでいる場合、MIT で公開することはできません。結合された著作物には GPL が適用されます）
• LICENSE ファイルが存在し、内容が正しいことを確認します
• NOTICE ファイルが存在し、必要な帰属表示（Apache-2.0 など）が記載されていることを確認します
• 必要な場合、サードパーティのライセンステキストが同梱されていることを確認します
• リポジトリの履歴に、専有コード、機密情報、顧客データ、埋め込み認証情報が含まれていないことを確認します
• プロジェクト名に関する商標およびブランドポリシーを確認します（著作権ライセンスとは別です）

ステップ 7：メモをまとめる

~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md → ## Outputs にある成果物ヘッダーを先頭に付けます（ユーザーの役割によって異なります。「## Who's using this」を参照）。

このメモおよびレビュー対象となった依存関係の一覧は、弁護士・依頼者間秘匿特権の対象、機密情報、またはその両方に該当する場合があります。出力には元資料と同じステータスが適用されます。秘匿特権の対象者の範囲内でのみ配布してください。外部に提供する前（秘匿特権の対象者の範囲外にあるエンジニアリングチケットにメモを添付する前も含む）に、成果物ヘッダーを削除してください。

無断の補足禁止。 メモに必要なルール（特定の法域における AGPL のネットワークトリガーの執行可能性、GPL-3.0 の特許許諾の範囲、最近ライセンスが変更されたパッケージの最新のライセンステキストなど）について、設定済みの法律調査ツールで検索しても結果がほとんど、またはまったく得られない場合は、見つかった内容を報告して、そこで止めてください。確認を求めずに、ウェブ検索やモデルの知識で不足分を補ってはいけません。次のように伝えてください。「[tool] での検索結果は [N] 件でした。[rule / license / jurisdiction] に関する情報は限られているようです。次の選択肢があります：（1）検索クエリを広げる、（2）別の調査ツールを試す、（3）ウェブを検索する（結果には [web search — verify] とタグ付けされ、根拠として使用する前に一次資料との照合が必要です）、または（4）未検証としてフラグを付け、終了する。どれを希望しますか？」信頼度の低い情報源を受け入れるかどうかは、弁護士が判断します。

情報源の帰属表示。 メモでライセンステキスト、ライセンスを解釈する裁判所の判断、または管理団体（FSF、OSI、SPDX、SFLC）のガイダンスを引用する場合は、その引用に [OSI]、[SPDX]、[FSF]、[SFC/SFLC]、[Westlaw]、またはコネクターから取得した引用には MCP ツール名のタグを付けてください。ウェブ検索による引用には [web search — verify]、学習データから想起した引用には [model knowledge — verify]、リポジトリから直接読んだライセンステキストには [user provided] を付けます。verify タグ付きの引用は、捏造のリスクがより高くなります。タグを削除したり、まとめたりしてはいけません。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

# OSS Review: [Project / Dependency List / Package]

**Reviewed:** [date]
**Scope:** [Dependency list / Single library / Outbound code]
**Deployment model:** [SaaS / Binary / Internal / Embedded]

---

## Bottom line

[Two sentences. Can this ship? What has to happen first?]

**Packages reviewed:** [N]
**By classification:** [N permissive, N weak copyleft, N strong copyleft, N public domain, N non-OSI, N unknown]
**Issues:** [N]🔴 [N]🟠 [N]🟡 [N]🟢

**Approval needed from:** [name, per practice profile]

---

## Top-of-memo flags

[License-unknown list, license-conflict list, non-OSI-posing-as-OSS list, incompatible combinations]

---

## By package

[Blocks from Step 4, grouped by severity]

---

## Jurisdiction note

OSS license enforceability varies — AGPL's network trigger has not been broadly tested in court; GPL-3.0's patent clause reads differently under US vs. EU patent law; dedications to public domain are not universally recognized. State the governing-law choice for any downstream distribution (e.g., vendor agreements incorporating the code) and flag jurisdictions the practice profile marks as escalate.

---

## Outbound check (if applicable)

[From Step 6]

---

## Approval routing

[From practice profile — who approves, what triggers automatic escalation]

判断の方針

ライセンスを確信をもって分類できない場合は、**「要レビュー」**とフラグを付けてください。許容的なライセンスだと判断してはいけません。ライセンスリスクを過小評価することは後戻りできません。許容的だという前提で出荷を決めると、数か月後にソース開示義務や差止命令につながるおそれがあります。フラグを付けすぎても、レビューで弁護士がリストを絞り込めるため、後戻りできます。

同様に、コピーレフトのトリガーに関する分析が争点となっている問題（AGPL の「ネットワーク経由での対話」、GPL-3.0 の「伝達」、LGPL のリンクの範囲）に左右される場合は、弁護士のレビュー対象としてフラグを付け、双方に有利な要素を明示してください。

提出前の品質チェック

• 業務プロファイルと OSS ポリシー（該当する場合）を読み込んだ
• 義務を分類する前にデプロイモデルを確認した
• トランジティブ依存関係についても、確認可能な範囲で、すべての依存関係を分類した
• ライセンス不明のパッケージにフラグを付け、許容的だと決めつけていない
• コピーレフト、または OSI 非承認と判定したライセンスについて、メタデータだけでなくライセンステキストを読んだ
• 引用に情報源タグを付け、verify タグを削除していない
• 業務プロファイルに従って承認者を明記した
• 出力に成果物ヘッダーを付けた

次のステップの判断ツリーで締めくくる

CLAUDE.md の ## Outputs に従い、次のステップの判断ツリーで締めくくります。このスキルで今回作成した内容に合わせて選択肢を調整してください。デフォルトの5つの分岐（X の下書きを作成する、エスカレーションする、情報を追加で入手する、様子を見る、その他）は出発点であり、固定ではありません。出力するのは判断ツリーです。選択するのは弁護士です。

スキャンで検出されたパッケージが約10件を超える場合、またはユーザーが希望した場合は、ダッシュボードを提案します（CLAUDE.md の ## Outputs → Dashboard offer for data-heavy outputs を参照）。今回の用途に役立つ内容になるよう提案を調整してください。ライセンスの種類別の件数（許容型／弱いコピーレフト／強いコピーレフト／AGPL／プロプライエタリ／不明）、リスクの分布、重要度とパッケージのバージョンを記載した調査結果の表などが考えられます。