商业源码协议为何得到 HashiCorp 等企业的垂青
一、事件概述
1. 新闻背景
当地时间 2023 年 8 月 10 日，知名开源软件公司 HashiCorp 发布公告，宣布其原先在 Mozilla Public License 2.0 协议下发布的 Terraform、Consul 和 Vault 等多款软件，将在未来的版本中改为使用商业源码协议（Business Source License 1.1）来发布。
2. 核心内容
商业源码协议（Business Source License，简称 BSL 或 BuSL）是由 MariaDB 公司创建的一种带有商业保护条款的源码公开协议。该协议当前版本为 1.1，在 Linux 基金会的 SPDX 标准中以 BUSL-1.1 作为标识符。
3. 涉及企业
除 HashiCorp 外，还有多家知名企业采用了商业源码协议：
- MariaDB 公司的 MaxScale 数据库代理
- CockroachLabs 公司的 CockroachDB 数据库
- Lightbend 公司的 Akka 框架
- Materialize 公司的 Materialize 流数据库
- Outline 公司的 Outline 知识库
二、商业源码协议详解
1. 协议特点
BuSL 1.1 协议在实际使用时具有以下两个核心特点：
A. 生产环境使用限制
协议授权接收方复制、修改、衍生和重新分发被许可软件的权利，但只能在非生产环境下使用该软件。许可方可在附加使用条款中允许其他受限的生产环境使用条款。由于 BuSL 1.1 不授权接收方使用不同协议分发的权利，因此生产环境使用的限制将传递到所有直接或间接的下游。
B. 时间限制与协议变更
协议约定一个不超过四年的期限。在该期限过后，接收方将获得许可方指定的变更协议授予的权限，同时生产环境使用限制条款终止。变更协议必须与 GPL 2.0 或更高版本兼容。
2. 与开源协议的区别
BuSL 1.1 协议并非开源协议，因为它限制生产环境的使用，这不符合开源定义中的第六条"不得歧视特定领域的使用"。BuSL 1.1 在协议文本说明中也直接说明了这一点。
3. 协议模板性质
与同类型的 Elastic License 2.0（ELv2）协议相比，BuSL 1.1 更像一个协议模板。使用时需要决定：
- 是否约定一个小于四年的协议变更期限
- 是否在附加使用条款中允许客户在其他特定生产环境使用
三、商业源码协议应用案例分析
1. MaxScale（MariaDB）
作为协议诞生之地，MaxScale 约定了最长的四年变更期限，并以 GPL 2.0 or later 作为变更协议。
生产环境使用条款：
You may use the Licensed Work when your application uses the
Licensed Work with a total of less than three server instances
in production.分析：允许单个应用部署不超过三个节点，限制了大规模集群场景，允许个人用户和小企业使用，促使需要维护大集群的更有实力付费的用户购买商业许可。
2. CockroachDB（CockroachLabs）
CockroachLabs 起初使用 Apache License 2.0（ALv2），后续开发了 CockroachDB Community License Agreement 来发布高级功能，几年后发现仍无法达成商业目标，最终将核心部分改用 BuSL 1.1 协议。
配置：
- 变更期限：三年半
- 变更协议：ALv2
生产环境使用条款：
You may make use of the Licensed Work, provided that you may not
use the Licensed Work for a Database Service.分析：不限制一般意义上的集群使用，仅限制下游使用 CockroachDB 提供数据库服务。这属于禁止竞争条款，因为 CockroachLabs 本身以提供数据库服务盈利。
3. Redpanda
Redpanda 全面复刻了 CockroachLabs 的策略：创建自己的 Community License Agreement，同时使用 BuSL 1.1 许可核心代码。
配置：
- 变更期限：四年
- 变更协议：ALv2
生产环境使用条款：
You may make use of the Licensed Work, provided that you may not
use the Licensed Work for a Streaming or Queuing Service.分析：限制与 CockroachDB 类似，允许用户内部使用，但禁止向外部用户提供消息队列功能。内部使用基本不受影响，因为内部使用属于雇员或合同工创建主题的例外范畴。
4. Materialize
Materialize 从一开始就使用 BuSL 1.1 协议。
配置：
- 变更期限：四年
- 变更协议：ALv2
生产环境使用条款：
Within a single installation of Materialize, you may create one
compute cluster with one single-process replica for any purpose...
(a) you may not create installations with multiple clusters, nor
compute clusters with multiple replicas...
(b) you may not use the Licensed Work for a Database Service.分析：同时采用 MaxScale 和 CockroachDB 的限制，即不能创建大集群，也不能提供数据库服务。
5. Outline
Outline 是知识库产品，对标本 Notion 或印象笔记。
配置：
- 变更期限：四年
- 变更协议：ALv2
生产环境使用条款：
You may make use of the Licensed Work, provided that you may not
use the Licensed Work for a Document Service.分析：仿照 CockroachLabs 的写法，把数据库服务改成文档服务。允许公司内部做知识库构建，允许外部用户查看，但不允许外部用户创建团队和文档。
6. Akka（Lightbend）
Akka 是久负盛名的 Scala 语言异步通信和应用开发框架，从 2009 年到 2022 年已以 ALv2 发布十多年。
配置：
- 变更期限：三年
- 变更协议：ALv2
生产环境使用条款：
If you develop an application using a version of Play Framework
that utilizes binary versions of akka-streams and its dependencies,
you may use such binary versions of akka-streams and its dependencies
in the development of your application only as they are incorporated
into Play Framework...分析：任何情况都不能在生产环境部署 Akka 应用，除非使用 Play 框架开发且应用中没有直接和 Akka 的接口通信。这是最严格的 BuSL 1.1 实例。Lightbend 提到年收入在一千万美元以下的公司可申请免费使用许可。
7. HashiCorp
HashiCorp 选择了四年的"保护期"，变更协议是此前采用的 MPL 2.0 协议。
生产环境使用条款：
You may make production use of the Licensed Work, provided such use
does not include offering the Licensed Work to third parties on a
hosted or embedded basis which is competitive with HashiCorp's products分析：这是带有兜底条款的竞业限制协议，限制非常模糊。HashiCorp 对"竞争"的解释不明确，建议用户如有疑问联系律师。
四、企业采用商业源码协议的深层动机
1. 开源商业模式困境
许多自诩"开源商业公司"的企业初期不提供商业收费版本，投入巨大人力开发唯一的开源软件，但发现用户只是使用而不付费，甚至有供应商拿代码修改后做出竞争解决方案，且由于上游使用宽容开源许可，这些供应商可以隐藏源代码。这超出了企业创始人的预料，修改软件许可就成为了必然选择。
2. 云厂商竞争压力
云厂商搭建的完善交付体系，挤压了采用原先商业模式的开源商业公司的生存空间。作为反制，Red Hat 虽然不能修改 Linux 的软件协议，但通过改变其发行版的打包流水线，增加了云厂商原封不动打包交付的难度。
3. 商业保护需求
如果商业模型是销售开源软件本身的功能，那么核心功能转向专有软件只不过是时间问题。商业源码协议提供了相对最优解：绝大部分和开源协议一样，但是禁止直接商业竞争。
graph TD
A[开源软件] --> B{商业模式选择}
B --> C[完全开源]
B --> D[商业源码协议]
B --> E[完全闭源]
C --> F[云厂商免费搭便车]
D --> G[禁止直接商业竞争]
E --> H[失去社区贡献]
F --> I[原厂收入受损]
G --> J[保护核心收入]
H --> K[社区活力下降]
五、影响分析
1. 对开源社群的影响
核心参与者离开会重挫开源社群的可持续性。当开源社群中心的软件是企业产权，核心开发者都是公司雇员时，一旦公司倒台，大部分情况下软件也会随之消亡。
但也有反例：Akka 修改协议后，其庞大用户群自发从最后一个开源版本拉出分支，以 Apache Pekko 的名字继续维护。ElasticSearch、Redis 和 Kafka 这样的项目，没有公司做商业化也能持续下去。
2. 对开源软件本身的影响
开源软件只有很少一部分是由一家企业主导的。Redpanda 闹腾得再厉害，开源的标准是 Kafka 协议。不管 Redpanda 和 Confluent 是否存在，Kafka 会一直在。当初依靠做 Hadoop 生态发行版的企业几经浮沉，并没有太多影响 Hadoop 自己的发展。
3. 个人开发者的选择
Apache 基金会前任董事 Ted Dunning 的经验表明：用 Apache 协议发布软件后，会得到更多用户和宝贵反馈，而这才是开发者所期待的。作为个人，没有足够动力和时间向每一个商用用户索要费用。
正如 Ted 所说：如果不愿为授权费奔走，那么根本不必提出要求。因此，商业源码协议对个人开发者应该没有什么帮助。
六、各方反应
1. 企业辩白书
在企业转向带有商业保护条款的源码公开协议时，企业都会发布辩白书，提到同一个问题：自己投入人力开发的软件，商业对手却坐享其成，使得竞争对手在投入产出上存在优势。
这些企业随后会放大竞争对手的优势，控诉他们"不向上游回馈"，警告用户自己无法存续等于软件死亡。
2. 逻辑链条的问题
这个逻辑链条存在两个不成立的地方：
A. 增长受挫而非无法持续
挑战通常不是无法持续，而是无法扩张。资本的本性就是扩张，MongoDB、Elastic 和 CockroachDB 控诉 AWS 等云厂商竞争导致丢掉客户，实际上是增长受挫的反应。
B. 公司不等于社群
公司死了，开源软件有用，未必它就不能发展。Akka 修改协议后，用户群自发拉出分支继续维护就是明证。
七、技术趋势展望
1. 协议演进的螺旋上升
企业选择带有商业保护条款的源码公开协议，可以看做是从完全闭源的商业协议，到冒进的全面开源协议，之后的一次螺旋上升的准备。开源协议是完善的，它解决了源代码如何自由分享的问题。
2. 个人开源的价值
对于个人开发者来说，采用真正的开源协议（如 Apache、MIT）可以获得更多用户反馈和社区贡献，这是软件发展更重要的推动力。
3. 社群自我修复能力
开源社群具有强大的自我修复能力。当企业主导的项目转向商业源码协议时，社群往往会 fork 出一个完全开源的版本继续维护。Apache Pekko 的出现就是最好的证明。
八、总结
商业源码协议是开源商业公司在现有市场经济体制下找到的相对最优解。它既保留了源代码公开的特性，又通过禁止直接商业竞争来保护原厂的核心收入来源。
但是，开源软件的价值在于开放的协作和共享，而不是企业的商业利益。企业可以选择商业源码协议，但开源社群也会选择自己的道路。正如 Kafka 之于 Redpanda，Linux 之于各类发行版，真正的开源项目会超越任何单一企业而持续发展。
对于个人开发者而言，选择真正的开源协议，拥抱开放的社群，或许才是更有价值的道路。