1. Load

   ~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md

   . If placeholders present, stop and prompt: "Run

   /ip-legal:cold-start-interview

   first — I need to learn your practice profile (and OSS policy, if any) before I can review." If the practice profile points at an uploaded OSS policy, read that too — it is the source of truth for accepted / review / banned licenses on this team.
2. Establish the scope: a dependency list (package.json, requirements.txt, go.mod, Gemfile, Cargo.toml, pom.xml, SBOM), a single library, or outbound code the team is preparing to open-source. If the user passed a path, infer from the file; otherwise ask.
3. Establish the deployment model before classifying obligations — SaaS, distributed binary, internal only, or embedded. The same dependency list triggers different obligations depending on this.
4. Follow the workflow below. In particular:
   • Read the actual license text, not just metadata — LICENSE files can be wrong, package metadata can be stale.
   • Classify each package into permissive / weak copyleft / strong copyleft / public domain / non-OSI / unknown.
   • Flag license-unknown as "needs review," not permissive by default.
   • Flag non-OSI source-available licenses (SSPL, BUSL, Commons Clause, Elastic License, fair-source) — these are not open source.
   • For outbound code, check that the chosen outbound license is compatible with every embedded dependency.
5. Output the memo per the template below — work-product header first, bottom line, top-of-memo flags, per-package blocks grouped by severity, jurisdiction note, outbound check (if applicable), approval routing.
6. Respect the decision posture. When a copyleft-trigger analysis turns on a contested question (AGPL's "interacts over a network," GPL-3.0's "conveying," LGPL linking scope), flag for attorney review and surface the factors cutting both ways. Anything flagged as strong copyleft or license-unknown goes to an attorney before the dependency ships or the code is released.

~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md

/ip-legal:cold-start-interview

• Who owns OSS review on this team (often engineering with legal sign-off)
• Escalation routing for copyleft obligations
• The work-product header to prepend

What are we reviewing?

1. A dependency list —

   package.json

   ,

   requirements.txt

   ,

   go.mod

   ,

   Gemfile

   ,

   Cargo.toml

   ,

   pom.xml

   , an SBOM (SPDX / CycloneDX), a lockfile
2. A single library — one specific package you're considering adding
3. Our own code — we're planning to open-source this and need to check what's embedded

• Dependency list → classify every entry, roll up obligations
• Single library → classify one package and walk its transitive dependencies if available
• Outbound code → check what's embedded (direct and transitive), check whether chosen outbound license is compatible with all embedded licenses, check that LICENSE / NOTICE files are correct

How will this be deployed?

1. SaaS / hosted service — users access over a network; nothing ships to the user
2. Distributed binary — we ship compiled code to users (desktop app, mobile app, on-prem server, CLI tool)
3. Internal only — used only inside the company, not distributed outside
4. Embedded / firmware — shipped in hardware or as closed-system firmware

• Dual-licensed packages — which license are we using? The choice may change obligations.
• Deprecated packages — the package is no longer maintained; is there a supported replacement?
• Packages with a copyleft dependency in their own tree — the top-level license is permissive but a transitive dependency is copyleft.
• Packages that changed license recently — Redis, MongoDB, Elastic, HashiCorp — make sure the version pinned is under the license you think it is.

• [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"]

> **How is the copyleft dependency consumed?** The linking relationship determines whether copyleft actually triggers. Ask or determine:
> - **Static linking / compilation together:** The works are combined into one binary. Strong signal that copyleft triggers (LGPL "work based on the Library," GPL derivative work).
> - **Dynamic linking / shared library:** The works remain separable at runtime. LGPL explicitly permits this ("work that uses the Library"). GPL's position is contested (FSF says derivative, others disagree).
> - **Header inclusion / inline functions:** Can create a derivative work depending on how much is included.
> - **Subprocess / IPC:** Separate processes communicating over well-defined interfaces. Generally not derivative.
> - **Network API call:** For most licenses, no. For **AGPL**, the network-interaction clause means serving the software over a network IS distribution. In a microservices architecture, an AGPL component behind an API still triggers.
> - **File-scope copyleft (MPL):** Only the modified files carry copyleft, not the whole work. Check whether any copyleft files were modified.
>
> **The severity rating depends on this.** "LGPL — weak copyleft, linking rules vary" without the linking analysis is the answer that gets an engineer sued. Static-linked LGPL in a proprietary product is 🔴 Critical. Dynamic-linked LGPL is 🟢 Low. Same license, opposite rating.

**Severity calibration:**

| Level | Means |
|---|---|
| 🔴 Critical | Strong copyleft in a deployment that triggers it (e.g., GPL in a distributed binary, AGPL in a SaaS). Non-OSI license that the business model actually conflicts with (e.g., SSPL while we're building a managed service). License cannot be determined and the package is load-bearing. |
| 🟠 High | Weak copyleft with obligations the team hasn't set up for (file-level disclosure, NOTICE requirements). Dual-licensed where the chosen license is ambiguous. License file says one thing, headers say another. |
| 🟡 Medium | Permissive with attribution requirements that haven't been wired into the build (missing NOTICES file, missing LICENSE in distribution). Transitive copyleft in a position that may or may not trigger, depending on how the library is consumed. |
| 🟢 Low | Permissive with obligations already satisfied. Copyleft in a deployment model that doesn't trigger it (e.g., GPL library used internally only, with no redistribution). |

• License unknown — classify as "needs review," not permissive. An unclassified dependency should stop a ship decision, not slip through.
• License file conflicts with file headers — read both and report the conflict.
• Incompatible combinations — GPL-2.0 only + Apache-2.0 historically a known incompatibility; check MPL / EPL / GPL combinations carefully.
• Non-OSI licenses posing as open source — SSPL, BUSL, Commons Clause, Elastic License, Confluent Community. Read the license; don't rely on GitHub's "open source" badge.
• License changes — if a prior version was permissive and the current version is source-available, the pin matters.

• Confirm the chosen outbound license is compatible with every embedded dependency's license (e.g., you cannot release under MIT if you've embedded GPL code — the combined work must be GPL)
• Confirm LICENSE file is present and correct
• Confirm NOTICE file is present and lists required attributions (Apache-2.0 and others)
• Confirm third-party license texts are bundled where required
• Confirm no proprietary or confidential code, no customer data, no embedded credentials in the repo history
• Confirm trademark and brand policy for any project name (separate from the copyright license)

~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md

## Outputs

## Who's using this

No silent supplement. If a research query to the configured legal research tool returns few or no results for a rule the memo needs (enforceability of AGPL's network trigger in a given jurisdiction, scope of GPL-3.0's patent grant, latest license text for a recently-relicensed package), report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [rule / license / jurisdiction]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged

[web search — verify]

and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.

Source attribution. Where the memo cites a license text, a court decision interpreting a license, or guidance from a steward (FSF, OSI, SPDX, SFLC), tag the citation:

[OSI]

,

[SPDX]

,

[FSF]

,

[SFC/SFLC]

,

[Westlaw]

, or the MCP tool name for citations retrieved from a connector;

[web search — verify]

for web-search citations;

[model knowledge — verify]

for citations recalled from training data;

[user provided]

for license text read directly from the repo. Citations tagged

verify

carry higher fabrication risk. Never strip or collapse the tags.

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

• Practice profile and any OSS policy were loaded
• Deployment model was established before classifying obligations
• Every dependency has a classification, including transitives where available
• License-unknown packages are flagged, not defaulted to permissive
• License text was read (not just metadata) for any copyleft or non-OSI finding
• Source tags applied to citations; no stripped

  verify

  tags
• Approver named per practice profile
• Output marked with the work-product header