GNU通用公共許可協議（General Public License，GPL）是一種適用于軟件和其他各類作品的自由且不可加以限制的COPYLEFT許可證。根據GPL3.0規定，被許可人享有復制、修改（署名）及轉發源代碼的權利，但同時需承擔相應的法律義務，即GPL3.0要求被許可人在轉發經其修改后的軟件作品時，必須具有顯著的聲明：說明對該作品進行了修改并提供修改相關的日期，說明該作品是依據本許可證以及根據第7條附加的條件進行發布的；并且根據本許可證將整個作品作為一個整體授權給任何擁有副本的人；本許可證將與任何適用的第7條附加條款一起，適用于整個作品及其所有部分，無論它們是如何打包。

而GPL的核心原則就是它的“傳染性”。“傳染性”可以通俗定義為：如果是轉發修改后的源代碼，新修改的代碼也必須遵循GPL協議；以保證無論他人是否修改源代碼，都可以享有繼續復制、修改、轉發的權利，以使得這種自由的權利繼續延續下去。這種"傳染性"確保了開源軟件的自由傳播、開源共享和開放合作。

下面結合最高人民法院的一則司法案例進行GPL“傳染性”的探討[1]。

一、案件背景

2014年3月原告不亂買公司成立。2014年8月10日，不亂買公司網站（××）上線。2016年8月23日，國家版權局頒發計算機軟件登記證書，顯示軟件名稱為“不亂買時尚海淘軟件（ＰＣ版）”，著作權人為不亂買公司，開發完成日期為2015年3月27日，首次發表日期為2015年3月27日。不亂買公司提交了（2016）京中信內經證字第72865號公證書，2016年8月30日對不亂買公司網站（××）頁面信息、網頁源代碼及腳本源代碼進行了公證。該公證書顯示，不亂買公司網站頁面底部標有“2013-2016不亂買電子商務（北京）有限公司”字樣。同時，不亂買公司亦提交了其網站源代碼電子文件及用以證明涉案軟件的研發過程的證據。

一審庭審中，不亂買公司確認其主張權利的代碼為其后端所有代碼，不包括數據庫。被告閃亮時尚公司對不亂買公司軟件源代碼權屬不予認可，但未提交相反證據。為證明閃亮時尚公司對不亂買公司享有著作權的軟件具有接觸可能性，不亂買公司提交了微信記錄、郵件截圖、勞動合同及閃亮時尚公司工商登記信息等。

二、關于雙方源代碼獲取及比對情況

不亂買公司對閃亮時尚公司網站頁面信息、網頁源代碼及腳本源代碼進行了公證，并提交了自行比對的結果，閃亮時尚公司對此不予認可。

一審中，不亂買公司向原審法院提交了調查取證申請，依據不亂買公司申請，原審法院于2018年3月向阿里云計算有限公司調取其服務器中閃亮時尚公司網站后臺全部軟件代碼。技術調查官對不亂買公司提交的后端代碼進行了篩查，排除了開源代碼的使用。因閃亮時尚公司不同意向不亂買公司及案外人提供其網站代碼文件，僅同意在原審法院的主持下進行比對，且由于雙方代碼文件數量龐大，雙方當事人均同意采用抽樣方式進行比對，故原審法院確認在其主持下采用抽樣比對的方式對不亂買公司和閃亮時尚公司網站代碼文件進行比對，抽樣比對結果將推及全部代碼。抽樣及比對過程如下：

在原審法院主持下，不亂買公司明確有版權的權利文件3922個。經雙方當事人一致同意，原審法院確認以5%的比例從中挑選20個文件作為不亂買公司的抽樣比對文件，再以關鍵詞等方式確定閃亮時尚公司的對應文件，最后用比對軟件進行比對。在技術調查官的監督下對原審法院調取的閃亮時尚公司網站源代碼壓縮文件進行全盤解壓，共計1086萬個文件。不亂買公司針對其選取的20個核心代碼文件在已解壓的閃亮時尚公司源代碼文件中進行查找，最終確定對應文件13個。針對上述13個文件使用雙方確定的ultracompare軟件與不亂買公司對應源代碼文件進行逐一比對，最終由該比對軟件輸出13份比對結果。比對結果顯示：二者有些許差異，總體上實質相似。

三、GPL3.0部分相關規定

定義部分，“本程序”指任何在本許可下批準的受版權保護的程序。“修訂”程序是指從軟件拷貝或者做出全部或一丁點兒的修改，這不同于逐字逐句的拷貝，是需要版權許可的。修訂成果被稱為先前程序的“修訂版本”或者“基于”先前程序的程序。

第5條，發布修訂過的源碼版本，您可根據第4條的條款，以源碼形式發布一個基于本程序的程序，或者從本程序中制作該程序需要進行的修訂，但是您必須同時滿足所有以下條件：c)…本許可以及第7條中的任何附加條款適用于整個程序及其所有部分，無論該等程序以什么形式打包。d)…如果一個受保護程序和其它獨立程序的聯合作品，則若該聯合作品并非該程序的自然擴展，也不是為了在某個存儲或發布媒介上生成更大的程序，且如果聯合作品和產生的版權未用于限制編譯用戶的訪問或超出個別程序許可的合法權利時，這樣的聯合作品就被稱為“聚合體”。包含受保護程序的聚合體并不會使本許可應用于該聚合體的其他部分。

四、一審法院觀點

在不亂買公司已就其享有涉案軟件著作權提交初步證據且閃亮時尚公司并未舉出反證的情況下，原審法院對不亂買公司的權利予以認可。不亂買公司有權就涉案侵權行為提起訴訟。閃亮時尚公司提交的公證書顯示，不亂買公司網站的前端代碼中使用了GPL許可協議下的開源代碼，不亂買公司對此亦予以認可。閃亮時尚公司認為，不亂買公司使用了適用于GPL軟件許可協議下的開源代碼，根據GPL許可協議相關內容，不亂買公司無權對其網站整個軟件主張著作權。對此，原審法院認為，不亂買公司明確其主張權利的代碼為后端代碼。前端代碼開發主要是指前端用戶可見的操作界面如頁面布局、交互效果等頁面設計的一種實現方式，后端代碼開發則主要是指后端用戶不可見的服務端相關邏輯功能等模塊的實現，二者展示方式不同、所用技術不同、分工亦有明顯區別，屬于可獨立的程序。根據GPL協議的相關規定，GPL協議的許可客體是在GPL協議許可下批準的受版權保護的程序以及基于該程序的衍生產品或修訂版本。就該案而言，不亂買公司主張的權利的后端代碼中已排除開源代碼，不亂買公司雖在其前端代碼中使用了開源代碼，但其后端代碼程序并非其前端程序的衍生品或修訂版本，故根據GPL協議的相關規定，該協議對涉案權利代碼并無拘束力。據此，閃亮時尚公司的相關抗辯理由不能成立。

著作權侵權案件中判斷被訴侵權作品是否使用了享有著作權作品的方法一般適用“接觸加實質性相似”。綜合本案證據，原審法院認可閃亮時尚公司具有接觸到不亂買公司涉案權利軟件的可能性。

關于實質性相似。基于比對結果及技術分析可知，抽樣比對的絕大部分程序文件在程序邏輯和結構方面實質相同，函數變量命名特點相同或相似，且閃亮時尚公司不同文件的代碼中多次出現與不亂買公司程序中相同的注釋錯誤，該現象難謂巧合。據此，可以確定閃亮時尚公司與不亂買公司的上述程序文件實質相似的比例較高，閃亮時尚公司的該行為落入不亂買公司的復制權及修改權的保護范圍。故閃亮時尚公司未經不亂買公司許可使用涉案軟件的行為已侵犯不亂買公司就其軟件享有的署名權、復制權及修改權，應承擔停止侵權、賠償損失及賠禮道歉的法律責任。

五、二審法院觀點

閃亮時尚公司上訴稱不亂買公司前端代碼與后端代碼存在交互且沒有進行有效隔離，不是相互獨立的，根據GPL協議的相關內容以及極強的傳染性特性，不亂買公司的前端文件和后端文件共同構成的其主張著作權的軟件，整體軟件都可以視為前端程序的修訂版本，應當遵循GPL協議向所有第三方無償開源。對此，二審法院認為，第一，前端代碼一般是關于用戶可見部分的編碼，用以實現操作界面如頁面布局、交互效果等頁面設計；而后端代碼一般是涉及用戶不可見部分的編碼，用以實現服務端的相關邏輯功能。同時，前端代碼與后端代碼是可以分別獨立打包、部署的。因此，前端代碼與后端代碼在展示方式、所用技術、功能分工等上均存在明顯不同，不能因前端代碼與后端代碼之間存在交互配合就認定二者屬于一體，原審法院認定前端代碼與后端代碼相互獨立并無不當。第二，不亂買公司作為權利人在本案中明確放棄以前端代碼主張權利，僅以后端代碼主張權利，因此涉案軟件僅為后端代碼而非閃亮公司所稱前端文件和后端文件共同構成涉案軟件。第三，根據2007年6月29日發布的GPL協議第3版第5條關于“一個受保護程序和其它獨立程序的聯合作品，在既不是該程序的自然擴展，也不是為了生成更大的程序，且聯合作品和產生的版權未用于限制編譯用戶的訪問或超出個別程序許可的合法權利時，被稱為聚合體。包含受保護程序的聚合體并不會使本許可應用于該聚合體的其他部分”的規定，閃亮時尚公司所稱GPL協議的“傳染性”應當是指GPL協議的許可客體不僅限于受保護程序本身，還包括受保護程序的衍生程序或修訂版本，但不包括與其聯合的其他獨立程序。本案中，雖然不亂買公司認可其前端代碼中使用了GPL協議下的開源代碼，但其主張權利的是后端代碼，其后端代碼是獨立于前端代碼的其他程序，并不受GPL協議的約束，無需強制開源。綜上，閃亮時尚公司的上訴理由不能成立。

六、本文作者觀點

最高法院在二審中確認了涉案軟件前端代碼和后端代碼的區別，即前端代碼一般是關于用戶可見部分的編碼，用以實現操作界面如頁面布局、交互效果等頁面設計；而后端代碼一般是涉及用戶不可見部分的編碼，用以實現服務端的相關邏輯功能。前端代碼與后端代碼可以分別獨立打包、部署。前端代碼與后端代碼在展示方式、所用技術、功能分工等上均存在明顯不同，不能因前端代碼與后端代碼之間存在交互配合就認定二者屬于一體。筆者認為，上述觀點盡管基本符合GPL的相關規定，但感覺仍有很大的探討空間。即在前端代碼與后端代碼之間存在交互配合的情況下，哪些情形可以認定構成一體，哪些情形不構成一體？

我們假設一種情形，后端代碼盡管可以獨立打包并實現相關邏輯功能，但后端代碼只能且唯一依賴該前端代碼才能運行，否則后端代碼不能獨立運行，即后端代碼只能依靠該前端代碼才能實現其功能和價值，或者后端代碼與前端代碼之間存在調用代碼或者函數的關系，亦或者前端代碼直接影響后端代碼的結構，此時前端代碼仍然不能傳染給后端代碼嗎？答案可能是否定的。與之相反的情形，當后端代碼通過程序接口可以與多種前端代碼交互配合或者反之亦然，即前端代碼和后端代碼都可以獨立運行且具有兼容性，則該種情形下認定前端代碼不具有傳染性應該不會有太大的爭議。

進一步而言，在軟件開發實踐中，廣泛存在開源軟件與專有軟件進行組合的情形。GPL軟件與專有軟件形成的組合軟件是否需要開源，應取決于GPL軟件與專有軟件的交互方式。例如，Linux開發環境下的應用程序，如果一個為Linux系統編寫的專有軟件僅運行于Linux內核的常規系統調用中并保留在“用戶區（UserLand）”，則該專有軟件應該無須遵守GPL。另一個例子，如果利用GPL下的軟件工具創建專有軟件，GPL軟件工具中的代碼沒有合并到創建的專有軟件中，則該專有軟件應該無須遵守GPL，此種情形下，GPL軟件工具僅用作創建專有軟件的輔助工具[2]。另外，關于用戶單獨分發Linux內核模塊，及GPL下訪問軟件庫的程序等情形是否需要遵守GPL，還有開源軟件應用程序接口（API）的侵權風險等問題，目前還缺少相關的司法案例，筆者將繼續關注并研究。

參考文獻：

[1] 最高人民法院民事判決書（2019）最高法知民終663號。

[2] 張平，徐美玲：《開源規則：案例、許可證及開源組織》，知識產權出版社，2022年11月第1版，第15頁。

作者：高玉光北京市信利（深圳）律師事務所

編輯：智愿君 校對：智愿君