核子可樂、Tina InfoQ
編譯 | 核子可樂、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
