作者： Shay Banon
请注意：最初发布这篇博客后，我们又增发了两篇博客来补充一些详细信息：许可协议变更澄清 和 为什么我们必须变更许可协议。
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 企业搜索、可观测性和安全。
我们有成熟的产品，围绕这些产品培育了充满活力的社区，并专注于为用户提供最大价值。今天，我们有数百名工程师，他们每天的工作内容就是努力让我们的产品变得更好。而且我们还有成千上万的社区成员参与其中，帮助我们取得共同成功。
我为我们建立的公司感到骄傲，更为我们赢得用户的信任而深感责任重大。我们从成立之初就是一家开放、透明的公司，并且我们在各项决策中也一直坚持全心全意为社区和广大用户服务。
免费开放 — 无可替代
早在 2018 年，我们就在 Elastic 许可（一种可获得源代码的许可）下开放了免费和付费专有功能的代码，并将默认分发版更改为了包含所有功能，并默认启用所有免费功能。
这样做有几个原因。首先，这让我们能够像与社区互动一样接触我们的付费用户：实现公开交流。再者，让我们能够构建更多赋予我们用户的免费功能，而不是将这些功能提供给某些公司，他们不只是自己使用我们的产品，还会将我们的产品作为他们对外提供的服务（如 Amazon Elasticsearch Service）之一，并从我们的开源软件中获利，而并没有做出任何回馈。
我们的这种做法很受欢迎。今天，超过 90% 的新下载用户都选择了这个分发版，这使得我们能够免费提供这么多的功能，同时也建立了一家成功的公司。
在这项新的免费、开放（但又是专有的）许可下，我们推出了大量改进。我为我们的团队和社区在所有产品上取得的惊人进步所折服，我非常乐意与大家分享其中的一些改进：
我们通过一种新的分布式一致性算法极大提高了 Elasticsearch 的速度、可扩展性和可靠性，并显著降低了内存使用量；此外，还应用了新的数据存储和压缩方法，在提高索引和查询吞吐量的同时，将典型索引大小缩减了近 40%。我们针对地理空间分析添加了新的字段类型，以更有效的方式来存储和搜索日志，并对安全性数据执行快速、不区分大小写的搜索。在 Kibana 中，我们将加载时间缩减了 80%，消除了整页刷新，这都要归功于一个多年的平台重构项目，同时我们还引入了 Kibana Lens 直观的拖放式数据可视化体验，以及仪表板深入分析等关键功能。
在过去三年里，我们还围绕最常见的用例构建了一流的体验。在安全解决方案方面，我们直接在 Kibana 内部创建了一个免费开放的 SIEM，它有一个强大的检测引擎，通过 Elasticsearch 中新的查询语言 EQL 支持简单的规则和复杂的关联。我们与社区协作，公开开发了数百条检测规则。而且，我们还与领先的终端安全公司 Endgame 联手，发布了免费且功能强大的恶意软件防护功能，这也是 Elastic Agent 中的一项重要功能；Elastic Agent 是我们针对服务器和终端推出的统一、集中管理的可观测性和安全管理代理软件，未来还会推出更多功能。
在可观测性方面，改进也齐头并进。我们直接在 Kibana 内部构建了一个完整的可观测性套件，从实时的 tail 日志 UI 到直观的基础架构级视图，能够查看主机、Pod 和容器中的各项关键指标和告警。现在，我们有了一个功能齐全的 APM 产品，配备了开源数据收集器和代理，支持 OpenTelemetry、真实用户监测 (RUM)、综合监测，以及最近添加的用户体验监测。
在 Elastic 企业搜索中，我们引入了 App Search，这是基于 Elasticsearch 的，它简化了复杂应用程序的构建过程，并提供了强大的管理界面，用于相关性调优，以及使用情况分析。此外，我们还提供了一个免费的 Workplace Search 产品，可以轻松的集成和搜索您所使用到的有关个人或公司的各种内容数据源，如 Google Workplace、Microsoft 365、Atlassian Jira 和 Confluence 以及Salesforce。
我们能够构建所有这些功能，并免费的提供给我们的社区，这真是太了不起了。看到我们产品的参与度和采用率，以及这些新功能帮助这么多人和企业取得了成功，我们深感责任重大。之所以能够做到这一点，正是因为我们社区的绝大多数人都选择了 Elastic 许可下的默认分发版，其中所有这些功能都是免费开放的。
为什么要变更许可协议？
如前所述，在过去三年中，市场不断发展，社区逐渐认识到，开源公司只有更好地保护自己的软件，才能保持高水平的投资和创新。随着以 SaaS 作为交付模式的转变，一些云服务提供商利用了开源产品的优势，将其作为一项服务对外提供，而不向社区提供任何回馈。这种做法转移了本可以再投资到产品上的资金，损害了用户和社区的利益。
与众多开源同行一样，我们也亲身经历过这种情况，从我们的商标被滥用，到企图通过对我们的 OSS 产品进行“公开”重新包装，甚至从我们的专有代码中获得“灵感”，这些做法彻底的分裂了我们的社区。虽然每个开源公司解决这个问题所采取的方法略有不同，但为了保护他们在免费软件上的投资，他们在试图保持开放、透明和协作原则的同时，通常都修改了自己的开源许可。同样，我们也本能地采取了这样的做法，就如何授权我们的源代码做了有针对性的变更。此次变更对绝大部分用户没有影响，主要是限制云服务提供商将我们的软件作为一项服务对外提供。
我们估计，会有一些竞争对手围绕这一变更试图传播各种各样的担忧、不确定性和质疑。我在这里对那些唱反调的人郑重说明：我们对产品免费开放，以及对社区透明的原则坚信不疑。我们以往的表现也证明了这一承诺，我们将继续在此基础上再接再厉。
到底有哪些变化
从即将发布的 Elastic 7.11 版开始，我们将把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为双重授权许可模式（即 SSPL + Elastic 许可），以便用户选择适合自己的许可。SSPL 是 MongoDB 原创的一个可获得源代码的许可，它既体现了开放原则，同时又起到了保护作用，防止公共云提供商在不向社区提供任何回馈的情况下将开源产品作为一项服务对外提供。SSPL 虽然允许免费随意地使用及修改产品源代码，但有一个基本要求，也就是，在 SSPL 协议下，如果您将产品作为服务对外提供，则必须同时公开发布任何修改以及您自己管理层的源代码。
我们之所以选择这条道路，是因为它给了我们一个尽可能开放的机会，同时还保护了我们的社区和公司。在某些方面，这一变更会让我们更加开放。作为这一变更的后续工作，我们会着手将我们的免费专有功能从 Elastic 许可改为 SSPL 下的双重授权许可，这将更加宽松，更符合我们使产品尽可能免费开放的目标。
虽然更改源代码的许可在某些方面是一件大事，但对我们社区的绝大多数人实际上没有任何影响。如果您是我们的客户，无论是在 Elastic Cloud 还是本地部署，请放心，一切都没变。如果您已经下载并在使用我们的默认分发版，它们都是的 Elastic 许可，仍然是免费且开放。如果您一直在为 Elasticsearch 或 Kibana 的项目代码做贡献（非常感谢！），对您来说也没什么变化。
我们会与过去三年一样，将继续以开放的方式开发我们的代码，与我们的社区协作，并在 Elastic 许可下免费发布我们的版本。我们仍然承诺保持我们所有的免费功能继续免费，不会做任何改变，以前免费使用的功能依然免费，需要付费订阅的功能继续付费订阅。
我们对统一社区的重要性的信念从未如此坚定。这一变化能够使我们像过去 10 年那样，继续表明我们的承诺，并用未来的行动赢得您的信任。
资源：
前瞻性陈述
本篇博文包含了涉及重大风险和不确定性的前瞻性陈述，其中包括但不限于：关于公司代码许可、软件即服务和开源服务器端软件的市场机会、开源创新的好处、公司采用的许可模式的影响、我们未来在研发方面的投资，以及我们对解决方案和产品优势的评估等陈述。这些前瞻性陈述符合 1995 年《私人证券诉讼改革法案》中安全港条款的规定。这些前瞻性陈述反映了我们目前对其计划、意图、预期、战略和前景的看法，是基于我们目前所掌握信息和我们所作假设提出的。尽管我们认为这些前瞻性陈述所反映或建议的计划、意图、预期、战略和前景是合理的，但我们不保证将达到或实现这些计划、意图、预期或战略。由于不确定性、风险和环境变化，实际成果和结果可能与这些前瞻性陈述中所预期的成果和结果存在重大差异，包括但不限于：我们及时、成功地实施新的双重授权许可模式并实现其各项优势的能力；客户和我们的用户社区对新许可模式的接受程度；我们继续建立和维护开发人员社区信誉的能力；竞争对手 SaaS 服务的影响；我们维护、保护、执行和增强我们知识产权的能力；SaaS 产品的扩展和采用对开源许可模式的影响，以及我们对未来运营的信念和目标。我们向证券交易委员会（简称 SEC）提交的文件中包含了可能导致实际成果和结果发生重大差异的其他风险和不确定性，其中包括截至 2020 年 4 月 30 日本财年的 10-K 年度报告，以及随后提交给 SEC 的任何报告。SEC 文件可在 Elastic 网站 (ir.elastic.co) 的“投资者关系”部分或 SEC 网站 (www.sec.gov) 找到。除法律规定外，Elastic 公司不承担更新任何此类前瞻性陈述的义务，目前也没有更新的打算。
原文出处：https://www.elastic.co/cn/blog/licensing-change
来源：oschina
链接：https://my.oschina.net/u/4397718/blog/4933403