oss-review

/oss-review

Against ~/.claude/plugins/config/claude-for-legal-zh/ip-legal/CLAUDE.md perform an open source license compliance check using the practice profile in . Classify dependencies by license family, map obligations to deployment mode, flag unknown licenses and fake open-source packages masquerading as open source, and recommend actions — comply, replace, remove, seek legal review, seek commercial licensing.

Instructions

Load ~/.claude/plugins/config/claude-for-legal-zh/ip-legal/CLAUDE.md。 If it contains placeholders, stop and prompt: "Run /ip-legal:cold-start-interviewfirst — before reviewing I need to know your practice profile (and open source policy, if any)." If the practice profile points to an uploaded open source policy, read that file too — it is the authoritative source for licenses your team approves/reviews/prohibits.
Determine scope: a dependency list (package.json, requirements.txt, go.mod, Gemfile, Cargo.toml, pom.xml, SBOM), an individual library, or externally released code the team is preparing to open-source. If the user passed a path, infer from the file; otherwise ask.
Determine the deployment mode before classifying obligations — SaaS, distributing binaries, internal use only, or embedded. The same dependency list triggers different obligations under different modes.
Execute the following workflow. In particular:
- Read the actual license text, not just metadata — LICENSE files can be wrong, and package metadata can be outdated.
- Classify packages into: permissive / weak copyleft / strong copyleft / public domain / non-OSI / unknown.
- Flag unknown licenses as "needs review"; do not default to treating them as permissive.
- Flag non-OSI source-available licenses (SSPL, BUSL, Commons Clause, Elastic License, etc.) — these are not open source.
- For externally released code, check whether the chosen output license is compatible with every embedded dependency.

Output the memo using the following template — work product header at the top, bottom-line conclusion, top-level flags, per-package blocks grouped by severity, jurisdictional notes, external release checks (if applicable), approval routing.
Respect decision posture. When copyleft trigger analysis depends on contested issues (AGPL's "interacting over a network," GPL-3.0's "conveying," LGPL linking scope), flag for attorney review and show the factors favoring each side. Anything classified as strong copyleft or unknown-license must be evaluated by an attorney before dependency release or code release.

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  # 仓库根目录 — 扫描所有清单

Better when connected

Open source compliance requests usually come in through ticketing systems. After connecting to Jira, Linear, or Asana, this skill can: monitor incoming open source requests, reply directly in tickets with guidance (flag incomplete information, request repository links, return license family classifications), and track compliance status for each request.

Without a connector, paste the ticket or describe the request, and I will handle them one by one.

Matter context

Matter context. Check the practice-level CLAUDE.md for ## 事项工作区. If Enabled is ✗(the default state for legal users), skip the rest of this section — skills use practice-level context, and the matter mechanism is not visible. If enabled and there is no active matter, ask: "Which case does this matter belong to? Run /ip-legal:matter-workspace switch <slug> or reply 实务级."Load the active matter's matter.md to get matter-specific context and override settings. Write output to the matter folder ~/.claude/plugins/config/claude-for-legal-zh/ip-legal/matters/<事项slug>/. Unless 跨事项上下文 is enabled, never read files from other matters.

Purpose

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

This is a preliminary classification. Copyleft analysis depends on deployment mode, degree of linking, jurisdiction, and sometimes on legally untested questions (such as AGPL's "interaction over a network"). Anything classified as strong copyleft or unknown license must be evaluated by a lawyer before dependency release or code release. This skill reports what it found; the lawyer decides what to do.

Prerequisite: Load the practice profile

Before scanning dependencies, first read ~/.claude/plugins/config/claude-for-legal-zh/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 is responsible for open source review on the team (usually engineer + legal sign-off)
Escalation routing for copyleft obligations
Work product header attached to the output

If the practice profile has an uploaded open source policy, read that file too—it is the true source for which licenses the team accepts, which trigger review, and which are prohibited.

Workflow

Step 1: What is the scope?

Ask (or infer from what the user provided):

What are we reviewing?

Dependency list — package.json、requirements.txt、go.mod、Gemfile、Cargo.toml、pom.xml, SBOM (SPDX / CycloneDX), lockfile

Single library — a specific package you are considering adding

Our own code — we plan to open source this and need to check what is embedded

The analysis path differs:

Dependency list → classify each item, summarize obligations
Single library → classify one package, and if obtainable traverse its transitive dependencies
Code to be released externally → check what is embedded (direct and transitive), check whether the chosen outbound license is compatible with all embedded licenses, check whether LICENSE / NOTICE files are correct

Step 2: Deployment mode?

This is the most important input after the license list—the same library carries different obligations under different software delivery methods. Ask:

How will this be deployed?

SaaS / hosted service — users access it over the network; nothing is delivered to users

Distribute binaries — we deliver compiled code to users (desktop app, mobile app, on-prem server, CLI tool)

Internal use only — used only inside the company, not distributed externally

Embedded / firmware — embedded in hardware or released as closed-system firmware

Deployment method	Materially relevant licenses
SaaS	AGPL (network-triggered), permissive attribution obligations in any interface, SSPL/BUSL/Elastic if resold as a competing service
Distribute binaries	GPL, LGPL, MPL, EPL (all trigger on distribution), permissive attribution obligations
Internal use only	Most copyleft does not trigger — no distribution. Permissive attribution is still good practice. If external users interact over the network, AGPL still triggers.
Embedded / firmware	GPL is particularly difficult to comply with here (source disclosure + reproducible builds + installation instructions in some cases). Plan before release, not after.

Mark the deployment mode in the output memo — the same dependency list reviewed as "SaaS" vs "distributed binaries" produces different obligations.

Step 3: Classify dependency by dependency

For each package, determine the license. Read the actual license text, not just the metadata — the LICENSE file may be wrong (file says MIT but the header declares GPL; README claims Apache but there is no LICENSE file), and package manager metadata may be outdated.

Classify into:

Category	Examples	Key obligations
Permissive	MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0、ISC、Zlib、Unlicense	Attribution, retain license text, Apache-2.0 adds patent grant + NOTICE requirement
Weak copyleft	LGPL-2.1、LGPL-3.0、MPL-2.0、EPL-1.0、EPL-2.0、CDDL	File-level or library-level source disclosure; linking rules vary
Strong copyleft	GPL-2.0, GPL-3.0, AGPL-3.0, OSL, EUPL (depending on version)	Broad source disclosure; AGPL extends to network use
Public domain / waiver	CC0、Unlicense、WTFPL	Usually no obligations, but contested in jurisdictions that do not recognize public domain waivers (e.g., moral rights of attribution are inalienable under Chinese civil law)
Non-OSI source-available	SSPL, BUSL, Commons Clause, Elastic License, Confluent Community, fair-source family	Not open source — restricts commercial use, competing service use, or both. Read the specific license.
Other / custom / unknown	Vendor-specific, proprietary, missing license file, license text conflicting with header	Stop — must not be treated as permissive by default

Flag:

Dual-licensed package — which license are we using? The choice may change obligations.
Deprecated package — the package is no longer maintained; is there a supported replacement?
Package with copyleft dependencies in its own dependency tree — the top-level license is permissive but a transitive dependency is copyleft.
Package that changed license recently — Redis, MongoDB, Elastic, HashiCorp — ensure the pinned version falls under a license you understand.

Step 4: Map obligations to deployment mode

For each classified dependency, state what the deployment mode triggers:

### [包@版本] — [许可证]

**分类：** [宽松型 / 弱 copyleft / 强 copyleft / 公有领域 / 非OSI / 未知]

**对我们的部署（[SaaS / 二进制 / 内部 / 嵌入式]）的义务：**

- [ ] [具体义务 — 例如"在随应用分发的NOTICES文件中包含署名"]
- [ ] [例如"如我们修改并分发，公布我们的修改的源码"]
- [ ] [例如"AGPL网络触发 — 如用户通过网络访问我们的修改版本，须向他们提供源码"]

**风险：** 🔴 严重 | 🟠 高 | 🟡 中 | 🟢 低

**建议：** [履行义务 | 替换为[替代方案] | 移除 | 发布前经律师审查 | 向[供应商]寻求商业许可]

How is the copyleft dependency consumed? The linking relationship determines whether copyleft actually triggers. Ask or determine:

Static linking / compiled together: The work is merged into a single binary. Strong signal that copyleft triggers (LGPL's "work based on the library", GPL's derivative work).

Dynamic linking / shared library: The work remains separable at runtime. LGPL explicitly permits this ("work that uses the library"). GPL's position is contested.

Header file inclusion / inline functions: May create derivative works depending on inclusion.

Subprocess / IPC: Independent processes communicating through a well-defined interface. Generally non-derivative.

Network API calls: For most licenses, no. For AGPL, the network interaction clause means that providing the software over a network constitutes distribution. In a microservices architecture, an AGPL component behind an API still triggers.

File-level copyleft (MPL): Only modified files carry copyleft, not the entire work. Check whether any copyleft files have been modified.

Severity is determined accordingly. "LGPL — weak copyleft, linking rules vary" without linking analysis is the answer that gets engineers sued. LGPL statically linked in a proprietary product is 🔴 severe. LGPL dynamically linked is 🟢 low. The same license, opposite ratings.

Severity calibration:

Level	Meaning
🔴 Severe	Strong copyleft in the deployment that triggers it (e.g., GPL in a distributed binary, AGPL in SaaS). Non-OSI licenses where the business model actually conflicts (e.g., we are running a hosted service while the code uses SSPL). The license cannot be determined and the package is a critical dependency.
🟠 High	Weak copyleft obligations that the team has not yet established (file-level disclosure, NOTICE requirements). Dual licensing with an unclear selected license. LICENSE file inconsistent with headers.
🟡 Medium	Permissive but attribution requirements not yet wired into the build process (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 and obligations are satisfied. Copyleft in a deployment mode that does not trigger it (e.g., a GPL library used only internally, with no redistribution).

Step 5: Flag failure modes

Point out any of the following at the top of the memo:

Unknown license — classify as "needs review", not permissive. Unclassified dependencies should block release decisions and must not slip through.
LICENSE file conflicts with file headers — read both and report the conflict.
Incompatible combinations — GPL-2.0 only + Apache-2.0 is a historically known incompatibility; carefully check MPL/EPL/GPL combinations.
Non-OSI licenses disguised as open source — SSPL, BUSL, Commons Clause, Elastic License, Confluent Community. Read the license; do not rely on GitHub's "open source" badge.
License changes — e.g., if a previous version was permissive and the current version is source-available, pinning the version is critical.

Step 6: External release check (e.g., reviewing our own code before an open source release)

If the user is preparing to open source the code:

Confirm the chosen output license is compatible with every embedded dependency's license (for example, if GPL code is embedded, it cannot be released under MIT — the combined work must be GPL)
Confirm the LICENSE file exists and is correct
Confirm the NOTICE file exists and lists the required attributions (Apache-2.0, etc.)
Confirm third-party license texts are packaged as required
Confirm there is no proprietary or confidential code, no customer data, and no embedded credentials in the repository history
Confirm trademark and branding policy for the project name (independent of the copyright license)

Step Seven: Assemble the memorandum

In ~/.claude/plugins/config/claude-for-legal-zh/ip-legal/CLAUDE.md → ## 输出 prepend the work product header (varies by role — see ## 使用者）。

This memorandum and the reliance list reviewed may be confidential and/or privileged. Output inherits the source status. Distribute only within the confidentiality circle; remove the work product header before external delivery.

No silent completion. If the legal research tool returns few or no results for the rules needed for the memorandum, report what was found and stop. Do not fill gaps via web search or model knowledge without asking. State: "The search returned [N] results from [tool]. Coverage of [rule/license/jurisdiction] appears thin. Options: (1) expand the search query, (2) try another research tool, (3) search the web — results will be labeled[联网检索 — 需复核], (4) mark as unverified and stop. Which do you choose?" It is for the lawyer to decide whether to accept lower-reliability sources.

Source attribution. When the memorandum cites license text, court decisions interpreting the license, or regulator guidance, label the citation:[OSI]、[SPDX]、[FSF]、[元典检索]or the connector's MCP tool name; web search citations are labeled[联网检索 — 需复核]; citations recalled from training data are labeled[模型知识 — 需验证]; license text read directly from the repository is labeled[用户提供]. Citations labeled需验证carry a higher fabrication risk. Never strip or merge labels.

[工作成果页眉 — 按插件配置 ## 输出]

# 开源审查：[项目 / 依赖列表 / 包]

**审查日期：** [日期]
**范围：** [依赖列表 / 单个库 / 对外发布代码]
**部署模式：** [SaaS / 二进制 / 内部 / 嵌入式]

---

## 底线结论

[两句话。可以发布吗？必须先做什么？]

**已审查包数：** [N]
**按分类：** [N 宽松型、N 弱 copyleft、N 强 copyleft、N 公有领域、N 非OSI、N 未知]
**问题：** [N]🔴 [N]🟠 [N]🟡 [N]🟢

**需要审批人：** [姓名，按实务画像]

---

## 顶部备忘录标注

[许可证未知列表、许可证冲突列表、非OSI伪装开源列表、不兼容组合]

---

## 逐包分析

[第四步的分析块，按严重程度分组]

---

## 管辖提示

开源许可证的可执行性各异——AGPL的网络触发尚未在法庭上广泛检验；GPL-3.0的专利条款在中美专利法下解读不同；公有领域放弃并非普适承认。说明任何下游分发的管辖法律选择并标注实务画像标记为升级的管辖。

---

## 对外发布检查（如适用）

[第六步]

---

## 审批路由

[来自实务画像 — 谁审批，什么触发自动升级]

Decision posture

When a license cannot be confidently classified, mark it as **"needs review"** — do not call it permissive. Underestimating license risk is a one-way door: a release decision made on a "permissive by default" basis becomes a source disclosure obligation or an injunction months later. Over-labeling is a two-way door — the lawyer narrows the list during review.

Likewise, when the copyleft trigger analysis depends on a contested issue, label it for lawyer review and present the factors favoring each side.

Pre-delivery quality check

Practice profile and any open source policy have been loaded
Deployment mode has been determined before classifying obligations
Every dependency has a classification (including transitive dependencies, if any)
Packages with unknown licenses have been labeled, not defaulted to permissive
The license text has been read for any copyleft or non-OSI finding (not just metadata)
Source labels have been applied on citations; no stripped 需验证 labels
Approvers are named per the practice profile
Output is marked with the work product header

End with an action-options decision tree

End with the action-options decision tree specified in CLAUDE.md ## 输出 . Customize the options to what this skill just produced — the five default branches (draft X, escalate, gather more facts, watch and wait, other matters) are only a starting point, not a fixed template. It is for the lawyer to choose from the decision tree.

If the scan covers more than about 10 packages, or when the user needs it: provide a data dashboard. Present it as: counts by license family (permissive / weak copyleft / strong copyleft / AGPL / proprietary / unknown), a risk distribution, and a sortable table of findings with severity and package version.