ABC 時代 GPL 許可證傳染性問題探討

我們目前所處的時代被稱為「ABC（AI、Big Data、Cloud）時代」，也是大量採用開源軟體的時代。在這個過程中，不可避免地會遇到開源軟體合規的問題，而其中最讓人感到困惑的，可以說就是 GPL 許可證傳染性問題。那麼 GPL 軟體是不是真的像傳說中的避之唯恐不及，其傳染性風險令人談之色變呢？本次演講和大家簡要探討一下 GPL 傳染性問題。

演講內容主要包括四個部分，第一部分為「從合規到牟利」，簡要介紹目前開源軟體合規環境的變化情況。第二部分為「 GPL 傳染性判斷」，介紹從實務角度考慮，GPL 傳染性判斷的流程、方法和原則。第三部分為「MongoDB 案例」，介紹了採用 AGPL 許可證的 MongoDB 案例。第四部分為「開源智慧專欄」，簡單介紹集慧智佳與 Linux 中國合作開辦的「開源智慧專欄」。

第一部分題目為「從合規到牟利」，介紹了近些年開源軟體合規和訴訟態勢發生的變化，已經從單純的「尋求合規」轉變為「追求牟利」，而這種變化使得開源軟體用戶的合規風險變得越來越嚴重。

以最為嚴格的 GPL 許可證來說，自由軟體基金會和自由軟體管理機構是全球推行 GPL 許可的主要機構，其追求的主要目標之一是實現 GPL 的合規，對於那些在無意中違反 GPL 許可證的行為，本著「懲前毖後，治病救人」的原則，大多數還是以教育和幫助為主，並不會刻意追求罰款、賠償等。

但是，隨著開源軟體合規和訴訟生態的發展，湧現了更多類型的新玩家。根據國外律師的觀察，除了諸如 SFLC、SFC 等傳統的合規機構之外，近年來出現了比較激進的例如 McHardy 這樣的 版權流氓 （ Copyright Troll ） ，或者說是 GPL 牟利者，其主要目標已經從合規轉變為牟利，要求對違規行為頒髮禁令或進行賠償。

根據「開源智慧專欄」發表的翻譯文章《如何應對開源軟體的版權牟利者？ 開源律師說這樣做！》，GPL 牟利者 McHardy 已經騷擾了 50 多個目標，據說有些國內企業也在其中。

面對越來越複雜的開源軟體合規態勢，作為開源軟體用戶來說，對於許可證合規問題，需要引起重視，而 GPL 傳染性顯然是其中最讓人頭疼的問題。

第二部分我們具體探討一下「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 是一個非常典型的使用 AGPL 許可證的開源軟體。國外有文章甚至開玩笑說，正是因為有了 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 這個案例可以看出，一些開源軟體的著作權人為了保護和推廣自己的開源項目，可以說是「煞費苦心」，絞盡腦汁地在許可證方面進行精巧的設計，給出一些「例外聲明」，為用戶「開後門」，讓用戶可以相對比較放心地使用，推動了這些開源軟體的迅速普及。

「開源智慧專欄」由集慧智佳與國內領先的開源社區 Linux 中國合作創辦，聚焦開源軟體的知識產權問題，旨在傳播域外動態，梳理經典判例，翻譯重要文本，關注行業熱點，分享實務經驗。

在第三部分簡要介紹了 GPL 傳染性判斷的方法和原則，其主要依據是自由軟體基金會發布的 GPL 許可證官方問答。我們也對這個問題進行了翻譯，陸續發表在本專欄中。此外，對於此前鬧得沸沸揚揚的 Facebook 公司 react 許可證事件，我們也進行了實時的跟蹤和解讀。

以上所列為本專欄從創辦至今所發表的文章列表，大家可以登錄 Linux 中國的「開源智慧專欄」查看，或者掃描關注微信公眾號，接收實時推送的相關文章。

最後，簡單介紹一下我本人。我所供職的單位——集慧智佳是中國第一家在新三板掛牌（838286）的知識產權諮詢公司，對開源知識產權問題一直進行持續的跟蹤和研究，曾承擔國家級的開源知識產權研究課題，並為國內知名的互聯網軟體企業提供開源知識產權風險排查服務。

我在集慧智佳互聯網事業部擔任高級諮詢師，擅長專利檢索、專利分析、專利布局、競爭對手跟蹤、FTO 調查、開源軟體知識產權風險分析；長期為聯想、中國移動、海爾、東軟等互聯網企業、高科技公司提供知識產權諮詢服務；擔任「開源智慧專欄」主要撰稿人。

• 2017 年 10 月 14 日，在 GNOME 2017 亞洲峰會上發表題為《開源軟體的知識產權風險》演講。
• 2017 年 11 月 18 日，在 2017 中國開源年會上發表題為《ABC 時代 GPL 許可證傳染性問題探討》演講（PDF）。

歡迎大家圍繞開源軟體知識產權問題與我進行交流！

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive