许可证合规检查是什么
扫描依赖的许可证类型，识别 GPL、AGPL 等与分发方式相关的条款；在构建阶段生成清单，对策略外许可证阻断或转人工评审。检查对象要覆盖直接依赖与全部传递依赖，策略按白名单、灰名单、黑名单分类处理。输出清单随制品归档，支撑法务复核，也是审计时的直接证据。
基本信息
| 常见工具 | FOSSA、license_finder、ORT、pip-licenses |
|---|---|
| 检查对象 | 直接依赖与传递依赖 |
| 策略 | 白名单、灰名单、黑名单分类处理 |
| 输出 | 许可证清单随制品归档，支持法务复核 |
| 时机 | 构建阶段自动扫描，发布前形成结论 |
典型使用场景
- 发布门禁：发现黑名单许可证即阻断构建
- 法务评审：灰名单许可证转人工确认
- AGPL 核查：网络服务场景确认源码开放义务是否可接受
- 新依赖引入：合入前自动检出许可证类型
- 归档追溯：每个发行版本对应一份许可证清单
- 多语言覆盖：不同生态各用工具，汇总到统一策略
生成依赖许可证清单
生成依赖许可证清单
pip-licenses --format=csv --with-urls > licenses.csv # Python 依赖清单
npx license-checker --summary # Node 依赖摘要
# CI 里把结果与策略清单比对，未批准项退出非零码阻断
# 输出随制品归档，保证每个版本都能追溯到当时的结论策略分级读法
| 名单 | 处理 | 说明 |
|---|---|---|
| 白名单 | 直接放行 | 宽松条款类许可证 |
| 灰名单 | 转人工评审 | 视使用方式而定的条款 |
| 黑名单 | 阻断构建 | 与分发方式冲突的强传染条款 |
| 未识别 | 按最严格处理 | 保守默认，不静默放行 |
AGPL 与网络服务场景相关：对外提供服务时需确认履行源码开放义务的方式。
扫描要覆盖传递依赖：直接依赖许可证没问题，不代表依赖的依赖也没问题。
策略清单是团队资产：白灰黑名单要有人维护，更新走评审与版本控制。