开源协议企业实战与常见误区
# 企业实战与常见误区
# 一、企业引入第三方库：合规清单
在项目里 npm install 或 go get 之前，先问三个问题：
# 1.1 检查清单
| 步骤 | 做什么 | 工具 |
|---|---|---|
| 1 | 扫描所有依赖的协议类型 | license-checker / FOSSA |
| 2 | 标记 GPL/AGPL 依赖（高风险） | 人工审查 |
| 3 | 检查协议兼容性 | SPDX 兼容矩阵 |
| 4 | 创建 NOTICE 文件汇总（Apache 要求） | 手动 |
| 5 | CI 中加入协议检查步骤 | GitHub Actions |
# 1.2 实操：扫描 npm 项目
# 安装工具
npm install -g license-checker
# 查看所有依赖的协议
license-checker --summary
# 输出示例：
# ├─ MIT: 423
# ├─ Apache-2.0: 87
# ├─ ISC: 56
# ├─ BSD-2-Clause: 23
# ├─ GPL-3.0: 1 ← 🔴 高风险！人工审查这个
2
3
4
5
6
7
8
9
10
11
12
# 1.3 实操：Go 项目
# 安装 govulncheck 或使用 go-licenses
go install github.com/google/go-licenses@latest
go-licenses report ./...
2
3
# 1.4 GitHub Actions 自动化
# .github/workflows/license-check.yml
name: License Check
on: [push, pull_request]
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm ci
- run: npx license-checker --summary --failOn "GPL;AGPL"
# 有 GPL 依赖就直接 CI 失败
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 二、企业开源自己的项目：选型流程
Step 1：确定归属
├── 个人项目 → 选 MIT 或 GPL（凭个人偏好）
└── 公司项目 → 通常要求 Apache 2.0（法务要求）
Step 2：确定目标
├── 最大化使用率 → MIT
├── 需要专利保护 → Apache 2.0
├── 防止竞品白嫖 → GPL v3
└── 云服务 → AGPL
Step 3：补充文件
├── LICENSE → 必选
├── NOTICE → Apache 2.0 必选
├── CONTRIBUTING → 推荐（贡献指南）
├── CODE_OF_CONDUCT → 推荐（行为准则）
└── CLA/DCO → 大项目需要（贡献者协议）
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 2.1 CLA 与 DCO
| CLA（Contributor License Agreement） | DCO（Developer Certificate of Origin） | |
|---|---|---|
| 是什么 | 法律文件，需要签署 | git commit -s 加一行 |
| 复杂度 | 高，需要律师 | 低，自动化 |
| 代表项目 | Google、Apache 基金会 | Linux 内核、K8s |
| 目的 | 确保贡献者授权公司/基金会使用其代码 | 证明贡献者有权利贡献 |
# 三、常见误区
# 误区一：GitHub 上公开的代码就可以随便用
错。 没有 LICENSE 文件的代码默认"All Rights Reserved"——保留所有权利。GitHub 公开 ≠ 开源。
2017 年，有人从 GitHub 无 License 项目中复制代码用于商业项目，原作者起诉侵权，胜诉。
# 误区二：MIT 协议不需要署名
错。 MIT 明确要求保留版权声明。"署名"不是"必须在产品上写名字"，而是你必须保留 LICENSE 文件。
# 误区三：修改 GPL 代码但没发布就不违规
对。 GPL 传染只在分发时触发。内部使用不需要开源。但一旦分发给外部，触发传染。
例外：AGPL 下，即使通过 SaaS 提供服务也算分发。
# 误区四：用了 MIT 库，作者负责 bug 导致的损失
错。 几乎所有开源协议都包含"AS IS"免责声明。MIT 写得最直白：
"THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND"
# 误区五：Apache 2.0 和 GPL v2 兼容
错。 Apache 2.0 和 GPL v2 不兼容。但 Apache 2.0 和 GPL v3 兼容。
兼容性速查：
| MIT | Apache 2.0 | GPL v2 | GPL v3 | MPL 2.0 | |
|---|---|---|---|---|---|
| MIT | ✅ | ✅ | ✅ | ✅ | ✅ |
| Apache 2.0 | ✅ | ✅ | ❌ | ✅ | ✅ |
| GPL v2 | ✅ | ❌ | ✅ | ❌ | ❌ |
| GPL v3 | ✅ | ✅ | ❌ | ✅ | ✅ |
| MPL 2.0 | ✅ | ✅ | ❌ | ✅ | ✅ |
# 误区六：修改了一行 GPL 代码，可以用 MIT 重新发布
错。 GPL 的传染性要求衍生作品也必须用 GPL。修改一行 = 衍生作品。
# 误区七：选择 CC 协议适用于代码
错。 Creative Commons（CC）协议是为图片、文档、音视频等非软件作品设计的。软件请用 MIT/Apache/GPL 等专用软件协议。
# 四、云服务的协议漏洞与对策
# 4.1 GPL 的 SaaS 漏洞
你的产品用 GPL 代码做了个服务，部署在自己服务器上
→ 客户通过网络访问你的服务
→ 你没有"分发"软件给客户
→ GPL 传染不触发 ✅（法律上你赢了）
→ 你可以闭源你的整个服务
2
3
4
5
# 4.2 如何堵漏洞
如果你希望即使以 SaaS 形式提供，别人也必须开源：
→ 用 AGPL（Affero GPL）
如果你希望云厂商不能把你的开源软件做成云服务卖钱：
→ 用 SSPL（Server Side Public License，MongoDB 的选择）
或 BSL（Business Source License）
2
3
4
5
6
# 4.3 MongoDB 的教训
2018 年，AWS 基于 MongoDB 社区版（AGPL）推出了 DocumentDB——一个兼容 MongoDB 的云服务。AWS 没有修改 MongoDB 代码，只是做了兼容层，合法避开了 AGPL。
MongoDB 随后将协议改为 SSPL（Server Side Public License）：如果你提供该软件的服务，你必须开源整个服务栈（包括管理软件、API、监控等）。 这比 AGPL 更激进，但因此被 OSI 拒绝认定为"开源协议"。
# 五、快速决策矩阵
| 你的情况 | 推荐协议 |
|---|---|
| 个人小工具，无所谓 | MIT |
| 公司项目，需专利保护 | Apache 2.0 |
| 基础库，希望最大化使用 | MIT / Apache 2.0 |
| 核心产品，防竞品白嫖 | GPL v3 |
| 云服务，防云厂商白嫖 | AGPL |
| 混合开源/闭源 | MPL 2.0 |
| 学术机构 | BSD 3-Clause |
| 完全放弃 | Unlicense |
| 不确定 | MIT |
# 六、总结
| 原则 | 说明 |
|---|---|
| 默认选 MIT | 90% 场景够用 |
| 公司项目选 Apache 2.0 | 法务更喜欢 |
| GPL 是武器，也是枷锁 | 你用 GPL，别人也用 GPL，生态兼容性是问题 |
| 没有 License ≠ 开源 | 别人不能合法使用 |
| LICENSE + NOTICE | Apache 2.0 的两个必备文件 |
| 做一次依赖扫描 | 别等被告了才发现依赖里有 GPL |
