開源協議超過 2000 種，那我選錯了，能捅出多大簍子？

作者：騰訊技術工程 2025-05-16 10:43:59

這幾年，因為開源協議“倒大霉”的開源項目不在少數。今天，就開源協議的話題，我們邀請了八位工程師一起來聊聊。

一、話題背景

這幾年，因為開源協議“倒大霉”的開源項目不在少數，典型的案例例如因GPL協議的“傳染性”而被索賠9億等等（只要產品中用了GPL代碼，所有關聯代碼必須開源）。那是不是說，GPL傳染性極高，用docker隔離GPL代碼也無法規避傳染性，那就不用GPL協議就好了？MIT寬松又友好，選MIT是不是就沒啥風險？

關于開源協議，我們邀請了8位工程師一起來聊聊（方向參考如下）：

大家選擇開源協議有啥經驗嗎？good case、bad case都可以！
大家選開源協議時，是優先技術自由還是商業安全？

二、鵝廠工程師的看法

1. @moto-技術運營▼

從我許可證選擇有一個很經典的決策樹：

但是選擇許可證有終端用戶/開發者/對外開源三種場景，三者的視角是不一樣的：

終端用戶：使用軟件最好是能關注一下軟件的授權信息，但一般會在風險成規模之后才會導致訴訟，所以作為員工建議積極配合相關的指引操作并密切各個渠道的提醒。
開發者：寬松型/Permissive開源許可證（MIT 等）風險可控，Copyleft 許可證（如 GPL）需結合項目情況判斷。
對外發布開源項目：產品評估包括項目目標與權限、法律合規（選 OSI 認證許可證）、社區與商業化三方面。

2. @grey-前端開發▼

開源協議的選擇本質上是技術理想與商業現實的平衡??——比如GPL的“傳染性”并非洪水猛獸，我理解它的核心是捍衛開源生態的互惠原則。若企業基于GPL代碼獲利卻不回饋社區，法律風險自然是會存在的。——比如MIT協議雖商業友好，但也存在隱患：如果核心代碼被競品封裝成閉源產品，開發者可能就會失去技術主導權。

所以如何選擇開源協議其實要分情況討論：

如果希望技術快速普及（比如工具庫這些），可以選MIT/Apache；如果是構建生態壁壘（如數據庫），GPL/AGPL協議會更穩妥~
開源協議可隨商業階段迭代，也可以選擇有法律兜底的協議，保證開源的同時又保留商標控制權

技術自由與商業安全其實并非對立的關系，關鍵還是在協議設計與商業模式的權衡上~

3. @ruixiang-后臺開發▼

目前開源社區對于協議兼容和特性已經有很多非常成熟的總結了，例如可以參考開源社的相關總結，原貼鏈接如下：

https://kaiyuanshe.github.io/oss-book/Open-Source-Legal-Compliance-Practice.html
https://kaiyuanshe.github.io/oss-book/Open-Source-License.html

4. @osong-運營開發▼

剛好前端時間在處理開源協議傳染的問題。

因為自己的項目用的是Java語言的，很多底層的包都是引用開源的項目，尤其比較多的apache協議， gpl協議，lgpl協議的都有。

大家選型的時候盡量用apache協議，mit協議或者bsd-new協議的開源項目，這種屬于低風險的。

如果涉及傳染性的問題，不同的協議處理方式也是不同的：

(1) 高風險協議：GPL-3.0、GPL-2.0、elastic-license-v2

針對這類高風險的協議，需要做的就是【隔離空間地址技術】來防范風險。

怎么實現隔離地址空間：通過技術手段使自研項目與GPL程序在相互隔離（非共享）的地址空間內運行來增強二者的獨立性，以避免被“傳染”，并被迫開放源代碼。

實踐中，常用的技術手段包括：管道（pipes）、套接（sockets，如TCP socket）、命令行參數（ command-line ）、使用HTTP API進行交互或直接通過API接口暴露給進程內其他組件進行調用等。

實踐中，可以通過測試兩個模塊是否在不同的進程中運行來輔助確定二者是否位于非共享的地址空間。

(2) 中風險協議：協議：LGPL-2.1-or-later、LGPL-3.0-only、lgpl-3.0

涉及LGPL的組件，請重點判斷是否是【動態調用】的LGPL庫，如果是動態調用的話，一般來說是可以阻卻傳染性風險的

協議：edl-1.0、cddl-1.0、epl-2.0、Elastic-2.0

這類風險關注是否【對組件進行了修改】，如果進行了代碼上的修改，我們則需要將修改部分進行對外開源。

5. @chuanliang-應用開發▼

GPL 這種協議是有些大牛重塑軟件世界打下的定海神針。他們的傳染性是為了保證開源的路徑是可以延長的，開源版圖會越來越大。

很多小公司本身是不具備開發基礎組件能力的，需要穩定的輪子就必須要向社區要，這時候因為商業利益考量，又不能把自己的其他產物全都貢獻出去，如果沒有 MIT，其實就是兩頭不到岸。MIT 這樣的協議就是這些小公司的救星。

因為 mit 非常寬松，所以確實目前 mit 相關的項目（Node、React）都沒有出現過 GPL 式的風險。所以對于使用者而言，選 MIT就是無風險選項，這完全沒有問題。

這種技術路線的穩定問題倒不只在協議上，問題在于：你是否能夠完整掌控你的技術組件？對于希望掌控某類技術實現的公司而言，抄襲/自研一個社區組件，才是最沒有風險的方案，因為沒有人跟你簽任何協議。那些白嫖技術社區省下來的資源，完全可能有一天因為別的事情支付出去-比如當年Python 升級、CentOS 改變政策-是的，GPL也不能保證它一定會按你想的那樣開放。如果一家公司擁有自研組件能力，就可能要從反面看待這個技術問題，如果我的技術組件有辦法產生跨越公司邊界的影響力，我有沒有辦法通過社區變現？這時候選擇什么協議，就是看變現的價碼的怎么設計了。

要怎么看待協議，最好先看看你是進攻端還是防守端。如果你是防守端，最好的方案仍然是不簽協議。

6. @yinjie-事務型開發▼

首先，需要明確項目目的和用途：

個人化或者非商業項目：就可以選擇更為寬松的協議，也方便推廣和傳播；
商業化項目：需要關注協議對商業化的限制。

其次，需要關注專利條款，避免專利相關的風險。

總的來說，取決于不同公司對商業安全和技術自由的判斷。

選主流寬松協議（MIT/Apache 2.0）是最保險的做法。

7. @hanchen-應用研究▼

(1) 選擇開源協議的經驗

① Good Case

以TensorFlow為例，它采用MIT協議。這使得該項目能夠在學術界、工業界廣泛傳播和使用。開發者可以自由地將其用于各種研究和商業項目中，無需擔心過多的限制，極大地促進了深度學習技術的發展和應用。

② Bad Case

某些項目使用了非常嚴格的開源協議，要求所有基于該項目的衍生作品都必須開源且使用相同協議。這可能會限制項目的應用場景和商業合作機會。例如，一些企業可能因為擔心無法滿足協議要求而不敢使用該項目，導致項目的推廣和發展受到阻礙。

(2) 技術自由與商業安全的權衡

對于一些開源社區的純粹技術愛好者和致力于推動技術創新的開發者來說，他們可能更看重技術自由。他們希望自己的代碼能夠被自由地使用、修改和傳播，以促進技術的快速發展和共享。例如，在一些前沿的學術研究項目中，研究者們通常會選擇寬松的開源協議，以便讓全球的同行都能夠自由地獲取和改進代碼，加速研究成果的轉化和應用。