酷应用

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

百家作者：InfoQ 2020-10-20 16:35:14

编译 | 核子可乐、Tina

开源的威胁一直都在。

上周四，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

今日荐文

点击下方图片即可阅读

守旧的互联网企业 VS 创新的传统企业：微软站哪端？

InfoQ 读者交流群上线啦！各位小伙伴可以扫描下方二维码，添加 InfoQ 小助手，回复关键字“进群”申请入群。回复“资料”，获取资料包传送门，注册 InfoQ 网站后，可以任意领取一门极客时间课程，免费滴！大家可以和 InfoQ 读者一起畅所欲言，和编辑们零距离接触，超值的技术礼包等你领取，还有超值活动等你参加，快来加入我们吧！