<img id="edit_4876368" src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/0e466e8e0ebb161994576596979f9045_1626403521.jpeg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1020" height="639" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/0e466e8e0ebb161994576596979f9045_1626403521.jpeg"/>圖片來源 @視覺中國<blockquote>文 | 光錐智能，作者｜陳思</blockquote>6 月下旬，微軟旗下代碼託管平台 GitHub 推出了能夠對整行或全部代碼給出 AI 分析建議的 Copilot 編程輔助工具。這款工具不僅能夠支持多種編程語言，還可以給出開發者修改建議，甚至根據簡單的文字描述生成代碼段。然而，這款怎麼看都覺得是提升開發人員工作效率的工具，一經推出後，迎來的幾乎沒有歡呼，更多的是來自開源作者們的批判。<h2>代碼未經許可被拿走，開源作者們怒了</h2>“他們不打一聲招呼，就直接拿走我們的代碼去訓練他們的 AI 模型，這簡直太過分了！”在 Twitter、Hackernews 等社交平台以及論壇上，越來越多的開發者發出了對 GitHub 以及微軟公司的聲討，更有甚者宣佈自己今後將不再使用 GitHub：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/6d9215814e0e773ec7d818037658f06f_1626403522.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1080" height="819" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/6d9215814e0e773ec7d818037658f06f_1626403522.png"/></div>(大意：我不同意 GitHub 未經授權和未經許可就使用受版權保護的源代碼作為其基於機器學習的 GitHub Copilot 產品的訓練數據。該產品將受版權保護的代碼注入其客户的軟件中，而無需獲取原始代碼創作者的許可。我認為這是對版權所有者權利的嚴重攻擊，因此我不會繼續使用 GitHub 的服務。)要了解開發者們的憤怒源頭，首先要知道一下 GitHub Copilot 是什麼。GitHub Copilot 是基於非盈利技術組織 OpenAI 的一個代碼補全項目 CodeX 創建的。根據官網介紹，Copilot 可以實現以下功能：根據函數名稱補全代碼：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/1786cef2f7b99c2700602ae78c8afefd_1626403522.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1080" height="542" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/1786cef2f7b99c2700602ae78c8afefd_1626403522.png"/></div>根據註釋所寫邏輯，直接實現代碼：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/5811817fcff799dc6dbd409af2eb4ccb_1626403523.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1003" height="863" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/5811817fcff799dc6dbd409af2eb4ccb_1626403523.png"/></div>自動補全重複代碼：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/e97380246b1f21fc452c83957359d6ac_1626403523.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="858" height="643" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/e97380246b1f21fc452c83957359d6ac_1626403523.png"/></div>在測試的時候，直接生成與代碼相匹配的測試模塊：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/95130b543466691a46a6acdeaafc6832_1626403523.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="829" height="498" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/95130b543466691a46a6acdeaafc6832_1626403523.png"/></div>從功能上來看，這都是一個對開發者非常友好的工具，對提升工作效率非常有幫助，這一點在國內外的開發者論壇中也得到了不少的好評。可為什麼它讓這麼多開發者憤怒呢？既然是 AI 工具，總得有一個訓練數據的來源吧？沒錯，正如文章開頭説的那樣：GitHub Copilot 的訓練數據全都是站內開發者貢獻的開源代碼，且並未告知開發者，這也是開發者們憤怒的直接來源。據瞭解，微軟未來還計劃將 GitHub Copilot 做成收費的企業版本，這一點則更讓開發者們不爽：“免費拿了我們的代碼去訓練不説，還想用它來盈利，而且對於我們這些貢獻者，微軟一丁點補償都沒有！”<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/ebb1d20c445d1cf89e1d97c66e0a6139_1626403524.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="552" height="347" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/ebb1d20c445d1cf89e1d97c66e0a6139_1626403524.png"/></div>（大意：我知道有人對這個工具很興奮，但是 GitHub 偷拿了你的代碼，用它訓練了這個 AI，甚至還考慮在未來向你收費。）不少開發者認為，這樣的行為是非常嚴重的侵權。隨着話題不斷髮酵，GitHub Copilot 被 “罵上熱搜”，甚至一度佔據 HackerNews 熱度榜第二的位置。<h2>GitHub 深陷侵權漩渦</h2>起初，還有一些開發者認為，GitHub 本身作為一個開源代碼託管的平台，應該不至於做出如此過分的事情，然而當他們發送郵件向官方詢問後，卻得到了令他們失望的回覆：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/3186e1c63da5e6fd19fecd6b227f13e5_1626403524.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1080" height="487" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/3186e1c63da5e6fd19fecd6b227f13e5_1626403524.png"/></div>（大意：這位開發者想知道當 GitHub 選擇代碼進行訓練時，會不會區分許可證？然而官方的回覆是，所有公開的代碼都會拿來訓練，並不會區分許可證。）GitHub 官方起初為了保護開發者的版權，提供了一套許可證機制（License），這樣其他用户在使用開源作者的代碼時，就要遵循一定的規則，不能任意使用。比如 GPL 許可，它要求任何人修改了軟件後，修改後的內容也必須開源。因此，商業公司在使用此類代碼的時候會非常有顧慮，因為一旦公司使用了 GPL 的代碼，那麼自己辛辛苦苦做出的修改內容也必須要通過 GPL 開源，讓競爭對手也可以直接拿來用，很難形成競爭壁壘。這也勸退了一些想要拿開源代碼 “不勞而獲” 的公司或組織。可是，根據網友的反饋，GitHub Copilot 雖然使用了包含 GPL 許可證的代碼，卻沒有按照自己的規定將 Copilot 開源，這也同樣引起了一些開發者的不滿。一些開發者在使用 GitHub Copilot 的過程中也發現了一些問題。當使用代碼補全功能的時候，Copilot 提供的代碼片段極有可能是某個開源作者的作品，這相當於未經許可使用了對方的代碼，但是，使用者和被侵權者兩方有可能都不知情。仍然以 GPL 許可來舉例。如果一位用户的代碼補全採用了其他用户的 GPL 許可證代碼，但因為這個用户不知情，並沒有按規則開源自己修改後的代碼，一旦後續發生了維權事件，這個責任該由誰來負？而企業開發者一旦使用了這項功能開發產品，並實現了盈利，是否應該給代碼的原作者分成？或者應該由 GitHub 來給開源作者們一些補償？<img id="edit_5484250" src="https://imageproxy.pbkrs.com/http://images.tmtpost.com/uploads/images/2016/12/2r3t43gret3.jpg?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" alt="" original-src="https://imageproxy.pbkrs.com/http://images.tmtpost.com/uploads/images/2016/12/2r3t43gret3.jpg"/>很不幸的是，都沒有，至少目前來看，GitHub 和微軟都沒有這方面的考慮。甚至 GitHub Copilot 官方的聲明上明確寫着：<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/40366ac5d37e0c9ca2388d11cd987f29_1626403525.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="692" height="297" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/40366ac5d37e0c9ca2388d11cd987f29_1626403525.png"/></div>“您在 GitHub Copilot 的幫助下創建的代碼屬於您自己......就像編譯器一樣，您使用 GitHub Copilot 輸出的東西屬於您。”自己辛苦開源出來的東西被一聲不吭地拿走，之後又可能在自己完全不知情的情況下成為他人的盈利工具，難怪開源作者們會如此憤怒。一些開源作者們想要聯合起來，對微軟提起訴訟，可是面對着力量龐大的技術大廠，維權談何容易。有關注此事的法律界人士表示：關於科技巨頭計劃如何使用開源資源庫，法律上是沒有任何規則或規定的。即使開發者們決定起訴微軟，這也意味着可能會對如何使用開源軟件施加一套新的規則，這反過來又會讓人們質疑開源的真正意義。總而言之一句話，即便被 “噴” 得這麼慘，微軟也未必擔心會受到法律制裁，只要 GitHub 還在他們手裏，怎麼使用也不過是換一套規則罷了。<h2>新時代的開源難題</h2>GitHub Copilot 帶來的版權問題也引起了一些國內技術專家與開發者的關注。比如小米集團副總裁崔寶秋就曾在微博上表示：“這確實是新時代的開源面臨的一個新挑戰。”<div><img src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/bf1cc3ffe784d6eb908150835c4729de_1626403525.png?x-oss-process=image/auto-orient,1/interlace,1/resize,w_1440,h_1440/quality,q_95/format,jpg" width="1041" height="619" original-src="https://imageproxy.pbkrs.com/https://images.tmtpost.com/uploads/images/2021/07/bf1cc3ffe784d6eb908150835c4729de_1626403525.png"/></div>光錐智能也就 “開源侵權與維權” 的話題跟開發者們聊了聊。綜合受訪者們的回答，我們總結出新時代的開源難題一般存在於這樣幾個層面：（1）侵權定性難一位開發者説：以他的瞭解，好像大家對 “代碼侵權” 沒什麼概念。一方面，“侵權” 的邊界很難界定，“開發者經常有借鑑別人思路的時候，或者參考了其他人的代碼結構，在這種情況下，是不是涉及侵權呢？” 他補充説，另一方面，即便真的有疑似侵權的情況，誰來判定侵權的事實是否成立呢？（2）證據蒐集難對於獨立開發者或者小型初創團隊來説，這幾乎是一道最難的坎兒。一位曾經參與創業的受訪者告訴光錐智能：“我們以前因為類似的事情跟大廠 ‘正面剛’ 過，但是我們沒有辦法證明他們的代碼創意來自我們。” 對方的回應與前文那位開發者説的情況極為類似，以 “撞了思路” 為由，將他們拒之門外。他補充説：“如果要反編譯他們的代碼，對方很有可能反過來把我們給告了，所以證據不足的情況下，下一步維權也難以走下去了。”（3）維權成本高綜合前面幾位開發者的講述，想必讀者們也發現了，開源代碼侵權這件事，首先從法律認定上就比較困難。根據光錐智能的瞭解，目前我國暫時沒有發生過與開源軟件許可證有關的訴訟，在法律層面上來説，這一部分也尚屬空白。雖然有法律專家表示，可以從著作權、專利權等角度入手進行訴訟，但是難度較大，只能在培養法律意識方面多多加強，並呼籲國家儘快在相關領域建立可以參考的政策法規。另一方面，開源維權往往發生在獨立開發者、小型初創團隊/公司與一些大廠之間，“人家大廠有資金、有法務，我們就算想打官司，也未必打得過人家”，一位受訪者無奈地表示，“對方吃準了你沒時間、沒精力、沒錢，光是從時間成本上來説，我們也耗不過他們。”“甚至於” 他補充説，“有些大廠因為嫌麻煩，收到維權郵件後，就直接問公司賬户是多少，靠砸錢來解決問題，真的是又好氣又好笑。”而國外的情況，想必大家在前文中也看到了，即便有過一些先例，即便有相對健全的法律，開發者們仍然只能吃啞巴虧，這是很多人非常難以接受，但目前又不得不接受得一點。<h2>開源不易維權難，且請珍惜</h2>在採訪的過程中，光錐智能感覺到開發者們雖然對侵權問題深惡痛絕，但卻無能為力；而行業內，也主要依靠開發者們普遍較高的道德水準，或者公司的嚴格規定在進行約束。某科技公司 CTO 表示：“嚴格注意版權問題不止是公司規定，更是行業規定，如果出問題是要有法律責任的。”可是，當侵權問題真的發生了，又有多少人能維權成功呢？<ul><li>參考鏈接：https://zhuanlan.zhihu.com/p/91071379</li></ul>更多精彩內容，關注鈦媒體微信號（ID：taimeiti），或者下載鈦媒體 App

開源者的怒火，這一次被 GitHub 點燃了。

GitHub 用 AI 幫程序員補全代碼，卻惹怒了一羣開源作者