审查依赖清单/SBOM/单个库或拟开源代码的 OSS…

在需要判断依赖或自有代码的许可证家族、copyleft 触发义务、许可证兼容性与发布/开源前行动项时，结合部署模型输出可执行合规备忘录。

适用场景

解决思路

1. 读取 `~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md`；若仍有占位符，停止并提示：先运行 `/ip-legal:cold-start-interview`，说明需要先了解 practice profile（以及 OSS policy，如有）才能审查。
2. 如果 practice profile 指向已上传的 OSS policy，也读取该政策；它是团队接受/需审查/禁止许可证的权威来源。
3. 确定审查范围：依赖清单（`package.json`、`requirements.txt`、`go.mod`、`Gemfile`、`Cargo.toml`、`pom.xml`、SBOM、lockfile）、单个库，或团队准备开源的 outbound code；若用户传入路径则从文件推断，否则询问。
4. 按范围选择分析路径：依赖清单→逐项分类并汇总义务；单个库→分类该包，并在可用时遍历其传递依赖；outbound code→检查直接和传递嵌入项，检查所选开源许可证是否与所有嵌入许可证兼容，检查 `LICENSE` / `NOTICE` 是否正确。
5. 在分类义务前确定部署模型：SaaS / hosted service、distributed binary、internal only、embedded / firmware；同一依赖清单在不同部署模型下触发不同义务。
6. 在备忘录中标注部署模型；按模型关注重点：SaaS 看 AGPL 网络触发、UI 中的 permissive attribution、若改造成竞争服务看 SSPL/BUSL/Elastic；distributed binary 看 GPL、LGPL、MPL、EPL 的分发触发和 permissive attribution；internal only 多数 copyleft 因无分发不触发，但外部用户通过网络交互时 AGPL 仍触发，permissive attribution 仍作为良好实践；embedded/firmware 看 GPL 的源代码披露、可复现构建、安装信息等难点，需在发布前规划。
7. 对每个包确定许可证：读取实际许可证文本，不只读元数据；因为 `LICENSE` 文件可能错误、包管理器元数据可能过期。
8. 将每个包分类为 permissive、weak copyleft、strong copyleft、public domain / dedication、non-OSI source-available、other/custom/unknown。
9. permissive：例如 MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0、ISC、Zlib、Unlicense；关键义务是署名、保留许可证文本，Apache-2.0 另有专利授权 + `NOTICE` 要求。
10. weak copyleft：例如 LGPL-2.1、LGPL-3.0、MPL-2.0、EPL-1.0、EPL-2.0、CDDL；关键义务是文件级或库级源代码披露，链接规则不同。
11. strong copyleft：例如 GPL-2.0、GPL-3.0、AGPL-3.0、OSL、EUPL（视版本）；关键义务是广泛源代码披露，AGPL 延伸到网络使用。
12. public domain / dedication：例如 CC0、Unlicense、WTFPL；通常无义务，但在不承认公共领域奉献的司法辖区有争议。
13. non-OSI source-available：例如 SSPL、BUSL、Commons Clause、Elastic License、Confluent Community、fair-source 家族；不是开源，限制商业使用、竞争服务使用或两者，需读具体许可证。
14. other / custom / unknown：例如厂商特定、专有、缺少许可证文件、文件与头声明冲突；停止，不要默认 permissive。
15. 标记特殊情况：双许可证包——使用哪个许可证？选择可能改变义务；已弃用包——是否不再维护、是否有支持替代；自身树中含 copyleft 依赖的包——顶层许可证 permissive 但传递依赖 copyleft；近期变更许可证的包——Redis、MongoDB、Elastic、HashiCorp——确认固定版本处在你认为的许可证下。
16. 将义务映射到部署模型：对每个已分类依赖，写明部署模型触发的义务。输出块包含：`[package@version] — [License]`、分类、针对本部署模型（SaaS / binary / internal / embedded）的义务 checklist、风险等级（🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low）、建议（Comply with obligations / Replace with [alternative] / Remove / Attorney review before shipping / Seek commercial license from [vendor]）。
17. 判断 copyleft 依赖如何被消费，因为它决定 copyleft 是否触发：静态链接/一起编译→合并为一个二进制，强信号触发（LGPL 的 “work based on the Library”、GPL 的 derivative work）；动态链接/共享库→运行时仍可分离，LGPL 明确允许（“work that uses the Library”），GPL 立场有争议（FSF 认为衍生，其他人不同意）；头文件包含/内联函数→根据包含量可能构成衍生；子进程/IPC→通过定义良好的接口通信的独立进程，通常不是衍生；网络 API 调用→对多数许可证不是，但对 AGPL 网络交互条款意味着通过网络提供服务即分发，微服务架构中 API 后面的 AGPL 组件仍会触发；文件范围 copyleft（MPL）→只有修改过的文件携带 copyleft，不是整个作品，检查是否有 copyleft 文件被修改。
18. 按严重程度校准：🔴 Critical：在会触发的部署中混入 strong copyleft（如 distributed binary 中的 GPL、SaaS 中的 AGPL）；商业模式实际冲突的 non-OSI（如构建托管服务时用 SSPL）；无法确定许可证且该包承担关键功能。🟠 High：weak copyleft 且团队未准备好义务（文件级披露、`NOTICE` 要求）；双许可证中选择的许可证不明确；`LICENSE` 文件说一套、头声明说另一套。🟡 Medium：permissive 有署名要求但未接入构建（缺 `NOTICES` 文件、分发中缺 `LICENSE`）；传递 copyleft 的位置可能触发也可能不触发，取决于消费方式。🟢 Low：permissive 且义务已满足；copyleft 处于不触发的部署模型（如仅内部使用且不再分发的 GPL 库）。
19. 在备忘录顶部标记失败模式：许可证未知——归类为 “needs review”，不要归为 permissive；许可证文件与文件头冲突——两者都读并报告冲突；不兼容组合——GPL-2.0 only + Apache-2.0 历史上已知不兼容，仔细检查 MPL / EPL / GPL 组合；冒充开源的 non-OSI 许可证——SSPL、BUSL、Commons Clause、Elastic License、Confluent Community；不要依赖 GitHub 的 “open source” 徽章；许可证变更——若旧版本 permissive 而当前版本 source-available，固定版本很重要。
20. 若审查的是准备开源的自家代码，执行 outbound check：确认所选 outbound license 与每个嵌入依赖的许可证兼容（例如嵌入 GPL 代码后不能以 MIT 发布，组合作品必须 GPL）；确认 `LICENSE` 文件存在且正确；确认 `NOTICE` 文件存在并列出所需署名（Apache-2.0 等）；确认按要求打包第三方许可证文本；确认仓库历史中没有专有或机密代码、客户数据、嵌入凭据；确认项目名称的商标和品牌政策（与版权许可证分开）。
21. 组装备忘录：按 `~/.claude/plugins/config/claude-for-legal/ip-legal/CLAUDE.md` → `## Outputs` 前置 work-product header（因用户角色不同）。备忘录和被审查的依赖清单可能享有特权、保密或两者兼有；输出继承来源状态；只在特权圈内分发；对外交付前（包括把备忘录附到特权圈外的工程 ticket 前）去掉 work-product header。
22. 执行 no silent supplement：若对配置的法律研究工具的研究查询对备忘录所需规则（某司法辖区 AGPL 网络触发可执行性、GPL-3.0 专利授权范围、近期重许可包的最新许可证文本）返回很少或没有结果，报告发现并停止；不要在未询问时用 web search 或模型知识补空白；提示选项：(1) 扩大搜索查询，(2) 换一个研究工具，(3) 搜索网页——结果标记 `[web search — verify]` 并应与一手来源核对后再依赖，(4) 标记为未验证并停止；由律师决定是否接受低置信来源。
23. 做来源归属：备忘录引用许可证文本、解释许可证的法院判决或 steward 指引（FSF、OSI、SPDX、SFLC）时打标签：`[OSI]`、`[SPDX]`、`[FSF]`、`[SFC/SFLC]`、`[Westlaw]`，来自 connector 的引用用 MCP 工具名；web search 用 `[web search — verify]`；训练数据回忆用 `[model knowledge — verify]`；直接从仓库读取的许可证文本用 `[user provided]`；带 `verify` 的引用伪造风险更高；永远不要剥离或合并标签。
24. 使用指定备忘录模板：work-product header；`# OSS Review: [Project / Dependency List / Package]`；Reviewed 日期；Scope；Deployment model；Bottom line（两句话：能否发布？先做什么？）；Packages reviewed 数量；By classification 数量；Issues 计数；Approval needed from（按 practice profile）；Top-of-memo flags；By package（按严重程度分组的 Step 4 块）；Jurisdiction note；Outbound check（如适用）；Approval routing。
25. 在 jurisdiction note 中说明：OSS 许可证可执行性因司法辖区而异——AGPL 网络触发尚未广泛在法院测试；GPL-3.0 专利条款在美国与欧盟专利法下解读不同；公共领域奉献并非普遍被承认；说明下游分发（如包含该代码的供应商协议）的管辖法律选择，并标记 practice profile 标为 escalate 的辖区。
26. 遵守 decision posture：许可证无法自信分类时标为 “needs review”，不要称为 permissive；低估许可证风险是单向门——基于默认 permissive 假设做出的发布决定，可能数月后变成源代码披露义务或禁令；过度标记是双向门——律师可在审查中缩小列表。
27. 当 copyleft 触发分析取决于争议问题（AGPL 的 “interacts over a network”、GPL-3.0 的 “conveying”、LGPL 链接范围）时，标记律师审查并呈现正反两方面因素；任何标为 strong copyleft 或 license-unknown 的内容，必须在依赖发布或代码发布前交由律师。
28. 把结果定位为 first-pass classification：copyleft 分析取决于部署模型、链接程度、司法辖区及未在法院测试的法律问题（尤其 AGPL 的 “interacts over a network”、GPL-3.0 专利条款）；strong copyleft 或 license-unknown 由律师在依赖发布或代码发布前评估；skill 只报告发现，律师决定行动。
29. 交付前质量检查：practice profile 和 OSS policy 已加载；在分类义务前已确定部署模型；每个依赖都有分类，包括可获得的传递依赖；license-unknown 包被标记而非默认 permissive；任何 copyleft 或 non-OSI 发现都读取了许可证文本而不只是元数据；来源标签已应用且没有剥离 `verify` 标签；按 practice profile 命名审批人；输出标记 work-product header。
30. 结尾提供 next-steps decision tree：按 CLAUDE.md `## Outputs` 以 next-steps decision tree 结束；按本 skill 刚产出的内容定制选项；五个默认分支（draft the X、escalate、get more facts、watch and wait、something else）是起点而非锁定；decision tree 就是输出，由律师选择。
31. 若扫描发现超过约 10 个包，或用户要求，提供 dashboard（见 CLAUDE.md `## Outputs → Dashboard offer for data-heavy outputs`）；按此处有用内容塑造：按许可证家族计数（permissive / weak copyleft / strong copyleft / AGPL / proprietary / unknown）、风险分布、含严重程度和包版本的发现表。
32. 连接 ticketing 系统时（Jira、Linear、Asana）：监控传入 OSS 请求，在 ticket 中直接回复指导（标记信息不完整、要求 repo 链接、返回 license-family 分类），并跨请求跟踪 clearance 状态；无 connector 时，一次处理一个：粘贴 ticket 或描述请求；见 repo 根目录 `CONNECTORS.md` 了解如何添加 ticketing connector。
33. 处理 matter context：检查 practice-level CLAUDE.md 中的 `## Matter workspaces`；若 `Enabled` 为 `✗`（内部用户的默认值），跳过其余段落——skills 使用 practice-level context，matter machinery 不可见；若启用且没有 active matter，询问：“Which matter is this for? Run `/ip-legal:matter-workspace switch <slug>` or say `practice-level`.”；加载 active matter 的 `matter.md` 获取 matter-specific context 和 overrides；输出写入 matter 文件夹 `~/.claude/plugins/config/claude-for-legal/ip-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，否则绝不读取另一个 matter 的文件。
34. 支持调用示例：`/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）。

适用边界 · 注意事项

• 未加载或无法加载 practice profile / OSS policy 时，不要直接扫描出结论；若缺少或仍有占位符，先运行 `/ip-legal:cold-start-interview`。
• 不适合作为最终法律意见或替代律师对 strong copyleft、license-unknown、争议条款的审阅；这些必须在发布前升级。
• 不适合在没有部署模型或无法确定审查范围/清单时强行分类；先补齐部署模型和审查对象。