開源軟件社區(qū)貢獻(xiàn)者維權(quán)的法律問題
——以德國 “McHardy v.Geniatech” 案為視角

劉海虹

（上海外國語大學(xué)法學(xué)院，上海 200083）

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

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

開源軟件的維權(quán)案中原告是否有起訴資格取決于開源軟件的著作權(quán)歸屬，開源軟件的開發(fā)是一種開放協(xié)作，大型開源項(xiàng)目的開發(fā)一般都涉及眾多社區(qū)貢獻(xiàn)者，其著作權(quán)權(quán)屬的認(rèn)定更為復(fù)雜。除了開源項(xiàng)目的發(fā)起人之外，作為開源軟件開發(fā)的重要參與者，開源社區(qū)貢獻(xiàn)者是否也有權(quán)就開源軟件單獨(dú)維權(quán)？開源軟件社區(qū)貢獻(xiàn)者的維權(quán)還會(huì)涉及哪些法律問題？

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

我國目前尚無開源軟件社區(qū)貢獻(xiàn)者的維權(quán)實(shí)踐，以下以 “McHardy v. Geniatech” 案為切入點(diǎn)，從開源軟件開發(fā)的特點(diǎn)與開源軟件 “開發(fā)者” 的推定，開源軟件的著作權(quán)歸屬與社區(qū)貢獻(xiàn)者的維權(quán)資格，以及開源軟件社區(qū)貢獻(xiàn)者維權(quán)的正當(dāng)性邊界等幾方面結(jié)合我國相關(guān)法律對(duì)開源軟件社區(qū)貢獻(xiàn)者維權(quán)的法律問題予以論述。

一、開源軟件開發(fā)的特點(diǎn)與開源軟件 “開發(fā)者” 的推定

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

（一）開源軟件開發(fā)的特點(diǎn)

開源軟件的開發(fā)與傳統(tǒng)軟件開發(fā)最大的區(qū)別在于源代碼開放，眾多軟件用戶都可以直接參與軟件的測(cè)試、維護(hù)和改進(jìn)。開源軟件的協(xié)作開發(fā)是一個(gè)復(fù)雜的動(dòng)態(tài)創(chuàng)作過程，開發(fā)人員的組成、分工、能力等會(huì)發(fā)生經(jīng)常性的改變，在技術(shù)上利用 “標(biāo)簽” 、代碼管理系統(tǒng)等工具高效分類、索引、整合眾多參與者的代碼創(chuàng)作活動(dòng)，在人員管理上通過組織架構(gòu)促進(jìn)參與者有效分工和提高協(xié)作效率。

1.開源軟件開發(fā)的動(dòng)態(tài)技術(shù)過程及其法律意義

首先，開源項(xiàng)目發(fā)起人會(huì)選擇一個(gè)開源社區(qū)平臺(tái)發(fā)起開源項(xiàng)目，將項(xiàng)目原型程序（Origin）的初始源代碼在開源社區(qū)發(fā)布。這是開源軟件開發(fā)的啟動(dòng)階段，目的是吸引用戶使用項(xiàng)目原型程序。與普通軟件開發(fā)不同的是，開源軟件的開發(fā)不是由用戶提出需求的按需開發(fā)，而是將可以滿足用戶某些需求的原型程序直接提供給用戶使用。為了吸引用戶的使用和引導(dǎo)用戶結(jié)合自己的使用場(chǎng)景積極參與項(xiàng)目反饋，開源項(xiàng)目發(fā)起人一般都會(huì)在發(fā)起項(xiàng)目時(shí)就向社區(qū)用戶明確項(xiàng)目的意圖、預(yù)期的目標(biāo)、要解決的關(guān)鍵問題等。

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

開源軟件社區(qū)用戶的代碼貢獻(xiàn)既涉及開源項(xiàng)目原型程序的測(cè)試和修改，也有新特性的開發(fā)。一些復(fù)雜的開源軟件項(xiàng)目采取的是多分支并行開發(fā)模式，即同時(shí)存在一個(gè)主線和多個(gè)分支，不同的分支各自獨(dú)立，具有不同的開發(fā)目的。社區(qū)用戶在相關(guān)分支上提交代碼，可以請(qǐng)求將其貢獻(xiàn)的代碼合并到主線（pull request），提交的補(bǔ)丁程序或?qū)崿F(xiàn)新特性的代碼是否符合項(xiàng)目的預(yù)期目需要同行評(píng)審。如果通過審核并最終被合并到主線上，就會(huì)形成開源軟件的 “主線版本” ；未被納入主線的 “分支版本” 如果未被刪除則可以獨(dú)立存在。

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

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

頻繁地發(fā)布、修改、提交，迭代是開源軟件開發(fā)過程的最大特點(diǎn)，在這個(gè)動(dòng)態(tài)過程中社區(qū)貢獻(xiàn)者也是流動(dòng)的，開發(fā)者流失與對(duì)應(yīng)程序包丟棄、被接管等也普遍存在[8]。在開源軟件社區(qū)貢獻(xiàn)者維權(quán)時(shí)，首先需要在事實(shí)上界定開源軟件的二次使用人使用的是哪個(gè)版本的程序，在法律上需要認(rèn)定維權(quán)者的貢獻(xiàn)是否構(gòu)成著作權(quán)法意義上的 “開發(fā)” 。

2.開源軟件開發(fā)的組織架構(gòu)與參與者署名問題

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

為了確保上述參與者的協(xié)作開發(fā)高效運(yùn)行，實(shí)踐中較為復(fù)雜的開源項(xiàng)目會(huì)形成包括項(xiàng)目發(fā)起人、核心開發(fā)者團(tuán)隊(duì)和社區(qū)貢獻(xiàn)者的梯層組織結(jié)構(gòu)對(duì)應(yīng)承擔(dān)上述角色。在開源項(xiàng)目的社區(qū)協(xié)作開發(fā)中通常項(xiàng)目維護(hù)者的角色由項(xiàng)目發(fā)起人承擔(dān)，分支/模塊維護(hù)者一般都是核心開發(fā)者，眾多社區(qū)用戶作為普通開發(fā)者以貢獻(xiàn)代碼的方式參與開發(fā)。開源軟件社區(qū)還會(huì)確立各種人員管理機(jī)制，比如，社區(qū)成員成為貢獻(xiàn)者的機(jī)制（如基于貢獻(xiàn)度PR數(shù)，或基于開發(fā)者投票等），核心團(tuán)隊(duì)的產(chǎn)生機(jī)制，開發(fā)過程中的溝通機(jī)制（如通過郵件列表溝通）及參與開發(fā)者在管理開發(fā)過程的分工機(jī)制等。

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

（二）開源軟件開發(fā)者的推定

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

開源軟件版本控制系統(tǒng)的記錄是通過技術(shù)管理開發(fā)過程和版本發(fā)布，項(xiàng)目開發(fā)的組織架構(gòu)則側(cè)重高效組織協(xié)作開發(fā)中參與者的活動(dòng)。比如，核心開發(fā)團(tuán)隊(duì)的成員可能并未實(shí)際參與核心的代碼提交和審核活動(dòng)。因此，這些署名不能與軟件著作權(quán)登記中的開發(fā)者署名等同，在法律上并不能根據(jù)這樣的 “署名” 推定被署名者為軟件開發(fā)者。

二、開源軟件著作權(quán)的歸屬與社區(qū)貢獻(xiàn)者的維權(quán)資格

由于開源項(xiàng)目軟件的版本是不斷迭代的，在認(rèn)定社區(qū)用戶貢獻(xiàn)的法律性質(zhì)時(shí)，必須首先明確其主張的版本。在典型的開源軟件 “集市開發(fā)” 模式下，發(fā)起人發(fā)布的項(xiàng)目初始原型是由其單獨(dú)開發(fā)完成的初始版本，發(fā)起人對(duì)其單獨(dú)享有著作權(quán)，社區(qū)用戶對(duì)初始版本沒有任何貢獻(xiàn)，不能對(duì)初始版本主張權(quán)利。社區(qū)用戶的參與主要涉及對(duì)初始版本的不斷改進(jìn)，對(duì)于其參與改進(jìn)的版本，其貢獻(xiàn)可能涉及著作權(quán)法上的合作開發(fā)和改編。

（一）合作開發(fā)者的認(rèn)定

在 “McHardy v. Geniatech” 案中，證據(jù)顯示Linux內(nèi)核是由Linus Torvalds 獨(dú)立開發(fā)完成之后再向社區(qū)發(fā)布的，雖然后續(xù)有超過15 000 的社區(qū)開發(fā)者參與改進(jìn)，僅就Linux 內(nèi)核初始版本的開發(fā)而言，Linus Torvalds對(duì)其單獨(dú)享有著作權(quán)。臨時(shí)禁令的被申請(qǐng)人否認(rèn)Patrick 提起臨時(shí)禁令申請(qǐng)的資格，請(qǐng)求法院駁回禁令申請(qǐng)，因?yàn)樗炔皇荓inux 內(nèi)核的合作作者（Miturheber），也不是Linux 內(nèi)核網(wǎng)絡(luò)堆?；蚪M件Netfilter的合作作者。

主審法官認(rèn)為并不是所有對(duì)Linux內(nèi)核做出貢獻(xiàn)的人都可以主張自己是整個(gè)程序的合作作者，應(yīng)根據(jù)德國著作權(quán)法的相關(guān)規(guī)定結(jié)合Patrick 的具體貢獻(xiàn)，認(rèn)定其是否為Linux 內(nèi)核的合作作者。根據(jù)《德國著作權(quán)法》第八條的規(guī)定，如果多人共同創(chuàng)作了一部作品，并且各自創(chuàng)作的部分不能被分開使用，他們就是該作品的合作作者。社區(qū)貢獻(xiàn)者能否被認(rèn)定為德國著作權(quán)法規(guī)定的合作作者取決于其與其他開發(fā)者是否有共同創(chuàng)作的合意，其貢獻(xiàn)是否滿足作品獨(dú)創(chuàng)性的要求，以及其創(chuàng)作的部分與其他合作者創(chuàng)作的部分是否具有不可分割性。

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

其次，還需要認(rèn)定社區(qū)用戶的貢獻(xiàn)是否具有獨(dú)創(chuàng)性?；卮鹦率值膯栴}，對(duì)發(fā)布的新版本進(jìn)行測(cè)試并反饋問題，對(duì)開源源代碼進(jìn)行復(fù)核并發(fā)表意見等社區(qū)用戶的貢獻(xiàn)均難以被認(rèn)定具有 “獨(dú)創(chuàng)性” ；而提交代碼的補(bǔ)丁一般可以認(rèn)定為具有獨(dú)創(chuàng)性。根據(jù)德國著作權(quán)法的規(guī)定，這些代碼需具有獨(dú)創(chuàng)性，還需要被合并到主線成為開源軟件不可分割的部分，才能認(rèn)定該社區(qū)貢獻(xiàn)者具有合作作者的法律地位。

德國法關(guān)于合作開發(fā)軟件的規(guī)定與我國的相關(guān)規(guī)定相似，不同的是我國《計(jì)算機(jī)軟件保護(hù)條例》規(guī)定合作開發(fā)的軟件著作權(quán)可以由合作開發(fā)者書面約定，若無約定的，須區(qū)分可分割使用的軟件和不可分割使用的軟件，確定著作權(quán)行使規(guī)則3《計(jì)算機(jī)軟件保護(hù)條例》第十條。。 但是對(duì)于如何認(rèn)定合作開發(fā)者，計(jì)算機(jī)軟件保護(hù)條例并沒有明確規(guī)定，應(yīng)依據(jù)著作權(quán)法關(guān)于合作作者的規(guī)定來認(rèn)定，即合作作者之間要有共同創(chuàng)作的合意，合作作者的貢獻(xiàn)應(yīng)為著作權(quán)法規(guī)定的創(chuàng)作，即有獨(dú)創(chuàng)性。無論不同合作作者創(chuàng)作完成的部分之間是否可以分割使用，均可以構(gòu)成合作作品。

（二）改編者的認(rèn)定

對(duì)于未被納入主線的 “分支版本” 如果未被刪除則可以獨(dú)立存在，分支版本是基于開源軟件源代碼的初始版本所做的修改，該修改依據(jù)開源協(xié)議是經(jīng)過授權(quán)的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.。 根據(jù)《德國著作權(quán)法》第三條的規(guī)定屬于對(duì)既有作品的改編（Bearbeitung），如果改編具有獨(dú)創(chuàng)性，改編者對(duì)分支版本享有獨(dú)立的著作權(quán)，但同時(shí)應(yīng)遵守開源協(xié)議的相關(guān)條款規(guī)定。當(dāng)然，開源軟件社區(qū)開發(fā)的實(shí)踐中，分支版本的開發(fā)者常常很多，分支版本也可能被認(rèn)定為合作開發(fā)的軟件。還要進(jìn)一步分析主張著作權(quán)的社區(qū)貢獻(xiàn)者貢獻(xiàn)的代碼是否具有獨(dú)創(chuàng)性，以確定其是否為分支版本改編作品的共同開發(fā)者。

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

（三）社區(qū)貢獻(xiàn)者的維權(quán)資格

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

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

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

即使社區(qū)貢獻(xiàn)者沒有單獨(dú)起訴的資格，如果以向違規(guī)使用者發(fā)送侵權(quán)警告函的形式維權(quán)又有什么問題呢？

三、開源軟件社區(qū)貢獻(xiàn)者維權(quán)的正當(dāng)性邊界

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

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

（一）知識(shí)產(chǎn)權(quán)侵權(quán)警告的法律性質(zhì)與侵權(quán)警告的正當(dāng)性

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

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

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

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

（二）GPLv2 開源協(xié)議自動(dòng)終止條款的濫用風(fēng)險(xiǎn)與侵權(quán)警告的正當(dāng)性

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

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

對(duì)于這一存在潛在濫用風(fēng)險(xiǎn)的條款，GPLv3 協(xié)議進(jìn)行修改，將GPLv2 中的 “如果違反條款將自動(dòng)終止許可” 規(guī)定改為 “如果是首次違反條款，則可在一定時(shí)期內(nèi)自我修正，并自動(dòng)恢復(fù)許可證所授予的權(quán)利” 這一修改與之前德國法院判例中的解釋是一致的，根據(jù)該修改，違規(guī)使用者在首次收到警告函之后只要及時(shí)糾正違規(guī)使用行為就不必?fù)?dān)心被維權(quán)營利者終止權(quán)利了。

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

四、結(jié)語

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

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

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

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

目前，我國的開源基金會(huì)僅有2020 年成立的開放原子開源基金會(huì)，通過接受捐贈(zèng)和獲得授權(quán)管理開源項(xiàng)目。為避免社區(qū)貢獻(xiàn)者自行營利性維權(quán)，應(yīng)借鑒國外著名的開源社區(qū)的經(jīng)驗(yàn)，鼓勵(lì)開源軟件社區(qū)管理組織確立以公開為原則、激勵(lì)合規(guī)為導(dǎo)向的社區(qū)投訴和維權(quán)規(guī)則。同時(shí)，應(yīng)加強(qiáng)開源軟件社區(qū)管理組織或開源軟件基金會(huì)在法律救濟(jì)中的地位，明確他們的法律地位，便于他們更有效參與開源軟件著作權(quán)的維權(quán)。