AWS收购DuckDB后的信任三件套：开源+基金会+MIT

2026 年 8–9 月，三个独立事件把同一件事讲了三遍：AWS 收购 DuckLabs 时明确 DuckDB 维持 MIT 许可并由基金会托管；MariaDB Foundation 明确拒绝 fork Galera Cluster，让社区转向 Percona XtraDB Cluster 9.7；Percona 借机接管 PXC 9.7 用户群。被收购后社区的“信任底线”到底在哪？这三件事合在一起，给出了 2026 年开源数据库收购的标配条款。

一、AWS 收购 DuckLabs：DuckDB 进入“基金会 + MIT”模式

2026 年 8 月 26 日，Amazon 官方宣布已签署收购总部位于阿姆斯特丹的 DuckLabs 的最终协议。DuckLabs 是开源分析型数据库 DuckDB 的母公司，由 Hannes Mühleisen 和 Mark Raasveldt 联合创立。

收购条款中最关键的三条：

1. DuckDB 维持 MIT 许可证——Amazon 明确“不收购 DuckDB 开源项目”，MIT 许可不变。
2. 独立基金会托管——非营利的 DuckDB Foundation 继续管理项目，并成立技术顾问委员会。
3. 核心团队留任——Mühleisen 与 Raasveldt 继续在 AWS 内领导技术方向，团队留在阿姆斯特丹。

AWS 副总裁 Andy Warfield 在 All Things Distributed 博客中讲得更直白：“AWS 想让 DuckDB 继续按过去 8 年的速度演进，并保留让开发者喜爱它的所有特性——社区、开发节奏、应用领域。” AWS 已与 DuckLabs 合作超过一年，期间共同把 Iceberg 扩展做到每周 80 万次下载，并推动了 2.0 版本即将到来的 async I/O 改造。

这个案子的“反向操作”到底特别在哪？AWS 没有像传统大厂收购那样把项目“导流到自家云服务”，而是反过来——承认 DuckDB 的核心价值在社区与开发者体验，把这部分锁定在 MIT + 基金会，自家只接手商业化与基础设施整合。

二、MariaDB Foundation 拒绝 fork Galera：开源基金会的边界在哪

时间线往回拨：

• 2025 年 5 月：MariaDB Corporation 收购 Galera Cluster 的原作者 Codership Oy，连同 Galera Cluster for MySQL。
• 2026 年初：MariaDB Corp 宣布将在 9 月底停止对 Galera Cluster for MySQL 8.4 的支持。
• 2026 年中：MariaDB Corp 又表示将不再在 Community Edition 中支持 Galera Cluster（for MariaDB）。
• 社区反应：强烈反弹——大量依赖 Galera 做高可用的 MySQL 用户（电商、SaaS、金融客户）找不到合适的开源替代。
• MariaDB Corp 部分退让：声明“现在不是做重大变更的时机”，保留 Community Edition 中的 Galera 支持，但承诺措辞含糊。
• MariaDB Foundation 表态：明确“不打算 fork Galera Cluster，也不支持或鼓励这种行为”。

这意味着 MariaDB Foundation 给自己划了一条清晰边界：它只负责 MariaDB Server 本体，对于“附属项目被收购后是否 fork”这种问题，基金会选择“不介入”。这个选择让社区失去了 fork 路径，但也让 MariaDB Foundation 的中立性更可信——它不会被指责“借机 fork 抢 Codership 遗产”。

三、Percona XtraDB Cluster 9.7 GA：唯一继续维护“类 Galera” MySQL 集群的开源选项

2026 年 9 月 10 日，Percona 发布 PXC 9.7（基于 MySQL 9.7.1 + Galera 改进分支，提供 wsrep 兼容协议）。这是 MariaDB Corp 放弃 Galera 后，社区唯一能直接迁过去的“类 Galera” MySQL 集群选项。

PXC 9.7 的关键点：

• 兼容 MySQL 9.7 LTS 数据格式
• 提供 wsrep 协议兼容，应用层无需修改
• Percona 自有维护节奏（不走 MariaDB 的合并窗口）
• 同步发布到 Docker / Helm / AWS / Azure / GCP Marketplace

FromDual 在迁移指南中明确：“社区在两周内集体迁移到 Percona XtraDB Cluster”。这种“两周内迁移完成”的集体行动，只有在“原方案维护者明确放弃 + 替代方案接口完全兼容”两个条件同时成立时才可能发生。PXC 9.7 的发布是 2026 年 MySQL 高可用领域最关键的一次生态重组。

四、为什么“开源 + 基金会 + MIT”成为标配

把三件事并排看，可以提炼出 2026 年开源数据库收购的“信任三件套”：

条款	目的	不做的代价
开源	维持社区可见、可审计、可 fork	社区立即分叉，开发资源稀释
基金会	把治理权从商业公司剥离	任何商业决策都会被怀疑“是不是为了营收”
MIT	最大化二次使用自由度	Apache / GPL / AGPL 都会带来合规摩擦

AWS 收购 DuckLabs 时把三件套全部明示；MariaDB Foundation 通过拒绝 fork Galera 间接证明“基金会不会介入商业决策”；Percona 通过维持 MySQL 协议兼容证明“开源生态的迁移路径是可用的”。三件事讲的是同一句话：当收购不可避免时，“开源 + 基金会 + MIT”是维持社区信任的唯一路径。

背后是 2018 年 MongoDB 改 SSPL、2021 年 Elastic 改 SSPL、2024 年 HashiCorp 改 BSL 三次“开源许可证变更”给整个行业留下的教训：开发者对“许可证收窄”的容忍度极低，一旦收紧，社区立即迁移到 fork 或替代方案。2026 年的收购方学到了——与其冒险收紧，不如从一开始就明示“开源 + 基金会 + MIT”。开源协议的选择，从来就不是法律团队单独能拍板的事。

五、对国产数据库（openGauss / OceanBase / TiDB）出海与被收的启示

国产数据库如果未来要做“出海”或“被国际厂商战略投资 / 收购”，三件事是必须前置回答的：

1. License 是不是 MIT / Apache 2.0 / BSD 这类“宽松”许可？ Apache 2.0 是底线，MIT 是上限。AGPL / SSPL / 商业许可证会在欧美市场立即被合规团队拦截。
2. 有没有独立基金会托管？ Linux Foundation、Apache Foundation、CNCF 是已经被开发者接受的“白名单”。新设基金会需要时间建立信任，建议直接挂靠现有基金会。
3. 核心团队留任条款是否清楚？ AWS 收购 DuckLabs 时明示“团队留在阿姆斯特丹”，这一点对社区情绪的影响不亚于许可证本身。开发者不信任“被收购后团队半年内离职”的剧本。

反过来，对国产数据库厂商来说，如果要做“收购海外开源项目”或“战略投资海外开源公司”，同样要尊重三件套。MariaDB Foundation 处置 Galera 的先例说明，被收购方完全有理由拒绝 fork——这意味着收购方必须从一开始就规划好“开源 + 基金会 + MIT”的全部细节，否则签约之后可能被社区反噬。

六、给开源项目维护者的结论

对正在维护开源数据库项目的团队（无论国内外），三件套不是“做大以后再考虑”的事，而是立项时就要写进章程的事：

1. License 选择在第一天：选 MIT / Apache 2.0，避免 GPL / AGPL / 商业许可。
2. 基金会治理在第一个外部贡献者加入时设立：不要等到被收购才匆忙成立基金会，那时社区已经怀疑治理动机。
3. 治理结构文档化：技术决策权、商业决策权、人事决策权分别在谁手里，写清楚并公开。

2026 年已经证明：开源数据库项目的“长期价值”不在代码量，而在社区信任。社区信任的具体载体，就是“开源 + 基金会 + MIT”三件套。

数据来源：

• AWS Big Data 博客：“AWS and DuckLabs: Building the future of analytics together”
• aboutamazon.com：“AWS to acquire DuckLabs”
• DuckLabs 官方公告：“DuckLabs to Join AWS, Projects to Remain Open Source”
• Andy Warfield：“DuckDB and the changing physics of analytics”（All Things Distributed）
• FromDual：“Percona releases Galera Cluster Version 9.7”
• Percona 文档：“Percona Distribution for MySQL 9.7.1 using Percona XtraDB Cluster”
• MariaDB Foundation 关于 Galera fork 的官方表态