企业开源合规自查 Checklist (2025版)

适用对象： CTO、技术总监、法务合规官
使用说明： 建议每季度进行一次自查，并在大版本发布前强制执行“发布阶段”检查。

检查项 ID	检查内容	风险等级	状态 (Yes/No)	备注
G-01	公司内部是否有明确的《开源软件使用管理规范》？	⭐⭐⭐	⬜	需明确白名单（MIT/Apache）与红名单（AGPL/WTFPL）。
G-02	是否设立了开源合规负责人或虚拟小组（OSPO）？	⭐⭐	⬜	至少需一名研发主管兼任。
G-03	是否对研发团队进行了开源协议（License）基础培训？	⭐⭐	⬜	避免因为不懂而随意 Copy 代码。
G-04	是否建立了开源组件的“引入审批流程”？	⭐⭐⭐	⬜	尤其是引入 GPL 类组件是否经过 CT O/法务签字？

检查项 ID	检查内容	风险等级	状态 (Yes/No)	备注
D-01	是否禁止开发人员直接将 Github 代码片段复制粘贴到私有仓库？	⭐⭐⭐	⬜	这是一个极其隐蔽的风险点。
D-02	引入 GPL/LGPL 组件时，是否做好了物理隔离？	⭐⭐⭐	⬜	关键：确保通过 IPC/API 调用，而非静态/动态链接。
D-03	是否记录了所有依赖包的来源 URL 和版本号？	⭐	⬜	用于生成 SBOM（软件物料清单）。
D-04	是否修改了开源组件的源代码？	⭐⭐	⬜	若修改了 GPL 代码，必须向社区回馈源码。

检查项 ID	检查内容	风险等级	状态 (Yes/No)	备注
R-01	是否使用工具（如 SCANOSS/BlackDuck）进行了全量代码扫描？	⭐⭐⭐	⬜	必须项，人工检查不可靠。
R-02	扫描出的高危协议（High Risk）是否已全部修复或获得豁免？	⭐⭐⭐	⬜	严禁带病上线。
R-03	产品发布包中是否包含了 `NOTICE` 文件和 `LICENSE` 文件？	⭐⭐	⬜	履行 Apache/MIT 的署名义务。
R-04	针对 GPL 组件，是否提供了“源码下载链接”或“源码获取说明”？	⭐⭐⭐	⬜	未提供源码获取途径是 GPL 诉讼的主要把柄。
R-05	是否检查了 UI 素材（字体、图标）的开源授权？	⭐	⬜	字体侵权同样高发。