開源合規機制研究

一. 開源許可證概述

符合開源定義的許可證，即開源許可證，也稱為開源協議。開源的標準由開源促進會（Open Source Initiative, OSI）制定，主要包括以下要素 ¹：（1）免費再分發；（2）程序包含源代碼；（3）可以修改和二次開發；（4）確保源代碼完整性；（5）不歧視個人或群體；（6）不歧視應用領域；（7）允許重新分發；（8）不基于特定產品；（9）不限制其他軟件；（10）技術中立。

開源許可證適用的場景既包括軟件、代碼，也包括數據集、版權或者是硬件。最常見的是軟件開源許可證，例如在選擇開源許可證的網站（https://choosealicense.com/licenses/）上列示的GNU AGPLv3、GNU GPLv3、GNU LGPLv3、Mozilla Public License 2.0、Apache License 2.0、MIT License等，其他涉及數據集或版權適用的開源許可證則包括Creative Commons Zero v1.0 Universal（CC0-1.0）、Creative Commons Attribution 4.0 International（CC-BY-4.0）、Creative Commons Attribution Share Alike 4.0 International（ CC-BY-SA-4.0）等，硬件也有可適用的開源許可證，包括CERN Open Hardware Licence Version 2 - Permissive（CERN-OHL-P-2.0 ）、CERN Open Hardware Licence Version 2 - Weakly Reciprocal（CERN-OHL-W-2.0 ）、CERN Open Hardware Licence Version 2 - Strongly Reciprocal（CERN-OHL-S-2.0 ）²等；甚至于字體也有專門的開源許可證，例如SIL Open Font License 1.1³。

根據中國信通院的定義，開源是一種分布式協作模式，并且逐漸成為新的軟件開發模式 ⁴。開源的目的是為了促進技術創新、開放協同，其與商業模式有一定區別，但并 不意味著開源的就是免費的，公開的就是開源的。以軟件為例，開源軟件并不等于免費軟件（可以使用開源軟件收費），也不等于公開軟件（二次開發可以閉源，即不公開代碼）。開源指向的是一種特定形態的產品 ⁵，通常體現為軟件、算法、數據甚至硬件、字體等形態；該產品可以根據開發者的選擇適用各種開源許可證，呈現出不同的開源模式。開發者既可以完全適用已有的開源許可證，也可以修訂現存開源許可證，或者制定新的開源許可證；開發者也可以在一個開源產品上同時適用多個開源許可證，例如將開源產品中的代碼、模型、數據等分別適用不同的開源許可證。根據開源許可證中限制分發的強弱程度，可將主要的開源許可證分為以下兩種類型：

2. 強著佐權型（Copyleft），與著作權（Copyright）的法益相反，通常只要前序軟件適用了該類型的開源許可證，后續開發的軟件將被強制“傳染”成為開源軟件。即一旦開源，后續不能再閉源。這是為了促進開發者群體的技術合作和創新，促進代碼之間的自由共享。典型的例子可參考GNU AGPL、GNU GPLv3許可證等 ⁸。

但實務中，在軟件領域仍存在其他多種類型的開源許可證，有些許可證并不適合按照上述原則做統一歸類。例如在GNU AGPL以及 GNU GPL許可證這類強著佐權類型下，還存在一類弱著佐權類型，即LGPL（Lesser General Public License）許可證，這是GPL許可證下的附加許可證。在適用LGPL許可證情形下，開發者可以通過僅鏈接或組合的方式，避免后續開發不得閉源的情形。又如Meta公司就其開源的Llama模型專門設置的Llama2社區許可協議，雖然具備一定的開源因素，例如免費分發、可修改、含源代碼等，但其在第2條中規定了月活量超7億的用戶必須獲得Meta公司的單獨授權才能使用，模型卡內規定Llama2開源模型不適用于除英語以外的語言中使用 ⁸，同時違反了開源要素中的第（5）條不限制用戶或群體的內容； 以及第1條第2款第5項中規定了不得使用Llama模型去提高其他語言模型的限制，違反了開源要素中第（9）條不限制其他軟件的內容。顯然，Llama2社區許可協議并非典型開源許可協議。近期，相關新聞爆出Yi萬物疑似存在抄襲Llama2模型代碼的行為，顯然違反了開源許可協議中有關規定。雖未看到Meta的公開追責，但此行為必然存在極大的侵權風險 ¹⁰。所以在技術開發場景下，需根據業務實際使用的開源軟件對應的開源許可證規則，做具體的開源合規設計與安排。

二. 常見開源許可證梳理

在不同的社區或代碼平臺，其對開源許可證的偏好不同。例如， Apache平臺以及Cloud Native Computing Foundation 平臺外推薦使用Apache License 2.0， GNU平臺則為大多數的項目推薦GNU GPLv3 ；Npm packages 強烈推薦適用 MIT 以及相類似的ISC 等。根據開源許可證中設置的條件數量排序，例如可商用、可分發、可修改及對應的局限性等，許可證規則數量由高到低（或根據寬松程度由低到高）分別為：GNU AGPLv3＞GNU GPLv3＞GNU LGPLv3＞Mozilla Public License 2.0＞Apache License 2.0＞MIT License＞Boost Software License 1.0＞The Unlicense ¹²。

三. AIGC開源大模型中的開源許可證

在生成式人工智能發展的浪潮中，開源大模型遍地開花。本節主要對生成式人工智能行業目前已開源大模型適用的開源許可證情況做簡要的規則梳理。其中值得注意的是，國外開源模型對開源內容并未做細致的許可證規則劃分，而國內的開源大模型中，開源模型通常被拆分為代碼（Model Code）、模型權重（Model Weights）以及數據等內容，并分別適用不同的開源許可證。

從上述內容可知，目前國內外生成式人工智能行業內的開源大模型適用的開源許可證各有千秋。根據開發者的需求，針對開源組件不同而適用開源程度不同的許可證，或者是新創開源規則等。整體而言，對于版權聲明、免責聲明、原樣提供的要求基本保持一致，核心的差別主要在于后續的開源傳染性特征、商業化路徑、二次開發、限制用途范圍等方面。所以在使用開源模型進行商業化設計時，應當尤其注意使用了GPL類許可證的開源模型，應用中應考慮對于具體代碼使用、分發以及開源傳染性的有關限制性規則條款，否則可能導致后續開發的源代碼被強制披露、公開的后果。

四. 開源許可證境內法律規制

針對開源許可證的性質及其法律適用，目前國內并無明確的法律規定。國內涉及開源許可證類型的爭議解決時，通常體現為《著作權法》中關于著作權許可、轉讓、侵權認定及處理等相關法規，以及《民法典》中涉及單方意思表示成立、合同成立、解除、終止等相關法規。

在開源許可證引發爭議的有限幾起司法判例中，各地法院并未達成一致意見。一些地方知識產權法院將該類開源許可證認為是著作權合同，而最高人民法院僅僅是引用了其中一類開源許可證的條款作為釋明依據，并未明確其性質和適用范圍。例如，在濟寧市羅盒網絡科技有限公司、廣州市玩友網絡科技有限公司等侵害計算機軟件著作權糾紛一案 ²⁴中，廣州知識產權法院依據原《合同法》第45條（現《民法典》第158條）認定GNU GPLv3為附解除條件的著作權合同，且“許可條款是版權許可的條件，如果用戶違背條款規定，那么許可的前提條件已不復存在，則GPLv3協議（GNU GPLv3）終止適用，用戶獲得的授權也將自動終止” ²⁵。在近期的深圳市君用科技有限公司等與山西夢多福科技有限公司不正當競爭糾紛一案 ²⁶中，北京市西城區人民法院在論述Apache2.0開源協議的證據效力時，認為“開源協議本質上是許可協議，目的在于鼓勵軟件開發者共享自己的代碼，向使用者開放一定權限，這種公開許可的內容主要針對的是軟件代碼的復制、修改，涉及的是軟件著作權相關問題” ²⁷。而在北京閃亮時尚信息技術有限公司與不亂買電子商務（北京）有限公司侵害計算機軟件著作權糾紛一案中 ²⁸，最高人民法院在二審程序中則直接引用了GNU GPLv3第5條關于聚合體作品的認定方式的內容，并基于該內容對涉案軟件做出是否屬于開源軟件的判斷。但最高人民法院并未在該案中釋明GNU GPLv3的性質，究竟是格式化合同還是權利聲明文件，不得而知。且我國并非判例法國家，即使根據同案同判、類案類判的原則，在開源許可證種類繁多、規則差別較大的情況下，現有的案例裁判觀點恐怕也無法實現普遍的適用，僅能起到非常有限的參考作用。例如GPL類許可證的核心特征即開源會傳染，而MIT許可證通常是修改即可閉源，開源規則的重大區別將在個案中實質影響雙方爭議處理的走向。

在國家標準層面，近期由全國信息安全標準化技術委員會發布了一版《信息安全技術軟件產品開源代碼安全評價方法》的征求意見稿，其中對軟件產品包含的開源代碼許可證的規范性做了具體評價要素的規定，評價范圍包括許可證的授權范圍、授權條件、違約與授權終止、免責聲明等，以及履行開源許可證規定的相關條款、義務情況。同時開源許可證的互惠性、兼容性、其專利授予情況及適用范圍，均被納入到評價范圍中 ²⁹。

五. 開源風險概述

承前所述，在各類開源許可證的法律性質不明，適用范圍不清的現狀下，目前在使用開源軟件中會存在以下風險：

其一，開發者選擇開源許可證時，對于開源許可證的理解通常面臨條款內容太復雜、考慮因素不確定這兩項困難 ³⁰。開源許可證主要由基本信息、序言、定義、授權范圍、義務、違約與授權終止、擔保與責任限制、準據法、許可證版本與兼容性、許可證使用說明等部分組成 ³¹。常用的幾類開源許可證多為外文許可證，實務中選擇許可證或者使用這類許可證下的開源軟件時，則可能出現規則內容理解困難、不同司法管轄權的法律適用不熟悉等問題。

其二，一個開源軟件可能適用多類許可證，許可證之間規則可能不兼容。例如上述提到的AI開源大模型發布中，可能將模型權重、代碼、數據分別適用不同開放程度的許可證。后續開發者在集成多個開源模型時，則需要考慮各模型之間適用的開源許可證兼容問題。

其三，開源軟件本身可能存在的侵權問題，例如開源軟件使用了未經授權的專利，導致后續使用者需承擔專利侵權賠償；或者使用者未經許可使用頒發者的商標信息，包括商號、商標、服務標記或產品名稱等使用的限制等。

其四，如違反開源許可證，可能面臨多重路徑的救濟維權。例如將開源許可證視為負解除條件的合同，如果違反其中規則，則相關開源軟件授權視為自動終止。如將開源許可證認為是著作權許可合同，則可能涉及著作權侵權責任承擔等。

其五，開源軟件可能根據開發者需求針對不同版本或開發進程，對原開源許可證規則進行調整或變更，或直接加入商業使用限制條款。常見情形是開源軟件孵化為商業公司，為了獲得商業利益，從寬松的開源許可證變更為強著佐權開源許可證，抑或使用雙許可的方式，在原先的開源許可協議上添加商業授權條款。