--- name: ip-oss-review description: 面向中国法的开源许可证合规审查，对依赖清单、单一组件或对外开源代码进行许可证分类、义务映射与风险标记；当用户需要审查SBOM或依赖清单的copyleft义务、判断组件能否随产品发布、或准备代码对外开源时使用 argument-hint: "[清单文件路径 | SBOM | 包名 | 代码仓库路径 | 粘贴文本]" --- # /oss-review-cn 依据团队实务配置文件中的实务画像，对开源许可证进行合规审查。按许可证族分类依赖项，将义务映射到部署模式，标记许可证未知和冒充开源的非OSI组件，给出行动建议——合规、替换、移除、寻求法律审查、寻求商业许可。 ## 使用说明 1. **加载团队实务配置。** 若配置文件缺失或仍为占位符，停止并提示："请先完成实务画像配置——我需要在审查前了解团队的实务画像（及OSS策略，如有）。" 若实务画像指向已上传的OSS策略，一并读取——该策略是团队接受/需审查/禁止许可证的权威来源。 2. **确定审查范围：** 依赖清单（package.json、requirements.txt、go.mod、Gemfile、Cargo.toml、pom.xml、SBOM），单一组件，或团队准备对外开源的自有代码。若用户传入了路径，从文件推断；否则询问。 3. **在分类义务前确定部署模式**——SaaS、分发二进制、仅内部使用、嵌入式。同一依赖清单在不同部署模式下触发不同义务。 4. **按下方工作流执行。** 特别注意： - 阅读实际许可证文本，而非仅看元数据——LICENSE文件可能有误，包元数据可能过时。 - 将每个包分类为宽松型/弱copyleft/强copyleft/公共领域/非OSI/未知。 - 将许可证未知标记为"需审查"，而非默认视为宽松型。 - 标记非OSI源可用许可证（SSPL、BUSL、Commons Clause、Elastic License、fair-source）——这些不是开源软件。 - 对外开源代码，检查所选对外许可证是否与所有嵌入依赖的许可证兼容。 5. **按下方模板输出备忘录**——工作成果抬头、底线结论、顶部标记、按严重度分组的逐包清单、中国法域注释、对外开源检查（如适用）、审批路由。 6. **遵守决策姿态。** 当copyleft触发分析取决于争议问题时（AGPL的"网络交互"与中国法下"信息网络传播权"的关系、GPL-3.0的"传达"与中国法下"发行权"的对应、LGPL链接范围），标记为律师审查并列出双方因素。任何被标记为强copyleft或许可证未知的组件，须在依赖随产品发布或代码开源前由律师评估。 ## 示例 ``` /oss-review-cn ~/code/my-project/package.json /oss-review-cn ~/code/my-project/requirements.txt /oss-review-cn redis /oss-review-cn ~/code/my-project # 仓库根目录——扫描所有清单文件 ``` --- ## 协作扩展 OSS合规审查请求通常通过工单系统提交。连接Jira、Linear或Asana后，本技能可以：监控入站OSS请求，直接在工单中回复指引（标记信息不完整、索要仓库链接、返回许可证族分类），并跨请求追踪审查状态。 未连接时，粘贴工单或描述请求，逐条处理。 ## 事项上下文 **事项上下文。** 检查实务配置中的"事项工作区"设置。若为"未启用"（内部用户的默认值），跳过本段——技能使用实务级上下文，事项机制不可见。若已启用且无活动事项，询问："这是哪个事项的？切换到对应事项或说明使用实务级上下文。" 加载活动事项的事项文件获取事项特定上下文和覆盖。输出写入事项文件夹。除非"跨事项上下文"已开启，否则不读取其他事项的文件。 --- ## 目的 告知用户依赖树中有哪些许可证，这些许可证在给定部署方式下触发哪些义务，以及针对每个许可证应采取什么行动。输出是一份律师（或有律师访问权的工程师）可据以行动的备忘录——合规、替换、移除、寻求法律审查、寻求商业许可。 **这是首轮分类。** Copyleft分析取决于部署模式、链接程度、法域，有时取决于未经司法检验的法律问题（尤其是AGPL的"网络交互"与中国法下"信息网络传播权"的关系、GPL-3.0专利条款在中国专利法下的解读）。任何被分类为强copyleft或许可证未知的组件，须在依赖随产品发布或代码开源前由律师评估。本技能报告发现；律师决定行动。 ## 前置条件：加载实务画像 **在扫描依赖前，读取团队实务配置文件。** 若缺失或仍含占位符，停止并提示先完成实务画像配置。实务画像告知你： - 团队中谁负责OSS审查（通常是工程团队加法务签字） - Copyleft义务的上报路由 - 需添加的工作成果抬头 若实务画像有已上传的OSS策略，一并读取——该策略是团队接受哪些许可证、哪些触发审查、哪些被禁止的权威来源。 ## 工作流 ### 步骤1：审查范围是什么？ 询问（或从用户提供的输入推断）： > 我们要审查什么？ > > 1. **依赖清单**——package.json、requirements.txt、go.mod、Gemfile、Cargo.toml、pom.xml、SBOM（SPDX/CycloneDX）、lockfile > 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"vs."分发二进制"审查会产生不同义务。 ### 步骤3：分类每个依赖 对每个包，确定许可证。阅读实际许可证文本，而非仅看元数据——LICENSE文件可能有误（文件写MIT但头文件写GPL；README声称Apache但没有许可证文件），包管理器元数据可能过时。 分类为： | 类别 | 示例 | 关键义务 | |---|---|---| | **宽松型** | MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0、ISC、Zlib、Unlicense | 署名、保留许可证文本，Apache-2.0附加专利授权+NOTICE要求 | | **弱copyleft** | LGPL-2.1、LGPL-3.0、MPL-2.0、EPL-1.0、EPL-2.0、CDDL | 文件级或库级源代码披露；链接规则各异 | | **强copyleft** | 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族 | 非开源——限制商业使用、竞争服务使用或两者兼有。阅读具体许可证。 | | **其他/自定义/未知** | 厂商特定、专有、缺少许可证文件、文件与头文件许可证冲突 | 停止——不要默认视为宽松型 | 标记： - **双许可包**——我们使用哪个许可证？选择可能改变义务。 - **已弃用包**——该包不再维护；是否有受支持的替代品？ - **传递依赖中含copyleft的包**——顶层许可证为宽松型但传递依赖为copyleft。 - **近期变更许可证的包**——Redis、MongoDB、Elastic、HashiCorp——确认所钉版本使用的许可证与预期一致。 ### 步骤4：将义务映射到部署模式 对每个已分类依赖，陈述部署模式触发的义务： ```markdown ### [package@version] — [许可证] **分类：** [宽松型 / 弱copyleft / 强copyleft / 公共领域 / 非OSI / 未知] **在我们的部署模式下的义务（[SaaS / 分发二进制 / 仅内部 / 嵌入式]）：** - [ ] [具体义务——例如："在随应用分发的NOTICES文件中包含署名"] - [ ] [例如："若修改并分发，公开我们修改部分的源代码"] - [ ] [例如："AGPL网络触发——若用户通过网络访问我们修改后的版本，须向其提供源代码"] **风险：** 严重 | 高 | 中 | 低 **建议：** [履行义务 | 替换为[替代品] | 移除 | 发布前律师审查 | 向[厂商]寻求商业许可] ``` > **copyleft依赖如何被消费？** 链接关系决定copyleft是否实际触发。询问或判断： > - **静态链接/一起编译：** 作品合并为一个二进制。强信号表明copyleft触发（LGPL"基于库的作品"、GPL演绎作品）。中国法下对应"改编权"和"复制权"的行使 [模型知识 — 需核验]。 > - **动态链接/共享库：** 作品在运行时保持可分离。LGPL明确允许（"使用库的作品"）。GPL立场有争议（FSF认为是演绎作品，其他人不认同）。 > - **头文件包含/内联函数：** 可能构成演绎作品，取决于包含量。 > - **子进程/IPC：** 独立进程通过明确定义的接口通信。通常不构成演绎作品。 > - **网络API调用：** 对大多数许可证，不触发。对**AGPL**，网络交互条款意味着通过网络提供软件即为中国法下的"信息网络传播"行为。在微服务架构中，API背后的AGPL组件仍触发。 > - **文件范围copyleft（MPL）：** 仅修改文件承担copyleft，而非整个作品。检查是否有copyleft文件被修改。 > > **严重度评级取决于此。** "LGPL——弱copyleft，链接规则各异"而不做链接分析，是让工程师承担法律风险的答案。专有产品中静态链接的LGPL为严重。动态链接的LGPL为低。同一许可证，评级相反。 **严重度校准：** | 级别 | 含义 | |---|---| | 严重 | 强copyleft在触发它的部署模式中（如分发二进制中的GPL，SaaS中的AGPL）。非OSI许可证与商业模式实际冲突（如SSPL用于托管服务）。无法确定许可证且该包为关键依赖。 | | 高 | 弱copyleft但团队未准备履行义务（文件级披露、NOTICE要求）。双许可但所选许可证不明确。许可证文件与头文件不一致。 | | 中 | 宽松型但署名要求未接入构建流程（缺少NOTICES文件、分发中缺少LICENSE）。传递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：组装备忘录 在备忘录前添加团队实务配置中的工作成果抬头。 本备忘录及所审查的任何依赖清单可能属于特权、保密或两者兼有。输出继承来源的该等属性。仅在特权圈内分发；在任何对外交付前（包括将备忘录附加到特权圈外的工程工单前）去除工作成果抬头。 > **无静默补充。** 若对备忘录所需规则的检索查询返回少量或无结果（AGPL网络触发在中国法下的可执行性、GPL-3.0专利条款在中国专利法下的范围、最近变更许可证包的最新许可证文本），报告发现结果并停止。不要未经询问从网络搜索或模型知识填补空白。说明："检索从[工具]返回[N]条结果。对[规则/许可证/法域]的覆盖似不足。选项：(1) 扩展检索查询，(2) 尝试不同检索工具，(3) 搜索网络——结果将标记为`[网络搜索 - 需核验]`且应在依赖前对照原始来源核实，(4) 标记为未核验并停止。请选择。" 律师决定是否接受较低置信度来源。 > > **来源标注。** 备忘录引用许可证文本、解释许可证的法院判决或管理组织指南时，标注引用来源：`[OSI]`、`[SPDX]`、`[FSF]`、`[SFC/SFLC]`、`[国家法律法规数据库]`、`[中国裁判文书网]`、`[元典法规]`、`[元典案例]`、`[监管机构官网]`，或从连接器检索的引用标注工具名；`[网络搜索 - 需核验]`用于网络搜索引用；`[模型知识 - 需核验]`用于从训练数据回忆的引用；`[用户提供]`用于直接从仓库读取的许可证文本。标注`需核验`的引用具有更高的编造风险。永远不要去除或合并这些标签。 ```markdown [工作成果抬头——按实务配置] # 开源审查：[项目 / 依赖清单 / 组件] **审查日期：** [日期] **范围：** [依赖清单 / 单一组件 / 对外开源代码] **部署模式：** [SaaS / 分发二进制 / 仅内部 / 嵌入式] --- ## 底线结论 [两句话。能否发布？发布前须完成什么？] **审查包数：** [N] **按分类：** [N宽松型, N弱copyleft, N强copyleft, N公共领域, N非OSI, N未知] **问题：** [N]严重 [N]高 [N]中 [N]低 **需审批人：** [姓名，按实务画像] --- ## 顶部标记 [许可证未知列表、许可证冲突列表、冒充开源的非OSI列表、不兼容组合] --- ## 逐包分析 [步骤4的清单，按严重度分组] --- ## 中国法域注释 中国法下开源许可证的可执行性依据： - 《中华人民共和国著作权法》（2020修正）第10条：发行权与信息网络传播权 - GPL类许可证的义务触发条件在中国法下对应"发行权"（分发场景）和"信息网络传播权"（网络交互场景），而非美国法下的"conveying"或"distribution" [模型知识 — 需核验] - AGPL的网络交互条款与中国法"信息网络传播权"的对应关系尚未经中国法院直接裁判确认 [模型知识 — 需核验] - 罗盒科技诉风灵科技案（2019）确认GPL在中国法下具有合同约束力，违反GPL条款构成著作权侵权 [中国裁判文书网] - 中国著作权法下，"放弃著作权"（如CC0）的效力存在争议——著作权中人身权（署名权等）不可放弃 [模型知识 — 需核验] - 《计算机软件保护条例》对软件著作权的特殊规定 - 《中华人民共和国专利法》对开源许可证中专利授权条款的解读 标注本项目任何下游分发的适用法律选择，并标记实务画像中标记为需上报的法域。 --- ## 监管合规（中国特有） 若项目涉及以下场景，需额外审查： - **关键信息基础设施**：使用开源组件需符合《网络安全法》《关键信息基础设施安全保护条例》的供应链安全要求 [模型知识 — 需核验] - **数据安全**：开源组件处理重要数据或个人信息的，需符合《数据安全法》《个人信息保护法》要求 [模型知识 — 需核验] - **出口管制**：含加密功能的开源组件可能受《出口管制法》约束——确认是否涉及管制物项 [模型知识 — 需核验] - **软件供应链安全**：参照《软件供应链安全要求》等相关标准，审查开源组件来源可信度和安全漏洞 [模型知识 — 需核验] --- ## 对外开源检查（如适用） [来自步骤6] --- ## 审批路由 [来自实务画像——谁审批，什么触发自动上报] ``` ## 资源索引 - 脚本:见 [scripts/run_evals.py](scripts/run_evals.py)(用途:运行5项评估测试，验证SKILL.md中的中国法适配指导和行为要求) - 参考:见 [references/cn-legal-sources.md](references/cn-legal-sources.md)(何时读取:需要中国法法律法规原文、案例引用、监管文件来源及效力状态时) - 参考:见 [references/intake.json](references/intake.json)(何时读取:需要了解本次中国法适配的提交登记信息、变更类型和来源引用时) - 参考:见 [references/notes.md](references/notes.md)(何时读取:需要了解中国法适配的具体变更内容、法律推演依据和待确认问题时) - 参考:见 [references/normal-case.md](references/normal-case.md)(何时读取:需要参考SaaS项目依赖清单审查的正常样例时) - 参考:见 [references/edge-case.md](references/edge-case.md)(何时读取:需要参考AGPL网络触发的边界样例时) ## 决策姿态 当许可证无法被确信分类时，标记为**"需审查"**——不要称为宽松型。低估许可证风险是单向门：基于宽松型默认假设做出的发布决策，可能数月后变成源代码披露义务或禁令。过度标记是双向门——律师在审查中收窄清单。 同样，当copyleft触发分析取决于争议问题时（AGPL的"网络交互"与中国法"信息网络传播权"的对应、GPL-3.0的"传达"与中国法"发行权"的映射、LGPL链接范围），标记为律师审查并列出双方因素。 ## 交付前质量检查 - [ ] 实务画像及任何OSS策略已加载 - [ ] 分类义务前已确定部署模式 - [ ] 每个依赖都有分类，包括可获取的传递依赖 - [ ] 许可证未知的包已标记，未默认为宽松型 - [ ] 对任何copyleft或非OSI发现已阅读许可证文本（而非仅元数据） - [ ] 引用已加来源标签；未去除`需核验`标签 - [ ] 审批人按实务画像指定 - [ ] 输出已标记工作成果抬头 - [ ] 中国法域注释已包含 - [ ] 监管合规章节（如触发）已包含 ## 以下一步决策树收尾 以实务配置中的下一步决策树结束。根据本技能产出的内容定制选项——五个默认分支（起草X、上报、补充事实、观察等待、其他）是起点而非锁定。决策树是输出；律师选择。 若扫描涉及超过约10个包，或用户随时询问：提供仪表盘（参见实务配置中的仪表盘提议）。根据此处有用的内容定制提议——按许可证族计数（宽松型/弱copyleft/强copyleft/AGPL/专有/未知）、风险分布、发现清单含严重度和包版本。