| 名称 | dependency-license-audit |
| 描述 | 当需要审查项目开源依赖许可证、判断能否商用分发或准备合规材料时使用。该技能汇总直接与传递依赖的许可证，按网络服务、内部工具、对外分发三种场景给出允许/条件允许/禁止结论，生成署名清单与替换建议。适用于商业软件发布、开源合规审查、供应链风险管理和采购尽调。关键词：开源许可证、License、合规、GPL、AGPL、MIT、Apache、BSD、MPL、传递依赖、SBOM、商用、分发、署名、NOTICE、供应链、许可证冲突。 |
开源依赖许可证审计
回答：这个项目能不能商用、能不能闭源分发、需要履行哪些义务。
何时使用
- 产品发布前需要出具开源合规结论。
- 引入新依赖，需要判断许可证风险。
- 收到许可证合规问询或客户尽调。
- 需要生成 SBOM 与署名清单。
不适用：专利侵权判断（需法务）；商业授权谈判。
输入
- 依赖清单：锁文件或 SBOM（CycloneDX / SPDX）。
- 使用场景：SaaS 服务、内部工具、桌面或嵌入式分发。
- 是否修改依赖源码、是否静态链接。
- 公司政策：黑白名单与豁免流程。
场景不明确时，按“对外分发 + 静态链接”从严评估。
工作流
第 1 步：收集全量依赖
- 直接依赖与传递依赖都要列出，传递依赖常被忽略。
- 记录名称、版本、来源、许可证声明、是否修改。
- 许可证缺失视为“未知”，按高风险处理，不能默认宽松。
第 2 步：归一化
把写法各异的声明映射为标准标识：
Apache License 2.0、Apache-2.0视为同一。BSD-3-Clause与BSD-2-Clause区分。- 双许可证（
MIT OR Apache-2.0）按有利分支选择，并在清单中注明。 - 自定义许可证需要人工阅读原文。
第 3 步：按场景判定
按 references/license-matrix.md 对照：
| 场景 | 关注点 |
|---|---|
| SaaS | AGPL、SSPL 触发网络分发义务 |
| 内部工具 | 分发义务通常不触发，但仍需遵守署名 |
| 对外分发（含静态链接） | GPL 类强传染，需开源或替换 |
| 嵌入式固件 | GPL 与静态链接组合风险最高 |
第 4 步：义务清单
对每个“条件允许”的依赖列出必须履行的义务：
- 保留版权声明与许可证文本。
- 附带 NOTICE 文件（Apache 类）。
- 标注修改过的文件。
- 提供对应源码（GPL/AGPL）。
- 不得使用商标。
第 5 步：处置
- 替换：寻找 Apache/MIT 许可的替代库。
- 隔离：拆成独立进程并通过接口调用，降低链接传染风险（需法务确认）。
- 采购：购买商业授权。
- 豁免：走公司豁免流程并登记期限。
第 6 步：持续监控
- 每次依赖升级重新扫描。
- 新引入依赖在 CI 中做许可证门禁。
- 对“未知许可证”单独立项清零。
检查清单
- [ ] 传递依赖已纳入统计。
- [ ] 许可证标识已归一化，双许可已选择并记录。
- [ ] 未知许可证已人工核实。
- [ ] 使用场景与链接方式已明确。
- [ ] 每个条件允许项都有对应义务与责任人。
- [ ] AGPL/SSPL 已评估网络服务触发条件。
- [ ] 署名与 NOTICE 已并入发布包。
- [ ] CI 门禁与升级重扫已配置。
输出模板
## 结论
可商用发布 / 条件允许 / 存在阻断项
## 风险清单
| 依赖 | 版本 | 许可证 | 场景结论 | 义务 | 处置 |
| --- | --- | --- | --- | --- | --- |
## 阻断项
- ...
## 署名清单
- 组件名 版本 许可证 版权方
## 后续
- 替换计划 / 豁免申请 / 监控机制
反模式
- 只看直接依赖，忽略传递依赖。
- 把“仓库里有 LICENSE 文件”当作合规完成。
- 认为 SaaS 不用管 GPL，忽略 AGPL 的网络条款。
- 静态链接 GPL 库后闭源分发。
- 许可证缺失时默认按 MIT 处理。
参考文件
references/license-matrix.md：常见许可证义务与场景结论。references/sbom-guide.md：SBOM 生成与署名清单实践。scripts/license_check.py：按策略文件批量判定依赖许可证。