《中倫律師事務：2024開源合規白皮書（第二版）（中英雙語版）（156頁）.pdf》由會員分享，可在線閱讀，更多相關《中倫律師事務：2024開源合規白皮書（第二版）（中英雙語版）（156頁）.pdf（156頁珍藏版）》請在三個皮匠報告上搜索。

1、北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty開源合規白皮書開源合規白皮書第二版（2025 年 5 月 18 日）第二版（2025 年 5 月 18 日）北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?

2、東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty版權聲明Copyright Statement本白皮書版權歸北京中倫（杭州）律師事務所王紅燕律師所有，轉載、編撰或利用其他方式使用本白皮書文字或觀點，應注明來源開源合規白皮書 2024（中倫杭州王紅燕律師）。違反上述聲明者，編者將追究其相關

3、法律責任。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty目 錄目 錄第一部分開源簡述第一部分開源簡述71第二部分開源風險與合規建設 第二部分開源風險與合規建設 10第三部分中國開源軟件司法實踐 第三部分中國開源軟件司法實

4、踐 100第四部分域外開源軟件案例解讀 第四部分域外開源軟件案例解讀 117第五部分關于建立開源平臺的合規要求 第五部分關于建立開源平臺的合規要求 125第六部分開源合規適用法律以及相關政策 第六部分開源合規適用法律以及相關政策 133第七部分開源合規第七部分開源合規 Q&A（持續豐富中）（持續豐富中）145第八部分信息安全技術軟件產品開源代碼安全評價方法 第八部分信息安全技術軟件產品開源代碼安全評價方法 154北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou

5、 Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty4第一部分開源簡述第一部分開源簡述北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Ko

6、ng London New York Los Angeles San Francisco Almaty5開源簡述開源簡述開源（Open-Source），全稱為開放源代碼，這一概念興起于軟件行業，其基本內涵是開放源代碼，也即源代碼開放共享的開發模式。在開源模式下，通過許可證的方式，使用者在遵守許可限制的條件下，可自由獲取源代碼等，并可使用、復制、修改和再發布。發展至今，開源作為一種創新協作模式，其表現形式已不僅僅局限于開源軟件（Open Source Software），而且也包括開源硬件（Open Source Hardware）、開源設計（Open Design）、開源文檔（Open Doc

7、ument）、開源技術（Open source Technologies）等。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty6一、開源簡史一、開源簡史從歷史發展的角度，開源項目的演進，大致經歷了以下幾個階段1：（一）（一

8、）1950s-1960s：早期計算機領域的合作和信息共享：早期計算機領域的合作和信息共享在 20 世紀 50-60 年代，計算機科學正處于萌芽階段。計算機硬件和軟件的開發主要由大學和研究機構進行，形成了一個相對較小但緊密合作的社區。計算機系統的規模相對較小，研究者們注重合作和信息共享，通過科學論文和會議傳播計算機科學的知識?？梢钥醋魇且环N早期的“開放”文化。（二）1970s：（二）1970s：UNIX 的出現的出現在 20 世紀 70 年代初，貝爾實驗室的研究員開發了 UNIX 操作系統。UNIX的源代碼被許多學術機構和公司開放，這一開放性的實踐為合作和信息共享奠定了基礎。這個時期的特點是社區

9、內部的互動和知識交流。（三）（三）1980s：自由軟件基金會的成立：自由軟件基金會的成立1985 年，理查德斯托曼創建了自由軟件基金會（FSF），倡導“自由軟件”概念，強調用戶對軟件自由使用、修改和分享的權利。FSF 推動了 GNU 項目的啟動，致力于創建一個完全自由的 UNIX 兼容操作系統。這一時期見證了對“自由”概念的深入探討和定義。（四）1990s：（四）1990s：Linux 內核和開源運動的興起內核和開源運動的興起1991 年，芬蘭學生林納斯托瓦茲發布了 Linux 內核的第一個版本。Linux成為一個成功的開源項目，吸引了全球范圍內的開發者積極參與。這一時期標志著“開源”概念的正

10、式提出，社區的規模和活躍度急劇增加。（五）（五）1998：開源倡議的成立：開源倡議的成立1998 年，開源倡議（OSI）成立，旨在推動開源軟件的定義和推廣。OSI1Vivek Singh：A Brief History of Open Source，2018北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London

11、 New York Los Angeles San Francisco Almaty7制定了開源定義，認證了符合這一定義的開源許可證。這一時期是開源概念得到系統化和規范化的時刻。（六）（六）2000s：開源軟件的商業應用：開源軟件的商業應用隨著時間的推移，越來越多的公司認識到開源軟件的潛力，并積極參與開源項目，或者基于開源軟件構建自己的產品和服務。知名的開源項目，如 ApacheHTTP 服務器、MySQL 數據庫和 Linux 操作系統，在這一時期成為構建企業級應用的關鍵組成部分。（七）（七）2010s 至今：開源在技術和社會中的廣泛影響至今：開源在技術和社會中的廣泛影響過去的十年中，開源已

12、經成為 IT 行業的主導力量，不僅在操作系統和服務器領域占據主導地位，還擴展到云計算、大數據、人工智能等新興領域。全球范圍內的開源項目蓬勃發展，社區合作的模式也在不斷演進。開源的成功示范如 Kubernetes、TensorFlow 等，為技術創新提供了強大的推動力。開源發展的歷史是一部不斷演變的史詩，代表了計算機科學和軟件工程領域對開放、協作和創新的持續追求。這個歷程在推動技術發展的同時，也在社會層面產生了深遠的影響，塑造了當今數字時代的面貌。二、中國開源的發展進程二、中國開源的發展進程我國的開源發展經歷了多個階段，展現出逐步深化和廣泛參與的趨勢。起步階段（20 世紀 90 年代至 2000

13、 年代初）：我國在這一時期主要處于對開源軟件的初步采用和使用階段，主要集中在一些高校和科研機構。初步開源社區形成（2000 年代中期）：國內的開源社區在這一時期開始初步形成。一些開源項目逐漸引起國內關注，開發者開始參與到國際開源社區中。國內自主開源項目崛起（2010 年代初）：隨著國內技術水平的提升，我國自主開源項目開始嶄露頭角。一些企業和獨立開發者積極參與到一些關鍵項目北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongq

14、ing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty8中，如中國開源軟件產業聯盟的成立。社區的活躍與國際交流（2010 年代中期至今）：國內的開源社區在這一時期變得更加活躍。一方面，國內社區在國際上積極參與，推動了一些國際開源項目的發展；另一方面，國內涌現出一系列優秀的自主開源項目，如螞蟻金服的 Dubbo、華為的 HarmonyOS 等。政府政策引導與支持（2010 年代中期至今）：政府逐漸認識到開源在技術創新和產業升級中的戰略地位。出臺了一系列

15、支持開源發展的政策，包括鼓勵政府采購開源軟件、推動企業開源項目、以及促進國際開源合作等。產業化和技術創新（2015 年至今）：近年來，我國的開源生態系統進入了更為成熟和產業化的階段。一些知名企業在開源領域取得顯著進展，成為一些重要開源項目的主要貢獻者。國際合作與社區建設（近年來）：我國的開源社區與國際社區的交流日益頻繁。中國的開發者和企業積極參與到全球性的開源項目中，促進了技術的國際交流與合作?？傮w而言，我國的開源發展經歷了從起步、涌現到成熟和國際化的過程。在政府政策的支持下，我國開源社區逐漸成為全球開源生態系統中不可忽視的一部分，為技術創新和產業發展注入了強大動力。北京 上海 深圳 廣州 武

16、漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty9第二部分開源風險與合規建設第二部分開源風險與合規建設北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai

17、 Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty10開源風險與合規建設開源風險與合規建設一、開源許可證分類二、常見開源許可證介紹三、開源軟件合規風險四、企業開源合規體系的構建北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuha

18、n Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty11一、開源許可證分類一、開源許可證分類開源許可證，又被稱為開源協議，是開源理念在實踐中的重要產物。正如之前所強調的，開源的核心理念是通過共享知識來促進技術進步，而非與嵌入在智力成果中的知識產權對抗。在追求這一目標的同時，開源同樣需要通過法律手段來確保開發者的合法權益。為了在維護開發者權益的同時充分保障用戶對軟件的自由使用權，著佐權（Copyleft）的概念應運而生

19、。通過開源許可證的方式，既保護了作者的專有權利，又施加了一定的自我權利限制，從而確保了用戶在分享和修改軟件方面的自由。各個開源社區、知名大學以及團體紛紛制定了一系列開源許可證，這些許可證在權利和義務方面都有各自獨特的規定，往往反映了不同的價值觀和考慮。開源許可證一般分為 2 種類型：寬松型和著佐權型。1、寬松型(Permissive)：該類許可證往往只要求被許可方保留原作品的版權信息，對用戶施加的限制較少，衍生軟件可以成為私有軟件，如 Apache、MIT、BSD 系列許可證。由于它們容許衍生軟件閉源，因而在商業化環境中備受歡迎。2、著佐權型（Copyleft）：也稱為互惠型或者強保護型許可證

20、。此類許可證設計目的是通過要求對軟件的修改和擴展必須按照相同許可證進行開源，以促進開發人員的合作，確保源代碼的自由共享。著佐權型許可證進一步可以分為強著佐權型許可證和弱著佐權型許可證，常見的強著佐權型許可證包括AGPL、SSPL、GPL 許可證等；常見的弱著佐權型許可證包括 LGPL 系列許可證、MPL 許可證等。強著佐權型許可證要求對軟件的修改和擴展更為嚴格，追求更高程度的開源傳染性，確保整個項目都是開源的。相比之下，弱著佐權型許可證在開源要求上相對寬松，允許與非開源軟件組合使用。選擇使用哪種類型的許可證通常取決于項目的性質、社區的需求以及開發者對代碼共享的態度。22Heather Meek

21、er：開源軟件許可實用指南，人民郵電出版社，2023，劉偉譯。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty12二、常見開源許可證介紹二、常見開源許可證介紹（一）（一）MIT 許可證許可證MIT 許可證是一種非常寬松的開

22、源許可證，被廣泛應用于許多開源項目。它起源于麻省理工學院（MIT），因此得名。主要特點有：（1）簡潔明了：MIT 許可證是一份非常簡潔、直觀的許可證，不包含過多復雜的法律術語。（2）允許使用、修改和再分發：MIT 許可證允許任何人無論是私人用戶還是企業都可以自由使用、修改和再分發軟件。（3）無傳染性：與著佐權型許可證不同，MIT 許可證沒有傳染性，即不要求衍生作品必須使用相同的許可證。（4）包含版權聲明和免責條款：MIT 許可證要求在軟件的所有副本或重要部分中包含原始許可證和版權聲明。此外，它附帶了免責聲明，概述了軟件是按原樣提供的，沒有任何形式的擔保。（5）商業友好：由于其寬松的限制，MIT

23、 許可證在商業環境中非常受歡迎。企業可以將包含 MIT 許可的軟件集成到他們的商業項目中，而不會受到限制。（二）（二）BSD 許可證許可證The BSD License（BSD）是 Berkeley Software Distribution License 的縮寫。BSD 許可證是一系列開源許可證的統稱，其中最常見的兩個版本是 BSD2-Clause License（又稱為 Simplified BSD License 或 FreeBSD License）和 BSD3-Clause License（又稱為 New BSD License 或 Modified BSD License）。這兩個

24、版本的 BSD 許可證都源自于加利福尼亞大學伯克利分校（University ofCalifornia,Berkeley）開發的 BSD 操作系統。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty13BSD 2-Claus

25、e License 主要特點有：（1）簡潔明了：與 MIT 許可證一樣，BSD 2-Clause License 是一種非常簡潔明了的許可證。（2）允許使用、修改和再分發：許可證允許在滿足特定條件的情況下使用、修改和再分發軟件。（3）保留版權和免責聲明：與 MIT 許可證類似，BSD 2-Clause License 要求在軟件的所有副本或重要部分中包含原始許可證和版權聲明，并且包含免責聲明。BSD 3-Clause License 主要特點有：（1）允許使用、修改和再分發：與 BSD 2-Clause License 相似，許可證允許在滿足特定條件的情況下使用、修改和再分發軟件。（2）要求不

26、使用原作者或貢獻者的名字進行宣傳：在使用軟件的宣傳資料中，不得使用原作者或貢獻者的名字、商標或其他標識，以表示它們的認可或推薦。（3）保留版權和免責聲明：同樣要求在軟件的所有副本或重要部分中包含原始許可證和版權聲明，并且包含免責聲明。BSD 許可證因其靈活性和簡潔性而受到歡迎，特別是在與商業軟件集成或用于學術研究項目中。（三）（三）Apache 許可證許可證Apache 許可證是一種廣泛使用的開源許可證，最初由 Apache 軟件基金會（Apache Software Foundation）創建并維護。該許可證適用于許多知名的開源項目，其中最著名的就是 Apache HTTP 服務器。Apac

27、he 許可證主要特點有：（1）允許商業使用：Apache 許可證對商業和非商業用戶都是開放的，允北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty14許在閉源和開源項目中使用。（2）允許修改和再分發：許可證允許用戶修改源代碼

28、，并將修改后的代碼以開源或閉源形式再分發。（3）有限的專利授予：Apache 許可證包含有限的專利授予條款，即授予用戶使用與軟件相關的專利的權限。這有助于防止專利訴訟對開源項目的侵害。（4）保留版權和免責聲明：許可證要求在軟件的所有副本或重要部分中包含原始許可證和版權聲明。此外，它還包含了免責聲明，說明軟件是按原樣提供的，不提供任何擔保。Apache 許可證因其靈活性、商業友好性以及對專利授予的處理而被廣泛采用，許多重要的開源項目都選擇使用這一許可證。（四）（四）GPL 許可證許可證GPL（GNU General Public License，通用公共許可證）是一種由自由軟件基金會（Free

29、Software Foundation）創建的開源許可證。GPL 是一種著佐權型許可證，旨在保障用戶的自由，確保每個使用、修改和分發軟件的人都能享有相應的自由。主要特點有：（1）開源和自由使用：GPL 確保被授權方可以自由使用、修改和分發軟件的源代碼。（2）傳染性（Copyleft）：GPL 的主要特點之一是其傳染性，要求任何基于 GPL 許可的軟件修改和衍生作品也必須使用 GPL 進行分發。（3）源代碼的可用性：如果在項目中使用了 GPL 許可的軟件，那么對于任何分發的二進制形式，必須同時提供相應的源代碼，確保用戶有權查看和修改代碼。（4）修改的開源性：對于基于 GPL 軟件的修改，這些修改

30、必須同樣使北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty15用 GPL 進行分發，以保證整個項目的開源性。GPL 先后發布了有 3 個版本，常用的 GPL 許可證為 GPL v2 和 GPL v3。版本版本發布時間發布時

31、間內容內容GPLv11989 年基于 GPLv1，如果發布了可執行的二進制代碼，就必須同時發布可讀的源代碼，并且在發布任何基于 GPL 許可的軟件時，不能添加任何限制性的條款。GPLv21991 年在 GPLv2 中所做的最大的改動就是增加了“自由還是死亡”（Liberty or Death）的條款。該條款規定，發布源于 GPL 的軟件時，源代碼應公開，如果規定只能以二進制代碼的形式發布軟件，那么使用者將根本無權發布該軟件。GPLv32007 年GPLv3 的修改主要為：明確了專利問題、與其他許可證的兼容性問題；重新定義了發布、傳播、源代碼等概念；解決數字版權管理(DRM)問題。GPL 許可證

32、因其強調用戶自由的特點，特別適用于開源社區和項目，但同時也因其傳染性和一些要求而在商業領域引起爭議。項目選擇 GPL 許可證通常是出于對自由軟件原則的堅持。（五）（五）AGPL 許可證許可證AGPL（GNU Affero General Public License，Affero 通用公共許可證）許可證是一種強著佐權許可證。與 GPL 一樣，其要求對軟件的修改和擴展必須按照相同的許可證進行開源。主要特點有：（1）網絡服務的傳染性：AGPL 要求如果服務商使用 AGPL 許可的軟件提供網絡服務，那么對該軟件的修改和衍生作品也必須使用 AGPL 進行開源，即使這些修改只是在服務器上運行，而沒有分發

33、給客戶端。（2）遠程用戶的訪問權：AGPL 強調了遠程用戶通過網絡訪問該軟件的權利，以確保他們能夠獲得相應的源代碼。（3）源代碼的可用性：與 GPL 類似，AGPL 要求在分發二進制形式的同時提供相應的源代碼。但是，AGPL 更明確地強調了通過網絡提供軟件服務的情況。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong L

34、ondon New York Los Angeles San Francisco Almaty16（4）應用于網絡服務和托管環境：AGPL 的設計目的是應對云計算和托管服務的興起，確保在這些環境中使用的開源軟件仍然保持開源。AGPL 通常被選擇用于那些提供在線服務的開源項目，特別是在云計算、軟件即服務（SaaS）和其他網絡服務模型中，以確保在這些環境中使用的軟件仍然保持開源。AGPL 的使用場景主要是基于對開源社區的貢獻和對用戶自由的強調。（六）（六）LGPL 許可證許可證LGPL（GNU Lesser General Public License，寬通用公共許可證）是一種由自由軟件基金會（F

35、ree Software Foundation）創建和維護的弱著佐權許可證。與 GPL 不同，LGPL 相對更為寬松，允許開發者將 LGPL 許可的庫（或部分代碼）鏈接到非開源軟件中而不需要將整個應用程序的源代碼開放。主要特點有：（1）鏈接允許：LGPL 允許開發者將 LGPL 許可的庫（或部分代碼）鏈接到非 LGPL 許可的應用程序中，而不需要開放整個應用程序的源代碼。（2）修改的開源性：對于 LGPL 許可的庫的修改，這些修改必須同樣使用 LGPL 進行分發，以保持整個庫的開源性。（3）庫的自由使用：對于 LGPL 許可的庫，用戶可以自由使用、修改和分發該庫的源代碼。（4）修改的開源性：如

36、果修改 LGPL 許可的庫并將其嵌入應用程序中，這些修改必須同樣使用 LGPL 進行分發。LGPL 通常被選擇用于開發可重用的軟件庫或組件，允許這些庫在開發者構建閉源應用程序時被鏈接。這使得開發者可以享受開源庫的好處，同時不需要公開整個應用程序的源代碼。（七）（七）MPL 許可證許可證北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Ho

37、ng Kong London New York Los Angeles San Francisco Almaty17MPL（The Mozilla Public License）許可證由 Mozilla 基金會創建和維護。MPL 是一種相對寬松的許可證，旨在鼓勵軟件的開發和共享，同時保護作者的權益。MPL 的特點之一是其“文件級別”的復雜性管理，允許開發者以 MPL許可證的形式選擇性地授權其軟件的部分。主要特點有：（1）文件級別授權：MPL 允許開發者選擇性地使用 MPL 授權他們的軟件的部分，而不是整個項目。這種模塊化的授權使得 MPL 更為靈活。（2）派生作品的開源性：對于派生作品，MPL

38、 要求這些派生作品必須使用 MPL 進行分發，以保持開源性。（3）允許與其他許可證組合：MPL 允許與其他許可證組合，包括 GPL 和LGPL。這種靈活性有助于與其他開源項目進行集成。（4）修改的可追溯性：如果對軟件進行了修改，MPL 要求在修改的文件中清晰地注明修改的地方，并提供原始文件的副本。MPL 通常被用于開源項目，特別是 Mozilla 基金會的項目，如 Firefox 瀏覽器。由于其相對靈活的授權和與其他許可證的兼容性，MPL 適用于需要保護原始代碼的作者權益，同時希望與其他開源項目集成的情況?？傮w而言，MPL 是一種綜合了開源原則和對作者權益保護的許可證，適用于多樣化的開發場景。

39、（八）木蘭許可證（八）木蘭許可證木蘭開源許可證是由北京大學牽頭，依托全國信標委云計算標準工作組和中國開源云聯盟，聯合國內開源生態圈產學研各界優勢團隊、開源社區以及擁有豐富知識產權相關經驗的眾多律師，在對現有主流開源協議全面分析的基礎上，共同起草、修訂并發布的開源許可證。目前，木蘭開源許可證共有 3 個版本：“木蘭寬松許可證”第 1 版、“木蘭寬松許可證”第 2 版和“木蘭公共許可證”。其中，“木蘭寬松許可證”第北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou

40、Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty182 版（MulanPSL v2）于 2020 年通過開源促進會（OSI）認證，被批準為國際化開源許可證。木蘭寬松許可證具有以下特點：（1）木蘭許可證內容以中英文雙語表述，中英文版本具有同等法律效力，方便更多的開源參與者閱讀使用，簡化了中文開發者進行法律解釋時的復雜度。（2）木蘭許可證明確授予用戶永久性、全球性、免費的、非獨占的、不可撤銷的版權和專利許可，

41、并針對目前專利聯盟存在的互訴漏洞問題，明確規定禁止“貢獻者”或“關聯實體”直接或間接地（通過代理、專利被許可人或受讓人）進行專利訴訟或其他維權行動，否則終止專利授權。（3）為保護“貢獻者”的切身利益，木蘭許可證明確不提供對“貢獻者”的商品名稱、商標、服務標志等的商標許可。（4）木蘭許可證經技術專家和法律專家共同修訂，在明確合同雙方行為約束的前提下盡可能地精簡條款、優化表述，降低產生法律糾紛的風險3。（九）開源許可證的兼容性問題（九）開源許可證的兼容性問題開源許可證的兼容性是指不同開源許可證之間的關系，即一個軟件項目可以使用同時受到不同許可證保護的組件，并確保這些組件在合法范圍內相互協作。當將適

42、用不同許可證的開源程序代碼進行合并或者鏈接時，如果各個許可證的限制或條件沒有沖突，我們就可以說這些許可證是兼容的。了解兼容性是開發者和組織在選擇、組合和分發開源軟件時的關鍵考慮因素。常見的代碼組合方式有兩種，即合并或者使用庫鏈接，下表對常見開源許可證的兼容性進行了分類：3來源：紅山開源平臺微信公眾號 https:/ 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Ha

43、ikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty19圖 1開源許可證兼容性列表（合并代碼）4圖 2開源許可證兼容性列表（使用庫鏈接）5三、開源軟件合規風險三、開源軟件合規風險開源軟件現已被廣泛運用于商業軟件的開發與使用中。但企業在引入開源技術的同時，如果沒有遵守開源軟件使用的規則，往往會給企業帶來各種法律風險。（一）知識產權風險（一）知識產權風險4來源：可信開源合規計劃開源合規指南（企業篇）第 33 頁。5來源：可信開源合規計劃開源合規指南（企業篇）第 33 頁。北京 上海 深圳 廣州 武漢 成都 重慶

44、青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty201、著作權侵權風險著作權侵權風險包括以下幾點：未經授權的復制和分發：企業在使用開源軟件時必須遵循許可證的規定，包括復制和分發源代碼的條件。如果企業未經授權就復制、修改或分發軟件的源代碼，可能觸發著作權侵權。修改代

45、碼而未共享：開源軟件通常允許用戶修改源代碼，但在對源代碼進行修改后，必須按照相同的許可證要求分享修改后的代碼。如果企業對開源軟件進行了修改但未共享這些修改，可能導致著作權侵權指控。依賴未授權版本：企業可能依賴于開源軟件的特定版本，但如果未經許可證允許就對軟件進行修改，可能會侵犯原始作者的著作權?；旌鲜褂貌患嫒莸脑S可證軟件：當企業同時使用具有不同許可證的開源軟件時，許可證之間可能存在不兼容性。這可能導致著作權侵權的問題，特別是在涉及較嚴格的許可證（如 GPL）時。2、專利侵權風險使用開源軟件的專利侵權風險來源于內部、外部兩個方面。第一，內部專利侵權風險，是指開源軟件可能包含了被專利保護的技術，尤

46、其是一些先進和創新的功能。如果企業在未經授權的情況下使用了這些技術，可能會觸發專利侵權。有些開源許可協議（如 Apache 2.0）明示了專利授權且存在專利報復條款，內部專利風險相對較小。然而，部分開源許可協議（如BSD、MIT 等）沒有明示專利許可規定，開源軟件的開發者或者貢獻者可以向開源軟件使用者提起專利訴訟并收取專利許可費，因此內部專利風險較大。第二，外部專利侵權風險，是指不受開源許可協議約束的第三方向開源軟件使用者發起專利訴訟，聲稱所述開源軟件使用了其專利。例如微軟就曾表示過包括 Linux 在內的開源軟件使用了微軟的專利，微軟曾向谷歌以及眾多手機北京 上海 深圳 廣州 武漢 成都 重

47、慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty21廠商如富士康、京瓷、三星等提起了專利侵權訴訟，要求其向微軟支付專利使用許可費。這些案件后來多以雙方簽訂了專利許可協議，向微軟支付專利許可費的方式達成了和解。3、商標侵權風險在使用開源軟件時，企業可能未經授權地

48、使用了該軟件的商標，包括軟件的名稱、標志或其他標識。這可能觸發商標侵權指控。如果其商標與該軟件或其開發者的商標相似，可能引起混淆，使人誤認為兩者有關聯，也可能導致商標侵權糾紛。因此企業在使用開源軟件時應當認真了解開源軟件的商標使用規定，確保在商標使用方面遵循合規要求，以降低商標侵權風險。4、商業秘密風險開源軟件的商業秘密侵權風險涉及到企業在使用、修改和分發開源軟件時可能泄露其內部商業秘密的可能性。商業秘密侵權風險可能源于對軟件代碼、配置、算法等方面的不當處理，使得企業的核心業務信息可能被揭示。一是被迫公開商業秘密的風險。開源軟件通常提供源代碼供用戶審查和修改。企業在使用這些源代碼時，如果未能進

49、行適當的審查，可能無意中將其自有商業秘密混入到公開的代碼中，代碼若受到著佐權類開源許可證的“傳染”而可能需要被迫開源，則可引起商業秘密公開的風險。二是商業秘密被非法獲取的風險。惡意的開源軟件可能包含后門，通過這些后門，黑客可以訪問企業的敏感信息，包括商業秘密。如引入的開源軟件存在惡意代碼、病毒或其他安全漏洞，可能引起內部系統商業秘密泄露的風險；他人未經企業批準擅自在開源社區上貢獻源代碼，也可能引起企業商業秘密的泄露風險。為減少商業秘密侵權風險，企業應當實施全面的開源軟件管理策略，包括審查、清理和安全審計源代碼，選擇可信賴的開源軟件，遵守開源許可協議的北京 上海 深圳 廣州 武漢 成都 重慶 青

50、島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty22規定，并保障企業的商業秘密得到妥善保護。（二）企業商譽風險（二）企業商譽風險對于未遵守開源許可證的企業，開源軟件的權利人等可能會發文進行輿論聲討，或加入“恥辱黑名單”進行輿論譴責，引起企業商譽受損的風險。例如Ony

51、x 的電子書設備是在 Linux 內核基礎上的改版，而 Linux 內核遵循 GPL 許可證，要求二次分發項目也必須開源，然而 Onyx 拒絕發布其源碼。Onyx 的態度激起許多人的不滿，部分批評者認為 Onyx 事件暴露了很多廠商不尊重開源協議的現狀。（三）數據合規風險（三）數據合規風險近年來，隨著人工智能技術的發展，開源軟件在人工智能領域的應用和推動作用愈發顯著，許多先進的機器學習算法和深度學習模型以開源方式發布，也有公司直接開源了自己的 AI 開發框架，推動了 AI 技術的廣泛應用。企業在選擇這些 AI 開源工具時，要注意遵守我國在人工智能領域的監管法規，關注數據合規風險。根據生成式人工

52、智能服務管理暫行辦法，提供生成式人工智能服務在數據安全方面應當遵守中華人民共和國網絡安全法、中華人民共和國數據安全法、中華人民共和國個人信息保護法等法律法規的規定。因此，若開源軟件的數據來源和使用涉及個人信息侵權行為，可能給用戶造成數據合規風險。同時，開源軟件生成數據是否包含違法信息，也可能導致用戶面臨相應風險。此外，提供生成式人工智能服務應當進行安全評估（評估內容包括信息服務的合法性、落實安全措施的有效性、防控安全風險的有效性等），同時應當履行算法備案義務。四、企業開源合規體系的構建四、企業開源合規體系的構建（一）企業開源合規團隊的組成（一）企業開源合規團隊的組成北京 上海 深圳 廣州 武漢

53、 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty23當企業在日常運營中廣泛采用開源軟件時，確保其合規性變得至關重要。為了有效應對開源合規的復雜性，企業需要建立一個專業的開源合規團隊。該團隊應該由法務團隊、技術人員和外部律師組成，各部門之間需要密切合作

54、，以應對開源帶來的風險。首先，法務團隊在企業開源合規中扮演著核心角色。他們負責解析各種開源許可證的法律要求，并監督企業的開源軟件策略。法務團隊需要與技術團隊協作，確保開發人員理解和遵循許可證條款，同時制定和更新內部開源合規政策，以適應不斷變化的法律環境。其次，技術人員是實施開源合規政策的關鍵執行者。他們需要理解開源軟件的技術細節，確保企業在使用、修改和分發開源代碼時不違反相關許可證。技術團隊與法務團隊之間的協作至關重要，以確保技術實踐與法律要求保持一致。技術團隊還需要定期審查和更新企業使用的開源軟件，以及時解決潛在的合規性問題。為了獲取專業法律意見和支持，企業還需要與外部律師建立戰略合作關系。

55、外部律師通常具有深厚的開源法律知識，特別是在復雜的許可證問題上能夠為企業提供法律咨詢服務。他們可以幫助企業制定更為精準和可操作的開源合規策略，并在爭議出現時提供必要的支持?？绮块T協作是確保開源合規成功的關鍵。團隊成員之間的有效溝通和信息共享是保持一致性和高效合作的基礎。協作工具和平臺可以加強團隊之間的聯系，確保信息及時傳遞。此外，定期的培訓和會議有助于確保團隊對最新法規和最佳實踐保持敏感，并促進共識的形成。通過建立強大的企業開源合規團隊，并通過跨部門協作，企業可以更好地管理開源軟件的復雜性，確保其在法律和技術層面的合規性，為可持續的業務發展提供堅實的法律基礎。北京 上海 深圳 廣州 武漢 成都

56、 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty24（二）搭建企業開源合規知識庫（二）搭建企業開源合規知識庫搭建一套全面而高效的企業開源合規知識庫可以有效提高企業開源合規的協作效率。知識庫主要包括以下內容：1、開源許可證快捷查詢手冊制定開源許可證快捷查詢手

57、冊是構建知識庫的基礎。該手冊應當涵蓋各種常見開源許可證的要點和風險提示，并提供簡明扼要的解釋，為法務和技術人員提供便捷的可操作的參考。由于許可證的種類繁多且條款和限制各異，因此一個簡便而詳實的查詢手冊能夠迅速幫助企業團隊了解和判斷許可證的影響。2、開源許可證分組策略采用開源許可證分組策略有助于更系統地管理開源許可證的復雜性。根據不同許可證的傳染性強弱以及公司的實際需求等可以將許可證劃分為不同的組別，如自由使用組許可證組、審查批準許可證組、禁止使用許可證組等，不同組別需要遵循相應的使用標準和審查流程。3、開源合規工具在構建開源合規知識庫時，利用先進的開源合規分析工具尤為重要。如使用軟件成分分析工

58、具對源代碼進行掃描，識別出使用的開源組件，然后對其進行審計，以確定是否存在未經許可的使用、許可證沖突、已知的安全漏洞等問題。這種自動化的分析工具能夠極大地提高效率，減輕團隊的工作負擔，并為企業提供準確的許可證合規狀態和風險評估，使其能夠及時采取必要的措施。（三）制定合規的軟件開發流程（三）制定合規的軟件開發流程為了更全面地確保軟件開發流程在使用開源軟件方面合規，引入軟件構建材料清單（SBOM）是至關重要的一環，企業必須了解自身的產品中使用了哪些開源軟件6。首先，開發團隊在軟件開發流程的起始階段，應當明確規定對每6Heather Meeker：開源軟件許可實用指南，人民郵電出版社，2023，劉偉

59、譯，第 139-147 頁。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty25個選用的開源軟件組件生成 SBOM 的要求。SBOM 將清晰列出所使用的每個組件及其版本、依賴關系等信息，為整個開發生命周期提供了可追溯的材料

60、清單。在軟件設計和規劃階段，開發團隊需要特別強調對 SBOM 的完整性和準確性的驗證。制定規范，確保 SBOM 中包含準確的許可證信息、漏洞信息等關鍵內容。這有助于降低潛在的法律風險和安全風險，并為后續的合規工作提供實質性的支持。在編碼和測試階段，SBOM 也應成為開發人員的參考依據。在修改或擴展開源代碼時，開發團隊應利用代碼掃描等工具，及時檢查和更新 SBOM，以確保其中的信息與實際代碼保持一致。在測試階段，SBOM 可以用于驗證開源組件的安全性和合規性，幫助開發團隊及時發現和解決潛在問題。在軟件部署和交付階段，SBOM 的角色同樣不可忽視。規范的許可證聲明環節應當基于 SBOM 提供的信息

61、，確保軟件的用戶文檔、安裝說明和相關信息中明確列出了所使用的所有開源組件及其相應的許可證信息。在軟件維護和更新階段，開發團隊可以借助 SBOM 重新評估和驗證每個開源組件，以確定是否需要更新或替換。SBOM 還可以用于有效地進行漏洞管理，定期檢查和更新 SBOM 以反映最新的安全和合規狀況。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo

62、 Hong Kong London New York Los Angeles San Francisco Almaty26第三部分中國開源軟件司法實踐第三部分中國開源軟件司法實踐北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Alma

63、ty27中國開源軟件司法實踐中國開源軟件司法實踐開源軟件不是公共領域軟件，其享有著作權并受著作權法保護，如果企業沒有按照開源許可協議的規定使用開源軟件，則存在很大的著作權侵權風險，甚至卷入訴訟糾紛。我國涉及開源軟件的司法案件并不太多，本章將對其中的典型案例進行整理，幫助讀者理解目前我國法院在開源軟件領域的主流觀點和裁判規則。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nan

64、jing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty28案件名稱案件名稱案件摘要案件摘要法院觀點法院觀點典型意義典型意義天創科技訴阿凡提案阿凡提公司在其運營的網站使用了原告依法享有著作權的 ShopNC 電商系統系列計算機軟件，ShopNC 軟件系采用PHP+MYSQL 軟件編寫軟件使用手冊的開源性質 CC 許可證并不等同于軟件的許可證，PHP 軟件是否開源及開源權利取決于PHP軟件作者選擇何種許可證。該案明確了與作為編寫工具的計算機語言之間不存在承繼或衍生關系數字天堂訴柚子科技案柚子公司的AP

65、ICloud 使用了原告 HBuilder 軟件三個插件的GPL開源代碼，侵 害 了 其 對HBuilder 享有的軟件著作權涉案三個插件的文件夾中并無GPL開源協議文件，而涉案軟件的根目錄下亦不存在GPL開源協議文件的情況下，該協議對于涉案三個插件并無拘束力該案為我國司法實踐中涉及GPL開源協議的第一案，表明我國法院承認GPL協議在中國具有法律約束力。羅盒訴風靈案原告開發的羅盒軟件適用“點心桌面”的軟件適用 GPL3.0協議（后刪除該條款），被告開發的“點心桌面”與原告軟件構成實質性相似GPL3.0 協議具有合同性質，被告不履行該協議規定的使用條件，其獲得的授權已自動終止，構成侵權該案明確了

66、開源許可證具有合同性質羅盒訴玩友案被訴侵權軟件中的沙盒分身功能與涉案軟件構成實質性相似，玩友公司收取會員費和不提供開源代碼的行為違反限制商業使用條款和GPLv3協議構成侵權。GPLv3 協議屬于附解除條件的著作權合同，玩友公司違反GPLv3 協議的約定，其依據GPLv3協議獲得的授權自動終止，玩友公司再使用涉案軟件構成侵權。該案明確了屬于附解除條件的非典型著作權許可使用合同閃亮公司訴不亂買案閃亮時尚公司開發的網站運營軟件的相關代碼文件使用雖然不亂買公司認可其前端代碼中使用了GPL協議下的開最高院在二審判決中引用了 GPL.v3 開源協議中對開源傳北京 上海 深圳 廣州 武漢 成都 重慶 青島

67、杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty29了不亂買軟件的源代碼，侵害了其享有的軟件著作權源代碼，但其主張權利的是后端代碼，其后端代碼是獨立于前端代碼的其他程序，并不受 GPL 協議的約束，無需強制開源染性的例外條款。突出體現了基于對程序之間關系的深入分析、綜合

68、判斷涉案程序是屬于“衍生產品”還是“獨立程序”的總體思路。未來公司訴云蜻蜓案未來公司起訴稱，就其享有的“未來網上投標文件制作工作軟件”計算機軟件著作權，云蜻蜓公司侵害了上述計算機軟件著作權主程序部分受GPL協議的傳染和約束，未來公司違反 GPL 協議，對源代碼進行了閉源處理，不應受到保護。預覽程序文件與主程序文件相互獨立，不受 GPL 協議的傳染和影響。本案系全國首起支持GPL抗辯的典型案例。該判決對于受GPL 傳染性條款約束軟件的認定以及軟件產業中關于開源軟件的合理使用規則，具有較強的指引作用。對于開源許可證的法律性質，我國法院在實踐中將開源許可證認定為“附解除條件的著作權許可合同”。這里包

69、含了兩層意思，一是開源許可證具有合同性質，二是開源許可證是附解除條件的許可合同。首先，開源許可證具備合同特征：（1）雙方意愿：合同的成立需要雙方的意愿達成一致。在開源許可證中，著作權持有人（許可方）通過明確的許可條款表達了將軟件授予他人使用的意愿，而使用者（被許可方）通過接受許可條款表達了接受這些使用權利的意愿。（2）法定義務：合同的一方提供某種權利或服務，而另一方則需要履行相應的法定義務。在開源許可證中，許可方提供了特定的軟件使用權利，而被許可方則需要履行許可證中規定的條件，如保留版權聲明、遵循開源許可證的規定等。其次，開源許可證具有附解除條件許可的性質。GPLv3 許可證第 8 條“終止授

70、權”規定，授權人許可用戶在遵守許可證規定的前提下行使某些權利，但用戶必須承擔相應的義務。若用戶違反 GPL3.0 協議的使用條件來復制、修改或傳播受保護的作品，其通過 GPL3.0 協議獲得的授權將會自動終止。一旦用北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles

71、 San Francisco Almaty30戶違反了這些條件，就意味著許可證合同在當事人之間自動解除，用戶基于許可證獲得的授權將會自動終止。用戶之前根據授權已經或正在實施的復制、修改、發布行為便失去了法律依據，違約行為就演變為侵權行為7。與我國民法典第一百五十八條中對于附解除條件的民事法律行為的內涵相一致。一、天創科技訴阿凡提案：作為編寫工具的計算機語言與軟件作品沒有傳染性一、天創科技訴阿凡提案：作為編寫工具的計算機語言與軟件作品沒有傳染性8【案件摘要】【案件摘要】天創科技研發了 ShopNC 電商門戶系統軟件并辦理了計算機軟件登記證書。2016 年，原告發現阿凡提公司在其運營的網站上非法使

72、用了其依法享有著作權的 ShopNC 電商系統系列計算機軟件，遂以侵害計算機軟件著作權為由將阿凡提公司訴至法院。阿凡提公司認為，原告的 ShopNC 軟件系采用 PHP+MYSQL軟件編寫。PHP 和 MYSQL 軟件均屬于開源軟件，PHP 軟件使用基于 GPL 開源協議的 PHPCCPL 開源協議，MYSQL 使用標準 GPL 開源協議。無論是根據CCPL 還是 GPL 開源協議的規定，使用 PHP 和 MYSQL 軟件編寫的 ShopNC軟件作者具有署名權，但是原告不能禁止其他方改編、使用、復制、發表該軟件，也不得向其他方收取軟件使用費用?！痉ㄔ河^點】【法院觀點】法院認為，所涉 PHP 開

73、源軟件中文官網手冊明確以 CC 協議為附帶的開源授權許可協議，需明確的是該軟件使用手冊的開源性質 CC 許可證并不等同于軟件的許可證，PHP 軟件是否開源及開源權利取決于 PHP 軟件作者選擇何種許可證。雖然 PHP 手冊采用了知識共享許可協議，涉案軟件亦采用 PHP 語言編寫，但計算機語言本身具有工具屬性，以特定計算機語言編寫的 ShopNC 軟件作品通過作者創造性的智力勞動所表現的作品獨創性與計算機語言之間并7參見 Heather Meeker：開源軟件許可實用指南，人民郵電出版社，2023，劉偉譯，第 63-70 頁。8詳見（2017）浙 02 民終 3852 號民事判決書北京 上海 深

74、圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty31未體現以后者為基礎的派生關系，故不屬于 PHP 語言演繹作品?！镜湫鸵饬x】【典型意義】該案明確了以特定計算機語言編寫得到的軟件作品體現的是作者就該軟件作品的個性表達，與作為編寫工具的計

75、算機語言之間不存在承繼或衍生關系，兩者之間也不應具有開源傳導性。二、數字天堂訴柚子科技案：我國司法實踐中涉及二、數字天堂訴柚子科技案：我國司法實踐中涉及 GPL 開源協議的第一案開源協議的第一案9【案件摘要】【案件摘要】數字天堂公司開發了軟件 HBuilder，該軟件包括三個插件：代碼輸入法功能插件、真機運行功能插件、邊改邊看功能插件。柚子公司開發了軟件 APICloud。數字天堂公司認為，柚子公司的 APICloud 使用了上述三個插件的 GPL 開源代碼（協議為 GPL3.0），侵害了其對 HBuilder 享有的軟件著作權，起訴到法院請求判決柚子公司承擔賠償損失等法律責任?！痉ㄔ河^點】【

76、法院觀點】一審法院審理認為，涉案三個插件屬于獨立的軟件作品，三個插件的文件夾中并無 GPL 開源協議文件，而涉案軟件的根目錄下亦不存在 GPL 開源協議文件的情況下，盡管涉案軟件其他文件夾中包含 GPL 開源協議文件，但該協議對于涉案三個插件并無拘束力，柚子公司構成著作權侵權。二審法院也認可了 GPL 的法律效力?！镜湫鸵饬x】【典型意義】該案為我國司法實踐中涉及 GPL 開源協議的第一案，該案涉及到的關鍵問題是 GPL 協議的“強傳染性“問題，一審法院大篇幅引用了 2007 年 6 月發9詳見（2018）京民終 471 號民事判決書北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 海

77、口 東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty32布的 GPL 協議第 3 版的規定，二審法院也同樣接受了一審法院關于 GPL 協議效力問題的論述。這表明我國法院承認 GPL 協議在中國具有法律約束力。但根據一二審法院的裁判結果來看，法院沒有結合開源協議傳染性條款相關內容和軟件技術

78、細節進行深入審查討論，判斷依據簡單，在認定涉案軟件是否適用“傳染性”的問題上仍有進一步商榷討論的空間。三、羅盒訴風靈案：開源許可證具有合同性質三、羅盒訴風靈案：開源許可證具有合同性質10【案件摘要】【案件摘要】原告濟寧市羅盒網絡科技有限公司獨立開發“羅盒（VirtualApp）插件化框架虛擬引擎系統 VirtualAppV1.0”（以下稱涉案軟件），其在國際著名的軟件托管平臺 GitHub 上公開了涉案軟件的源代碼，并于 2017 年取得計算機軟件著作權登記證書。VirtualApp 從 2016 年 7 月 8 日的版本開始引入開源協議，起初為 LGPL3.0 協議，2016 年 8 月 1

79、2 日更換為 GPL3.0 協議。2017 年 10 月 29日，原告在 VirtualApp 后續開源版本中刪除“適用 GPL3.0 協議”的表述。2019年，原告發現名為“點心桌面”的軟件，經過對比源代碼，發現“點心桌面”與涉案軟件構成實質性相似，故提起軟件著作權侵權訴訟?！痉ㄔ河^點】【法院觀點】深圳市中級人民法院認為，1、GPL3.0 協議具有合同性質，系授權人與用戶之間訂立的著作權協議，適用合同法有關規定。2、原告系涉案軟件著作權人，開源軟件維權無需經過所有貢獻者的同意或授權，原告有權提起本案訴訟。3、被告使用了附帶 GPL3.0 協議的開源代碼，卻不履行該協議規定的使用條件，其獲得的

80、授權已自動終止，故其實施的復制、修改、發布等行為，因失去權利來源而構成侵權?！镜湫鸵饬x】【典型意義】10詳見（2019）粵 03 民初 3928 號民事判決書北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty33本案為國內首

81、個明確 GPL 3.0 協議性質的司法裁判案例。法院認定開源協議具有合同性質，在這個版權糾紛案中被告因違反了 GPL3.0 協議導致 GPL3.0協議自動解除，從而失去了 GPL3.0 協議下的源代碼授權保護，進而構成侵權。四、羅盒訴玩友案：開源許可證屬于附解除條件的非典型著作權許可使用合同四、羅盒訴玩友案：開源許可證屬于附解除條件的非典型著作權許可使用合同11【案件摘要】【案件摘要】羅盒公司的股東羅迪在Github網站上傳了其開發的VirtualApp軟件初始源代碼并適用 GPLv3（GNU General Public License Version 3）開源許可協議，另附加聲明任何人如用

82、于商業用途需購買，后又刪除了 GPLv3 協議并停止更新而轉向開發閉源商業收費版。羅盒公司通過受讓方式取得了涉案軟件的著作權并登記。玩友公司開發了四款被訴侵權的微信視頻美顏相機 APP 并上傳于各平臺供用戶下載，但并未提供源代碼下載，用戶可免費試用半小時，之后需付會員費才可繼續使用。羅盒公司提供鑒定報告主張四款被訴侵權軟件中的沙盒分身功能與涉案軟件構成實質性相似，玩友公司收取會員費和不提供開源代碼的行為違反限制商業使用條款和 GPLv3 協議構成侵權，請求判令玩友公司停止提供四款軟件的下載、安裝和運營服務并賠償經濟損失 1500 萬元和維權合理費用 15 萬元?！痉ㄔ河^點】【法院觀點】廣州知識

83、產權法院經審理認為，羅迪是涉案軟件的最主要貢獻者，羅盒公司有權單獨提起本案訴訟。羅盒公司無權在適用 GPLv3 協議的涉案項目中添加商業使用限制保留條款。沙盒分身部分功能代碼是作為被訴侵權軟件的衍生部分而整體發布的，GPL 協議具有高傳染性，故玩友公司未開源整個被訴侵權軟件的源代碼違反協議約定。GPLv3 協議屬于附解除條件的著作權合同，許可11詳見（2019）粵 73 知民初 207 號民事判決書北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan

84、Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty34條款是版權許可的條件。玩友公司違反 GPLv3 協議的約定，其依據 GPLv3 協議獲得的授權自動終止，玩友公司再使用涉案軟件已沒有法律和合同依據，故其構成侵權。本案另外三被告的收款行為無過錯，無需擔責。法院據此判決玩友公司停止侵權行為并賠償羅盒公司經濟損失及維權合理開支 50 萬元。一審判決后，雙方均未提起上訴?！镜湫鸵饬x】【典型意義】該判決就開源協議的法律性質作

85、了進一步的明確，還對開源協議的發展、分類、域外司法觀點等進行了深度分析和解讀，并就 GPLv3 協議的相關規則作了詳細梳理。對開源軟件涉及的諸多問題進行了闡明（例如“軟件集合包”匯編作品中的獨立作品之間是否互相發生傳染，合作作品的判斷標準，開源軟件其他貢獻者提交代碼是否對軟件著作權產生實質影響），同時還明確了重視和支持開源發展的司法態度。本案無疑為開源和閉源軟件的混合經營指明航向，對開源軟件合規治理具有重要的司法指導意義。五、閃亮時尚訴不亂買案：判斷涉案程序是屬于“衍生產品”還是“獨立程序”五、閃亮時尚訴不亂買案：判斷涉案程序是屬于“衍生產品”還是“獨立程序”12【案件摘要】【案件摘要】不亂買

86、公司開發了“不亂買時尚海淘軟件”用于網站運營。閃亮時尚公司也開發了網站運營軟件。不亂買公司認為，閃亮時尚公司的相關代碼文件使用了不亂買軟件的源代碼，侵害了其享有的軟件著作權，起訴到法院請求判決閃亮時尚公司承擔賠償損失等法律責任?！痉ㄔ河^點】【法院觀點】一審法院認為，原告的網頁僅有前端代碼明確使用了開源代碼，原告主張權利的是其后端代碼。二者展示方式不同、所用技術不同、分工亦有明顯區別，12詳見（2019）最高法知民終 663 號民事判決書北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzh

87、en Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty35屬于可獨立的程序。因此根據 GPL3.0 協議的相關規定，該協議對涉案權利代碼并無拘束力。在二審中，被告上訴稱原告的前端代碼和后端代碼存在交互且沒有進行有效隔離，不是相互獨立的。最高院在二審判決中認為，根據 GPL3.0 協議開源傳染性的例外條款對“聚合體”的規定，閃亮時尚公司所稱 GPL 協議的“傳染性”應當是指 GPL 協議

88、的許可客體不僅限于受保護程序本身，還包括受保護程序的衍生程序或修訂版本，但不包括與其聯合的其他獨立程序。本案中，雖然不亂買公司認可其前端代碼中使用了 GPL 協議下的開源代碼，但其主張權利的是后端代碼，其后端代碼是獨立于前端代碼的其他程序，并不受 GPL協議的約束，無需強制開源?！镜湫鸵饬x】【典型意義】最高院在二審判決中引用了 GPL.v3 開源協議中對開源傳染性的例外條款。突出體現了基于對程序之間關系的深入分析、綜合判斷涉案程序是屬于“衍生產品”還是“獨立程序”的總體思路。這體現了我國法院對于涉開源協議相關案件審理理論和方法的進步，也更符合開源社區和其他國家司法實踐中的主流思路和方案。六、未

89、來公司訴云蜻蜓案：全國首起支持六、未來公司訴云蜻蜓案：全國首起支持 GPL 抗辯的典型案例抗辯的典型案例13【案件摘要】【案件摘要】未來公司起訴稱，就其享有的“未來網上投標文件制作工作軟件”計算機軟件著作權，云蜻蜓公司侵害了上述計算機軟件著作權。法院審理查明，未來公司主張權利的軟件包含主程序及預覽程序兩個部分。其中，主程序源代碼中存在第三方開源軟件的源代碼，系遵守 GPLv2 開源許可證的開源代碼。未來公司并未遵守開源協議要求，對涉案主張權利的軟件進13詳見（2021）蘇 01 民初 3229 號民事判決書北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約

90、 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty36行了閉源處理?！痉ㄔ河^點】【法院觀點】法院認為，本案的關鍵在于判斷涉案軟件的哪些部分被 GPL 協議所傳染，以及確定自有代碼是如何與開源代碼結合或交互的。被 GPL 協議傳染的部分軟件應當是與原開源軟件形成密切通信使得二者高度牽連融合成一體的程序。本案中，未

91、來公司涉案投標軟件主要包含主程序和預覽程序，應分別評價。主程序受 GPL 開源代碼的影響。涉案開源代碼所涉功能系涉案主程序運行、上傳等不可或缺的功能，主程序部分受 GPL 協議的傳染和約束，未來公司違反 GPL 協議，對源代碼進行了閉源處理，若該行為給予侵權法上的保護，勢必虛置 GPL 協議關于源代碼持續開源的相關規定，對 GPL 協議關于源代碼的持續開源傳播產生不利影響。因此，法院對主程序部分認定不構成著作權侵權。首先，預覽程序部分不受 GPL 協議的傳染和影響。預覽程序文件與主程序文件相互獨立，其實現獨立的查看投標文件的功能，并非用戶制作、上傳投標文件所必需。預覽程序文件連同不包含 GPL

92、 開源代碼的 DLL 文件，脫離主程序后在新目錄下能夠獨立運行。主程序目錄下刪除預覽程序文件后，主程序亦能獨立運行。其次，預覽程序構成實質性相似。法院認定，預覽程序部分的相似度為 79.36%，云蜻蜓公司構成侵權?！镜湫鸵饬x】【典型意義】本案系全國首起支持 GPL 抗辯的典型案例。南京中院在全國首次認定，受 GPL 傳染性條款約束的軟件，若違反 GPL 協議關于源代碼持續開源的約定，則對權利人的權利主張不予支持。該判決對于受 GPL 傳染性條款約束軟件的認定以及軟件產業中關于開源軟件的合理使用規則，具有較強的指引作用。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港

93、 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty37北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingda

94、o Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty38第四部分域外開源軟件案例解讀第四部分域外開源軟件案例解讀北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York

95、 Los Angeles San Francisco Almaty39一、一、Jacobsen 訴訴 Katzer 案：違反開源許可協議是選擇違約之訴還是侵權之訴？案：違反開源許可協議是選擇違約之訴還是侵權之訴？14【案件摘要】【案件摘要】原告 Robert Jacobsen 是“Java 模范鐵路操作接口(Java Model RailroadInterface,JMRI)”軟件程序開發小組的管理者，該開發小組研發出了一套名為“解碼博(DecoderPro)”的軟件程序，同時以“開源代碼(open source)”中所謂的技術許可(Artistic License)的方式放置在一個名為 So

96、urce Forge 的網站來供其他的使用者無償下載。被告 Katzer 開發了一套與原告從事競爭、名為“解碼指揮官(Decoder Commander)”的軟件程序。原告認為被告的一名軟件工程師下載了原告的軟件，并將其中的定義檔(definition file)和其他部分程序納入到了“解碼指揮官”軟件中，被告在使用原告的定義檔時沒有符合關于許可的要求，從而構成對其著作權的侵權行為。具體行為是，“解碼指揮官”并未列示(1)原始作者的姓名、(2)JMRI 的著作權說明、(3)其許可內涵為技術許可以及出處、(4)JMRI 或 SourceForge 為其定義檔的原始來源、以及(5)其程序代碼是如何

97、從原始碼予以改變等?！痉ㄔ河^點】【法院觀點】一審中，聯邦地方法院認為，“開源代碼”之中的技術許可本質是一個范圍極為廣泛的非專屬許可(“intentionally broad”non-exclusive license)。這種許可并沒有限制，因此也就沒有著作侵權的問題，原告僅能以違約起訴，因此沒有同意原告要求頒布暫時禁制令的要求。原告遂針對其是否具有主張著作侵權的訴因(cause of action)的部分提起上訴。二審聯邦巡回上訴法院撤銷(vacate)了聯邦地方法院的原判決，并將本案發回重審(remand)。其理由是認為原告在14參見 Jacobsen v.Katzer,535F.3d 13

98、73,1379(Fed.Cir.2008).北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty40網站上公布的技術許可協議，被許可方使用的前提是同意其提出的具體事項，如果被許可人未能遵從這一前提，那就沒有權利獲得該項技術許可

99、。因而被告的行為涉嫌構成侵權行為，應當予以重審?！镜湫鸵饬x】【典型意義】該案厘清了開源許可協議的條款性質，指出許可條款中對于被許可人的義務需要區分是作為著作權許可的條件（condition）還是對于許可合同一般義務的約定（covenant）。如果屬于許可的條件，那么一旦違反，則被許可人的行為已經超過了許可的范圍，許可人可以以著作權起訴。如果屬于一般義務的約定，則相關違約事項則應當按照合同法相關規定論處。從該案例可以看出，許可協議中條款的設計非常關鍵，一旦約定不明或者不能將被許可人的義務解釋為獲得許可的前提，則著作權人有可能喪失通過著作權侵權的方式主張權利，而只能通過違約之訴來主張被許可人的違約

100、責任。二、二、Christopher Helwig 訴訴 Vmware 案：自由軟件開發者依據案：自由軟件開發者依據GPL 協議主張權利協議主張權利15【案件摘要】【案件摘要】2006 年，Christopher Helwig 發現 Hypervisor vSphere VMware ESXi 5.5.0軟件使用了 Linux 源代碼，但是并沒有開源相關管理程序組件，其行為違反了 GPL2.0 協議的約定。2015 年 Christopher 在軟件自由保護協會的幫助下起訴了 VMware，而 2016 年，法院駁回了該訴訟請求，后 Christopher 提起上訴，但最終還是被駁回。該案件中

101、，法院并沒有處理實質性問題，而是從程序上否定了 Christopher 的訴權?！痉ㄔ河^點】【法院觀點】法院認為，Christopher 沒有充分的證據表明被告組件的所有權或版權屬于15參見 Hamburg District Court,Christoph Hellwig v.Vmware,August 2016北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing H

102、aikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty41Linux，所以在一審、二審中均駁回了原告的訴請。具體而言，Christopher 未能在 VMware 產品中確定他擁有版權的特定代碼行，因此其不能證明自身是適格的原告?！镜湫鸵饬x】【典型意義】本案相較于其他 GPL 協議有關案件引發了眾多關注，因為在本案中，涉及到對 GPL 具體條款范圍的解釋問題。該案中，被告 Vmware 是從 Linux 內核重新調整用途的代碼，而調整后的代碼包含在 VMware 的 ESXi 中運行的模塊中，被告還對 ESX

103、i 代碼進行了相關修改。如果法院對實體進行審查，則勢必要對 VMware 將 ESXi 的 vmkernel 與包含 Linux 內核代碼的模塊（vmklinux）相結合的方式是否會導致 vmkernel 受 GPL 約束的問題進行回答，很遺憾的是，法院回避了這一問題，而是從程序性的問題上解決本案的爭議，這也導致自由軟件開發人員會很難根據 GPL 協議單獨主張自身的權利。三、三、Harald 訴訴 D-Link 案：德國法院認為開源協議屬于一種不需要被許可人做出聲明承諾的著作權許可協議案：德國法院認為開源協議屬于一種不需要被許可人做出聲明承諾的著作權許可協議16【案件摘要】【案件摘要】原告 W

104、elter 是 GPL-violations.org 開源社區項目負責人，其受讓了三項軟件的著作權，上述軟件在開源軟件發布并且使用 GPL 協議。被告 D-Link 公司研發售賣的產品使用了原告 Welter 的三項軟件，但未附上 GPL 開源許可證協議、完整的源代碼、原作者著作權標示和無擔保聲明。Welter 向 D-Link 公司發送了警告信，要求其停止著作權侵權行為、披露有關信息并賠償其經濟損失?！痉ㄔ河^點】【法院觀點】法院認為，根據德國民法典第 305 條規定，GPL 開源協議的性質如同一般合同，根據德國民法典第 151 條的規定，其無須被許可人的任何承諾16參見 District C

105、ourt of Frankfurt am Main，In re Welte v D-Link Deutschland GmbH，September 22，2006北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty42或者聲明

106、，被許可人即與許可人形成合同關系，該開源協議具有法律效力。既然開源協議約定了軟件使用人在復制、修改、再授權或發布軟件時應附上 GPL開源許可證協議、完整的源代碼、原作者著作權標示和無擔保聲明等有效條款，那么被告作為被許可人就有義務負擔上述行為。本案中，被告違反上述合同義務，其使用許可軟件的行為應當無效，其無權獲得 GPL 協議中的授權權利。因此最終法院支持了原告的訴求，要求被告 D-Link 公司承擔停止侵權、披露信息、賠償損失的法律責任?！镜湫鸵饬x】【典型意義】本案是德國法院針對開源協議性質發表觀點的典型案例，在德國法中，法院對于開源協議屬于一種具有法律約束力的著作權許可合同的觀點基本已經達

107、成一致。這種特殊的合同關系中，并不需要被許可人做出簽字、蓋章等形式上的行為，而只要使用該軟件，就可以視為合同關系成立。當被許可人違反該合同時，權利人可以選擇主張違約責任，也可以主張侵權責任，其承擔侵權責任的方式主要有停止侵權、披露信息、賠償損失等。四、四、Harald 訴訴 FANTEC 案：產品銷售者對于產品是否符合開源協議要求同樣具有審核義務案：產品銷售者對于產品是否符合開源協議要求同樣具有審核義務17【案件摘要】【案件摘要】FANTEC 銷 售 的 一 款 媒 體 播 放 器 中 使 用 的 一 款 軟 件 中 包 含 了netfilter/iptables，該軟件的著作權人是 Hara

108、ld Welte，其通過 GPL2.0 協議以開源軟件的形式對公眾免費提供軟件。Harald Welte 發現 FANTEC 沒有依照 netfilter/iptables 采用的授權條款-GNU General Public License v2.0(GPL-2.0)的 要 求，向 用 戶 取 得netfilter/iptables 程序源碼的配套，該行為已經違反了 GPL-2.0 授權程序的使17參見 Regional Court of Hamburg,Harald v.FANTEC,June 2013北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約

109、 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty43用規則。因此 Harald Welte 在向 FANTEC 告知侵權但是協商失敗之后向法院提起了訴訟。FANTEC 的抗辯理由主要是其只是經銷商，其產品是通過中國供應商采購的，中國供應商保證源代碼是完整的?！痉ㄔ河^點】【法院觀點】法院認為，FANTEC 作為

110、制作商和分銷商，有義務審查其產品是否符合開源協議的要求，其依賴上級軟件供應商的保證不是有效的抗辯理由。另一點被告提出額外審查需要額外付費，這也不是逃避義務承擔的理由，其應當對自身產品不侵犯他人權利承擔相應的義務。很明顯，FANTEC 違反了 GPL2.0 協議的要求，沒有按照協議要求提供完整的源代碼，因此其喪失了 GPL2.0 協議所許可使用相應軟件的權利。最后法院判決FANTEC應當支付原告合同罰款5100歐元，以及原告的律師費和其他費用。此外，被告還需要提供有關媒體播放器銷售的詳細信息，以確定應向原告支付的許可費用金額?！镜湫鸵饬x】【典型意義】本案中的被告是產品的銷售者，其對于采購的軟件未

111、盡到相應的審查責任，這也說明開源合規審查應當被企業重視，任何采購產品中含有軟件產品的，企業都應當有相應的合規審查義務，否則一旦所銷售的產品違反開源協議，所使用的開源軟件就不再具有合法授權。這對于企業的產品銷售無疑會產生巨大打擊，即使企業后續可以根據合同違約責任要求軟件提供方承擔責任，但是也不能作為本次著作權侵權案件的有效抗辯，仍然會對企業造成嚴重的損害。因此，提前做好合規安排，建立開源合規審查制度是預防風險的重要手段。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangz

112、hou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty44第五部分關于建立開源平臺的合規要求第五部分關于建立開源平臺的合規要求北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjin

113、g Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty45開源風險與合規建設開源風險與合規建設一、關于開源平臺運營者的合規要求二、關于開源項目的出口管制合規要求三、關于開源社區司法管轄權的合規要求四、關于知識產權風險的合規要求五、關于合同糾紛風險的合規要求六、關于網絡安全的合規要求北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongq

114、ing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty46一、關于開源平臺運營者的合規要求一、關于開源平臺運營者的合規要求（一）開源平臺/開源平臺的運營者需要遵守相關國家的法律法規、監管要求、以及文化習慣。在守法的基礎上，帶動當地的開發者投入到開源的貢獻之中。（二）開源平臺的運營者需要根據各國政府的監管要求成立合法的運營主體、并取得相應的資質。例如中國大陸需要成立社會團體、基金會、或社會服務機構等主體來運營；對于開源平臺網站，則至少需要辦理 ICP

115、備案。二、關于開源項目的出口管制合規要求二、關于開源項目的出口管制合規要求通常來說，開源項目不會受到出口管制的限制，但需要關注各國出口管制立法方面的變化，一旦法律規定有變化，則可能會對開源平臺/開源項目產生一定的影響。為降低出口管制等因素對中國企業的影響，建議：1.對于通過托管方式運營的開源項目，可以建立該等托管平臺在中國境內的鏡像平臺，以降低由于受限而無法訪問第三方托管平臺的風險；2.建議采用在公共庫設立開源項目的方式來運營開源項目，以降低托管平臺可能采取限制訪問等措施的運營風險；3.設立開源項目時，可以進行內部評估，對于可能涉及重大商業秘密或國家安全的開源項目，建議通過自建平臺在國內運營；

116、4.在通過第三方托管平臺運營管理開源項目時，可考慮同時將用戶盡量引流至自建平臺上，以逐步擴大自建平臺的影響力，從而建立自身的開源生態系統。三、關于開源社區司法管轄權的合規要求三、關于開源社區司法管轄權的合規要求（一）開源社區的運營和開源項目的開展都是基于開源平臺與用戶之間所北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kon

117、g London New York Los Angeles San Francisco Almaty47簽訂的協議，包括用戶協議以及平臺公開的管理規則（開源社區決策規則、生態角色規則、項目決策規則等）。因此，需要關注此等開源平臺或社區的規則的具體內容（包括司法管轄權），在考慮相應風險的基礎上選擇合適的開源平臺。例如，GitHub 服務條款規定，平臺用戶與 GitHub 之間的協議以及對網站或服務的任何訪問或使用，均受美國聯邦法律和加利福尼亞州法律的管轄，不考慮沖突法原則。（二）開源項目牽涉開源許可協議，而某些開源許可協議會制定有關司法管轄權的特殊條款，需要特別關注。企業在使用到此等開源項目中的

118、開源代碼時，需要關注司法管轄權可能會對自身運營項目帶來的實際影響和相關風險。四、關于知識產權風險的合規要求四、關于知識產權風險的合規要求（一）對于企業主動選擇開源的項目而言，需要在開源之前做好軟件著作權登記、商標注冊申請、專利申請等前期的工作，只有這樣才能在開源的同時保護好自己，而且一旦出現后續貢獻者或使用者不遵守開源許可證的情況，也可以拿起知識產權的武器維護自身的合法權益。此外，在主動開源時，企業還需要考慮開源平臺的知識產權風險、以及開源項目的知識產權許可范圍，選擇合適的開源許可證。例如，企業需要研究開源平臺/開源項目許可證對知識產權歸屬、侵犯第三方知識產權時的免責等相關規定。在許可證的選擇

119、上，如果考慮僅在版權方面給予許可，可以考慮選擇 MIT、BSD 等許可證；如果考慮對版權和專利權都給予許可，則可以考慮 Apache、木蘭許可證等許可證。（二）在企業選擇直接使用開源代碼時，也需要在研究開源許可證之余，重點關注這些代碼來源方的知識產權風險，避免侵犯第三方的知識產權。例如，在相關開源許可證對專利權的使用未作約定，而代碼來源方又持有相關專利的情況下，應當審慎做出是否使用此類開源代碼的決定。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan

120、 Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty48（三）關注知識產權的權屬問題：由于貢獻者、開發者、審批者、平臺本身都可能參與到項目開發中，因此版權、專利權等知識產權的歸屬需要通過 章程、開源許可證、用戶協議等多種協議及平臺規則進行明確規定，以防止在項目開發過程中產生的專利權發生權屬糾紛，進而影響到開源項目的推進。必要時，需要平臺參與各方簽署相關協議（例如會員協議）來事先約定原始代碼或軟件版本/后續修改代碼或軟件

121、版本的版權/專利權歸屬。（四）根據不同平臺構建模式制定不同的知識產權政策：對于自建平臺，可以通過開源社區規章或自制開源許可證的方式對平臺會員捐獻或自主開發的開源項目進行知識產權方面的法律規制；對于在托管平臺的項目，可以通過設立項目聲明的方式，要求貢獻者披露其貢獻代碼是否包含第三方代碼等信息，以避免知識產權等方面的風險。五、關于合同糾紛風險的合規要求五、關于合同糾紛風險的合規要求（一）對于自建平臺而言，章程、開源許可證、用戶協議、貢獻者協議、隱私政策等相關平臺文件構成平臺運營者與用戶（包括貢獻者）之間的合同約定。因此需要規范與平臺和項目運營有關的規范文件，以防范合同糾紛風險。以開源許可協議為例，

122、可以考慮在自建平臺上制定符合自身定位和需求的開源許可協議，對版權、專利權、商標權、免責聲明等各方面進行有選擇的規范和規定。（二）對于托管在第三方平臺的項目，第三方平臺相關的制度文件（包括用戶協議、貢獻者協議、隱私政策等）以及開源項目的開源許可證和項目聲明等構成開源平臺/開源項目與用戶之間的合同約定。因此，在該等平臺上發布/參與開源項目時，需要遵守此等合同約定，避免產生糾紛。以 Github 等第三方托管平臺為例，需要特別注意其用戶協議中的免責北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai She

123、nzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty49條款，以免發生爭議。此外，以開源許可協議為例，第三方托管平臺上通常會提供相應的許可證選擇范圍，可以考慮直接選用，但若想自制開源許可證，則可能受到一定的限制。六、關于網絡安全的合規要求六、關于網絡安全的合規要求（一）采取相應的技術措施保障網絡安全、穩定運行，并對網絡安全事件制定應急響應預案，以維護網絡正常運行。（二）落實國家

124、網絡安全等級保護制度要求，開展信息系統等級保護測評及備案工作。另外，需要注意履行作為網絡運營者的相關義務，例如注意通過相關規章和制度來規范網絡日志留存期限（不得少于六個月）的管理。（三）在對開發者或普通用戶的注冊登錄過程中采集用戶信息的行為進行規范管理，征得用戶的知情同意，并滿足合法、正當、必要等原則。此外，在維護和管理用戶信息的過程中，需要特別注意防止用戶信息的泄露，在發生泄露時應當按照相關法規的要求，立即采取補救措施，按照規定及時告知用戶并向有關主管部門報告。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing S

125、hanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty50第六部分 開源合規適用法律以及相關政策第六部分 開源合規適用法律以及相關政策北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongq

126、ing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty51開源合規適用法律以及相關政策開源合規適用法律以及相關政策一、開源合規適用法律法規二、開源首次列入國家“十四五”規劃和 2035 年遠景目標綱要三、關于加快推動區塊鏈技術應用和產業發展的指導意見強調開源的重要性四、央行等五部門聯合發布關于規范金融業開源技術應用與發展的意見五、工信部發布“十四五”軟件和信息技術服務業發展規劃六、中央網絡安全和信息化委員會印發“十四五”國家信息化規劃七、信息安全技術

127、軟件產品開源代碼安全評價方法北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty52一、開源合規適用法律法規一、開源合規適用法律法規開源軟件合規涉及到多個法律法規，其中一些主要的法律包括全國代表大會及其常委會制定的包括民法典著

128、作權法在內的法律，國務院制定的著作權條例計算機軟件保護條例信息網絡傳播權保護條例著作權集體管理條例在內的行政法規，以及最高人民法院制定的包括最高人民法院關于審理著作權民事糾紛案件適用法律若干問題的解釋最高人民法院關于審理技術合同糾紛案件適用法律若干問題的解釋最高人民法院關于審理侵害信息網絡傳播權民事糾紛案件適用法律若干問題的規定在內的司法解釋。對于這些法律法規和司法解釋的適用順位，根據特別法優于一般法的原則，應首先適用著作權法、著作權實施條例、計算機軟件保護條例等特別法律規范；然后適用民法典合同編中的一般規定；再次則參照民法典中的技術合同等有名合同的規定，在民法典頒布后修正的技術合同司法解釋中

129、對此也作出了規定。以下對其中的主要法律法規進行介紹：（一）民法典合同編（一）民法典合同編開源許可協議是一種合同，規定了使用、修改和分發開源軟件的條件。在法律層面，合同法的規定對開源軟件的使用和分發關系具有約束力。直接受 民法典中合同編相關規定的調整。（二）著作權法以及著作權法實施條例（二）著作權法以及著作權法實施條例著作權法以及著作權法實施條例是軟件著作權保護的主要法律法規。根據該法，軟件的原創者享有對其作品的著作權。開源軟件項目通常會選擇適用特定的開源許可證，以規定對著作權的使用和分發方式。（三）計算機軟件保護條例（三）計算機軟件保護條例計算機軟件保護條例規定了關于計算機軟件保護的一系列法規

130、。這些法規涵蓋了軟件著作權、反盜版、軟件進口等多個方面，與開源軟件的合規性北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty53也有一定關系。（四）反壟斷法（四）反壟斷法民法典中規定了“技術轉讓合同和技術許可合同可以約定實施

131、專利或者使用技術秘密的范圍，但是不得限制技術競爭和技術發展”，是對技術領域反壟斷要求的體現之一。我國的反壟斷法中同樣涉及到與開源軟件相關的競爭政策。在一些情況下，開源軟件的使用可能會涉及到反壟斷法規定的競爭政策，特別是當涉及到市場份額、競爭限制等方面的問題。（五）網絡安全法（五）網絡安全法網絡安全法對涉及網絡的軟件有一系列規定，包括網絡產品的安全評估、網絡安全監管等。開源軟件在涉及網絡使用和開發時需要遵守相關的網絡安全法規。（六）開源與出口管制（六）開源與出口管制在開源軟件使用的過程中，還應關注出口管制的風險。特別是在 AI 領域，用開源軟件來訓練生成式人工智能可能會產生法律風險，風險具體取決

132、于開源軟件的許可證（經許可的或未經許可的），以及訓練數據是否被四處散布。同時如果人工智能相關技術（包括硬件和軟件）被輸出到美國境外，或者該技術在美國境內被傳輸給非美籍人士，在此情況下，美國武器國際運輸條例（ITAR）和美國出口管制條例（EAR）等出口管制可能適用于該技術。將保密信息上傳到“公共的”生成式人工智能的行為可能會被認定為出口行為，并且根據信息的性質可能會受到美國武器國際運輸條例（ITAR）和美國出口管制條例（EAR）的約束。（七）域外法案（七）域外法案美國參議院在 2022 年 9 月發布了2022 保護開源軟件法案，該法案旨在預防開源軟件帶來的安全問題，加強聯邦政府與開源社區的合作

133、，以確保聯北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty54邦政府、關鍵基礎設施和其他機構安全可靠地使用開源軟件。該法案主要規定了美國網絡安全與基礎設施安全局（CISA）在保護開源軟件安全方面的職責等，是全球范圍內首個將

134、開源軟件納入國家關鍵基礎設施的國家立法，也是政府部門對開源軟件的健康和安全進行監管的歷史性一步。二、開源首次列入國家“十四五”規劃和二、開源首次列入國家“十四五”規劃和 2035 年遠景目標綱要年遠景目標綱要182021 年，3 月 12 日，新華社受權發布中華人民共和國國民經濟和社會發展第十四個五年規劃和 2035 年遠景目標綱要，綱要共分為 19 篇，主要闡明國家戰略意圖，明確政府工作重點，引導規范市場主體行為，是我國開啟全面建設社會主義現代化國家新征程的宏偉藍圖，是全國各族人民共同的行動綱領。其中值得關注的是，“支持數字技術開源社區等創新聯合體發展，完善開源知識產權和法律體系，鼓勵企業開

135、放軟件源代碼、硬件設計和應用服務?！笔状伪幻鞔_列入國民經濟和社會發展五年規劃綱要。這可以看出國家已經看到了開源軟件的重要性和開源合規建設的必要性。三、關于加快推動區塊鏈技術應用和產業發展的指導意見強調開源的重要性三、關于加快推動區塊鏈技術應用和產業發展的指導意見強調開源的重要性192021 年 6 月 7 日，工業和信息化部、中央網絡安全和信息化委員會辦公室聯合發布 關于加快推動區塊鏈技術應用和產業發展的指導意見（以下稱 指導意見）?！笆奈濉睍r期，隨著全球數字化進程的深入推進，區塊鏈產業競爭將更加激烈，出臺指導意見，有助于進一步夯實我國區塊鏈發展基礎，加快技18參見https:/ 上海 深圳

136、 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty55術應用規?；?，建設具有世界先進水平的區塊鏈產業生態體系，實現跨越發展。指導意見強調了開源的重要性。指出要建立開源生態，加快建設區塊鏈開源社區，圍繞底層平臺、應用開發框架、測試工具等，培育

137、一批高質量開源項目。完善區塊鏈開源推進機制，廣泛匯聚開發者和用戶資源，大力推廣成熟的開源產品和應用解決方案，打造良性互動的開源社區新生態。四、央行等五部門聯合發布關于規范金融業開源技術應用與發展的意見四、央行等五部門聯合發布關于規范金融業開源技術應用與發展的意見202021 年 10 月 27 日，央行等五部門聯合發布關于規范金融業開源技術應用與發展的意見，意見指出開源技術在金融業各領域得到廣泛應用，在推動金融機構科技創新和數字化轉型方面發揮著積極作用，但也面臨安全可控等諸多挑戰。金融機構在使用開源技術時應遵循以下原則：（一）堅持安全可控。金融機構應當把保障信息系統安全作為使用開源技術的底線，

138、認真開展事前技術評估和安全評估，堵塞安全漏洞，切實保證技術可持續和供應鏈安全，提升信息系統業務連續性水平。（二）堅持合規使用。金融機構應當遵循開源技術相關法律和許可要求，合規使用開源技術，明確開源技術的使用范圍和使用的權利與義務，保障開源技術作者或權利人的合法權益。（三）堅持問題導向。鼓勵金融機構有針對性地選擇和使用開源技術，建立開源技術使用問題發現、反饋、解決等閉環機制，推動開源技術不斷迭代升級。（四）堅持開放創新。鼓勵金融機構重視開源技術應用與發展，積極參與國際國內開源技術社區建設，汲取先進技術，貢獻中國智慧，培育適合金融場景的開源產業鏈，提升開源技術話語權。這說明，金融機構作為風險高發地

139、，監管部門已經開始重視并強調開源合規制度的建設與完善。20參見 http:/ 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty56五、工信部發布“十四五”軟件和信息技術服務業發展規劃五、工信部發布“十四五”軟件和信息技術服務業發

140、展規劃212021 年 11 月 30 日，工業和信息化部印發了“十四五”軟件和信息技術服務業發展規劃（以下簡稱規劃）。其中指出，開源是全球軟件技術和產業創新的主導模式；開源軟件已經成為軟件產業創新源泉和“標準件庫”；開源還開辟了產業競爭新賽道，基于全球開發者眾研眾用眾創的開源生態正加速形成。規劃提出，“十四五”時期我國軟件和信息技術服務業要實現“產業基礎實現新提升，產業鏈達到新水平，生態培育獲得新發展，產業發展取得新成效”的“四新”發展目標。到 2025 年，規模以上企業軟件業務收入突破 14萬億元，年均增長 12以上，工業 APP 突破 100 萬個，建設 2-3 個有國際影響力的開源社區

141、，高水平建成 20 家中國軟件名園。規劃突出強調開源在驅動軟件產業創新發展、賦能數字中國建設的重要作用，提出“繁榮國內開源生態”的重點任務，設置“開源生態培育”專項行動，統籌推進建設高水平基金會，打造優秀開源項目，深化開源技術應用，夯實開源基礎設施，普及開源文化，完善開源治理機制和治理規則，加強開源國際合作，推動形成眾研眾用眾創的開源軟件生態。六、中央網絡安全和信息化委員會印發“十四五”國家信息化規劃六、中央網絡安全和信息化委員會印發“十四五”國家信息化規劃222021 年 12 月 27 日，中央網絡安全和信息化委員會印發“十四五”國家信息化規劃（以下簡稱規劃），對我國“十四五”時期信息化發

142、展作出部署安排。其中在總體部署中提到，“十四五”期間，我國開源社區生態建21參見 https:/ http:/ 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty57設要取得重要進展。大數據應用、人工智能和區塊鏈等領域的開源社區建

143、設被寫入其中；開源技術產品的專利風險應對也被提到了相應位置;規劃鼓勵我國相關機構和企業積極加入國際重大核心技術的開源組織，參與國際標準合作共建;我國也應加快國際化的開源社區和開源平臺建設，聯合有關國家和組織完善開源開發平臺接口建設，規范開源產品法律、市場和許可。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong Lond

144、on New York Los Angeles San Francisco Almaty58第七部分 開源合規第七部分 開源合規 Q&A(持續豐富中)(持續豐富中)北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty59一、開

145、源等于免費？一、開源等于免費？開源與免費之間并不能畫等號，OSI 官網上對開源軟件是否可以用于商業目的做出了明確答復：“所有開源軟件都可以用于商業目的，開源定義保證了這一點。你甚至可以銷售開源軟件?！彪m然開源軟件的程序、文檔免費，但一些軟件公司會通過售賣配套技術支持、培訓、咨詢服務等方式盈利。二、企業的開源合規流程是怎樣的？二、企業的開源合規流程是怎樣的？企業的開源合規流程一般包括以下步驟，以流程圖的方式表現為：圖 3開源合規流程23三、如果企業開發的集成軟件中，有一部分組件由合作廠商完成，三、如果企業開發的集成軟件中，有一部分組件由合作廠商完成，23來源：可信開源合規計劃開源合規指南（企業篇

146、）第 42 頁。北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty60且合作廠商沒有提供源代碼，從開源合規角度怎么考慮？且合作廠商沒有提供源代碼，從開源合規角度怎么考慮？可以考慮和合作廠商簽訂協議，要求合作廠商對其提供的代碼

147、部分的開源合規性負責，若因為合作廠商提供的源代碼出現了開源合規瑕疵導致損害后果的，合作廠商應當承擔相應的責任。四、企業在發布軟件時，如何選擇開源還是閉源？四、企業在發布軟件時，如何選擇開源還是閉源？決定將軟件是開源發布還是閉源發布是一個涉及多方面因素的戰略性決策。企業在做出這一決策時應考慮以下因素：1.業務目標和戰略：確定企業的業務目標和戰略，以及軟件在實現這些目標中的角色。如果開源有助于推動業務目標，例如增加用戶基礎、提高知名度或促進行業標準，那么開源可能是一個好的選擇。2.知識產權策略：評估軟件的核心技術是否是企業的核心競爭優勢。如果是，保持閉源可能更有利于保護知識產權。如果軟件的價值主要

148、在于社區貢獻、用戶生態系統或服務，那么開源可能更為適合。3.社區與合作：考慮與外部社區和其他企業的合作關系。開源軟件通常更容易與其他項目集成，促進合作和創新。4.商業模式：考慮企業的商業模式，以確定開源或閉源對收入和盈利模式的影響。有些企業通過提供專有功能、服務或支持來獲取收入，而同時開源核心代碼以促進社區參與。5.社區和用戶互動：評估開源可能會如何影響企業與用戶和社區的互動。開源軟件通常能夠吸引更廣泛的用戶參與和反饋。6.風險管理：考慮開源可能帶來的法律風險和知識產權問題。了解開源許可證的類型及其對企業的影響。7.技術架構和生態系統：評估軟件的技術架構和生態系統，以確定開源北京 上海 深圳

149、廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty61是否對技術創新和生態系統發展有積極的影響。8.市場趨勢和競爭環境：研究市場趨勢和競爭環境，了解同類軟件是開源還是閉源的比例，并考慮如何在市場中保持競爭力。在實際中，一些企業也會采用混合模式

150、，即將部分軟件開源，而將另一部分保持閉源，以平衡開源的好處和封閉源的商業需求。五、如果開發人員在開發過程中使用了五、如果開發人員在開發過程中使用了MPL許可證的開源組件，如果避免開源風險？許可證的開源組件，如果避免開源風險？MPL 許可證中對“發布”的定義是“以源代碼方式發布的文件”，這就意味著 MPL 允許企業在自己已有的源代碼庫上加一個接口，除了接口程序的源代碼以 MPL 許可證的形式對外許可外，源代碼庫中的源代碼就可以不用 MPL許可證的方式強制對外許可。因此開發人員可以通過設置接口的方式來避免開源風險。六、如果開發人員在開發過程中使用了六、如果開發人員在開發過程中使用了 LGPL 許可

151、證的開源組件，如果避免開源風險？許可證的開源組件，如果避免開源風險？根據 LGPL 許可證的要求，如果軟件是一個獨立的作品，不與 LGPL 組件進行靜態鏈接，那可以在軟件中使用LGPL組件而不必開源整個軟件的源代碼。如果對 LGPL 組件進行靜態鏈接，那就需要開放軟件的整個源代碼，以遵守LGPL 的要求。因此開發人員可以通過采用動態鏈接調用 LGPL 許可證的庫實現風險隔離。七、企業在對軟件進行開源時，如何選擇許可證類型？七、企業在對軟件進行開源時，如何選擇許可證類型？許可協議的選擇應該根據具體情況進行權衡，并考慮到軟件作者的目標和需求。如果企業希望確保開源軟件的代碼始終對社區開放，防止閉源產

152、品私有北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty62化代碼的情況，可以考慮使用 GPL 等強著佐權許可證；如果企業希望鼓勵廣泛使用、貢獻和集成的項目，可以考慮使用 MIT 等對商業閉源產品沒有過多限制的寬松型許可證。

153、八、只有將軟件直接提供給客戶才算“分發”嗎？八、只有將軟件直接提供給客戶才算“分發”嗎？在開源軟件領域，分發是一個重要的概念，涉及多種情況。分發并不僅僅指將軟件直接提供給最終用戶，還包括了多種形式的傳播和提供方式。以下是一些常見的分發情況：1.直接下載和安裝：將軟件的可執行文件、源代碼或安裝包提供給用戶，使用戶能夠直接下載并在本地計算機上安裝使用。2.打包和發布：將軟件打包成操作系統特定的安裝包，如.deb（Debian/Ubuntu）、.rpm（Red Hat/Fedora）、.dmg（macOS）等，供用戶通過包管理工具或手動安裝。3.集成到其他軟件中：將開源軟件的一部分嵌入到其他軟件中，

154、作為整個產品的組成部分。這可能包括動態鏈接、靜態鏈接或以其他方式集成。4.虛擬機鏡像：提供包含預配置軟件的虛擬機鏡像，用戶可以通過虛擬化平臺（如 VirtualBox、VMware）直接部署和運行。5.源代碼托管平臺：將源代碼托管在開源代碼托管平臺（如 GitHub、GitLab）上，供其他開發者或用戶通過版本控制工具檢出和使用。6.CDN 分發：利用內容分發網絡（CDN）分發軟件，使用戶能夠從離他們最近的服務器獲取軟件，提高下載速度和可用性。九、開源軟件會有安全漏洞嗎？九、開源軟件會有安全漏洞嗎？開源軟件也可能存在安全漏洞。盡管開源軟件因為其透明的開發過程和廣泛的社區審查通常能夠更迅速地發現

155、和修復漏洞，但并不意味著它是絕對安全北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty63的。例如開發過程中可能存在缺陷，例如不足的測試覆蓋率、缺少安全審查等。這可能導致潛在的漏洞未被及時發現。因此，企業在引入開源軟件時，應

156、當重視軟件安全問題，先進行安全掃描，并對安全風險進行評估之后再開始使用。十、開源軟件有技術支持嗎？十、開源軟件有技術支持嗎？一些人可能認為開源軟件缺乏專業支持。實際上，許多開源項目有著積極的社區支持，并且一些開源軟件的背后有專業的支持和服務提供商。對于企業而言，在開展關鍵任務部署時，建議考慮有供應商提供支持的企業級版本。十一、他人開源的十一、他人開源的 AI 訓練數據集受開源許可證限制嗎？訓練數據集受開源許可證限制嗎？開源的 AI 訓練數據集也會受到特定的開源許可證或使用條款的限制，通常會對數據集的著作權歸屬、使用、修改、再分發等方面的進行規定和限制。數據集常見的開源許可證包括但不限于 MIT

157、 許可證、Apache 許可證、CreativeCommons 許可證（CC 協議）等。在使用他人開源的 AI 訓練數據集時，建議查看該數據集的門戶網站或者代碼托管網站等，詳細了解該數據集的使用條款或者開源許可證類型，明確具體限制，遵守相應條款十二、如果開發人員在軟件開發過程中使用了十二、如果開發人員在軟件開發過程中使用了 GPL 許可證的開源組件，如何避免開源風險？許可證的開源組件，如何避免開源風險？若代碼掃描工具顯示軟件成分中含有 GPL 組件，并不一定意味著軟件一定存在被開源的風險，可以從以下幾個方面進行風險排查：（1）與開發人員確認 GPL 組件在軟件代碼倉中的具體位置、作用等，若GP

158、L 組件是編譯工具、測試代碼等，不會被整合到軟件主程序的代碼中，則開源風險較低；北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty64（2）確認 GPL 組件的許可證信息，有些 GPL 組件許可證中包含了豁免情形，若符合該豁

159、免情形，則開源風險較低。十三、每個開源代碼中包含了很多代碼文件，每個文件中的作者聲明都不一樣，我們應該選哪個放入到開源聲明中呢？十三、每個開源代碼中包含了很多代碼文件，每個文件中的作者聲明都不一樣，我們應該選哪個放入到開源聲明中呢？選擇哪個許可證聲明放入到開源聲明中，取決于項目的具體需求、社區的期望以及法律的要求。如果一個開源項目包含了多個代碼文件，并且每個文件中的作者聲明不同，開發者在確定如何聲明開源許可證時一般考慮以下步驟：（1）許可證兼容性：首先，檢查所有不同的許可證是否彼此兼容。有些許可證可能不允許與其他特定許可證的代碼一起使用。（2）項目許可證選擇：如果項目決定采用單一許可證，開發者

160、需要選擇一個與所有現有許可證兼容的許可證。這通常是通過選擇最寬松的許可證來實現的，因為更嚴格的許可證可能會限制代碼的重用。（3）許可證明確性：在項目的根目錄或 README 文件中明確聲明整個項目遵循的許可證，有助于用戶和貢獻者理解他們可以如何使用和貢獻代碼。（4）個別文件聲明：對于每個單獨的代碼文件，保留原作者的版權聲明和許可證聲明。（5）貢獻者協議：如果項目接受外部貢獻，有貢獻者協議要求貢獻者同意其代碼將遵循項目的許可證。（6）文檔和傳播：確保許可證和版權聲明在項目的文檔中清晰可見，軟件分發時一并提供。另外，隨著項目的進展和代碼的更新，建議定期審查和更新許可證聲明。北京 上海 深圳 廣州

161、武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty65第八部分 信息安全技術軟件產品開源代碼安全評價方法第八部分 信息安全技術軟件產品開源代碼安全評價方法北京 上海 深圳 廣州 武漢 成都 重慶 青島 杭州 南京 ?？?東京 香港 倫敦 紐約 洛杉

162、磯 舊金山 阿拉木圖Beijing Shanghai Shenzhen Guangzhou Wuhan Chengdu Chongqing Qingdao Hangzhou Nanjing Haikou Tokyo Hong Kong London New York Los Angeles San Francisco Almaty66信息安全技術軟件產品開源代碼安全評價方法信息安全技術軟件產品開源代碼安全評價方法一、信息安全技術軟件產品開源代碼安全評價方法-編制說明二、信息安全技術軟件產品開源代碼安全評價方法-標準文本67香港辦公室香港辦公室Hong Kong Office香港中環康樂廣場香港

163、中環康樂廣場 1 號怡和大廈號怡和大廈 4 層層4/F Jardine House,1 Connaught Place,Central,Hong KongTel：+852 2877 3088Fax：+852 2525 1099杭州辦公室杭州辦公室Hangzhou Office浙江省杭州市上城區錢江路浙江省杭州市上城區錢江路 1366 號華潤大廈號華潤大廈 A 座座 22 層，郵編層，郵編 31002022/F,Block A,China Resources Building,1366 Qianjiang Road,ShangchengDistrict,Hangzhou,Zhejiang 310

164、020,ChinaTel：+86 571 5692 1222Fax：+86 571 5692 1333舊金山辦公室舊金山辦公室San Francisco Office美國加利福尼亞州帕洛奧圖市東海岸路美國加利福尼亞州帕洛奧圖市東海岸路 2479 號號 215 室，郵編室，郵編943032479 E.Bayshore Rd,Suite 215,Palo Alto,CA94303,USATel:+1 415 868 4398Fax:+1 415 868 4399青島辦公室青島辦公室Qingdao Office山東省青島市香港中路山東省青島市香港中路 61 號乙遠洋大廈號乙遠洋大廈 A 座座 27-

165、28 層，郵編層，郵編 26607127-28/F,Tower A,COSCO Plaza,61B Hong Kong Middle Road,Qingdao,Shandong 266071,ChinaTel：+86 532 5572 8677/8678Fax：+86 532 5572 8667/7666北京辦公室北京辦公室Beijing Office北京市朝陽區金和東路北京市朝陽區金和東路 20 號院正大中心號院正大中心 3 號樓南塔號樓南塔 22-31 層郵編層郵編 10002022-31/F,South Tower of CP Center,20 Jin He East Avenue,C

166、haoyang District,Beijing100020,ChinaTel：+86 10 5957 2288Fax：+86 10 6568 1022/1838倫敦辦公室倫敦辦公室London Office英國倫敦奧斯丁修士街英國倫敦奧斯丁修士街 10-11 號，郵編號，郵編 EC2N 2HG10-11Austin Friars,London EC2N 2HG,U.K.Tel：+44 20 7382 1567Fax：+44 20 7382 1568深圳辦公室深圳辦公室Shenzhen Office廣東省深圳市福田區益田路廣東省深圳市福田區益田路 5033 號平安金融中心號平安金融中心 A 座

167、座 57/58/59層，郵編層，郵編 51800057/58/59/F,Tower A,Ping An Finance Centre,5033 Yitian Road,FutianDistrict,Shenzhen,Guangdong 518000,ChinaTel：+86 755 3325 6666Fax：+86 755 3320 6888廣州辦公室廣州辦公室Guangzhou Office廣東省廣州市天河區珠江新城華夏路廣東省廣州市天河區珠江新城華夏路 10 號富力中心號富力中心 23 樓整層及樓整層及 31 樓樓 01、04 單元，郵編單元，郵編 51062323/F,Units 01&

168、04 of 31/F,R&F Center,10 Huaxia Road,Zhujiang NewTown,Tianhe District,Guangzhou,Guangdong 510623,ChinaTel：+86 20 2826 1688Fax：+86 20 2826 1666重慶辦公室重慶辦公室Chongqing Office重慶市江北區金融街重慶市江北區金融街3號號D座中國人保壽險大廈座中國人保壽險大廈5-1層層A單元，郵編單元，郵編 4000235-1A,Tower D,PICC Life Insurance Tower,3 Financial Street,JiangbeiDis

169、trict,Chongqing 400023,ChinaTel：+86 23 8879 8388Fax：+86 23 8879 8300阿拉木圖辦公室阿拉木圖辦公室Almaty Office哈薩克斯坦共和國阿拉木圖市麥迪奧區哈薩克斯坦共和國阿拉木圖市麥迪奧區 Samal-2 街區街區 58 號樓號樓 2單元單元 11 層，郵編層，郵編 05005911th Floor,Unit 2,Building 58,Samal-2,Medio District,Almaty,Republic ofKazakhstan，050059Tel:+7 727 339 1880Fax:+7 727 339 188

170、0I.A Brief History of OpenSourceFromtheperspectiveofhistoricaldevelopment,theevolutionofopensourceprojectshasroughlygonethrough the following stages:（一）1950s-1960s:earlycooperationandinformation sharingin computingInthe1950sand1960s,computersciencewasinitsinfancy.Thedevelopmentofcomputerhardwareands

171、oftwarewascarriedoutprimarilybyuniversitiesandresearch institutions,creating arelatively small but tightly knitcommunity.Thescaleofcomputer systems was relativelysmall,and researchers focusedoncollaborationandinformationsharing,disseminatingknowledgeofcomputersciencethroughscientificpapersandconfere

172、nces.This can be seen asan early open culture.（二）1970s:Theemergence of UNIXIntheearly1970s,researchersatBellLabsdeveloped the UNIX operatingsystem.ThesourcecodeforUNIXwasmadeavailabletomany academic institutions andcompanies,and this practice ofopennesssetthestageforcollaborationandinformationsharin

173、g.Thisperiodwascharacterized by interaction andknowledge exchange within thecommunity.（三）1980s:Founding oftheFreeSoftwareFoundationIn 1985,Richard StallmanfoundedtheFreeSoftwareFoundation(FSF)topromotethe concept of free software,which emphasizes the rights ofusers to freely use,modify,andshare soft

174、ware,and to promotethe launch of the GNU project,whichisdedicatedtothecreation of a completely freeUNIX-compatibleoperatingsystem.This period witnessedanin-depthexplorationanddefinitionoftheconceptoffreedom.（四）1990s:TheLinuxKernel and the Riseof the Open SourceMovementIn1991,FinnishstudentLinus Torv

175、alds released the firstversion of the Linux kernel,andLinux became a successful opensourceproject,attractingdevelopers from all over theworld.This period marked theformalization of the concept ofopen source,and the size andactivityofthecommunityincreased dramatically.（五）1998:Establishment of theOpen

176、SourceInitiativeIn 1998,the Open SourceInitiative(OSI)was formed topromotethedefinitionandpromotionofopensourcesoftware.OSIdevelopedadefinition of open source andcertified open source licensesthatmet thisdefinition.Thisperiod was the moment whenthe concept of open source wassystematized and standard

177、ized.（六）2000s:commercialapplications of opensource softwareOver time,more and morecompaniesrecognizedthepotentialofopensourcesoftwareandactivelyparticipatedinopensourceprojects or built their productsandservicesbasedonopensourcesoftware.Well-knownopen source projects,such asthe Apache HTTP server,My

178、SQLdatabases,andtheLinuxoperating system,became keycomponentsinbuildingenterprise-classapplicationsduring this period.（七）2010stopresent:the broader impactofopensourceintechnologyandsocietyOver the past decade,opensource has become a dominantforce in the IT industry,not onlydominatingtheoperatingsyst

179、em and server space,butalso expanding into emergingareas such as cloud computing,bigdata,andartificialintelligence.Opensourceprojectshaveflourishedglobally,andmodelsofcommunity collaboration haveevolved.Successfuldemonstrations of open sourcesuchasKubernetesandTensorFlowhaveprovidedastrongimpetusfor

180、technological innovation.The history of open sourcedevelopmentisanever-evolvingepicthatrepresents a continuous questfor openness,collaboration,andinnovation in computer scienceand software engineering.Whilethisjourneyhasdriventechnologicaldevelopment,ithas also had a profound impactat the societal l

181、evel,shaping theface of todays digital age.II.Thedevelopmentprocess of open source inChinaThe development of opensourceinChinahasgonethrough several stages,showinga trend of gradual deepeningand broad participation.Start-upphase(1990stoearly 2000s):China is mainly inthe initial adoption and use ofop

182、en source software in thisperiod,mainly concentrated insome universities and researchinstitutions.Initialopensourcecommunityformation(mid-2000s):The domestic opensourcecommunitybegantotake initial shape during thisperiod.Someopensourceprojectsgraduallyattracteddomesticattention,anddevelopers began t

183、o participatein the international open sourcecommunity.Riseofdomesticindependentopensourceprojects(early 2010s):With theimprovementofdomestictechnologylevel,Chinasindependentopensourceprojects began to emerge.Someenterprisesandindependentdevelopers actively participatedin some key projects,such as t

184、heestablishmentoftheChinaOpen Source Software IndustryAlliance.Activecommunityandinternationalcommunication(mid-2010stopresent):Thedomesticopensourcecommunity became more activein this period.On the one hand,thedomesticcommunityhasactivelyparticipatedininternationalexchangesandpromoted the developme

185、nt ofsome international open sourceprojects;on the other hand,aseries of excellent independentopensourceprojectshaveemergedinChina,suchasDubbo of Ant Gold,HarmonyOSof Huawei,and so on.Governmentpolicyguidanceandsupport(mid-2010stopresent):Thegovernmenthasgraduallyrecognizedthestrategicpositionofopen

186、sourceintechnologicalinnovationandindustrial upgrading.A series ofpolicies have been introducedto support the development ofopensource,includingencouraginggovernmentprocurementofopensourcesoftware,promoting enterpriseopensourceprojects,andfacilitatinginternationalopensource cooperation.Industrializa

187、tionandtechnologicalinnovation(2015-present):In recent years,Chinas open source ecosystemhas entered a more mature andindustrializedstage.Somewell-knownenterpriseshavemade significant progress in theopen source field and becomemajorcontributorstosomeimportant open source projects.Internationalcooper

188、ationandcommunitybuilding(inrecentyears):Chinasopensourcecommunityhasincreasingly interacted with theinternationalcommunity.Chinesedevelopersandenterprises actively participatein global open source projects,promotinginternationalexchangeandcooperationintechnology.Overall,Chinas open sourcedevelopmen

189、t has gone throughtheprocessofstarting,emergingtomaturityandinternationalization.Withthesupport of government policies,Chinas open source communityhasgraduallybecomeanindispensable part of the globalopensourceecosystem,injecting a strong impetus fortechnologicalinnovationandindustrial development.Fi

190、rst,Classification of theOpen Source LicenseOpen source licenses,alsoknownasopensourceagreements,are an importantproductoftheopensourcephilosophyinpractice.Aspreviously emphasized,the coreconcept of open source is topromote technological progressthroughthesharingofknowledge,not to fight againstintel

191、lectualpropertyrightsembeddedinintellectualachievements.Whilepursuingthisgoal,opensourcealsorequires legal means to ensurethelegitimaterightsandinterests of developers.In ordertoprotecttherightsandinterests of developers and atthe same time fully guaranteethe right of users to freely usethesoftware,

192、theconcept ofcopyleft was born.By means ofopensourcelicenses,theauthors proprietary rights areprotected and certain self-rightsrestrictions are imposed,thusensuring the freedom of userstoshareandmodifythesoftware.Various open sourcecommunities,leadinguniversities,andgroups havedevelopedarangeofopens

193、ource licenses that have theirown unique set of rights andobligations,oftenreflectingdifferentvaluesandconsiderations.There are 2 general types ofopensourcelicenses:relaxedand licensed.1,loose type(Permissive):This type of license often onlyrequires the licensee to retainthe copyright information of

194、 theoriginalwork,andimposesfewer restrictions on the user,and the derived software canbecomeproprietary,suchasApache,MIT,BSDserieslicenses.They are popular incommercializedenvironmentsbecausetheyallowderivedsoftware to be closed source.2.Copyleft:Also known asreciprocal or strong protectionlicenses.

195、This type of license isdesigned to promote developercooperation and ensure the freesharingofsourcecodebyrequiring that modifications andextensions to the software mustbeopen-sourcedunderthesamelicense.Authorshiplicenses can be further dividedinto strong and weak authorshiplicenses,commonstrongauthor

196、shiplicensesincludeAGPL,SSPL,GPL licenses,etc.;commonweakauthorshiplicensesincludeLGPLserieslicenses,MPLlicenses,etc.Strongly-authoredlicensesrequiremorestringentmodifications and extensions tothe software,pursuing a higherdegreeofopensourcecontagion and ensuring that theentire project is open sourc

197、e.Incontrast,weakly-encumberedlicensesarelessstringentintheir open source requirementsandallowcombinationswithnon-open source software.Thechoice of which type of licenseto use usually depends on thenature of the project,the needsofthecommunity,andthedevelopersattitudetowardcode sharing.Second,Introd

198、uctiontocommonopensourcelicenses(i)MIT licenseThe MIT license is a veryloose open source license that iswidelyusedinmanyopensource projects.It originated atthe Massachusetts Institute ofTechnology(MIT),hencethename.The main features are:(1)Simplicity:TheMITLicense is a very simple,intuitivelicense t

199、hat does not containtoo much complex legal jargon.(2)PermissiontoUse,Modify,and Redistribute:TheMITlicensepermitsanyone,whetheraprivateuserorabusiness,to freely use,modify,and redistribute the software.(3)Non-Contagious:Unlikean authorship-based license,aMIT license is not contagious,i.e.,there is n

200、o requirement thatderivative works use the samelicense.(4)Inclusion of copyrightnotice and disclaimer:The MITlicense requires that the originallicense and copyright notice beincludedinallcopiesorsignificantportionsofthesoftware.In addition,it comeswith a disclaimer outlining thatthe software is prov

201、ided as is,without warranty of any kind.(5)Business Friendly:MITlicensesareverypopularinbusiness environments due totheirlooserestrictions.EnterprisescanintegratesoftwarecontainingMITlicensesintotheirbusinessprojects without restrictions.(ii)BSD licensesTheBSDLicense(BSD)standsforBerkeleySoftwareDis

202、tributionLicense.TheBSDLicense is an umbrella term for aseries of open source licenses,the two most common of whichare the BSD 2-Clause License(also known as Simplified BSDLicense The two most commonversions are the BSD 2-ClauseLicense(alsoknownastheSimplifiedBSDLicenseorFreeBSD License)and the BSD3

203、-Clause License(also known astheNewBSDLicenseorModifiedBSDLicense).Bothversions of the BSD license arederived from the BSD operatingsystemdevelopedattheUniversityofCalifornia,Berkeley.The main features of theBSD 2-Clause License are:(1)Simplicity:Like the MITLicense,theBSD2-ClauseLicense is a very s

204、imple andstraightforward license.(2)Permissiontouse,modifyandredistribute:Thelicensepermitstheuse,modification and redistributionofthesoftwareifcertainconditions are met.(3)Retention of Copyrightand Disclaimer:Similar to theMIT License,the BSD 2-ClauseLicense requires that the originallicense and co

205、pyright notice beincludedinallcopiesorsignificantportionsofthesoftware and that a disclaimerbe included.The main features of theBSD 3-Clause License are:(1)PermittedUse,Modification,andRedistribution:SimilartotheBSD2-ClauseLicense,thelicensepermitstheuse,modification,and redistributionofthesoftwarei

206、fcertainconditions are met.(2)Requirement not to usethe name of the original authoror contributor for publicity:thename,trademarkorotheridentificationoftheoriginalauthor or contributor should notbe used in publicity materials fortheuseofthesoftwaretoindicate their endorsement orrecommendation.(3)Ret

207、ention of copyrightanddisclaimer:Thesamerequirementtoincludetheoriginal license and copyrightnotice in all copies or significantportions of the software and toinclude a disclaimer.BSD licenses are popular fortheirflexibilityandsimplicity,especially when integrated withcommercial software or used ina

208、cademic research projects.(iii)Apache licenseTheApachelicenseisawidely used open source licenseoriginallycreatedandmaintainedbytheApacheSoftwareFoundation.Thelicenseappliestomanywell-knownopensourceprojects,mostnotablytheApache HTTP server.The mainfeatures of the Apache licenseare:(1)Commercial use

209、allowed:The Apache license is open tobothcommercialandnon-commercial users,allowinguse in both closed-source andopen-source projects.(2)Permissiontomodifyandredistribute:Thelicensepermits the user to modify thesource code and redistribute themodified code in open or closedsource form.(3)LimitedPaten

210、tGrant:The Apache license contains alimitedpatentgrantclause,which grants users permissionto use patents related to thesoftware.Thishelpspreventpatentlawsuitsagainstopensource projects.(4)Retention of copyrightanddisclaimer:Thelicenserequires that the original licenseandcopyrightnoticebeincludedinal

211、lcopiesorsignificantportionsofthesoftware.In addition,it containsadisclaimerstatingthatthesoftwareisprovidedasiswithout warranty of any kind.The Apache license is widelyadoptedforitsflexibility,businessfriendliness,andtreatment of patent grants,andmanyimportantopensourceprojects have chosen to use t

212、hislicense.(iv)GPL licensesTheGPL(GNUGeneralPublicLicense)isanopensource license created by theFreeSoftwareFoundation.TheGPLisanauthorship-basedlicense designed to safeguardthe freedom of users and ensurethateveryonewhouses,modifies,anddistributesthesoftwareenjoysthecorrespondingfreedom.Themain feat

213、ures are:(1)Open Source and FreeUse:TheGPLensuresthatlicensees are free to use,modify,and distribute the source codeof the software.(2)Contagious(Copyleft):One of the main features of theGPL is its contagiousness,whichrequiresthatanysoftwaremodificationsandderivativeworks licensed under the GPLmust

214、also be distributed usingthe GPL.(3)Availabilityofsourcecode:If GPL-licensed software isusedinaproject,thecorrespondingsourcecodemust be made available with anydistribution in binary form toensure that users have the rightto view and modify the code.(4)Open source nature ofmodifications:For modifica

215、tionsto GPL-basedsoftware,thesemodifications must be similarlydistributedusingtheGPLtoensure the open source natureof the entire project.The GPL has been releasedin three versions,and the mostcommon GPL licenses are GPLv2 and GPL v3.GPL licenses are particularlysuitableforopensourcecommunitiesandpro

216、jectsbecause of their emphasis onuser freedom,but they are alsocontroversial in the commercialworldbecauseoftheircontagiousnessandsomeoftheirrequirements.Projectsusually choose GPL licenses outof adherence to free softwareprinciples.(v)AGPL licensesTheAGPL(GNUAfferoGeneral Public License)license isa

217、 strong authorship license.LiketheGPL,itrequiresthatmodifications and extensions tothesoftwaremustbeopen-sourced under the samelicense.The main features are:(1)Contagiousness of WebServices:The AGPL requires thatif a service provider offers webservicesusingAGPL-licensedsoftware,thenmodificationsandd

218、erivativeworkstothatsoftwaremustalsobeopen-sourced using the AGPL,even if the modifications areonly run on the server and notdistributed to clients.(2)Access rights for remoteusers:The AGPL emphasizes theright of remote users to accessthe software over the networkto ensure that they have accesstothe

219、correspondingsourcecode.(3)Availabilityofsourcecode:Similar to the GPL,theAGPL requires that distributionofthebinaryformbeaccompaniedbythecorrespondingsourcecode.However,theAGPLmoreexplicitly emphasizes the case ofsoftware services provided overthe Web.(4)Applicationtowebservicesandhostingenvironmen

220、ts:TheAGPLwasdesigned to respond to the riseof cloud computing and hostingservices by ensuring that opensource software used in theseenvironmentsremainsopensource.The AGPL is often chosenfor use in open source projectsthatprovideonlineservices,especially in cloud computing,Software as a Service(SaaS

221、),andother web service models,toensure that the software used intheseenvironmentsremainsopensource.AGPLusagescenarios are primarily based oncontributionstotheopensourcecommunityandanemphasis on user freedom.(vi)LGPL licensesTheLGPL(GNULesserGeneralPublicLicense)isaweakly-authored license createdandm

222、aintainedbytheFreeSoftware Foundation.Unlike theGPL,the LGPL is relatively morepermissive,allowing developersto link LGPL-licensed libraries(or portions of the code)tonon-opensourcesoftwarewithoutopeningtheentireapplications source code.Themain features are:(1)LinkingAllowed:TheLGPL allows developer

223、s to linkLGPL-licensedlibraries(orportionsofcode)intonon-LGPL-licensed applicationswithout opening up the entireapplications source code.(2)Open source nature ofmodifications:For modificationsto LGPL-licensed libraries,thesemodifications must be similarlydistributed using the LGPL tomaintain the ope

224、n source natureof the entire library.(3)Free use of libraries:ForLGPL-licensed libraries,users arefreetouse,modifyanddistribute the source code of thelibrary.(4)Open source nature ofmodifications:If LGPL-licensedlibrariesaremodifiedandembeddedinanapplication,thesemodificationsmustbesimilarly distrib

225、uted using theLGPL.The LGPL is often chosen forthedevelopmentofreusablesoftwarelibrariesorcomponents,allowingtheselibrariestobelinkedasdevelopers build closed-sourceapplications.Thisallowsdevelopers to enjoy the benefitsof open source libraries withouthaving to expose the sourcecode of the entire ap

226、plication.(vii)MPL LicenseThe MPL(The Mozilla PublicLicense)license was created andis maintained by theMozillaFoundation.TheMPLisarelatively loose license designedto encourage the developmentand sharing of software whileprotectingtherightsofauthors.One of the hallmarks oftheMPLisitsfile-levelcomplex

227、ity.One of the featuresoftheMPLisitsfile-levelcomplexity management,whichallows developers to selectivelylicense parts of their softwareunder the MPL license.The mainfeatures are:(1)File Level Licensing:MPLallows developers to selectivelyuse MPL to license portions oftheir software rather than theen

228、tireproject.ThismodularlicensingmakesMPLmoreflexible.(2)OpenSourceforDerivative Works:For DerivativeWorks,the MPL requires thattheseDerivativeWorksbedistributed using the MPL inorder to remain open source.(3)Allow combinations withotherlicenses:MPLallowscombinationswithotherlicenses,includingGPLandL

229、GPL.this flexibility facilitatesintegrationwithotheropensource projects.(4)Traceabilityofmodifications:Ifmodificationsare made to the software,theMPLrequiresthatthemodifications be clearly notedin the modified file and that acopyoftheoriginalfilebeprovided.The MPL is commonly usedinopensourceproject

230、s,especially those of the MozillaFoundation,such as the Firefoxbrowser.Due to its relativelyflexiblelicensingandcompatibilitywithotherlicenses,MPLissuitableforsituationswheretheauthorsrights of the original code needto be protected and integrationwith other open source projectsis desired.Overall,MPL

231、 is a license thatcombinesopensourceprinciplesandprotectionofauthorsrightsfordiversedevelopment scenarios.(viii)Magnolia LicenseMulan Open Source Licenseis an open source license led byPeking University,relying on theCloudComputingStandardWorking Group of the NationalInformationStandardCommittee and

232、 the China OpenSourceCloudAlliance,andjointlydrafting,revisingandreleasing an open source licensebasedonacomprehensiveanalysisoftheexistingmainstreamopensourceprotocols by the advantageousteams from all sectors of theindustry,academia and researchoftheUnitedNationsopensourceecosystem,theopensource c

233、ommunity as well as alarge number of lawyers whohaverichexperienceinintellectualpropertyrightsrelated issues.Currently,thereare3versions of Mulan Open SourceLicense:Mulan Loose Licenseversion1,MulanLooseLicense version 2 and MulanPublic License.Among them,theMulanRelaxedLicenseversion 2(MulanPSL v2)

234、wascertified by the Open SourceInitiative(OSI)in2020andapprovedasaninternationalizedopensourcelicense.The Magnolia Loose Licensehas the following characteristics:(1)The content of MulanLicenseisexpressedinbothChinese and English,and theChineseandEnglishversionshavethesamelegaleffect,which is conveni

235、ent for moreopen source participants to readanduse,andsimplifiesthecomplexityoflegalinterpretationforChinesedevelopers.(2)TheMagnoliaLicenseexpresslygrantsusersaperpetual,worldwide,free,non-exclusive,irrevocablelicensetocopyrightsandpatents,and,in response to theinterpleader loophole that existsin t

236、he Patent Alliance,expresslyprohibitsaContributororAffiliated Entity from Directlyor indirectly(through an agent,licensee or assignee)engage inpatentlitigationorotherenforcementactions,orterminate the patent license.(3)In order to protect theinterestsofContributors,theMulanLicenseexplicitlydoesnot p

237、rovide trademark licensesfor Contributors trade names,trademarks,service marks,andso on.(4)TheMagnoliaLicensehas been revised by technicaland legal experts to streamlinethe clauses and optimize theexpressions as much as possibleunder the premise of clarifyingthebehavioralconstraintsofboth parties to

238、 the contract andreducingtheriskoflegaldisputes.(ix)Open source licensecompatibility issuesOpensourcelicensecompatibilityreferstotherelationshipbetweendifferentopen source licenses,i.e.,theability of a software project tousecomponentsthataresimultaneouslyprotectedbydifferent licenses and to ensureth

239、atthesecomponentscollaborate with each other tothe extent that they are legal.When merging or linking opensource program code to whichdifferent licenses apply,we cansaythatthelicensesarecompatible if the restrictions orconditionsoftheindividuallicensesdonotconflict.Understanding compatibility is ake

240、yconsiderationfordevelopersandorganizationswhen selecting,combining anddistributingopensourcesoftware.Therearetwocommonwaysofcombiningcode,merging or using library links,andthefollowingtablecategorizes the compatibility ofcommon open source licenses:Third,Opensourcesoftware compliance risksOpensourc

241、esoftwareisnowwidelyutilizedinthedevelopmentanduseofcommercial software.However,the introduction of open sourcetechnology by enterprises oftenbrings various legal risks to theenterprisesiftheydonotcomply with the rules on the useof open source software.(i)Intellectualpropertyrisk1.Riskofcopyrightinf

242、ringementCopyrightinfringementrisks include the following:Unauthorized copying anddistribution:Enterprisesusingopensourcesoftwaremustfollow the terms of the license,includingtheconditionsforcopyinganddistributingthesource code.If an enterprisecopies,modifies or distributesthe source code of the soft

243、warewithout authorization,copyrightinfringement may be triggered.Modifyingcodewithoutsharing:Open source softwareoften allows users to modify thesource code,but after makingchanges to the source code,themodified code must be sharedunderthesamelicenserequirements.If an organizationmakesmodificationst

244、oopensourcesoftwarebutfailstoshare those modifications,thiscouldleadtoallegationsofcopyright infringement.Relyingonunlicensedversions:Businesses may rely onspecific versions of open sourcesoftware,but may infringe onthe copyright of the originalauthorsifmodificationsaremade to the software withoutth

245、e permission of the license.Mixed use of software withincompatiblelicenses:Whenenterprisesuseopensourcesoftware with different licensesat the same time,there may beincompatibilitybetweenthelicenses.Thiscanleadtoproblemsofcopyrightinfringement,especiallywhenstricter licenses(e.g.GPL)areinvolved.2、Pat

246、ent infringement riskTheriskofpatentinfringement in the use of opensourcesoftwarecomesfrombothinternalandexternalsources.First,theriskofinternalpatentinfringementreferstothefactthatopen-sourcesoftwaremaycontaintechnology that is protected bypatents,especiallysomeadvancedandinnovativefeatures.If comp

247、anies use thesetechnologieswithoutauthorization,patentinfringement may be triggered.Someopensourcelicensingagreements(e.g.,Apache 2.0)expresslygrantpatentsandhave patent retaliation clauses,and the internal patent risk isrelatively low.However,someopensourcelicensingagreements(e.g.,BSD,MIT,etc.)do n

248、ot expressly provide forpatentlicensing,andthedeveloper or contributor of theopen source software can filepatentlawsuitsandcollectroyalties from the users of theopen source software,so theinternal patent risk is higher.Second,the risk of externalpatentinfringementreferstothe risk of a third party no

249、tboundbyanopensourcelicense agreement initiating apatent lawsuit against a user ofopen source software,claimingthatthesaidopensourcesoftware uses its patents.Forexample,Microsoft has statedthatopensourcesoftware,including Linux,uses Microsoftspatents,and Microsoft has filedpatentinfringementlawsuits

250、againstGoogleaswellasnumerouscellphonemanufacturers,such as Foxconn,Kyocera,Samsung,etc.,demanding that they pay patentroyaltiestoMicrosoft.Thesecases were later settled by bothparties signing a patent licenseagreement and paying royaltiesto Microsoft.3.Trademark infringementriskWhenusingopensources

251、oftware,a business may makeunauthorizeduseofthesoftwares trademarks,includingthe softwares name,logo,orother marks.This may triggerallegationsoftrademarkinfringement.If its trademarksaresimilartothoseofthesoftware or its developer,thismay cause confusion and leadto the mistaken belief that thetwo ar

252、e related,which may alsolead to trademark infringementdisputes.Therefore,companiesusingopensourcesoftwareshould carefully understand thetrademarkuseregulationsofopensourcesoftwareandensurethattheyfollowthecompliancerequirementsinterms of trademark use in orderto reduce the risk of trademarkinfringem

253、ent.4.Trade secret riskTheriskoftradesecretinfringementofopensourcesoftwarerelatestothepossibilitythatanenterprisemayrevealitsinternaltradesecrets when using,modifyinganddistributingopensourcesoftware.The risk of trade secretinfringementmayarisefrommishandling of software code,configurations,algorit

254、hms,etc.,such that an organizations corebusinessinformationmayberevealed.One is the risk of beingforced to disclose trade secrets.Open source software usuallyprovides source code for userstoreviewandmodify.Enterprises using such sourcecodemayinadvertentlymixtheir own trade secrets into thepublicly a

255、vailable code if theyfailtoconductappropriatereviews,and the code may beforced to be open-sourced if it isinfectedbycopyright-basedopen-sourcelicenses,whichmay give rise to the risk ofdisclosure of trade secrets.The second is the risk oftradesecretsbeingillegallyaccessed.Malicious open sourcesoftwar

256、e may contain backdoorsthroughwhichhackerscanaccess sensitive information ofthe enterprise,including tradesecrets.If the introduced opensource software has maliciouscode,viruses or other securityholes,it may cause the risk ofleaking business secrets in theinternalsystem;otherscontribute source code

257、to theopen source community withoutthe approval of the enterprise,which may also cause the risk ofleaking business secrets.To reduce the risk of tradesecret infringement,enterprisesshouldimplementacomprehensiveopensourcesoftware management strategy,includingreviewing,cleaningandsecurityauditingsourc

258、ecode,selectingtrustedopensource software,complying withthe provisions of open sourcelicenseagreements,andensuring that their trade secretsare properly protected.(ii)Enterprise goodwill riskFor companies that do notcomplywithopensourcelicenses,open source softwarerights holders and others maypublish

259、articlestodenouncethem or add them to a blacklistof shame to condemn them,causing the risk of damage tothecompanysgoodwill.Forexample,Onyxs e-book deviceis based on a modified versionof the Linux kernel,which islicensedundertheGPLandrequires secondary distributionprojects to be open-source,butOnyxre

260、fusedtoreleaseitssource code.Onyxs attitude hasstirredupagreatdealofdiscontent,withsomecriticsarguingthattheOnyxcaseexposes the lack of respect foropen-source protocols on thepart of many vendors.(iii)Data compliance riskInrecentyears,withthedevelopment of AI technology,the application and promotion

261、of open source software in thefield of AI has become more andmoresignificant,andmanyadvancedmachinelearningalgorithms and deep learningmodels have been released asopensource,andsomecompanies have directly opensourcedtheirownAIdevelopment frameworks,whichhas promoted the widespreadapplicationofAItech

262、nology.When choosing these AI opensource tools,enterprises shouldpay attention to complying withChinasregulatorylawsandregulations in the field of AI andpayattentiontodatacompliance risks.AccordingtotheInterimMeasures for the AdministrationofGenerativeArtificialIntelligenceServices,theprovision of G

263、enerative ArtificialIntelligenceServicesshallcomply with the provisions ofthe Cybersecurity Law of thePeoples Republic of China,theDataSecurityLawofthePeoples Republic of China,andthePersonalInformationProtection Law of the PeoplesRepublicofChinaandotherlaws and regulations in terms ofdata security.

264、Therefore,if thesource and use of the data oftheopensourcesoftwareinvolvesinfringementofpersonalinformation,itmaycause data compliance risks tousers.At the same time,whetherthe data generated by the opensource software contains illegalinformation may also lead tocorresponding risks for users.Inaddit

265、ion,theprovisionofgenerative AI services should besubject to security assessment(theassessmentincludesthelegitimacyof theinformationservice,the effectiveness of theimplementationofsecuritymeasures,and the effectivenessof the prevention and control ofsecurity risks,etc.),and it shouldfulfill the obli

266、gation of algorithmfiling.Fourth,the constructionof enterprise open sourcecompliance system(i)Compositionofcorporateopensourcecompliance teamsAsorganizationswidelyadopt open source software intheir day-to-day operations,itbecomes critical to ensure itscompliance.To effectively dealwith the complexit

267、ies of opensourcecompliance,organizations need to establishadedicatedopensourcecomplianceteam.Thisteamshould consist of a legal team,technicalstaffandexternallawyers,and the departmentsneed to work closely together toaddress the risks posed by opensource.Firstandforemost,legalteamsplayacentralrolein

268、enterpriseopensourcecompliance.Theyareresponsible for parsing the legalrequirements of various opensource licenses and overseeingtheenterprisesopensourcesoftware strategy.Legal teamsneedtocollaboratewithtechnical teams to ensure thatdevelopersunderstandandfollow the terms of the licenses,as well as

269、develop and updateinternalopensourcecompliance policies to adapt tothe changing legal landscape.Second,technical staff arethekeyenforcersinimplementingopensourcecompliance policies.They needtounderstandthetechnicaldetails of open source softwareand ensure that companies donot violate the relevant li

270、censeswhenusing,modifyinganddistributing open source code.Collaboration between technicaland legal teams is critical toensure that technical practicesarealignedwithlegalrequirements.Thetechnologyteam also needs to regularlyreview and update the opensourcesoftwareused bytheorganizationtoaddresspotent

271、ial compliance issues in atimely manner.Inordertoobtainspecializedlegaladviceandsupport,enterprises also needtoestablishstrategicpartnershipswithexternallawyers.External lawyers usuallyhave deep knowledge of opensourcelawandareabletoprovide legal consulting servicestoenterprises,especiallyoncomplex

272、licensing issues.Theycanhelpenterprisesdevelopmorepreciseandactionableopensourcecompliancestrategiesandprovidethenecessarysupportwhendisputes arise.Cross-departmentalcollaboration is key to ensuringthesuccessofopensourcecompliance.Effectivecommunication and informationsharing among team membersis th

273、e foundation for consistencyandefficientcollaboration.Collaborationtoolsandplatformscanstrengthenthebondsbetweenteamsandensurethatinformationisdelivered in a timely manner.Inaddition,regular trainings andmeetings help ensure that theteam is sensitized to the latestregulations and best practicesandfa

274、cilitateconsensusbuilding.Bybuildingstrongcorporateopensourcecompliance teams and throughcross-departmentalcollaboration,organizations canbetter manage the complexityof open source software,ensureits compliance at both the legaland technical levels,and provideasolidlegalfoundationforsustainablebusin

275、essdevelopment.(ii)Building an enterpriseopen source compliance thinktankBuildingacomprehensiveandefficiententerpriseopensource compliance knowledgebase can effectively improve theefficiencyofenterpriseopensourcecompliancecollaboration.Theknowledgebasemainlyincludesthefollowing contents:1、Open sourc

276、e license quicksearch manualThe development of a quickreferencemanualforopensource licenses is the basis forbuilding a knowledge base.Themanual should cover the keypoints and risk tips of variouscommon open source licensesand provide clear and conciseexplanations,providingaconvenientandactionableref

277、erence for legal and technicalstaff.Given the wide variety oflicenses and their varying termsand restrictions,a simple anddetailedlookupmanualcanquicklyhelpbusinessteamsunderstand and determine theimpact of licenses.2,opensourcelicensegrouping strategyTheuseofopensourcelicense grouping strategy help

278、sto manage the complexity ofopensourcelicensesmoresystematically.According to thecontagious strength of differentlicenses and the actual needs ofthe company can be dividedinto different groups of licenses,such as free use group licensegroup,review and approval ofthelicensegroup,prohibiteduse of the

279、license group,etc.,the different groups need tofollow the corresponding use ofstandards and review process.3.Open source compliancetoolsThe use of advanced opensource compliance analysis toolsis particularly important whenbuildinganopensourcecomplianceknowledgebase.Forexample,asoftwarecomponent anal

280、ysis tool is usedto scan the source code,identifythe open source componentsused,and then audit them forunauthorizeduse,licenseconflicts,knownsecurityvulnerabilities,and other issues.Such automated analysis toolscan greatly increase efficiency,reduce the workload of teams,and provide organizations wi

281、thanaccurateassessmentoflicense compliance status andrisk,enabling them to take thenecessarystepsinatimelymanner.(iii)Establishmentofacompliantsoftwaredevelopment processInordertomorefullyensurethatthesoftwaredevelopmentprocessiscompliant with the use of opensourcesoftware,theintroduction of a Softw

282、are BuildOrder of Materials(SBOM)is acrucial part of the process,and itis important for organizations toknowwhatopensourcesoftware is being used in theirproducts.Asafirststep,developmentteamsshouldspecify at the beginning of thesoftware development processthe requirement to generate anSBOM for each

283、selected opensource software component.theSBOMwillclearlylisteachcomponent used,along with itsversion,dependencies,etc.,andprovideatraceablebillofmaterialsthroughoutthedevelopment lifecycle.During the software designandplanningphase,thedevelopmentteamneedstoplacespecialemphasisonverifying the comple

284、teness andaccuracy of the SBOM.Developspecifications to ensure that theSBOM contains accurate licenseinformation,vulnerabilityinformation,and other criticalcontent.Thishelpsreducepotential legal and security risksandprovidessubstantialsupportforsubsequentcompliance efforts.The SBOM should also serve

285、as a reference for developersduring the coding and testingphases.Whenmodifyingorextendingtheopensourcecode,thedevelopmentteamshould utilize tools such as codescanning to check and updatethe SBOM in a timely manner toensure that the information in itisconsistentwiththeactualcode.During the testing ph

286、ase,SBOM can be used to verify thesecurity and compliance of opensource components,helping thedevelopment team to identifyand solve potential problems ina timely manner.TheroleoftheSBOMshouldnotbeoverlookedduring the software deploymentanddeliveryphase.Thestandardized license declarationprocessshoul

287、dbebasedoninformationprovidedbytheSBOM,ensuring that all opensource components used andtheircorrespondinglicenseinformation are clearly listed inthesoftwaresuserdocumentation,installationinstructionsandrelatedinformation.Duringthesoftwaremaintenanceandupdatephases,development teams canleveragetheSBO

288、Mtore-evaluate and validate eachopensourcecomponenttodetermineifitneedstobeupdated or replaced.The SBOMcan also be used for effectivevulnerability management,withtheSBOMregularlycheckedand updated to reflect the latestsecurity and compliance status.Regarding the legal natureofopensourcelicenses,thec

289、ourts of China have in practicerecognized open source licensesas copyright licensing contractswith conditions for termination.This contains two meanings,oneis that the open source licensehas the nature of a contract,andthe other is that the open sourcelicense is a licensing contractwith a release co

290、ndition.Firstofall,opensourcelicenseshavecontractualcharacteristics:(1)Willingness ofboth parties:the formation of acontract requires that the will ofboth parties be agreed upon.Intheopensourcelicense,thecopyrightholder(licensor)through clear license terms toexpressthesoftwarewillbegranted to others

291、 to use the willof the user(licensee)throughthe acceptance of the licenseterms to express the willingnessto accept these rights of use.(2)Statutory obligations:One partyto a contract provides a certainright or service,and the otherpartyisrequiredtofulfillacorrespondingstatutoryobligation.In an open

292、sourcelicense,the licensor provides aspecificrighttousethesoftware,andthelicenseeisrequired to fulfill the conditionsset forth in the license,such asretainingcopyrightnotices,following the provisions of theopen source license,and so on.Secondly,opensourcelicenses have the nature of alicensewithaterm

293、inationcondition;Article 8 of the GPLv3license,TerminationofLicense,states that the licensorgrantstheusertherighttoexercisecertainrightsincompliance with the terms ofthe license,but the user mustassumethecorrespondingobligations.Iftheuserreproduces,modifiesordistributes the protected workin violatio

294、n of the conditions ofuse of the GPLv3.0 license,thelicensegrantedundertheGPLv3.0licensewillautomaticallyterminate.Oncetheuserviolatestheseconditions,the license contractisautomaticallyterminatedbetween the parties,and theusers authorization based onthelicenseisautomaticallyterminated.Thecopying,mod

295、ification,anddistributionthat the user has done or isdoing under the license will loseits legal basis,and the breach ofcontract will become a tort.It isconsistent with the connotationof civil legal acts with conditionsof termination in Article 158 ofthe Civil Code of China.1.Skytronicsv.Avanti:Compu

296、ter language as anauthoringtoolisnotcontagious with softwareworksCase summaryTianchuangTechnologyresearched and developed theShopNCe-commerceportalsystem software and applied foracomputersoftwareregistration certificate.2016,theplaintifffoundthatAvantiCompanyillegallyuseditslegallycopyrightedShopNCe

297、-commercesystemseriescomputersoftwareonthewebsiteoperatedbyAvantiCompany,soitsuedAvantiCompany for infringement ofthe copyright of the computersoftware to the court.AvantiarguedthattheplaintiffsShopNC software was written inPHP+MYSQL software,and thatboth PHP and MYSQL softwarebelonged to the open-s

298、ourcesoftware,withPHPsoftwareusing the PHPCCPL open-sourceagreement based on the GPLopen-sourceagreement,andMYSQL using the standard GPLopen-sourceagreement.Theauthors of the ShopNC softwarewritten in PHP and MYSQL havethe right of authorship underboth the CCPL and GPL opensourceagreements,butPlaint

299、iffs cannot prohibit otherpartiesfromadapting,using,reproducing,or publishing thesoftware,or from charging otherpartiesfortheuseofthesoftware.Views of the CourtThe court held that the PHPopen source software Chineseofficial website manual explicitlyused the CC agreement as theaccompanyingopensourcel

300、icense agreement,and it shouldbe clear that the open sourcenature of the software manualCC license is not equivalent tothesoftwarelicense,whetherthe PHP software is open sourceandtheopensourcerightdepends on what kind of licensethe author of the PHP softwarechooses.AlthoughthePHPmanualadoptedtheCrea

301、tiveCommonslicenseagreement,the software in question is alsowritten in PHP language,but thecomputerlanguageitselfhasthe attributes of the tool,writteninaparticularcomputerlanguageShopNCsoftwareworksthroughtheauthorscreative intellectual labor of theworksofingenuityandthecomputerlanguagedoesnotreflec

302、t the latter as the basis forthederivationoftherelationship between the works,so it does not belong to theinterpretation of the languageof PHP works.Typical significanceThe case made it clear that asoftwareworkwritteninaparticularcomputerlanguagereflects the authors individualexpression of the softw

303、are work,and that there is no relationshipof succession or derivation withthe computer language used astheauthoringtool,andthatthere should be no open sourceconductivity between the two.2.DigitalParadisev.Pomelo Technology:TheFirst Case Involving GPLOpen Source AgreementinChinasJudicialPracticeCase

304、summaryDigital Paradise developedthesoftwareHBuilder,whichincludesthreeplug-ins:thecodeinputmethodfunctionplug-in,therealmachinerunning function plug-in,andthe change-as-you-go functionplug-in.Pomelo developed thesoftware APICloud,and DigitalParadise believed that PomelosAPICloud used the GPL openso

305、urce code of the above threeplug-ins(theagreementwasGPL3.0),whichinfringeditssoftware copyright on HBuilder,andsuedtothecourtrequestingthatPomelobejudgedtobearthelegalresponsibility of compensatingthelossandotherlegalliabilities.Views of the CourtThe Court of First Instanceheld that the three plug-i

306、ns inquestionwereindependentsoftware works,there was noGPL open source agreement fileinthefolderofthethreeplug-ins,and there was no GPLopen source agreement file intherootdirectoryofthesoftwareinquestion,eventhough the other folders of thesoftware in question containedGPLopensourceagreementfiles,the

307、 agreement was notbinding on the three plug-ins inquestion,andPomeloconstitutedcopyrightinfringement.Thecourtofsecond instance also recognizedthe legal effect of GPL.Typical significanceThe case is the first caseinvolving the GPL open sourceagreementinChinasjudicialpractice,the case involves thekey

308、issue is the GPL agreementsstrong contagious issue,thecourt of first instance quotedtheprovisionsoftheGPLversion 3 released in June 2007,the court of second instancealso accepted the court of firstinstance on the validity of theGPL agreement.The court ofsecond instance also acceptedthe argument of t

309、he court offirst instance on the validity oftheGPLagreement.ThisindicatesthatourcourtsrecognizethattheGPLagreement is legally binding inChina.However,according tothe decision of the court of firstand second instance,the courtdid not examine and discuss therelevantcontentsofthecontagious clause of th

310、e opensourceagreementandthetechnical details of the software,and the judgment was based ona simple basis,and there is stillroom for further discussion onwhetherthesoftwareinquestion is applicable to thecontagious issue.3.Luo Box v.Wind Spirit:open source licenses arecontractual in natureCase summary

311、PlaintiffJiningLuoboxNetworkTechnologyCo.Ltd.independentlydevelopedLuobox(VirtualApp)plug-inframework virtual engine systemVirtualAppV1.0(hereinafterreferred to as the software inquestion),and it disclosed thesource code of the software inquestiononGitHub,aninternationallyrenownedsoftware hosting pl

312、atform andobtainedacertificateofcomputersoftwarecopyrightregistration in 2017.VirtualAppbegan to introduce open sourceprotocols starting with the July8,2016version,initiallytheLGPL3.0protocol,whichwasreplacedwiththeGPL3.0protocol on August 12,2016.OnOctober29,2017,Plaintiffsdeletedfromthesubsequento

313、pensourceversionsofVirtualApp On October 29,2017,PlaintiffdeletedthephraseGPL3.0 from the subsequentopen source version of VirtualApp,andin2019,PlaintiffdiscoveredasoftwarecalledDim Sum Desktop,and aftercomparingthesourcecode,found that Dim Sum Desktopwas substantially similar to thesoftwareinquesti

314、on.Aftercomparing the source code,theplaintiff found that Dim SumDesktopwassubstantiallysimilartothesoftwareinquestion,and therefore filed asoftware copyright infringementlawsuit.Views of the CourtThe Shenzhen IntermediateCourt held that,1.the GPL3.0agreementiscontractualinnature,andisacopyrightagre

315、ement between the licensorand the user,and the relevantprovisions of the contract laware applicable.2.the plaintiff isthecopyrightownerofthesoftware in question,and theopensourcesoftwarerightsdefense does not need to gothroughtheconsentorauthorization of all contributors,and the plaintiff is entitle

316、d to filethepresentlawsuit.3.thedefendant has used the opensourcecodeattachedtotheGPL3.0 agreement,and yet itdoes not The defendant usedtheopensourcecodewithGPL3.0 agreement,but did notfulfilltheconditionsofusestipulated in the agreement,andthe authorization obtained bythedefendanthasbeenautomatical

317、lyterminated,therefore,the acts of copying,modifyinganddistributingcarried out by the defendantconstitute an infringement ofthe copyright due to the loss ofthe source of rights.Typical significanceThis case is the first judicialcaseinChinatoclarifythenatureoftheGPL3.0agreement.Thecourtdetermined tha

318、topen sourceagreements are contractual innature,and that the defendantin this copyright dispute casehadviolatedtheGPL3.0agreement,which ledtotheautomaticterminationoftheGPL 3.0 agreement,thus losingtheprotectionofthesourcecode license under the GPL 3.0agreement,and constituting aninfringement of the

319、 copyright.4.Luo Box v.Playmate:Open Source Licenses areAtypicalCopyrightLicenseContractswithCancellation ConditionsCase summaryRoddy,ashareholderofRobox,uploadedtheinitialsource code of his VirtualAppsoftware on the Github websiteunder the GPLv3(GNU GeneralPublicLicenseVersion3)open-sourcelicense,w

320、ithanadditionaldisclaimerthatanyonewhousesitcommercially needs to purchaseit,and then removed the GPLv3license and stopped updating it,andmovedontothedevelopment of a closed-sourcecommercial paid version.Later,theGPLv3agreementwasremovedandupdateswerediscontinuedinfavorofthedevelopmentofaclosed-sour

321、ce,commercial,fee-basedversion.Loboxacquired the copyright of thesoftware in question by way ofassignmentandregisteredit.Playmatedevelopedfourinfringing WeChat video beautycameraAPPsanduploadedthem on various platforms forusers to download,but did notprovidethesourcecodefordownload.UserscantrytheAPP

322、s for free for half an hour,and after that,they need to paya membership fee to continueto use the APPs.The appraisalreportprovidedbyLoboxclaimed that the sandbox splitfunction of the four allegedlyinfringingsoftwarewassubstantiallysimilartothesoftware in question,and thatPlaymatescollectionofmembers

323、hip fees and failure toprovidethesourcecodeconstitutedinfringementbyviolatingtherestrictiononcommercial use clause and theGPLv3agreement,andrequestedthatPlaymatebeordered to cease to provide thedownload,installation,andoperation services for the foursoftware,and to compensate forthe economic loss of

324、 15 millionyuan and reasonable costs of150,000 yuan for defending therights.The court requested thatPlaymate be ordered to stopprovidingdownloadandinstallation services for the foursoftwareproductsandcompensateforeconomiclosses of 15 million yuan andreasonable costs of defendingthe rights.Views of t

325、he CourtThe Guangzhou IntellectualProperty Court held that Rodywasthemostimportantcontributor to the software inquestion,and that Lobox hadthe right to bring this lawsuitalone.Luo Box Company has noright to add a commercial userestriction reservation clause tothe project in question whichapplies the

326、 GPLv3 agreement.Part of the functional code ofSandbox Split was released as aderivative part of the infringingsoftware as a whole,and theGPLagreementishighlycontagious,soPlaymatesfailure to open source the entiresource code of the infringingsoftwareviolatedtheagreement.theGPLv3agreementisacopyright

327、contractwithaterminationcondition,andthelicensingterms are the conditions of thecopyrightlicense.Playmateviolated the GPLv3 agreement,and the authorization obtainedunder the GPLv3 agreement wasautomaticallyterminated,andtherewasnolegalorcontractual basis for Playmateto use the software in question,t

328、husconstitutinganinfringement of the copyright.Theotherthreedefendantswerenotatfaultfortheircollection behavior and did notneedtobearresponsibility.Accordingly,the court ruled thatPlaymatestoppedtheinfringement and compensated500,000 RMB for the economicloss and reasonable expensesincurred by Lobox.

329、After the firstinstance judgment,both partiesdid not appeal.Typical significanceThejudgmentfurtherclarified the legal nature of opensourceagreements,andalsoprovided an in-depth analysisandinterpretationofthedevelopment,classification,andextra-territorial judicial views ofopen source agreements,as we

330、llas a detailed overview of therelevantrulesoftheGPLv3agreement.It also clarifies manyissues related to open sourcesoftware(e.g.whethertheindependentworksinthecompilation work of softwarecollectionpackagearecontagious to each other,thejudgmentstandardofcooperative work,whether thesubmission of code

331、by othercontributorsofopensourcesoftware has substantive impacton software copyright),and alsoclarifies the judicial attitude ofattachingimportancetoandsupporting the development ofopensource.Thecaseisundoubtedly a good example ofthe importance of open sourceand closed source software.Thiscase undou

332、btedly points out thedirectionforthemixedoperation of open source andclosed source software,and is ofgreat significance as a judicialguide for the compliance andgovernanceofopensourcesoftware.5.Shining Fashion v.Buluanmai:determiningwhether the proceedingsinquestionarederivativeorstand-aloneproceedi

333、ngsCase summaryNo Mess Buy developed theNo Mess Buy Fashion AmoySoftware for website operation.Shining Fashion also developedthe software for the operationof the website.The companybelieved that the relevant codefilesofShiningFashionCompany used the source codeof the software,infringing on itssoftwarecopyright,andsuedthecourt,requestingthatShiningFashion Companybejudgedtobearthelegalresponsibility