返回
前言：
隨著全球開源創(chuàng)作內(nèi)容的井噴和開源社區(qū)的不斷發(fā)展，大多數(shù)在生產(chǎn)經(jīng)營活動中開發(fā)和使用計算機(jī)軟件的主體都會不可避免地使用到開源代碼，而如何安全、合規(guī)地使用開源代碼卻甚少得到重視。近年來，開源軟件權(quán)利人在我國境內(nèi)的維權(quán)行動增多，越來越多的企業(yè)希望能夠事先建立完善的開源代碼合規(guī)使用體系，并希望在面對違約/侵權(quán)指控時能夠得到專業(yè)的幫助。本文將從實(shí)務(wù)和現(xiàn)有司法實(shí)踐角度出發(fā)，為開源代碼合規(guī)使用及風(fēng)險處置問題提供一定指引。
一、開源代碼的基本概念與合規(guī)目標(biāo)
（一）基本概念
“開源”，即開放源代碼（Open source code），亦稱為源代碼公開。為避免歧義，本文中的“開源代碼”或“開源軟件”僅用以描述受某種開源協(xié)議（開源許可證）約束，并可以在許可范圍內(nèi)自由使用、復(fù)制、修改和再發(fā)布的代碼。
大量既有文章已經(jīng)對開源代碼的發(fā)展歷史、開源社區(qū)的基本情況、開源協(xié)議的基本類型進(jìn)行了充分的介紹，本文就此內(nèi)容不再贅言，僅以最大化實(shí)現(xiàn)開源代碼價值為目標(biāo)，對企業(yè)的開源合規(guī)和訴訟應(yīng)對問題提供方案指引。
（二）合規(guī)目標(biāo)
企業(yè)進(jìn)行開源代碼合規(guī)建設(shè)的主要意義主要有三：一是實(shí)現(xiàn)合法使用，在降本增效的同時避免各類法律風(fēng)險；二是保證安全，防止因安全漏洞或潛在限制等原因給企業(yè)造成損失；三是方便管理，降低重復(fù)分析、選型帶來巨大的管理成本，同時有效管理開源軟件的生命周期。
二、開源代碼合規(guī)使用方案
（一）開源代碼識別
根據(jù)筆者的實(shí)務(wù)經(jīng)驗，絕大多數(shù)企業(yè)的經(jīng)營管理者實(shí)際上不了解自身開發(fā)或使用的軟件中是否存在第三方開源代碼、存在何種開源代碼。這樣的情況可能是開發(fā)人員隱瞞軟件開發(fā)過程、企業(yè)缺乏軟件開發(fā)和使用過程監(jiān)督、軟件迭代歷史久遠(yuǎn)等原因綜合造成的。那么，如何對既有軟件是否使用了開源軟件進(jìn)行核查與識別，就是開源合規(guī)的首要問題。
一方面，可以利用專業(yè)的第三方工具對現(xiàn)有軟件代碼進(jìn)行核查。市面上常用的此類識別工具有BlackDuck、FOSSID、探方（Scantist SCA）等。此類第三方工具能夠通過掃描源代碼，發(fā)現(xiàn)并確認(rèn)其中存在的開源代碼及其版本、許可證信息，識別準(zhǔn)確率較高。
另一方面，可以人工對軟件根目錄、說明文檔、庫文件名稱等進(jìn)行篩查。大量軟件中嵌入的開源代碼多以獨(dú)立組件形式存在，因此有經(jīng)驗的開發(fā)人員可以查閱軟件根目錄、說明文檔、庫文件名稱等信息，并自行在Github等開源平臺上進(jìn)行比對核查。此種核查方式只適用于軟件開發(fā)過程記錄相對清晰、體量相對較小的軟件，在缺乏其他校驗措施的情況下其結(jié)果難免出現(xiàn)錯漏。
（二）開源代碼盡職調(diào)查
識別開源代碼只是第一步，為了制定完善的開源代碼合規(guī)使用方案，還需要結(jié)合企業(yè)開發(fā)和使用軟件的具體情況，對相關(guān)開源代碼具體信息進(jìn)行盡調(diào)。
盡調(diào)內(nèi)容通常包括：軟件項目名稱、該項目是否存在多個開源代碼、開源代碼名稱及版本、受控的開源協(xié)議、代碼行數(shù)/文件包大小、代碼來源、根目錄License文件、是否對開源代碼進(jìn)行修改及再分發(fā)、該開源組件與主程序的交互方式、該開源組件功能描述及重要性評估、該開源組件是否具有替代方案及替代成本、該項目是否申請專利等。
（三）開源代碼歸類
在完成盡職調(diào)查的基礎(chǔ)上，我們會將全部開源代碼進(jìn)行分類處理，通常而言會根據(jù)開源許可證對修改及再分發(fā)行為的限制程度分為以下三類：
?A類許可證：A類許可證的核心特點(diǎn)是對修改和再分發(fā)行為幾無任何限制（但可能要求修改者對修改的內(nèi)容進(jìn)行聲明），也不強(qiáng)制使用者履行開源義務(wù)。典型的此類許可證包括MIT許可證[1]、BSD許可證[2]（包括2條款版BSD和3條款版BSD）、APACHE 2.0許可證[3]等；
?B類許可證：B類許可證的核心特點(diǎn)是允許使用者將受控代碼與自創(chuàng)代碼（通過動態(tài)鏈接庫、遠(yuǎn)程服務(wù)調(diào)用等方式）分開，僅要求對原受控代碼（可能包括衍生代碼）進(jìn)行開源，典型的此類許可證包括MPL 2.0許可證[4]、EPL 2.0許可證[5]等；
?C類許可證：C類許可證的核心特點(diǎn)是具有極強(qiáng)的“開源傳染性”，即要求使用者將與受控代碼相關(guān)的全部代碼按照本許可證或指定的許可證開源，如GPL3.0許可證[6]等。
如某個許可證內(nèi)容無法被歸類入以上任何一個類別，那么我們將逐字逐句地對該許可證內(nèi)容進(jìn)行分析，尤其關(guān)注其對使用、再分發(fā)行為的要求以及是否強(qiáng)制要求閉源，并在此基礎(chǔ)上針對該開源軟件提出后續(xù)使用建議。
（四）制定《開源軟件管理辦法》
在完成盡調(diào)、歸類和分析的基礎(chǔ)上，我們建議企業(yè)進(jìn)一步制定《開源軟件管理辦法》。《開源軟件管理辦法》不是具體的操作規(guī)范，而是結(jié)合企業(yè)具體情況明確開源軟件管理的意義、運(yùn)行機(jī)制和權(quán)責(zé)規(guī)范。
《開源軟件管理辦法》通常包括：總則（企業(yè)開源軟件管理的意義、涉及部門、名詞定義等）、部門與職責(zé)（需求提出部門-審核與監(jiān)督部門-實(shí)際開發(fā)部門-資產(chǎn)管理部門）、運(yùn)行流程、更新與準(zhǔn)出標(biāo)準(zhǔn)等具體章節(jié)。
（五）編寫《開源軟件使用手冊》
《開源軟件使用手冊》（以下簡稱“《手冊》”）是開源軟件的全流程使用指南，是合規(guī)工作的落地指引。
對于既有軟件而言，《手冊》將明確針對受控于上述A類、B類和C類的開源代碼指明后續(xù)使用方式、整改方式（例如增加開源說明文件、更改動態(tài)鏈接方式等）以及替換退出期限，并以附件形式將不可歸類的開源代碼使用注意事項進(jìn)行標(biāo)注。
對于未來的開源軟件使用需求，《手冊》將明確各類主體（包括需求提出人、軟件開發(fā)人、軟件使用人、軟件審批人、軟件監(jiān)管人等）的職責(zé)，繪制使用管理流程圖，并對各個流程提出規(guī)范指引（例如：在審批環(huán)節(jié)明確非經(jīng)特殊批準(zhǔn)禁止使用C類許可證軟件；在入庫環(huán)節(jié)要求需求提出者注明開源代碼來源和版本、提供鏈接及許可證全文、將未歸類許可證內(nèi)容提交審查等）。
（六）企業(yè)宣貫
上述工作完成后，我們將配合企業(yè)進(jìn)行數(shù)輪的宣貫，尤其注重對軟件開發(fā)人員的培訓(xùn)，有效落實(shí)《手冊》的規(guī)定和要求。
三、開源代碼侵權(quán)警告及訴訟應(yīng)對方案
相比于少量能夠事先建立開源代碼合規(guī)體系和風(fēng)險防范機(jī)制的企業(yè)，更多的企業(yè)往往是在面對權(quán)利人的侵權(quán)指控時才意識到自身可能存在違反開源許可證的行為，那么針對此類風(fēng)向應(yīng)當(dāng)如何處置呢？
（一）開源代碼相關(guān)案例
1、某盒v.某靈案[7]
裁判觀點(diǎn)（最高人民法院）：關(guān)于GPL3.0協(xié)議的性質(zhì)及效力問題。GPL3.0協(xié)議的內(nèi)容具有合同性質(zhì)，開源軟件的發(fā)布可視為要約，用戶使用即為承諾，在用戶使用開源軟件時合同成立……被訴侵權(quán)軟件使用了某盒公司采用GPL3.0協(xié)議發(fā)布的涉案軟件中的源代碼，福建某靈公司對此亦予以確認(rèn)。因此，被訴侵權(quán)軟件應(yīng)當(dāng)遵循GPL3.0協(xié)議，向公眾開放源代碼……被訴侵權(quán)軟件本應(yīng)遵循GPL3.0協(xié)議向用戶開放源代碼，其對于涉案軟件源代碼的使用因后續(xù)未開源而喪失正當(dāng)?shù)臋?quán)利來源基礎(chǔ)，因此某靈公司對涉案軟件源代碼的使用屬于未經(jīng)著作權(quán)人許可而使用其作品的行為，已經(jīng)構(gòu)成對某盒公司涉案軟件著作權(quán)的侵害。
風(fēng)險提示：使用受強(qiáng)傳染性協(xié)議控制的開源代碼時，應(yīng)當(dāng)履行后續(xù)開源義務(wù)，否則可能承擔(dān)包括停止侵權(quán)、賠償損失等在內(nèi)的著作權(quán)侵權(quán)責(zé)任。
2、某拓v.某湘案[8]
裁判觀點(diǎn)（武漢中院）：原告雖然在開源條款中開放其涉案軟件源代碼，公開許可終端用戶免費(fèi)使用其涉案軟件，但在開源條款中，原告明確終端用戶使用其軟件時應(yīng)該保留涉案軟件署名標(biāo)識和版權(quán)鏈接。該協(xié)議不違反我國法律、法規(guī)規(guī)定，軟件作品署名信息和保留鏈接信息應(yīng)受尊重和保護(hù)。原告提交的第三方取證平臺抓取的被訴網(wǎng)站的相關(guān)頁面顯示，被訴網(wǎng)站沒有按照開源協(xié)議限制條款署名原告軟件標(biāo)識和網(wǎng)站尾頁底部版權(quán)聲明鏈接，違反原告涉案軟件開源條款，被訴網(wǎng)站使用涉案軟件行為超出了該軟件開源條款授權(quán)許可范圍，侵害原告涉案軟件署名權(quán)。
風(fēng)險提示：對開源代碼進(jìn)行使用時，如違反開源許可證明確約定的義務(wù)，則可能構(gòu)成侵權(quán)。
3、任某v.某致案[9]
裁判觀點(diǎn)（最高人民法院）：涉案軟件源代碼被上傳至GitHub網(wǎng)站，任某對此解釋為：其出于保存源代碼的考慮在開發(fā)初期將源代碼同步保存在GitHub網(wǎng)站……雖然某致公司主張其從未授權(quán)任某公開涉案軟件的源代碼，但是沒有證據(jù)表明某致公司內(nèi)部對于軟件源代碼的保存設(shè)有規(guī)章制度。某致公司對于員工開發(fā)軟件等工作行為也應(yīng)當(dāng)進(jìn)行相應(yīng)的日常管理，但某致公司在整個軟件開發(fā)過程中對于任某的行為沒有提出異議，某致公司當(dāng)時對任衛(wèi)的行為很可能持默許態(tài)度，至少持放任態(tài)度，某致公司本身對此具有明顯過錯。訴訟發(fā)生后任某在一審開庭審理前已經(jīng)刪除了GitHub網(wǎng)站上的源代碼，及時制止了損害結(jié)果。據(jù)此，本院認(rèn)定任某對于開發(fā)工作中出于工作需要將涉案軟件源代碼上傳至GitHub網(wǎng)站并導(dǎo)致源代碼被公開，并無明顯過失，更不存在故意或重大過失，對某致公司并不構(gòu)成侵權(quán)。
風(fēng)險提示：公司應(yīng)制定完善的軟件開發(fā)、管理制度，否則需要自行承擔(dān)公司資產(chǎn)受到的損失（例如源代碼被公開）。
（二）風(fēng)險應(yīng)對建議
1、核查權(quán)利人侵權(quán)警告內(nèi)容是否屬實(shí)
根據(jù)筆者經(jīng)驗，部分權(quán)利人在發(fā)出侵權(quán)警告時存在并不審慎乃至警告錯誤的情況。例如，某些開源軟件存在多個版本且受控許可證不同，權(quán)利人在發(fā)現(xiàn)軟件中包含某一名稱的開源組件便以使用人違反了GPL協(xié)議的傳染性為由主張侵權(quán)，但實(shí)際上該特定版本的組件并不受GPL協(xié)議控制。
此外，部分軟件權(quán)利人通過設(shè)置軟件“后門”的方式獲取所謂的“侵權(quán)證據(jù)”，且侵權(quán)警告函中拒不說明證據(jù)的來源和具體內(nèi)容，被警告人無從具體查證。
上述情況多發(fā)于部分采取“廣撒網(wǎng)”方式進(jìn)行維權(quán)的主體，此類警告大多“沒有后文”。 我們建議企業(yè)核查權(quán)利人侵權(quán)警告是否屬實(shí)，如警告不實(shí)或無法查證，可書面回函澄清或要求權(quán)利人提供完整的證據(jù)材料。如權(quán)利人發(fā)出的侵權(quán)警告確有錯誤且已經(jīng)對企業(yè)的生產(chǎn)經(jīng)營造成影響，也可以考慮主動提起確認(rèn)不侵權(quán)之訴。
2、確認(rèn)具體使用行為是否違反了開源許可證條款
需要澄清的是，絕大部分的開源許可證并不限制“商業(yè)使用”。即使以限制最嚴(yán)格的GPL協(xié)議為例，在使用人沒有修改、將受控源代碼編入新程序的情況下，使用人在商業(yè)場景中使用受控于GPL協(xié)議的軟件并不構(gòu)成侵權(quán)。
因此，在面對侵權(quán)警告或訴訟時，實(shí)際使用人應(yīng)當(dāng)仔細(xì)核查開源許可證的權(quán)利義務(wù)要求，并分析實(shí)際使用行為是否超出了授權(quán)范圍或違反了其他義務(wù)。
3、核查開發(fā)者鏈條和許可證鏈條
面對侵權(quán)警告或訴訟時，實(shí)際使用人應(yīng)當(dāng)仔細(xì)核對其使用的開源軟件版本信息和開發(fā)歷史。如實(shí)際使用部分并非警告人或原告創(chuàng)作的，此時警告人或原告不應(yīng)就該部分向?qū)嶋H使用人主張權(quán)利。
此外，實(shí)際使用人還應(yīng)當(dāng)就被控開源軟件的許可證鏈條（如有）進(jìn)行核查。如果警告人或原告本身也是在既有開源代碼的基礎(chǔ)上進(jìn)行二次創(chuàng)作的，而其又將創(chuàng)作成果以違反原許可證的條件進(jìn)行分發(fā)甚至閉源，那么警告人或原告可能并不享有相應(yīng)的警告權(quán)利或請求權(quán)基礎(chǔ)。
4、盡快修正使用行為以重新滿足許可證要求
如確實(shí)在使用過程中違反了開源許可證的要求，我們建議實(shí)際使用人盡快修正其使用行為。有些情況下，實(shí)際使用人只需要通過諸如增加版權(quán)說明或者修改庫文件調(diào)用方式等手段就可以更正其違約/侵權(quán)行為。但是，就此前已經(jīng)發(fā)生的違約/侵權(quán)行為，實(shí)際使用人的責(zé)任不能就此完全免除。
此外，實(shí)務(wù)中存在大量以下情況：權(quán)利人開發(fā)某款工具類軟件后，推出商用付費(fèi)版和非商用開源版兩個版本，且非商用開源版往往根據(jù)GPL 3.0等C類許可證進(jìn)行發(fā)布。實(shí)際使用人使用了上述非商用開源版組件進(jìn)行軟件開發(fā)，程序開發(fā)完畢后卻沒有按照許可證的要求開源，最終開源組件的權(quán)利人警告或起訴，索要極高的賠償金。此種情況下，實(shí)際使用人可以在權(quán)衡獨(dú)立研發(fā)成本、替代軟件可行性等因素的情況下，主動購買該軟件的商用付費(fèi)版。
5、主動替換高風(fēng)險開源代碼
使用開源代碼可能產(chǎn)生的風(fēng)險包括但不限于：因開源協(xié)議傳染性導(dǎo)致自主研發(fā)軟件無法實(shí)現(xiàn)商業(yè)價值的風(fēng)險、專利限制風(fēng)險、安全漏洞風(fēng)險、因違反許可證要求導(dǎo)致的違約/侵權(quán)風(fēng)險等。
在開源合規(guī)梳理和風(fēng)險應(yīng)對的過程中，企業(yè)應(yīng)當(dāng)明確自身的“不可承受之重”，對于可能給企業(yè)帶來無法承受風(fēng)險的開源代碼，應(yīng)當(dāng)盡早進(jìn)行替換。
以上內(nèi)容是筆者結(jié)合自身實(shí)務(wù)經(jīng)驗及現(xiàn)有司法實(shí)踐歸納總結(jié)的開源代碼合規(guī)使用及風(fēng)險方案，謹(jǐn)供讀者參考。針對不同企業(yè)、不同軟件客體的實(shí)際情況，相關(guān)使用合規(guī)及風(fēng)險處置方案需要進(jìn)一步豐富和調(diào)整。如有任何問題，歡迎與筆者聯(lián)系。
[1]https://www.mit-license.org/
[2]https://opensource.org/licenses/BSD-2-Clause；[3]https://opensource.org/licenses/BSD-3-Clause
[4]https://www.apache.org/licenses/LICENSE-2.0
[5]https://www.mozilla.org/en-US/MPL/2.0/
[6]https://www.eclipse.org/legal/epl-2.0/
[7]https://www.gnu.org/licenses/gpl-3.0.en.html
[8]參見（2021）最高法知民終2063號民事判決書。
[9]參見（2022）鄂01知民初2520號民事判決書。
[10]參見（2021）最高法知民終1246號民事判決書。
律師簡介
姜軍 律師
北京云亭律師事務(wù)所合伙人
手機(jī)：18810666024
電話：010 59449968
郵箱：jiangjun@yuntinglaw.com
姜軍是中國執(zhí)業(yè)律師，畢業(yè)于北京大學(xué)法學(xué)院。加入云亭前，姜軍律師曾經(jīng)在某頂級紅圈律師事務(wù)所北京辦公室工作六年。姜軍律師的執(zhí)業(yè)領(lǐng)域包括知識產(chǎn)權(quán)、民商事爭議解決、公司業(yè)務(wù)及家事與財富管理。姜軍律師處理了大量具有典型意義或疑難復(fù)雜的訴訟/仲裁案件，其代理的多個案件獲評為各級法院典型案例。
