編者按
開源運動是席捲軟體開發行業的一股浪潮，開源以自由、開放、協作的精神，吸引來自全球的優秀軟體開發人員，給世界貢獻了海量優質程式碼。境內軟體開發企業在開發過程中，可充分利用開源軟體提升開發效率和質量。但同時，因大量開源軟體的權利人來源於境外，且其中不乏訴訟能力極強的跨國企業，境內企業在使用開源軟體時若不慎違反了開源許可證的要求，可能會因此引發來自境外的侵權訴訟風險。本文以GPLv3開源許可證為例，提出了企業面臨的過度傳染和程式碼侵權兩種主要風險，並分別對兩種風險提出了防範建議。本文榮獲第三屆「金陵律師論壇」論文一等獎。
目 錄
一、引言
二、GPL概述及法律屬性
三、GPL v3的主要內容
四、GPL v3項下的主要風險及防範
五、結語
一、引 言
開源軟體是指對使用者開放源程式碼，並且使用者可自由使用、複製、修改和分發的一類軟體[注1]，此類軟體的作者大多反對軟體著作權的僵化保護，更加強調軟體的自由、開放、共享與協作。當前最具影響力的開源組織自由軟體基金會由理查德·斯特曼（Richard Stallman）於1985年成立，經過數十年的發展，開源軟體的規模已經空前龐大，全球最大的軟體項目託管平臺GitHub上已彙集了8300餘萬個人、4百餘萬機構參與開源軟體開發，共產生了2億餘個開源程式碼倉庫（Repositories）[注2]。國際諮詢根據公司高德納（Gartner）等機構的研究資料顯示，當前99%的商業軟體含有開源元件，75%則直接由開源程式碼組成[注3]。在版權保護問題上一向保守的微軟公司也在2014年10月20日公開宣佈「擁抱開源」。截止2021年底，微軟公司成為GitHub上總活躍度第一的公司，Google位居第二，亞馬遜、IBM、Adobe等大型網際網路公司活躍度也名列前茅[注4]。
國內軟體開發行業同樣大量依靠開源社區的成果，大到作業系統級的（如國產作業系統紅旗Linux和華為鴻蒙作業系統）[注5]，小到軟體開發工作者日常使用的各類類庫[注6]，開源軟體幾乎已經成為了軟體工作者必備的基礎資源。「不要重複發明輪子（Stop Trying to Reinvent the Wheel）」也成為了軟體從業者們的入行第一課。在軟體開發行業中，使用前人已經公開、開放的成果並不是一件可恥的事，反而是一件備受推崇的行業共識。開源的理念與思想雖然形式上看與傳統的版權保護思想背道而馳，卻實現了版權制度設立的初衷，實現了促進人類知識的繁榮與進步。
開源軟體所主張的自由，並非絕對的自由。「開源許可證」就是這種自由所帶的枷鎖，開發人員在使用開源軟體時需遵循許可證制定的規則，否則就可能喪失授權。但是現實情況是，國內大量軟體從業人員並不具備相應的法律知識，且開源意識淡薄，面對冗長、繁雜的開源許可協議條款一般難以準確把握其規則，國內企業在使用開源軟體時可能因違反開源協議進而侵犯他人版權的隱患。
目前國際上通行的主要開源許可證從總體上可分為寬鬆式（permissive）和責任傳播式（copyleft）兩類。前者如Apache-2.0許可證，對商業應用較為友好，使用者可自由將衍生作品作為開源或閉源軟體發佈，開發者使用時一般只需遵守一定的署名、聲明等規則後便可自由使用，侵權風險較小。後者如GNU General Public License（以下簡稱「GPL」），適用該協議發佈的開源軟體在使用時附有大量的限制，在進行商業軟體開發時需高度小心，如稍有不慎，則可能構成對軟體作者的侵權。加上目前開源社區中如微軟、Google、Adobe等大型跨國公司均為高度活躍使用者，一旦違反許可證的要求，侵犯了這些有極強訴訟能力的機構使用者的權益，可能會引發較大的跨境訴訟風險，給開發者及所屬公司造成嚴重損失。本文擬以GPL為例，對開源程式碼使用的主要法律風險進行分析，並對其防範提出建議。
二、GPL概述及法律屬性
(一) GPL概述
GPL許可證是一個許可證家族的泛稱，是一個被廣泛使用的自由軟體許可協議條款，按照GPL官網提供的資訊，大部分GNU（一種開源作業系統）的程序和超過一半的自由軟體使用GPL許可證[注7]。
GPL許可證允許任何收到軟體副本的人自由使用該軟體，但隨之而來的代價是任何基於以GPL許可證發佈的軟體（以下簡稱「GPL軟體」）的衍生出的軟體，在二次分發時，都必須以GPL分發，這一特性也被稱為GPL許可證的「傳染性」。比如說，如果一個開發者使用了一個200行的GPL軟體源程式碼，並將這200行融入到了自己20000行的大型軟體中形成了一個20200行的新軟體。那麼這個新軟體也必須按照GPL發佈，雖然原先使用的GPL軟體程式碼僅佔比不足1%，但整個軟體也都受到了傳染，使用人必須按照GPL的約定完整公開源程式碼，並允許所有人自由使用。
該協議目前主要有GPL v2和GPL v3兩個版本，GPL v2版本於1989年發佈，後因其存在一定的漏洞（如不能防止使用者在軟硬結合系統中，通過對硬體的限制阻礙軟體的修改和傳播），自由軟體基金會於2007年發佈GPL v3版本。除填補以上漏洞之外，GPL v3的兼容性也得到了加強。由於新版本的GPL許可證受到了包括Linux創始人林納斯·託瓦茲（Linus Torvalds）在內的開源界巨頭反對，最終各方在協議的升級上達成了妥協，一部分開源組織和企業執行升級版GPL v3，另一部分則繼續執行GPL v2[注8]，造成了目前兩版本許可證並行的局面，自由軟體基金會也允許使用者自由選擇適用的版本[注9]。由於兩許可證存在一定差異，本文後續內容以GPL v3為例進行討論。
(二) 因GPL而產生糾紛的法律適用
在美國，GPL存在單純許可或是合同的性質之爭。該性質對GPL在美國的實施至關重要。如認為GPL構成合同，則需按照美國各州合同法處理，如認為GPL為單純許可，則根據聯邦統一的《版權法》相關規則處理，經過長時間的爭論，GPL應當屬於《版權法》調整的許可行為逐漸成為美國通說[注10]。
而在我國，由於境內法律並不區分許可和合同，所以前述爭論並不那麼必要，即便是境外主體對境內主體提出的訴訟，根據《涉外民事關係法律適用法》的規定，也應當適用侵權行為地即中國法。因此可按照中國的合同法律規範對GPL進行解釋。下文為簡便表述，對雙方基於GPL而成立的許可合同法律關係簡稱為GPL合同或GPL合同法律關係。
(三) GPL合同的成立與生效
在中國法下，一個GPL合同需有當事人明示或默示的要約與承諾方才能夠成立。在典型的應用場景中，開發者從GitHub上下載軟體程式碼時，GitHub均會醒目展示該程式碼適用的開源許可證類型。GPL本身也要求發佈者完整發布GPL許可證文字。因此公開展示的許可證文字可視為要約。使用者在看到明示的許可證文字後仍繼續使用的行為，可視為承諾，雙方據此成立GPL合同法律關係，該合同依法在成立時生效。使用者依據GPL享有複製、修改、分發軟體的授權，同時必須遵守GPL明確約定的相關義務。在被譽為國內「GPL第一案」的濟寧市羅盒網路科技有限公司與廣州市玩友網路科技有限公司等侵害計算機軟體著作權糾紛案（以下簡稱「羅盒案」）中，法院對合同的成立與生效即採用了此種觀點。[注11]同時，根據GPL的約定，在出現特定情形之前，GPL合同不可撤銷不可終止。即一旦授權即為永久授權。
三、GPL v3的主要內容
GPL v3主要由引言（Preamble）、術語和條件（Terms and Conditions）以及附錄三部分組成。
(一) 引言主要內容
GPL的引言介紹了GPL即促進軟體的自由傳播的精神與目的。引言也同時強調GPL並不否認著作權，也不要求作者放棄著作權。相反，GPL正是通過對著作權的肯定，來確保所有取得作品的人，因受到上游作者著作權的威懾，而不得不繼續以GPL載明的模式向下傳播作品。正是這種模式，使得GPL成為當今世界影響力最大的開源許可證之一。
另外，引言部分特別指出，GPL所強調的自由（Free）不等同於免費（Free of Charge）。使用人在使用GPL軟體時，可以收費，亦可以免費，這也是「自由使用」的體現。
(二) GPL被許可方享有的自由
術語和條件部分的第2、3和規定了版權許可的有關內容，簡而言之即授予被許可方四項自由：這組許可證授予使用人以下四項自由：（1）自由運行軟體；（2）自由學習和修改軟體源程式碼；（3）自由再發布軟體複製；（4）自由發佈修改後的軟體版本[注12]；同時第2條還明確，這一授權是不可撤銷的授權。
(三) 被許可方享有自由的限制
術語和條件部分的第4、5、6條規定了行為的限制，這三條即為判斷被許可方是否違反GPL的核心條款。
第4條規定了被許可方原樣複製GPL軟體源程式碼並傳播的前提：（1）保留原軟體中所有關於GPL及限制條款的內容；（2）完整附上GPL的正文；（3）發佈原作者著作權標識；（4）開放源程式碼；（5）保留所有原作者的免責聲明。第4條第2款對GPL軟體的收費進行了規定，即可以在提供軟體副本時收費（下載收費、光碟收費等），也可以在為軟體提供服務支持和質量擔保時收取費用。
第5條則在第4條的基礎上，規定了以原始碼形式傳播修改後的GPL軟體的前提條件，被許可方除需滿足第4條規定的所有條件之外，還需要做到以下幾點：（1）明確地標識出軟體已經被修改，並標明修改時間；（2）無論最終軟體如何封裝，修改後的整個軟體仍必須以GPL傳播，不得以其他方式傳播，並且需要顯著地標識本軟體受GPL約束，並保留所有限制條款。第5條即賦予GPL傳染性的核心條款。另外，第5條第2款規定了獨立軟體不受傳染的特例。即如果兩個軟體在本質上是相互獨立的，則可不適用GPL繼續傳播，這也是各大軟體企業避免產品受到GPL過度傳染的重要手段，具體方式會在後文詳述。
第6條則規定了以非源程式碼形式傳播作品時的要求。由於開放源程式碼是「開源」的基本要求，所以如果被許可方以非源程式碼形式傳播作品時，必須以其他形式提供源程式碼，如提供相應的物理媒介（如光碟等），或提供可以獲取源程式碼的地址等等。
GPL的4、5、6三條，以層層遞進的方式，建立了了被許可方使用GPL軟體並二次傳播時所必須遵守的行為準則體系。其核心要求可以概括為三個方面：（1）明確聲明軟體繼續適用GPL傳播；（2）開放源程式碼並允許他人自由使用；（3）保留原作者版權聲明和免責聲明。
(四) 授權終止、治癒以及永久終結
GPLv3第8條則規定了當被許可方違反規定後授權的自動終止以及治癒條款。被許可方違反GPL的行為，將導致許可自動終止。隨著許可合同的終止，被許可方使用軟體作品的行為則失去了合法權利來源，構成了對作者版權的侵犯，這也是境內企業在使用GPL軟體時所面臨的最大風險。
另外，關於該自動終止的法律定性，應屬附解除條件的法律行為中所附條件，而不應被解釋為《民法典》中合同的需經過通知的約定解除權。具體來說，根據GPL文義的要求，此處的授權終止並不需要許可方一方向被許可方發出終止授權的意思表示，其法律效果發生的方式與合同解除權發生效力的機理不同。而考慮到在此情形下雙方法律關係的變動無需當事人意志的介入而自動發生作用，將這一規定解釋為我國《民法典》規定的附解除條件的法律行為中所附條件更為妥帖。在「羅盒案」中，法院也採納了該觀點。該案被告因為違反了GPL的約定，導致喪失了其使用的原告開源程式碼的授權，進而法院直接認定雙方的許可合同法律關係終止，未考察雙方是否有通知解除的具體行為[注13]。
該條同時規定了授權的治癒，即被許可方糾正了違約行為後，其授權可自動恢復。
當然，由於被許可方已經有了一次違約行為，許可方可因此享有徹底終結授權的權利，其只需在被授權方糾正違約行為前或糾正違約行為後60日內通知被許可方，即可永久的、不可恢復地終結對被許可方的授權，這也是GPL項下許可方唯一一次可以永久終結授權的機會。
(五) 其他條款
第7條、第11條分別針對商標權和專利權進行了相應規定，由於篇幅限制，本文不在此展開。第13條、14條主要規定版本於兼容性的問題，15、16、17條為免責聲明和責任限制。由於篇幅限制，本文不展開詳述。
四、GPL v3項下的主要風險及防範
(一) 軟體產品被過度傳染的風險及防範
因GPL的強傳染性且不容使用者拒絕、不可撤銷的特性，使得了GPL這一開源許可證以極快的速度傳播。1991年林納斯·託瓦茲以GPL許可發佈了開源作業系統Linux v0.01後，GPL的發展更是一發不可收拾。後人在實際的商用軟體開發過程中，很難完全規避GPL的影響。而一旦商用軟體中使用了任何GPL軟體，開發者將不得不開放整個軟體的全部源程式碼並允許所有人自由使用，在開發Linux系統中的相關軟體時更是如此。雖然GPL不禁止收費，但任何購買了軟體副本的第一個使用者均可免費傳播的這一大前提，也導致企業靠售賣軟體副本盈利的可能性不復存在。
對於此類情形，境內軟體開發企業可採取以下兩種措施：
1. 將GPL開源軟體與軟體其他模組隔離
這是GPL v3第5條明確規定的可阻斷傳染性的情形，也是被廣泛運用的一種模式。典型的如Google的安卓系統，系以基於GPL的Linux kernel為核心，為防止整個安卓系統被GPL傳染，Google採取了分層的模式將Linux核心封裝在底層，通過某些技術措施，實現了與使用者層的隔離，Google的這一做法也得到了理查德·斯特曼本人的認可。[注14]
國內法院也支持了此類做法，在北京閃亮時尚資訊技術有限公司、不亂買電子商務（北京）有限公司侵害計算機軟體著作權糾紛（以下簡稱「不亂買案」）一案中，原告發布的軟體為B/S結構（即使用者端與伺服器端相分離），而僅伺服器端使用了GPL程式碼，最高院最終認定，原告對外發布的使用者端軟體未受GPL傳染，進而有權主張被告的侵權責任。
因此，對於中大型軟體開發者來說，對軟體的合理分層和隔離，是避免GPL過度傳染的有力手段。
2. 免費發佈，以服務作為主要盈利來源
對於開發中小型軟體，或源程式碼中不含有重大技術成分的常規應用軟體，開發者可選擇直接將產品按照GPL發佈，同時以提供具體服務的方式收取費用，如會員服務，技術支持服務等，並儘可能在軟體設計時，加強使用者對服務的依賴性。這樣雖然軟體本身可隨意被第三方獲取和自由使用，但開發者仍可通過提供服務的方式確保自己的經濟利益。同時也可以借開源之便，促進自身軟體的流通速度，可謂一舉兩得。
(二) 違反GPL導致喪失授權的風險及防範
如前所述，任何對GPL的違反都會導致授權的自動終止，如羅盒案中，被告就因未開放源程式碼而被法院認定為侵權[注15]。因而境內開發者必須嚴格按照GPL的規範發佈軟體，避免侵犯作者版權。但在實踐中，使用GPL軟體而不遵守GPL的情形，大多不是企業層面的正式決策，很多情況是因相關人員開源意識淡薄而未注意，或具體的開發人員在企業不知情的情況下使用了GPL軟體，導致企業產品在不經意間被傳染。對此，境內開發企業應當建立相關的機制予以防範：
1. 控制開源程式碼的使用
如果完全禁止工程師使用開源程式碼，勢必導致公司軟體開發進度緩慢，成本上升。且彙集了世界各地智慧的優質的開源程式碼往往在穩定性等方面也優於單一工程師臨時開發的程式碼。因此在軟體開發的過程中，開發企業也無需聞開源色變，但需建立一定的控制機制，如開源程式碼使用審批制度等，要求具體的開發人員在使用開源程式碼時，及時登記模組的名稱、適用許可證類型等，交由相關人員審核，審核批准後方才允許使用。
2. 技術程式碼審核與法務開源審核相結合
為防範員工擅自使用開源軟體而不上報的情形，開發企業可結合自身的程式碼審核（Code Review）程序，將開源合規審核融入程式碼審核之中，對具體開發人員提交的程式碼進行抽查，一旦發現使用開源程式碼，及時向法務或外部法律顧問通報，以制定應對方案。
3. 發現使用GPL後應及時糾正
GPL中賦予了使用者授權終止後自行糾正的權利，一旦公司發現自己已發佈的軟體中存在GPL程式碼，應第一時間予以糾正，如將GPL軟體整體替換，或重新調整產品結構，將GPL軟體予以隔離，以恢復GPL授權。
五、結 語
開源運動對境內軟體開發企業來說，既是機遇也是挑戰，擁抱開源給企業帶來了開發上的便利，也為產品的推廣提供了強大助力。但開源背後的挑戰和風險，也是不容忽視的。境內企業在享受開源帶來的便利的同時，也應當時刻注意開源風險的防範，加強技術與法務或外部法律顧問的互動，將開源合規納入企業智慧財產權合規體系之中，為企業在開源浪潮中順勢前行保駕護航。
上下滑動查看全部
註釋：
[1] 王志強, 伍勝, 肖國強, et al. 開源許可證合規性研究 [J]. 軟體學報, 2022, (08 vo 33): 3035-58.
[2] 參見Github官網，https://github.com/，2022年9月17日訪問。
[3] 王曉冬. 我國開源軟體產業面臨的突出風險及對策研究 [J]. 資訊安全研究, 2021, (10 vo 7): 973-6.
[4] 參見CSDN. 2022中國開源發展藍皮書，https://blog.csdn.net/csdnnews/article/details/125923869?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166339613016782412559776%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=166339613016782412559776&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-1-125923869-null-null.142^v47^pc_rank_34_2,201^v3^control&utm_term=%E8%93%9D%E7%9A%AE%E4%B9%A6&spm=1018.2226.3001.4187，2022年9月17日訪問。
[5] 紅旗Linux及鴻蒙作業系統均基於開源的Linux核心開發。
[6] 如知名人工智慧類庫TensorFlow就適用Apache License 2.0。參見https://github.com/tensorflow/tensorflow/blob/master/LICENSE，2022年9月17日訪問
[7] GNU官網, https://www.gnu.org/licenses/licenses.html，2022年9月17日訪問。
[8] 前引4.
[9] Frequently Asked Questions about version 2 of the GNU GPL, https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#VersionTwoOrLater, 2022年9月17日訪問。
[10] 張長丹. Gpl的法律性質及各方法律風險研究——以違反gpl的案例為視角 [J]. 電子智慧財產權, 2018, (01): 70-7.
[11] 參見（2019）粵73知民初207號民事判決書。
[12] What is Free Software?，https://www.gnu.org/philosophy/free-sw.en.html，2022年9月17日訪問。
[13] 前引11。
[14] Richard Stallman：Android and Users’ Freedom，https://www.gnu.org/philosophy/android-and-users-freedom.en.html，2022年9月18日訪問。
[15] 前引11。
參考文獻：
[1] 王志強, 伍勝, 肖國強, et al. 開源許可證合規性研究 [J]. 軟體學報, 2022, (08 vo 33): 3035-58.
[2] 吳欣, 武健宇, 周明輝, et al. 開源許可證的選擇:挑戰和影響因素 [J]. 軟體學報, 2022, (01 vo 33): 1-25.
[3] 張長丹. Gpl的法律性質及各方法律風險研究——以違反gpl的案例為視角 [J]. 電子智慧財產權, 2018, (01): 70-7.
[4] 張漢華. 違反開源軟體許可證的法律救濟——以德國法為視角 [J]. 法學評論, 2015, (03 vo 33): 83-8.
[5] 王曉冬. 我國開源軟體產業面臨的突出風險及對策研究 [J]. 資訊安全研究, 2021, (10 vo 7): 973-6.
[6] DUSOLLIER S. Open Source of Copyleft: Authorship Reconsidered [J]. Columbia Journal of Law & the Arts, 2003, 26: 281.
[7] KUMAR S. Enforcing the GNU GPL [J]. University of Illinois Journal of Law, Technology & Policy, 2006, 2006(1): 1.
[8] BENKLER Y. Coase’s Penguin, or, Linux and The Nature of the Firm [J]. Yale Law Journal, 2002, 112(3): 369-446.
[9] MCGOWAN D. Legal Implications of Open-Source Software [J]. University of Illinois Law Review, 2001, 2001(1): 241-304.
[10] DALEY D A, RUCHIKA; SARBORARIA, MATTHEW; MILLER, DEBORAH K. Revisiting Open Source [J]. International In-House Counsel Journal, 2018, 11(42): 1.
【 特別聲明：本篇文章所闡述和說明的觀點僅代表作者本人意見，僅供參考和交流，不代表本所或其律師出具的任何形式之法律意見或建議。】
陶冶
國浩南京律師
業務領域：軟體和網際網路
郵箱：taoye@grandall.com.cn
