Elasticsearch 和 Kibana 的许可协议即将变更

我们即将把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 的源代码变更为双重许可模式（即 SSPL 1.0 和 Elastic 许可），以便用户选择适合自己的许可。通过这一许可协议的变更，这样既能确保我们的社区和客户继续以免费开放的方式使用、修改和重新分发代码，又能开展基于代码的协作，而且还可以限制云服务提供商在不向社区提供任何回馈的情况下，将 Elasticsearch 和 Kibana 作为一项对外提供的服务，从而保护我们在开发免费及开放产品方面的持续投资。此次变更将适用于 Elasticsearch 和 Kibana 的所有维护分支，并从我们即将发布的 7.11 版本开始生效。我们的发行版将继续使用与三年前相同的 Elastic 许可。

此次源代码许可协议变更对绝大部分免费使用默认分发版的社区用户没有影响，也不会影响我们的云服务客户或自管型软件客户。

近年来，市场已发生了很大的变化，社区开始逐渐的认识到，开源公司只有更好地保护了自己的软件，才能够实现持续创新和进行必要的投资。随着很多公司不断的转型到 SaaS 产品，有些云服务提供商已经采用了开源产品，并在不向社区提供任何回馈的情况下，将其作为一项对外提供的服务。在大约三年前，我们开放了商业代码，并将他们全面的开放，所有这些都是在 Elastic 许可下进行的，从而让我们现在可以采用 SSPL 和 Elastic 许可的双重授权许可策略，这对我们来说是水到渠成的一步。这与近年来许多其他开源公司（包括开发 SSPL 的 MongoDB）的做法类似。SSPL 虽然允许自由随意地使用及修改产品源代码，但有一个基本要求，也就是，在 SSPL 协议下，如果您将产品作为服务对外提供，则必须同时公开发布所做出的任何修改，以及您自己构建的管理层源代码。

我们的开源之旅

我个人的开源之旅可以追溯到很久以前。2005 年，我开源了我的第一个项目 — Compass，在 Apache Lucene 的基础上提供了一个 Java 框架，那时我在为我妻子开发一个关于菜谱的应用。在接下来的五年间里，我投入了无数个周末和夜晚来完善这个项目，从编写代码到帮助用户解决故障、功能等方面的各种问题。

我并没有细想自己做这件事的目的是什么，尤其是我还有一份已经沦为“副业”的工作，但我醉心于此，因为这是能产生如此积极影响的机会 — 尝试通过开源的力量，打造出一款优质产品，而且更重要的是，围绕这款产品构建起一个良好的社区。

2009 年，我决定重新再来一次，于是开始编写一个全新的项目，它就是 Elasticsearch。我花了很多个夜晚和周末来构建这个项目，并在 2010 年开放了源代码。我甚至辞掉了工作，决定全力以赴。通过编写代码、在 GitHub 上写博客、发邮件及通过 IRC 聊天工具，为用户提供帮助。

而当我们在 2012 年成立 Elastic 公司时，也将这种精神带到了我们的公司。我们在免费开放的产品上投入了大量资金，并支持用户社区的快速发展。我们从单纯的 Elasticsearch 扩展到 Kibana、Logstash、Beats，现在，Elastic Stack 中内置了一系列的解决方案：Elastic 企业搜索、可观测性和安全。

我们有成熟的产品，围绕这些产品培育了充满活力的社区，并专注于为用户提供最大价值。今天，我们有数百名工程师，他们每天的工作内容就是努力让我们的产品变得更好。而且我们还有成千上万的社区成员参与其中，帮助我们取得共同成功。

我为我们建立的公司感到骄傲，更为我们赢得用户的信任而深感责任重大。我们从成立之初就是一家开放、透明的公司，并且我们在各项决策中也一直坚持全心全意为社区和广大用户服务。
 
详细阅读，请参阅文章 https://elasticstack.blog.csdn ... 38956