name	oss-review
description	审查开源软件许可证合规性，识别 GPL/AGPL/LGPL 传染风险、专利报复条款、披露义务，适配中国《著作权法》《计算机软件保护条例》及 GPL 传染性司法认定规则（罗盒诉风灵案等）。
argument-hint	<SBOM/依赖清单文件路径或手动输入的依赖列表> [部署方式：独立分发/云服务(SaaS)/嵌入式/动态链接/静态链接]
user-invocable	true

开源软件许可证合规检查（中国法）

目标

对企业软件产品中使用的开源软件组件进行许可证合规审查，识别传染性风险、专利条款风险、披露义务、商标限制及与中国《著作权法》的冲突点，输出合规审查意见与整改建议。

核心法律依据

《著作权法》第3条（软件属于作品）、第14条（合作作品）、第53条（侵权）
《计算机软件保护条例》第9条（软件著作权归属）、第18-22条（许可/转让）
《民法典》合同编（开源许可证的合同性质）
《专利法》第11条（排他权）
《刑法》第217条（侵犯著作权罪，若违反开源许可证被认定为侵权）
司法判例：罗盒诉风灵案（广州知识产权法院，2019）—— GPL 传染性被认可；数字天堂诉柚子公司案——开源协议约束力

开源许可证分类体系

按传染性（Copyleft 强度）

类别	许可证	传染性	闭源商用友好度	说明
宽松型	MIT、BSD-2/3-Clause、Apache-2.0、ISC、木兰宽松许可证	无	⭐⭐⭐⭐⭐	可闭源商用，仅需保留版权声明
弱传染型	LGPL-2.1/3.0、MPL-2.0、EPL-2.0	有限	⭐⭐⭐⭐	修改后的库须开源，调用该库的主程序可闭源（LGPL 动态链接安全，静态链接有风险）
强传染型	GPL-2.0/3.0、AGPL-3.0、木兰公共许可证	强	⭐	任何包含/链接/修改的作品整体须开源；AGPL 额外覆盖网络交互（SaaS 也触发）
特殊型	CC0、Unlicense、WTFPL	公有领域	⭐⭐⭐⭐⭐	放弃所有权利，但不同法域效力不同
中国自主	木兰宽松许可证（MulanPSL-2.0）、木兰公共许可证（MulanPubL-2.0）	宽松/强	视版本	中英文双语，兼容 Apache-2.0/GPL

按专利条款

许可证	专利授权	专利报复条款	中国法风险
MIT	❌ 无	❌ 无	低
BSD	❌ 无	❌ 无	低
Apache-2.0	✅ 明示授权	✅ 有（提起专利诉讼则终止许可）	中（报复条款在中国法下效力未充分验证）
GPL-2.0	❌ 未明确	❌ 无	中
GPL-3.0	✅ 明示授权	✅ 有	中
AGPL-3.0	✅ 明示授权	✅ 有	高（SaaS 触发）
LGPL	同对应 GPL 版本	同对应 GPL 版本	中

前置门控（Bounce 模式）

若以下任一条件成立，须暂停当前任务并引导用户先行完成冷启动面试：

未检测到 CLAUDE.md 实践档案文件
CLAUDE.md 中 企业概况（第1节） 的关键字段为 [待填写]（如企业全称、行业领域、核心技术领域）
用户明确表示"尚未运行过冷启动面试"或"不确定 CLAUDE.md 是否存在"

引导话术：

⚠️ 实践档案未就绪

您的企业知识产权实践画像（CLAUDE.md）尚未建立或关键信息缺失。所有 skill 的输出质量高度依赖这份档案中的企业具体情况（技术领域、组合规模、审批权限、维权策略等）。

请先运行冷启动面试（约15-20分钟）：
/claude-for-legal-china-IP:cold-start-interview
完成后重新执行本命令。若您是首次使用本插件，跳过此步骤是输出质量差的最常见原因。

若 CLAUDE.md 已就绪，继续执行以下步骤。

执行前准备

读取 CLAUDE.md 确认：
- 开源软件管理政策（允许/审查/禁止清单）
- 源代码披露审批流程（CTO+保密办联合审批）
- 审批权限（GPL/AGPL 使用须知识产权总经理 + CTO 特批）
获取软件物料清单（SBOM）：
- 推荐格式：SPDX、CycloneDX、SWID
- 来源：包管理器导出（npm、pip、maven、gradle、go mod）、SCA 工具（Black Duck、FOSSology、Snyk）
- 最小信息：组件名称、版本、许可证标识（SPDX ID）、来源仓库

执行步骤

Step 1: SBOM 解析与许可证识别

标准化解析：
- 读取 SBOM 文件（JSON/XML/CSV）
- 识别每个组件的许可证标识
- 对"双许可"（Dual License）组件，标记须选择的许可方案
- 对"许可证冲突"组件（如同时标 MIT 和 GPL），标记须澄清
许可证归一化：
- 将非标准许可证声明映射至 SPDX 标准标识符
- 标记"未知许可证"（Unknown License）组件
- 标记"自定义许可证"（Proprietary/Custom）组件
漏洞关联（可选但建议）：
- 关联 CVE 数据库，识别高风险漏洞组件
- 高风险漏洞 + 宽松许可证：建议升级
- 高风险漏洞 + 强传染许可证：评估替换方案

Step 2: 传染路径分析

2.1 使用方式判定

使用方式	定义	GPL 传染风险	LGPL 传染风险
独立进程/微服务	通过 IPC/网络协议通信	无	无
动态链接	运行时加载共享库（.so/.dll/.dylib）	中（有争议，GPL FAQ 认为无；但保守策略视为有风险）	无
静态链接	编译时链接进可执行文件	高（确定传染）	高（修改后的库须开源）
源码修改后编译	修改开源代码后重新编译	高（确定传染）	高（修改后的库须开源）
头文件包含	包含 GPL 头文件（C/C++）	高（若包含大量内联代码）	视情况而定
Java/Python 导入	import/package 引用	低（通常视为动态链接）	低
SaaS/云服务调用	服务器端调用 AGPL/GPL 组件，用户通过网络使用	AGPL: 高（确定触发）；GPL: 视解释（保守视为高）	AGPL: 高
容器镜像包含	Docker 镜像中包含 GPL 组件	高（若为静态链接或紧密集成）	视集成方式

2.2 传染边界分析

关键问题：我们的闭源软件是否因使用了某开源组件而"被传染"？

分析框架：

组件关系图：绘制闭源主程序与所有开源组件的调用/链接关系
通信协议：若通过标准网络协议（HTTP/REST/gRPC）通信，通常不传染
数据格式：仅交换数据（JSON/XML）通常不传染
共享地址空间：在同一进程地址空间内运行，传染风险高

中国司法实践参考：

罗盒诉风灵案（广州知识产权法院，2019）：法院认可 GPL 许可证的合同约束力，违反 GPL 的再分发行为构成违约/侵权
数字天堂诉柚子公司案：法院认可开源协议的约束力
启示：中国法院倾向于将开源许可证视为有效合同，违反许可证义务（如未开源）可能承担法律责任

Step 3: 专利条款风险评估

3.1 Apache-2.0 专利条款分析

条款内容（第3条）：

贡献者向用户授予专利权许可
专利报复：若用户提起专利诉讼主张该开源作品或其衍生作品侵犯其专利，则该用户的 Apache-2.0 许可终止

中国法风险：

专利报复条款在中国法下尚未有明确司法判例确认其效力
保守策略：假设该条款有效，避免在使用 Apache-2.0 组件的同时起诉该组件或其贡献者专利侵权
若企业拥有与 Apache-2.0 组件相关的专利，须评估专利报复触发风险

3.2 GPL 专利条款分析

GPL-2.0：未明确专利授权，但第7条隐含"不得增加额外限制"
GPL-3.0：第11条明确专利授权，第10条包含专利报复
风险：使用 GPL 组件的企业，若起诉该组件贡献者专利侵权，可能丧失 GPL 许可

Step 4: 披露义务检查

许可证	保留版权声明	提供许可证全文	提供源代码	修改声明	商标限制
MIT	✅	✅	❌	❌	❌
BSD-3-Clause	✅	✅	❌	❌	✅
Apache-2.0	✅	✅	❌	✅（须声明修改）	✅
GPL-2.0/3.0	✅	✅	✅（完整源代码或书面提供源代码要约）	✅	❌
AGPL-3.0	✅	✅	✅（网络交互用户也须获得源代码）	✅	❌
LGPL	✅	✅	✅（修改后的库源代码）	✅	❌
MPL-2.0	✅	✅	✅（修改后的文件源代码）	✅	❌

常见违规情形：

删除了源代码中的版权声明
未随软件分发许可证副本
GPL 组件未提供源代码下载链接或书面要约
修改 GPL 代码后未声明修改内容和日期

Step 5: 中国自主许可证支持

5.1 木兰宽松许可证（MulanPSL-2.0）

中英文双语，无需额外翻译
兼容 Apache-2.0
无专利报复条款
允许闭源商用
建议：优先选用木兰宽松许可证替代 MIT/Apache-2.0（尤其政府项目）

5.2 木兰公共许可证（MulanPubL-2.0）

中英文双语
类似 GPL-2.0 的强传染性
无专利报复条款
建议：如需强传染许可证，优先考虑木兰公共许可证以规避 GPL 专利报复风险

Step 6: 输出《开源软件合规审查意见书》

# 开源软件合规审查意见书

## 一、审查范围
- **产品名称**：
- **版本号**：
- **审查日期**：YYYY-MM-DD
- **SBOM 来源**：
- **组件总数**：[X] 个
- **涉及许可证类型**：[列出所有许可证]

## 二、组件风险分级清单

### 🔴 高风险（须立即整改）
| 组件名 | 版本 | 许可证 | 使用方式 | 风险说明 | 整改建议 |
|:---|:---|:---|:---|:---|:---|
| | | AGPL-3.0 | SaaS 后端调用 | 触发传染性，须整体开源或替换 | 替换为 MIT/Apache 替代方案 |
| | | GPL-3.0 | 静态链接 | 确定传染闭源代码 | 改为动态链接或替换 |

### 🟡 中风险（须关注并采取缓解措施）
| 组件名 | 版本 | 许可证 | 使用方式 | 风险说明 | 缓解措施 |
|:---|:---|:---|:---|:---|:---|
| | | LGPL | 静态链接 | 修改后的库须开源 | 改为动态链接；若已修改，开源修改后的库 |
| | | Apache-2.0 | 核心模块 | 专利报复条款 | 评估企业相关专利布局，避免起诉该组件贡献者 |

### 🟢 低风险（合规，仅需履行披露义务）
| 组件名 | 版本 | 许可证 | 披露义务 | 完成状态 |
|:---|:---|:---|:---|:---|
| | | MIT | 保留版权声明 | □ 已完成 □ 待完成 |

## 三、专利条款专项评估
| 组件 | 许可证 | 专利报复风险 | 评估结论 | 建议 |
|:---|:---|:---|:---|:---|
| | Apache-2.0 | 中 | [结论] | [建议] |

## 四、整改计划
| 优先级 | 组件 | 整改措施 | 责任人 | 完成期限 | 验证方式 |
|:---|:---|:---|:---|:---|:---|
| P1 | | 替换为 [替代组件] | 研发经理 | [日期] | 重新运行 SCA 扫描 |
| P2 | | 改为动态链接 + 开源修改版 | 研发工程师 | [日期] | 代码评审 |
| P3 | | 补充版权声明和许可证副本 | 法务助理 | [日期] | 发布包检查 |

## 五、持续合规建议
1. 在 CI/CD 流程中集成 SCA 扫描（如 FOSSology、Snyk、Black Duck）
2. 建立开源软件准入清单：允许/审查/禁止三级
3. 定期（每季度）扫描产品 SBOM，识别新引入组件
4. 对高风险组件建立替代方案库

## 六、审批
- **审查人**：AI 辅助系统
- **复核人**：________________（研发经理）
- **审批人**：________________（知识产权总经理 + CTO，如涉 GPL/AGPL）
- **日期**：________________

特别注意事项

GPL 与 SaaS 的灰色地带：
- GPL-2.0/3.0 的"分发"（distribute）是否包含 SaaS 网络提供，业界存在争议
- 保守策略：SaaS 中使用 GPL 组件视为"分发"
- AGPL-3.0 明确覆盖：通过计算机网络远程交互的用户有权获得源代码
- 建议：SaaS 产品中避免使用 GPL/AGPL 组件，除非准备整体开源
微服务架构下的传染边界：
- 若 GPL 组件运行在独立微服务中，主程序通过 REST API 调用，通常认为不传染
- 但须确保微服务自身合规（提供源代码）
- 若微服务与主程序共享内存或进程空间，风险升高
容器与虚拟化：
- Docker 镜像中包含 GPL 组件，若该组件与闭源应用紧密集成（同一容器、共享文件系统），可能触发传染
- 建议：将 GPL 组件置于独立容器，通过标准网络接口通信
政府项目的开源合规：
- 政府软件项目越来越多要求使用国产开源或自主可控软件
- 木兰系列许可证（MulanPSL/MulanPubL）是中国自主开源许可证，在政府项目中具有合规优势
- 注意：使用 GPL 组件的政府项目，若被要求开源，可能涉及国家秘密或敏感信息的披露风险——须提前评估
开源合规与商业秘密的交叉：
- 若企业闭源代码中使用了 GPL 组件，GPL 要求开源的"衍生作品"是否包含企业的商业秘密代码？
- 这是一个复杂问题，保守策略：避免将核心商业秘密算法与 GPL 代码编译在同一可执行文件中
- 建议核心算法以独立进程/微服务形式部署，通过加密通信与 GPL 组件交互
违反开源许可证的法律责任：
- 民事责任：停止侵权、赔偿损失（可参照著作权侵权标准）
- 违约责任：开源许可证被视为合同，违反许可证义务构成违约
- 刑事责任：若情节严重，可能触犯《刑法》第217条侵犯著作权罪（但开源软件侵权入刑案例极少）
- 商誉风险：开源社区公开谴责、GPL 合规诉讼（如罗盒案）