开源许可证合规审查是确保企业在使用、修改或分发开源软件时遵守相关许可证条款的关键流程。以下是详细的审查步骤和注意事项：

1. 识别开源组件

• 清单管理：使用工具（如FOSSology、Black Duck、SCA工具）扫描代码库，生成所有开源组件的详细清单，包括直接和间接依赖项。
• 版本记录：明确每个组件的版本号，因为不同版本可能适用不同许可证。

2. 许可证分类与风险评级

• 常见许可证分类：
  • 宽松型（MIT、Apache 2.0、BSD）：允许自由使用，需保留版权声明。
  • 弱Copyleft（LGPL）：允许动态链接闭源代码，但修改部分需开源。
  • 强Copyleft（GPL、AGPL）：衍生作品必须开源，AGPL还要求网络服务提供源码。
• 高风险场景：GPL代码与专有代码静态链接可能触发“传染性”条款。

3. 义务分析

• 常见合规要求：
  • 声明版权与许可证：在软件文档或界面中注明原作者信息（如MIT要求）。
  • 提供源码：GPL要求分发时提供完整可构建的源码（包括修改部分）。
  • 专利授权：Apache 2.0明确授予专利使用权。
  • 独立通知文件：汇总所有第三方许可证（如Android的NOTICE文件）。

4. 代码交互审查

• 动态链接 vs 静态链接：
  • LGPL允许动态链接闭源代码，但静态链接可能需开源衍生代码。
• 衍生作品判定：修改GPL代码或与其紧密耦合的代码可能被视为衍生作品，需全部开源。

5. 自动化工具辅助

• 推荐工具：
  • ScanCode：识别代码中的许可证声明。
  • SPDX：标准化许可证信息格式。
  • GitHub依赖图/Dependabot：监控依赖项的许可证变更。

6. 制定合规流程

• 内部政策：
  • 设立开源审查委员会，审批新引入的开源组件。
  • 禁止高风险许可证（如GPL）用于核心专有代码。
• 文档化：记录每个组件的许可证、义务及合规措施（如源码分发方式）。

7. 分发与商业化注意事项

• SaaS场景：AGPL要求提供网络服务时公开修改后的源码，需谨慎评估。
• 双重许可：部分项目（如MySQL）提供商业许可选项，可绕过Copyleft限制。

8. 持续监控

• 依赖更新：定期检查依赖项是否更新许可证（如React从BSD+专利条款改为MIT）。
• 法律咨询：复杂情况（如多许可证兼容性）需专业律师介入。

常见陷阱

• 忽略间接依赖：通过npm/pip安装的库可能引入GPL依赖。
• 混淆许可证版本：GPL-2.0与GPL-3.0条款差异显著。
• 未履行通知义务：遗漏版权声明可能导致法律风险。

通过系统化的审查流程，企业可有效降低法律风险，同时充分利用开源生态的优势。对于关键项目，建议结合自动化工具与法律专家意见，确保全面合规。