開源軟件社區貢獻者維權的法律問題
——以德國 “McHardy v.Geniatech” 案為視角

劉海虹

（上海外國語大學法學院，上海 200083）

自1998 年開源組織OSI 正式提出 “開源” 理念以來，通過海量用戶和開發者匯聚創意、檢查漏洞的 “集市” 開發模式①Eric S.Raymond 在其著作《大教堂與集市》中將開源軟件的開發模式描述為 “集市” 模式。RAYMOND E，The Cathedral&the Bazaar:Musings on Linux and Open Source by an Accidental Revolutionary.O’Reilly&Associates,Inc.,2001.極大推動了軟件產業的發展。在數字網絡技術持續發展的背景下，全球對開源的熱情不減，開源項目數量持續攀升。2021年3月， “支持數字技術開源社區等創新聯合體發展，完善開源知識產權和法律體系，鼓勵企業開放軟件源代碼、硬件設計和應用服務” 首次被明確寫入國家 “十四五” 規劃②《中華人民共和國國民經濟和社會發展第十四個五年規劃和2035年遠景目標綱要》。，2021年10月 “完善開源知識產權和法律體系” 又被列為 “十四五” 國家知識產權保護工作重點③《 “十四五” 國家知識產權保護和運用規劃》。。

我國司法實踐中涉及開源軟件的早期糾紛主要表現為利用開源軟件的二次開發者被訴侵犯原告軟件著作權時以 “涉案軟件使用了開源代碼” 作為抗辯。在這些案件④主要案件如：天津市網城天創科技有限責任公司等訴溫嶺市達克羅涂復工業有限公司等侵害計算機軟件著作權糾紛案，一審案號：（2016）浙1081民初3924號，二審案號：（2017）浙10民終1825號；柚子（北京）科技有限公司等與數字天堂（北京）網絡技術有限公司侵犯計算機軟件著作權糾紛案，案號：(2018)京民終471號； “京閃亮時尚信息技術有限公司訴不亂買電子商務（北京）有限公司侵害計算機軟件著作權糾紛案，案號：（2019）最高法知民終663號。中，法院均以證據不足不予支持，但均認可了GPL 開源協議的效力。2019 年，濟寧羅盒網絡科技有限公司分別在廣州、深圳向兩家使用其開源軟件的公司發起了侵權之訴⑤濟寧市羅盒網絡科技有限公司訴福建風靈創景科技有限公司等侵害計算機軟件著作權糾紛案，案號：(2019)粵03 民初3928 號；濟寧市羅盒網絡科技有限公司訴廣州市玩友網絡科技有限公司等侵害計算機軟件著作權糾紛案，案號：（2019）粵73知民初207號。，開啟了我國開源軟件著作權人維權的司法實踐。

開源軟件的維權案中原告是否有起訴資格取決于開源軟件的著作權歸屬，開源軟件的開發是一種開放協作，大型開源項目的開發一般都涉及眾多社區貢獻者，其著作權權屬的認定更為復雜。除了開源項目的發起人之外，作為開源軟件開發的重要參與者，開源社區貢獻者是否也有權就開源軟件單獨維權？開源軟件社區貢獻者的維權還會涉及哪些法律問題？

在過去幾年，一名Linux 內核Netfilter 的代碼貢獻者Patrick McHardy，在德國頻頻向涉嫌違規使用者發出警告函，提出他們分發含有Netfilter 軟件的行為沒有提供源代碼，違反了GPLv2 許可協議[1]。 收到警告函的不少企業選擇支付一定金額的費用達成和解，有報道稱，他在18 個月內利用這樣的維權從多家企業獲得超過200 萬歐元的 “賠償”[2]。 Patrick McHardy 的維權引發了廣泛爭議，也招致Netfilter 項目的公開反對[3]，被不少開源精神的捍衛者稱為 “版權流氓” （copyright troll）。2017年7月，Patrick購買了中國深圳Geniatech 公司的歐洲代理商Geniatech Europe GmbH 銷售的包含Linux Netfilter 軟件的衛星電視接收器，以該公司未按照GPLv2的規定開放源代碼侵犯其著作權為由向科隆地區法院申請對Geniatech Europe GmbH 簽發臨時禁令。針對法院做出臨時禁令的裁決⑥Landgericht k?ln：14 O 188/17.，被申請人提起上訴。2018 年3 月7 日，Patrick 在德國科隆高等地區法院舉行的口頭聽證會上撤訴，聽證中的爭議焦點集中在開源軟件社區貢獻者的訴訟資格及發送警告函維權的正當性問題⑦臨時禁令申請上訴口頭聽證會內容及相關專家證據等由于原告撤訴均未公開發布，參見德國知名的開源軟件專家Herald Welte 撰寫的聽證會綜述：WELTE H. Report from the Geniatech vs. McHardy GPL violation court hearing.http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/.最后訪問時間：2022年9月12日。。

我國目前尚無開源軟件社區貢獻者的維權實踐，以下以 “McHardy v. Geniatech” 案為切入點，從開源軟件開發的特點與開源軟件 “開發者” 的推定，開源軟件的著作權歸屬與社區貢獻者的維權資格，以及開源軟件社區貢獻者維權的正當性邊界等幾方面結合我國相關法律對開源軟件社區貢獻者維權的法律問題予以論述。

一、開源軟件開發的特點與開源軟件 “開發者” 的推定

根據《中華人民共和國著作權法》（以下簡稱《著作權法》）的規定，著作權屬于作者，軟件著作權屬于軟件開發者⑧《中華人民共和國著作權法》（2020）第11條，《計算機軟件保護條例》（2013）第9條。。 因此，認定計算機軟件著作權歸屬的根本在于 “計算機軟件的開發” 。從法律上講受著作權法保護的計算機軟件是以指令、文字、符號等表達的計算機程序及其有關文檔；而從技術上講，計算機軟件的本質是 “以計算為工具實現應用目標的解決方案”[4]，它是對人腦思維形成的問題解決方案的計算機語言表達。實踐中，軟件開發（software development）是一個體系化的創作過程，其核心是涵蓋軟件生命周期過程模型以及軟件開發中采用的方法[5], 隨著開發技術的發展，完成這個方案的過程模型也在不斷發展，但一般均包括問題定義、需求分析、設計、編碼、測試、維護等一系列的創作過程[6]。

（一）開源軟件開發的特點

開源軟件的開發與傳統軟件開發最大的區別在于源代碼開放，眾多軟件用戶都可以直接參與軟件的測試、維護和改進。開源軟件的協作開發是一個復雜的動態創作過程，開發人員的組成、分工、能力等會發生經常性的改變，在技術上利用 “標簽” 、代碼管理系統等工具高效分類、索引、整合眾多參與者的代碼創作活動，在人員管理上通過組織架構促進參與者有效分工和提高協作效率。

1.開源軟件開發的動態技術過程及其法律意義

首先，開源項目發起人會選擇一個開源社區平臺發起開源項目，將項目原型程序（Origin）的初始源代碼在開源社區發布。這是開源軟件開發的啟動階段，目的是吸引用戶使用項目原型程序。與普通軟件開發不同的是，開源軟件的開發不是由用戶提出需求的按需開發，而是將可以滿足用戶某些需求的原型程序直接提供給用戶使用。為了吸引用戶的使用和引導用戶結合自己的使用場景積極參與項目反饋，開源項目發起人一般都會在發起項目時就向社區用戶明確項目的意圖、預期的目標、要解決的關鍵問題等。

其次，開源軟件在社區開源發布之后，社區用戶通過使用對項目原型程序的初始源代碼進行測試，對缺陷予以修改，或者根據特定場景的需求編寫實現新功能的代碼等，即社區協作開發。為了防止互相干擾，提高協作同開發效率，大部分開源項目都是采取分支管理代碼的方式開展協作開發。分支管理開發有不同的模式，常見的有主干開發模式（Trunk Based Development）和特性分支開發模式（Feature Branch Development）。主干開發模式是指所有的開發人員僅在一個主線（master）上進行協作開發，一般不允許新建其他長期存在的開發分支，所有的代碼提交均需要在主線上完成。特性分支開發模式是指為一個或多個特定的需求/缺陷/任務創建代碼分支（branch），在其上完成相應的開發后，把它合并（merge）到主線的開發模式⑨https://cn.trunkbaseddevelopment.com/.。

開源軟件社區用戶的代碼貢獻既涉及開源項目原型程序的測試和修改，也有新特性的開發。一些復雜的開源軟件項目采取的是多分支并行開發模式，即同時存在一個主線和多個分支，不同的分支各自獨立，具有不同的開發目的。社區用戶在相關分支上提交代碼，可以請求將其貢獻的代碼合并到主線（pull request），提交的補丁程序或實現新特性的代碼是否符合項目的預期目需要同行評審。如果通過審核并最終被合并到主線上，就會形成開源軟件的 “主線版本” ；未被納入主線的 “分支版本” 如果未被刪除則可以獨立存在。

最后，開源軟件的社區協作開發是 “連續、循環進行的迭代” 。社區用戶的修改早期是通過錯誤報告郵件列表（bug report mailing list）提交，隨著技術的發展，修訂控制系統（Revision Control System，RCS）、版本控制系統（Version Control System，VCS）和代碼管理系統等開發支持工具不斷迭代更新，社區用戶工作的完整歷史記錄得以便捷地存檔，提高了開源社區用戶共同參與協同開發的效率。主線版本和分支版本各自會不斷優化迭代升級，每一個軟件版本可能包含對上一個版本所含bug( 軟件缺陷) 的修復，也可能包含新添加的功能。在每次發布新的軟件版本時，軟件項目的管理團隊需要在綜合考慮軟件的穩定性以及任務緊迫性的前提下，決定是否需要把某些特定改動加入到本次發布計劃中[7]。

以 “McHardy v. Geniatech” 案爭議的開源項目Linux 內核的開發為例，它是由Linus Torvalds 開發的Linux開源項目原型程序，雖然僅是完整Linux系統中較小的一部分軟件，但它是確定該系統運行不可或缺的核心，于1991 年10 月5 日正式發布v.0.0.2 版本。最初社區用戶提交的代碼是通過郵件列表等提交審核，由Linus Torvalds 決定是否納入源代碼庫，后來，該項目采用了更先進的Git分布式版本控制系統實現多分支的平行開發。Linux 內核共有五個分支：mainline 分支、mm 分支、next 分支、stable 分支和staging 分支⑩mainline分支是主線，記錄了進入主線的所有代碼修改、提交記錄，Linux內核的每個發布版本都是以主線為基礎的；mm分支是對所有提交到mainline 分支的子系統代碼進行整合測試的；next 分支是一個自動化整合測試分支，每天自動拉取兩百多個子系統分支代碼；stable 分支的目的則是對已經發布的正式版本進行后續維護；而staging 分支則用來存放那些不足以進入mainline分支的獨立的文件系統或驅動代碼。。社區用戶首先通過郵件列表討論分支中正在測試的代碼，發現代碼問題之后，用戶將其編寫的新代碼或代碼修改提交到相應的分支，由分支的維護人員進行單獨測試，然后再確定是否進一步集成到mm分支或next 分支中進行整合測試；接著由Linus Torvalds 決定從幾個主要測試分支上拉取沒有問題的代碼到主線；最后Linus Torvalds 基于主線上集成的代碼發布新的Linux內核版本。

頻繁地發布、修改、提交，迭代是開源軟件開發過程的最大特點，在這個動態過程中社區貢獻者也是流動的，開發者流失與對應程序包丟棄、被接管等也普遍存在[8]。在開源軟件社區貢獻者維權時，首先需要在事實上界定開源軟件的二次使用人使用的是哪個版本的程序，在法律上需要認定維權者的貢獻是否構成著作權法意義上的 “開發” 。

2.開源軟件開發的組織架構與參與者署名問題

從技術上講，開源項目的社區協作開發活動的核心是代碼編寫、提交、審核及合并，在利用分支管理模式的軟件開發核心活動中，通常包括以下角色：項目維護者、分支/模塊維護者、普通開發者。項目維護者的主要工作內容是合并分支、發布版本；模塊維護者的主要工作內容是審核代碼、合入代碼；開發者的主要工作內容是編寫代碼、提交代碼[9]。當然，這些角色并非一成不變，如果項目小，可能并不區分模塊，就不需要模塊維護者。但是，廣義上講，開源社區用戶的 “貢獻” 除了代碼之外，還包括各種其他活動。比如回答新手的問題，對發布的新版本進行測試并反饋問題，對開源源代碼進行復核并發表意見，以及與代碼完全無關的外圍支持，如操作界面的外語翻譯，數據類型錯誤或者數據丟失的缺陷報告等。

為了確保上述參與者的協作開發高效運行，實踐中較為復雜的開源項目會形成包括項目發起人、核心開發者團隊和社區貢獻者的梯層組織結構對應承擔上述角色。在開源項目的社區協作開發中通常項目維護者的角色由項目發起人承擔，分支/模塊維護者一般都是核心開發者，眾多社區用戶作為普通開發者以貢獻代碼的方式參與開發。開源軟件社區還會確立各種人員管理機制，比如，社區成員成為貢獻者的機制（如基于貢獻度PR數，或基于開發者投票等），核心團隊的產生機制，開發過程中的溝通機制（如通過郵件列表溝通）及參與開發者在管理開發過程的分工機制等。

以Linux 開源項目為例，由于其內核最初是由Linus Torvalds 發起并全權負責的，隨著項目的發展逐漸確立了社區貢獻者、核心開發團隊和發起人的協作開發組織架構。社區用戶提交的補丁程序需要首先在郵件列表中通過同行評審和更廣泛的測試，分支的核心開發者1Greg Koroah Hartman,Andrew Morton,Stephen Rothwell,David S.Miller 等都是Linux 內核發布后5 年內加入的核心開發人員，分別負責領導上述Linux內核分支的維護。負責決定是否將補丁納入分支版本。但是，所有的代碼最終都要通Linus Torvalds的審查，他對進入內核的代碼擁有最終決定權[10]。Git 數據包記錄著Linux 內核開發過程中社區每次代碼修改、審核提交和版本發布的信息；此外，Linux 內核發布版本的C 文件的注釋里標有該版本文件的作者和重要修改者信息（姓名、郵箱等）；在Linux 內核發布版本中有一個文件名為Maintainer 的文件，維護者的信息均記錄在這個文件里。版本控制系統記錄中的署名或作為核心開發者的署名在法律上有什么意義呢？

（二）開源軟件開發者的推定

從法律上而言，為開源項目開發做出貢獻的社區用戶是否能構成開源軟件開發者應依據著作權法的相關規定來認定。我國《計算機軟件保護條例》第九條規定：軟件著作權屬于軟件開發者，本條例另有規定的除外。如無相反證明，在軟件上署名的自然人、法人或者其他組織為開發者。德國著作權法也有相同的規定2《德國著作權法》第十條。。 在 “McHardy v. Geniatech” 案中，爭議的開源軟件Netfilter 是Linux 內核中的一個可以執行各種網絡功能的實用程序，Patrick 自2013 年擔任Netfilter 核心開發團隊的負責人，直到2016 年都是Netfilter 核心開發團隊的成員。McHardy 向科隆地區法院請求臨時禁令（einstweilige Verfuegung），禁止的內容是很寬泛的，包括禁止被告向公眾提供Linux 內核軟件，銷售含有Linux 內核軟件的產品及在其網站上提供Linux 內核軟件的下載鏈接、程序文檔的下載等。科隆地區法院在初審裁決中基于Patrick 已經證明其作為Netfilter 核心開發團隊的負責人（head of the netfilter core team）身份及Linux 內核網絡堆棧維護者（subsystem maintainer）身份，認定其長期參與Linux內核的開發，因此他具有申請臨時禁令的資格。但是，科隆高等地區法院在上訴口頭聽證會認為不能依據 “核心開發團隊的負責人” 以及分支版本維護者的署名直接推定其為 “開發者” ；審核過大量的 “補丁” 以及決定是否將補丁并入也不意味著其對這些補丁享有著作權，必須根據該程序的開發方式和過程明確其貢獻的法律性質。

開源軟件版本控制系統的記錄是通過技術管理開發過程和版本發布，項目開發的組織架構則側重高效組織協作開發中參與者的活動。比如，核心開發團隊的成員可能并未實際參與核心的代碼提交和審核活動。因此，這些署名不能與軟件著作權登記中的開發者署名等同，在法律上并不能根據這樣的 “署名” 推定被署名者為軟件開發者。

二、開源軟件著作權的歸屬與社區貢獻者的維權資格

由于開源項目軟件的版本是不斷迭代的，在認定社區用戶貢獻的法律性質時，必須首先明確其主張的版本。在典型的開源軟件 “集市開發” 模式下，發起人發布的項目初始原型是由其單獨開發完成的初始版本，發起人對其單獨享有著作權，社區用戶對初始版本沒有任何貢獻，不能對初始版本主張權利。社區用戶的參與主要涉及對初始版本的不斷改進，對于其參與改進的版本，其貢獻可能涉及著作權法上的合作開發和改編。

（一）合作開發者的認定

在 “McHardy v. Geniatech” 案中，證據顯示Linux內核是由Linus Torvalds 獨立開發完成之后再向社區發布的，雖然后續有超過15 000 的社區開發者參與改進，僅就Linux 內核初始版本的開發而言，Linus Torvalds對其單獨享有著作權。臨時禁令的被申請人否認Patrick 提起臨時禁令申請的資格，請求法院駁回禁令申請，因為他既不是Linux 內核的合作作者（Miturheber），也不是Linux 內核網絡堆棧或組件Netfilter的合作作者。

主審法官認為并不是所有對Linux內核做出貢獻的人都可以主張自己是整個程序的合作作者，應根據德國著作權法的相關規定結合Patrick 的具體貢獻，認定其是否為Linux 內核的合作作者。根據《德國著作權法》第八條的規定，如果多人共同創作了一部作品，并且各自創作的部分不能被分開使用，他們就是該作品的合作作者。社區貢獻者能否被認定為德國著作權法規定的合作作者取決于其與其他開發者是否有共同創作的合意，其貢獻是否滿足作品獨創性的要求，以及其創作的部分與其他合作者創作的部分是否具有不可分割性。

首先，需要認定社區貢獻者與發起人和核心開發團隊是否存在改進版本的共同創作合意。根據分支管理代碼的方式，由項目發起人或核心開發團隊創建主線，社區用戶可以基于主線創建其自己的分支并自行修改維護。社區用戶申請 “同行評審” 由項目管理者（發起人或核心團隊相關人員）根據項目發起人的開發意圖做出取舍決定是否將其分支中的修改合并入主線。這個過程表明項目發起人、核心團隊和貢獻代碼的用戶之間是存在合作開發改進版本的合意。如果社區用戶并不申請將其創作的代碼并入主線，或者并未通過同行評審及項目管理者的最終決定被并入主線，就不應該認定其存在合作開發的合意。

其次，還需要認定社區用戶的貢獻是否具有獨創性。回答新手的問題，對發布的新版本進行測試并反饋問題，對開源源代碼進行復核并發表意見等社區用戶的貢獻均難以被認定具有 “獨創性” ；而提交代碼的補丁一般可以認定為具有獨創性。根據德國著作權法的規定，這些代碼需具有獨創性，還需要被合并到主線成為開源軟件不可分割的部分，才能認定該社區貢獻者具有合作作者的法律地位。

德國法關于合作開發軟件的規定與我國的相關規定相似，不同的是我國《計算機軟件保護條例》規定合作開發的軟件著作權可以由合作開發者書面約定，若無約定的，須區分可分割使用的軟件和不可分割使用的軟件，確定著作權行使規則3《計算機軟件保護條例》第十條。。 但是對于如何認定合作開發者，計算機軟件保護條例并沒有明確規定，應依據著作權法關于合作作者的規定來認定，即合作作者之間要有共同創作的合意，合作作者的貢獻應為著作權法規定的創作，即有獨創性。無論不同合作作者創作完成的部分之間是否可以分割使用，均可以構成合作作品。

（二）改編者的認定

對于未被納入主線的 “分支版本” 如果未被刪除則可以獨立存在，分支版本是基于開源軟件源代碼的初始版本所做的修改，該修改依據開源協議是經過授權的4Section 2 of GPL V.2 provides:You may modify your copy or copies of the Program or any portion of it,thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions.。 根據《德國著作權法》第三條的規定屬于對既有作品的改編（Bearbeitung），如果改編具有獨創性，改編者對分支版本享有獨立的著作權，但同時應遵守開源協議的相關條款規定。當然，開源軟件社區開發的實踐中，分支版本的開發者常常很多，分支版本也可能被認定為合作開發的軟件。還要進一步分析主張著作權的社區貢獻者貢獻的代碼是否具有獨創性，以確定其是否為分支版本改編作品的共同開發者。

在 “McHardy v. Geniatech” 案中，Patrick主張他在參與Linux 社區開發的多年間，一共編寫了約50 000行代碼，并提交了一張帶有修改日志的CD 作為證據。但是，科隆高等地區法院認為這并不足以證明這些代碼均受著作權法保護。根據口頭聽證會上專家證人Greg Kroah Hartman 提交的宣誓證據[11]，Linux內核2.5.12 版由Linus Torvolds 于2002 年4 月30 日發布,在貢獻者記錄中沒有證據5Patrick對Linux內核所做明確貢獻的首個記錄是在2002年4月23日,最后訪問時間：2015年11月24日。表明Patrick 對內核2.4.18 和2.5.12 版之前的版本做出過任何代碼貢獻。因此，科隆高等地區法院裁定，Linux 內核開發模式不支持Patrick作為Linux 內核合作作者的主張，他充其量僅是改編者。

（三）社區貢獻者的維權資格

如果社區貢獻者被認定為共同開發者或改編作品的共同開發者，他是否可以對他人違規使用合作開發版本和改編版本的行為以自己的名義來提起侵權之訴呢？ “McHardy v. Geniatech” 案中，二審法院認為Patrick 作為改編者僅擁有其自己貢獻的代碼的著作權，但不擁有整個Linux 內核的著作權。他有權向法院申請臨時禁令，但是范圍僅限于其享有著作權的部分，他沒有資格就整個Linux 內核的著作權申請臨時禁令。在上訴法院的口頭聽證會后，Patrick撤回了禁令申請。

開源軟件的社區貢獻者在我國維權的話，根據我國《計算機軟件保護條例》的規定6第十條...合作開發者對其共同開發的軟件著作權歸屬沒有約定或約定不明的，合作開發的軟件可以分割使用的，開發者對各自開發的部分可以單獨享有著作權；但是，行使著作權時，不得擴展到合作開發的軟件整體的著作權。合作開發的軟件不能分割使用的，其著作權由各合作開發者共同享有，通過協商一致行使；不能協商一致，又無正當理由的，任何一方不得阻止他方行使除轉讓權以外的其他權利，但是所得收益應當合理分配給所有合作開發者。，如果他是分支版本的唯一作者，就可以單獨就分支版本提起訴訟；如果他僅為分支版本的合作作者，或是主線版本的合作作者，我國現行《著作權法》對合作作者訴權行使未作規定。司法實踐中，合作作品侵權之訴的被告常以單獨起訴的合作作者未經其他合作作者授權為由，提出其沒有起訴資格的抗辯。對此，有的法院認為合作作者不可以單獨起訴，必須取得其他合作作者授權才享有起訴的資格7浙江省杭州市中級人民法院民事裁定書(2009)浙杭知初字第365號。；有的法院認為可以依據《著作權法實施條例》第九條（現著作權法第十四條第二款）有關合作作品著作權行使的規定，合作作者之間就起訴應協商一致，如果未能達成一致起訴的決定，沒有正當理由，其他合作作者不得阻止主張起訴的作者單獨起訴8(2015)浦民三(知)初字第60號。；還有的法院認為合作作者可以單獨起訴9(2011)豫法民三終字第19號。。 針對這一實踐中的問題，2014 年公布的《著作權法（修訂草案送審稿）》第十七條第四款0《著作權法（修訂草案送審稿）》（2014）第十七條第四款 “他人侵犯合作作品著作權的，任何合作作者可以以自己的名義提起訴訟，但其所獲得的賠償應當合理分配給所有合作作者” 。規定合作作者可單獨行使其訴權，但這一規定并未被2020 年著作權法第三次修正案采納。

在濟寧羅盒網絡科技有限公司提起的兩起侵權訴訟案中，對于作為共同著作權人的發起人的維權資格，法院考慮開源軟件社區開發中發起人與社區貢獻者的角色不同，認為發起人因公開開源項目的初始版源代碼具備主張著作權的基礎，同時又在軟件研發過程中的創造性勞動最多，此外還考慮維權若要分散各地的社區貢獻者一致同意是不現實的，最終認定發起人具有起訴資格。但按照這個裁判思路，社區貢獻者在軟件開發過程中并非都是貢獻創造性勞動較多，可能很難具有單獨起訴的資格。

即使社區貢獻者沒有單獨起訴的資格，如果以向違規使用者發送侵權警告函的形式維權又有什么問題呢？

三、開源軟件社區貢獻者維權的正當性邊界

如上所述，開源軟件的開發雖然具有與非開源軟件不同的特點，但同樣受著作權保護，只是著作權人通過開源許可協議保障了所有用戶自由使用軟件的權利1一般開源許可協議均授予所有用戶自由地復制、修改和分發開源軟件程序的權利。；但是開源許可協議通常也規定了用戶使用軟件的義務。開源軟件許可協議大致可以分為 “copyleft” ， “寬松” 或 “弱copyleft” 兩類。 “McHardy v.Geniatech” 案所涉開源許可協議為GPLv2 屬于copyleft 類型。GPLv2 下開源軟件使用者的核心義務是承諾繼續開源，即任何基于copyleft 程序衍生開發的作品必須以與原程序相同的copyleft許可協議授予許可，這就是所謂的copyleft 的 “遺傳效應” 或 “傳染性”2為使用戶能夠自由地學習、修改和共享，所有的GPL 程序用戶在獲得二進制或可執行代碼后，都有權要求分發人提供完整對應源碼(Complete and corresponding source code,簡稱C&CS)。如果完整對應源碼未與二進制代碼一起分發，則需要附隨一份書面要約（即表示愿意提供完整對應源碼的書面聲明），無論使用何種介質分發軟件均是如此。要求分發者提供或表示愿意提供C&CS 是保護用戶權利的基本要求。參見Eben Moglen,Mishi Choudhary,Software Freedom Law Center Guide to GPL Compliance, 2nd Edition (2014), https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.pdf,最后訪問時間：2022年7月8日。。 copyleft 開源軟件項目的目標在于確保每個用戶都有權自由地修復bugs、提升性能和二次使用代碼，保障實現開源軟件開發者開發軟件的意圖。開源軟件的使用者不遵守上述開源許可協議的行為都意味著用戶權利的損失。比如，如果使用開源軟件的二次開發者未向其用戶提供其產品中所含copyleft 軟件及適用許可條款等必要信息，該二次開發產品的用戶就無法通過可靠方式獲取copyleft 軟件的源代碼。因此，開源社區鼓勵以非訴的方式督促使用者遵守開源許可協議的規定，而不是尋求訴訟或賠償。

但是，Patrick McHardy 的維權之所以備受爭議不僅在于其維權資格存在瑕疵，還在于他向80多家3由于不少公司做出的停止侵害聲明都規定了保密條款，Patrick具體向多少家公司發送過警告函并沒有準確的數字，也有報道稱50多家。公司發了警告函，利用維權獲得大量賠償金。Patrick利用警告函獲得賠償金的維權固然與德國法下警告函的性質有關，但也暴露出開源軟件社區貢獻者維權的正當性邊界問題。

（一）知識產權侵權警告的法律性質與侵權警告的正當性

我國相關法律法規中沒有明確規定 “知識產權侵權警告” 的概念，對于知識產權侵權警告的法律性質存在不同的觀點。 “權利行使論” 認為發送侵權警告函是知識產權人行使其權利的行為，否定警告者的責任[12]；但是，我國司法實踐中有法院認定發送警告函是一種維護自身權益的行為4在理邦案的二審中，法院認為 “邁瑞公司作為相關專利產品的專利權人，針對涉嫌侵權產品的銷售者發出要求停止侵權的警告，是采取合法手段維護自身權益的正當行為” 。該案案號為最高人民法院(2015)民申字第191號。。對于 “維護自身權益的行為” 是不是構成自力救濟，學者們均認同其具有自力救濟的色彩，但并非民法典明確規定的自力救濟行為[13]。 因此，發送知識產權警告函不應像自力救濟那樣以存在危害請求權的實現且依靠公力救濟仍無法避免為前提，其正當性的空間應該更大一些。也有學者認為， “警告函在性質上應被視為簽訂服從合同而發出的要約。在警告函中，警告人要求被警告人作出以違約金作擔保的停止侵權的承諾，但不能要求賠償損失。”[14]但是，《德國著作權法》第97a條規定著作權人可以通過警告函（Abmahnung）和自愿接受懲罰（Unterwerfungerklaerung）的非訴方式行使請求權。警告函一般都會要求違規使用者將來不再從事侵權行為，并允許被警告者做出 “停止侵害聲明” 終結雙方糾紛，即聲明如果再次侵權便自愿支付適當金額的懲罰金。這也帶來了濫用警告函進行營利性維權的風險。

根據德國法規定，這種警告函構成 “以締結自愿接受懲罰合同為目的而做出的《德國民法典》第145條意義上的要約（Antrag）”[15]。 如果被警告的違規使用者作出了自愿接受懲罰的聲明，著作權人就對其將來的侵權行為獲得了一種以合同罰金作為擔保的合同請求權保護。由于停止侵害聲明可能還會包含保密的要求，例如：限制權利人尋求其他侵權人的支持或向社區公開權利人的權利主張，接收到Patrick 警告函的大多數公司為了避免可能被訴和侵權行為在社區被公開都會對警告函作出回應，并作出自愿接受懲罰的 “停止侵害聲明” 。被警告的違規使用者如果不履行合規義務，存在繼續或重復侵權行為，就對發出警告函的權利人負有支付懲罰金的合同義務。發出警告函的權利人可以直接向法院請求被警告的違規使用者履行該合同義務。

根據德國法的相關規定，警告函的目的在于消除侵權人重復侵權的危險，使著作權人能夠在不借助法院的幫助下對侵權行為進行迅速而有效的防御。但是，由于停止侵害聲明具有合同性質，警告函也存在被濫用的可能。比如，警告者并非被侵權內容的著作權人，或者盡管警告者對被侵權內容享有著作權，但是首個警告函并不詳細列出所有已知的侵權行為；此外，還有要求眾多被警告者簽署寬泛的停止侵權聲明，超出警告者著作權保護的范圍等。Patrick向眾多公司發出警告函要求他們停止分發含有Linux內核產品的維權就存在上述問題。由于許多公司作出的停止侵害聲明中均有保密的要求，Patrick的集中維權并沒有及時引起關注，因而，他通過發送警告函的方式獲得了大量的損害賠償金，直到被警告的Geniatech Europe GmbH 拒絕作出自愿接受懲罰停止侵害的聲明。

對于知識產權人發送侵權警告函的正當性，我國最高法院在 “理邦” 案的再審判決中指出：通常要根據權利人的權利狀況、警告內容及發送的意圖、對象、方式、范圍等多種因素進行綜合判斷5最高人民法院(2015)民申字第191號。。 如上所述開源軟件的開發涉及眾多社區貢獻者，其貢獻可能被認定為共同開發或改編，且所涉開源軟件的版本也需要根據具體情況來確定，社區貢獻者發送警告函的行為在權利狀況、警告內容、警告范圍等方面均可能存在瑕疵，超出正常范圍。被警告者在回應警告函時應及時尋求專業法律意見，謹慎作出停止侵害的承諾。

（二）GPLv2 開源協議自動終止條款的濫用風險與侵權警告的正當性

侵權警告的目的是認定警告正當性的重要考量因素，開源軟件社區貢獻者發送警告函的目的是維護自身權益，還是 “勒索” 賠償金并不容易認定。根據開源許可協議，使用開源軟件的二次開發者對軟件源代碼的獲取和使用本來就是自由的，大部分開源軟件著作權人的維權是為了督促使用者履行開源軟件許可協議中開放衍生作品源代碼的義務。為了約束使用人，GPLv2 第4 節規定了自動終止條款，即使用者如果違背開源協議條款，則自動終止許可。這樣，使用者如果想重新獲得分發的權利，必須獲得著作權人的重新授權。

盡管開源社區的著作權人對于依據侵權人的請求恢復分發權一直持合作態度，但這也給像Patrick這樣以維權營利的人提供了索要巨額費用才同意恢復權利的機會。Patrick 在向科隆地區法院申請禁令之前，就通過Email 直接終止了Geniatech Europe GmbH 在GPLv2 下的權利。但是，德國相關判例6Landgericht Muechen:21 O 6123/04,Welte/Sitecom Deutschland GmbH.對GPLv2 第4 節的解釋是：GPLv2 下的許可并不因使用者的侵權而自動終止，侵權人可以通過接受和遵守許可協議規定的合規行為隨時獲得權利。 這一做法本身進一步證明Patrick 維權的目的不是督促違規使用者合規，而是索要賠償金。

對于這一存在潛在濫用風險的條款，GPLv3 協議進行修改，將GPLv2 中的 “如果違反條款將自動終止許可” 規定改為 “如果是首次違反條款，則可在一定時期內自我修正，并自動恢復許可證所授予的權利” 這一修改與之前德國法院判例中的解釋是一致的，根據該修改，違規使用者在首次收到警告函之后只要及時糾正違規使用行為就不必擔心被維權營利者終止權利了。

對于Patrick 版權流氓式的維權，包括軟件自由保護組織在內的各種社區成員一直努力試圖說服其改變策略，經過漫長的交涉，Linux內核的核心團隊終于在2021 年12 月27 日就Linux 內核的維權問題在德國曼海姆地區法院與Patrick 達成和解。雙方共同承諾未經Linux 內核Netfilter 核心團隊的大多數活躍成員事先同意不得自行通過發送警告函等方式就適用GNU 開源許可協議的軟件著作權（包括共同著作權或改編著作權）侵權維權或強制違規使用者合規。

四、結語

“McHardy v. Geniatech” 案具有其特殊性，但是該案也暴露出開源軟件社區貢獻者維權中的問題。德國法院對開源軟件社區貢獻者申請禁令的資格及發送警告函維權的正當邊界的意見對于開源軟件在我國的司法保護仍具有重要的參考意義。

2021 年，GitHub 上的中國用戶數達到755 萬人，實際參與到開源項目中的開發者僅占32%[16]，開源軟件開發者維權的案件剛剛出現。在濟寧羅盒網絡科技有限公司提起的兩起侵權訴訟案中，被告均對原告的起訴資格提出挑戰，認為原告主張被侵權的軟件源代碼是開源代碼，而參與編寫該開源代碼的有32 人，作為原告股東的項目發起人僅為合作開發軟件的共同著作權人。該案的判決中法官最終認可發起人的起訴資格，理由是發起人在開源平臺公開初始版源代碼具備主張著作權的基礎，且在軟件研發過程中的創造性勞動最多；此外，開源項目的貢獻者人數眾多、互不相識又身居世界各地，且隨著項目修改處于持續增加、變動之中，若要全體一致同意，實則導致維權無從提起。

可見，我國目前涉及開源軟件的司法實踐中保護軟件研發的創造性勞動是基本核心，無論是開源項目的發起人還是社區貢獻者，判斷其是否具有維權資格，均應依據《著作權法》和《軟件著作權保護條例》的規定，結合其在開發中的具體貢獻來認定。根據開源軟件分支管理代碼的開發方式，主線版本與分支版本的著作權歸屬應區別對待。社區用戶編寫的代碼具有獨創性并提交審核被納入主線版本的，該社區貢獻者可以認定為主線版本的共同著作權人；未經過審核被納入主線版本的分支版本是基于開源軟件初始版本的改編作品，如果社區貢獻者是分支版本的唯一開發者，就可以單獨就分支版本維權。作為主線版本及分支版本共同開發者的社區貢獻者，應根據共同著作權人行使著作權的規定維權。

但是，侵權訴訟一向是開源軟件權利人維權的最終法律解決機制，督促開源軟件使用人合規才是其根本目標。為了解放開源軟件開發者所面臨的維權負擔，捍衛 “自由、協作、共享” 的開源精神，提高開源軟件使用人的合規意識，自由軟件基金會(FSF)這類托管機構開始設立，還有軟件自由法律中心(SFLC) 、軟件自由保護組織(SFC）和GPL-violations.org 這些專門為開源社區提供法律服務的機構。他們經開源軟件著作權人授權，代理其維權。一般情況下他們先對投訴情況進行全面調查并核實，然后再與明顯違規的當事人聯系，通過協商或發送警告函的方式要求違規者糾正違規行為；對于沒有糾正的違規者，上述機構也曾代理權利人提起侵權訴訟。

目前，我國的開源基金會僅有2020 年成立的開放原子開源基金會，通過接受捐贈和獲得授權管理開源項目。為避免社區貢獻者自行營利性維權，應借鑒國外著名的開源社區的經驗，鼓勵開源軟件社區管理組織確立以公開為原則、激勵合規為導向的社區投訴和維權規則。同時，應加強開源軟件社區管理組織或開源軟件基金會在法律救濟中的地位，明確他們的法律地位，便于他們更有效參與開源軟件著作權的維權。