前言
作為一名遊戲開發者，是否曾因使用免費的開源軟體或工具大幅提升了專案進度？許多遊戲開發者在使用 GPL（GNU General Public License） 開源軟體時，往往忽略了其背後的隱藏風險，GPL 協議的強制開源條款可能迫使您將自己的專案也進行開源。今天將透過這篇文章從多個層面探討並深入剖析這一協議，幫助遊戲開發者避開這些可能影響商業化的陷阱。
GPL 開源協議的基礎概念
GPL是什麼?
GPL（GNU General Public License，GNU 通用公共許可證）是一種由自由軟體基金會（Free Software Foundation, FSF）推出的開源協議，旨在保障軟體使用者的四大自由，具體包括：
- 分發與共享軟體的自由
用戶可以自由地複製和分發原始或修改後的軟體版本，推動技術的傳播與應用。 - 改進軟體並公開分享的自由
如果對軟體進行了改進，用戶有自由將改進版本分享給他人，讓整個社群都能從中受益。 - 運行軟體的自由
用戶可以為任何目的運行軟體，無論是【個人用途】還是【商業用途】。 - 學習與修改軟體的自由
源代碼對所有用戶公開，允許學習軟體的運作原理並根據需要進行修改。
GPL 的核心理念是 Copyleft（著佐權），即允許用戶【自由使用】、【修改】和【分發】，但要求所有衍生作品必須遵循相同的開源協議，從而確保軟體的自由性得以延續。
GPL 的主要特性
- 複製自由
允許將軟體複製到任何電腦上，並且不限制複製的【數量】或【用途】。 - 修改自由
開發者可以自由對軟體進行修改，【增強功能】或【修復漏洞】，並可以將修改後的版本重新分發。 - 共享自由
用戶可以自由分發軟體，但需遵守 GPL 的條款，例如保留原始的協議內容，並向接收者提供完整的源代碼。 - 傳染性
GPL 的 "傳染性"（Copyleft）條款要求，任何包含或基於 GPL 軟體的作品，都必須同樣以 GPL 協議進行開源，不能轉換為其他封閉協議。這是 GPL 與其他開源協議（如 MIT、Apache）的主要區別之一。
GPL 是否允許商業用途？
GPL商用的可否是大家常討論的問題，事實上 GPL 並不禁止商業用途，而且明確允許用戶將 GPL 軟體用於商業環境中，包括直接銷售軟體或將其作為產品的一部分進行分發。但在進行商業用途時，需嚴格遵守 GPL 的開源條款，尤其是 Copyleft（著佐權）的規定。
- 公開源代碼
如果你基於 GPL 軟體進行修改或二次開發，並將修改後的軟體分發給他人，則必須公開源代碼，並採用與原軟體相同的 GPL 協議。這適用於商業銷售的情況。 - 不得封閉源代碼
無論是原始軟體還是修改後的版本，都必須以開放原始碼的形式提供給用戶。你不能將 GPL 軟體或其衍生作品封閉起來，否則會違反協議。 - 分發時需附帶授權聲明
在分發軟體時，必須附帶原始的 GPL 許可證文件，並聲明軟體的開源性質。同時應告知用戶他們有權獲得源代碼並自由使用。 - 允許用戶自由分享
購買或獲得你商用版本的用戶有權根據 GPL 協議自由分享這款軟體的副本（包括源代碼）。
不同版本的 GPL 協議與其傳染性
GPL 協議的演進歷程
| 版本 | 發布年份 | 特點 |
|---|---|---|
| GNU GPL v1 | 1989 年 | 最初版本，規定所有派生作品必須免費並公開原始碼。 |
| GNU GPL v2 | 1991 年 | 引入獨立部分的概念，允許部分代碼不受傳染性影響，解決第一版中部分不明確的法律問題。 |
| GNU GPL v3 | 2007 年 | 擴大傳染性的範圍，將所有衍生作品統一納入 GPL 的約束，增加對 Tivo-ization（硬體限制自由軟體）的防範條款。 |
GPL 不同版本的傳染性區別
- GPL v1：
任何使用 GPL 授權代碼的作品，無論是橫向結合（使用代碼部分或全部）還是縱向衍生（修改代碼），整體都需遵循 GPL 協議。 - GPL v2：
在橫向傳染的情況下，只有使用了 GPL 授權代碼的部分和衍生部分需要遵循 GPL 協議，而獨立部分則可不受影響，前提是獨立部分單獨分發且不與 GPL 部分【靜態】或【動態】結合。 - GPL v3：
無論橫向結合或縱向衍生，只要與 GPL 授權代碼結合的作品，均被視為不可分割的整體，需全面遵守 GPL 協議。
GPL 傳染性的定義與影響
GPL 的 "傳染性"（Copyleft）是指當 GPL 授權代碼與其他代碼結合後，整體作品需遵循 GPL 協議，也就是我們常聽到的 GPL感染的問題。其傳染性可以分為【橫向】和【縱向】兩個維度：
- 橫向傳染：
- 指在使用 GPL 授權的開源代碼時，凡是使用其部分或全部的代碼，整體作品需受 GPL 協議約束。
- 例如，若使用了 GPL 開源代碼的功能模組，這些模組與專案結合後，整個專案可能都會被視為受 GPL 約束的作品。
- 縱向傳染：
- 指直接在 GPL 授權代碼上進行【修改】、【優化】，形成衍生版本（如新增功能或修改功能），這些衍生作品也必須遵循 GPL 協議。
- 縱向傳染確保修改後的代碼仍保持自由與公開，促進軟體的共同發展。
GPL 傳染性對遊戲開發的影響
假設某遊戲開發者使用了一個 GPL 授權的開源物理引擎開發遊戲，以下是不同版本的影響：
- GPL v1：
- 使用該物理引擎，並將其結合進遊戲專案中，整個遊戲（包括獨立部分）都需遵循 GPL 協議，必須公開所有原始碼。
- 橫向傳染：無論結合部分是否修改，整體都會受影響。
- GPL v2：
- 修改了引擎（縱向傳染）或使用引擎功能模組（橫向傳染），則需公開相應的修改部分或使用的模組，但獨立於引擎的遊戲邏輯和其他模組可以保持專有授權。
- 例如遊戲的資源文件或未與引擎結合的腳本可以不公開，只需單獨分發。
- GPL v3：
- 無論是否修改引擎或其模組，只要該引擎與遊戲結合，整個遊戲都需遵循 GPL 協議，公開所有原始碼，包括與引擎無直接關聯的獨立部分。
- 橫向與縱向傳染擴大：任何與引擎結合的部分都受影響。
當遊戲開發者使用 GPL 授權的軟體或工具，需要了解這些軟體或工具可能對整個遊戲專案帶來的授權影響和潛在風險。以下用一張圖清楚說明實際上該如何判斷：
GPL 與其他開源協議的比較
目前市面上存在許多種類的開源協議，其中經過 Open Source Initiative 組織通過批准的開源協議目前有 58 種。我們在常見的開源協議如 【GPL】、【LGPL】、【MIT】、【BSD】 和 【Apache】，這些都是 OSI 批准的協議，如果要開源自己的代碼，最好也是選擇這些被批准的開源協議。
常見協議比較表
| 協議 | 特點 | 傳染性 | 商業友好程度 | 是否保留版權聲明 | 典型使用場合 | 兼容性 |
|---|---|---|---|---|---|---|
| GPL | 強制開源衍生作品，禁止閉源分發。 | 強 | 低 | 是 | 操作系統（Linux） | 與 MIT/BSD 兼容；與 Apache 有爭議 |
| LGPL | 對於非衍生作品（如動態連結）傳染性較弱。 | 弱 | 中 | 是 | 動態庫（Glibc） | 與大多數協議兼容 |
| MIT | 非常寬鬆，允許商業化和閉源分發。 | 無 | 高 | 是 | 前端框架（React）、工具類軟體 | 幾乎與所有協議兼容 |
| BSD | 與 MIT 類似，允許閉源分發。 | 無 | 高 | 是 | 程式語言（Go） | 幾乎與所有協議兼容 |
| Apache | 增加專利授權條款，對商業應用友好，但不強制衍生作品開源。 | 無 | 高 | 是 | 分散式系統（Hadoop, Kubernetes） | 與 GPL v3 兼容；與 GPL v2 不兼容 |
開源協議分析圖
這是一張烏克蘭程式設計師 Paul Bagwell 繪製的分析圖，內容已經由阮一峰老師翻譯並重新製作，整體來看簡單明瞭，說明了該如何選擇開源許可證。我覺得這是我見過最簡單的開源許可證講解，短短幾分鐘就能掌握這六種主要許可證之間的最大差異。
阮一峰老師曾在 2011 年製作了這份圖的中文版，雖然已經有一段時間，但到今日仍然非常的實用而且具有參考價值。將這張圖分享給各位開發者，主要是方便大家隨時查看，希望能對大家有所幫助。
相關介紹影片
企業應用 GPL 的挑戰與解決方案
在現代企業應用中，開源軟體的使用越來越普遍，無論是提升開發效率、降低成本，還是促進技術創新，開源軟體都扮演了重要角色。然而隨之而來的是開源協議的合規挑戰，尤其是像 GPL（GNU General Public License）這類強制要求公開源代碼的協議，對於使用者的商業模式與核心技術保護構成一定影響。企業需要平衡使用開源軟體帶來的優勢與潛在的法律風險，制定合理的合規策略，避免觸發協議中的傳染性條款，同時確保產品與服務的競爭力不受削弱。
實際案例分享
D-Link 案例
2006 年， 德國法院裁定 D-Link 違反 GPL 協議，因其產品中使用了 GPL 授權的軟體，但未遵守協議要求公開源代碼。最終 D-Link 被迫公開相關軟體的源代碼，這一判決確立了 GPL 在德國的法律效力。
Tesla 案例
Tesla 的車載系統使用了 GPL 授權的 BusyBox 軟體，但未按照協議要求公開源代碼。經自由軟體基金會（Free Software Foundation, FSF）質疑後，特斯拉採取行動，遵守 GPL 許可，並發布了部分車載技術的源代碼。
潛在後果
- 停止分發相關產品。
- 被迫公開商業機密代碼。
- 面臨法律訴訟與賠償風險。
再分享個 GPL 協議相關判決，中國大陸廣東省深圳市中級人民法院於 2021 年 6 月 30 日發布的判決書，裁定被告【福建風靈創景科技有限公司】及【北京風靈創景科技有限公司】違反 GPL 3.0 協議，未按規定開放修改後的源碼，構成侵權，並判賠 50 萬元。法院認定 GPL 3.0 具合同性質，違反協議授權自動終止，行為人失去合法權利，需承擔法律責任。
規避傳染性的策略
- 使用 SaaS 模式：通過僅提供線上服務（例如 Web 應用），避免軟體分發，從而減少 GPL 傳染性的影響。
- 動態連結與插件模式：保持 GPL 代碼與其他代碼分離，僅在用戶端進行結合，以降低傳染性風險。
- 選擇替代協議：在可能情況下，選擇使用 MIT、BSD 或 Apache 協議的開源軟體，這些協議對商業應用更為友好。
Android 的是如何規避 GPL感染的？
可以借鑒 Android 的運作模式，將開源服務整合到自家的開源封裝中，最終生成封閉的商業化產品。這種方式確保最終輸出的產品中不包含任何開源軟體的實質性部分。例如假設 A 是一個開源的程式編輯器，企業在此基礎上封裝開源功能，並利用 A 來完成特定程序的編寫工作。最後 B 作為封閉的程式碼產品，即使簡單地調用或觸發 A 的功能，也不會因與 A 的交互而影響 B 的封閉性。這種方法有效降低了 GPL 協議的傳染性風險。
為何遊戲開發者應關注 GPL 開源協議帶來的問題？
先來講講我當初怎麼會寫這篇文章，剛開始是因為我在整理並分享 Unity 的相關插件，當中包含了許多免費且開源的資源。在整理的這個過程中，意外發現許多開發者對於 GPL 授權的規範和應用有些疑惑，因此決定撰寫這篇文章，希望透過整理與分享相關資訊，讓大家在選擇和使用插件時更有方向，避免掉進授權的陷阱。
最後還是要回到遊戲開發上，為什麼遊戲開發者應關注 GPL 開源協議帶來的問題？
在遊戲開發中，許多軟體像是【物理引擎】、【腳色創建工具】、【視覺特效工具】都可能採用了GPL協議。若開發者未能正確理解協議條款並隨意地使用這些 GPL授權的軟體，可能無意中將遊戲專案置於必須公開源碼的風險中，這不僅會直接影響遊戲的商業化運營，也可能損害開發者的長期利益，這就是常常有人在討論的 GPL 開源協議陷阱。
實際影響與考量
對遊戲開發者而言，GPL 協議的傳染性特質帶來以下挑戰：
- 公開原始碼：使用 GPL 工具的遊戲專案，相關代碼必須公開，這可能導致【商業秘密】無法保護，影響核心技術的競爭力。
- 商業化運營的局限：GPL 要求免費公開源碼，與遊戲常見的【付費下載】、【訂閱服務】等商業模式存在衝突，甚至 可能導致商業模式難以落地。
- 靜態連結的風險：舉個例子，若遊戲開發團隊選用 GPL 授權的圖形渲染引擎，並將其【靜態連結】到遊戲中，則根據 GPL 條款，整個遊戲專案的代碼都可能需要公開，包括與引擎無關的其他部分。這對遊戲專案的【商業化和保密性構】成極大挑戰。
如何應對與建議
作為遊戲開發者，面對 GPL 授權工具時，應注意以下幾點：
- 深入理解協議條款：在選用任何開源工具前，務必詳細了解其授權協議，評估潛在風險。
- 審慎選擇開源工具：若商業化需求明確，應考慮使用【MIT】、【BSD】、【Apache】等更為寬鬆的開源協議工具，避免 GPL 的傳染性影響。
- 動態連結替代方案：若必須使用 GPL 工具，考慮以【動態連結】方式集成，減輕源碼公開的風險（需同時確認符合 GPL 條款）。
- 商業授權替代：部分 GPL 工具提供商可能同時提供【商業授權版本】，可根據需求購買許可，避免協議衝突。
當然講了這麼多，並不是要汙名化 GPL 協議。相反地 GPL 是一個非常重要且強大的授權條款，它推動了開源社群的發展，並讓開發者能免費使用功能強大的工具與資源。透過 GPL 更多人能參與軟體的創建和改進，形成良性循環。只要理解並遵守其條款，GPL 資源也能為遊戲開發者帶來巨大的助力，任何開發者在使用這些資源時，應該具備基本的授權意識，確保在專案的架構和商業目標之間找到平衡點。
結語
遊戲開發的道路本就充滿挑戰，但也正因如此，與社群分享經驗與知識，能幫助我們彼此減少摸索的時間，加速創新的腳步。我希望這篇文章不僅能解答一些關於 GPL 的疑惑，也能為各位開發者提供更多工具和靈感，讓大家更專注於創造出色的作品。開發之路漫長且充滿未知，唯有互相扶持與分享才能走得更遠。共勉之！
好文推薦：【持續更新】Unity 好用插件推薦，一起讓遊戲開發事半功倍！
參考文獻
【The GNU Operating System and the Free Software Movement】
官方網站：The GNU Operating System and the Free Software Movement
【自由軟體基金會】
【GNU 通用公眾授權條款】
【避坑指南—GPL 开源协议】
【是佛心還是惡霸條例，了解 GPL 開源(Open Source)許可證的風險與感染性】
Progress Bar：是佛心還是惡霸條例，了解 GPL 開源(Open Source)許可證的風險與感染性
【20110920-GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍】
Lu-six Person's Notes：20110920-GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍
【五種開源授權規範的比較(BSD, APACHE, GPL, LGPL, MIT)】
痞客邦 PIXNET：五種開源授權規範的比較(BSD, APACHE, GPL, LGPL, MIT)
【Open Source Initiative】
【如何选择开源许可证？一张图看懂开源许可协议】
互联网产品经理@唐杰：如何选择开源许可证？一张图看懂开源许可协议
【全球第一個 GPL 完整法院訴訟案例剖析】
智邦公益電子報：[法律源地] 全球第一個 GPL 完整法院訴訟案例剖析
【gpl-violations.org project prevails in court case on GPL violation by D-Link】
gpl-violations.org：gpl-violations.org project prevails in court case on GPL violation by D-Link
【因為 GPL 條款，特斯拉釋出自駕車相關程式碼】
LINE TODAY：因為 GPL 條款，特斯拉釋出自駕車相關程式碼
【国内首个违反 GPL 的案件介绍】
CSDN - 专业开发者社区：国内首个违反 GPL 的案件介绍
【开源协议软件代码传染性的认识与防治——以 GPL 协议为例】
康达律师事务所：开源协议软件代码传染性的认识与防治——以 GPL 协议为例
本文原創(或整理)於亞洲電玩通，未經作者與本站同意不得隨意引用、轉載、改編或截錄。
特約作家簡介
經中華網龍遊戲企劃進入遊戲圈，然後被雷打到去學程式前後端又學了點設計再帶帶幾個研發團隊，見證了 3D 渲染技術及遊戲引擎互相進步，也見證了研發代理的更迭與博弈遊戲的興起，再毅然研究起 SEO 網路行銷與社群廣告投放，深信自研自賣才是最大贏家，期望能為台灣研發重回輝煌時光貢獻一點力量。如果你也有遊戲夢，歡迎交流認識。
支持贊助 / DONATE
亞洲電玩通只是很小的力量，但仍希望為復甦台灣遊戲研發貢獻一點動能，如果您喜歡亞洲電玩通的文章，或是覺得它們對您有幫助，歡迎給予一些支持鼓勵，不論是按讚追蹤或是贊助，讓亞洲電玩通持續產出，感謝。
 |  |  |  |  |  |
BTC |
 |
352Bw8r46rfXv6jno8qt9Bc3xx6ptTcPze |
|
ETH |
 |
0x795442E321a953363a442C76d39f3fbf9b6bC666 |
|
TRON |
 |
TCNcVmin18LbnXfdWZsY5pzcFvYe1MoD6f |
