对于一个应该使软件开发无摩擦的东西，开源许可证产生了大量的热量和噪音。
自从开源这个词出现以来，已经快25年了，对于什么是开源，什么不是开源，一直存在着激烈的争论。但在过去的几年里，由于在开源时代诞生的一代软件公司声称云计算巨头开始劫持 "他们的 "项目而大发雷霆，因此变得尤为激烈。
开源合规咨询公司Orcro的首席执行官、律师事务所Moorcrofts LLP的合伙人安德鲁-卡茨（Andrew Katz）用一些轻描淡写的语言描述了当前的情况。"目前，它有点支离破碎。我认为过去的共识在一定程度上开始恶化。我认为这是一个很大的遗憾。"
2018年，MongoDB公司为MongoDB NoSQL数据库推出了服务器端公共许可证(SSPL)，从而使球滚动起来，该数据库此前一直由AGPL覆盖。这是在MongoDB公司对AWS将数据库作为服务提供的担忧之后--也是在MongoDB的IPO之后一年。它认为，"一旦一个开源项目变得有趣，大型云计算供应商就很容易获取所有的价值，但对社区却没有任何贡献"。
MongoDB公司表示，SSPL将消除提供MongoDB作为服务的困惑，并且"还旨在确保那些运行公开的MongoDB作为服务的公司，或任何受SSPL约束的软件，都是在回馈社区。"
Redis有限公司在其开发的Redis模块的Redis源码可用许可证上也采取了类似的举措。Redis社区的其他开发者可以自由地将他们选择的许可证应用于他们创建的模块。
但真正拿起球并把它扔回AWS的脸上的是Elastic NV。在2021年1月的一篇博客中，创始人兼首席执行官Shay Banon指责AWS及其亚马逊Elasticsearch服务，"自2015年以来，我们认为做的事情就是不对的，而且情况只会越来越糟。"
Banon声称AWS使用了 "我们认为是由第三方从我们的商业代码中复制出来的代码，并将其作为Open Distro项目的一部分提供"。他还声称，该公司还发现了AWS "有道德问题的行为 "的其他例子，即专有功能作为该网络巨头自己产品的 "灵感"。
结果是Elastic的产品采用了双重许可的方法，使用MongoDB开创的SPPL和它自己的Elastic License v2的组合。 其目的是防止公司 "使用我们的Elasticsearch和Kibana产品，在不与我们合作的情况下直接提供服务。"
寒心的许可证？
不用说，Banon坚持认为，对于客户来说，"这一变化很可能对你，我们的用户没有影响。它对我们的客户没有任何影响，这些客户与我们在云端或现场进行合作。它的目标，希望是相当明确的"。
同样清楚的是，这些新的许可类型并不是开源的。在开发其许可证时，MongoDB公司与开放源码组织（Open-Source Initiative）进行了接触，该组织是开放源码定义的监护人，以确定SSPL是否可以归类为开放源码许可证。但是，正如OSI执行董事Stefano Maffulli告诉我们的那样，"我们花了很低的扫描来审查它，说它不是。"
更重要的是，Maffulli说这些新的许可证 "消除了无摩擦的创新"，而这正是开源成功的核心所在。
"他说："它们要求你的法律团队在说'是的，你可以使用它们，或者不，你不能使用它们'之前，仔细审查它们。"他们强迫你通过一个守门人。而这确实违背了开放源码的精神和文字"。
卡茨说，除了不得不担心精神问题外，这也给开发者和他们的雇主带来了真正的日常问题。"他说："从根本上说，人们关心的是旅行的方向。他说："如果他们已经承诺使用受这些许可证约束的特定基础设施软件，那么在12、18、24、48个月的过程中，这将意味着什么？这是否意味着他们在这些不同的假设上所做的投资会给他们带来问题？"
依靠开源软件几乎是技术型创业公司的必然选择。但正如活动管理平台Venueserve的首席运营官乔纳森-西蒙兹（Jonathan Symonds）所说，许可的不确定性使围绕将开源代码整合到创业公司自己的产品中的问题变得更加复杂。
当涉及到 "实现业务 "时，他说："我必须确保知识产权和产品都是由企业实际拥有的，而不是由其他人拥有，如果我打算退出或者我也要去筹集资金的话。"
卡茨说，除了纯粹的商业问题，还有组织的 "认知 "问题。"如果他们把自己描述成一家开源公司，而他们开始使用框架、数据库等非严格意义上的开源部分，那么对于他们自己的开发者来说，这可能是一个内部认知问题，他们可能对此感到不舒服。"而这些观念上的问题可能会延伸到客户和其他用户。
还有人担心某个云供应商的立场在未来会发生巨大的变化，卡茨说。"有什么动力可以防止这种变化在未来对他们不利？当你有一些竞争者，并且他们的利益相互平衡时，市场就会运作得最好。"
虽然主要的云计算供应商确实竞争激烈，但这并不是一个开放的市场。在少数几个主要的云计算供应商（他们本身就是主要的软件工厂）和绝大多数开源软件供应商之间存在着明显的权力不平衡，更不用说最终用户了。
上游有问题
从卡茨的角度来看，对于如何解决这种情况，有两个主要的思想流派。"要么我们需要确保人们不能在云中隐藏他们对软件的改进，我们要通过许可证的方式来解决这个问题。而且，你知道，AGPL是一个尝试，但它是一个相当广泛误解的许可证。然后你开始看像SSPL和Commons Clause之类的许可证。"
他继续说，另一个选择是重新审视软件开发方式背后的动力。"因此，我们怎样才能使你从上游得到的好处继续适用？
这在一个多元的中型云供应商相互竞争的世界里更容易做到，他们想使用项目，但发现如果没有更广泛的社区的支持，维护一个项目对他们中的任何一个来说都太难了。
"我担心的是，我们的市场上有极少数非常大的云供应商，"卡茨说，"他们可以有效地分叉软件，并能继续承担内部维护的费用，而上游的经济性和好处不再一定适用于他们。"
他补充说，这只是一种预感。
但是，是否有人能介入并使交战各方走到一起？也许吧。但这不会是OSI，Maffulli说。
并不是说OSI不理解Elastic公司所处的位置。"我有同情心。绝对的。我有，"马富礼说。"企业和社区之间的这种紧张关系，以及企业本身的紧张关系，一直都存在着。这不是一个新事物。"
他说，像Elastic和MongoDB这样的公司显然已经从开源中受益。现在他们发现自己处于这样一种境地："他们有一个商业模式，而且是与一些巨头公司直接竞争。在这个层面上，以这些理由进行竞争是很难的。所以，他们不得不改变许可方式，这很公平"。
但是，他继续说："这不是一个开源的问题。这是一个商业问题"。
那么，谁应该对商业问题进行裁决呢？Maffulli说，最终是市场。
分叉了
卡茨说，当涉及到新的许可证时，这是一个真正设定期望的问题，从一开始就这样。如果一个新的许可证不是严格意义上的开放源代码，他说："确保你不以任何方式、形式或形式暗示它是开放源代码。尽量不要使用混乱的术语来混淆问题。而且真的要完全诚实，直截了当地说明你为什么要这样做。"
最根本的问题是什么能保持 "社区 "的活力。"我们只是不知道答案。我认为这将在很大程度上因项目而异。这将需要大量的管理（相当棘手的管理），我们不会知道，直到这些想法在市场上决出胜负。"
那么，市场在说什么呢？
好吧，没有一个相关的组织愿意为这篇报道直接与我们交谈。Redis是一家私人公司，所以很难衡量它的许可计划有什么影响。自2019年以来，MongoDB在其公开交流中几乎没有提到SSPL。在夏天，Elastic说它 "很高兴看到社区对这种变化的支持程度"。
所以，让我们相信，这一切都在为他们而努力。毕竟，信任是这里整个辩论的核心。
而信任--或者至少是相互迁就--可以在最奇怪的地方爆发出来。AWS，似乎一直在努力巩固其开源的资格。
7月，AWS的开源博客点名批评Redis说，虽然两个组织 "继续为Redis的工作负载竞争，但我们也紧密合作，为我们共同的客户提供服务。"这篇文章为读者指出了Redis在AWS上的Redis企业云的页面。
10月，AWS的开源博客刊登了MongoDB的一篇文章，讨论了 "MongoDB和亚马逊的搜索团队在Lucene上的合作方式，为我们自己的需求量身定做，同时为大家改进项目。"
"这只是我们合作关系的开始，"博客作者承诺。
至于Elastic，早在一月份AWS就写道："Elastic知道他们所做的事情是有猫腻的......他们认为，限制他们的许可证将锁定其他人提供管理Elasticsearch服务，这将让Elastic建立一个更大的业务。Elastic有权利改变他们的许可，但他们也应该站出来，拥有自己的决定"。
6月，在AWS完成分叉并将其Elasticsearch服务重新命名为OpenSearch之后，Elastic写道："我们很高兴能够摆脱混乱，知道我们的用户不会再因为产品不一样而被误导或有不好的体验。"
并不是完全埋葬了仇恨，但它继续与这个网络服务巨头的其他部分合作，最近在11月成为AWS ISV工作负载迁移计划合作伙伴的认证。
Elastic的网站上仍然有那篇博客，Banon在其中描述AWS是 "道德上的挑战"。这大概就是Elastic选择中国网络巨头阿里巴巴云作为其年度生态系统合作伙伴的原因吧。