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

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

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

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

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

Keivan 對(duì)微軟的做法感到非常失望，他認(rèn)為微軟抄襲他的開(kāi)源軟件沒(méi)有問(wèn)題，但希望自己的工作獲得適當(dāng)?shù)臉s譽(yù)。為此他發(fā)表了 “AppGet 之死”一文，宣布放棄 AppGet 項(xiàng)目的更新，因?yàn)榕c微軟這種量級(jí)的開(kāi)發(fā)者競(jìng)爭(zhēng)沒(méi)有任何意義。

微軟抄襲 AppGet 始末，開(kāi)源普法任重道遠(yuǎn)

而對(duì)于微軟面試官 Andrew 的做法，Keivan 在推特中表示：“我并不想站在 WinGet 的對(duì)立面，我也不希望任何人因這件事被解雇，我只是想分享我在這個(gè)故事中遭遇的一些不公平對(duì)待。”同時(shí)他也不想因?yàn)橐恍┧饺硕髟苟鴼У粢豢詈玫漠a(chǎn)品，希望微軟方面能給出適當(dāng)?shù)拇饛?fù)。

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

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

在安裝過(guò)程中沒(méi)有腳本 —— 這是我們完全同意的，但不允許使用 MSIX

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

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

存儲(chǔ)庫(kù)中應(yīng)用程序的無(wú)縫更新

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

盡管微軟承認(rèn)了 AppGet 的貢獻(xiàn)并表達(dá)了謝意，但仍然沒(méi)有表達(dá)對(duì)整件事情的歉意，有網(wǎng)友對(duì)此表達(dá)了不滿。

微軟抄襲 AppGet 始末，開(kāi)源普法任重道遠(yuǎn)

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

其實(shí)網(wǎng)友的嘲諷并非心血來(lái)潮，早在 2018 年 6 月，微軟就曝出過(guò)類似的抄襲事件。當(dāng)時(shí)，開(kāi)源的多包存儲(chǔ)庫(kù)管理工具 Lerna 作者 jamiebuilds 指責(zé)微軟抄襲其代碼。

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

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

微軟抄襲 AppGet 始末，開(kāi)源普法任重道遠(yuǎn)

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

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

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

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

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

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

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

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

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

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

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

相關(guān)閱讀：

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