微軟抄襲 AppGet 始末

近日，開源項目 AppGet 作者 Keivan Beigi 與微軟 WinGet 項目的「抄襲糾紛」事件迎來了最新進展。微軟方面做出回應，坦承「辜負了 Keivan 和 AppGet」，並肯定了 Keivan 與 AppGet 對微軟新項目的貢獻。

https://my.oschina.net/editorial-story/blog/4300683

作者：開源中國

近日，開源項目 AppGet 作者 Keivan Beigi 與微軟 WinGet 項目的「抄襲糾紛」事件迎來了最新進展。微軟方面做出回應，坦承「辜負了 Keivan 和 AppGet」，並肯定了 Keivan 與 AppGet 對微軟新項目的貢獻。

今年 5 月，微軟在 Build 2020 大會上發布了新的軟體包管理工具WinGet，並將其開源。而就在 WinGet 發布之後不久，開源軟體包管理工具 AppGet 項目作者 Keivan Beigi 發文宣布 AppGet 項目「死亡」，矛頭直指微軟的 WinGet 抄襲了 AppGet 。

AppGet 是一款開源的 Windows 軟體包管理工具，它可以在 Windows PC 上自動安裝軟體。作者 Keivan Beigi 是一名居住在加拿大溫哥華的軟體工程師。去年 7 月，微軟 App 事業部產品經理 Andrew Clinick 開始主動接觸 Keivan，表達了微軟對於 AppGet 的興趣，並表示可以給 Keivan 提供在微軟的職位，共同開發 Windows 系統的軟體包管理項目。期間，Andrew 多次與 Keivan 以交換意見為由進行面試溝通，獲取了 AppGet 的開發思路。去年 12 月，Keivan 在微軟位於西雅圖的總部接受了一整天的採訪，事情本來正向著好的方向發展。

然而此後的 6 個月里，微軟沒有再與 Keivan 聯繫。直到今年 5 月，Keivan 突然收到了一封來自微軟的郵件：「我想花點時間告訴你，我們非常感謝你的投入和見解。我們一直在構建 windows 包管理器，第一個預覽版將於明天在 Build 上線，我們的包管理器也將是開源的，我們歡迎您的任何貢獻。」隨後，微軟就在 Build 上發布了 WinGet 。

Keivan 表示，當他看到公告和 WinGet 的代碼時感到很震驚。Keivan 認為 WinGet 的核心機制、術語、manifest 格式和結構，甚至是包存儲庫的文件夾結構都有 AppGet 的影子。而微軟在公告中對於 AppGet 的描述僅有一句 「 ……還有許多其他類似 AppGet、Npackd 和基於 PowerShell 的 OneGet 包管理器。」

Keivan 對微軟的做法感到非常失望，他認為微軟抄襲他的開源軟體沒有問題，但希望自己的工作獲得適當的榮譽。為此他發表了「AppGet 之死」一文，宣布放棄 AppGet 項目的更新，因為與微軟這種量級的開發者競爭沒有任何意義。

而對於微軟面試官 Andrew 的做法，Keivan 在推特中表示：「我並不想站在 WinGet 的對立面，我也不希望任何人因這件事被解僱，我只是想分享我在這個故事中遭遇的一些不公平對待。」同時他也不想因為一些私人恩怨而毀掉一款好的產品，希望微軟方面能給出適當的答覆。

5 月 30 日，微軟產品經理 Andrew 在微軟官方發文回應稱，「去年夏天，我們與 Keivan 進行了交談，探討了共同提供 Windows Package Manager 的潛在機會。AppGet 具有許多品質，確實可以幫助我們為 WinGet 找到更好的產品方向。」 承認了 Keivan 與 AppGet 對微軟 WinGet 項目的貢獻。「Windows Package Manger 的宗旨，是提供產品讓社區和用戶都能做出貢獻並獲得認可，這就是為什麼我們要把它建立在 GitHub 上的原因；在過去的幾天里，我們聽取了社區的意見，並從中吸取了教訓，顯然我們有負於這個目標。更確切地說，我們辜負了 Keivan 和 AppGet 。這也是我們最不願意看到的。」

Andrew 還明確列出了數個 AppGet 「幫助 WinGet 變得更好」的貢獻：

??在安裝過程中沒有腳本 —— 這是我們完全同意的，但不允許使用 MSIX

??GitHub 中豐富的清單定義—— 與應用程序的豐富聲明性元數據相結合的開放能力對於實現目標非常重要

??支持所有類型的 Windows 應用程序安裝程序（包括 Win32/Win64）

??存儲庫中應用程序的無縫更新

Andrew 表示希望藉此機會表達對 Keivan 提供的 AppGet 的開發思路，以及 Keivan 與微軟合作的感謝。並希望未來能和 Keivan 以及其他開發者合作，把 WinGet 做得更好。

儘管微軟承認了 AppGet 的貢獻並表達了謝意，但仍然沒有表達對整件事情的歉意，有網友對此表達了不滿。

甚至有網友表示「這下所有事情都明朗了，微軟之所以開始向開源靠攏，是為了更方便竊取別人的勞動成果？」

其實網友的嘲諷並非心血來潮，早在 2018 年 6 月，微軟就曝出過類似的抄襲事件。當時，開源的多包存儲庫管理工具 Lerna 作者 jamiebuilds 指責微軟抄襲其代碼。

jamiebuilds 表示，當自己在為 Babel 6 工作的過程中發現所有東西都拆分成漂亮的小插件包，但同時也就需要管理數十個軟體包。因此，多包存儲庫管理工具 Lerna.js 應運而生。為讓項目更好用，他對項目進行了 5 次重寫，試圖讓架構更完善。之後某天，jamiebuilds 發現了微軟推出了由許多小包組成的新的設計體系，本以為是微軟在項目中使用了 Lerna ，結果發現他們使用的是一個名為 「Rush」 的東西。

Rush 或許是微軟在 Lerna 的基礎上開發的一個分支？抱著這樣的想法，jamiebuilds 進一步查看了 Rush 的 Git 日誌，結果發現該項目是在 Lerna 創建幾天之後創建的，同時在文檔中介紹了包括 Lerna 在內的其他類似工具，並稱之為「不夠好的產品」，儼然一副 「Rush 是比這些產品都要好的原創工具」的樣子。為了解二者的區別，jamiebuilds 對兩個項目進行了對比，結果發現 Rush 的文件和目錄命名、核心功能的代碼都與 Lerna 完全相同，甚至連提交記錄都是一致的，也就是說 Rush 在不斷複製 Lerna 的更改，然後聲稱其是微軟開發的原創作品。

jamiebuilds 稱自己主動與認識的微軟員工聯繫說明此事後，對方感到震驚並道歉，但之後並沒有任何來自官方的合理解釋。Rush 項目也沒有去更改許可證，或者添加補充說明，而是將提交記錄進行了混淆，將代碼位置進行移動，並重新編寫或重命名了一些函數。

jamiebuilds 提到，如果是其他人做了這件事，他或許會有點不高興但仍然把他忽略掉。但微軟這樣一個萬億市值的軟體業巨頭做這樣的事情，這令他非常生氣。

這件事最後不了了之。值得一提的是，這一次 Lerna 的開發者並沒有選擇向微軟屈服。如今 Lerna 在 GitHub 上擁有 23k 的 Star ，成為名副其實的明星項目，以至於微軟後來在自己的項目Just中也把多包存儲管理工具改為使用 Lerna 。

儘管這些抄襲事件或許只是由微軟個別員工的不當做法引起，但微軟的一系列抄襲行為還是引發了開源界的擔憂。事實上，在開源社區中 fork 或 copy 某人的代碼並不是什麼壞事。但微軟這種將別人的勞動成果歸功於己的行為，顯然違反了開源社區應有的道德規範，當然也違反了開源協議。

目前，很多軟體工程師普遍對於開源協議仍然不夠了解。有人甚至認為：開源軟體就是免費的軟體，所以我可以不受限制地隨意使用。這顯然是一種誤解。

據業內律師介紹，開源軟體與專有軟體等閉源軟體一樣，都是受法律保護的。開源軟體的著作權既沒有放棄也沒有過期，作者仍然是享有著作權的。除了著作權外，開源軟體還可能被合同法、專利法、商標法等法律所規制。在著作權法的語境下，軟體代碼是類似於文字作品一樣被保護的。在獲得了一段源代碼之後，默認情況下不能對該源代碼進行改編或者再發行。而開源軟體的特點在於，對於部分寬鬆開源協議（如 MIT、Apache 2.0）來說，在使用者承諾滿足一定條件（通常包括給作者署名、附帶許可證）的情況下，作者會放棄、讓渡部分權利，例如允許使用者將代碼改編或者再發行。

律師介紹，使用者所承諾的條件以及作者所放棄的部分權利形成了一種合同關係，更具體來講是許可合同，在開源軟體的情況下該合同也就是我們常說的開源許可證（License）。許可證是一種無需磋商的、標準化的公共合同，降低了合同的成本。

理論上來說，使用 MIT、Apache 2.0 等寬鬆開源許可證的項目，源代碼可以被任何人拿去修改、分發、甚至閉源商業化，但必須保留項目原作者的著作權，也就是在源代碼引用的部分保留項目作者的版權聲明。以 MIT 許可協議為例，該協議規定，被授權人要履行 「在軟體和軟體的所有副本中都必須包含版權聲明和許可聲明」 的義務。也就是說，微軟採用開源項目源代碼開發新項目本身並沒有任何問題，但其拒絕履行開源協議規定的「保護軟體原作者著作權」的義務，事實上是違反了開源協議的。

儘管開源項目源代碼受到開源協議的保護，但個人開發者維護的開源項目在面對微軟這種級別的大型企業時，往往難以維護自己的合法權利。比較大型的開源項目通常會由專門成立的基金會來處理相關的法務問題，這些大型開源項目的版權屬於中立的開源基金會，基金會享有處理項目授權、更改開源協議的權利，能夠隨時應對項目授權問題帶來的法律糾紛。但個人開發的項目版權屬於開發者自己，面對類似的侵權行為時，顯然缺乏足夠的人力和財力去處理這些法律糾紛，在大多數情況下只能悶聲吃虧。因此，在個人開發者決定是否將自己的項目開源時，一定要衡量開源的利弊，充分理解各類開源許可證的各項條款，預測項目開源後可能帶來的後果，三思而後行。同樣的，當我們在使用開源項目的代碼時，也要尊重原作者的勞動成果，自覺履行開源協議所要求的義務。

最後，以《是誰在阻礙我們創新》中的一句話作為結尾：

「我們總是習慣去索取，而忘記了回饋。」

參考鏈接：

1.Microsoft Continues to Attack and Steal From the Open Source/Free Software Communities

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！