從轉載阿里開源專案 Egg.js 技術文件引發的“版權糾紛”，看寬鬆的 MIT 許可該如何用？
作者 | 蘇宓、彭慧中
出品 | CSDN（ID：CSDNnews）
開源迅速發展的這兩年，很多內部問題逐漸凸顯出來，如安全、版權、協議使用等。
近日，來自V2EX社群中一位開發者 @an168bang521 釋出的一篇題為《想問下懂法律的老哥們，摘抄阿里開源軟體 Egg。js 技術文件內容算不算侵權》的文章，引發開源屆不少開發者的熱議與關注，當專案團隊成員釋出的技術文件所遵循的開源協議遇上文章版權，該遵循哪種使用規則？其二者是否會有衝突？外部的開發者怎麼做才是合法合規？又該如何避免開源專案的開發者和開源使用者之間的矛盾？
為解答這些極具爭議的問題，CSDN 開源直播欄目《開源圓桌派》邀請到 OSCAR 開源共讀發起人、LF APAC 開源佈道者團隊主席李建盛（適兕），《大教堂與集市》譯者衛劍釩，Zilliz 合夥人&開源佈道師顧鈞，以及開源之道北京活動主持人、開源愛好者鬱志強，從法律、許可使用的角度分享開源協議 MIT 的具體使用，幫助更多的開源開發者“普法”與“避坑”。
轉載技術文件引發的侵權爭議
想必很多前端開發者，對於阿里巴巴團隊研發的企業級 Node。js 框架 Egg。js（以下簡稱 Egg）並不陌生。截止目前，Egg 在 GitHub 上 Star 數為 17。9k，Fork 數為 1。7k。在研發之初，其開發團隊的願景便是希望“由 Egg。js 孕育出更多上層框架，幫助開發團隊和開發人員降低開發和維護成本”。
今天的爭議點也是圍繞開源 Egg 技術文件的使用展開。
首先，回顧事件始末，還要從 2018 年開始說起。
2018 年 4 月 5 日，作為 Egg 核心開發者之一，“天豬”（暱稱）在知乎上釋出了一篇關於 Egg 的使用指南帖子——《當 Egg 遇到 Type，收穫茶葉蛋一枚》（https：//zhuanlan。zhihu。com/p/35334932）。其內容詳述了使用 TypeScript 開發 Egg 過程中遇到的一些影響開發者體驗的問題，並附上了開發規範和問題的解決方案。
此內容釋出之後，吸引了不少 Egg 框架使用者的點贊與分享，僅是在知乎平臺上，這篇文章的點贊數達到了 270+。
由於這篇文章反響不錯，Egg 專案團隊覺得可以將其整合到官方文件中。於是不久後，這篇文章合併到了 GitHub Egg 的官方文件中（https：//github。com/eggjs/egg/commits/2。29。3/docs/source/zh-cn/tutorials/typescript。md）。
沒想到，“隱患”也就此埋下。
四年之後的 5 月 26 日，正如文章伊始所述，開發者“an168bang521” 在一篇帖子中提到，自己收到了一個知乎使用者委託公司的郵件，告知自己的個人網站擅自使用了知乎的作品，侵犯了知乎的資訊網路傳播權，並要求採取相關的補救措施。
an168bang521 被告“侵權”的內容，正是天豬的那篇《當 Egg 遇到 TypeScript ，收穫茶葉蛋一枚》及同樣釋出在 GitHub 官方文件上的內容。
在收到“授權委託書”時，an168bang521 感到十分不解，其表示，“網站文章來自 GitHub Egg 倉庫以及 Egg 官網，且 Egg 使用了 MIT 許可協議，該協議允許任何人使用和操作程式碼，自己也是在這個協議下進行操作的，因此不算侵權。”
透過郵件溝通，對方給出的回覆是，「該篇內容的版權方屬於天豬在知乎上的個人賬戶，而他是以個人身份告這位網友」。
值得一提的是，GitHub 上的 Egg 開源專案使用的是主流的開源許可之一的 MIT。相對其他常見的 GPL、BSD 等軟體許可協議，MIT 更為寬鬆，其允許任何人免費獲得軟體和相關文件檔案副本的許可，不受限制地處理本軟體，被許可人有權利使用、複製、修改、合併、出版發行、散佈、再許可和/或販售軟體及軟體的副本，及授予被供應人同等權利。
那麼問題來了，一邊是需要遵循釋出的媒體平臺協議，一邊是需要遵循 GitHub 平臺上 Egg 所使用的 MIT 許可，同一篇內容釋出在兩個平臺時，到底應該依據哪一種平臺規則呢？
an168bang521 也在帖子上表達了他的疑惑：“以個人的身份告我侵權，是否屬於維護他的正當權利？如果是屬於走著正當權利，我可以把文章刪掉，甚至我還可以專門寫一篇文章掛在首頁上賠禮道歉。”
作為另一當事人，天豬則顯得有些被動，其表示，自己是在 an168bang5 釋出帖子的第二天在被各路網友“討伐”中，才知道自己身處“輿論的漩渦”。由於郵件是因為該專欄是授權給媒體平臺了，自然也使用了該平臺的版權服務，當它檢測到文章被未授權就被轉載時會自動傳送侵權通知，而自己本人並不知情。
他表示，“這麼多年來，遇到希望轉載的人，他基本上都是免費授權的。唯一的要求就是：事先通知過他本人獲取授權，並註明原文出處，不要破壞文章結構以及加太多廣告。”針對此次事件，他並不想追究侵權。
而開發者 an168bang521 也表示發帖的目的並非針對文件作者本人，因為 MIT 爭議空間較大，涉嫌侵權的內容目前已經做了全部刪除和下線處理。
僅有 40% 的開發者知道不同開源協議之間的區別
至此，兩位開發者之間關於侵權一事已達成和解，但是這件事給其二人心中都留下了一些疑問。
事實上，這也不僅是這兩位開源開發者的顧慮，據 CSDN 釋出的《2021-2022中國開發者調查報告》顯示，當問及開發者，對開源協議瞭解有幾何時，發現近三成的開發者仍然不懂開源協議。在進一步探究時，僅有 40% 的開發者知道MIT、GPL 與 Apache 開源協議的區別。
這意味著絕大多數開發者處於模糊和完全不懂的迷茫中，這同樣引發了我們的反思與思考。在本期《開源圓桌派》直播對話欄目中，來自 4 位開源屆的一線專家也將為我們深度揭曉開源協議的普及現狀與使用的那些事。
鬱志強：當前開源社群成員對開源許可的瞭解情況如何？
衛劍釩： 開發者成長為開源開發者，這是一個需要不斷普及的過程。一開始很多人版權意識比較弱，也不去看很多開源許可證，而後經歷很多諸如此類的事件，從而不斷地瞭解與學習，久而久之，大家才會有這樣的意識。就開源領域而言，在我們的學校教育以及工作的文化教育體系中，往往都缺乏版權意識培養，導致不瞭解的人很多，這個屬於正常現象，也希望以後會越來越多的人瞭解版權、許可的知識。
顧鈞：我們的專案是用 Apache 2。0 進行開源的。開源的時候，在 GitHub 上整個專案的程式碼倉庫包含了軟體本身以及文件，同時也涉及一些技術 Demo。這些 Demo 有時候可能是一篇技術文章，其中會包含程式碼和指令碼，讓初使用者可以跟著一步一步地復現 Demo 中涉及的案例。這意味著整個程式碼倉庫所包含的內容，不僅僅只有程式碼，還會有文件、部落格、測試報告等。
然而，這樣做往往會帶來一些問題，就 GitHub 網站而言，由於資訊顯示方式的影響，當開源開發者提交程式碼時，頁面可能就顯示了最初建立程式碼倉庫時所選擇的主要許可。但是，在提交過程中，程式碼倉庫有好多不同的目錄，每個目錄可能都有不同的協議，有的專案也會引用一些第三方的專案，而第三方專案所遵循的協議可能是 MIT、LGPL，不一定就是 Apache 2。0。
其實當前很多開發者也會存在誤解，即當他們看到 GitHub 上顯示該程式碼倉庫是某一種協議時，會誤以為裡面包含的所有內容都是遵循這樣的協議。事實上並非如此，程式碼倉庫的每個目錄下面都有可能是不一樣的協議。因此，當我們瀏覽或使用尤其是綜合性的程式碼倉庫時，都需要留意一下所引用的內容，情況往往比較複雜。
鬱志強：在同一程式碼庫中，我們是不是可以選用多個不同的協議，在同一個專案的程式碼和文件以及相互的約束之前，在一些系列協議裡是否有相關的規定呢？
衛劍釩： 雖然這種我見得不多，但在大型專案中會存在這種情況。當一個專案中存在不同的模組、文件時，應該用顯著的方式將使用的不同協議標註出來，而不應該讓開發者自己去查詢。不過，現實情況下，大多數專案還是以單一的協議居多，另外即使是專案中引用了第三方模組，建議開發者能夠明確說出來，原來所遵循的協議是什麼，相容以後使用的協議又是什麼，這樣都是可以的。
如何避免潛在的侵權事件發生？
鬱志強：程式碼倉庫怎麼構建，怎麼確定協議？
適兕：開源，大家最倡導的一個理念就是開源是一個來自全球協作的集體產品。所謂集體產品，作為程式設計人員都知道，最終是以某一個檔案的方式去展示某個作品的許可，其中的許可就是指作者希望別人如何去使用。
從協作的角度，如果軟體各部分不衝突，整體就可以使用一種授權方式，又或者可以讓大部分的檔案使用某一種許可，小部分使用另一種許可。事實上，軟體每一個版本都可能重新發布許可，當然這個很少見，但如果你去觀察，你會看到例如像 Python 程式語言這樣的龐大專案中，每隔一個大版本就會重新定義一下自己使用的協議。因此，作為開發者，在構建程式碼倉庫時，可以先對軟體專案的過去歷史要有所瞭解，因為很多專案是一個多人協作的產物。
鬱志強： 在上述事件中，開發者 an168bang521 這樣轉載的行為，以及版權是如何判定的？
衛劍釩：從他們各自發表的文章中可以看出來，這位開發者原先沒有說明文章來源，直接複製貼上他人的文章，這種做法有些欠妥。即使文章是在 MIT 協議下發布的，但也需要注意 MIT 協議是有前提條件的，即註明版權資訊，而且還需要附上 MIT 協議。這樣的做法才符合 MIT 協議的要求，顯然在事件中，原開發者有些步驟缺失了。
顧鈞：大家可能在實操層面都會誤認為：只要是在 MIT 協議下發布的內容，就可以非常自由地去分享，但實際上並非如此。在開源世界當中，我們經常可能會用雙重許可的方式去釋出同一個內容，比如這篇文章在 GitHub 上遵循的是 MIT 協議，而在知乎上遵循的是更為嚴格的 CC 協議（知識共享許可協議，Creative Commons license，又叫 CC 協議）。如果想要用更為自由的 MIT 的方式去轉載內容，就必須要很明確地表明這是在 MIT 協議下分享的，不然可能就會造成誤解，會被誤認為違反了更加嚴格的 CC 協議。
還有例如像 Mexico 這樣的開源專案，它既有 GPL 同時也有商業版的 License。有些公司在使用過程中可能做了 Mexico 的二次開發，但依舊想保持閉源的狀態，那麼其可以透過購買商業版的 License 使得自己二次開發之後保持閉源。因此，一個專案有多個許可是完全有可能發生的，同時我們也需要注意自己是在哪個許可下使用所需要的內容。
相對寬鬆的 MIT 協議究竟應該怎麼用？
鬱志強：MIT 協議裡允許的操作空間是什麼？是否可以不經過原作者同意直接使用 MIT 協議下的文件？
衛劍釩：MIT 協議一共包括三段說明：
第一段表達的是如果你滿足我的要求，你就可以擁有使用、複製、修改、合併、釋出等這些操作的權利，但前提是必須得滿足協議中的條件；
第二段所註明的條件就是需要附上版權資訊及 MIT 協議。事實上，使用者附上 MIT 協議全文或者附上 MIT 的連結都可以的。
第三段有個很重要的部分就是
