译序

我在此前的多篇文章中讨论了商业开源的话题：

• 《企业开源的软件协议模型实践》
• 《企业实践开源的动机》
• 《商业源码协议为何得到 HashiCorp 等企业的垂青？》
• 《企业如何实践开源协同》
• 《中国不缺好的开源开发者》“商业探索与可持续”一节
• 《开源不是商业模式》
• 《诱导转向的伪开源战略》
• 《免费增值的商业模式》

这些讨论当中观点的源头，除了我在商业开源公司的工作经历以外，也有对国外企业主和律师的内容的理解。其中，撰写了《Open Source for Business》（中文版为开放原子开源基金会律师刘伟翻译的《商业开源》）的大律师 Heather Meeker 的观点尤为重要。早在夜天之书 #6 一文里，我就引用过 Heather Meeker 的观点。

今年五月份前后，我读到了 Elastic License 2.0 and the Evolution of Open Source Licensing 一文。它是 Heather Meeker 律师带头撰写 Elastic License 2.0 协议背后的故事和自述。我深感它对于近五年商业开源软件形势发展的影响，于是向 Heather Meeker 申请了翻译本文的授权。今天终于有时间完成翻译，希望能帮助国内关注商业开源的企业家、开发者以及律师，了解发生在北美软件行业的一系列变化。

以下原文翻译。

2021 年 2 月，Elastic 发布了其软件产品的新协议，即 Elastic License 2.0 协议。通过这一举措，包括 ElasticSearch 和 Kibana 在内的一系列重要软件采用了一种新的、公开的以及简化的协议模型。这一变化是如何发生的？其背后的原因是什么？这些变化又意味着什么呢？

Elastic 的新协议是针对采用开放发展模式的公司在软件协议最佳实践方面的一个重要趋势的结晶。它并不是一个开源协议，但它旨在设定最低限度的限制，以在自由使用、共享和修改软件之间取得平衡，并防止对社群造成损害的行为的发生。

UNIX / Linux / 自由软件 / 开源

要想理解 Elastic License 2.0 所代表的新协议趋势，知道它是如何从开源协议运动中发展而来的至关重要。

开源运动或自由软件运动，源于开发者对软件私有化和软件开发分叉的担忧。UNIX 的一系列操作是这些担忧的来源。

UNIX 是当时最流行的操作系统。多年来，UNIX 的许可条件非常慷慨，因为它的开发者 AT&T 贝尔实验室受制于 1956 年的同意法令，不能从其研究项目中获利，其中包括 UNIX 和 C 语言。学者、研究人员和开发者开始分享他们的改动和改进，因此 UNIX 很快成为操作系统的领导者。

原注 “Modification of Final Judgment,” August 24, 1982, filed in case 82-0192, United States of America v. Western Electric Company, Incorporated, and American Telephone and Telegraph Company, U.S. District Court for the District of Columbia web.archive.org/web/20060827191354/members.cox.

然而，上述同意法令在 1983 年一经解除，AT&T 就立刻根据传统的商业条款设计不允许分享更改的软件协议。此后，UNIX 分裂成许多不兼容的版本，并且其专有软件协议禁止用户像以前那样通过分享改动进行合作。

自由软件运动以及随后的开源运动是对 UNIX 私有化的回应。它们试图防止基础设施软件再次走向封闭。这个运动以 UNIX 的自由软件替代品 Linux 为中心，并很快发展成一个认为“所有软件生而自由”的具有巨大影响力的运动。这个运动的核心理念包括用户有权访问源代码、改进软件和分享软件的改进版本。这些原则体现在 GNU 通用公共协议（GPL）中，该协议要求二进制文件的分发者必须向接受者免费提供相应的源代码。

随着时间的推移，尤其是 2000 年初互联网的兴起，开源协议变得越来越受欢迎。尽管部分开源协议（例如 GPL 协议）新颖且复杂，引发了一些法律上的担忧，但它们为企业间的合作铺平了道路。很快，开源以及它所促进的合作被整个技术行业全心接受。如今，开源是电子商务的支柱，企业经常合作开发基础软件。

云的兴起和 AGPL 协议

GPL 协议要求分享修改后的源代码，但是这个要求只在二进制分发时生效，即取得二进制的人有权索要源代码。但是，这意味着 GPL 允许制作和使用“私有版本”：如果不对外分发二进制，也就无需分享更改。在大多数软件仍然依靠本地分发的年代，这种方式有效地促使了分享。从 2000 年开始，软件交付开始向公共云迁移，软件服务提供商不再需要直接向客户分发任何二进制文件。相反，客户可以在不获取本地副本的情况下使用软件。

随着云服务的业务规模增长，这种范式转变激化了部分开源社群和 AWS 等企业之间的紧张关系。云厂商没有任何法律义务分享他们的改进。有点讽刺的是，这种情况有时被称为“Google 漏洞”。“Google 漏洞”这一称谓之所以说讽刺，是因为尽管谷歌依赖 Linux 来支持其搜索服务，但是谷歌和许多其他顶级云厂商（如 IBM 等）为包括 Linux 在内的开源社群做出过重大贡献。

自由软件社群对此的回应，是创造了一种名为 Affero GPL (AGPL) 的 GPL 替代形式。AGPL 3.0 与 GPL 3.0 几乎完全相同，但增加了一个远程网络交互条款，该条款规定：“如果你修改了程序，你的修改版本必须明显地向通过计算机网络与之远程交互的所有用户，提供通过某种标准或习惯的软件复制方式，无偿地从网络服务器获得您版本的相应源代码的支持。”这个新的协议旨在强制云厂商分享它们的源代码改进，从而再现 GPL 约束 Linux 发行版开放其源代码的成功。

If you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software….

AGPL 和双重许可

AGPL 自首次发布以来就备受争议。

在 GPL 3.0 起草并最终于 2007 年发布的过程中，有一派人想将 GPL 改为与如今的 AGPL 一样的网络共享模型。然而，自由软件社群最终决定保留 GPL 3.0 中的“漏洞”。

几个月后，自由软件基金会发布了 AGPL 作为解决该漏洞的替代方案。但是 AGPL 并没有得到广泛采用。不过，就像 GPL 有 Linux 这一杀手级应用，AGPL 也有自己的杀手级应用，这就是 MongoDB 数据库。

MongoDB 是一款非常受欢迎的分布式数据库产品。虽然一开始，很多企业难以理解和接受 AGPL 协议，但是大多数用户从未更改过软件，也没有将其作为服务提供，因此他们能够理性地决定在 AGPL 下使用该软件。

MongoDB 基于 AGPL 协议设计了它的双重许可商业模型，即软件可以根据被许可人选择的两种协议之一提供：（1）AGPL 协议（2）经过协商取得的商业软件协议。那些不希望遵守 AGPL 要求，或不愿进行法律分析以确定是否能够遵守的人，选择购买商业软件协议。

这种商业模型最初由 MySQL 开创，MySQL 当时使用了 GPL 的一个变种。随着时间的推移，AGPL 成为双重许可模式的首选软件协议。MongoDB 在这种协议模型下取得了相当的成功。AGPL 是常用软件协议里最强的强制共享（Copyleft）软件协议，因此在推动商业谈判方面最有用，也就被用在双重许可模型上。但是，AGPL 的起草者批评了这种使用 AGPL 的方式，称该商业模型是一种有害的勒索行为。尽管如此，APL 的源码分享条件并不足以阻止企业在不给开发者或用户社群带来任何回报的前提下大规模商用。

Strip-mining

译注：国外开源语境下的 strip-mining 含义和国内所谓的“白嫖开源”意义类似。

就像云计算的发展打破了基于 GPL 的双重许可模型一样，2010 年代云计算的进步，云交付模式开始对基于 AGPL 的双重许可模型施加压力。

这次问题有所不同，“漏洞”出现在 GPL 或 AGPL 的范围仅限于一个单独的程序可执行文件。这个“漏洞”是有意设计到 GPL 中的，理论上，版权协议只能为一个可受版权保护的作品规定条款。因此，GPL 对衍生作品（derivative works）有源代码共享的要求，但对集体作品（collective works）没有。在法律上，这两者之间的界线非常模糊，完全取决于观察者的主观看法。但在过去，随着 GPL 的普及，强大的行业实践已经形成：一个程序被定义为一个可执行进程。自由软件基金会在其 GPL FAQ 中长期阐述了这些原则。

然而，随着云服务的发展，发生了两件事：

1. 软件工程越来越专注于云部署。云厂商曾经需要修改开源软件以使其能在云环境中正确运行，但软件工程的进步使现有的开源软件更加适应云厂商的“即插即用”需求。也就是说，不用修改一行代码，开源软件也可以与云基础设施良好的集成。
2. 云厂商开始在核心开源软件之外进行创新。他们开发了额外的软件来管理、监控和部署软件。这些创新推动了云服务的业务增长。同时，它们是跟核心开源软件独立的软件，即使核心软件以 AGPL 发布，也无法强制云厂商分享这些辅助软件的源代码。

这两者相结合形成了这样一种形势：商业开源公司实际上成为大型云厂商“资产负债表以外的研发机构”。这个问题在开源的平台软件或中间件方面尤为突出，因为这些软件位于顶层应用程序和操作系统之间，在应用程序栈中起着重要作用，且对于云部署非常有用。

这种变化在商业界引起了对云厂商使用开源软件的强烈抗议。在 2018 年的一份具有里程碑意义的宣言中，贝恩资本的 Salil Deshpande 写道：“明确地说，这并不违法。但我们认为这是错误的，不利于开源社群的可持续发展。”另一位评论家写道：“AWS 正在攻击开源的阿喀琉斯之踵：窃取他人的工作，并销售租赁这些工作成果的服务。”问题在于，所有主要的开源协议都允许以这种方式使用软件。

商业开源公司及其投资者对开源模型的局限感到不满，他们手头没有任何软件协议可以利用版权法强制云厂商进行共享。即使是 GPL 和 AGPL 也对此无能为力。

同时，拥有庞大客户群的云厂商可以为开源软件提供更好的云平台集成。在 AWS、Azure 或 Google Cloud 平台上，客户可以轻松地一键添加软件。一些开源软件的开发者提供了自己的云服务，但是发现与免费使用他们开发的开源软件的大型云厂商竞争太困难了。即使开发者的服务更好，与云厂商建立合作关系也存在交易成本，而不仅仅是云厂商原生集成服务的一键集成体验。

SSPL 和源码可得协议

在 2018 年，整个行业的发展来到了一个临界点：随着 AWS 等云厂商持续不断地通过托管开源软件挣钱，开发者们开始采取应对措施，首先就是一系列快速的软件协议变更。

商业开源公司对 strip-mining 问题做出了两种不同的反应：一种是超强网络共享软件协议，另一种是带有限制条件的源码可得协议。在此之前，还没有人对这两类协议进行明确定义。这两类协议都旨在支持双重许可模型，即引导潜在客户经过协商购买商业软件协议，就像帮助构建 MySQL 和 MongoDB 的模式一样。

超强网络共享软件协议的方法由 MongoDB 推进发展，他们在 2018 年发布了 Server Side Public License (SSPL) 协议。SSPL 与 AGPL 几乎完全相同，但扩展了 AGPL 的远程网络条款，如下所述：

13. Offering the Program as a Service.

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available. [emphasis added].

译注：法律文本翻译极其拗口，这里放原文。主要 SSPL 跟 AGPL 的区别就在于 AGPL 仅对衍生作品提出分享源码的要求，即前文所述的运行在同一进程的代码，而 SSPL 定义了 Service Source Code 的概念，即要求整个服务栈相关的代码都需要以 SSPL 的条款提供。

SSPL 的编写旨在为 strip-mining 问题提供一个开源解决方案。它的源码共享要求比 AGPL 更广泛。这种更广泛的源码共享描述被有意设计成类似于 GPL 对分发软件的要求的形式。MongoDB 继续采用双重许可模型，其软件可根据 SSPL 协议或经过协商的商业软件协议提供。

MongoDB 将 SSPL 提交给开源促进会（OSI）审议。经过数月的激烈争议后，SSPL 的 OSI 认证申请被驳回，但 MongoDB 继续在其双重许可模型的“开源”选项中使用 SSPL 协议。关于为什么 SSPL 符合或不符合开源定义，讨论很复杂。不过，符合开源定义并不是唯一的争论点，总体而言，这个要求共享范围如此广泛的软件协议是否能够“保证软件自由”，尚且没有一个明确的结论。

其他人选择了不同的道路。一些公司采用了由 Salil Deshpande 主持编写的 Commons Clause 条款，而其他公司则自行制定了软件协议，例如 Redis、Confluent 和 CockroachDB 等，以及 Elastic 公司的 Elastic License 1.0 协议。不同于 SSPL 协议，这些软件协议从未期望符合开源定义。相反，它们具有专门针对 strip-mining 的限制条款。

为什么选择了这些不同的道路？这与一个被称为 Freedom 0 的概念有关。Freedom 0 的内容是：用户按照自己的意愿运行程序，用于任何目的的自由。

原注：自由软件定义和开源定义类似，但是更加简短和清晰。

开源或自由软件协议的主要特点之一，就是它不包含任何许可限制或限制条件。

原注：开源协议可以包含条件，例如发布时包含 NOTICE 文件或要求共享源代码，但是这些并不是限制用户使用软件的规定。它们只要求如果用户选择执行某些操作，您也必须执行其他操作。（译注：例如，GPL 允许用户自由使用，但是如果一个人要分发修改版本的二进制，那么分发者需要保证接收者能够以和 GPL 相同的条款使用修改版本，其中包括取得修改版本的源代码。）

相比于典型的商业软件协议，终端用户协议只允许用户使用软件，但不允许分发或修改；企业软件协议通常限制软件使用的用户数、服务器数或物理位置，并要求公司对其使用进行审计。但是，开源协议不包含任何此类限制。因此，可能有些反直觉，虽然开源软件源代码总是免费提供，但是如果一个自称开源协议限制软件的非商业使用，那么它也违反了开源定义。

这意味着任何许可限制都使软件协议不再属于开源协议。

在 2018 年及以后的重新许可浪潮中发布的所有协议都具有大致相似的限制。虽然每个协议都有自己的条款，但它们都侧重于允许用户免费使用软件，同时禁止使用软件提供竞争性的托管服务。

Elastic License 2.0

在2021年初，Elastic 开辟了新的道路，同时选择了上述两种路径。它使用 SSPL 和 Elastic License 2.0 (ELv2) 对 ElasticSearch 进行双重许可。

ELv2 非常简短。它用通俗的语言编写，内容总共只有一页多。ELv2 授予用户一个典型开源协议授予的几乎所有自由。软件的接收者可以自由使用、更改和重新分发软件。即使您以前从未阅读过软件协议，也值得一读。

ELv2 在上述自由之外有两个关键限制：

You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key functionality in the software, and you may not remove or obscure any functionality in the software that is protected by the license key.

第一条限制是为了解决 strip-mining 问题。通过这条限制，ELv2 不授权接受者基于该软件提供托管服务。

第二条限制禁止破解软件许可密钥。这样的限制在软件许可中长期存在，但在源码可得协议中的使用刚刚开始。这些条款允许开发人员运行与软件交互的付费服务，或者保留一些软件组件用于付费功能。

ELv2 的其他条款非常直接，对于任何阅读过开源协议的人来说应该是熟悉的。

为什么选择双重许可？

在提供 SSPL 和 ELv2 两种选择给用户时，Elastic 选择了一条不寻常的道路。如今，许多公司采用“开放核心”模型，事实上，Elastic 之前也使用过这种模型。两者之间的区别可能很微妙。开放核心模型在开源协议下提供核心软件：通常使用 Apache License 2.0 这样的宽松开源协议。然后，这些公司开发额外的适用于大规模企业部署的功能，并只在限制型协议下提供，或者仅作为商业服务提供。但是，通过新的软件协议，Elastic 坚持采用双重许可模型，即相同的软件可在两种不同的软件协议下使用。这种模型由 MySQL 首创，通常使用类似 GPL、AGPL 或 SSPL 的强制共享协议作为免费软件协议选择。由于开源协议和云服务之间的紧张关系，这种模型在最近几年变得不太流行。

Elastic 的选择更加不寻常，因为它提供了两种免费的软件协议选择，SSPL 和 ELv2 都有免费使用的条款，而双重许可通常只提供一种免费选项。通过做出这个独特的选择，Elastic 强调了其灵活性，可以免费向几乎所有用户提供软件。

Elastic License 2.0 和软件协议的最新发展

Elastic 采用了新的软件协议模型，以尽可能保持开放性，同时保持对用户和开发人员公平可持续的商业模式。在这样做的过程中，它呼应了源代码可用运动中其他参与者的目标，并在创建软件协议时寻求同行的意见。

正如 ELv2 FAQ 提到的，Elastic 的软件协议变更预计不会对其客户群体产生影响，对社群用户的影响也很小。因为大多数用户在 Elastic 的软件上构建应用程序，并不从事“将软件作为托管或管理服务提供给第三方”的业务。

设计一个更好的软件协议

此外，通过投入资源起草 ELv2 协议，Elastic 努力推动软件协议起草的技术水平。从某种意义上说，源码可得协议的存在时间与软件一样长。事实上，仅二进制的软件协议是上世纪 80 年代 PC 平台标准化的产物；在那之前，几乎所有的软件都以源代码格式进行许可。但是随着时间的推移，软件协议的形式和部署方式发生了很大变化。

ELv2 是这一趋势的最终体现。在形式上，它采用了一些最受欢迎的开源协议特性：简单直观的起草和模板协议。它的密钥保留条款使得供应商发布同时包含免费功能和付费功能的软件事也能轻松地使用 ELv2 协议。

与几十年前专有 UNIX 的不兼容版本一样，专有软件协议是一个由自定义条款和条件组成的混乱合成体。即使是普通消费者软件产品的简单终端用户协议通常也很长，晦涩难懂，大多数用户无法理解。关于没人阅读用户协议的笑话屡见不鲜。但是，大部分复杂性是不必要的。这是开源协议的一个教训，特别是宽松开源协议：一套简单的规则就足够了，而且规则越易理解，用户越有可能遵守。

ELv2 不仅简短、简单和易理解，而且其他人也可以将其用作模板。自反对 strip-mining 的辩论开始以来，用户愈发希望出现一个能够支持流畅部署软件、可以具有合理限制，但是必须简单易懂的软件协议。但是，大多数小型软件公司没有资源来起草自己的协议。因此，毫不奇怪，许多软件初创公司都希望采用 ELv2 或 Confluent Community License 等现成软件协议来构成其软件协议模型。

这个趋势愈演愈烈，最终形成了一个名为 Fair Code 的倡议和标准，其中写到：

Fair-code is not a software license. It describes a software model where software:

• is generally free to use and can be distributed by anybody
• has its source code openly available
• can be extended by anybody in public and private communities
• is commercially restricted by its authors

虽然这项倡议还处于非常早期阶段，但显然行业开始意识到需要一个公平对待用户和开发者的范式。同时，这一范式还应当允许商业开发者，以一种比如今的开源协议更加灵活的方式，在两者之间取得平衡。一位评论员甚至将最近的软件协议发展称为后开源时代。不过事实上，在商业和软件协议模型不断发展的过程中，源码可得协议与开源协议通常是并行发展的。因此，这两种模型互补，而不是互为替代品。

同一时间，其他标准化的软件协议工作也在进行。2020 年，一群律师发起了 PolyForm 项目，起草了一系列源码可得协议模板。这些软件协议由在开源和专有协议方面经验丰富的律师进行同行评审。就像 Creative Commons 用于开放内容协议一样，它提供了一系列选项，如非商业、仅用于评估和反竞争协议。所有这些软件协议，就像 ELv2 一样，都允许免费使用、提供源代码，并授予必要的专利许可。PolyForm Perimeter 和 PolyForm Shield 与其前身 Confluent Community License 类似，而 ELv2 也遵循了这一趋势，推进了软件协议可选项的发展。

如果您有疑问或想要阅读更多信息，这里有一些资源：

• The rise of open source IPOs 这篇文章追踪了一些商业开源公司的成功案例。
• The After Open Source Era Has Started 这篇文章讨论了公司转向源码可得协议所代表的重大变革。
• 美国众议院司法委员会关于数字市场竞争调查的报告（由反垄断、商业和行政法小组牵头）请注意第 326 页提到了 Elastic 的例子。

注：本文的起草代表了我（Heather Meeker）的个人观点。然而，我想指出，撰写这篇白皮书的工作部分受到了 Elastic 的资助。

当地时间 8 月 10 日，知名开源软件公司 HashiCorp 发布一则公告，称其原先在 Mozilla Public License 2.0 下发布的 Terraform、Consul 和 Vault 等多款软件，将在未来的版本中改为使用商业源码协议，即 Business Source License 1.1 来发布。

此前，已有其他知名开源软件公司也改用或从一开始就使用商业源码协议许可其源码公开的软件。

• MariaDB 公司的产品 MaxScale 数据库代理；
• CockroachLabs 公司的产品 CockroachDB 数据库；
• Lightbend 公司的产品 Akka 框架；
• Materialize 公司的产品 Materialize 流数据库；
• Outline 公司的产品 Outline 知识库。

本文首先介绍商业源码协议的由来和内容，进而以剖析选择该协议的公司和软件的方式讨论其作用。最后，从企业开源的动机和利益权衡出发，讨论为何 HashiCorp 等一众所谓开源软件公司，最终都走向带有商业保护条款的源码公开协议。

什么是商业源码协议

商业源码协议是 Business Source License 的逐词翻译，常被简称为 BSL 协议或 BuSL 协议，当前版本是 1.1 版本。

在此前的文章中，我基本使用 BSL 1.1 来指代当前版本的商业源码协议。但是，在 Linux 基金会推动的 SPDX 标准里，商业源码协议以 BUSL-1.1 作为标识符。这是因为 BSL 被用来指代 Boost Software License 1.0 这个更早出现的协议：它是一个类似 MIT License 的协议。因此下文及以后的文章里，我会尽量用 BuSL 1.1 来指代商业源码协议。

BuSL 1.1 是 MariaDB 公司为其产品 MaxScale 数据库代理量身定制的带有商业保护条款的源码公开协议。该协议实际使用时必然带有以下两个特点：

第一，协议授权接收方复制、修改、衍生和重新分发被许可软件的权利，但是只能在非生产环境下使用该软件。许可方可能在附加使用条款中允许其他受限的生产环境使用条款。

由于 BuSL 1.1 不授权接收方即下游用户或开发者使用不同协议分发的权利，因此上述生产环境使用的限制将传递到所有直接或间接的下游。

第二，协议约定一个不超过四年的期限。在该期限过后，接收方将获得许可方指定的变更协议授予的权限，同时第一点中的条款终止。变更协议必须与 GPL 2.0 或更高版本兼容。

把这段协议文本翻译成人话，意思就是软件以 BuSL 1.1 协议发布后，在最多四年的期限后会“变成”以新协议发布。这个新协议必须是跟 GPL 兼容的协议，兼容方向是 GPL 许可的软件能够跟该协议许可的软件集成后以 GPL 发布。再直白点说，所有 Permissive 开源协议和 Copyleft 开源协议里选一个。

所以，BuSL 1.1 协议，比起同类型的 Elastic License 2.0 (ELv2) 协议拿来即用，更像是一个协议模板。要想使用 BuSL 1.1 协议，需要决定是否约定一个小于四年的协议变更期限，以及是否在附加使用条款中允许客户在其他特定生产环境使用。

当然，BuSL 1.1 协议在许可方契约一节里也约定了任何自称 BuSL 1.1 的填完空的具体协议，只能细化这两处，且不能与一开始就授予的复制、修改、衍生和重新分发等权利相冲突。

显然，BuSL 1.1 协议并不是开源协议，因为它限制生产环境的使用，而这不满足开源定义当中的第六条“不得歧视特定领域的使用”。BuSL 1.1 在其协议文本说明中也直接地说明了这点，同时提供了两份分别对于下游用户和许可方的常见问题解答：

• Frequently Asked Questions
• Adopting and Developing BSL Software

下面，我们从具体的应用案例出发，分析 BuSL 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.

简言之，可以在生产环境使用，但是单个应用不能部署超过三个节点。

这其实就是限制了大规模集群的场景，允许个人用户和小企业用起来，做产品反馈和帮助传播。对于需要维护大集群的用户，通常也是更有实力付费的用户，限制其使用，促使它们谈判商业合同付费购买使用许可。

CockroachDB

CockroachLabs 起初使用 Apache License 2.0 (ALv2) 来许可自己的数据库。随后开发出一套所谓的 CockroachDB Community License Agreement 来发布一些高级功能和插件，以图促使高级用户付费。

稍微展开一下这个 Community License Agreement 对下一节讨论协议采用动机有帮助，因为这个模式是在 ELv2 和 BuSL 1.1 出现之前开源商业公司追加商业保护条款的常见做法。

这个协议很长，所以对开发者极不友好。去掉所有套话，其中最关键的条款是第四条“费用”和第五条“试用协议”。简言之，开发者通过申请，每个自然年最多可以试用 30 天企业版，除此以外的使用统统要付钱。

所以这其实是一个很典型的商业协议，甚至没有跟源码公开协议、开源协议放在一起讨论的价值。只是因为它是一家开源商业公司 CockroachLabs 创造，且在相当一段时间内被其他开源商业公司使用，所以做一个解释。同时它的名字 Community License Agreement 也非常的令人费解：这就是一个商业软件协议，跟 Community 没有任何关系。

回到正题，CockroachLabs 在实行 ALv2 + Community License Agreement 几年后，发现仍然无法达成商业目标，于是干脆把原先用 ALv2 许可的核心部分也改用 BuSL 1.1 协议来许可。

CockroachDB 选择的变更期限是三年半，变更协议是此前使用的 ALv2 协议。同样这个不需要展开，主要看它对生产环境使用的条款：

You may make use of the Licensed Work, provided that you may not use the Licensed Work for a Database Service.

A “Database Service” is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work by creating tables whose schemas are controlled by such third parties.

可以看到，和 MaxScale 不同的是，CockroachDB 不限制一般意义上的集群使用，只是限制下游使用 CockroachDB 提供数据库服务。CockroachLabs 本身以提供数据库服务盈利，所以这可以认为是一个禁止竞争的条款。

这个条款的写法是我比较喜欢的，因为它把数据库服务定义得非常清楚：当你的应用基于 CockroachDB 搭建时，你不能支持外部用户创建他们自定义结构的表。

从一个工程师的角度来看，这意味着内部使用 CockroachDB 是可行的，只要整个领域模型仅内部可见。例如，作为一家电商公司，我可以用 CockroadDB 存储操作我的用户数据和交易数据，因为用户表和交易表都是我内部定义的，外部用户并不知道这些定义，也无法自定义表。同样，我可以把 CockroachDB 用来存任何其他事务数据，用来支持搜索引擎，这都没有问题。

Redpanda

Redpanda 公司在 2020 年开始许可自己的代码，全面复刻了 CockroachLabs 的策略：仿照 CockroachLabs 的 Community License Agreement 如法炮制了一个 Redpanda 版本，同时使用 BuSL 1.1 许可核心代码。

不出意料，Redpanda 选择了四年的“保护期”，指定变更协议为 ALv2 协议，其生产环境使用的条款如下：

You may make use of the Licensed Work, provided that you may not use the Licensed Work for a Streaming or Queuing Service. A “Streaming or Queueing Service” is a commercial offering that allows third parties (other than your employees and individual contractors) to access the functionality of the Licensed Work by performing an action directly or indirectly that causes the creation of a topic in the Licensed Work. For clarity, a Streaming or Queuing Service would include providers of infrastructure services, such as cloud services, hosting services, data center services and similarly situated third parties (including affiliates of such entities) that would offer the Licensed Work in connection with a broader service offering to customers or subscribers of such of such third party’s core services.

内容很长，一句话就是你不能允许外部用户创建主题。Redpanda 是 Kafka 的平替，这里所说的主题也就是 Kafka 或者消息队列领域里的主题。

这个限制和 CockroachDB 基本类似，也就是允许用户内部使用，但是斩断了向外部用户提供消息队列功能的可能。毕竟我是一个消息队列服务的用户，我肯定是要自己先创建主题，再往其中生产消费消息的。内部使用基本不受影响，因为内部使用属于雇员或合同工创建主题的例外范畴。举个例子，你还是可以用 Redpanda 作为内部数据同步的管道。

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 and you may concurrently use multiple such installations, subject to each of the following conditions:
(a) you may not create installations with multiple clusters, nor compute clusters with multiple replicas, nor compute cluster replicas with multiple processes; and
(b) you may not use the Licensed Work for a Database Service. A “Database Service” is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work by creating views whose definitions are controlled by such third parties.

很简单，MaxScale + CockroachDB 的限制一起上，即不能创建大集群，也不能提供数据库服务。

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.

A “Document Service” is a commercial offering that allows third parties (other than your employees and contractors) to access the functionality of the Licensed Work by creating teams and documents controlled by such third parties.

基本是仿照了 CockroachLabs 的写法，不过把数据库服务改成了文档服务。其中，对文档服务的定义是允许外部用户自行创建或使用文档。

简言之，如果只是在公司内部做知识库构建，可能可以允许外部用户查看，但是不允许外部用户创建团队和文档，这是协议授权范围内的。这基本满足了用户自建知识库和共享给客户查阅的需求。

Akka

Akka 是久负盛名的 Scala 语言异步通信和应用开发框架，实现了 Actor Model 的设计，号称 JVM 上的 Erlang/OTP 实现。Akka 开源的时间非常久，从 2009 年到去年中修改协议，已经以 ALv2 发布了十多个年头。许多开源软件和业务都搭建在 Akka 的底盘上。

Akka 于 2022 年九月宣布未来版本将改用 BuSL 1.1 许可。在填空题上，Akka 选择了三年“保护期”和 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 and solely to implement the functionality provided by Play Framework; provided that, they are only used in the following way: Connecting to a Play Framework websocket and/or Play Framework request/response bodies for server and play-ws client.

写得非常复杂，但是总结下来是很简单的一句话：任何情况都不能在生产环境部署 Akka 应用，除非你是用 Play 框架开发应用，且应用中没有直接和 Akka 的接口通信。

这个涉及到一些历史背景：Play 框架和 Akka 都是 Lightbend 公司的产品，早在几年前 Lightbend 公司就宣布不在以公司投入维护 Play 框架，而是转为“社群维护”。这也是个后来被广泛应用的话术，用以指代公司放弃某个开源软件的开发。由于 Play 框架的底层就是 Akka 支撑的，修改 Akka 协议时，或许出于避免级联影响到此前已经弃养的 Play 框架的用户，Lightbend 公司通过这一条款规避了原 Play 框架用户可能收到的冲击。

从协议上看，Akka 直接禁止了生产环境的使用，可以说是最严格的 BuSL 1.1 实例。不过在 Lightbend 的博文中提到，年收入在一千万美元以下的公司，可以向 Lightbend 公司申请免费使用的许可。

HashiCorp

最后，终于我们可以看看今天的主角 HashiCorp 是怎么使用 BuSL 1.1 协议的了。

毫无意外，HashiCorp 选择了四年的“保护期”，变更协议是此前它们采用的 Mozilla Public License 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 产品存在竞争的服务上。

那么，什么是“跟 HashiCorp 存在竞争”就是一个非常模糊的说法。对此，HashiCorp 的解释很有一家商业公司典型的做派：如果你不清楚是否违规，请联系我们的律师。

HashiCorp considers a competitive offering to be a product or service provided to users or customers outside of your organization that has significant overlap with the capabilities of HashiCorp’s commercial products or services. For example, this definition would include providing a HashiCorp tool as a hosted service or embedding HashiCorp products in a solution that is sold competitively against our offerings. If you need further clarification with respect to a particular use case, you can email licensing@hashicorp.com. Custom licensing terms are also available to provide more clarity and enable use cases beyond the BSL limitations.

当然，如果你给钱，HashiCorp 将竭诚为您定制符合您需要的协议。

开源商业的深层次动机及得失计算

我在《诱导转向的伪开源策略》一文中提到：

自诩“开源商业公司”的企业一开始不提供商业收费的版本，投入巨大的人力开发唯一的开源软件，这可能是一种不成熟的行为。尤其是如果公司创始人没有想好此后如何盈利，只是觉得自己写好一个软件，以开源的方式打开名声，就能坐地收钱，那日后破防也是不可避免的。
对于这些企业来说，初心就是“写个软件好卖钱”，而且确实也是创始人辛辛苦苦拿到融资，组织起来一帮兄弟姐妹领工资夜以继日地开发软件。到头来用户只是使用而不付费，甚至因为太好用找不到付费的理由。这个时候，又冒出来几家供应商把代码拿过去改改做出自己的解决方案，甚至由于上游使用宽容开源许可，这些供应商源代码一藏，随口就说碾压上游版本。
这实在是大大超出了企业创始人的预料，于是修改软件许可，让这些用户和供应商搞清楚状况就会被加紧提上日程。

在企业转向带有商业保护条款的源码公开协议时，此前利用开源标签赢得口碑和声望的企业都会写一篇辩白书：

• Why are we changing the license for MongoDB?
• Upcoming licensing changes to Elasticsearch and Kibana
• Why We’re Relicensing CockroachDB
• A New License to Future Proof the Commoditization of Data Integration
• Why We Are Changing the License for Akka

可以看到，Materialize 和 Redpanda 这样一上来就是 BuSL 1.1 的软件是不用写一篇《我的忏悔》的。

上述辩白书不全是转向 BuSL 1.1 的，还有 SSPLv1 和 ELv2 等。但是它们都提到了同一个问题：自己投入人力开发的软件，商业对手却坐享其成，这使得竞争对手在这个层面上存在投入产出的优势。当然，这些企业随后会放大这种竞争对手的优势，控诉他们“不向上游回馈”，自己几乎要因此而无法存续，然后警告用户自己无法存续等于软件死亡。

这个逻辑链条有两个不成立的地方：

1. 挑战通常不是无法持续，而是无法扩张。资本的本性就是扩张，赚了一百万就想赚一千万，市值一个亿就想冲一百亿。除了 Lightbend 确实有可能是因为 Scala 式微导致维持现有规模都有挑战以外，MongoDB、Elastic 和 CockroachDB 控诉 AWS 等云厂商竞争导致它们丢掉客户，实际上是增长受挫的反应。
2. 公司等于社群对社群的存续未必是一件好事。这些企业会把开源软件的存续和自己捆绑，由于这些开源软件确实是公司产权，这也无可厚非。不过公司死了，开源软件有用，未必它就不能发展了。例如 Akka 修改协议以后，其庞大的用户群自发从最后一个开源版本拉出分支继续以开源协同的形式维护，目前在 Apache 孵化器以 Pekko 的名字在继续。

当然，逻辑链条不对不代表客观上没有道理。

关于增长受挫的问题，其之一是资本的本性就是扩张，所以增长受挫确实是资本所不能接受的。其之二是云厂商搭建起来的完善交付体系，确实挤压了采用原先商业模式的开源商业公司的生存空间。作为反制，Red Hat 虽然不能修改 Linux 的软件协议，但是通过改变其发行版的打包流水线，实际上增加了云厂商在其企业级发行版上原封不动打包交付的难度。

关于社群存续的问题，毫无疑问核心参与者的离开会重挫开源社群的可持续性。当开源社群中心的软件是企业产权，开源社群的核心开发者都是该公司雇员的时候，一旦公司倒台，大部分情况下确实软件也会随之消亡。但是事实证明 Akka 不会，ElasticSearch 也不会，我相信 Redis 和 Kafka 这样的项目，没有公司做商业化，也能持续下去。所以这是个有相关性但不绝对的论断。

我在《企业实践开源的动机》一文中，对“商业模型是销售开源软件”的企业做过判断，认为它们早晚会将自己的开源软件改成专有软件：

如果一个企业的商业模型就是销售“开源”软件本身的功能，那么他们的核心功能转向专有软件只不过是时间问题，或者说只要面临商业竞争，就是经不起挑战的。

回到修改软件协议这件事上，我在《企业开源的软件协议模型实践》一文里已经提出了这个风险：

• 风险：竞争对手的商业竞争
• 风险：团队分裂并参与竞争
• 策略：运维和高级功能
• 策略：独特品牌建设
• 策略：赛道维度升级
• 策略：市场占有率与开放标准

随后我提到的“源码公开但禁止商业竞争”其实就是第五个策略：改变协议。其中又包含“核心禁止商业竞争”和“高级功能需要付费”的分支。

应该说，在现有的市场经济体制和资本主义体系下，开源软件本身是不能作为企业盈利的核心的。即使在《大教堂与集市》的《魔法锅》一章中，Eric Raymond 提出了十几个与开源软件相关的获利途径，他也同时承认“开源使得从软件中直接获取销售价值变得更加困难”。

对于商业开源来说，企业在当前的体制体系下能够找到的相对最优解，就是 BuSL 1.1 协议或 ELv2 协议：绝大部分和开源协议一样，但是禁止（直接）商业竞争。因为如果发行商能够直接和原厂竞争，那么原厂投入的研发资源就被竞争对手搭便车，竞争对手从而能够构建出其他排他的优势。典型的案例就是云厂商可以优化自己的交付体验和云基础，直接移植开源软件提供收费服务。对于没有这样一个完整基础设施团队和获取客户的强大销售团队的原厂来说，这确实使得它们在市场竞争下失去了独占软件产权的优势。

不过，对于开源软件本身，这并不是什么致命的变化，甚至都谈不上变化。

开源软件只有很少的一部分是由一家企业主导的。Redpanda 闹腾得再厉害，开源的标准是 Kafka 协议。不管 Redpanda 和 Confluent 还在不在，我相信 Kafka 会一直在。当初依靠做 Hadoop 生态发行版的企业几经浮沉，并没有太多影响 Hadoop 自己的发展。至于 RedisLabs 公司，我甚至觉得它如果死了，对 Redis 可能是一件好事。毕竟以 @antirez 现在的声誉，仿照 Linus 或尤雨溪的路子养活自己并不难，而他的参与贡献才是 Redis 发展的核心。

企业选择带有商业保护条款的源码公开协议，可以看做是从完全闭源的商业协议，到冒进的全面开源协议，在之后的一次螺旋上升的准备。我相信开源协议是完善的，它解决了源代码如何自由分享的问题。在《大教堂与集市》的论述中，Eric Raymond 从未指望供应商自己转变，而是试图通过说服用户理解开源的价值，以及鼓动任何企业开源其非盈利软件来实现开源的未来。这也是我认可的方式。

对于个人开源来说，Apache 基金会的前任董事、经验丰富的开源开发者 Ted Dunning 说过一个故事。

Ted 曾经在发布自己的软件源码时，授权接收方自由使用、更改和分发，但是如果接收方要商用，那么需要向他付一笔授权费用。但是后来他发现，用 Apache 协议发布自己的软件以后，自己一下子得到了更多的用户和他们宝贵的反馈，而这才是他作为一个开发者所期待的。同时，作为个人，他没有那么强的动力，实际上也不可能花费大量自己的时间向每一个商用的用户索要费用。

他于是说：如果我不愿为授权费奔走，那么我根本不必提出要求。

所以，商业源码协议对个人应该是没有什么帮助的（笑）。

我在《企业开源该选什么软件许可证？》一文当中，已经从软件许可证的角度讨论过不同协议对企业开源的意义。

不过，那篇文章主要是从许可证内容出发的，即先给定了协议，分析完协议细节，再判断是否符合企业和计划公开的软件的情形。本文从企业开源的不同诉求和风险出发，结合现存的企业组织实践，重新讨论源码公开第一步就要面临的选择软件协议问题应该如何决策。

完全开放源码

完全开放源码，即以符合开源定义的软件协议发布企业自研软件的情形。

在讨论什么样的企业针对什么样的软件会采用完全开放源码的策略之前，我们先讨论完全开放源码的策略会给企业带来什么风险。符合开源定义的软件协议既包括宽容软件协议，也包括 Copyleft 式的协议，这里不做区分，因为企业面临的是相同的问题。

当然，对于企业完全自有产权的情形，企业随时可以改变软件协议以规避下面提到的风险。所以这里提到的风险主要涉及的是将自研软件捐赠给第三方如开源基金会，或者试图坚持完全开放源码策略的企业。

风险：竞争对手的商业竞争

我在《黑客与顾客：开源软件能商业化吗？》一文里讨论过，开源软件的用户包括黑客和顾客两种类型。

对于完全开放源码的创始团队来说，黑客用户既然自己有能力把软件用起来，甚至修改软件以解决自己的需求，那么可以认为开发成本已经付出，不从这类用户身上赚钱，而是寻求合作共建，是合理的。目前绝大部分“开源商业化”企业的逻辑，也是以服务无力或不愿承担开发和维护任务的顾客为主。

这一点，从目前新兴的 Elastic License 2.0 (ELv2) 和 Business Source License 1.1 (BSLv1) 的不少实践都允许在不进行同类商业服务竞争的情形下自由使用可见一斑。而上述两个源码公开的商业软件协议，想要避免的也正是同行黑客的商业竞争。

例如，业内提供 Apache Kafka 托管服务的企业数不胜数。在聚拢了相当数量的核心开发者的 Confluent 之外，Upstash 和 Aiven 这样的 SaaS 企业都提供了 Kafka 托管服务，更不用说大大小小的平台云厂商顺手提供的 Kafka 服务，例如 AWS 的 MSK 服务、阿里云的 Kafka 服务和红帽的 OpenShift Streams for Apache Kafka 服务等等。

这样的竞争使得 Confluent 不得不在简单的提供 Kafka 服务以外寻求新的增长点，例如只在商业版本提供多租户功能，以及在流计算集成上多次失败的尝试。当然，Kafka 的创始工作和捐赠都是在 LinkedIn 公司的主导下完成的。这样 Confluent 公司虽然无法效仿 MongoDB 公司在竞争对手直接提供商业服务的时候变更协议釜底抽薪，但是心里也不至于太不平衡。

ElasticSearch 和 MongoDB 起初分别以 Apache License 2.0 (ALv2) 和 GNU Affero General Public License 3.0 (AGPLv3) 发布，但是在 AWS 等商业公司低技术成本、高平台优势的竞争下，既无法找到新的增重点缓解危机，又无法抗拒近在咫尺的釜底抽薪方案，于是变更协议直接禁止使用源码进行商业竞争。

风险：团队分裂并参与竞争

Confluent 的案例里暗含了另一种完全开放源码的风险，即在软件可以自由演绎和商用的情况下，企业当中的开发者可能分裂出去单独进行商业运作并参与竞争。

Confluent 的创始团队来自 LinkedIn 公司，LinkedIn 本身没有提供云服务的业务，这种竞争尚不明显。其他处于 LinkedIn 情境的公司，甚至可以通过提供早期投资的方式，换取新团队比此前直接雇佣更低成本的支持。

Apache Hadoop 的故事演示了多家势均力敌的企业，同时基于非自有产权的开源软件做简单封装的商业化模式的风险。

在 Hadoop 的孵化公司雅虎不下场的情况下，Cloudera 公司、Hortonworks 公司和 MapR 公司为了竞争 Hadoop 私有化部署和运维服务打得头破血流，最后的结局是 Hortonworks 和 MapR 被收购，Cloudera 私有化退市。而退市以后的 Cloudera 公司，还是面临市面上拿着 Apache Ambari 封装或者自研大数据套件的提供商的剧烈竞争。

Apache Flink 的故事演示了在一家企业主导社群发展的情形下，部分团队寻求独立带来的分裂风险。

起初，Flink 在一所德国大学里开发并捐赠到 Apache 软件基金会。随后创始成员成立了 Ververica 公司，并于 2019 年被阿里巴巴收购。完成收购的阿里巴巴基本形成了对 Flink 社群的主导，并于接下来的一段时间无需顾虑其他基于 Flink 的商业服务的竞争。然而，就在过去的一两年里，核心团队分几次出走，加入到其他基于 Flink 做商业服务的公司，或者单独成立商业公司提供 Flink 服务。其中，走后面一条路的 Immerok 公司在不久前被 Confluent 收购，一下子使得阿里巴巴的流计算业务受到 Confluent 流存储 + 流计算的强势狙击。

在这些戏剧化的商业操作背后，Flink 本身是一个完全开放源码的软件，允许任何人和组织自由演绎和使用，也包括商用和提供商业竞争，是合规层面的一个基础性的支撑。

上面提到的例子里，即使有企业完成对社群话语权主导的案例，但是都全都是企业对开源软件没有自主产权的情形。接下来的这个例子虽然也是 Apache 软件基金会的项目，但是其中使用的方法是可以套用到企业自有产权的软件的。

这个案例就是 Apache Doris 项目。

Apache Doris 由百度的研发团队开发并捐赠给 Apache 软件基金会。凭借其符合国内企业需要的数据分析能力的设计，Doris 在一开始的十年里逐渐发展出一个可观的用户群体，其中相当部分还是有购买商业服务的潜在顾客。百度自己基于 Doris 发布了 Palo 数据分析产品，但是不久以后，部分核心开发者出走，并 fork Doris 发布了后来改名为 StarRocks 的同类竞争产品。没过几年，另一个研发团队出走并成立了 SelectDB 基于 Doris 提供同类的数据分析服务。

单看这个围绕 Doris 的竞争，似乎和 Hadoop 几家公司的竞争也没有什么差别。但是 StarRocks 并不是一个典型的围绕上游的版本，而是从某个版本硬分支的全新版本，目前和 Doris 的关系算得上是“大路朝天，各走一边”。这样硬分支的手段带来的竞争，即使上游是完全自有产权的软件，也无法通过修改协议来避免。

为了表明 Doris 的案例并非孤例，我这里再举几个类似的商业相关的硬分支案例：

• Trino 是基于 Facebook Presto 的硬分支，后续 Trino 团队成立了 Starburst 公司提出数据网格（Data Mesh）概念做为商业化方向。
• Lightbend 公司将 Akka 切换成年收入在一千万美元以上的公司使用就需要商用协议以后，Akka 社群的中立成员随即 fork 了 Akka 并在 Apache 软件基金会的孵化器中以 Pekko 的名字继续运行。
• AWS 在 Elastic 公司将 ElasticSearch 切换到 ELv2 后，发起了 OpenSearch 项目并基于它提供了类似的商业服务。

面对上述风险，企业可以采取以下策略来降低或规避商业竞争的挑战。这些策略不是互斥的，应该根据企业自身的情况灵活组合使用。

策略：运维和高级功能

这是最基本的一个策略，即提供一个比开源版本功能更丰富的企业版本，包含闭源高级功能或运维支持，提供售后、服务水平保证和责任承担。

通常来说，它并不能在策略层面提供明显的竞争优势，因为你的竞争对手在能够自由使用相同软件的情形下，与你在这一层面的竞争是处于同一起跑线的。唯一的区别是你可能拥有更多熟悉软件的工程师，能够提供更好的服务支持。

但是，为了保持开源软件的活力、技术迭代与用户群，不至于变成开源一个闭源专有软件的快照，你的工程师会投入到开源上游核心的开发中去，这些成本由你支出，而你的竞争对手将无偿取得。同时，因此你的企业版本很难做出合适的代差以说服客户使用，而纯粹的运维支持，营收在竞争对手不需要维护一个内核研发团队的价格战下很难支持公司增长。

总的来说，这是一个保护性策略，即你必须要提供运维支持、售后、服务水平保证和责任承担，从而让客户能够像使用一个商业产品一样使用你提供的开源软件发行版或服务。但是它很少成为一个决定性的优胜策略。

策略：独特品牌建设

完全开放源码风险的共同点，是出现了其他企业或团队，以相同的软件代码基础展开商业竞争。企业开源的情形下，软件代码的归属是明确的，不仅创始工作在企业内的研发团队完成，版权所有的也是企业。这样，企业可以通过基于软件建设公司独特的品牌，将软件与公司品牌相关联来赢得在同类产品的用户群体中的心智竞争。

例如，Hashicorp 的基础软件均以 Mozilla Public License 2.0 (MPLv2) 发布。

实践上，MPLv2 可以被简单理解为允许包括提供同类服务的商业用途，可以和商业软件集成而不要求开放集成软件的源代码，可以基于已有接口的开发闭源的新机制实现，但是对软件接口的修改需要公开。MPLv2 许可的软件是完全开放源码的软件，一家公司直接拿走 Terraform 等软件，提供和 Hashicorp 相同接口的服务进行竞争是可能的。

然而，支撑用户采用 Terrafrom 等软件的，是 Hashicorp 对基础设施即代码的解释和实践。用户采购的不仅仅是 Terrafrom 或 Nomad 单独的一个工具，而是 Hashicorp 定义的一整套基础设施即代码的工作方式。如果下游企业仅仅是跟随这些概念，那么面对 Hashicorp 推出的新概念，自然很难第一时间跟进，更遑论超越。这样，用户就没有理由选择一个被上游带着跑的提供商，而是直接接触原创厂商。如果原创厂商的产品不能满足要求，也不太会选择追随者。

同样，商业智能数据分析服务的内核软件，例如 Cube.js 和 Streamlit 也是完全开放源码的。这类场景的定制化和依赖方法论的程度高，厂商基本可以将自己的技术品牌和开源软件相绑定，从而建立起竞争对手难以逾越的心智门槛。

Starburst 公司是另一个佼佼者，它拥有 Trino 即原先的 PrestoSQL 的版权，而 Trino 是联邦查询优秀的解决方案。Starburst 趁热打铁，推出了极具传播效果的 Data Mesh 概念，即不同来源和模式数据在同一个平台下进行分析，从而将数据打造成产品，而要做到这点，联邦查询引擎 Trino 自然能提供强力支持。这个概念的传播性之强，以至于 Confluent 也出书将自家的 Data in Motion 概念和 Data Mesh 捆绑营销，Trino 和 Starburst 借此水涨船高。

不过，对于标准化完成度高的赛道，这样的策略往往就难以提供竞争优势，而成为必须要做的保护型策略了。例如，MySQL AB 公司拥有 MySQL 的版权，但是在后来的发展里，业界对于数据库应该是什么样子的越来越有清晰的共识，甚至不少 MySQL 的运维专家自己都可以开设公司提供商业服务。MySQL AB 公司提供的附加价值有限，相当长时间内也不再提出具有开创性的品牌概念，终于在公有云服务登场以后，彻底被云厂商的关系数据库服务截取几乎所有利润。

策略：赛道维度升级

当完全开放源码的基础软件逐渐取得行业认可，甚至成为行业标准以后，品牌建设带来的心智门槛就会逐渐被抹平。这个时候，单纯提供简单的部署运维服务的商业模式，就会陷入到恐怖的价格战当中。在保持基础软件完全开放源码的前提下，要想另辟蹊径取得商业优势，就需要进行赛道维度升级，即基于开源软件提出新的解决方案。

要想走到这一步并不容易，如果初创企业辛苦研发后开源的核心软件，经过运营真的成为了某种标准，模仿者众，初创企业效仿 MongoDB 和 Elastic 直接切换成专有协议是目前仅有的实践。我们以一个无法切换协议的企业来模拟在这种情况下坚持完全开放源码、升级赛道维度将如何进行，它就是 Databricks 公司。

起初，Databricks 的商业模式还是 Spark 的简单包装。它和微软 Azure 达成合作，在 Azure 上捆绑销售 Apache Spark 性能优化的发行版。

随后，Databricks 以 AI 为切入点，在 Spark 生态推出了 SparkR 和 PySpark 等集成支持，同时和 edX 合作推出了 Spark 系列课程，强化 Databricks 品牌在 Spark 生态中的地位。同时，在商业产品侧，针对 AI 的典型计算任务提供了标准化算力资源和一揽子解决方案，开始将 Spark 作为公司依赖的计算引擎核心而非差异化卖点。

再后来，Alluxio 和 JuiceFS 的探索让 Databricks 发现了 Spark 的计算能力加上存储以后的巨大需求市场，于是自研了 Delta Lake 软件，提出湖仓一体概念兜售新的解决方案。随着公司逐渐站稳脚跟，Databricks 也有了更多的资源投入到先前 AI 阵线上如今火起来的 AIOps 概念，以及完善整个湖仓一体故事所需的，包括 Delta Live Table 在内的一系列周边产品。

今天的 Databricks 已经不是一个简单的 Spark 提供商，而是一个 Data + AI 领域的企业级方案和云服务提供商。其他简单提供 Spark 作业调度和运维的企业，跟 Databricks 并不在同一个维度内竞争。

策略：市场占有率与开放标准

目前，能够在自有产权的情况下坚持完全开放源码，并在其他维度展开竞争的企业，其开放源码的软件都不是企业盈利的核心软件，而是打开市场和建立开放标准的敲门砖。换言之，企业对此类软件选择和坚持完全开放源码策略的一个主要原因，是企业希望完全开放源码的软件赢得广泛的市场占有率，甚至形成开放标准。

以开源的程序设计语言实现为例，在语言本身赢得用户之前，很少有企业能够直接通过售卖语言实现的编译器或解释器来盈利。瑞典电信公司 Ericsson 支持工程师 Joe Armstrong 开发 Erlang 语言之后，将整个 Erlang/OTP 平台完全开放。从当年的发布文稿中，我们可以看到开放标准的典型思路：

Erlang/OTP was invented within Ericsson and most Erlang/OTP users are still within Ericsson. In order to speed development of Erlang/OTP, ensure a good supply of Erlang/OTP fluent programmers, minimise maintenance and development costs for the language, and keep the OTP applications up to world class, we need to spread the technology outside of Ericsson.

也就是说，Ericsson 内部的电信系统高度依赖 Erlang/OTP 平台，为了保证劳动力市场上一直有人熟练掌握这一语言和开发平台，从而保证 Ericsson 内部系统不至于无人能够维护，Ericsson 希望完全开发源码，以期在公司以外的广阔生态中推广 Erlang/OTP 平台。事实证明，这一决定为 Erlang/OTP 平台起初在电信行业内的推广，以及后来在游戏行业中的广泛应用，再到近些年其底层虚拟机 BEAM 借助新语言 Elixir 的发展再次得到关注，都起到了至关重要的作用。Joe 为 Ericsson 创建高可用的服务打造了一个完整的开源软件和开发平台，但是如果没有开放源码，这将只是 Ericsson 这个如今已不那么有名的企业的一个内部系统。或许会成为一个仅存于谈话之中的传说，但是不可能有今天的生态。

同样是 Erlang 生态的一部分，José Valim 设计的 Elixir 语言及其开发的解释器和网站开发套件，代表了开放源码以赢得市场占有率的策略。

José 起初在自己参与联合创办的 Plataformatec 开发出了 Elixir 语言的解释器，以及 ecto 工具和 Phoenix 框架。后来，Elixir 的使用率日益增长，José 于是另外创办了 Dashbit 公司来提供 Elixir 应用的开发和运维支持。

从 Dashbit 公司的视角出发，其拥有部分 Elixir 核心生态软件的知识产权，但是它却没有通过限制核心软件使用，要求用户购买 LICENSE 的方式来盈利。这是因为，Elixir 毕竟还是一个小众的语言，用户使用量的增长才是做企业支持的基本盘。如果小有成就马上杀鸡取卵、竭泽而渔，那么新用户就很难有信心上车，而存量用户也会想办法跳车，最终生态凋敝，没人有理由购买 LICENSE 授权。

José 本人在 LinkedIn 上的头衔就是 Chief Adoption Officer 即首席（用户）采用官，可见 Dashbit 的开源策略当中对市场采用率的重视程度。同类的案例还有 VMWare 的 Greenplum Database、Spring Framwork 和 RabbitMQ 等项目，这些公司（在相关方向）的主要商业模式是提供支持和咨询，而不是售卖软件或提供云服务，因此其提供支持和咨询的对象的使用率越高越好。

再来看一种竞争型的开放标准策略，其中典型的当属 Google 的开源矩阵：

1. Chromium 打下了浏览器内核的半壁江山。如今，多少网页应用都注明仅在 Chrome 上经过测试。
2. Android 从 iOS 和 Symbian 的夹缝中取得了移动端市场的船票，并最终和 iOS 二分天下。
3. Kubernetes 和 Istio 是 borg 技术溢出以后，Google 主动建立生态的尝试。在相当一段时间里，用上 Kuberneets 就“等于”云原生。

Google 是重度参与 C++ 标准讨论或者说竞争的，这可从 C++ 之父 Bjarne Stroustrup 的论文 Thriving in a Crowded and Changing World: C++ 2006–2020 中关于 C++ 标准委员会的讨论中窥见端倪。应该说，标准之争是激烈甚至残酷的。企业内部总有领先与行业标准所做的尝试，一旦行业后续面对相同问题时将另一种解法确定为标准，那么本公司不说此前的研发投入打了水瓢，至少也需要付出可观的额外努力来兼容新标准。Google 深知这点的厉害，而 Kuberneets 打赢容器战争，对比失败的 OpenStack、Docker Swarm 和 Apache Mesos 与重金投入它们的公司，Google 账面之外的获利不可计数。

无独有偶，Facebook 的 React 前端应用开发框架已经成为无可置疑的标准，对应 Google 推出的 Angular 势弱，多少投资 Angular 的企业和开发者损失惨重。

国内也不乏出于这个动机完全开放软件源码的企业。例如，Apache InLong 是腾讯大数据平台里数据集成能力的开放，Apache Dubbo 和 Nacos 是阿里巴巴微服务架设和治理经验的开源表现，CloudWeGo 是字节跳动中间件能力的系列开源行动，Go Kratos 是 Bilibili 开源的微服务框架。当然，这些软件集中在所谓的“中间件”领域，是另一个值得探讨分析的话题。

最后，上面提到的都是体量巨大或至少相对较大的公司，对于初创公司来说，有没有实践市场采用率和开放标准这一策略的空间呢？

肯定还是有的。例如，近期已被 Apache 孵化器接受的 OpenDAL 数据访问库，就是由 2021 年初创的企业 DatafuseLabs 捐赠的。又例如，CockroachDB 的存储引擎 Pebble 以 BSD-3-Clause 协议开源，连 PingCAP 的数据导入工具 Lightning 都在使用。

一般来说，初创公司更容易在细分领域或者新兴领域，通过开放源码软件来赢得大量声誉和共同维护生态成员都有需要的基础软件。

源码公开但禁止商业竞争

完全开发源码的策略会面临其他企业直接拿走软件代码，提供同类接口展开商业竞争的风险。即使是 Copyleft 式的协议，也很难逃过这样的竞争。

例如，红帽公司的 Red Hat Enterprise Linux (RHEL) 以 GPLv2 发布，这就使得 CentOS 可以利用相同的代码提供自己的发行版和服务。国内运维应该都了解，CentOS 在相当一段时间内是国内企业环境部署量最大的 Linux 发行版。这对红帽的商业模式造成了很大的冲击，最终红帽在 2014 年收购了 CentOS 公司。而 2021 年 CentOS 的作者再次复刻代码开发 Rocky Linux 进行商业竞争，或多或少再次冲击了 RHEL 的市场。

当然，今天的红帽已经不是单纯 RHEL 发行版的订阅提供商了，这样的冲击未必造成多大影响。然而，红帽面临这些问题毕竟是因为它是上游 Linux 的一个追随者，没有代码版权。对于新兴的初创公司来说，一旦通过开放源码的方式赢得了第一批客户，其他公司复刻代码直接竞争，一个行之有效的手段就是切换到禁止商业竞争的软件协议，杜绝此类事情发生。

然而，这毕竟是诱导转向的手段：切换软件协议后，企业与产品的品牌会收到打击，社群反噬和衰退引起用户客户逃离，生态集成出现问题不再繁荣。这些都是可能出现的问题。对于一开始就采取禁止商业竞争策略的企业，不会受到切换协议带来的打击，但是社群规模和生态集成的问题和进行切换的企业最终面临的状况是类似的。

接下来，我们讨论采用禁止商业竞争的源码公开协议的企业，如何构建其软件协议模型，面临哪些挑战并将如何应对。

核心禁止商业竞争

这一门派的著名选手是 MongoDB 公司和 Elastic 公司，分别创造了 Server Side Public License (SSPL) 和 Elastic License 2.0 (ELv2) 两个协议。

其中 SSPL 并不直接禁止商业竞争，而是要求在向企业之外提供同类服务时，必须将服务所有相关软件的源代码都以 SSPL 公开提供。由于这个条件对于服务所有相关软件的定义非常模糊，在没有判例的情况下没有公司想要测试到底它能不能“传染”到企业所有核心代码。目前，遵循 SSPL 开放服务软件栈的案例应该完全没有。

虽然所有软件源码公开、自由使用和修改是自由软件的追求，但是 SSPL 主要的目的是针对云厂商，限制它们的提供同类服务。因此自由软件阵营的 Fedora 社群明确否认 SSPL 是自由软件协议。同时，SSPL 的文本明确违反了开源定义第九条“不得限制其他软件”，因此也不被开放源码阵营所认可。实际上，它期望起到的作用就是禁止同类服务的商业竞争，虽然实际上由于协议条文的潜在风险，企业在不购买 MongoDB 的商业协议授权时，往往选择完全不使用 MongoDB 软件。

ELv2 对禁止商业竞争的意图和范围描述是清晰的，其文本量也相对较少：在允许用户使用、复制、修改和分发的前提下，不允许用户改变软件协议，不允许破解密钥保护的功能，禁止提供与软件功能相似的商业服务。因此，企业内部使用，以及把 Elastic Search 作为支撑业务逻辑的倒排索引系统是可以的，只要不直接提供跟 Elastic Search 相同或相似接口的服务即可。

另外一个常用的协议，Business Source License 1.1 (BSLv1) 则是由失败过一次的 MySQL 团队的部分成员重新创业的 MariaDB 公司创造的。它被用在 MariaDB 的企业级解决方案核心软件 MaxScale 上，其协议内容禁止用户使用 MaxScale 集成超过三个节点的集群，实际上就限制了有效的商业竞争，同时迫使大规模使用该软件的企业购买商业协议。

最后，介绍 Redis Labs 曾经为了禁止商业竞争，而在 BSD 3-Cluase License 上添加的 Common Clause 条款，它禁止取得软件源码的接收者“售卖”该软件。

Redis Labs 后来在社群大规模反弹下切换回了纯粹的 BSD 3-Cluase License 模型，而 Common Clause 也因为对“售卖”的定义及其模糊而几乎没有其他采用案例。自由软件基金会在对软件协议的评论里更是专门抨击了 Common Cluase 对 “Common” 和 “Sell” 两个词词义的污染，并强烈建议不要使用这个附加条款。

总的来说，使用范围较广的禁止商业竞争的源码公开协议只有 ELv2 和 BSLv1 这两者。我们看看其他公司的采用情况。

Airbyte 是 ELv2 + MIT 最典型的玩家。虽然它起初完全是用 MIT 许可发布的，但是很快就出现了模仿者打价格战。Airbyte 的主要研发投入仍然在其数据集成核心上，而这个需求相对来说是有行业共识的，在数据传输协议公开的前提下，打的就是集成多寡的体力仗。这种情况下，Airbyte 优化核心的投入会被下游无偿获取，其细分领域内建设独特品牌的策略提供不了公司想要的壁垒，而公司的人力又不足以完成升级赛道维度的开发。因此，Airbyte 选择切换核心软件协议，釜底抽薪。

由于 Airbyte 切换协议的时候，大型云厂商尚未关注到它，用户要么是自己部署，要么是使用 Airbyte 的服务，使用竞品服务的用户只是初现趋势，而 ELv2 本身并不禁止用户自己部署使用的情形，因此没有引起巨大的反弹。同时，Airbyte 的命令行工具、连接器代码和开发套件，以及数据传输协议实现仍然是 MIT 许可的，这就不影响社群开发的 Airbyte 集成继续以开源协议发布，对社群生态也没有造成明显的影响。当然，有人不喜欢这类变化，选择其他自由软件的情况是有的。核心模块的开发者规模虽然此前也主要是 Airbyte 员工响应，没有受到太大影响，但是也不会再有想象空间了。

BSLv1 在限制条款上留白，因此应该算是一个协议框架，实际使用 BSLv1 的企业分成两类。

第一类是 CockroachDB 和 Outline 式的禁止提供同类服务，这在模式上和使用 ELv2 大体相同。

第二类会有各种更加严格的限制，不同于第一类只是禁止商业竞争，更像是确定了免费增值的策略，一旦超出“试用额度”，就需要付费。

祖师爷 MariaDB 的做法是限制以其 BSLv1 版本使用 MaxScale 的用户不得链接超过三个节点的集群。

Materialize 在禁止提供同类服务之上还要求只能部署单集群单并发。一般而言，有后面这个限制已经无法进行有效的商业竞争，不知道是不是担心注册多家公司进行公司级 sharding 钻空子。这样彻底抹杀可能性，可以说尽显商业专业协议的特色。

Lightbend 为 Akka 挑选的 BSLv1 版本，要求用户只能将 Akka 用于和 Play Framwork 下的应用进程通信。实际上，Play Framework 以 ALv2 许可发布，且强依赖 Akka 作为基础软件，这个条款更多是对 Play Framework 社群的妥协，保障 Play Framework 的用户不受 Akka 切换协议的影响，但是也不能从中暴露 Akka 接口脱离 Play Framework 使用。

BSLv1 相比 ELv2 还有一个特色，那就是它明确约定许可发布的软件在不超过四年的一个给定期限内，将自动视为以一个版权人挑选的 GPLv2 or later 兼容的协议许可发布。实践中，除了 MaxScale 选择在四年后以 GPLv2 or later 重新发布，其他企业均选择在四年后以 ALv2 重新发布。

对于行业来说，这在长时间轴上允许后来人自由使用这些代码，但是从商业竞争的角度来说，已经足够拉开和竞争对手的技术代差，劝退所有试图模仿的企业。

高级功能需要付费

另外一类包含禁止商业竞争的代码的软件协议模型，是限制高级功能的使用。

这一方案的代表企业是 GitLab 公司，其核心服务端软件代码协议模型有六个分点：

1. 文档以 CC BY-SA 4.0 许可发布。
2. ee 目录下的代码以商业协议发布，该协议允许测试和开发环境的自由修改和使用，但是生产环境使用必须有对应的订阅席位。
3. jh 目录下的代码以商业协议发布，协议内容同上，除了企业主体变成极狐公司。
4. 客户端 JavaScript 代码以 MIT Expat 许可发布。
5. 第三方软件以其原协议发布。
6. 其他代码以 MIT Expat 许可发布。

可以看到，代码在一起开发，但是高级功能需要付费才能商用。

这样的模式基本和完全开放核心源码，以闭源的插件或企业版代差来盈利类似，除了高级功能代码是公开可读的，而限制使用。

初创企业当中也有效仿这一模式的，例如 Bytebase 将高级功能以密钥上锁并禁止破解，Logto 将其云上部署的功能上锁。

总的来说，GitLab 能够成功应用这个模型，是因为它对企业需要什么样的代码托管平台，以及实施服务开发流程和研发效能等完整需求有一整套解决方案。当企业代码安全审计要求上去，或者实际发生过代码泄露问题，或者开发流水线严重拖慢了业务迭代，或者老板迫切想评估研发效能等等，这样的时候 GitLab 能够提供支持，并且其高级功能能打到痛点。至于国内学习这个模型的企业会如何发展，我们拭目以待。