宽松还是紧缩? 厂商应如何选择开源协议

digoal2026年05月10日约 3 分钟

本期播客

如果你是一家软件厂商, 想通过开源造势, 构建生态. 应该如何选择开源协议?

你会选择宽松的还是紧缩的开源协议?

逻辑是什么?

未来还能修改开源协议吗?

这些问题相信每一位想搞开源的企业都思考过.

今天咱们来做一个回顾和逻辑推演.

站在 2026 年的时间点回顾，开源协议的版图正在经历自 1998 年“开源”定义诞生以来最深刻的两极分化。

未来的趋势可以概括为： “上帝的归上帝，凯撒的归凯撒” 。简单来说，开发者工具将继续拥抱极度自由，而作为商业基础设施的数据库，则会全面转向“有条件的开放”。

以下是未来几种主流协议的流行趋势预测及逻辑推演：

BSL 不是一种严格意义上的“开源协议”（未通过 OSI 认证），但它正在成为商业数据库厂商的首选。

运行逻辑： 它设定一个 “转正期” （通常为 3-4 年）。代码在初始发布时是商业受限的（例如禁止云厂商倒卖），但 4 年后会自动转化为纯正的 Apache 2.0 协议。
为什么流行： 它解决了厂商的“安全感”问题。它像是一个专利保护期：在技术最领先的前几年，厂商独占商业红利；等技术成熟、壁垒降低后，代码归还给社区。
典型趋势： 继 MariaDB、CockroachDB、HashiCorp 之后，越来越多的数据库初创公司在 A 轮融资后会直接选择 BSL，而不是先 Apache 再修改。

SSPL 虽然饱受争议，但它开创了 “针对云厂商传染” 的先河。

未来演进： 纯粹的 SSPL 可能会减少，但其核心条款会被吸纳进各种“云服务条款”中。未来会流行一种 “反云包装协议” ：允许个人用户、企业内部自由使用，甚至允许集成到闭源软件里，但唯独禁止“以数据库托管服务（Managed Service）”的形式进行售卖。
适用语境： 那些拥有极强“数据引力”的 NoSQL 或时序数据库（如 MongoDB）会坚持这一路线。

对于库、驱动程序、前端框架等非独立盈利的组件，宽松协议依然是绝对主流。

逻辑： 如果一个数据库的客户端驱动不是 MIT 协议，开发者根本不会去尝试。
流行领域： 嵌入式数据库（如 SQLite 类似物）、数据库周边中间件。
数据支撑： 在 2025-2026 年的 GitHub 新增项目中，MIT 依然占据 90% 以上。因为对于这些项目， “传播力”大于“保护力” 。

这是一个值得警惕的趋势。随着云厂商（AWS, Azure）开始深度介入数据库研发，他们不再倾向于“开源”，而是转向“源头可用”。

特征： 代码你可以在 GitHub 上看到，你也可以下载编译，但没有任何修改和分发的权利。
流行原因： 随着 AI 辅助编程（如 GitHub Copilot）的普及，厂商发现“代码可见”对于开发者调试非常重要，但“代码可分发”对商业利益有害。因此，只给看、不给动的“数字橱窗”模式会增多。

我们下次专门来介绍最近几年被迫兴起的一系列“源头可用”的开源协议.

协议类型	流行度趋势	核心目标	适用对象
BSL	激增	保护研发投入，平衡社区信任	商业数据库原厂 (TiDB, CockroachDB等)
MIT/Apache	平稳	追求极致的普及率和生态接入	驱动、工具、标准协议、AI 模型接口
SSPL 变体	局部强力	针对云巨头的防御性商业竞争	具有高运维门槛的分布式数据库
GPL/AGPL	萎缩	理想主义的自由软件精神	个人作品、非商业学术项目

我的洞察：
未来的开源世界将不再有统一的“自由”定义。 “License 动态化” 会成为常态 —— 一个项目可能在测试期用 Apache 2.0 骗取用户，在成长期转 BSL 保护利润，在衰退期回馈给 Apache 基金会。