为什么SSPL对你有害(第二部分)

后MongoDB切换到SSPL我写了这篇文章的第一部分，标题是“为什么MongoDB的SSPL对你有害”。当时这是一个MongoDB现象，尽管在过去两年多的时间里，更多的公司(通常是风投资助的独角兽公司或上市公司)改变执照到SSPL或类似。这在弹性更改他们的许可证到SSPL这是一个特别令人担忧的案例，原因有很多。

所以，在我们跳到本文的主题之前，让我谈谈为什么我认为Elastic的变化比MongoDB更令人担忧。

弹性的承诺，未兑现

弹性已经做了一些2018年牌照的自我反省。在那篇文章中，Shay Banon承诺“我们仍将是一家开源公司。”你还可以看到，因为开放和非开放代码混合在同一个GitHub存储库中，所以提供了以下解释和承诺:

有一个有趣的现象Twitter的线程看看这个。

据我所知，MongoDB从未给出过类似的承诺，总的来说，他们一直是一个“不情愿的开源公司”，并且相当开放地将MongoDB作为开源发布是他们的免费增值营销策略(源）.

从许可许可证更改

MongoDB一开始就获得了AGPL许可，这是一个非常严格的copyleft许可。从理论上讲，它应该保护MongoDB不必在提供DBaaS方面与云超规模提供商竞争。然而，在实践中，有许多公司提供AGPL许可的MongoDB作为其DBaaS的一部分，并且正如传言所说，它不容易执行。

事实上，MongoDB是AGPL授权的，这意味着MongoDB和其他贡献者从来没有一个“公平的竞争环境”。例如，在Percona，我们正在雷竞技下载官网构建MongoDB的扩展版本雷竞技下载官网MongoDB的Percona服务器-我们只能先在AGPL下发布它，然后是SSPL许可证。MongoDB可以在专有许可(比如MongoDB Enterprise)或任何其他开源许可下出售它，如果他们愿意的话。这一点很重要，因为许多公司，包括谷歌，不允许使用AGPL软件。

然而Apache 2.0是一个非常宽松的许可证，因为人们可以将这样的软件嵌入到几乎任何私有(或开源)软件中，使其作为云可用，等等。这意味着Elastic许可证变更将影响到更多的用户，比MongoDB的情况要严重得多。

贡献者,误导

Elastic有大量的贡献者，如果你相信这个来源。在创新速度方面，Elastic对贡献者的依赖远远超过MongoDB。这并不奇怪，因为核心软件使用的是Apache 2.0许可证，许多公司都有理由让ElasticSearch更好地满足他们自己的需求。

其中许多贡献都是因为合并后的工作可以在Apache 2.0许可下使用，而且Shay非常直言不讳地表示Elastic将永远坚持使用Apache 2.0许可。

我想知道，如果他们知道他们使用衍生作品的唯一方式是在SSPL许可的条款下，他们中有多少人会做出贡献……可能不会很多。

当然，你可以争辩说，贡献者仍然可以使用Apache 2.0授权的旧软件，如果他们不喜欢Elastic正在做的事情，他们可以派生它。但是，对于那些不擅长Elasticsearch开发的公司来说，这样做是不现实的。

有些公司有很大的业务需要Elastic来实现真正的开放(但不是Elastic对开放的定义)。正如我所期待的，AWS正在拆分ElasticSearch的工作为基础Elasticsearch的开放发行版。而且它并不孤单。Logz声明他们也在做同样的事情，虽然没有承诺自己做，艾文表示希望社区会一起来做这件事

危险的文字游戏

题目是关于许可证变更的博客文章是"加倍下注公开，第二部分"它没有说我们正在转向非osi许可或“源可用许可”，这类许可通常被称为“开放”和“免费”(如Beer)。这些词通常与开源软件联系在一起，所以在我看来，这是在故意迷惑读者。

公平地说，不只是弹性。长久以来，SQL一直被标榜为“开放标准”。AWS谈到"开源数据库当然，AWS提供的服务范围从专有代码数据库引擎技术(如DocumentDB和Aurora)到专有管理级别。

我非常担心那些拥有比大多数开源社区更大预算的公司的营销努力会侵蚀人们对开源真正意图的理解。

考虑到这些，现在让我们来思考为什么SSPL对你有害。

SSPL对最终用户不利

如果您只是使用软件，SSPL对您不利，因为它限制了您的选择。通常选择SSPL是为了让一家供应商垄断其SaaS/DBaaS部署模型，这意味着选择的减少和价格的提高。SaaS/DBaaS模式是许多软件中增长最快的使用模式。

不要相信供应商轻描淡写地说:“好吧，除非你打算以SaaS的形式销售它，否则它不会对你产生影响。”如果其他供应商不得不为他们的DBaaS支付更高的成本，这可能会直接甚至间接地影响到您，因为他们不可避免地将成本转嫁给作为客户的您。

SSPL通过阻止代码贡献者和增加供应商锁定来扼杀创新。虽然SSPL可能比传统的专有许可更适合您，但如果可以选择，您应该选择更自由的许可替代方案。

SSPL不利于代码贡献者

如果您正在贡献或计划贡献代码，那么SSPL对您是不利的，因为您只能根据SSPL的条款访问合并的工作。这对供应商有利，但对您自己如何使用该软件有严格的限制。

如果一个项目的许可证在事后变更为SSPL，您可能会发现自己是一个快速缩小的贡献者社区的成员，因为越来越少的人会发现它有吸引力。

SSPL不利于供应商

MongoDB和Elastic可能不会同意这一点，但事实上，他们改变了许可证，以使其在业务上处于更好的位置。但我认为这是短期思维。开源的车轮通常进展缓慢，但不可避免。我对5-10年后的MongoDB和Elastic非常感兴趣。它会是一项蓬勃发展的技术，供企业开发新的应用程序吗?还是会成为一个新的甲骨文，从不断萎缩的传统部署用户基础中汲取越来越多的收入?

MongoDB和Elastic可能把赌注押在云上，使开源变得无关紧要。然而，我相信我们将会看到开源软件的新浪潮，为我们提供当前私有公有云的可用性，但作为一个无锁定的开源解决方案，你可以在任何地方运行。与服务器硬件类似，虚拟化管理程序已经商品化，云也将如此。随着云的商品化，我们将寻找真正的开源数据存储，以拥有完整的堆栈，这将不可避免地导致它们的创建。

想要更多的智慧?看看这篇文章为什么真正的开源更好Matt Yonkovit。