AI前线导读：

今天，Confluent公司（为Apache Kafka开源软件提供商业化服务支持的初创公司，由Kafka的几位创立者离开LinkedIn后成立）联合创始人兼CEO Jay Kreps在Confluent官方博客发文表示：Confluent平台部分开源组件正式变更开源许可协议，从Apache 2.0切换到Confluent社区许可。这个新的许可允许免费下载、修改和重新发行代码（类似于Apache 2.0），但不允许将这些软件作为SaaS产品提供给用户。去年刚推出并引发关注的流数据SQL引擎KSQL将受到新许可的影响，但Kafka本身不受影响。

上个月，我们刚刚报道过最受欢迎图数据库Neo4j宣布企业版彻底闭源的消息，其中一个原因就是想避免云提供商只从开源中“薅羊毛”而不为这些项目作贡献。这一次Confluent变更开源许可协议，有人认为是开源和云对抗的升级，也有人认为这意味着开源社区的觉醒，你怎么看？

更多干货内容请关注微信公众号“AI前线”（ID：ai-front）

这不是第一例知名开源软件变更开源许可的事件。就在上个月，我们刚报道过知名图数据库Neo4j企业版彻底闭源的消息，而在更早之前，包括 MongoDB、Redis 在内的企业都陆续变更了一些开源项目的许可协议。

正如我们在之前的报道《开源危机：云计算厂商成为开源吸血鬼？》中所说：

处于巅峰的开源软件现在正面临着潜在的危机。

毫无疑问，开源软件的概念已经彻底改变了软件世界。在软件世界接受这种新的格局之前，它们花了数十亿美元与这个想法斗争了好多年。但是，现在有不少人开始怀疑开源软件的本质——几乎所有人都可以使用开源软件，并将它们用于任何目的——这种想法导致开源软件开发者在分布式云计算服务时代出了大问题。

在一些开源软件开发者眼中，这个大问题就是，云计算提供商从开源开发者的工作中受益，尤其是那些颇为成功的开源软件，但他们却没有为这些工作支付一分钱。Redis Labs 首席执行官Ofer Bengal更是直言不讳：“我想直率地说：多年来，我们就像个傻子一样，他们拿着我们开发的东西大赚了一笔”。

开源社区和云计算提供商的矛盾有愈演愈烈的趋势。Kafka无疑是目前全球最受欢迎、应用最广泛的消息系统，而现在，为Kafka提供商业化服务的Confluent也站出来表明了自己的态度。

AI前线将Jay Kreps发表的博文翻译整理如下：

我们正在将Confluent平台的一些组件的许可从Apache 2.0改为Confluent社区许可。这个新的许可允许你免费下载、修改和重新发行代码（类似于Apache 2.0），但不允许你将这些软件作为SaaS产品提供给用户。

例如，你可以将KSQL作为产品或服务的一部分，无论这些产品是作为软件发行还是作为SaaS服务提供给用户，但你不能用它创建类似“KSQL即服务”这样的东西。我们的开发仍然是开放的，并继续接受拉取请求和功能建议。对于那些非商业云提供商用户，即我们的99.9999％用户，新许可对他们来说并没有实质上的限制，同时我们会继续在开发上大量投入。

但新许可并没有针对Kafka，Kafka是Apache软件基金会的一部分，继续使用Apache 2.0许可。新许可只会影响到由Confluent维护的开源组件。

为什么要修改许可？

我们认为这是很有必要迈出的一步。一方面，我们需要大量投入才能开发出这些免费发行的代码，另一方面，我们需要保持业务的健康才能为这项开发提供足够的投入资金。接下来我会解释为什么这两件事都很重要。

首先，这种投资是否有必要？对于很多简单的开源项目来说，我认为不是必需的。GitHub上有成千上万的库不需要太多投资，它们只需要一些志愿者贡献者就可以了。但分布式数据系统不一样，构建一个成功的分布式数据平台是非常困难的。

你不一定要相信我说的话，但事实胜于雄辩。2009——2010年间出现了数十个NoSQL数据库。有些是作为附带项目创建的，有些来自大型网络公司的内部基础设施，有些是作为商业产品创建的。而我认为最明显的是，迄今为止能够继续保持竞争力的系统是那些能够建立稳定的商业实体来维持其开发的系统。那些做到这一点项目（MongoDB、ElasticSearch、Cassandra、Hadoop）都继续蓬勃发展，并成为现代技术栈的一部分。那些做不到的项目（Voldemort、Dynomite、CouchDB，等等）尽管早期也很受欢迎，但大都被淘汰了。它们可能仍然存在，但很可能你从未听说过它们。

造成这种差异的原因似乎很明显，我曾经在LinkedIn等公司、作为志愿者以及作为Confluent的一部分参与开源工作。我们最初在LinkedIn开发Kafka时，在很长一段时间内开发团队总共只有几个人。我利用圣诞假期写了原始代码库，因为公司没有为这个项目提供资源。这个小型的Kafka开发团队开发代码、运行服务，并最终说服了LinkedIn将项目转移到了Apache基金会。他们白天写编码，处理来自社区的问题和错误，晚上开会，并在深夜醒来处理偶尔会出现的运维问题。但随着社区的发展，新需求也随之增长：外部补丁的代码评审经常延迟，除Java以外的客户端库通常无法正常运行。

后来成立了Confluent，我们在开发上的投入远远超过了LinkedIn。很多纯粹出于热情在深夜工作的人现在可以得到报酬，并转成全职工作。Confluent不仅可以为开发提供资金，还可以进行相当大规模的分布式测试，这些测试不仅可以保持代码库的稳定，同时扩展了来自不断增长的社区的贡献。虽然代码仍然不完美，但它的改进速度要快得多。

换句话说，我认为企业可以为开源项目的良性循环带来资金上的支持。

在一个数据系统被作为内部部署软件交付的世界中，我们已经知道如何建立可以推动这种良性循环的可持续发展公司。但这并不容易，而创办一家公司更不容易。我们发现，Apache 2.0等开源许可可以成为维持健康业务的软件产品的主要组成部分。然而，随着云产品的兴起，它们将这些产品作为软件即服务提供给用户，让这个世界发生了巨大的变化。在这个新世界中，云提供商具有显著的优势：他们可以控制资源的定价，并且可以在他们的所有产品中集成自己的服务。

主要的云提供商（亚马逊、微软、阿里巴巴和谷歌）使用开源项目的方式都有所不同。其中一些公司与开源公司合作，这些公司提供系统的托管版本，并作为服务提供给用户。其他的公司则直接将开源代码放到他们的云产品中，并投入资金开发差异化的专有产品。我们不一定要从道德的角度来评判这种行为，他们也只是为了追求商业利益，并在软件许可允许的范围内行事。

作为一家公司，我们可以考虑构建更多的专有软件，并减少开源方面的投入。但我们认为，构建基础设施层的正确方法是使用开放代码。随着工作负载迁移到云端，我们需要一种机制来保持自由，同时也要实现投资周期，这就是我们改变许可的动因。

我们认为这是一个积极的变化，这样可以确保小型的开源社区不会成为科技巨头的免费开发资源，他们只会将资源投入到他们自己的差异化专有产品中。

这意味着什么？

我认为新的许可很简单，即使是没有法律知识的人也能读懂。在新许可中，我们试图尽可能地预先告知我们可以允许那些行为，不允许哪些行为，以及为什么。

不过，我担心会出现两种误读。首先，有人可能会认为Confluent陷入困境，所以需要这样做来赚钱。但事实并非如此，Confluent的表现其实非常出色，我们认为这对我们的客户以及我们投资社区和开源的能力来说都是一件很棒的事情。我们改变许可的目的是确保我们能够保持这种增长，并继续在开放和免费产品上投入。

第二种误读：这是贪婪策略的一部分，一家贪婪的公司想借此赚到更多的钱。对于这个误读，我只能这么说：Confluent并非仅仅是为了赚钱而创立的。我们对以事件流为中心的现代数据驱动型公司的架构有着远大的愿景，我们希望能够实现这一目标。Confluent是由一群相信这个想法能够成为现实的人组成的，对于我们当中的很多人来说，我们在这个项目上的贡献都早于Confluent本身。我们认为，基于事件流进行重新架构是一个大胆的计划，还需要做很多工作。这一次修改许可让我们能够在未来几十年继续开展这项工作，并为实现这一目标的软件、社区和实践做出贡献。

当然，这些并不意味着我们不是商业实体，或者不会专注于我们正在建立的业务。如果我们能够成功，流式平台将成为公司架构的核心，与关系数据库一样，我们将成为重要的、有价值的和具有战略性的数据平台。我们认为这代表了一种巨大的范式转变，并将成为伟大的业务的基础。

一些重要的问答

这对Apache Kafka有何影响？

没有影响。Kafka继续使用Apache 2.0许可。

我可以下载、修改或重新发行代码吗？

可以。代码仍然在GitHub上。

我可以将代码嵌入到我的软件中吗？

可以。

我可以使用代码构建SaaS产品吗？

可以，大部分情况下是可以的。如果你正在构建SaaS产品，可以使用Confluent社区软件。唯一的限制是不能将它们作为与我们的托管产品相竞争的托管服务。例如，你不能将KSQL本身作为SaaS产品提供给用户。

英文原文：

https://www.confluent.io/blog/license-changes-confluent-platform?from=timeline&isappinstalled=0

创作场景

Kafka 团队修改 KSQL 开源许可，怒怼云厂商