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

本期播客

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

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

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

逻辑是什么?

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

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

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

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

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

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

1. 商业基础设施：BSL (Business Source License) 将成为“事实标准”

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

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

2. 云原生防御战：SSPL (Server Side Public License) 的“变体”

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

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

3. 开发者生态：MIT/Apache 2.0 依然是“入场券”

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

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

4. 巨头的复仇：从开源转向“源头可用 (Source Available)”

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

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

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

总结：未来三年的协议格局

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