Oss Review

/oss-review

Runs an open source license compliance check against the practice profile in ~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md. Classifies dependencies by license family, maps obligations to the deployment model, flags license-unknown and non-OSI-posing-as-OSS packages, and recommends actions — comply, replace, remove, seek legal review, seek commercial license.

Instructions

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.

1. 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.

1. Establish the deployment model before classifying obligations — SaaS, distributed binary, internal only, or embedded. The same dependency list triggers different obligations depending on this.

1. 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.

1. 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.

1. 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.

Examples

/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

Works better connected

OSS clearance requests usually come in via a ticketing system. Connected to Jira, Linear, or Asana, this skill can: monitor incoming OSS requests, respond with guidance directly in the ticket (flagging incomplete info, asking for the repo link, returning the license-family classification), and track clearance status across requests.

Without a connector, paste the ticket or describe the request and I'll handle it one at a time. See CONNECTORS.md at the repo root for how to add a ticketing connector.

Matter context

Matter context. Check ## Matter workspaces in the practice-level CLAUDE.md. If Enabled is ✗ (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /ip-legal:matter-workspace switch <slug> or say practice-level." Load the active matter's matter.md for matter-specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude-for-legal/ip-legal/matters/<matter-slug>/. Never read another matter's files unless Cross-matter context is on.

Purpose

Tell the user what licenses are in their dependency tree, what obligations those licenses trigger given how the code will be deployed, and what to do about each one. The output is a memo the lawyer (or the engineer with attorney access) can act on — comply, replace, remove, seek legal review, seek commercial license.

This is a first-pass classification. Copyleft analysis depends on the deployment model, the degree of linking, the jurisdiction, and sometimes on legal questions that have not been tested in court (notably AGPL's "interacts over a network," GPL-3.0's patent clause). For anything that classifies as strong copyleft or license-unknown, an attorney evaluates before the dependency ships or the code is released. The skill reports what it found; the lawyer decides what to do.

Precondition: load the practice profile

Before scanning dependencies, read `~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md`. If it is missing or still contains placeholders, stop and run /ip-legal:cold-start-interview. The practice profile tells you:

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

If the practice profile has an OSS policy uploaded, read that too — it is the source of truth for which licenses the team accepts, which trigger review, and which are banned.

Workflow

Step 1: What's the scope?

Ask (or infer from what the user provided):

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

The analysis path differs:

• 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

Step 2: What's the deployment model?

This is the single most important input after the license list — the same library carries different obligations depending on how the software is delivered. Ask:

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

Flag the deployment model in the output memo — the same dependency list reviewed against "SaaS" vs. "distributed binary" yields different obligations.

Step 3: Classify each dependency

For every package, determine the license. Read the actual license text, not just the metadata — LICENSE files can be wrong (the file says MIT but the headers say GPL; the README claims Apache but there's no license file), and package manager metadata can be stale.

Classify into: