一、話題背景

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

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

• 大家選擇開源協(xié)議有啥經(jīng)驗嗎？good case、bad case都可以！
• 大家選開源協(xié)議時，是優(yōu)先技術(shù)自由還是商業(yè)安全？

二、鵝廠工程師的看法

1. @moto-技術(shù)運(yùn)營▼

從我許可證選擇有一個很經(jīng)典的決策樹：

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

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

2. @grey-前端開發(fā)▼

開源協(xié)議的選擇本質(zhì)上是技術(shù)理想與商業(yè)現(xiàn)實的平衡??——比如GPL的“傳染性”并非洪水猛獸，我理解它的核心是捍衛(wèi)開源生態(tài)的互惠原則。若企業(yè)基于GPL代碼獲利卻不回饋社區(qū)，法律風(fēng)險自然是會存在的。——比如MIT協(xié)議雖商業(yè)友好，但也存在隱患：如果核心代碼被競品封裝成閉源產(chǎn)品，開發(fā)者可能就會失去技術(shù)主導(dǎo)權(quán)。

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

• 如果希望技術(shù)快速普及（比如工具庫這些），可以選MIT/Apache；如果是構(gòu)建生態(tài)壁壘（如數(shù)據(jù)庫），GPL/AGPL協(xié)議會更穩(wěn)妥~
• 開源協(xié)議可隨商業(yè)階段迭代，也可以選擇有法律兜底的協(xié)議，保證開源的同時又保留商標(biāo)控制權(quán)

技術(shù)自由與商業(yè)安全其實并非對立的關(guān)系，關(guān)鍵還是在協(xié)議設(shè)計與商業(yè)模式的權(quán)衡上~

3. @ruixiang-后臺開發(fā)▼

目前開源社區(qū)對于協(xié)議兼容和特性已經(jīng)有很多非常成熟的總結(jié)了，例如可以參考開源社的相關(guān)總結(jié)，原貼鏈接如下：

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

4. @osong-運(yùn)營開發(fā)▼

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

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

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

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

(1) 高風(fēng)險協(xié)議：GPL-3.0、GPL-2.0、elastic-license-v2

針對這類高風(fēng)險的協(xié)議，需要做的就是【隔離空間地址技術(shù)】來防范風(fēng)險。

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

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

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

(2) 中風(fēng)險協(xié)議：協(xié)議：LGPL-2.1-or-later、LGPL-3.0-only、lgpl-3.0

涉及LGPL的組件，請重點(diǎn)判斷是否是【動態(tài)調(diào)用】的LGPL庫，如果是動態(tài)調(diào)用的話，一般來說是可以阻卻傳染性風(fēng)險的

協(xié)議：edl-1.0、cddl-1.0、epl-2.0、Elastic-2.0

這類風(fēng)險關(guān)注是否【對組件進(jìn)行了修改】，如果進(jìn)行了代碼上的修改，我們則需要將修改部分進(jìn)行對外開源。

5. @chuanliang-應(yīng)用開發(fā)▼ 

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

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

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

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

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

6. @yinjie-事務(wù)型開發(fā)▼

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

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

其次，需要關(guān)注專利條款，避免專利相關(guān)的風(fēng)險。

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

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

7. @hanchen-應(yīng)用研究▼

(1) 選擇開源協(xié)議的經(jīng)驗

① Good Case

以TensorFlow為例，它采用MIT協(xié)議。這使得該項目能夠在學(xué)術(shù)界、工業(yè)界廣泛傳播和使用。開發(fā)者可以自由地將其用于各種研究和商業(yè)項目中，無需擔(dān)心過多的限制，極大地促進(jìn)了深度學(xué)習(xí)技術(shù)的發(fā)展和應(yīng)用。

② Bad Case

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

(2) 技術(shù)自由與商業(yè)安全的權(quán)衡

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

8. @jack-產(chǎn)品策劃▼

(1) 議題一：大家選擇開源協(xié)議有啥經(jīng)驗嗎？good case、bad case都可以！

開源協(xié)議種類繁多，選錯可能帶來嚴(yán)重后果。印象最深刻的就是～～～某公司曾因使用GPL協(xié)議代碼被索賠9億元！原因是GPL的“傳染性”要求衍生作品必須開源，即使通過Docker隔離也無法規(guī)避。這一案例警示企業(yè)：技術(shù)自由與商業(yè)安全需謹(jǐn)慎權(quán)衡。

① Good Case

MIT協(xié)議因其寬松性被廣泛采用。例如，Node.js和Vue.js等流行項目均使用MIT協(xié)議，允許閉源商用，吸引了大量企業(yè)參與生態(tài)建設(shè)，既推動了技術(shù)發(fā)展，又保障了商業(yè)利益。

② Bad Case

除了某公司，還有一些企業(yè)因未遵守AGPL協(xié)議（如MongoDB的早期爭議）被迫公開代碼或支付巨額費(fèi)用。此外，部分開發(fā)者誤用LGPL協(xié)議，導(dǎo)致動態(tài)鏈接的閉源軟件仍需開源修改部分，引發(fā)法律糾紛。

(2) 議題二大家選開源協(xié)議時，是優(yōu)先技術(shù)自由還是商業(yè)安全？

① 優(yōu)先級考量

• 技術(shù)自由導(dǎo)向：若項目追求最大傳播和協(xié)作（如基礎(chǔ)庫或科研工具），GPL/LGPL等互惠協(xié)議可確保改進(jìn)共享，但需接受衍生作品開源的限制。
• 商業(yè)安全優(yōu)先：若涉及閉源商用或SaaS服務(wù)，MIT、Apache或BSD更合適，它們允許自由修改和閉源分發(fā)，降低法律風(fēng)險

② 關(guān)鍵建議

• 明確需求：評估項目目標(biāo)是技術(shù)擴(kuò)散還是商業(yè)變現(xiàn)。
• 隔離非萬能：Docker等工具無法規(guī)避GPL/AGPL的傳染性，需從源頭選擇協(xié)議。
• 咨詢專業(yè)意見：復(fù)雜場景下，建議引入法律顧問審核協(xié)議兼容性。

總的來說～開源協(xié)議的選擇需結(jié)合戰(zhàn)略目標(biāo)，避免因疏忽導(dǎo)致商業(yè)或法律危機(jī)哈!