一、OceanBase：MulanPubL-2.0 的工程选择

1.1 OceanBase 开源历程

OceanBase 由蚂蚁集团（Ant Group）自 2010 年起研发，是一个面向金融级场景的分布式关系型数据库，具备强一致性、高可用和 HTAP（混合事务分析处理）能力。2021 年 6 月，蚂蚁集团宣布将 OceanBase 开源，代码托管于 GitHub（oceanbase/oceanbase），并在此后逐步完善文档和社区建设。

1.2 MulanPubL-2.0 许可证解析

OceanBase 选用木兰公共许可证（第 2 版，Mulan Public License v2，MulanPubL-2.0）。这是 Mulan 许可证家族的 Copyleft 版本，与 MulanPSL v2（宽松版）有重要差异：

关键工程影响：MulanPubL-2.0 的 Copyleft 条款意味着，如果企业修改 OceanBase 并对外发布（包括通过网络向用户提供服务，视具体解读），需要以相同协议公开修改后的源码。

从蚂蚁集团的视角，这一选择有清晰的逻辑：

1. 防止竞争性改造：防止其他数据库厂商直接基于 OceanBase 代码构建竞争产品而不回馈社区；
2. 鼓励社区贡献：Copyleft 要求贡献者将改进开放，理论上使社区代码质量持续提升；
3. 商业支持优势：蚂蚁集团自身不受协议限制（作为版权持有者），可以向企业客户提供不同条款的商业授权。

1.3 MulanPubL-2.0 的”网络使用”模糊地带

与 AGPL（明确要求通过网络提供服务也必须开源）相比，MulanPubL-2.0 的网络使用触发条款表述相对模糊。协议第 4 条规定了”网络部署”的要求，但具体何种情形属于”修改后通过网络部署”，在没有中国法院判例的情况下存在解释空间。

工程建议：如果企业对 OceanBase 代码进行了修改并作为 SaaS/PaaS 产品向外部用户提供服务，应咨询法律顾问，评估是否需要公开修改后的源码或与蚂蚁集团洽谈商业协议。

1.4 OceanBase 的双许可模式

OceanBase 在开源之后，实际上同时存在两个可供企业选择的授权版本：

• 开源版（Community Edition）：以 MulanPubL-2.0 协议发布，托管于 GitHub（oceanbase/oceanbase），任何人均可下载、部署、修改，但需遵守 Copyleft 条款；
• 商业版（Enterprise Edition）：由蚂蚁集团以独立的商业授权条款提供，不受 MulanPubL-2.0 约束，客户签订商业合同后可以闭源二次开发、不触发网络部署的源码披露义务、并获得 SLA 支持。

1.4.1 社区版与商业版的功能差异

根据 OceanBase 官方公开文档与产品页面，两版在功能层面的主要差异可以归纳为四类增量能力：

1. 诊断报告与 ASH（Active Session History）：商业版提供完整的 AWR/ASH 风格诊断报告，用于分析活跃会话、等待事件、SQL 执行剖面；社区版的诊断能力相对有限，需要依赖外部工具拼接；
2. OceanBase Cloud 云服务版：商业版本以 SaaS 形式在公有云（包括阿里云、AWS 等）提供托管集群，带有自动化运维、弹性扩缩容、备份恢复等能力；社区版需要用户自行搭建和运维；
3. 商业级技术支持 SLA：商业版提供 7×24 小时技术支持、原厂现场支持、版本补丁的长周期维护；社区版依赖公开的 Issue 渠道和社区志愿者响应；
4. 特定高级功能：商业版包含若干企业场景下的增量特性，例如并行 DDL、高级压缩算法、细粒度的资源隔离、审计合规增强等——这些特性的具体清单以官方产品文档为准。

1.4.2 版权持有人不受 Copyleft 约束

一个关键的法律事实是：版权持有人本身不受自己发布的许可证约束。蚂蚁集团作为 OceanBase 代码的版权持有者（外部贡献者需通过 CLA 将贡献的版权授予或广泛授权给蚂蚁集团），可以在不遵守 MulanPubL-2.0 的前提下，向特定客户授予完全不同的商业授权。

这使得双许可模式在法律上成立：

• 普通用户/开源社区：拿到 MulanPubL-2.0 版本，受 Copyleft 约束；
• 企业付费客户：拿到商业授权版本，不受 Copyleft 约束，可按照合同条款自由闭源集成。

1.4.3 与 MySQL 双许可模式的对比

OceanBase 的双许可模式与 MySQL 的历史模式高度相似：

两者的共通点在于：

• 都以 Copyleft 协议作为开源版的约束机制，防止闭源商用搭便车；
• 都通过版权归属集中，为商业版授权提供法律基础；
• 都通过 CLA 确保贡献者代码可以进入双轨分发。

差异在于：MySQL 在 Oracle 收购后引发社区对”单一公司控制”的担忧，催生了 MariaDB 这一 GPL 分支；而 OceanBase 开源至今时间较短，尚未出现显著的第三方分支，双许可模式的长期稳定性仍有待观察。

二、中国开源数据库协议选择时间线

把中国主要开源数据库产品放在时间轴上观察，可以更清晰地看到协议选择的演化规律。

2.1 完整时间线表格

观察这张表，可以提取三条规律：

1. Apache 2.0 是主流选择：TiDB、Apache Doris、Apache IoTDB、TiKV 都选择了 Apache 2.0，这与它们的国际化或基金会路线高度相关；
2. Copyleft 类协议集中在 2021 年前后出现：OceanBase（MulanPubL-2.0）、StarRocks（ELv2）、SequoiaDB（SSPL）的共同动机是在开放代码的同时防止云厂商或竞争对手”搭便车”；
3. 国产 Mulan 协议家族的分化：Mulan PSL v2（宽松）适合 OpenGauss 这类希望获得最大生态覆盖的产品，而 MulanPubL-2.0（Copyleft）适合 OceanBase 这类希望通过协议约束保留商业谈判空间的产品。

2.2 为何不选 AGPL：三类风险分析

值得注意的是，在所有上述产品中，没有任何一家选择 AGPL。即便目标是”防止云厂商搭便车”，中国数据库产品也普遍绕开 AGPL，原因可以从三类风险角度解释：

2.2.1 云厂商法务审查风险

AWS、Azure、Google Cloud、阿里云、腾讯云、华为云等主要云厂商的开源合规团队，普遍将 AGPL 列为高风险协议：

• 云厂商的管理、监控、计费、身份认证等服务层与被托管的开源数据库存在网络交互，AGPL 的”通过网络提供服务也视为分发”条款可能触发服务层代码的披露义务；
• 各主要云厂商的 SPDX 黑白名单中，AGPL 通常被标记为”需要法务专项审批”或”默认禁止”；
• 结果是：AGPL 类数据库产品在云市场上架的难度显著高于 Apache 2.0 类产品，即便技术上可行，也往往被推迟或搁置。

2.2.2 客户采购合规风险

金融机构、政府机构、央企等大型客户的采购合同中，通常对开源软件使用条款有明确约束：

• 要求供应商软件使用 OSI 认证的标准开源协议（AGPL 虽然 OSI 认证，但在许多采购标准中仍被单独列出）；
• 部分合同要求”不得包含网络使用即触发 Copyleft 的条款”，这直接排除 AGPL 和 SSPL；
• 采购方担心的是：自研业务系统与 AGPL 数据库交互，是否需要开放业务系统源码？虽然协议原意通常不要求这种披露，但澄清成本高。

2.2.3 出海融资限制

国际 VC 和 PE 在对数据库创业公司进行技术尽调（Technical Due Diligence）时，会系统审查以下项：

• 核心产品是否使用 AGPL/SSPL 协议？
• 核心产品依赖树中是否存在 AGPL/SSPL 组件？
• 如果存在，是否已获得商业授权？

AGPL 产品的 SaaS 化路径被视为”复杂”，因为云服务提供商需要仔细界定哪些代码必须开源；一些投资人会直接将 AGPL 产品的估值折扣，或要求在投资后进行协议变更。这使得以出海融资为目标的中国数据库公司倾向于从一开始就避免 AGPL。

2.3 AGPL 的实际应用场景

并不是说 AGPL 完全不可用——在以下三类场景中，AGPL 仍是一个合理选择：

1. 初创团队希望防止云厂商搭便车：产品尚未进入大型云厂商的目标清单，但团队担心未来被”白嫖”，AGPL 可以作为一道屏障；
2. 没有出海融资计划，专注国内私有部署市场：目标客户是国内金融/政府机构的私有化部署，这些场景下客户本身不面向公网提供服务，AGPL 的网络条款不触发；
3. 有明确商业版和 AGPL 开源版的双轨计划：类似 MongoDB（早期）、Grafana Labs（早期）、MinIO 等，通过 AGPL 开源版倒逼商业客户购买商业授权，核心收入来自商业版。

反过来说：如果目标是云厂商集成、国际化或 VC 融资，AGPL 的”防御价值”远低于它带来的”生态损失”，这正是 OceanBase、SequoiaDB 等没有选 AGPL 的根本原因——它们要么选择 MulanPubL-2.0（Copyleft 但更温和），要么直接选 SSPL（更激进但明确针对云厂商）。

3.1 TiDB 的协议选择历程

TiDB 由 PingCAP 于 2016 年开源，从项目初始就采用 Apache 2.0 许可证（TiKV 同样采用 Apache 2.0，后捐赠给 CNCF）。这一选择在当时的中国数据库生态中具有前瞻性。

PingCAP 明确以”成为国际化的数据库公司”为战略目标，Apache 2.0 的选择直接服务于这一目标：

1. 云厂商集成无障碍：AWS、Google Cloud、Azure 等可以将 TiDB 作为托管服务提供，无需开源自己的服务层代码，降低了生态合作门槛；
2. OSI 认证，法务红线低：Apache 2.0 是 OSI 认证的许可证，在大多数企业的法务审查中不存在使用限制；
3. 专利授权条款：Apache 2.0 包含显式专利授权，贡献者自动向用户授予必要专利的无偿许可；
4. 出海无政治负担：相比木兰许可证（中文主体），Apache 2.0 在国际合作伙伴和投资人层面更容易被接受。

3.2 PingCAP 的双轨收入模式

与许多开源数据库公司类似，PingCAP 采用”开源 + 商业支持/云服务”的双轨模式：

• 开源版 TiDB（Apache 2.0）：核心数据库引擎完全开源，任何人可自由使用、修改、分发；
• TiDB Cloud（云托管服务）：PingCAP 的主要 SaaS 产品，提供全托管的 TiDB 集群，在 AWS 和 Google Cloud 上运行；
• TiDB 企业版：附加监控、安全审计、技术支持等商业功能，部分为闭源插件。

这一模式中，Apache 2.0 是实现”让尽可能多的团队采用 TiDB”的工具，商业版和云服务是实现收入的机制。

3.3 TiKV 进入 CNCF

TiKV（TiDB 底层的分布式键值存储）于 2019 年捐赠给 CNCF（云原生计算基金会），并于 2020 年从 CNCF 孵化器毕业成为顶级项目。这一举措使 TiKV 获得了更广泛的国际社区认可，并与 Kubernetes 生态深度绑定。

从协议角度，TiKV 在 CNCF 下仍然采用 Apache 2.0，CLA 签署由 CNCF 统一管理。这是中国公司通过国际基金会扩大技术影响力的典型路径。

四、Apache Doris 与 StarRocks：同源分叉的协议分化

4.1 Apache Doris 的基金会路线

Apache Doris（原百度 Palo）是百度于 2017 年开源的 MPP（大规模并行处理）分析型数据库，2018 年捐赠给 Apache 软件基金会，在孵化器中运行，2022 年 5 月从 Apache 孵化器正式毕业成为 Apache 顶级项目。

协议：Apache 2.0（由 ASF 统一管理）

Apache Doris 走基金会路线的工程含义：

1. 版权归属于 Apache 软件基金会（通过 ICLA/CCLA 流程，贡献者将版权授予 ASF）；
2. ASF 持有”Apache Doris”商标；
3. 任何公司（包括百度）不能单独主导项目的治理决策，需遵循”Apache Way”；
4. 由于 ASF 受美国 EAR 约束，ASF 需要对出口合规进行审查（见本系列第 19 篇）。

百度选择将 Doris 捐给 ASF 而非在国内自建基金会，主要动因是 ASF 品牌的国际公信力，以及通过 ASF 生态吸引国际贡献者和用户。

4.2 StarRocks：从闭源到 ELv2

StarRocks 的历史是一段典型的”开源、闭源、再开源”的协议演化案例：

阶段一（2021 年以前）：StarRocks 的前身是 DorisDB，由原百度 Doris 团队部分成员成立的商业公司（硅谷 StarTree 和上海飞轮科技）基于 Apache Doris 代码开发。初始版本以闭源商业软件形式发布。

此举在开源社区引发争议：DorisDB 是否可以基于 Apache Doris（Apache 2.0）代码开发闭源产品？从协议角度，答案是可以的——Apache 2.0 明确允许闭源衍生产品。但社区对此仍有情感层面的不满，部分 Apache Doris 贡献者认为这违背了开源精神。

阶段二（2022 年）：公司将产品更名为 StarRocks，并宣布将 StarRocks 以 Elastic License 2.0（ELv2） 重新开源，代码托管于 GitHub（StarRocks/starrocks）。

阶段三（2024 年）：根据公开报道，StarRocks 公司（在美国注册为 CelerData Inc.）继续推进 StarRocks 开源社区建设，并在探索是否进一步调整协议以进入 Apache 基金会等路径（具体进展以官方公告为准）。

4.3 Elastic License 2.0 的核心限制

Elastic License 2.0（ELv2）不是 OSI 认证的开源许可证。其核心限制条款是：

1. 禁止将产品作为托管服务（Managed Service）提供给第三方：即不允许云厂商基于 StarRocks 代码向外部用户提供”数据库即服务（DBaaS）“；
2. 禁止绕过许可证保护机制：不得修改许可证本身或移除许可证限制；
3. 允许内部使用和学习研究：企业可以在内部部署 StarRocks 用于自身业务，不受上述限制。

ELv2 的设计初衷与 Elastic 公司（Elasticsearch）面对 AWS 提供 Amazon Elasticsearch Service 时的抉择一脉相承——通过许可证防止云厂商”搭便车”，同时保持代码的公开可见性。

工程影响：使用 ELv2 软件的企业内部 IT 团队通常不受限制，但如果是数据库服务提供商、多租户 SaaS 平台等”实质上是向第三方提供托管数据库服务”的场景，则需要获得商业许可。

4.4 StarRocks 与 Apache Doris 的 Fork 关系详解

StarRocks 与 Apache Doris 的关系是中国开源数据库生态中最具代表性的”同源分叉”案例。理解这段历史，有助于判断协议选择如何影响下游社区结构。

3.4.1 起源：DorisDB 的团队构成

DorisDB（后更名 StarRocks）由原百度 Doris 团队的部分核心成员离职创立。核心团队成员在百度任职期间是 Apache Doris 的主要贡献者，离职后选择以独立商业公司的形式继续发展 Doris 的衍生产品。

由于 Apache Doris 已经以 Apache 2.0 协议开源，DorisDB/StarRocks 基于该代码库开发衍生产品在协议层面完全合法：Apache 2.0 明确允许闭源衍生、商业化、修改后重新发布，只要保留原始版权声明和 NOTICE 文件即可。

3.4.2 社区争议的三个层面

尽管协议上合法，DorisDB 的路径在 Apache Doris 社区内引发了较大的争议，主要集中在三个层面：

1. 协议合法性 vs 社区道德：

   • 协议上：Apache 2.0 完全允许闭源衍生，这是 Apache 2.0 相对 GPL 的一大特点；
   • 社区道德层面：原 Apache Doris 贡献者认为，拿基金会项目的代码构建闭源商业竞品，在”开源精神”层面存在争议；
   • Apache Doris PMC 曾通过官方渠道对此行为的立场发表过声明，强调原社区的独立发展路径。

2. 人才分流：核心贡献者的离职，对 Apache Doris 社区的代码产出和 PMC 多元化带来了短期冲击；Apache Doris 社区需要吸收新的工业界贡献者来弥补。

3. 品牌混淆风险：DorisDB 早期的名字容易让用户混淆其与 Apache Doris 的关系。2021 年更名为 StarRocks 后，品牌边界变得清晰。

3.4.3 2022 年 StarRocks 选择 ELv2 的战略分析

StarRocks 在 2022 年选择 Elastic License 2.0 重新开源，是一次典型的”防守型开源”决策：

• 打开代码可见性：满足用户对”可以看到源码”的诉求，消除闭源带来的信任成本；
• 禁止托管服务竞争：通过 ELv2 的”禁止提供托管服务”条款，防止云厂商基于 StarRocks 代码直接构建 DBaaS 竞品；
• 保留商业授权通道：有托管服务需求的客户必须购买商业授权，这是 StarRocks 公司（CelerData）的核心收入来源之一。

3.4.4 代码兼容性与技术分化

StarRocks 与 Apache Doris 在查询层的 SQL 方言和基础语法高度相似，很多用户可以在两者之间以较小的迁移成本切换。但随着时间推移，两者的存储引擎、执行引擎、优化器实现已经发生了较大的分化：

• 存储引擎：StarRocks 对主键模型、列式存储压缩、Bitmap 索引等做了大量独立优化；
• 执行引擎：StarRocks 采用全面向量化执行引擎，Apache Doris 在后续版本中也引入了向量化；
• 生态集成：Apache Doris 作为 ASF 项目，与 Apache 大数据生态（Hive、Spark、Flink）的集成更自然；StarRocks 投入更多在自主生态（外部表、Iceberg/Hudi/Delta Lake 连接器）。

3.4.5 用户选择的实际影响

对于需要在两者之间选型的用户，协议差异带来的实际影响包括：

• 选 Apache Doris：享受 ASF 生态带来的中立治理、Apache 2.0 的零协议风险、可以闭源集成到自身产品中；
• 选 StarRocks：根据公开 benchmark 数据，某些 OLAP 场景下性能优化更激进，但 ELv2 限制了 DBaaS 化的可能性——如果未来计划将数据库能力作为托管服务对外输出，需要提前购买商业授权。

4.5 Apache Doris 在 ASF 孵化器的毕业过程

Apache Doris 从 2018 年进入 ASF 孵化器，到 2022 年 5 月毕业为 Apache 顶级项目，历时近四年。这段时间内，项目在三个方面进行了系统性调整。

3.5.1 PMC 多元化

ASF 的核心治理原则是”社区胜于代码”（Community over Code），对 PMC 构成的多元化有明确要求：

• PMC 成员不能全部来自单一公司（通常要求非捐赠公司的 committer 和 PMC 成员占一定比例）；
• 关键决策（版本发布、协议变更、Committer 提名）必须在公开邮件列表讨论并通过 PMC 投票；
• Apache Doris 在孵化期间，逐步吸纳了来自美团、小米、京东、网易、字节跳动等多家公司的贡献者进入 committer 和 PMC 行列。

3.5.2 代码许可证清理

孵化期间，ASF IP Clearance 流程要求项目对整个代码库的许可证状况进行清理：

• 确保所有源文件包含正确的 Apache License 头；
• 检查所有第三方依赖的许可证与 Apache 2.0 的兼容性（GPL/AGPL 类依赖需移除或替换）；
• 补齐缺失的 LICENSE、NOTICE 文件；
• 将不兼容的依赖（如 LGPL/GPL 组件）替换为兼容实现。

这一过程通常持续数个版本，是孵化器毕业评审中的关键项之一。

3.5.3 CLA 签署规范化

ASF 要求所有个人贡献者签署 ICLA（Individual Contributor License Agreement），公司贡献者签署 CCLA（Corporate Contributor License Agreement）。Apache Doris 在孵化期间建立了完整的 CLA 签署流程：

• GitHub PR 触发 CLA 检查机器人；
• ICLA/CCLA 签署后版权授予 ASF；
• PMC 定期审计贡献来源的合规性。

3.5.4 2022 年 5 月毕业评审要点

ASF 孵化器毕业的 board report 通常评估以下项，Apache Doris 毕业时均满足：

• 至少 3 次符合 ASF 规范的版本发布（源码包、签名、哈希校验、投票记录）；
• PMC 已具备自我治理能力（可独立完成版本发布、committer 提名、社区纠纷处理）；
• 项目的社区多元化程度满足要求（贡献者来自多家不同背景的公司/机构）；
• 法律和品牌事项清理完毕（商标归属 ASF、不存在协议兼容性问题）。

3.5.5 Apache Way 对 PMC 多元化的具体要求

ASF 没有硬性规定”PMC 中某一公司的比例不得超过 X%“，但在孵化器毕业评审时，Mentor 和 IPMC（Incubator PMC）会从以下角度综合判断：

• 是否有至少两家不同公司的 committer 活跃参与代码审查？
• 版本发布投票（Release Vote）是否有跨公司的 +1？
• 邮件列表讨论是否有跨公司的交互？
• 新 committer 提名是否经过跨公司的讨论？

对于百度这样的原始捐赠公司，典型的期望是”从主导转为深度参与”——继续投入核心开发资源，但不单方面决定项目方向。

五、Apache 基金会毕业标准与中国数据库的毕业之路

5.1 ASF 孵化器毕业标准

Apache 软件基金会的孵化器毕业流程有一套相对明确的检查项，不同项目的具体通过路径虽有差异，但核心标准可以归纳为五类：

5.1.1 PMC 多元化

• 避免被单一公司主导：毕业时应有来自至少两家（通常更多）不同公司或机构的 committer 与 PMC 成员；
• 决策流程公开：所有核心决策（版本发布、成员提名、协议变更）必须在公开邮件列表讨论并留痕。

5.1.2 代码清洁度

• 所有源文件含正确的 Apache License 头；
• 第三方依赖许可证与 Apache 2.0 兼容（无 GPL/AGPL 类传染性依赖）；
• LICENSE 和 NOTICE 文件规范；
• 捐赠时的软件授权（Software Grant Agreement）完整。

5.1.3 社区健康

• 邮件列表（dev@、user@）活跃，问题讨论公开；
• 有多家公司或个人的持续贡献；
• 版本发布符合 ASF 规范（源码发行、签名、SHA 校验、72 小时投票窗口）。

5.1.4 基础设施独立性

• 代码托管在 ASF 基础设施（gitbox.apache.org 或镜像到 GitHub/apache 组织）；
• 不依赖单一公司的构建、CI、网站；
• 邮件列表由 ASF infra 运营。

5.1.5 LEGAL/NOTICE 文件规范

• 项目根目录的 LICENSE 和 NOTICE 完整列出所有第三方组件及其许可证；
• 发版时的二进制产物的 LICENSE/NOTICE 与源码一致；
• 商标使用符合 ASF Trademark Policy。

5.2 中国数据库毕业案例对比

三个项目的对比揭示了几点：

• Apache Doris 孵化周期最长：原因是捐赠时 PMC 基本全部来自百度，多元化需要时间；加上代码库历史较长，第三方依赖清理工作量大；
• Apache IoTDB 毕业较快：学术项目的独立性相对明显（清华并非商业公司，不存在”公司主导”的结构性风险），技术范围聚焦在时序数据库，代码库相对干净；
• TiKV 走 CNCF 路线而非 ASF：CNCF 对云原生集成的要求高于 ASF，毕业标准更看重”被至少三个生产环境大规模使用”和”Kubernetes 生态集成”；TiKV 的选择与其定位（云原生分布式存储）匹配。

5.3 SequoiaDB SSPL 路线的教训

与走 ASF/CNCF 路线的项目不同，SequoiaDB 选择了 SSPL 开源路线。几年过去，这条路线在市场层面暴露出若干问题，可以作为反向教材。

5.3.1 SSPL 在云厂商法务层面的实际拦截效果

SSPL 对云厂商的设计目的是”如果你想把这个软件作为 SaaS 卖出去，你必须公开你的整个服务层代码”。在实践中：

• 阿里云、腾讯云、华为云等主要国内云厂商的法务团队，对 SSPL 产品的集成申请普遍采取保守态度；
• AWS、Google Cloud、Azure 将 SSPL 列为”受限协议”，内部服务团队提交 SSPL 产品的集成提案通常需要走高级别的法务审批；
• 结果是：SSPL 产品在云市场的上架数量和 Apache 2.0 产品不在同一量级。

5.3.2 国内云厂商对 SSPL 产品的态度

• 默认不推荐：开源合规团队在审查新产品引入时，默认对 SSPL 标注”需要商业授权”或”需要提交专项法务意见”；
• 替代方案优先：同类需求下，优先选择 Apache 2.0 产品（例如 TiDB、OceanBase 对比 SequoiaDB 时，云厂商倾向集成前两者）；
• 不阻止私有部署：但不排斥在客户侧的私有化部署项目中为 SSPL 产品提供工程服务。

5.3.3 SequoiaDB 的市场局限

SequoiaDB 的实际市场分布呈现出明显的聚集特征：

• 核心市场集中在金融机构（银行、保险、证券）的私有化部署；
• 在公有云 DBaaS 市场的存在感较弱；
• 海外市场扩展相对有限。

这和金融行业本身的”私有化优先”采购习惯有关，但同时也说明 SSPL 在面向公有云场景时的确构成明显的市场壁垒。

5.3.4 对比教训

对比 OceanBase 与 SequoiaDB：

• 两者同样面向金融行业；
• 两者都希望保留商业授权谈判空间；
• OceanBase 选择 MulanPubL-2.0（Copyleft 但更温和，且与云厂商的实际交互更友好）；
• SequoiaDB 选择 SSPL（Copyleft 极激进，直接触发主要云厂商法务红线）；

结果：OceanBase 在蚂蚁自身的云服务（OceanBase Cloud）之外，也获得了其他云厂商的合作机会；SequoiaDB 则主要依赖自身渠道和金融行业定制项目。

5.4 Apache IoTDB 走 ASF 路线的特殊性

在中国数据库项目中，Apache IoTDB 是少有的由高校学术团队主导进入 ASF 的项目，其路径选择有若干特殊性。

5.4.1 学术机构的治理契合

• 清华大学软件学院作为发起方，天然具备”中立第三方”的气质，不存在商业公司主导带来的公信力担忧；
• ASF 的中立治理模式与学术合作的”不归任何一方独占”传统契合度高；
• 毕业为 ASF 顶级项目后，项目品牌从”清华的 IoTDB”转为”Apache 的 IoTDB”，更容易吸引国际贡献者。

5.4.2 商业公司独立运营

天谋科技（TimechoDB）是基于 Apache IoTDB 提供商业版本和企业支持的独立公司，其与 ASF 项目的关系类似于 Cloudera/Hortonworks 与 Apache Hadoop：

• 天谋科技的员工可以作为 committer/PMC 成员参与 Apache IoTDB；
• 但公司不能单方面主导项目决策，需遵循 Apache Way；
• 商业版的闭源增强功能在公司内部开发，不进入 Apache 项目代码库。

5.4.3 国际学术引用价值

Apache 顶级项目的身份对学术论文合作有明显价值：

• 国际期刊和会议（VLDB、SIGMOD、ICDE）在引用开源项目时，Apache 顶级项目的权重明显高于非基金会项目；
• 学术合作伙伴（包括欧洲、美国、亚洲其他地区的高校和研究机构）在引入项目时的法务成本更低；
• 国际标准化组织（如 IIC、TSDB 相关标准）的参与机会更多。

六、双许可模式（Dual Licensing）工程分析

双许可模式是中国开源数据库生态中被广泛使用但常被简化理解的商业模式。本节系统地分析其法律基础与工程实践。

6.1 双许可模式的法律基础

6.1.1 版权持有人的权利

• 根据著作权法原理，版权持有人对自己的作品拥有完整的授权权利；
• 版权持有人可以同时以多个许可证版本发布同一作品（例如：同一份代码既以 GPL 发布，也向特定客户以商业授权发布）；
• 用户可以自由选择其中任一许可证——但一旦选择，就必须遵守该许可证的完整条款。

6.1.2 对版权归属的要求

双许可模式要求版权归属于单一实体（或统一授权的多个实体），否则发布商业版时会陷入法律困境：

• 如果代码中 A 部分的版权归 X 公司、B 部分归 Y 公司、C 部分归社区贡献者，X 公司要发布”全代码的商业授权版”，必须获得 Y 公司和每个社区贡献者的明确授权；
• 实际操作中这几乎不可行，因此双许可模式的项目普遍通过 CLA 将版权归属集中。

6.1.3 CLA 的作用

贡献者许可协议（Contributor License Agreement，CLA）有两种常见形态：

• 版权转让（Copyright Assignment）：贡献者将代码版权完全转让给项目所有方（较激进，部分贡献者不愿签）；
• 宽广授权（Broad License Grant）：贡献者保留版权，但向项目所有方授予足以支持双许可发布的广泛权利（更温和，接受度更高）。

对于 GPL+商业版这类双许可项目，CLA 是法律上的必要条件——没有 CLA，项目所有方无法获得”以不同协议重新发布贡献代码”的权利。

6.2 OceanBase 双许可实践

OceanBase 的双许可实践是中国数据库中的典型范例。

6.2.1 授权结构

• 开源版：MulanPubL-2.0（Copyleft），面向社区用户；
• 商业版：蚂蚁集团的独立商业授权合同，面向企业客户。

6.2.2 版权归属

• 蚂蚁集团持有 OceanBase 核心代码的版权；
• 外部贡献者通过 CLA 将贡献授权（或转让）给蚂蚁集团；
• 这使得蚂蚁可以在 MulanPubL-2.0 之外，为企业客户提供完全不同的商业授权条款。

6.2.3 商业版授权流程

典型的商业授权流程包括：

1. 客户提出商业授权需求（通常是希望闭源二次开发，或希望规避 MulanPubL-2.0 的网络部署条款）；
2. 蚂蚁团队评估客户场景（部署规模、使用方式、是否涉及网络服务）；
3. 签订商业授权合同（包含授权范围、技术支持级别、合规条款）；
4. 客户获得非 MulanPubL-2.0 的授权凭证，可以按合同条款自由闭源使用。

6.3 PingCAP TiDB 的”开源 + 云服务”模式

PingCAP 的商业模式与 OceanBase 的双许可不同——它是开放核心（Open Core）模式的一种变体。

6.3.1 模式差异

• TiDB 本身是 Apache 2.0，没有”闭源商业版”；
• PingCAP 的商业收入主要来自 TiDB Cloud（SaaS 产品）和 TiDB Enterprise（企业支持订阅）；
• TiDB Cloud 不是”闭源的 TiDB”，而是”TiDB 本体 + PingCAP 专有的运营层（自动扩缩容、监控仪表板、支持 SLA、合规认证）“。

6.3.2 盈利路径

• 运营层（Control Plane）闭源：计费、自动扩缩容、多租户隔离、安全审计等；
• 数据面（Data Plane）使用 Apache 2.0 的 TiDB；
• 客户付费购买的是”由 PingCAP 运营的可靠、合规、高 SLA 的 TiDB 集群服务”，而非”更强版本的 TiDB”。

6.3.3 相对双许可的优势

• 贡献者门槛低：不需要签复杂的 CLA（DCO 或轻量 CLA 即可，因为不需要双许可重发布权利）；
• 社区信任高：Apache 2.0 的纯开源身份避免了”为付费用户保留好功能”的质疑；
• 出海友好：Apache 2.0 在国际市场没有任何协议障碍。

6.3.4 相对双许可的挑战

• 云厂商搭便车风险：AWS 等云厂商完全可以基于 Apache 2.0 的 TiDB 自建 DBaaS，与 PingCAP 竞争；
• 解决方案是 PingCAP 依赖”我比云厂商更懂 TiDB”的专业壁垒，提供云厂商难以复制的运营质量和技术支持。

6.4 MySQL 双许可模式的历史参照

MySQL 是双许可模式在数据库领域最经典的案例，其历史对理解中国数据库的选择有参考价值。

6.4.1 历史阶段

• MySQL AB 时期（2000-2008）：MySQL AB 作为瑞典公司，采用 GPL + 商业版双许可；
• Sun Microsystems 收购（2008）：Sun 以约 10 亿美元收购 MySQL AB，双许可模式延续；
• Oracle 收购 Sun（2010）：Oracle 继续维护 MySQL 的双许可模式，推动企业版商业化；
• MariaDB 分支出现（2009）：MySQL 创始人 Monty Widenius 担忧 Oracle 控制，创立 MariaDB 作为 GPL 分支。

6.4.2 MariaDB 对 MySQL 的意义

• MariaDB 证明了：当版权持有人被视为”不可信”时，社区可以通过 GPL 分支保留项目延续性；
• 这对 OceanBase 等采用双许可的中国数据库项目是一个潜在启示——如果未来蚂蚁集团的策略发生重大变化，MulanPubL-2.0 社区版理论上也可以被分支为独立项目。

6.4.3 与 OceanBase 的对比

• MySQL/MariaDB：GPL（Copyleft）+ 商业版双许可；
• OceanBase：MulanPubL-2.0（Copyleft）+ 商业版双许可；
• 结构高度相似，差别主要在 Copyleft 协议的具体条款和适用法域。

6.5 选择双许可的工程建议

对于正在考虑采用双许可模式的数据库或中间件项目，以下工程建议来自公开实践经验：

6.5.1 CLA 设计

• 版权转让 vs 宽广授权：版权转让更激进、法律上更清晰，但贡献者接受度低；宽广授权更温和、社区接受度高，但实施时需要律师仔细起草确保涵盖未来可能的协议变更；
• ICLA + CCLA 双轨：针对个人贡献者与公司贡献者分别设计 CLA，避免公司员工个人签署却无法覆盖公司代码的问题；
• 电子签署流程：使用 CLA 签署机器人（如 CLA Assistant）在 GitHub PR 上自动提示，降低签署阻力。

6.5.2 贡献者体验

• 过于严格的 CLA（尤其是强制版权转让）会显著降低外部贡献意愿；
• 对比案例：Apache 项目采用的 ICLA 是宽广授权而非转让，因此更容易吸引跨公司贡献；
• 设计时应权衡”商业灵活性”与”社区健康度”。

6.5.3 律所参与

• 商业授权合同的条款（授权范围、限制条件、违约责任、SLA）需要法律专业支持；
• 建议在双许可启动前咨询熟悉开源法律的律师事务所（中国大陆有若干律所专门做开源合规，例如知产律师团队）；
• CLA 文本不宜自行起草——参考 Apache ICLA/CCLA、Google CLA 或 Canonical CLA 作为模板更可靠。

七、Apache IoTDB：清华大学的学术开源路线

7.1 项目背景

Apache IoTDB（物联网数据库）起源于清华大学软件学院的研究项目，针对时序数据的存储与查询进行了专项优化（列式存储、时间序列压缩算法、SQL-like 查询接口）。项目于 2019 年进入 Apache 孵化器，2020 年正式毕业为 Apache 顶级项目。

协议：Apache 2.0

商业化：天谋科技（TimechoDB 公司）基于 Apache IoTDB 提供商业版本和企业支持服务，与 Apache IoTDB 的关系类似于 Cloudera/HortonWorks 与 Apache Hadoop。

7.2 学术项目走基金会路线的特点

清华大学选择 Apache 基金会路线（而非国内基金会）具有多重考量：

1. 国际学术认可：Apache 顶级项目的身份在国际学术界具有较高认可度，有助于吸引国际合作者和论文引用；
2. 中立治理：ASF 的中立身份避免了单一企业主导的形象，有利于多家工业界合作伙伴参与；
3. 商业公司的独立性：商业公司（天谋科技）独立于 ASF 项目之外运营，专注于企业特性和技术支持，符合 ASF 的治理要求。

7.3 学术项目开源的一般性建议

基于 Apache IoTDB 的经验，学术机构发起的数据库项目走开源路线时可以参考以下几点：

• 产权归属提前规划：研究成果通常涉及高校、学生、资助方三方，进入基金会前需完成产权归属的清理，避免后期纠纷；
• 与商业公司的边界：学术团队主导时代码与商业公司代码应保持清晰的分支隔离；
• 长期维护机制：学生毕业会导致核心贡献者流失，需要及早培养工业界 committer 以保证长期可持续性；
• 资助合规：若使用国家自然科学基金、国家重点研发计划等经费，需核实资助条款是否允许将代码捐赠至境外基金会。

八、SequoiaDB：SSPL 策略与云市场局限

8.1 SequoiaDB 的 SSPL 选择

SequoiaDB（巨杉数据库）是广州巨杉软件开发有限公司开发的 NoSQL/NewSQL 数据库，面向金融行业的分布式事务场景。2019 年，SequoiaDB 将服务端代码以 SSPL v1（Server Side Public License） 开源。

SSPL 由 MongoDB Inc. 设计，是 AGPLv3 的加强版，核心条款是：

如果你修改了 SSPL 软件并将其作为服务提供，你必须以 SSPL 许可证开放为提供该服务所使用的所有代码，包括管理、监控、部署、配置等相关服务层代码。

这一条款比 AGPL 更激进：AGPL 要求开放”通过网络交互”的软件本身，SSPL 则要求开放整个”运营该软件所需的服务层代码”。

8.2 SSPL 对云厂商的影响

SSPL 的实践效果和 MongoDB 的经验一致：

• AWS、Azure、Google Cloud 不在其主要云服务市场列出 SSPL 软件的托管服务：各大云厂商的法务部门普遍将 SSPL 列为”高风险”协议，因为为 SSPL 软件提供托管服务意味着需要开放大量服务层代码；
• 企业法务审查红线：许多大型企业（尤其是科技公司）的开源合规政策将 SSPL 列为”需要特别审查”或”默认不可使用”的协议类别；
• OSI 未认证：SSPL 未获得 OSI 认证，不被视为标准开源许可证，部分采购政策将”必须使用 OSI 认证协议”作为硬性要求。

8.3 SequoiaDB 在云市场的局限

受 SSPL 的限制，SequoiaDB 在主流国际云市场的集成度明显低于 Apache 2.0 竞品：

• 无法在 AWS Marketplace 以标准 SaaS 方式提供；
• 国内云厂商（阿里云、腾讯云等）在引入 SSPL 产品时同样面临法务评估障碍；
• 目标市场主要集中在金融机构的私有化部署，而非公有云场景。

SequoiaDB 的策略选择与其目标市场（金融行业定制部署）有一定匹配性——金融机构通常倾向于私有化部署，对云市场的依赖程度较低；但对于希望进入广泛云生态的产品，SSPL 是一个明显的市场障碍。

九、为什么国内数据库偏爱 Apache 2.0

9.1 商用友好，云厂商积极集成

Apache 2.0 是目前对商业应用最友好的开源许可证之一，允许任何形式的使用、修改和分发（包括闭源商业产品和云服务）。对于希望进入云市场的数据库产品，Apache 2.0 可以显著降低云厂商集成的法务障碍。

从生态效应看，一旦被主流云厂商（AWS、Azure、GCP、阿里云、腾讯云、华为云）集成为托管服务，产品的用户获取成本大幅降低，同时市场知名度快速提升。

9.2 基金会治理的公信力

对于需要出海或与国际合作伙伴合作的项目，加入 Apache 软件基金会或 CNCF 可以显著提升项目的国际公信力：

• ASF 的”Apache 品牌”在全球开发者社区中有极高认知度；
• ASF/CNCF 的中立身份消除了”单一公司控制”的疑虑，降低了竞争企业参与社区的门槛；
• ASF 的项目管理规范（Apache Way）和孵化流程对项目质量有一定背书作用。

9.3 避免 AGPL/SSPL 的法务审查红线

国内数据库产品通常将”进入云市场”和”与国际投资人合作”列为重要目标，这两个场景对协议有明显的隐性要求：

• 主流国际 SaaS 公司和云厂商的供应链审查中，AGPL 和 SSPL 属于需要专项评估的高风险协议；
• 国际顶级 VC 和 PE 在进行技术尽调时，会关注核心产品是否包含 AGPL/SSPL 依赖，因为这会影响产品的商业可复制性；
• AGPL/SSPL 产品在部分国家/地区的云市场（如 AWS China）存在合规障碍。

这一”避免 AGPL/SSPL”的倾向不是中国独有的，而是全球范围内商业化开源数据库项目的普遍策略（参见 CockroachDB 从 BSL 变更为 Apache 2.0 的讨论、HashiCorp 因改为 BSL 而引发社区分裂的案例）。

此外值得一提的是，即便是 Elastic 和 Redis 这类国际知名项目，在选择 SSPL/RSAL 后也都引发了社区 Fork（OpenSearch、Valkey），最终迫使协议选择回到更宽松的方向。这对中国数据库项目的启示是：Copyleft 激进协议在现实市场中的”防御价值”往往被高估，而它带来的生态损失相对容易被低估。

9.4 出海无障碍

Apache 2.0 作为 OSI 认证的标准开源许可证，在全球绝大多数法律体系和商业环境中均被广泛接受。对于以”出海”为战略目标的数据库产品，Apache 2.0 规避了以下潜在障碍：

• 语言障碍：MulanPubL-2.0 的中文文本在非中文法律环境下可能存在理解和执行困难；
• OSI 认证：许多组织的采购政策或供应链规定要求”使用 OSI 认证的开源许可证”；
• 国际社区习惯：国际开源社区对 Apache 2.0 的理解和接受程度最高。

十、协议选择的决策框架

10.1 场景判断矩阵

对于正在考虑开源或更换许可证的数据库产品团队，以下矩阵提供了初步参考：

10.2 引用第三方数据库产品的合规注意事项

企业在技术栈中引入第三方数据库时，协议层面的关注点包括：

10.3 自研数据库开源时的协议选择路径图

对于正在考虑将自研数据库开源的团队，下面的决策路径可以作为协议选择的参考。

10.3.1 第一步：主要市场定位

询问：产品的主要市场是国内还是国际？

• 国内为主，且防竞争优先：选择 MulanPubL-2.0 或 AGPL
  • 适用场景：目标客户是国内政企机构的私有化部署，不需要进入国际云市场；
  • 优势：Copyleft 条款倒逼竞争对手贡献回流或购买商业授权；
  • 典型案例：OceanBase（MulanPubL-2.0）；
• 国际为主，云市场覆盖优先：选择 Apache 2.0
  • 适用场景：目标通过 AWS/Azure/GCP 云市场覆盖全球客户；
  • 优势：云厂商集成无障碍，OSI 认证法务红线低；
  • 典型案例：TiDB、Apache Doris；
• 两者兼顾，需商业双轨：选择 Apache 2.0 + 商业版（Open Core 模式）
  • 适用场景：希望开源版最大化生态覆盖，同时通过商业版/云服务变现；
  • 优势：开源版无协议限制，商业版通过专属功能/SLA 差异化；
  • 典型案例：PingCAP TiDB Cloud。

10.3.2 第二步：基金会归属

询问：是否希望加入国际基金会？

• 是：选择 Apache 2.0
  • ASF 路线：适合数据管理、大数据生态项目（Apache Doris、Apache IoTDB）；
  • CNCF 路线：适合云原生、Kubernetes 生态项目（TiKV）；
  • 代价：版权需捐赠给基金会、治理需遵循基金会规范（Apache Way / CNCF Graduation Criteria）。
• 否，选择国内基金会：选择 Mulan PSL v2 或 Apache 2.0
  • 开放原子开源基金会路线：适合面向信创/政企市场的项目（OpenHarmony、OpenGauss）；
  • 协议灵活性更高：可以使用 Mulan 协议家族，也可以使用 Apache 2.0。
• 不加入基金会，自主运营：选择任意协议
  • 优势：决策速度快，无外部治理约束；
  • 代价：公信力建设依赖自身，国际合作门槛更高。

10.3.3 第三步：云厂商集成策略

询问：产品是否有云厂商集成需求？

• 强需求（希望被主要云厂商托管）：绝对回避 SSPL/AGPL
  • 推荐：Apache 2.0；
  • 可以考虑：MulanPSL v2、MIT、BSD；
  • 慎重：MulanPubL-2.0（部分云厂商法务仍会单独审查）；
• 中等需求（仅希望被部分云厂商集成）：可以考虑 ELv2/BSL
  • ELv2：禁止托管服务，但不禁止内部部署；云厂商若不以 DBaaS 形式销售，仍可接受；
  • BSL：带时间限制的 Copyleft，若干年后自动转为开源协议；
• 弱需求或反对被白嫖：SSPL/AGPL/ELv2 都可以考虑
  • SSPL：直接打击云厂商 DBaaS 策略（代价：法务红线最高）；
  • AGPL：网络条款触发源码披露（代价：国际接受度中等）；
  • ELv2：明确禁止托管服务（代价：非 OSI 认证）。

10.3.4 综合决策矩阵

把三步综合起来，可以得到如下典型组合：

十一、工程坑点

11.1 MulanPubL-2.0 与 GPL 的兼容性问题

MulanPubL-2.0 是 Copyleft 协议，但与 GPLv2/GPLv3 的兼容性尚未得到广泛验证。如果系统中同时存在 MulanPubL-2.0 组件和 GPL 组件，理论上存在许可证兼容性问题（两者都要求衍生作品以相同协议发布，可能产生冲突）。

在实践中，工程团队应避免将 MulanPubL-2.0 组件与 GPL 组件在同一可执行文件或动态库中混用，或在使用前进行专项法务评估。

典型的冲突场景：

• 静态链接：将 GPL 库静态链接进 MulanPubL-2.0 的二进制，两个 Copyleft 协议都要求整个结果遵守自身，形成互斥；
• 动态链接：GPL 的解释通常认为动态链接也构成”衍生作品”，存在同样风险；FSF 的 GPL FAQ 对这一点有明确表态；
• 独立进程 + IPC 交互：通常认为不构成衍生作品，但应结合具体交互方式法务评估；
• 数据流交互（如数据库客户端）：一般不触发 Copyleft，但如果客户端代码深度依赖 MulanPubL-2.0 项目的 API 定义，仍需审查。

11.2 “Apache Way”的贡献门槛

将项目捐赠给 ASF 后，项目必须遵循”Apache Way”的治理规范，包括：

• 主要技术决策需在公开邮件列表（dev 列表）中讨论和记录；
• PMC 成员构成需逐步多元化，不能被单一公司主导；
• 版本发布必须通过 PMC 投票；
• 所有贡献需通过 ICLA/CCLA 签署版权授权。

这对于习惯于公司内部快速决策的团队是一个显著的流程约束。Apache Doris 在毕业过程中也经历了多轮 PMC 多元化的调整。

实践中常见的 Apache Way 适应难点：

• 决策节奏变慢：从”内部会议拍板”转为”公开邮件列表讨论 + 投票”，单次决策周期从数小时延长至数天甚至数周；
• 贡献者管理：不能单方面决定谁成为 committer，必须通过 PMC 讨论与投票；
• 版本发布流程：每次发版需走 Release Candidate → 72 小时投票 → 官方发布的完整流程，不能随意 hotfix 上线。

11.3 ELv2 的”托管服务”边界

ELv2 中”提供托管服务（Hosted Service）“的边界在实践中并不总是清晰的。以下场景存在灰色地带：

• 内部多租户平台：企业内部为多个业务部门提供统一的 StarRocks 服务，是否算”提供托管服务”？（通常认为内部使用不触发此条款，但跨法人实体的集团公司存在解释空间）
• MSP（托管服务提供商）：作为系统集成商，为甲方客户搭建并运维 StarRocks 集群，是否算”提供托管服务”？（存在争议，建议获取 StarRocks 商业许可）
• SaaS 产品中嵌入 StarRocks：SaaS 产品本身不是”数据库服务”，但底层使用 StarRocks 处理分析查询，是否触发 ELv2 限制？（需根据具体场景法务评估，关键在于”是否向用户暴露数据库本身的接口”）

11.4 CLA 签署流程对外部贡献者的影响

无论是走 ASF 路线还是走双许可模式，CLA 的实施都可能对外部贡献意愿产生可观察的负面影响：

• 企业贡献者的内部审批流：部分大公司（尤其是国企、金融机构）的员工签署外部 CLA 需要走公司法务审批，周期可能长达数周；
• 个人贡献者的心理负担：签署法律文件对技术开发者是额外的阻力，尤其是初次参与开源的开发者；
• 减缓社区扩张速度：CLA 严格的项目通常比使用 DCO（Developer Certificate of Origin，轻量声明）的项目社区扩张慢。

缓解措施：

• 使用 CLA Assistant 等自动化工具降低签署阻力；
• 提供中英文对照的 CLA 文本；
• 明确 CLA 不转让版权（如仅是授权），降低贡献者顾虑。

11.5 协议变更的工程影响

一些项目在成长过程中会考虑变更许可证（如 CockroachDB 从 Apache 2.0 改为 BSL，HashiCorp 从 MPL 改为 BSL），协议变更的工程成本不可忽视：

• 历史代码的版权核查：变更协议前，必须确保所有历史贡献都有 CLA 覆盖，否则需要回溯联系贡献者或移除代码；
• 社区信任消耗：协议变更往往引发社区分裂，典型案例是 HashiCorp 协议变更后社区 Fork 为 OpenTofu；
• 下游依赖的影响：商业用户的合规团队需要重新评估，部分用户可能选择停留在协议变更前的最后一个开源版本，造成”长期维护分叉”。

十二、选型建议

12.1 企业内部使用

• 没有限制：Apache 2.0（TiDB、Apache Doris、IoTDB）、MulanPSL v2（OpenGauss）、MulanPubL-2.0（OceanBase）内部使用均无限制；
• 需要注意：SSPL（SequoiaDB）和 ELv2（StarRocks）内部使用也无限制，但如果内部平台未来演化为对外服务，需要提前评估；
• 法务审查：若公司内部合规政策对 AGPL/SSPL 有限制，应在引入前完成评估，避免后期迁移成本。

建议在引入新的开源数据库时建立以下最小合规检查清单：

1. 确认协议类型（Apache 2.0 / MulanPSL / MulanPubL / SSPL / ELv2 / AGPL）；
2. 检查项目是否来自基金会（ASF / CNCF / 开放原子），若是则合规成本较低；
3. 确认是否存在修改需求，若有，评估是否触发 Copyleft；
4. 评估未来 12-24 个月内该数据库是否可能暴露为对外服务；
5. 在公司 SBOM（软件物料清单）中记录该组件的协议信息。

12.2 构建对外产品或服务

• 如产品面向国际市场，优先选择 Apache 2.0 的数据库（TiDB、Doris、IoTDB）；
• 如需要防止竞争对手以最小成本复制产品，考虑 ELv2（StarRocks）或 BSL；
• 避免在对外产品的核心数据路径上集成 SSPL 组件，除非已与版权持有人签订商业协议。

对外产品形态与协议选择的对应关系：

12.3 数据库产品开发商的协议选择

• 最大化生态覆盖：Apache 2.0（可以通过商业版/云服务变现）；
• 防止云厂商搭便车：ELv2 / BSL（非 OSI，但接受度相对 SSPL 更好）；
• 国内政企场景为主：MulanPubL-2.0 可以接受，但需要建立清晰的商业授权渠道。

从长期演化角度看，数据库协议选择的几个额外建议：

1. 协议可变，代码难变：优先选择可以向更宽松方向变更的协议（例如从 Apache 2.0 变 BSL 可行，从 GPL 变 Apache 2.0 几乎不可行），给未来留出空间；
2. CLA 从第一天建立：即便一开始选择纯 Apache 2.0，也建议通过 CLA 集中版权，这为未来可能的协议调整保留灵活性；
3. 不要假设协议能阻止竞争：协议只是”合规层面的门槛”，真正的竞争壁垒来自产品的工程质量、生态建设和商业运营能力；
4. 避免”既要又要”：SSPL/AGPL 既想获得开源生态又想阻止云厂商，实际效果是两头都不讨好——要么选 Apache 2.0 拥抱生态，要么直接闭源（Source Available），混合方案通常效果不佳。

12.4 协议迁移的决策时机

如果项目已经开源，但希望在未来变更协议，以下时机判断值得参考：

• 产品早期（< 1000 用户）：协议变更的阻力最小，可以相对自由地调整；
• 产品成长期（1 万 - 10 万用户）：需要公开沟通，但社区反弹可控；
• 产品成熟期（> 10 万用户 / 关键行业采用）：协议变更会引发显著社区反弹，甚至导致分叉（参考 ElasticSearch → OpenSearch、HashiCorp Terraform → OpenTofu、Redis → Valkey 等案例）。

因此最佳实践是：在项目早期就慎重选择协议，而不是依赖后期调整。

12.5 小结

协议选择是一项兼具法律属性与商业属性的工程决策。本文所讨论的几类典型中国数据库产品——OceanBase、TiDB、Apache Doris、StarRocks、Apache IoTDB、SequoiaDB——在协议选择上呈现的分化，实际上对应着它们各自不同的市场定位、商业模式与治理目标：

• OceanBase 的 MulanPubL-2.0 对应”金融级 + 双许可 + 蚂蚁云战略”；
• TiDB 的 Apache 2.0 对应”出海 + 国际云市场 + Open Core”；
• Apache Doris 的 Apache 2.0 + ASF 对应”生态最大化 + 国际公信力”；
• StarRocks 的 ELv2 对应”防云厂商托管 + 代码可见”；
• Apache IoTDB 的 Apache 2.0 + ASF 对应”学术中立 + 国际合作”；
• SequoiaDB 的 SSPL 对应”金融私有化 + 防搭便车（代价是云市场受限）“。

对后来者的启示是：协议不是目的，而是服务于战略的工具。在决策前清晰回答”我的市场在哪里、我靠什么赚钱、我希望谁参与社区”，协议选择就会变得自然。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。本文所述事件均来自公开报道与公开判决书，如有偏差以官方渠道为准。

参考资料

1. OceanBase GitHub 及许可证：github.com/oceanbase/oceanbase；MulanPubL-2.0 文本：license.coscl.org.cn/MulanPubL-2.0
2. OceanBase 开源公告（蚂蚁集团官方博客，2021 年 6 月）：OceanBase 宣布开源，代码托管于 GitHub，采用 MulanPubL-2.0 协议
3. TiDB GitHub（Apache 2.0）：github.com/pingcap/tidb
4. TiDB GitHub Release 历史：github.com/pingcap/tidb/releases（v1.0 GA 公告发布于 2017 年）
5. Apache Doris 官网：doris.apache.org
6. Apache Doris 毕业公告（ASF 官网，2022 年 5 月）：blogs.apache.org/foundation（The Apache Software Foundation Announces Apache Doris™ as a Top-Level Project）
7. StarRocks GitHub 及 ELv2 说明：github.com/StarRocks/starrocks
8. StarRocks ELv2 开源声明（GitHub 仓库 LICENSE 文件与公司官方博客，2022 年）
9. Apache IoTDB 官网：iotdb.apache.org
10. SequoiaDB 官网及 SSPL 说明：sequoiadb.com
11. Elastic License 2.0 文本：elastic.co/licensing/elastic-license
12. SSPL v1 文本（MongoDB）：mongodb.com/licensing/server-side-public-license
13. OSI 对 SSPL 的评估说明：opensource.org/node/1099
14. OpenGauss 官网及 MulanPSL v2：opengauss.org
15. TiKV 加入 CNCF 公告：cncf.io/announcements/2019/05/21/tikv-accepted-as-a-cncf-incubating-project
16. TiKV 毕业为 CNCF 顶级项目：cncf.io/announcements（2020 年 TiKV Graduation 公告）
17. Apache 软件基金会孵化器流程：incubator.apache.org
18. ASF 孵化器毕业指南：incubator.apache.org/guides/graduation.html
19. Apache ICLA/CCLA 文本：apache.org/licenses/contributor-agreements.html
20. MongoDB SSPL 发布说明与 AWS 对应回应（公开新闻，2018-2019 年）
21. CockroachDB 协议变更公开说明：CockroachDB 从早期的 Apache 2.0 切换至 BSL（2019 年），后续路线以官方公告为准：cockroachlabs.com/blog
22. HashiCorp 协议变更（Apache 2.0 → BSL，2023 年）及 OpenTofu 分支事件：hashicorp.com/blog
23. MariaDB 基金会关于 MySQL 分支的背景说明：mariadb.org
24. Elastic 从 Apache 2.0 切换至 SSPL/ELv2 的官方声明（Elastic Blog，2021 年）：elastic.co/blog
25. OpenSearch（AWS Fork 自 Elasticsearch）公告：opensearch.org
26. Redis 协议变更至 RSAL/SSPL 双许可及 Valkey 分支事件（Linux Foundation，2024 年）：linuxfoundation.org
27. 木兰开源社区（OpenAtom）关于 Mulan 协议家族的官方说明：license.coscl.org.cn

上一篇：OpenHarmony 与开放原子基金会：大厂捐赠意味着什么

下一篇：中国 GPL 诉讼第一案系列：数字天堂、不乱买、罗盒