我們目前所處的時代被稱爲“ABC（AI、Big Data、Cloud）時代”，也是大量採用開源軟件的時代。在這個過程中，不可避免地會遇到開源軟件合規的問題，而其中最讓人感到困惑的，可以說就是 GPL 許可證傳染性問題。那麼 GPL 軟件是不是真的像傳說中的避之唯恐不及，其傳染性風險令人談之色變呢？本次演講和大家簡要探討一下 GPL 傳染性問題。
**在 GPL 傳染性判斷時，是否爲獨立作品是非常關鍵的。
**
第一部分：從合規到牟利
以最爲嚴格的 GPL 許可證來說，自由軟件基金會和自由軟件管理機構是全球推行 GPL 許可的主要機構，其追求的主要目標之一是實現 GPL 的合規，對於那些在無意中違反 GPL 許可證的行爲，本着“懲前毖後，治病救人”的原則，大多數還是以教育和幫助爲主，並不會刻意追求罰款、賠償等。
但是，隨着開源軟件合規和訴訟生態的發展，湧現了更多類型的新玩家。根據國外律師的觀察，除了諸如 SFLC、SFC 等傳統的合規機構之外，近年來出現了比較激進的例如 McHardy 這樣的版權流氓Copyright Troll，或者說是 GPL 牟利者，其主要目標已經從合規轉變爲牟利，要求對違規行爲頒發禁令或進行賠償。
根據“開源智慧專欄”發表的翻譯文章《如何應對開源軟件的版權牟利者？ 開源律師說這樣做！》，GPL 牟利者 McHardy 已經騷擾了 50 多個目標，據說有些國內企業也在其中。
面對越來越複雜的開源軟件合規態勢，作爲開源軟件用戶來說，對於許可證合規問題，需要引起重視，而 GPL 傳染性顯然是其中最讓人頭疼的問題。
第二部分：GPL 傳染性判斷
對於軟件企業的技術人員來說，開源代碼是否好用，是他們選用開源代碼的重要標準之一，而不會過多考慮許可證問題。但對於企業的合規和法律部門來說，自己企業的技術人員使用了哪些開源軟件，這些開源軟件採用哪些許可證，則是需要進行排查和梳理，做到心中有數。而對於採用 GPL 許可證的軟件，爲了避免傳染性，是不是必須簡單地“一刀切”，絕對禁止使用呢？
我們認爲，根據 GPL 軟件類型和使用場景的不同，其傳染性風險也存在不同。其中一個關鍵的分界點，在於自用與分發。
自用的範疇比較廣泛，在公司個人、部門使用，甚至在公司內部分發，都可以自由使用。
對於編譯器、解釋器等工具類軟件，其主要作用是對代碼進行加工，可以歸爲自用的範疇，但也要區分 GPL 工具類軟件是否將自身代碼混進其所加工的代碼。例如 GCC 是 GPL 編譯器，但使用 GCC 不會感染被編譯的源文件。
對於採用 GPL、LGPL 許可證的軟件，如果放在服務器/雲上以 SaaS 方式對外提供服務，也可以算作自用的範疇。但是，採用 AGPL 許可證的軟件除外，AGPL 專門針對 SaaS 方式進行約束。
我們接着再來看分發，對於一些必須分發出去的 GPL 軟件，其類型也有多種。對於一些相對獨立的軟件，需要注意與自有代碼是各自獨立還是複雜的糅合，是否構成了結合作品。對於諸如 MQTT 等協議實現類的軟件，其實現方式有多種，可以選擇採用寬鬆許可證的開源軟件。許多開源軟件也採用雙重授權，如果擔心開源版本的風險問題，可以選擇花錢購買其商業授權版本。
對於自有代碼與 GPL 軟件的鏈接/混合，也分幾種情況。例如對於自有模塊 A 和 GPL 模塊 B，需要根據兩者之間的通信親密程度以及傳輸數據的複雜程度，判斷兩者是否構成了結合作品。對於 GPL 插件，需要分析自有代碼主程序對其調用的方式，判斷是否造成傳染。
對於自有代碼與 GPL 庫的鏈接，根據 GPL 許可證，無論是採用靜態鏈接或動態鏈接方式，都會造成自有代碼被傳染，必須進行公開。而之後發表的 LGPL 許可證，則對 GPL 庫的鏈接稍微放鬆了限制。由於 LGPL 專門針對庫而制定，採用 LGPL 的庫相對來說應該已經考慮了對調用程序的影響，更容易避免被“傳染”。
我們再來看一下“自用”，GNU 官方問答對於自用的解釋非常寬泛，在一個企業集團的總公司、分公司、子公司等使用，都可以算作自用的範疇，不構成分發。
對於採用 GPL、LGPL 許可證的軟件，如果放在服務器/雲上以 SaaS 方式對外提供服務，不構成分發，但如果將其部署在用戶終端上，則構成分發，帶來傳染性問題。
對於採用 AGPL 許可證的軟件，即便是運行在服務器/雲上，如果後續用戶對其源代碼進行了修改，也必須將修改版本發佈出來。
需要注意的是，某個GPL軟件的使用場景如果發生變化，之前對其傳染性風險的判斷也有可能變化，需要根據新的使用場景重新評估。
第三部分：MongoDB 案例分析
國外有文章甚至開玩笑說，正是因爲有了 MongoDB，人們對 AGPL 許可證的看法有了明顯改變，從 “never use AGPL” 轉變成 “never use AGPL except for Mongo DB”。
具體看一下 MongoDB 的許可政策。MongoDB 的數據庫部分採用嚴格的 AGPL v3.0 許可證，並且是雙重許可，用戶既可以選擇開源版本，也可以選擇商業授權版本。MongoDB 的驅動部分則採用寬鬆的 Apache v2.0 許可證。
通過對數據庫和驅動分別適用不同的許可證，MongoDB 在堅守其自由軟件本質的同時，也爲用戶大開方便之門。
其中需要注意，如果用戶修改了 MongoDB 核心數據庫的源代碼，則必須將修改版本發佈出來，回饋給社區。
反之，如果用戶的程序僅是使用 MongoDB 數據庫，沒有對數據庫源代碼進行修改，則不必發佈該用戶程序。Copyleft 僅適用於 mongod 和 mongos 數據庫，而驅動則採用 Apache 許可證，所以用戶的程序如果通過 MongoDB 官方推薦的驅動與數據庫進行交互，也不被視爲 AGPL 範疇下的結合作品，而是單獨的程序或作品，無需擔心被傳染。
從 MongoDB 這個案例可以看出，一些開源軟件的著作權人爲了保護和推廣自己的開源項目，可以說是“煞費苦心”，絞盡腦汁地在許可證方面進行精巧的設計，給出一些“例外聲明”，爲用戶“開後門”，讓用戶可以相對比較放心地使用，推動了這些開源軟件的迅速普及。