我们现将Confluent平台的一些组件的许可证由Apache 2.0改为Confluent社区许可证。这个新的许可证让你可以免费下载、修改和重新分发代码（这非常酷似Apache 2.0），但它不允许你将软件作为SaaS产品来提供。
这就意味着，比如说你可以使用KSQL，觉得它作为你自家产品或服务的一部分很适合，无论那些产品作为软件来交付还是作为SaaS来交付，但是你无法构建KSQL即服务产品。我们仍会在完全公开的环境下开展所有开发工作，接受合并请求和功能建议。对于那些不是商业云提供商的用户（它们是这些项目99.9999%的用户）而言，这对它们可以对软件做什么没有增添任何实质性限制，同时让我们可以继续大力投入于开发。
在这里相信有许多想要学习大数据的同学，大家可以+下大数据学习裙：957205962，即可免费领取套系统的大数据学习教程
这对于ApacheKafka没有任何影响，Apache 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不仅可以为代码贡献提供资金，还可以为运行大规模分布式压力测试所需的大笔云费用埋单，确保代码库稳定，同时让日益庞大的社区继续贡献代码需要这种测试。代码依然不完美，但改进的速度却大大加快了。
换句话说，我确实认为公司/企业有助于为开源贡献的良性循环提供资金。
在数据系统作为内部部署型（on-premises）软件来交付的形势下，我们这个行业已搞清楚了如何创办可持续发展的公司来促进这种良性循环。这不容易，但创办公司向来就不容易。在这种模式下，我们发现Apache 2.0等宽松的开源许可会是保持业务健康发展的成功软件产品的一个主要部分。然而，随着将这种软件作为服务来提供的云产品大行其道，形势已发生了翻天覆地的变化。在这个新形势下，云提供商拥有显著优势：它们控制着服务提供商将使用的所有资源的价格，并且面对其所有产品可以紧密整合自己的服务。
各大云提供商（亚马逊、微软、阿里巴巴和谷歌）在对待开源方面各有不同。其中一些公司与将托管版本的系统作为服务来提供的开源公司合作。其他公司拿来开源代码后做入到云产品中，把自己的所有资源都投入到差异化的专有产品中。我们倒不是想从道德角度对这种行为评头论足，而是说这些公司完全遵循其商业利益，在软件许可证允许的范围内行事。
作为一家公司，我们寻求的一个解决办法就是，我们构建更专有的软件，而对开源投入有所收缩。但我们认为，要构建根本性的基础设施层，正确方法是借助开放代码。随着工作负载迁移到云端，我们需要一种机制来保持这种自由，同时又能支持投入周期，这就是我们改变许可条款的动机。
我们认为这是积极的变化，可以帮助确保小型开源社区没有充当科技巨头免费的、不可持续发展的研发工具，科技巨头们将持续性资源只投入到它们自己的差异化专有产品中。
此举意味着什么？
我认为新的许可证很简单，就算不是律师也能看得一清二楚；无论是许可证，还是这份公告，我们都力求尽量阐明我们想要允许的做法、我们想要阻止的做法以及个中原委。
我担心外界对这份公告有两种愤世嫉俗的解释。第一种解释是，这表明Confluent现在步履维艰，需要这么做才能赚钱。事实并非如此，Confluent的业绩非常好，我们认为对于我们的客户以及对于我们投入于社区和开源的能力来说这都是一件好事。我们作出这番变化的目的是，确保我们能够保持这种发展，并继续投入于开放免费的产品。
颇具讽刺意味的是，第二种愤世嫉俗的解释恰恰相反：这是一种贪婪策略的一部分，一家贪婪成性的公司企图攫取更多的钱。对此我只能这么说：Confluent当初并不仅仅是为了赚钱而创办的。我们对于一家现代数据驱动型公司以事件流为中心的架构抱有愿景。我们希望在世界上实现这个目标。Confluent是一群坚信这个想法的人；对于我们中的许多人来说，我们在这个项目上开展的工作早于Confluent本身。构建代码和社区方面的早期工作并不是将其实现商业化的长达十年的计划的一部分。确切地说，我们认为围绕事件流，为世界上的所有公司重新设计架构的计划是大胆宏伟的计划，需要做大量的工作。这番变化使我们能够在未来几十年继续开展这项工作，为软件、社区和实践做贡献，从而实现这一目标。
这一切并不意味着我们不是一家商业实体或并不专注于我们在建立的业务。如果我们取得成功，这个事件流平台将完全成为一家公司的架构的核心，将会与关系数据库一样重要、有价值、具有战略性意义。我们认为，这代表一次巨大的范式转变，将是优秀公司的基础。
回答几个问题
下面是读者可能提出的另外几个问题的答案：
这对ApacheKafka有何影响？
没有影响。我们继续通过Apache软件基金会，为采用Apache 2.0许可证的Apache Kafka做贡献。
我可以下载、修改或重新分发代码吗？
可以。代码仍然都完全放在GitHub上。
我可以将代码嵌入到分发的软件中吗？
可以。
我可以使用代码来构建SaaS产品吗？
是的，几乎在所有情况下。如果你在构建一款SaaS产品，可以使用Confluent社区软件。唯一的限制是针对这种托管的服务产品：它提供的软件是与我们自己的托管服务产品相竞争的产品。因此比如说，要是KSQL本身就是提供的产品，你就无法构建SaaS产品。