oss-review

/oss-review

根据 ~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md 中的执业档案，执行开源许可证合规检查。按许可证类别对依赖项进行分类，根据部署模式映射义务，标记许可证未知及冒充开源的非 OSI 软件包，并建议采取相应措施——遵守要求、替换、移除、寻求法律审查或申请商业许可证。

Instructions

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 的链接范围），请标记为需要律师审查，并说明各方支持理由。任何被标记为强著佐权或许可证未知的依赖项，在发布依赖项或代码之前都必须交由律师审查。

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 合规审查请求通常通过工单系统提交。连接 Jira、Linear 或 Asana 后，此技能可以：监控收到的 OSS 请求、直接在工单中回复指引（标记信息不完整之处、索取代码仓库链接、返回许可证类别分类），并跟踪各请求的合规审查状态。

如果没有连接器，请粘贴工单或描述请求，我会逐一处理。关于如何添加工单连接器，请参阅仓库根目录下的 CONNECTORS.md。

Matter context

Matter context。 检查执业级别 CLAUDE.md 中的 ## Matter workspaces。如果 Enabled 为 ✗（内部法务用户的默认设置），请跳过本段其余内容——技能使用执业级别的上下文，Matter 机制不可见。如果已启用且没有活动 Matter，请询问：“这是哪个 Matter？请运行 /ip-legal:matter-workspace switch <slug>，或回复 practice-level。”加载活动 Matter 的 matter.md，以获取 Matter 专属上下文和覆盖设置。将输出写入 Matter 文件夹 ~/.claude/plugins/config/claude-for-legal/ip-legal/matters/<matter-slug>/。除非 Cross-matter context 为 on，否则不得读取其他 Matter 的文件。

---

目的

告知用户其依赖树中包含哪些许可证、根据代码的部署方式这些许可证会触发哪些义务，以及每项义务应如何处理。输出是一份备忘录，律师（或可咨询律师的工程师）可以据此采取行动——履行义务、替换、移除、寻求法律审查或寻求商业许可。

这是初步分类。 Copyleft 分析取决于部署模式、链接程度、司法管辖区，有时还取决于尚未经过法庭检验的法律问题（尤其是 AGPL 中的“通过网络交互”、GPL-3.0 的专利条款）。对于被归类为强 Copyleft 或许可证未知的任何情况，依赖项发布或代码公开前，都应由律师进行评估。本技能报告其发现；由律师决定如何处理。

前提：加载执业配置文件

扫描依赖项前，请阅读 ~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md。 如果文件缺失或仍包含占位符，请停止并运行 /ip-legal:cold-start-interview。执业配置文件会告知你：

• 该团队由谁负责 OSS 审查（通常由工程团队负责，并由法务签字确认）
• Copyleft 义务的升级处理路径
• 需要预先添加的工作成果页眉

如果执业配置文件中上传了 OSS 政策，也请阅读——它是团队接受哪些许可证、哪些许可证需要审查以及哪些许可证被禁止的权威依据。

工作流

步骤 1：审查范围是什么？

询问（或根据用户提供的信息推断）：

我们要审查什么？

1. 依赖项列表——package.json、requirements.txt、go.mod、Gemfile、Cargo.toml、pom.xml、SBOM（SPDX / CycloneDX）、锁文件
2. 单个库——你正在考虑添加的某个特定包
3. 我们自己的代码——我们计划将其开源，需要检查其中包含的内容

分析路径有所不同：

• 依赖项列表 → 对每一项进行分类，汇总义务
• 单个库 → 对一个包进行分类，并在有信息时检查其传递依赖项
• 对外发布代码 → 检查其中包含的内容（直接和传递依赖项），检查所选的对外发布许可证是否与所有内含许可证兼容，并检查 LICENSE / NOTICE 文件是否正确

步骤 2：部署模式是什么？

在许可证列表之后，这是最重要的输入——同一个库会根据软件的交付方式产生不同的义务。请询问：

软件将如何部署？

1. SaaS / 托管服务——用户通过网络访问；不会向用户交付任何内容
2. 分发二进制文件——我们向用户交付编译后的代码（桌面应用、移动应用、本地部署服务器、CLI 工具）
3. 仅限内部使用——仅在公司内部使用，不对外分发
4. 嵌入式 / 固件——随硬件交付，或作为封闭系统固件交付

部署方式	实质上需要关注的许可证
SaaS	AGPL（网络触发条款）、任何 UI 中的宽松许可证署名要求、将软件改作竞争性服务时适用的 SSPL/BUSL/Elastic
分发二进制文件	GPL、LGPL、MPL、EPL（均在分发时触发义务）、宽松许可证署名要求
仅限内部使用	大多数 Copyleft 义务不会触发——因为没有分发。遵守宽松许可证的署名要求仍是良好做法。如果公司外部的用户通过网络交互，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]]

Copyleft 依赖是如何被使用的？ 链接关系决定了 copyleft 是否会实际触发。请询问或确定：

• 静态链接 / 一起编译： 作品合并为一个二进制文件。强烈表明 copyleft 会触发（LGPL 中的“基于该库的作品”、GPL 衍生作品）。
• 动态链接 / 共享库： 作品在运行时仍可分离。LGPL 明确允许这种方式（“使用该库的作品”）。GPL 的立场存在争议（FSF 认为属于衍生作品，其他人持不同意见）。
• 包含头文件 / 内联函数： 根据包含内容的多少，可能产生衍生作品。
• 子进程 / IPC： 不同进程通过定义明确的接口通信。通常不构成衍生作品。
• 网络 API 调用： 对大多数许可证而言，不会。对于 AGPL，网络交互条款意味着通过网络提供该软件即属于分发。在微服务架构中，即使 AGPL 组件位于 API 后端，也仍会触发。
• 文件级 copyleft（MPL）： 只有被修改的文件受 copyleft 约束，而非整个作品。请确认是否修改了任何受 copyleft 约束的文件。

严重程度评级取决于此。 如果没有链接分析，只说“LGPL — 弱 copyleft，链接规则因情况而异”，工程师可能因此吃上官司。在专有产品中静态链接 LGPL 属于 🔴 严重。在专有产品中动态链接 LGPL 则属于 🟢 低。同一许可证，评级却截然相反。

严重程度校准：

级别	含义
🔴 严重	在会触发强 copyleft 义务的部署模式中使用强 copyleft（例如，在分发的二进制文件中使用 GPL，或在 SaaS 中使用 AGPL）。业务模式与之实际冲突的非 OSI 许可证（例如，我们正在构建托管服务，却使用 SSPL）。许可证无法确定，且该软件包不可或缺。
🟠 高	团队尚未为之做好准备的弱 copyleft 义务（文件级披露、NOTICE 要求）。采用双重许可，但所选许可证不明确。许可证文件与代码头部声明不一致。
🟡 中	需要署名但尚未纳入构建流程的宽松许可证（缺少 NOTICES 文件、分发时缺少 LICENSE）。传递性 copyleft 所处的使用方式可能触发也可能不触发，具体取决于如何使用该库。
🟢 低	义务已履行的宽松许可证。在不会触发 copyleft 的部署模式中使用 copyleft 许可证（例如，仅在内部使用 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]

决策原则

如果无法有把握地对许可证进行分类，请标记为 “需要审查”——不要将其称为宽松许可证。低估许可证风险是一条单行道：基于默认宽松假设作出的发布决定，可能在数月后演变为源代码公开义务或禁令。过度标记则是双向道——律师可以在审查中缩小清单范围。

同样，如果 copyleft 触发条件分析取决于有争议的问题（AGPL 的“通过网络交互”、GPL-3.0 的“传递”、LGPL 链接的范围），请标记为需要律师审查，并列出双方的考量因素。

交付前的质量检查

• 已加载执业资料及任何 OSS 政策
• 在分类义务之前，已确定部署模式
• 每项依赖项均已分类，并在可行时涵盖传递依赖项
• 已标记许可证未知的软件包，而非默认归为宽松许可证
• 对任何 copyleft 或非 OSI 发现，均已阅读许可证文本（而不只是元数据）
• 已为引用添加来源标签；未删除任何 verify 标签
• 已根据执业资料指定审批人
• 输出已添加工作成果标题

以接下来的步骤决策树收尾

按照 CLAUDE.md ## Outputs 中的要求，以接下来的步骤决策树收尾。根据此技能刚刚生成的内容自定义选项——五个默认分支（起草 X、升级处理、获取更多事实、观察并等待、其他事项）只是起点，并非固定选项。决策树就是输出；由律师选择。

如果扫描发现的软件包超过约 10 个，或用户有任何要求：提供仪表板（参见 CLAUDE.md ## Outputs → Dashboard offer for data-heavy outputs）。根据此处的实际需求设计仪表板内容——按许可证类别（宽松型 / 弱著佐权 / 强著佐权 / AGPL / 专有 / 未知）统计数量、风险分布，以及包含严重程度和软件包版本的发现项表格。