开源协议精讲 / 第七章：双重授权与商业许可
第七章：双重授权与商业许可
引言
双重授权（Dual Licensing）是一种商业模式，允许开源项目同时提供两种或多种许可证——通常是开源许可证（如 GPL）和商业许可证。这种模式既保障了开源社区的自由，又为版权持有者创造了商业收入。
MySQL、Qt、MongoDB、Redis 等知名项目都曾或正在使用双重授权模式。
7.1 双重授权的概念
7.1.1 什么是双重授权？
双重授权是指版权持有者将同一软件以两种不同许可证发布：
软件 X
├── 开源版本（如 GPL）→ 免费，但有传染性
└── 商业版本（如 Proprietary License）→ 付费，无传染性
用户选择：
| 用户类型 | 选择 | 原因 |
|---|---|---|
| 开源项目 | GPL | 免费使用，接受 GPL 传染 |
| 商业闭源项目 | 商业许可 | 付费使用，避免 GPL 传染 |
7.1.2 双重授权的商业逻辑
┌─────────────────────────────────────────────────────┐
│ 双重授权的商业逻辑 │
├─────────────────────────────────────────────────────┤
│ │
│ 开源社区 ──→ 使用 GPL ──→ 增加用户基础 │
│ │ │ │
│ └──→ 贡献代码 ──→ 改进软件 ──┘ │
│ │
│ 商业公司 ──→ 不想接受 GPL ──→ 购买商业许可 │
│ │ │ │
│ └──→ 支付许可费 ──→ 支持项目发展 ──┘ │
│ │
└─────────────────────────────────────────────────────┘
7.1.3 前提条件
实施双重授权必须满足：
- 版权控制：你必须拥有所有代码的版权（或获得所有贡献者的授权）
- CLA（贡献者许可协议）：要求贡献者签署 CLA，将版权或许可权转让给项目方
- 没有第三方 GPL 代码：如果包含第三方 GPL 代码，不能以商业许可证发布
7.2 经典案例分析
7.2.1 MySQL 模式
MySQL 是双重授权最著名的案例之一。
| 项目 | 信息 |
|---|---|
| 公司 | MySQL AB（后被 Sun，再被 Oracle 收购） |
| 开源许可证 | GPL v2 |
| 商业许可证 | MySQL Commercial License |
| 收入来源 | 商业许可 + 技术支持 + 培训 |
MySQL 模式的运作方式：
场景 1：开源项目使用 MySQL
→ 使用 GPL 版本
→ 免费
→ 自己的代码也必须开源（GPL 传染）
场景 2：商业软件嵌入 MySQL
→ 不想开源自己的代码
→ 购买商业许可证
→ 支付许可费
场景 3：Web 应用使用 MySQL
→ GPL 不影响 SaaS（GPL v2 的"漏洞"）
→ 可以免费使用 GPL 版本
→ 不需要购买商业许可
7.2.2 Qt 模式
Qt 是另一个经典的双重授权案例。
| 项目 | 信息 |
|---|---|
| 公司 | Qt Company（原 Nokia/Qt Development Frameworks） |
| 开源许可证 | LGPL v3 / GPL v3 |
| 商业许可证 | Qt Commercial License |
| 特点 | 开源版可用于闭源（通过 LGPL） |
Qt 的授权策略：
Qt 开发
├── 开源项目 → 使用 LGPL/GPL 版本 → 免费
├── 闭源桌面应用 → 使用 LGPL 版本 → 免费（遵守 LGPL）
├── 闭源嵌入式 → 使用 LGPL 或商业版 → 视情况
└── 需要额外支持/功能 → 使用商业版 → 付费
7.2.3 MongoDB 模式的转变
MongoDB 的授权策略经历了重要转变：
| 时期 | 许可证 | 变化原因 |
|---|---|---|
| 早期 | AGPL | 防止 SaaS 搭便车 |
| 2018 | SSPL | 云服务商绕过 AGPL |
| 现在 | SSPL + 商业许可 | 双重授权 |
SSPL（Server Side Public License）：
MongoDB 创建的 SSPL 要求：
如果你将 MongoDB 作为服务提供给第三方，你必须开源整个服务栈（包括管理层、监控、存储等）。
SSPL 不是 OSI 批准的开源许可证，被许多社区视为"非开源"。
7.2.4 Redis 的策略调整
Redis 在 2024 年也进行了许可证调整：
| 时期 | 许可证 |
|---|---|
| 早期 | BSD |
| 2018 | SSPL + Apache 2.0（双重许可） |
| 2024 | RSALv2 + SSPL（双重许可） |
7.3 双重授权的法律基础
7.3.1 版权独占性
双重授权的前提是版权持有者拥有独占性版权：
版权持有者
├── 可以同时以多种许可证发布
├── 可以随时改变许可证（对新版本）
├── 可以授予他人不同的权利
└── 不受任何单一许可证约束（因为他是版权持有者）
7.3.2 贡献者许可协议（CLA）
为了实施双重授权，必须确保所有贡献者将版权或许可权转让给项目方：
CLA 的两种形式：
| 形式 | 说明 | 例子 |
|---|---|---|
| 版权转让 | 贡献者将版权完全转让 | FSF 的 GNU 项目 |
| 许可证授予 | 贡献者保留版权，但授予广泛的许可权 | Apache 基金会 |
CLA 示例条款：
贡献者特此授予项目方：
1. 不可撤销的、全球性的、免版税的版权许可
2. 以任何许可证（包括商业许可证）再许可的权利
3. 转让以上权利给第三方的权利
7.3.3 双重授权与 GPL 的关系
关键问题：如果一个项目使用 GPL，它还能提供商业许可吗？
答案：可以，但有条件。
情况 1：你是唯一的版权持有者
→ 你可以同时以 GPL 和商业许可证发布
→ 用户可以选择其中一个
情况 2：你和他人共同拥有版权
→ 需要所有版权持有者同意
→ 通常通过 CLA 实现
情况 3：你的代码包含第三方 GPL 代码
→ 你不能以商业许可证发布包含 GPL 代码的部分
→ 但你可以为你的原创部分提供商业许可
7.4 双重授权的商业策略
7.4.1 收入模式
| 模式 | 说明 | 例子 |
|---|---|---|
| 许可费 | 按使用量或公司规模收费 | MySQL、Qt |
| 技术支持 | 付费技术支持 | Red Hat |
| 企业版功能 | 额外的企业功能 | GitLab、Elastic |
| 托管服务 | 云托管版本 | MongoDB Atlas |
| 认证培训 | 官方认证 | Red Hat、LPI |
7.4.2 定价策略
定价因素：
├── 公司规模（开发者数量/营收）
├── 使用方式（内部/外部/嵌入式）
├── 支持级别（社区/标准/高级）
├── 功能范围（社区版/企业版）
└── 合同期限（年付/多年）
7.4.3 社区版 vs 企业版
| 版本 | 特点 | 目标用户 |
|---|---|---|
| 社区版 | 开源、免费、基本功能 | 个人开发者、小公司 |
| 企业版 | 商业许可、高级功能、支持 | 大型企业 |
GitLab 的例子：
GitLab 授权策略（调整后）
├── 社区版（CE）→ MIT + 其他开源许可
├── 企业版（EE）→ 商业许可
└── 核心功能 → 开源
高级功能 → 商业
7.5 Open Core 模式
7.5.1 什么是 Open Core？
Open Core（开放核心）是双重授权的一种变体：
Open Core 模式
├── 核心功能 → 开源（如 MIT、Apache 2.0）
└── 高级功能 → 商业许可
与传统双重授权的区别：
| 维度 | 传统双重授权 | Open Core |
|---|---|---|
| 代码关系 | 同一代码库 | 不同功能模块 |
| 开源版本 | 完整功能 | 核心功能 |
| 商业版本 | 无额外功能 | 高级功能 |
| 例子 | MySQL | GitLab、Elastic |
7.5.2 Open Core 的成功案例
| 公司 | 开源核心 | 商业扩展 |
|---|---|---|
| GitLab | CI/CD、版本控制 | 安全、合规、分析 |
| Elastic | Elasticsearch | X-Pack 功能 |
| Redis | 核心数据结构 | 模块、集群管理 |
| Grafana | 监控仪表板 | 企业告警、数据源 |
| HashiCorp | Terraform、Vault | 企业功能 |
7.5.3 Open Core 的争议
支持者观点：
- 创造了可持续的开源商业模式
- 核心功能仍然开放
- 企业版收入支持开源开发
反对者观点：
- “开源诱饵”（Open Bait）策略
- 企业版功能往往是用户最需要的
- 社区贡献被商业化利用
7.6 选型指南
7.6.1 何时选择双重授权
适合双重授权的项目：
├── 拥有完整的版权控制（或 CLA）
├── 有明确的商业用户需求
├── 社区足够活跃
├── 竞争对手较少
└── 有持续开发的资源
不适合双重授权的项目：
├── 包含大量第三方 GPL 代码
├── 贡献者众多且未签 CLA
├── 纯工具/库项目
└── 竞争激烈的领域
7.6.2 许可证组合选择
| 开源许可证 | 商业许可证 | 适用场景 |
|---|---|---|
| GPL | Proprietary | 最大化商业压力 |
| LGPL | Proprietary | 中等商业压力 |
| AGPL | Proprietary | 防止 SaaS 搭便车 |
| Apache 2.0 | 增值商业版 | Open Core 模式 |
| MIT | 企业支持 | 以服务为主要收入 |
7.6.3 实施步骤
1. 评估版权情况
└── 是否拥有完整版权？是否需要 CLA？
2. 选择许可证组合
└── 开源许可证 + 商业许可证
3. 建立 CLA 流程
└── 使用 CLA 工具（如 CLA Assistant）
4. 制定商业策略
└── 定价、功能划分、销售渠道
5. 社区沟通
└── 透明说明授权策略
6. 法律审查
└── 确保合规
7.7 常见问题
Q1：我可以用 GPL + 商业双重授权吗？
可以，但你必须：
- 拥有所有代码的版权
- 获得所有贡献者的授权（通过 CLA）
- 不包含第三方 GPL 代码（除非你也获得商业许可）
Q2：双重授权违反开源精神吗？
有争议。支持者认为它创造了可持续的商业模式；反对者认为它利用了社区贡献。关键是透明度和公平性。
Q3：SSPL 是开源许可证吗？
不是。SSPL 没有获得 OSI 批准，不满足开源定义（OSD）。使用 SSPL 的项目通常被称为"源码可用"（Source Available）而非"开源"。
Q4：如何从单许可证转向双重授权？
- 确保拥有完整版权
- 引入 CLA 流程
- 新版本以双重授权发布
- 旧版本保持原许可证
Q5：CLA 会吓跑贡献者吗？
可能会。一些开发者反对 CLA，认为它不公平地将权利集中于项目方。建议：
- 使用公平的 CLA 模板
- 解释 CLA 的必要性
- 考虑使用 DCO（开发者原产地证书）替代
7.8 本章小结
| 模式 | 特点 | 适用场景 |
|---|---|---|
| 传统双重授权 | 同一代码，两种许可证 | 数据库、中间件 |
| Open Core | 核心开源，扩展商业 | DevOps、监控工具 |
| 商业 + 支持 | 免费软件，付费服务 | Linux 发行版 |
| SaaS 变体 | 云托管收费 | 云数据库、API 服务 |
扩展阅读
- MySQL 许可证：https://www.mysql.com/about/legal/licensing/oem/
- Qt 许可证：https://www.qt.io/licensing
- MongoDB SSPL：https://www.mongodb.com/licensing/server-side-public-license
- CLA Assistant：https://cla-assistant.io/
- Developer Certificate of Origin：https://developercertificate.org/
- 《Open Source Business Models》：https://www.linuxfoundation.org/