共计 1703 个字符，预计需要花费 5 分钟才能阅读完成。
今日 Elastic 公司 CEO Shay Banon 在公司官网发文训斥：「之所以决定将 Elasticsearch 和 Kibana 的开源协定由 Apache 2.0 变更为 SSPL 与 Elastic License，次要起因为了阻止云厂商的「白嫖」。」
此前在 1 月 15 日，Elastic 在官网发文称将对 Elasticsearch 和 Kibana 在许可证方面进行了重大的更改，由开源 Apache 2.0 许可证改为采纳 SSPL（服务器端公共许可证）。
Elastic 称变更确保了他们的社区和客户能够自在凋谢地应用、批改、从新公布和合作代码。它还通过限度云服务提供商在没有回馈的状况下将 Elasticsearch 和 Kibana 作为一项服务提供给用户，来爱护他们在开发收费和凋谢的产品方面的继续投资。这将实用于这两个产品的所有保护分支，并将在他们行将公布的 7.11 版本之前进行。版本将持续采纳 Elastic License，就像过来三年一样。
Elastic 示意源代码受权的这一变动对绝大多数收费应用默认发行版的用户社区没有影响，对云客户或自管理软件客户也没有影响。
为什么要扭转
如前文所述，在过来的三年里，社区曾经意识到市场产生了变动，开源公司须要更好地爱护本人的软件，以放弃高水平的投资和翻新。随着向 SaaS 交付模式的转变，一些云服务提供商将开源产品作为一种服务提供，而不收取回馈。这种做法「挪用」了原本能够从新投入到产品中的资金，侵害了用户和社区的利益。
与 Elastic 的开源同行相似，他们也亲身经历了这种状况，从商标被滥用，到公然试图通过「凋谢」从新包装开源软件产品，甚至从专有代码中获取「灵感」，以上种种行为都是在决裂社区。尽管每家开源公司都采取了不同的办法来解决这个问题，但他们个别都批改了开源许可证，以爱护他们在自由软件上的投资，同时致力保护凋谢、通明和合作的准则。同样，Elastic 下一步也会对他们的源代码以受权的形式进行针对性的批改，这一扭转不会影响绝大多数用户，但会限度云服务提供商将软件作为服务提供。
尽管一些竞争对手可能试图围绕这一变动分布各种 FUD（惧、惑、疑）。但 Elastic 示意他们始终深深置信自在和凋谢产品的准则，以及对社区的透明度。
将做出哪些扭转
从行将公布的 Elastic 7.11 版本开始，Elastic 将把 Apache 2.0 受权的 Elasticsearch 和 Kibana 代码转为 SSPL 和 Elastic License 的双重受权，让用户能够抉择实用哪个受权。SSPL 是 MongoDB 创立的一个源码可用的许可证，以体现开源的准则，同时提供爱护，避免私有云提供商将开源产品作为服务提供而不回馈。SSPL 容许自在和不受限制的应用和批改，但如果你把产品作为服务提供给他人，你也必须在 SSPL 下公开公布任何批改以及管理层的源代码。
Elastic 认为抉择了这条路线，会让他们有机会尽可能地凋谢，同时爱护社区和公司。作为这一变动的后续口头，Elastic 将开始把收费专有性能从 Elastic License 转移到 SSPL 下的双重许可，这将更加宽松，也更合乎使产品尽可能自在和凋谢的指标。
尽管从某些方面来说，扭转源代码的受权是一件小事，但社区的绝大多数人实际上不会经验任何扭转。如果你始终在下载和应用默认发行版，它依然是收费的，并且在雷同的 Elastic License 下凋谢。
Elastic 的扭转并非个例
计算机技术进入云时代后，与云平台的争端成为了开源软件业务无奈回避的一个难题。起因是云厂商通过打包这些产品进行基于云的 SaaS 服务，对这些公司造成了间接的竞争，相似于 MongoDB、Redis Labs 和 Confluent 等公司为了避免竞争不得不抉择更改了软件许可证，从原来的开源许可证转向更严格的条款，限度了软件的性能。
当初 Elastic 也走上了这条「背离开源之路」，这样的做法对 Elastic 自身也是一种挫伤，比方 Hopsworks 这样的开源平台就抉择迁徙到 Elasticsearch 的 Open Distro 分支，但目前除了批改条款还没有更好的解决方案。
原文链接：
https://www.elastic.co/cn/blo…
