企业开源合规该如何自查？

本文目录导读：

1. 第一阶段：摸底与资产盘点（搞清楚“家底”）
2. 第二阶段：合规分析与风险分级（搞清楚“风险”）
3. 第三阶段：执行合规措施（解决“怎么改”）
4. 第四阶段：建立常态化机制（解决“以后怎么办”）
5. 一份快速自查清单
6. 最后的建议

企业开源合规自查是一个系统性工程,核心目标是确保企业在使用、修改、分发开源代码时，满足相应开源许可证（License）的要求，避免法律和商业风险。

以下是一套分阶段、可操作的自查框架和步骤指南：

第一阶段：摸底与资产盘点（搞清楚“家底”）

这是最基础也最繁杂的一步,你需要全面梳理所有软件产品中涉及的开源代码。

1. 扫描代码库（核心动作）：

   • 工具推荐： 使用自动化工具进行扫描，效率远高于人工，主流工具包括：
     • 商业工具： Black Duck (Synopsys)、FOSSA、Snyk、WhiteSource (Mend)。
     • 开源工具： FOSSology、ScanCode、SW360、Trivy（主要做安全，也含License扫描）。
   • 扫描对象： 所有公司自研软件的源代码、外部引入的库、依赖包、SDK、甚至文档和配置文件。
   • 生成清单： 工具会生成一份软件物料清单（SBOM），你至少需要知道每个组件的：
     • 名称和版本号
     • 许可证类型（如 GPL, MIT, Apache 2.0, BSD, LGPL, MPL 等）
     • 来源（官方仓库、第三方供应商、内部开发）
     • 使用方式（直接使用、修改、静态链接、动态链接、作为依赖被引入）

2. 建立代码仓库黑/白名单：

   • 白名单： 允许使用的经过法务和工程部门共同认可的许可证和特定版本的库。
   • 黑名单： 严格禁止使用的许可证（如某些强Copyleft许可证，或无法兼容公司商业模式的许可证）。
   • 黄名单/待审名单： 需要法律或合规专家审查才能使用的许可证。

第二阶段：合规分析与风险分级（搞清楚“风险”）

拿到SBOM后,需要根据企业商业模式（尤其是是否开源/闭源、是否作为SaaS提供、是否商业分发）进行分析。

1. 许可证兼容性分析：

   • 核心问题： 你的代码的许可证与引入的开源组件的许可证是否冲突？
   • 常见冲突场景：
     • 你的商业/闭源软件静态链接了一个GPL 2.0的库，GPL 2.0要求整个衍生作品（你的软件）也必须开源并采用GPL许可，这是高风险。
     • 你的软件的核心是修改后的AGPL组件，AGPL在网络服务环境下也要求开源，如果你的产品是SaaS，这将直接影响商业模式。
     • 包含GPL和Apache 2.0的代码，需要检查具体条款（Apache 2.0兼容GPL 3.0但不兼容GPL 2.0）。

2. 风险等级划分（按使用方式）：

   • 高风险（通常不可接受）：
     • 在商业闭源软件中包含/链接强Copyleft许可证代码（GPL 2.0/3.0, AGPL 3.0）。
     • 修改了Copyleft代码并进行了二进制分发。
     • 使用了无许可证（No License）或禁止商用（Commons Clause, SSPL）的代码。
   • 中等风险（需要履行义务）：
     • 在商业软件中使用LGPL代码（通常允许动态链接，但需满足特定要求，如允许用户反向工程替换）。
     • 使用MPL 2.0（修改文件需开源，但其他部分可闭源）。
     • 网络分发 Copyleft代码（需提供源码）。
   • 低风险（通常较为安全，但需保留版权声明）：
     • 使用MIT, BSD-2/3, Apache 2.0, Unlicense等宽松许可证。
     • 唯一义务： 在软件文档中或About页面中保留原作者的版权声明和免责声明。

第三阶段：执行合规措施（解决“怎么改”）

确定风险后,针对每一个高风险或中风险组件，选择并执行合规策略。

1. 替换

   • 寻找一个许可证更宽松（如MIT, BSD, Apache 2.0）的替代库，实现相同功能。
   • 优点： 一劳永逸，风险最小。
   • 缺点： 可能需要大量开发工作。

2. 隔离

   • 将高风险代码作为一个独立的进程或服务,通过网络或IPC通信（而非代码层面的链接/派生）。
   • 原理： 大多数Copyleft许可证的定义中，独立的进程通信通常不视为“衍生作品”。
   • 注意： 这是灰色地带，需咨询法务。

3. 开源自有代码

   • 如果无法替换和隔离,且商业模式允许，将整个衍生作品（你的软件）以相同的自由开源许可证发布。
   • 适用场景： 追求社区影响力、开源商业模式、或SaaS服务（AGPL下需谨慎）。

4. 履行义务

   • 对于LGPL / MPL / 宽松许可证，最基本的要求是正确履行通知义务：
     • 保留版权声明： 在代码中 / 软件文档 / 关于页面中完整保留所有原作者的版权信息。
     • 提供许可证全文： 随软件分发一份LICENSE文件。
     • 提供修改说明： 如果修改了代码，需清晰标注修改时间、内容和作者。
     • 提供源代码： 如果是二进制分发了Copyleft代码，必须同时（或书面请求后）提供对应的源代码（或者对于LGPL，提供对象文件和链接所需的构建脚本）。

第四阶段：建立常态化机制（解决“以后怎么办”）

合规不是一次性任务,要融入研发流程。

1. 政策制定与宣贯：

   • 制定明确的《公司开源软件使用合规政策》。
   • 对全体研发人员进行培训,告知他们哪些许可证能用，哪些不行，以及引入新组件时的标准流程。

2. 流程集成（DevOps/CI-CD）：

   • 将SBOM扫描工具集成到你的Git仓库的CI/CD Pipeline中。
   • 当开发人员提交代码或引入新依赖时,自动扫描并阻断高风险许可证的引入。
   • 只有在“黄/待审”列表中的组件经过人工复审后，才允许通过。

3. 建立“责任到人”的清单：

   • 指定每个产品或业务线的开源合规负责人。
   • 明确SBOM的责任人（通常是架构师或技术负责人）和维护责任人（通常是法务或安全部门）。

4. 定期审计与复盘：

   • 每季度或每半年进行一次全面的代码库扫描和合规审计。
   • 更新黑/白名单，跟进新出现的许可证或法律判例。

一份快速自查清单

最后的建议

• 不要只依赖自动化工具。 工具能扫出License名字，但无法判断“派生”或“修改”的法律认定，重要决策（尤其是涉及GPL/AGPL的）必须让法务介入。
• 对于历史遗留项目（比如5年前的代码）， 逐行审查代码中所有#include / import / require语句，自己列一个手动清单，然后用工具对比，老项目往往是重灾区。
• 公司越小，越需要重视。 大公司有法务部兜底，小公司一旦被起诉（尤其是被SFC等组织盯上），可能直接导致业务停摆。

如果你能完成上述框架中的大部分步骤,你的企业开源合规水平就已经超过了绝大多数中小型公司。