GreptimeDB 是格睿科技（Greptime）公司研发的一款开源时序数据库，其源代码在 GitHub 平台公开发布。

我从 2022 年开始知道有 GreptimeDB 这个项目。2023 年，我注意到他们的 Community Program 是有认真写的，不是无脑复制所谓成功项目的大段规则，于是开始跟相关成员探讨开源治理和社群运营的话题。后来，我读过 GreptimeDB 的源代码，发现他们的工程能力很不错，于是就开始参与贡献。

经过这几个月的参与，我对 GreptimeDB 的社群有了初步的了解。我认为，这是一个值得参与的拥有巨大潜力的开源社群。于是写作这份社群观察报告做一个简单介绍和畅想。

GreptimeDB 的社群量化情况

两年前，曾有人半开玩笑地说 Rust 和时序数据库都快成开源世界的一个梗了，因为当时有大量的 Rust 语言写作开源项目和定位在时序数据库的开源项目出现。GreptimeDB 也算其中一员，它同样是用 Rust 语言写成的。

不过两年过去，回过头看能够坚持下来不断发展的项目，GreptimeDB 就是为数不多硕果仅存的一员。哪怕跟主流时序数据库项目社群相比，GreptimeDB 的活力也可圈可点。

上面两张图展示了 2023 年，即 GreptimeDB 开源运营第一年，从 OpenDigger 数据集生成的每月 OpenRank 和活跃指数（Activity）数据折线图。

可以看到，从 OpenRank 的维度看，GreptimeDB 显著超越了近年来发展乏力的 InfluxDB 项目，跟 TimescaleDB 和 Prometheus 不分伯仲，相比起战斗民族出品的商业开源产品 VictoriaMetrics 仍有差距。从项目活跃指数的维度看，GreptimeDB 则与 InfluxDB 之外的主流项目同属第一梯队。

OpenRank 是同济大学赵生宇博士定义的一个开源价值流分析指标。相比于容易受先发优势影响的 Star 数和 DB Engines 分数等指标，上面展示的每月 OpenRank 和 Activity 变化情况更能体现出项目当前的发展情况和未来趋势。

GreptimeDB 的社群运营情况

前面提到，我真正开始关注 GreptimeDB 社群的契机是发现他们的 Community Program 并非船货崇拜，而是明显经过思考，有一定可行性的。事实证明，确实如此。2023 年 GreptimeDB 按照 Community Program 的设计发展了两名公司之外的 Committer 新成员：

• Biweekly Report (Jun.5 - Jun.18) – A Key Milestone, First External Committer Onboard
• Biweekly Report (Jul.17 - Jul.30) – Welcome the Second External Committer!

这两位 Committer 都是通过代码贡献被提名的，提名前都提交了大约二十个代码补丁，且质量被项目团队所认可。此外，这两位 Committer 从开始参与项目发展到成为 Committer 都经过了若干个月的持续投入。可以看到，这个标准下筛选和认可的两位 Committer 在上个月仍然有活跃参与。

应该说，目前 GreptimeDB 的项目功能已经初具规模，能够达到线上交付的标准。这也意味着开荒阶段的大量初创工作已经完成，新加入的社群成员可以在一个坚实的工程基础上发挥自己的创造力。同时，GreptimeDB 在实现优化上还有很大的进步空间，倒排索引、WAL 和存储引擎等技术方向上还有很多未解决的设计实现问题。现在仍然是参与 GreptimeDB 成为 Committer 的机遇期。

不过，GreptimeDB 的 Community Program 距离成为一个商业开源标杆还有不少可以改进的地方。

例如目前邀请新的 Committer 只在 Biweekly 上简单提及。Community Program 设计的结构上并没有即时体现出它正常运转，以及社群存在公司之外的 Committer 的事实。对于活跃参与者和 Committer 的介绍和成功经验分享，也尚有欠缺。目前社群基本处于给代码写得好的人一份权限的朴素运营阶段。

此外，Community Program 虽然已经相比其他船货崇拜的同行删减了许多内容，以保证它能够务实地运作，但是仍然存在一些空洞的组织结构。例如设计出的 Steering Committee 做技术和社群发展决策，但是实际上当前阶段大部分工作就是公司团队商议决定后公开；例如还是定义了 SIG 乃至 OSPO 的组织，但是根本没有人力填充运营这些机构。

我认为，Community Program 应该继续依托当前社群实际运行的状态，结合期望达成且有能力达成的下一个状态，来做修订。例如，提高成为 Committer 的标准和路径的透明性，积极分享案例和邀请 Committer 说出自己的故事。例如，精简冗余和虚假的组织架构的同时，保留在社群征求意见和决策结果向社群公开的关键动作。例如，强调社群成员参与渠道的多样性，鼓励在不同渠道帮助他人使用 GreptimeDB 和参与贡献。这部分是 Ambassador/Advocate 的核心。

除了这个堪称开拓性探索工作的 Community Program 之外，GreptimeDB 社群还有两件事情让我印象深刻。

第一个是 GreptimeDB 社群积极参与开源之夏这样的务实的开源活动，今年释放的三个挑战项目都实现了不错的开源导师传帮带效果：

• Greptime & 开源之夏完美收官
• 邹伟：从 0 到 1 迈出开源世界第一步
• 实现 Truncate Table 功能
• 实现滑动采样窗口函数的语法及计算
• 实现对 Duration 和 Interval 数据类型的支持

第二个是 GreptimeDB 的 good-first-time issue 流转速度极快，大部分容易上手的工作往往在一周甚至两三天内就会有人认领，并且完成的情况也还不错。实际认领实现过程中，只要你能够主动更新进展和提问，项目团队成员大多能及时回复。这个体验还是很难得的。

GreptimeDB 的未来发展期望

前面介绍 GreptimeDB 的时候，提到了开源、Rust、分布式、云原生、时序数据库等关键词。虽然这些 buzzword 确实也是 GreptimeDB 能力或特点的一部分，但是从注重实效的程序员（The Pragmatic Programmer）的角度来说，我们还可以做一个具体的展开。

即使当初市面上已经有“恒河沙数”的时序数据库存在，GreptimeDB 的创始团队还是发现了这些现存解决方案没能处理好的问题。对于时序数据当中重要的三个分类：指标（Metrics）、事件（Events）和日志（Logs），大多数时序数据库都只能最优化其中一到两种分类的存储和访问。

GreptimeDB 的创始团队认为，这三类数据可以共用同一套查询层和对象存储层能力，只需要针对各自的数据特性实现各自的存储引擎即可。其中大部分 DB 的架构和能力，例如数据分片、分布式路由，以及查询、索引和压缩等都可以共享。这样，GreptimeDB 最终能够成为同时提供所有时序数据最优化的存储和访问体验的单一系统。

开源应用监控项目 Apache SkyWalking 自研数据库 BanyanDB 也是基于相似的挑战和思考，不过它作为一个监控项目的子项目，更多是以相当特化的方式在实现。但是这反应了时序数据可以统一存储逐渐成为业内共识，所有的通用主流产品都将朝这个方向发展。

在仰望星辰大海的期许之外，GreptimeDB 也有脚踏实地的挑战。

例如，虽然我前面夸赞 GreptimeDB 的工程化水平不错，工程师做功能扩展和代码重构都能找到一个相对整洁的切面，但是软件工程是一个即使知道了原理和最佳实践，真正做出来还是有相当长的必要劳动时间的领域。在快速原型迭代的过程中，GreptimeDB 对内存和抽象的使用是相对奔放的。随着线上应用逐渐增多，GreptimeDB 团队也能收到用户上报的各种性能问题。这就要求重新关注到在快速开发过程里被刻意忽略的细节，精打细算关键路径上的内存使用，针对性能修改抽象以充分利用机器资源。这部分工作都是细致工作，讲究一个 benchmark 发现性能瓶颈并逐个优化。目前的 GreptimeDB 应该有相当多这样的优化机会。

例如，之所以过去时序数据库没能同时服务前面提到的三种不同数据，除了数据建模上的差异，更主要还是因为在数据量暴涨之后，特定数据类型的特定访问形式的读写性能会骤然降低。目前针对此类问题，业界提出了一系列索引方案进行改良。GreptimeDB 目前正在实现其中倒排索引的方案，也将探索结合倒排索引、基于 Cost 的查询优化器和 MPP 查询引擎的自适应方案。这些工作存在许多参与机会，目前 GreptimeDB 团队成员也有不少精力投入在此。

例如，系统层面数据一致性和性能之间的取舍依赖 WAL 模块的实现。目前，GreptimeDB 仅提供了本地的 RaftEngine 实现和 Kafka Remote 的实现，其中 Kafka Remote 的实现发布还不足三个月。这部分工作现在跟进来，参与到现有实现的完善和优化，以及可能的自研 WAL 设计实现过程当中，对任何数据系统开发者而言都将是一段宝贵的经历。

例如，GreptimeDB 在部署形式上支持云端同构部署，时序数据从设备端到云端都是同一套技术栈在处理。这时，如果 GreptimeDB 能够支持一些高级的分析能力，那么时序数据分析的成本将大大降低，体验也将进一步提高。目前，GreptimeDB 已经支持通过 SQL / PromQL / Python 脚本等形式执行分析，正在设计实现基于 Dataflow 技术的分析功能。分析的需求无穷无尽，这一部分对于熟悉数据分析的开发者来说，是一个很好的切入点。

核心数据库系统代码之外，GreptimeDB 还开源了完整的 Dashboard 方案和多语言客户端。再加上本身 GreptimeDB 就支持 SQL 和 PromQL 等业内通用接口，从 GreptimeDB 与生态集成的角度入手参与到 GreptimeDB 的发展，也是一条不错的道路。就在几天之前，我还看到有位同时使用 EMQX 和 GreptimeDB 的开发者向 GreptimeDB 的 Erlang 客户端提交补丁。

软件开发参与之外，Greptime 社群维护的两个重要渠道：GitHub Discussions 主题讨论平台与 Slack 即时通信工作空间都欢迎任何对 Greptime 开源和商业产品感兴趣的人加入。

GreptimeDB 的商业与可持续

我曾经表达过一个观点：商业化不是开源项目可持续的必要条件。因为许多开源软件是个人开发者兴趣所为，这些个人开发者可以有其他经济收入。即使不基于其创造的开源软件做商业变现，也不影响这些开源项目持续维护和发展。

不过，GreptimeDB 是 Greptime 公司研发的开源软件，而公司要想存续下去，就必须以某种形式取得盈利。Greptime 公司投入了不少资本和人力在 GreptimeDB 的研发上，那么 GreptimeDB 总要为 Greptime 的商业成功创造价值。

Greptime 公司目前有两条商业产品线：

• GreptimeCloud 提供了全托管的云上时序数据库服务，其内核是 GreptimeDB 系统。这个服务可以免费试用，其 Playground 和 Dashboard 做的技术品味都很好。

• GreptimeAI 是为 AI 应用提供可观测性的服务。不同于其他数据库在赶上 AI 浪潮时采用的 PoweredBy AI 增强自身产品的思路，GreptimeAI 是 For AI 增强 AI 产品的思路。其实本轮语言大模型带动的 AI 浪潮对 Database 服务本身的提升还十分有限，反而是这些 AI 应用自身产生的数据需要 Database 来存储和管理。

这两个产品的底层都是 GreptimeDB 的开源代码提供的核心能力，而云控制面、企业管理、安全集成等功能，则是商业代码实现的。

至于为什么要开源 GreptimeDB 数据库核心代码，而不是干脆全部都是私有的商业代码，前几天 Meta 的财报上介绍的 Llama 开源的理由帮我省去了很多口水：

应用在 GreptimeDB 的情况，在 Greptime 团队决心做这个产品的时候，先发的主流时序数据库已经取得极大的优势，且它们几乎全是开源的。这种情况下，就算 GreptimeDB 存在没有历史包袱的优势，直接朝着正确的方向飞奔，但是软件工程的固有复杂度和必要劳动时间并不能无限减少，所以开源是追赶现有主流产品和赢得用户信赖的必选项。

当然，开源软件允许任何用户免费使用，因此构建商业价值不能直接基于开源软件本身。关于 Greptime 如何设计开源模型，或许我会另写一篇文章做对比介绍。目前而言，其开源模型接近 Databricks 的策略。虽然 GreptimeDB 是从头开始写的，不像 Databricks 直接基于开源的 Apache Spark 构造解决方案，但是其核心功能实现重度复用了已有的开源软件：

• Apache Arrow DataFusion
• Apache OpenDAL
• TiKV RaftEngine
• Apache Kafka
• …

而且，Greptime 团队对于什么功能应该开源是谨慎的，而不是 by default 开源。只有存在这样一个踌躇推敲的过程，才有可能做商业可持续的战略开源。

DISCLAIMER

在社群参与过程中，我跟 GreptimeDB 的核心社群成员有深入的交流，并于近期加入了 Greptime 团队，因此我的观察和评价可能存在一定的主观误差。欢迎各位留言或私信交流意见。

当地时间 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 协议发布自己的软件以后，自己一下子得到了更多的用户和他们宝贵的反馈，而这才是他作为一个开发者所期待的。同时，作为个人，他没有那么强的动力，实际上也不可能花费大量自己的时间向每一个商用的用户索要费用。

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

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