国产精品偷伦一区二区,国产精品美乳在线观看,日本亚洲导航

引言

在第一篇文章《開源軟件與法律探析導讀》中，我們介紹了開源、開源協議（也稱“開源許可證”）的相關概念、法律性質以及相關知識產權風險。

本文將針對目前發生法律糾紛較多的GPL協議進行詳細解讀。我們將梳理GPL協議的發展歷程，介紹對企業影響最為顯著的傳染性條款，并分析和總結司法實踐中的關注要點，如①GPL開源協議的性質、②開源項目貢獻者之一是否有權提起訴訟、③傳染性的判斷標準、④使用GPL開源開發工具編寫的軟件是否會被傳染等，從而向企業提供開源合規建議和指引，以期為企業的風險排查提供思路。

一、GPL開源協議簡介

GPL開源協議是開源領域被廣泛使用的協議，自1989年發布以來，共有3個版本（GPL v1/v2/v3）[1]，著名的Linux中就使用了GPL v2協議。GPL協議屬于典型的著佐權協議，其具有強傳染性，要求使用者公開相應源代碼。因此，因違反GPL開源協議的規定而產生糾紛的情形較多，主要涉及GPL v2與GPL v3協議，故本文將重點介紹這兩種開源協議。

1. GPL v2與GPL v3開源協議簡介

GPL v2與GPL v3開源協議雖為兩個獨立版本，但作為GPL協議家族的成員，兩者均繼承了GPL類開源協議的基本宗旨與精神，都給予了用戶使用開源軟件的自由，同時要求用戶保證前述自由的延續性（例如分發給下游用戶時需要開放源碼以及提供開源協議）。

GPL v2開源協議于1991年6月發布，被應用于Linux的Spacewalk，C/C++庫的API Sanity Checker、華為OpenHarmony的一款打包工具等知名項目。

GPL v3開源協議于2007年6月29日發布，其應用于Linux的4Pane、微信小程序、SaaS運營平臺的SAPI++、Ansible等知名項目。

為了更好地適應當時開源軟件的開發和使用，GPL v3開源協議在GPL v2的基礎上進行了澄清、細化和補充，主要涉及以下方面：

· 禁止Tivoization

Tivoization指的是在設計硬件時，硬件廠商使用了開源軟件，并通過硬件或者DRM限制（全稱為“digital rights management”，是一系列訪問控制技術，類似于數字“保護鎖”，可以控制和限制數字媒體的使用過程），使得用戶無法在原有硬件上運行修改過的開源軟件[2]。也即，即便硬件廠商按照開源協議的要求公開了源代碼，但用戶仍然無法在硬件上正常運行修改后的源代碼，實質上還是剝奪了用戶對開源軟件源代碼進行修改的權利。

由于GPL v2未限制Tivoization，開源軟件權利人無法通過GPLv2來規制硬件廠商的上述行為。因此，在更新的GPL v3開源協議中，第6條明確禁止Tivoization，要求硬件廠商不僅需要提供源碼，還需要提供安裝信息“基于修改過的源碼安裝運行該產品中的受保護作品的修改版所需的任何方法、流程、認證碼及其他信息”，以保證用戶可以在硬件上運行修改過的代碼[3]。

· 要求開源軟件貢獻者進行專利許可

為避免開源軟件貢獻者通過開源協議授予用戶著作權許可，但轉而又針對用戶提起專利侵權訴訟，GPL v3第11條明確規定“每個貢獻者就‘必要專利權利要求（essential patent claims）’授予用戶非獨占的、全球范圍的、免費的‘專利許可’”，其中“‘必要專利權利要求’是指貢獻者已經獲取或將會獲取的，可能會被他人在遵守GPL條款的前提下，因制造、使用或銷售本軟件而侵犯的所有專利權利要求”[4]，強制開源軟件貢獻者同時授予用戶專利許可，以保障用戶對開源軟件的自由使用不會受到專利的限制，而GPL v2中沒有類似規定。

· 從GPL v2到GPL v3，除了前述更新之外，還有允許破解、授權中止和恢復條款等更新。

2. GPL開源協議的傳染性條款

一般情形下，GPL開源協議中的眾多條款中，對企業影響最大的是傳染性條款。傳染性條款指的是，如果用戶使用了適用GPL協議的開源軟件，基于該開源軟件創作的后續作品的部分或全部都應當同樣進行開源。舉例而言：

· 若企業原封不動的使用適用GPL協議的開源軟件，那么在后續分發該開源軟件時，企業需要提供該開源軟件對應的全部源代碼。

· 若企業不僅使用開源軟件，還在開源軟件的基礎上進行修改開發而形成了開源軟件修改版，那么在分發該開源軟件修改版時也需要公開整個開源軟件修改版的源代碼。

· 若企業將開源軟件或其修改版作為新軟件作品的一部分，也即新軟件作品中包含該開源軟件或其修改版的源代碼，那么該新軟件作品也很可能同樣落入傳染性條款，需要公開整個新軟件作品的全部源代碼。

· 若企業在設計面向用戶的硬件產品時，使用了適用GPL v3的開源軟件，那么該企業除了需要公開相應源代碼，還可能需要同時提供安裝信息，包括認證碼、方法、流程及其他信息，以保證用戶可以在硬件上正常運行修改后的開源軟件。

· 例外情況：若與開源軟件或其修改版相比，企業開發的新軟件作品是分離且獨立的，新軟件作品與開源軟件或其修改版僅僅處于同一個存儲介質，新軟件作品并非基于開源軟件或其修改版，或也不屬于和開源軟件或其修改版一起構建出一個更大的軟件，那么該新軟件作品不會受到傳染性條款的影響，無需公開全部源代碼。

另外，企業在公開源代碼時，既可以通過任何媒介（如Github、光盤、U盤）直接公開源代碼；也可以在轉發開源軟件的目標代碼或可執行文件時，提供一個可獲取源碼的書面要約，告知用戶如何獲取源碼。

二、涉及GPL開源協議的法律問題

由于GPL協議提出時間較早、應用廣泛且傳染性較強，目前司法實踐中出現的開源軟件糾紛多涉及GPL協議。筆者梳理和總結了國內外相關的司法案例，主要涉及以下幾類法律問題：

1. GPL協議的法律性質

確定GPL協議的法律性質是厘清各方當事人權利和義務的基礎。如我們在第一篇文章《開源軟件與法律探析導讀》中所述，目前國內外的司法實踐中傾向于將GPL協議認定為附解除條件的著作權許可合同。具體地，

· 羅盒vs.玩友一案[5]中，廣州知識產權法院認為：“第一，協議的內容具備合同特征，屬于廣義的合同范疇。第二，協議是非典型合同。第三，協議是格式合同。第四，對協議的承諾是通過行為作出。GPLv3協議具有合同性質，是授權方和用戶訂立的格式化著作權協議，屬于我國合同法調整的范圍。”并進一步指出“GPLv3協議屬于附解除條件的著作權合同。許可條款是版權許可的條件，如果用戶違背條款規定，那么許可的前提條件已不復存在，則GPLv3協議終止適用，用戶獲得的授權也將自動終止”。

· Welte vs. D-Link一案[6]中，德國法蘭克福地區法院將GPL協議認定為附解除條件的合同，其中許可使用條件為解除條件，當被許可人未按許可使用條件使用時，合同解除、終止授權，被許可人繼續使用則構成侵權。

· Jacobsen vs. Katzer一案[7]中，美國加州北區地區法院和美國聯邦巡回上訴法院認為，由于權利人通過開源項目提高了其知名度，可以被認為是開源協議的對價，因此構成許可協議，超過協議部分的使用構成著作權侵權。

2. 開源項目貢獻者之一是否有權提起訴訟

開源軟件的開發過程中往往具有眾多貢獻者。例如，根據Github開源網站的規定，開源軟件項目管理人上傳開源代碼并創建主分支，其他用戶可以基于主分支創建副本（fork），創建自己的分支并自行修改維護。其他用戶也可以發起請求（pull request），申請加入主分支，項目管理者同意后，其分支并入主分支，且該用戶成為主分支的貢獻者。

根據著作權法的相關規定，一般認為不同貢獻者對各自貢獻的部分享有著作權。因而，在此類案件中，被控侵權人往往會質疑開源貢獻者作為原告的適格性，主張開源軟件是合作作品，具有眾多貢獻者，原告并非唯一權利人，只有在獲取所有貢獻者的許可后才能提起著作權侵權之訴。

但實踐中，開源軟件的眾多貢獻者往往來自不同的地區或國家，若要獲取所有貢獻者的許可后才能提起著作權侵權之訴，將會花費大量的時間和成本，無法有效保障開源軟件權利人的合法權益，不利于開源軟件的發展。

這種情況下，我國及其他國家的法院傾向于認為：起決定性作用的項目管理者可以作為著作權人起訴，而無需經過其他貢獻者的授權；若貢獻者未能證明其具體貢獻以及相應的著作權，則不能作為著作權人起訴。具體地，

· 我國法院觀點：起決定性作用的項目管理者可以作為著作權人起訴，而無需經過其他貢獻者的授權——羅盒vs.風靈[8]

權利人羅盒公司為開源代碼羅盒（Virtual App）的項目管理者，該項目中，共有30多個貢獻者對涉案源代碼做出了修改。被控侵權人風靈公司等抗辯涉案軟件是合作作品，沒有證據證明其他貢獻者將著作權轉讓給原告，因此羅盒公司不是適格原告，無權就開源代碼提起訴訟。

最高人民法院認為：“原告的股東作為項目管理人上傳了大量Virtual App初始版本源代碼，對涉案軟件源代碼的形成起到了決定性作用，其他貢獻者對Virtual App的著作權是否產生實質影響尚不明確；且即使開源代碼的其他貢獻者對其貢獻部分享有獨立的著作權，基于GPL3.0協議，項目管理人與貢獻者之間也存在著相互許可的關系。其他用戶提交代碼并申請并入主分支這一行為表示其默示同意項目管理人作為普通被許可人，可以提起侵權之訴。綜上，羅盒公司作為提交了涉案軟件絕大部分源代碼的項目管理人，其提起本案訴訟無需經過其他貢獻者的授權”。

· 德國法院觀點：若貢獻者未能證明其具體貢獻以及相應的著作權，則不能作為著作權人起訴——McHardy vs.Geniatech案[9]

Linux是知名的開源操作系統，Patrick McHardy負責維護Linux的子系統Netfilter，該子系統為 Linux 內核提供與網絡相關的操作。Geniatech制造的衛星電視接收器采用了Linux操作系統。Patrick McHardy認為Geniatech侵犯其著作權，并針對Geniatech使用的任何版本的Linux系統尋求禁令。

德國科隆法院高等法院認為：第一，Patrick McHardy只是一個編輯作者（例如做補丁）而非Linux和Netfilter的共同作者；第二，Netfilter早在1999年就存在，比Patrick McHardy首次為Netfilter做出貢獻早3年，也比Patrick McHardy加入核心團隊早5年；原告無法充分證明其對Linux操作系統的貢獻以及該貢獻可以構成著作權法上的作品，因此Patrick McHardy無權對整個Linux操作系統主張禁令。另外，在該案中，被告還提交了Patrick McHardy涉嫌濫用訴權的證據。

3. GPL傳染性判斷依據

如前所述，傳染性條款對企業的影響較大。如果落入傳染性條款，那么企業需要公開源代碼，否則將要面臨違約或者侵權風險。因此，傳染性的判斷對于企業而言尤為重要。近年來，在最高院和各地法院發布的多個案例中，在判斷傳染性時考慮了以下因素：

· 開源代碼與其他代碼所處的層級框架是否相同、各個層級框架是否適用相同的開源協議；

· 開源代碼與其他代碼的展示方式、所用技術、功能分工是否存在明顯不同（如前端代碼和后端代碼）；

· 開源代碼與其他代碼的隔離技術手段、所處的文件夾是否相同、是否使用同一共享地址空間并連接在一起；

· 開源代碼與其他代碼之間通信機制（exec、pipes、rpc、sockets和命令行參數等）、通信語義等。

下文將結合最高院和各地法院的幾個典型案例，進行簡要分析，以期為企業提供傳染性的判斷指引。

· 羅盒vs.玩友一案[10]中，羅盒是Virtual App的權利人，并在GitHub上公開了Virtual App的源代碼，適用GPLv3協議。玩友提供的被控侵權軟件“微信視頻美顏版等”，部分代碼與Virtual App相似，卻未公開源代碼。權利人羅盒認為玩友因使用了Virtual App，其被訴侵權軟件整體被傳染，但未向用戶提供源代碼，構成侵權。

廣州知識產權法院認為：“對于在邏輯上與開源代碼有關聯性且整體發布的衍生作品，只要其中有一部分適用了GPLv3協議發布，那么整個衍生作品都必須適用GPLv3協議而公開”，并基于玩友未能舉證其使用的開源代碼是獨立的或在各個獨立的不同層級框架中適用不同的開源授權許可協議，最終認定被訴侵權軟件整體應遵循GPLv3開源協議，其未向用戶提供源代碼的行為違反了GPLv3的規定。GPLv3協議自動終止，玩友構成侵權。

· 不亂買vs.閃亮時尚一案[11]中，原告不亂買起訴被告閃亮時尚的網站未經許可使用了原告網站后端源代碼等構成侵權。對此，閃亮時尚抗辯不亂買公司的后端代碼受前端代碼開源協議的傳染，應當遵循GPL協議向所有第三方無償開源。

最高院認為：針對“后端代碼是否受前端代碼開源協議的傳染”，“……前端代碼與后端代碼在展示方式、所用技術、功能分工等上均存在明顯不同，不能因前端代碼與后端代碼之間存在交互配合就認定二者屬于一體”，并基于GPLv3第5條的規定進一步認定“GPL協議的‘傳染性’……不包括與其聯合的其他獨立程序……后端代碼是獨立于前端代碼的其他程序，并不受GPL協議的約束，無需強制開源”。

· 數字天堂vs.柚子科技一案[12]中，原告數字天堂起訴被告柚子科技的API Cloud軟件侵犯了原告HBuilder開發工具軟件中的三個插件。對此，被告抗辯原告的HBuilder軟件中使用了受GPL協議約束的軟件，HBuilder軟件整體被傳染，需要公開源代碼并向用戶授予著作權許可，因此，任何第三方有權在GPL協議授權下使用其代碼并構建衍生軟件作品，被告不侵權。

北京知識產權法院認為：“對于原告涉案三個插件而言，在其所處文件夾中并無GPL開源協議文件，而HBuilder軟件的根目錄下亦不存在GPL開源協議文件的情況下，盡管HBuilder軟件其他文件夾中包含GPL開源協議文件，但該協議對于涉案三個插件并無拘束力，據此，涉案三個插件并不屬于該協議中所指應被開源的衍生產品或修訂版本，二被告認為原告軟件為開源軟件的相關抗辯理由不能成立”。北京市高級人民法院亦認可。

由上述案例可知，GPL的傳染性除了可以作為權利人主張構成侵權或違約的理由，也可能成為被訴侵權人主張不構成侵權的抗辯理由。例如，在羅盒vs.玩友一案中，權利人主張被訴侵權軟件使用了開源代碼，但是未履行開源義務，因而構成侵權；在不亂買vs.閃亮時尚和數字天堂vs.柚子科技兩案中，被控侵權人則抗辯權利軟件使用了開源協議或包含開源代碼，受GPL協議約束，權利軟件被傳染，權利人具有開源義務，因此被控侵權人使用開源代碼不侵犯權利人的著作權。

另外，在網經科技vs.浙江億邦、蘇州啟奧[13]一案中，最高院提及了關于傳染性的判斷因素“關于涉案軟件是否受GPLv2協議約束，該問題涉及底層系統軟件是否受GPLv2協議約束、上層功能軟件是否構成GPLv2協議項下‘獨立且分離的程序’、二者間采用的隔離技術手段、通信方式、通信內容等如何界定以及軟件領域對GPLv2協議傳導性的通常理解與行業管理等因素”。然而，在該案中，最高院并未對GPLv2的傳染性進行認定，而是認為開源系統的衍生軟件是否違反GPL協議需另案判斷，故本文僅簡要介紹并不做深入探討。

4. 使用GPL開源開發工具編寫的軟件是否需要受GPL協議約束

在上述案例中，主要是針對在開源軟件的源代碼基礎上進行再創作而得到的衍生作品的傳染性判斷，例如開源軟件本身或其修改版本的源代碼構成衍生作品的一部分。除此之外，在實踐中還存在使用受GPL協議約束的開源開發工具編寫軟件的情況。其中，開源開發工具本身的作用僅是開發工具，使用者所使用的也僅僅是其開發功能，而不會直接基于開源開發工具的源代碼來獲得衍生作品，換句話說，用其編寫出的衍生軟件作品并不包含開源開發工具的源代碼。這種情況下，根據目前的國內司法案例，傾向于認為“使用開源開發工具編寫的軟件本身不必然地受開源協議的影響”。具體地，

· 天津網城vs.浙江阿凡提[14]一案中，天津網城擁有權利的ShopNC軟件本身系使用開源軟件PHP編寫的，PHP使用Creative Commons Attribution 3.0協議（以下簡稱“CC協議”）。該案的爭議焦點在于：1）根據開源軟件PHP編寫的軟件是否屬于開源軟件；2）PHP軟件手冊自帶的CC協議是否使得ShopNC軟件也應受CC協議傳導而開源。

寧波市中級人民法院認為：“本案兩被上訴人主張著作權保護的ShopNC電商系統計算機軟件由PHP語言編寫，但計算機語言本身具有工具屬性，以特定計算機語言編寫的ShopNC軟件作品通過作者創造性的智力勞動所表現的作品獨創性與計算機語言之間并未體現以后者為基礎的派生關系，故也并非屬于PHP語言演繹作品。即使以演繹作品的角度審查，CC協議的上述開源傳導性，指向的是原作品的演繹作品，涉案ShopNC軟件也并不受軟件手冊CC協議開源義務的約束。”

三、GPL協議的開源合規建議

結合上文對GPL開源協議的分析，我們提供以下開源合規建議供企業參考，以期為企業的風險排查提供思路。

1. 要求和審核權利人的權利基礎

如收到權利人發送的警告函或維權通知，企業應首先要求權利人提供權屬證明材料，包括但不限于，權利人的版權證明材料、權利人對代碼貢獻部分的證明材料等。對于很多外國軟件公司，通常會授權給其中國子公司、分銷商、知識產權代理機構或律所來處理軟件維權事宜，此時企業也應要求其提供權利人的授權材料等，以驗證授權鏈條是否完整。

2. 確認是否適用GPL協議以及具體類型

企業應審查和確認其使用的開源代碼所對應的開源協議類型，如GPL協議中的GPL v2、GPL v3協議，亦或是其他類型的協議，如SSPL、AGPL、BSD、MIT等（對于其他類型的協議，我們將在后續文章中詳細說明）。此外，企業還應厘清其使用的開源協議和開源代碼的對應關系，例如A模塊使用GPL v2協議，B模塊使用BSD協議等。

值得注意的是，有些開源軟件可能包含雙重許可或者多重許可。例如，可以同時適用多種開源協議以及商業許可協議，企業可以結合自身業務特點以及發展情況擇一適用。例如，一些國際知名的軟件公司開發的多個開源軟件可以同時適用LGPL v3、GPL v2或GPL v3開源許可證，使用者可以選擇其一。

3. 自查是否存在違反GPL許可證要求的事項

如企業在開源代碼基礎上進行開發，應結合自身具體的應用場景，判斷是否觸發傳染性條款，是否具有開源義務以及應當開放源代碼的范圍。例如，通常從以下方面進行自查：1）針對使用場景，審查對于開源代碼的使用是否僅限于企業內部，還是會向外部分發；2）針對分發方式，審查是通過軟件副本的方式進行分發，還是通過遠程網絡交互等方式進行調用（如SaaS）；3）針對開源軟件與企業開發的軟件其他部分之間的關系來判斷傳染范圍，例如，可以結合開源代碼與企業開發的軟件其它部分所處的層級框架、顯示方式、功能分工、所處的位置或文件夾、隔離技術手段、通信機制、通信語義等因素進行判斷。

此外，GPL協議還規定了權利恢復期，若被控侵權人確實存在違約，如在一定期限內及時糾正，則授權恢復。

4. 與權利人進行商務談判

企業進行核查后，可根據自身需求，選擇跟權利人進行商務談判，積極溝通，以便盡快解決糾紛，降低對企業商譽的影響。例如，經內部自查后，發現短時間內難以改正所有違反GPL的事項，尤其如果按照傳染性條款的規定，企業需要公開后期開發的源代碼，可能會導致企業失去競爭優勢，也可能導致企業提供的服務或產品受到第三方的惡意篡改和破壞時，企業則可以考慮與權利人進行談判，以通過購買其商業許可的方式解決潛在糾紛。

5. 內部構建開源合規制度

企業應在內部設立開源合規體系，制定開源合規制度，加強開源合規意識，對內部人員進行培訓，明確開源軟件的使用和限制，制定開源合規和風險應對策略。同時，對于企業較為重要的軟件，在開發過程中，應盡量選擇使用那些本身對于商業用途更為友好的開源協議，以降低開源合規風險。

結語

隨著我國計算機行業的飛速發展，開源技術的重要價值日漸凸顯，開源合規也越來越受關注。在眾多的開源協議中，GPL開源協議是開源領域被廣泛使用的協議之一，也是目前司法案例中涉及最多的開源協議。在本文中，我們針對GPL協議進行了詳細解讀，梳理了GPL協議的發展歷程；介紹了對企業影響最為顯著的傳染性條款和開源義務；并結合典型案例，分析和總結了司法實踐關注的要點，以期幫助企業綜合全面的了解使用開源軟件的注意要點及相關法律風險，從而合理制定合規策略以及進行合規核查和整改。

后續我們將陸續對其他開源協議進行詳細解讀和合規分析，例如AGPL、SSPL、LGPL、LLaMA LICENSE AGREEMENT、BigScience RAIL License V1.0等。

*本文首發于知產力

向上滑動閱覽注釋

[1] GNU官網：https://www.gnu.org/

[2] 維基百科：https://en.wikipedia.org/wiki/Tivoization

[3] GNU官網：https://www.gnu.org/licenses/gpl-3.0.en.html

[4] GNU官網：https://www.gnu.org/licenses/gpl-3.0.en.html

[5] (2019)粵73知民初207號民事判決書

[6] 羅瑞雪：《開源協議適用范圍及其對軟件著作權侵權判定的影響》，載于《中國版權》，2020(5)，第89-93頁

[7] Robert Jacobsen v. Matthew Katzer, Kamind Associates, Inc. 535 F. 3d 1373 (2nd Cir. 2008)

[8] (2019)粵03民初3928號、(2021)最高法知民終2063號民事判決書

[9] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/

https://www.zdnet.com/article/linux-beats-internal-legal-threat/

https://zhuanlan.zhihu.com/p/59892331

[10] (2019)粵73知民初207號民事判決書

[11] (2016)京73民初1111號、(2019)最高法知民終663號民事判決書

[12] (2015)京知民初字第631號、(2018)京民終471號民事判決書

[13] (2021)最高法知民終51號民事判決書

[14] (2017)浙02民終3852號民事判決書

作者信息

賈媛媛

爭議解決，知識產權，反壟斷與競爭法

在线观看一区二区三区三州_日韩精品免费播放_日韩中文娱乐网_日韩欧美一区二

GPL協議解讀及合規建議