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

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.

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

…