編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

開源項目被 Fork，本是社區共建的一部分——但當一個個人項目被大廠“選中”，這究竟是榮譽加冕，還是原作者心血被悄然稀釋？

最近，開發者 Philip Laine 發長文分享了自己與微軟之間一段錯綜復雜的經歷。在開發了一個個人開源項目后，微軟主動“找上門”溝通，Philip 原以為微軟的主動接觸意味著一次潛在的合作，然而沒等來進一步的溝通，卻在一次偶然的參會中發現自己的項目早已被對方“借鑒”并改頭換面。

查閱對方項目代碼后，Philip 還驚訝地發現大量示例代碼與自己的相同、以及自己的個人注釋也出現在對方項目代碼中。而對方給出的致謝，僅僅是一句藏在 README 最后一行的“靈感來源”。

這一事件迅速引發了關于開源倫理與開發者權益的討論。事情的經過究竟如何？接下來我們來看看。

“我開發了一個無狀態的集群本地 OCI 注冊表鏡像系統”

事情的起點要追溯到三年前，Philip Laine 在一個負責為終端客戶開發和維護 Kubernetes 集群的團隊中工作。在實際工作中，他發現導致客戶系統頻繁宕機的主要原因之一是鏡像倉庫服務的中斷。

解決這個問題的傳統方法是搭建一個有狀態的鏡像站點（stateful mirror），但由于客戶的預算和時間限制，這種方式在實際操作中行不通。

后來，在某個星期五，GitHub 的容器鏡像倉庫宕機，導致 Philip 團隊的項目遭遇巨大的流量沖擊，這一事件嚴重影響了集群擴容能力，因為他們依賴的關鍵鏡像正好來自于那個出故障的倉庫。

這次經歷促使 Philip 開始思考如何避免此類可擴展性問題，且不依賴有狀態組件，同時還需要盡量減少運維負擔。正是在這樣的背景下，Spegel 項目（https://github.com/spegel-org/spegel）的想法誕生了。

簡單來看，Spegel 是一個開源的、無狀態的本地 OCI（Open Container Initiative）鏡像注冊表鏡像工具，專為 Kubernetes 集群設計。它通過在每個節點上運行 Spegel 實例，形成一個點對點（P2P）網絡，實現容器鏡像的本地緩存和共享，從而提高鏡像拉取速度，減少對外部鏡像倉庫的依賴，降低網絡帶寬消耗，并增強系統的可靠性。

當時，Philip 是這個開源項目的唯一維護者。某天，他突然收到微軟的消息，對方表示希望就 Spegel 項目進行會談，這讓他感到非常興奮。首次會議進行得十分順利，Philip 看到了合作的希望，甚至開始期待借此機會引入新的項目維護者。之后，他與微軟的一位工程師保持密切溝通，不僅協助對方順利部署了 Spegel，還積極解答了架構相關的技術問題。

基于此，Philip 對這次交流充滿期待，認為微軟未來可能會根據使用過程中的反饋，為項目帶來一些改進建議。但隨著時間推移，對方漸漸失去了回應，他也開始覺得，或許只是微軟的工作重心、內部優先級發生了變化。

轉折出現：微軟開發的項目直接引用原作者的一些信息

事情的轉折出現在巴黎舉辦的 KubeCon 大會上。Philip 在現場聽到一場主題為“提升鏡像分發速度策略”的演講，內容提到了 P2P（點對點）共享機制。演講摘要的方向與 Spegel 的設計理念高度契合，這讓他非常期待能聽到其他人對這一問題的思考與探索。

然而，在這位演講嘉賓分享過程中，Philip 意外地發現 Spegel——也就是他自己一手打造的項目——被當作 P2P 鏡像分發的案例在臺上公開介紹，這一度令他感到驚喜。

還沒高興多久，他還聽到演講中提到了微軟開發的一個名為 Peerd 的新項目——這是一個面向 Kubernetes 集群的容器內容 P2P 分發工具。出于好奇，Philip 立刻上網搜索相關信息，并在 Peerd 的 GitHub 倉庫 README（https://github.com/Azure/peerd）底部，發現了對他本人和 Spegel 項目的署名致謝。這條致謝看上去像是微軟從 Spegel 項目中獲得了靈感，并據此開發出了自己的版本。

來源：https://github.com/Azure/peerd

Philip Laine 在深入研究微軟的 Peerd 項目時，心情也從最初的好奇轉為不解以及憤怒。

因為他在 Peerd 代碼中發現了極為熟悉的函數簽名和注釋，幾乎就像是他自己寫的一樣。隨著進一步查看，他發現了一些測試用例，直接引用了 Spegel 項目和他前雇主的信息——這些測試用例原封不動地被復制過來，而且至今仍未被移除。

來源微軟的項目：https://github.com/Azure/peerd/blob/e0c0c5442f74937d56b70c3325d97bc9533f130e/pkg/oci/distribution/v2_test.go#L49-L57

來源微軟的項目：https://github.com/Azure/peerd/blob/e0c0c5442f74937d56b70c3325d97bc9533f130e/pkg/discovery/content/provider/provider_test.go#L21-L26

遵循 MIT 發布的開源項目

Philip 指出，Spegel 是在 MIT 許可證下發布的。根據該許可證，任何人都可以自由地 Fork（復制）和修改相關軟件，無需將修改內容回饋給原作者。他之所以默認使用 MIT 協議，是因為感覺它簡單、寬松。然而，這份許可證并不允許在移除原始許可證的前提下，假裝代碼是由他人原創的。

從目前情況來看，Spegel 項目的大量代碼似乎被直接復制了過去，卻沒有提及原始來源。為此，Philip 還附上了一段用于配置鏡像功能的對比代碼片段，其中甚至連函數注釋都完全相同。

來源：Peerd

來源：Spegel

此外，Philip 認為，Peerd 的出現也給他帶來了一些負面影響，因為很多新用戶根本分不清 Spegel 與 Peerd 之間的區別，由此經常跑來詢問 Philip 這兩個項目之間的關系。

Philip 稱，自己作為維護者，盡力保持客觀中立，以事實為依據地去解釋，但這種紛擾的歷史讓解釋工作變得十分艱難。微軟的品牌影響力極大，使得一個小型開源項目很難在這樣一個“巨頭”旁邊獲得足夠的關注和空間。

Philip 表示，作為一名開源維護者，他長期以來一直積極響應社區需求、修復漏洞并處理安全問題。他在與微軟溝通時也始終持開放態度，愿意合作，共同完善一個服務于整個開源社區的工具。多年來，他參與了多個開源項目的開發，并親力親為地開發了多個項目。Spegel 是他首個從零開始打造且獲得廣泛認可的作品。本以為 Spegel 被微軟 Fork 是一種認可，但隨著項目逐步被“取代”，他一度感到自己失去了價值，甚至懷疑是否還應該繼續維護 Spegel。

所幸的是，Philip 并未放棄。自兩年多前首次發布以來，Spegel 仍在持續發展，目前已獲得超過 1700 顆 GitHub 星標，鏡像被拉取次數超過 1440 萬次。

然而，Philip 也坦言，他并不是第一個、也不會是最后一個經歷這種“弱者對抗巨頭”的開源開發者。他發問：在如今開源生態受投資下滑、如 HashiCorp 許可證變更引發廣泛連鎖反應的背景下，獨立維護者如何在不被利用的前提下與大型企業共存？社區又該如何在這樣的環境下繼續前行？

為繼續資助 Spegel 的開發工作，Philip 啟用了 GitHub 贊助功能。同時，這段經歷也促使他認真考慮修改 Spegel 的開源許可證——因為這似乎是他唯一還能握在手中的“投石器”。

微軟回應：“沒有給予你應有的署名歸屬，這是我們的失誤”

隨著 Philip 將自己的經歷發出，在多個平臺尤其是 HN 上引發了大量網友的討論。

其中，有網友作為過來人，同樣分享自己與微軟之前溝通的經歷，要學會“首先談好條件再去解答問題”：

在很久以前（也就是微軟進入 Satya 納德拉時代之前），我曾是一個流行開源項目的維護者，這個項目主要解決了早期云計算從業者的一些專業痛點。它最初是為了解決我自己的問題開發的，我并不想把它商業化，所以愿意以開源形式發布。后來，微軟一位負責多個產品團隊的總監聯系我，表示希望“合作”。我說可以，把我的咨詢服務協議發給他們看。他們對費用有點抱怨，但我只是重申了那是我的標準價格。經歷了一輪法律上的來回之后，他們最終簽了協議，我在為期兩天的工作坊中解答了他們一堆問題，他們也如約付款了。如果他們真的很想要你的東西，他們就會愿意付錢。別免費打工。

也有開發者認為當前行業缺乏一種更可靠的開源許可方式：

我個人認為，我們需要一種全新的許可證模式：社區型開源許可。不為企業服務，只屬于社區。

這里的問題并不是微軟 Fork 了某個項目，而是在于，當像微軟這樣的大公司這么做時，往往會對我們的社區造成傷害。開源之所以能夠蓬勃發展，是因為無數個體和小團體在共同協作。

而微軟的運作邏輯，是圍繞“為股東創造利潤，不惜一切代價”。只要有利可圖，他們也會參與協作，但一旦無利可圖，便會回到那套熟悉的“擁抱、擴展、消滅”策略。這種缺乏社區精神的行為在企業中相當普遍，也正因此，它對我們的開源社區構成了生存威脅。將利潤凌駕于一切之上，不是合作，而是一種掠奪。

激烈爭論之下，還有一位自稱是來自 微軟 Cloud Native Ecosystem 團隊的人現身回應道：

你好 Philip，我是 Lachlan，來自微軟 Cloud Native Ecosystem 團隊。我們團隊長期在云原生開源社區中工作，目標是成為這些項目和社區中的優秀合作伙伴。對于你經歷的這件事，我深感抱歉。

我們非常認可你在 Spegel 項目上的領導力和付出，也看到這個項目確實為云原生社區解決了實際難題。感謝你發布的博客文章（https://philiplaine.com/posts/getting-forked-by-microsoft/），我想借此機會告訴你我們目前的做法，并回應幾個關鍵點。

我們剛剛提交了一個 Pull Request（https://github.com/Azure/peerd/pull/110），用于修正源碼文件中的許可證頭。我們在這方面確實做得不夠好：根據公司政策，應該在文件中保留版權聲明——目前我們已經為相關文件補充了許可證頭，并標注了你在項目中的貢獻。

我也想解釋一下我們為什么會選擇創建一個新項目：Peerd 之所以誕生，主要是為了加入 artifact streaming（制品流式傳輸）功能。當時你與我們工程師交流時提到，這個功能可能超出了 Spegel 的設計范圍，這個看法我們非常理解。我們確保在項目中致謝了 Spegel 并承認其對 Peerd 的啟發作用，就像你在博客中提到的那樣，但我們沒有給予你應有的署名歸屬，這是我們的失誤，對此我感到抱歉。你的聲音我們已經聽到，我們會改進流程，努力成為更負責任的開源參與者。

再次感謝你指出這個問題。我們會不斷改進在開源領域的合作方式，也始終歡迎你的反饋。

不過，顯然不少開發者對這樣的解釋并不買賬。有網友質問：“如果有家公司‘忘了’為 Windows/Office 或其他產品申請許可證，微軟會怎么處理？這不就是違反了許可證規定嗎？那微軟現在做的事，和盜版有什么區別？”

對此，你怎么看？

https://philiplaine.com/posts/getting-forked-by-microsoft/

https://news.ycombinator.com/item?id=43750535