开源的威胁一直都在。

上周四，Amazon Web Services推出了CloudWatch Synthetics Recorder。这是一款面向Chrome浏览器的扩展程序，可以说是直接照搬自开发者Time Nolet为该浏览器打造的Headless Recorder项目。

这种作法本身没有任何问题——毕竟Nolet的软件遵守Apache License v2，开发者们也希望看到自己的成果能够得到广泛应用。但Amazon的行为确实值得商榷，因为他们甚至没有公开提到这部分代码的真正创造者。在CloudWatch扩展中的一个NOTICE.txt文件倒是稍微说明了一下，但提及的并非Headless Recorder，而是其之前的曾用名“puppeteer-recorder”，而且完全是为了满足开源许可的要求。

作为极有荣誉感的群体，开源开发者们希望像AWS这样的巨头企业能够表达一点尊重之意。Nolet在一条采访消息中回应称，“（至少对我来说）问题的关键并不在于许可要求什么，而是大家重不重视开源精神。”

“事实上，AWS内部就没人意识到这是种特别让人恼火的行为吗？他们难道不会设身处地理解别人的感受吗？这种作法已经严重损害了AWS的公共形象。他们知道这事不对——这里我们说的不是合法性问题，而是对错的问题。必须有人站出来说几句。”

Nolet负责运行一项名为Checkly的软件监控服务，并开发了Headless Recorder浏览器扩展作为其所在公司及客户的工具。他表示，他从来没打算把Headless Recorder的许可弄得太复杂，因为这只是一款包含大量客户端代码的浏览器扩展，他希望任何熟悉浏览器开发工具的朋友都能理解并使用。

“Amazon应该是打开了一项PR（pull请求），想到‘不妨把这项功能加到原作者的代码里’。否则他们编写一个开源fork就好，何必来折腾我的项目。”

“但至少，他们应该提一句新功能是以我之前的工作为基础。我在Headless Recorder项目的README.md中就提到，这款扩展的开发灵感源自segment.io网站上的某个旧项目。”

最后，这个事情引起了AWS负责开源策略和营销的Matt Asay的关注，他对CloudWatch扩展的处理情况表示担忧，也表达了后悔之情。

他同时在Hacker News指出，“AWS使用到大量开源资源，我们也一直在代码层面（包括Firecracker及Bottlerocket等第一方项目，以及Redis、GraphQL、Open Telemetry等第三方项目）、测试、成果归属、基金会支持等方面做出贡献。”

“但开源的核心终究关乎人与社区，我个人认为我们应该做得更多，承认Tim与其他维护者们的出色工作，努力支持他们在Headless Recorder项目中的成就。目前，我们正在与Tim就此展开沟通。”

Nolet证实AWS确实与他取得了联系，他也相信AWS真实地希望改正不当行为。他表示“他们起初确实做得不好，现在希望能把问题解决好。但究竟怎么解决，我还不太清楚。”

但是得知此事的开发者们并不买账。

一位开发者给Matt Asay留言说：“我确实认为，作为一家数万亿美元的公司，在没有与原始创建者交谈的情况下分叉一个开源项目，并将其宣布为其平台的一项新功能，这样的行为有很多值得诟病的地方。如果说有什么需要改进的，那么首先就是‘不应该伸手’。你所做的一切在法律上或道德上都没有错，但是你可以做得更好，作为一家价值数万亿美元的公司你可以表现出更大的感激。“

一位名叫做William Pietri 的开发者和企业家说：“这是我与@awscloud之间的一大主要矛盾。在我看来，他们与开源社区的关系更多是种粗暴索取，而非健康协作。考虑到Amazon对员工的残酷压缩，这倒也不足为奇。但这种种行为实在令我无法信任他们。“

开源的威胁从未消失

AWS已经不是第一次直接夺取开源开发者的成果并直接塞进自家云产品了。

去年，AWS推出了Open Distro for Elasticsearch，此举直接威胁到了Elasticsearch作为开源项目开展自有业务的生存空间。AWS对此版本的评论语气还非常居高临下：“开源项目的维护者有责任保持源代码分发对所有人开放，而不是在中途改变规则”。

去年年初，AWS还基于开源MongoDB代码的旧版本发布了DocumentDB。

虽然目前不少流行的开源许可都支持这种作法，但由于AWS手中掌握着价值极高的基础设施资产，因此这类行径很可能扼杀小型企业将开源项目推向商业化的希望。

各家云厂商借助开源吸收各行各业的需求，使得产品更加的具备通用化的能力，覆盖更大的规模和更广的场景。成功的开源软件因为在相应领域覆盖了大量的开发者用户，当在云上推出相应的商业服务时也会自然的收获用户，但由于目前这些利益基本都被云厂商拿走，这让相对应的开源厂商的努力得不到回报，导致产生矛盾。

并且双方的冲突在2019年里达到了白热化的程度。去年底，在回应《纽约时报》关于AWS如何复制并整合其他厂商原创软件的相关报道时，AWS副总裁Andi Gutmans表达了批评意见。他抱怨说记者忽略了AWS合作伙伴的奉承言论，同时指出，AWS的内部开发人员也一直在为众多开源项目做出贡献，并坚称“AWS并未直接复制任何人的软件或服务。”

这种矛盾不容易被解决，也许我们将会继续看到云厂商试图以各种不同的方式从开源软件中榨取价值。开源模型虽然没有那么脆弱，但是云厂商继续利用开源项目而不给予回报，那么他们就会削弱开源发展的激励机制。至少，这是大多数开发人员在对开源模型感到沮丧时表达的痛点：一方面他们需要保持开放，一方面要付钱给他们的开发人员，其中一些正在流失资源。我们希望未来能在云供应商和企业开发人员之间看到更多商业交易，起码可以分摊开发成本，这也是一种合理的要求。

而且在可预见的未来，可直接用于云部署的企业软件供应商会对在开源许可下发布代码持谨慎态度。过去几年中，云厂商的行为（不加回馈，甚至一句感谢都没有）引发了开源社区的广泛关注，同时也催生出“云保护许可”等尝试。该许可旨在阻止云服务供应商吸纳公共软件项目。

就在上个月，数据库开发者TimSale通过了一项名为Timescale License（TSL）的新型源代码可用性许可，旨在对抗AWS及其他云巨头肆意妄为的气焰。

现在，我们正处于这样的一个分水岭，不断的产生 Commons Clause 和Timescale License（TSL）这样的替代许可模式，也许未来我们会看到更多的变体。

参考链接：

https://www.theregister.com/2020/10/16/aws_headless_recorder/

https://www.infoq.cn/article/2Q9MkC56NQ6IEp*Im2Vd

创作场景

AWS 分叉了我的开源项目，但他们连声感谢也没说