2019年7月16日，YugaByte DB 创始人兼 CTO Karthik Ranganathan在其官方博客发文宣布 YugaByte DB 已经100%开源，遵守Apache 2.0开源许可。YugaByte DB具有基于Google Spanner的存储架构和基于PostgreSQL的查询层，此次开源意味着其之前闭源的商业及企业功能现在也可以在开源项目中完全免费使用，而且即将推出的新功能也可以完全免费使用。

与YugaByte DB选择100%开源不同，近段时间多家开源软件公司选择了收紧授权许可。针对这些公司的开源许可变更， Karthik Ranganathan 也发表了自己的看法，他认为：“这些公司变更开源许可表面看起来似乎都是为了和AWS的DBaaS服务抗衡，但其实真正的原因各不相同，例如MongoDB 改为SSPL的主要目的其实是为了打击多年来兴起的较小的MongoDB托管服务商，并且想要将这部分托管云业务迁移到他们自己的Atlas服务；Cockroach Labs改为BSL的原因是为了给自己树立一个知名度高的竞争对手；而Confluent的目的则真的是为了禁止AWS从其开发的企业功能中获利。”

以下为 Karthik Ranganathan 博客原文的译文：

我们很高兴地宣布，YugaByte DB现在已经实现了100%开源，遵守Apache 2.0开源许可。这意味着之前闭源的商业以及企业功能，例如分布式备份、数据加密和只读副本，现在都可以在开源项目中完全免费的使用。并且这也同样适用于YugaByte DB即将推出的新功能，例如Change Data Capture 和 2 Data Center Deployments。

100%开源也意味着我们不再拥有YugaByte DB的Community Edition和Enterprise Edition，只有一个YugaByte DB 版本，那就是完全开源的版本。同时，我们宣布之前闭源的管理软件也将开源可用。以上这些修改从1.3版本开始生效，该版本于7月16日可用。

“开发人员越来越多地将PostgreSQL作为一种 Oracle 的逻辑替代方案，因为他们不再使用基于多个云上运行的、基于微服务的应用程序的单一数据库。但是PostgreSQL并不是专为云平台构建的，开源替代方案也有所限制。而Yugabyte DB通过支持PostgreSQL的现代云基础架构功能，填补了其在这一方面的空白。如今100%开源，Yugabyte DB也消除了其它使用障碍，成功吸引了在云原生平台上构建关键业务应用程序的开发人员。”

- Matt Asay，Adobe的专栏作家兼开发者生态系统负责人

行业观察员和开源专家指出：“Yugabyte DB的开源举措，与最近数据库和数据基础设施公司取消部分或全部核心项目开源许可有很大不同。”下图总结了Yugabyte DB与MongoDB、Cockroach Labs，Confluent（Apache Kafka背后的主要商业公司）和Elastic（2018-2019年）所做的开源更改。

本文将详细介绍YugaByte DB OSS项目和YugaByte作为商业OSS公司的目标以及开源变化背后的原因。

为什么要开源？

多年来，开源已被证明是开发和分发业务关键型基础架构软件最成功的方法。首先，它消除了用户的入门门槛，而且由于软件具有绝对的自由度，所以使得采用率的指数式增长成为可能。这种采用为快速、协作、社区驱动的功能丰富的软件开发提供了必要的快速反馈回路，同时也保持了高质量和可靠性。通过这种方法，安全性加强、生态系统集成、可扩展性框架和其他企业功能自然会变得更强。

具有免费增值层的专有基础设施软件也能做到这一点吗？是的，也可以做到，不过如果软件要成熟到相同的水平线，那么可能需要比较长的时间。此外，协作开发的损失和较慢的反馈循环意味着软件可能无法获得市场吸引力，从而逐渐消失。

开源许可变更

正如《Building a High Growth Business by Monetizing Open Source Software》文章中描写的，“开源软件和商业盈利并不矛盾。”健康的商业盈利是持续投资开源的必备条件，特别是在单一供应商的OSS项目中。针对那些认为OSS项目不能从单一供应商开源的纯粹主义者，我们也想提一个问题：“你们能否想象一个没有MongoDB、Elastic、Confluent、Databricks、Redis Labs、InfluxData、Hashicorp和更多商业OSS公司的世界？”

目前开源基础设施软件的商业模式大致可以分为以下三种：

Service, Support & Training
Open Core
Managed Service

其中，第一种和第三种比较容易理解，但是围绕着开源基础软件商业模式的讨论仍是大家关注的问题。对于数据库和数据基础设施公司而言，传统的Open Core意味着公司要为商业版本单独保留某些“企业级功能”，这类功能往往会包含附加功能，例如构建新数据模型、备份存储的数据、安全数据以及加密、多数据中心复制等。而管理软件位于核心之外，提供自动化集群创建、扩展、升级、备份和监控。托管云服务可以视为是具有内置云基础设施业务流程的托管管理软件。

有了以上的认知之后，我们来一起分析一下前文中提到的四家公司的开源许可变更，虽然在有些人看来，这四个事件大同小异，但其实每个案例都是独一无二的。

MongoDB：Core DB的开源许可从APGL更改为SSPL

2018年10月，MongoDB宣布将其核心数据库的开源许可从AGPL更改为SSPL。由于SSPL不是OSI批准的许可证，因此这种变化实质上意味着MongoDB现在已经成为了专有软件。

虽然大家都认为MongoDB改变开源许可是为了与AWS提供的数据库即服务竞争，但其实MongoDB真正要竞争的并不是AWS，2019年1月AWS 推出的兼容MongoDB的DocumentDB就是最好的证明，而且MongoDB最初的AGPL许可其实也有效的阻止了AWS按原样托管MongoDB。

由于MongoDB的创新一直是基于其查询语言，所以AWS必须为该查询语言重建服务器，并在类似Aurora的存储架构上运行它。这也是Azure Cosmos DB在2017年推出兼容MongoDB的API时所采用的方法。

MongoDB公司的管理人员不可能不清楚这些情况，所以他们更改为SSPL的主要目的其实是为了打击多年来兴起的较小的MongoDB托管服务商，并且想要将这部分托管云业务迁移到他们自己的Atlas服务。所以，我们看到云数据库服务公司MLAB在SSPL发布前一周被MongoDB收购了。

Cockroach Labs：Core DB的开源许可从Apache 2.0更改为BSL

2019年6月，Cockroach Labs 更改了许可证，其核心数据库从Apache 2.0更改为Business Source License（BSL），由于最初由MariaDB创建、采用的BSL也未经OSI批准，因此CockroachDB现在也是专有软件。

开源许可修改的公开原因也是因为AWS提供的托管云服务，不过，从现实情况来看，CockroachDB还没有达到AWS感兴趣的采用水平。那么为什么Cockroach Labs会做出改变呢？我们认为主要原因是将对手设为AWS有利于宣传，尤其是把对手定位为AWS增长最快的服务Amazon Aurora，因为有竞争才更有利于市场定位。

那么开源社区的反对声音怎么办呢？从目前的情况看，批评者的声音很小，时间一长，新用户未必会关心其开源许可是否发生了变化。

Confluent：Enterprise Features从Apache 2.0更改为CCL

Confluent是Apache Kafka背后的主要商业公司，Apache Kafka是一个广受欢迎的流媒体平台。在2018年12月，Confluent宣布将其部分企业功能的开源许可从Apache 2.0更改为Confluent Community License（CCL）。CCL是可用的开源许可证，但也不允许与Confluent 商业产品竞争的托管服务使用该功能。

由于Apache Kafka是由Apache Source Foundation（ASF）管理的Apache 2.0 许可的OSS项目，所以可以被所有云提供商托管。在Confluent公告发布之前，AWS已于2018年11月宣布了Kafka 管理流（MSK）服务。所以，这次开源许可变更的原因很明确，就是为了禁止AWS从其开发的企业功能中获利。

Elastic： Enterprise Features从闭源更改为 Elastic License

自2015年10月以来，AWS一直在提供Elasticsearch服务，因此，AWS并不是Elastic在2018年2月更改许可的原因，Elastic在新的开源许可下发布了其以前的闭源商业软件X-Pack的源代码，这一开源许可被称为 Elastic License（EL）。

Elastic这样做是为了促进协作开发和快速反馈循环。Apache 2.0 和Elastic License 许可下的代码都存放在相同的GitHub仓库中，可用于构建纯OSS代码以及OSS + EL代码。与所有最新的开源许可一样，Elastic License不允许来自托管服务的竞争。

DB Monetization 已死， DBaaS Monetization 长青

抛开最近的开源许可趋势不谈，我们能从OSS DB 商业化的历史中学到什么吗？首先，我们要了解Amazon Aurora成功地将PostgreSQL和MySQL规模化采用实现商业化背后的原因。其次，我们要分析MongoDB Atlas做的同样的事情，它也实现了MongoDB规模化采用的商业变现。另外，还有一个数据分析市场的例子，Databricks和AWS的Apache Spark EMR 商业化的例子。

在这些例子中，直接将OSS商业化，只有部分公司取得了成功，但是将云服务商业化的例子都获得了成功。用户需要很长时间来建立对数据库的信任，但是这种信任一旦建立成功，他们愿意为DBaaS的便利性支付更多的成本，尤其是当他们的数据库采用达到了一定的规模。

我们YugaByte认为，如果AWS想要基于OSS项目构建托管服务，几乎没有什么可以阻止它，唯一的问题可能就在于AWS需要为开发OSS付出代价。包括AGPL在内的限制性许可虽然可以减缓AWS的速度，但不能阻止它，所以这类许可真正的影响应该是降低用户的使用。

另外，AWS 构建服务也从另一个侧面证明了该OSS项目的持久力，让用户可以相信，他们的投资将获得多方保护。但是，对于商业OSS公司来说，这意味着他们必须提供足够出色的DBaaS服务来与AWS竞争，而不是依靠核心OSS DB的优势。在这一方面，Elastic就做得很好，它非常详细地强调了它与AWS的区别。

OSS项目与商业产品

鉴于上文的认知，我们不仅决定将YugaByte DB 100%开源，同时也会在OSS DB项目和商业DBaaS产品之间划清界限。之前企业版的自我管理DBaaS功能将会重新命名为 YugaByte Platform 。同时，我们还会宣布YugaByte Cloud的早期计划，这是我们在AWS和Google Cloud上完全托管的DBaaS产品。

在Polyform Free Trial License 1.0 (PFTL)下，YugaByte Platform 的源代码现在可以在与 YugaByte DB相同的GitHub存储库中获得。考虑到PFTL存在免费试用的限制，不符合开源的定义，因此YugaByte Platform应该被视为专有软件。

GitHub存储库中的默认构建目标只生成OSS二进制文件，以确保对基于PFTL的商业DBaaS特性不感兴趣的用户也可以拥有好的使用体验。对于有兴趣与提交者就商业特性进行协作的用户，此更改允许进行协作，包括讨论问题、提供设计反馈，甚至在上游提交自己的修复程序。这种方法类似于Elastic，但有一个显著的区别，即 YugaByte DB的企业特性是OSS，而Elastic不是。

Oracle for the Cloud

我们从不羞于承认我们想成为云上的Oracle的野心。在此之前，有很多公司都为此目标做了很多努力，但是都失败了，那么我们有什么不同之处吗？

1. Oracle-like Depth in Distributed SQL

我们的团队中有很多前Oracle数据库工程师，所以我们很清楚，只有数据库客户端的语言在确保高性能的同时，还能提供类似于Oracle的数据建模灵活性，应用程序开发人员才会把它放在和Oracle同样重要的位置上。

而这正好是YugaByte SQL（YSQL）的用武之地。YSQL按原样重用了PostgreSQL的查询层，但运行在DocDB (YugaByte DB受谷歌Spanner启发开发的分布式文档存储)之上。这种组合为YSQL提供了两种独特的优势，确保开发人员可以获得类似于Oracle的体验。

支持广泛的现有PostgreSQL结构，如存储过程、函数、触发器、扩展等。这涵盖了分布式SQL的“SQL”深度方面，现有的企业级SQL被设计用于高性能和可靠性高的分布式存储体系结构。
即将支持新的SQL构造来定义co-partitioned tables、行级地理分区以及增强SQL驱动程序，支持拓扑感知路由，从而确保高性能查询。这涵盖了分布式SQL的“分布式”深度方面，其中SQL得到了增强，可以最大限度地利用底层分布式存储体系结构。

2.类似PostgreSQL的大规模OSS采用

仅仅在分布式SQL中具有类似Oracle的深度是不够的，开发人员必须能够在自己的应用程序环境中体验到这种深度。这意味着需要与应用程序开发框架、对象关系映射器以及其它云基础架构的安装程序进行广泛和深入的集成。然后，通过开发人员将这些整合的好处带到各自的社区。通过这种方式，多年来PostgreSQL变得越来越受欢迎，作为PostgreSQL的分布式化身，我们完全可以执行类似的方法。

3.类似Aurora的DBaaS商业化

如果没有有效的商业化战略来实现对OSS项目的持续再投资，从长远来看，OSS项目可能会失败。正如我们之前强调的那样，DBaaS驱动的商业化是最佳选择。Amazon Aurora是非常成功的完全托管DBaaS的典范。但是，企业可能还需要额外的灵活性来自行管理自己基础架构上的DBaaS，这正是YugaByte Cloud和YugaByte Platform的发挥空间。

总结

YugaByte DB具有基于Google Spanner的存储架构和基于PostgreSQL的查询层，旨在为现代应用程序在云原生基础架构上提供分布式SQL中类似Oracle的体验，这次完全开源之后，我们希望工程团队能够比以往更快地向这种云原生应用程序发展。也许，有些人会觉得我们的目标有点大，甚至是不可能实现的，但是我们会一直努力，请大家持续关注我们。

下一步规划

原文链接：

https://blog.yugabyte.com/why-we-changed-yugabyte-db-licensing-to-100-open-source/

创作场景

开源软件纷纷收紧授权许可，为何 YugaByte DB 却选择 100% 开源？