开源协议精讲 / 第十章：合规实务

第十章：合规实务

引言

理解开源许可证是一回事，在实际项目中做到合规是另一回事。本章将介绍企业级开源合规的实务操作：如何建立合规流程、维护许可证声明、审计第三方依赖、处理合规问题。

10.1 合规的基本原则

10.1.1 开源合规的三大支柱

开源合规三支柱
├── 知识产权（IP）
│     ├── 确认有权使用所有代码
│     ├── 识别和管理许可证
│     └── 处理专利和商标问题
├── 许可证义务
│     ├── 源代码公开（GPL/AGPL）
│     ├── 署名和声明（MIT/BSD/Apache）
│     ├── 修改标注（Apache 2.0）
│     └── 传染性管理（Copyleft）
└── 流程和治理
      ├── 引入审批流程
      ├── 持续监控
      ├── 事件响应
      └── 人员培训

10.1.2 合规义务分类

10.1.3 合规风险等级

低风险：
├── MIT / BSD / ISC（仅需保留声明）
└── CC0 / Unlicense（几乎无要求）

中风险：
├── Apache-2.0（需要 NOTICE 文件 + 修改标注）
├── LGPL（需要确保可替换性）
└── MPL（需要开源修改的文件）

高风险：
├── GPL（需要开源衍生作品）
├── AGPL（SaaS 也需要开源）
└── 自定义许可证（法律不确定性）

10.2 许可证声明文件

10.2.1 LICENSE 文件

每个开源项目都应包含 LICENSE 文件：

项目根目录/
├── LICENSE          # 主许可证文件
├── LICENSES/        # 多许可证时的目录
│   ├── Apache-2.0.txt
│   ├── MIT.txt
│   └── GPL-3.0.txt
└── NOTICE           # Apache 2.0 要求的声明文件

LICENSE 文件内容示例：

MIT License

Copyright (c) 2024 Your Company

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

10.2.2 NOTICE 文件

Apache 2.0 要求保留原始项目的 NOTICE 文件，并在你的修改版本中添加信息：

NOTICE 文件示例：

Apache Foo Library
Copyright 2020-2024 The Apache Software Foundation

This product includes software developed at
The Apache Software Foundation (https://www.apache.org/).

This product includes code from the Bar Project.
Licensed under the MIT License.
Copyright 2019 John Doe.

10.2.3 第三方许可证清单

为项目中的所有第三方组件维护一份许可证清单：

# 第三方许可证清单

## 直接依赖

| 组件 | 版本 | 许可证 | 来源 |
|------|------|--------|------|
| express | 4.18.2 | MIT | https://github.com/expressjs/express |
| mongoose | 7.0.0 | MIT | https://github.com/Automattic/mongoose |
| lodash | 4.17.21 | MIT | https://github.com/lodash/lodash |

## 间接依赖（需要关注）

| 组件 | 版本 | 许可证 | 来源 | 风险 |
|------|------|--------|------|------|
| some-gpl-lib | 1.0.0 | GPL-2.0 | ... | 需评估 |

## 许可证统计

| 许可证 | 数量 |
|--------|------|
| MIT | 45 |
| Apache-2.0 | 12 |
| BSD-3-Clause | 8 |
| ISC | 5 |
| GPL-2.0 | 1 |

10.2.4 源代码头部声明

建议在每个源文件头部添加许可证声明：

/*
 * Copyright 2024 Your Company
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

10.3 第三方依赖管理

10.3.1 依赖审查清单

在引入新依赖前，完成以下审查：

第三方依赖审查清单
│
├── 基本信息
│     ├── 组件名称：_______________
│     ├── 版本：_______________
│     ├── 来源：_______________
│     └── 活跃度：_______________
│
├── 许可证信息
│     ├── 主许可证：_______________
│     ├── 是否 OSI 批准：□ 是 □ 否
│     ├── 与项目许可证兼容：□ 是 □ 否 □ 待评估
│     └── 传染风险：□ 无 □ 低 □ 中 □ 高
│
├── 安全信息
│     ├── 已知 CVE：_______________
│     ├── 最后安全更新：_______________
│     └── 维护状态：_______________
│
└── 决策
      ├── □ 批准引入
      ├── □ 需要法律审查
      ├── □ 拒绝引入
      └── 批准人：_______________

10.3.2 依赖许可证扫描

# Node.js 项目
npm install -g license-checker
license-checker --production --json > licenses.json

# Python 项目
pip install pip-licenses
pip-licenses --format=json --with-urls > licenses.json

# Java 项目（Maven）
mvn license:aggregate-third-party-report

# Go 项目
go-licenses csv ./... > licenses.csv

# Rust 项目
cargo install cargo-deny
cargo deny check licenses

10.3.3 自动化合规检查

# GitHub Actions - 许可证合规检查
name: License Compliance
on: [push, pull_request]

jobs:
  check-licenses:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies
        run: npm ci

      - name: Check licenses
        run: |
          npx license-checker --production --failOn "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL-1.0"

      - name: Generate license report
        run: |
          npx license-checker --production --json > license-report.json

      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: license-report
          path: license-report.json

10.3.4 许可证策略配置

// license-checker-config.json
{
  "allowed": [
    "MIT",
    "BSD-2-Clause",
    "BSD-3-Clause",
    "Apache-2.0",
    "ISC",
    "0BSD",
    "CC0-1.0",
    "Unlicense",
    "Zlib"
  ],
  "restricted": [
    "LGPL-2.1",
    "LGPL-3.0",
    "MPL-2.0",
    "EPL-2.0"
  ],
  "prohibited": [
    "AGPL-3.0",
    "SSPL-1.0",
    "GPL-2.0",
    "GPL-3.0"
  ]
}

10.4 GPL 合规实务

10.4.1 分发 GPL 软件的义务

如果你分发包含 GPL 代码的软件，必须：

GPL 合规检查清单
│
├── 提供源代码
│     ├── 分发时同时提供
│     ├── 或提供书面要约（有效期 3 年）
│     └── 源代码必须完整、可编译
│
├── 保留声明
│     ├── 版权声明
│     ├── 许可证文本
│     └── 保修免责声明
│
├── 传染性管理
│     ├── 识别所有 GPL 衍生作品
│     ├── 确保以 GPL 发布
│     └── 记录衍生关系
│
└── 文档化
      ├── 维护源代码清单
      ├── 记录修改历史
      └── 提供获取说明

10.4.2 源代码提供方式

GPL 要求提供"对应源代码"（Corresponding Source），有以下几种方式：

书面要约示例：

源代码获取说明

本产品包含受 GNU 通用公共许可证（GPL）保护的组件。
您可以通过以下方式获取对应的源代码：

方式一：在线下载
访问 https://github.com/yourcompany/yourproduct/releases
下载与您使用版本对应的源代码包。

方式二：书面请求
发送邮件至 opensource@yourcompany.com
注明您需要的产品版本和联系方式。
我们将在 3 个工作日内提供源代码。

方式三：邮寄请求
寄送至：[公司地址]
附上回邮信封和邮资。

10.4.3 Linux 内核模块的合规

Linux 内核使用 GPL-2.0-only，内核模块的合规是一个特殊话题：

Linux 内核模块合规

选项 1：使用 GPL 许可证
└── 最安全的合规方式

选项 2：使用 MODULE_LICENSE("Dual BSD/GPL")
└── 表示接受 GPL 条件

选项 3：仅声明专有许可证
└── 模块可以加载，但：
    ├── 不能使用 GPL-only 符号
    ├── 内核会标记为 "tainted"
    └── 存在法律争议

选项 4：用户空间驱动
└── 通过用户空间接口与内核通信
    └── 不受 GPL 传染

10.4.4 AGPL 的 SaaS 合规

如果你通过网络提供包含 AGPL 代码的服务：

AGPL SaaS 合规要求

1. 提供源代码
   └── 包含所有修改的 AGPL 代码

2. 明确声明
   └── 告知用户 AGPL 许可证

3. 提供下载
   └── 网络用户可获取源代码

4. 整体传染
   └── 如果与 AGPL 代码构成衍生作品
       └── 整个服务也必须以 AGPL 发布

10.5 Apache 2.0 合规实务

10.5.1 合规检查清单

Apache 2.0 合规清单

必须完成：
├── 保留原始版权声明
├── 保留 LICENSE 文件
├── 保留 NOTICE 文件（如果有）
├── 在修改的文件中标注修改内容
├── 不使用商标/名称进行背书
└── 保留保修免责声明

建议完成：
├── 创建自己的 NOTICE 文件
├── 记录所有修改
└── 维护第三方组件清单

10.5.2 修改标注

Apache 2.0 要求在修改的文件中标注：

/*
 * Copyright 2024 Original Author
 *
 * Licensed under the Apache License, Version 2.0
 *
 * Modifications:
 * 2024-01-15 Your Name - Added feature X
 * 2024-02-20 Your Name - Fixed bug in function Y
 */

10.6 审计工具与流程

10.6.1 开源审计流程

开源审计流程

阶段 1：准备
├── 确定审计范围
├── 收集代码和依赖清单
└── 确定审计标准

阶段 2：扫描
├── 使用扫描工具分析代码
├── 识别所有许可证
├── 检测潜在的许可证冲突
└── 生成初步报告

阶段 3：人工审查
├── 审查扫描结果
├── 验证许可证判断
├── 评估兼容性问题
└── 标记需要关注的组件

阶段 4：报告
├── 生成审计报告
├── 列出所有发现的问题
├── 提供合规建议
└── 制定修复计划

阶段 5：修复
├── 处理不合规项
├── 更新许可证声明
├── 移除或替换问题组件
└── 验证修复结果

阶段 6：持续监控
├── 建立自动化检查
├── 定期重新扫描
├── 更新许可证策略
└── 培训开发团队

10.6.2 审计工具对比

10.6.3 审计报告模板

# 开源许可证审计报告

## 项目信息
- 项目名称：_______________
- 版本：_______________
- 审计日期：_______________
- 审计工具：_______________

## 摘要
- 总组件数：___
- 许可证分布：
  - MIT: ___
  - Apache-2.0: ___
  - GPL: ___
  - 其他: ___

## 风险评估
| 风险等级 | 数量 | 组件 |
|---------|------|------|
| 高 | ___ | 列表... |
| 中 | ___ | 列表... |
| 低 | ___ | 列表... |

## 发现的问题
1. [问题描述]
   - 组件：___
   - 许可证：___
   - 建议：___

## 合规建议
1. [建议内容]

## 附录
- 完整组件清单
- 许可证文本

10.7 企业合规治理

10.7.1 OSPO（开源项目办公室）

大型企业通常设立 OSPO（Open Source Program Office）负责开源治理：

OSPO 职责
├── 制定开源策略
├── 管理开源合规
├── 审批开源使用
├── 管理对外贡献
├── 处理许可证问题
├── 培训开发团队
└── 维护与社区的关系

10.7.2 开源引入审批流程

开源组件引入流程

开发人员提出申请
    │
    ▼
自动许可证扫描
    │
    ├── 自动批准（白名单）
    │     └── 记录并引入
    │
    ├── 需要审查
    │     │
    │     ▼
    │   技术审查
    │     │
    │     ▼
    │   法律审查（如需要）
    │     │
    │     ▼
    │   批准/拒绝
    │
    └── 自动拒绝（黑名单）
          └── 通知并建议替代

10.7.3 贡献者协议

企业对外贡献开源代码时的管理：

对外贡献管理

1. 确认有权贡献
   ├── 不包含公司机密
   ├── 不包含第三方知识产权
   └── 获得必要批准

2. 检查 CLA/DCO
   ├── 需要签署 CLA？（如果项目要求）
   ├── 使用 DCO（Developer Certificate of Origin）
   └── 了解贡献的许可证含义

3. 代码审查
   ├── 技术质量
   ├── 无敏感信息泄露
   └── 符合公司政策

4. 提交
   └── 按项目规范提交

10.8 合规事件处理

10.8.1 常见合规问题

10.8.2 合规事件响应流程

合规事件响应

1. 发现问题
   └── 来源：审计、社区报告、法律通知

2. 评估影响
   ├── 严重程度
   ├── 影响范围
   └── 法律风险

3. 制定方案
   ├── 立即修复
   ├── 法律应对
   └── 沟通计划

4. 执行修复
   └── 按方案执行

5. 总结改进
   ├── 分析根因
   ├── 改进流程
   └── 更新培训

10.8.3 实际案例

案例：BusyBox 诉讼

背景：BusyBox 的开发者多次起诉违反 GPL 的公司
案例：2007-2012 年间提起多起诉讼
结果：大多数在庭外和解

教训：
- GPL 合规不是可选项
- 即使是嵌入式软件也必须合规
- 开发者有权利也有意愿执行 GPL

10.9 本章小结

扩展阅读

1. Linux 基金会 - 开源合规手册：https://www.linuxfoundation.org/resources/open-source-compliance
2. OpenChain 项目：https://www.openchainproject.org/
3. SPDX 合规指南：https://spdx.dev/
4. FSF GPL 合规指南：https://www.gnu.org/licenses/gpl-faq.html
5. Software Freedom Conservancy - GPL 合规：https://sfconservancy.org/copyleft-compliance/
6. TODO Group - OSPO 指南：https://todogroup.org/

上一章：SPDX 标准与工具 下一章：专利与开源