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

今年 5 月，微軟在 Build 2020 大會上發(fā)布了新的軟件包管理工具WinGet，并將其開源。而就在 WinGet 發(fā)布之后不久，開源軟件包管理工具 AppGet 項目作者 Keivan Beigi 發(fā)文宣布 AppGet 項目 “死亡”，矛頭直指微軟的 WinGet 抄襲了 AppGet 。

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

然而此后的 6 個月里，微軟沒有再與 Keivan 聯(lián)系。直到今年 5 月，Keivan 突然收到了一封來自微軟的郵件：“我想花點時間告訴你，我們非常感謝你的投入和見解。我們一直在構(gòu)建 windows 包管理器，第一個預(yù)覽版將于明天在 Build 上線，我們的包管理器也將是開源的，我們歡迎您的任何貢獻。”隨后，微軟就在 Build 上發(fā)布了 WinGet 。

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

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

而對于微軟面試官 Andrew 的做法，Keivan 在推特中表示：“我并不想站在 WinGet 的對立面，我也不希望任何人因這件事被解雇，我只是想分享我在這個故事中遭遇的一些不公平對待。”同時他也不想因為一些私人恩怨而毀掉一款好的產(chǎn)品，希望微軟方面能給出適當?shù)拇饛汀?/p>

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

Andrew 還明確列出了數(shù)個 AppGet “幫助 WinGet 變得更好”的貢獻：

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

• GitHub 中豐富的清單定義—— 與應(yīng)用程序的豐富聲明性元數(shù)據(jù)相結(jié)合的開放能力對于實現(xiàn)目標非常重要

• 支持所有類型的 Windows 應(yīng)用程序安裝程序（包括 Win32/Win64）

• 存儲庫中應(yīng)用程序的無縫更新

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

盡管微軟承認了 AppGet 的貢獻并表達了謝意，但仍然沒有表達對整件事情的歉意，有網(wǎng)友對此表達了不滿。

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

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

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

Rush 或許是微軟在 Lerna 的基礎(chǔ)上開發(fā)的一個分支？抱著這樣的想法，jamiebuilds 進一步查看了 Rush 的 Git 日志，結(jié)果發(fā)現(xiàn)該項目是在 Lerna 創(chuàng)建幾天之后創(chuàng)建的，同時在文檔中介紹了包括 Lerna 在內(nèi)的其他類似工具，并稱之為 “不夠好的產(chǎn)品”，儼然一副 “Rush 是比這些產(chǎn)品都要好的原創(chuàng)工具”的樣子。為了解二者的區(qū)別，jamiebuilds 對兩個項目進行了對比，結(jié)果發(fā)現(xiàn)Rush 的文件和目錄命名、核心功能的代碼都與 Lerna 完全相同，甚至連提交記錄都是一致的，也就是說 Rush 在不斷復制Lerna 的更改，然后聲稱其是微軟開發(fā)的原創(chuàng)作品。

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

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

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

盡管這些抄襲事件或許只是由微軟個別員工的不當做法引起，但微軟的一系列抄襲行為還是引發(fā)了開源界的擔憂。事實上，在開源社區(qū)中 fork 或 copy 某人的代碼并不是什么壞事。但微軟這種將別人的勞動成果歸功于己的行為，顯然違反了開源社區(qū)應(yīng)有的道德規(guī)范，當然也違反了開源協(xié)議。

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

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

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

理論上來說，使用 MIT、Apache 2.0 等寬松開源許可證的項目，源代碼可以被任何人拿去修改、分發(fā)、甚至閉源商業(yè)化，但必須保留項目原作者的著作權(quán)，也就是在源代碼引用的部分保留項目作者的版權(quán)聲明。以 MIT 許可協(xié)議為例，該協(xié)議規(guī)定，被授權(quán)人要履行 “在軟件和軟件的所有副本中都必須包含版權(quán)聲明和許可聲明” 的義務(wù)。也就是說，微軟采用開源項目源代碼開發(fā)新項目本身并沒有任何問題，但其拒絕履行開源協(xié)議規(guī)定的 “保護軟件原作者著作權(quán)”的義務(wù)，事實上是違反了開源協(xié)議的。

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

最后，以《是誰在阻礙我們創(chuàng)新》中的一句話作為結(jié)尾：

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

相關(guān)閱讀：

《微軟回應(yīng) “剽竊 AppGet”：肯定原作者貢獻》

總結(jié)

以上是生活随笔為你收集整理的微软抄袭 AppGet 始末，开源普法任重道远的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。