通用公共授權條款

什麼是 GNU 通用公共授權條款（GPL）？

GNU 通用公共授權條款（簡稱「GPL」）是全球廣泛採用的開源軟體授權條款之一。此授權規定，只要程式碼被使用、修改或散布，原始碼必須保持公開，並以相同的授權條款進行分享。GPL 是開源領域最具影響力的授權之一。

開源授權條款規範作者允許他人使用與修改程式碼的條件——就像分享食譜並允許他人改良。GPL 強調，任何改良後的「食譜」也必須公開，並遵循相同規則。這種互惠機制確保社群能持續受益於不斷的優化成果。

GPL 的核心原則是什麼？

GPL 的核心精神是「copyleft」（互惠版權）：當你使用或修改他人開放原始碼時，任何散布行為都必須維持開放，並完整保留原有的版權聲明與授權內容。

主要原則如下：

• 原始碼公開：散布可執行檔時，必須同時提供對應的原始碼。
• 授權延續：衍生作品必須繼續採用 GPL。
• 保留聲明：必須完整保留原始版權與授權聲明。
• 無擔保：軟體以「現狀」提供，作者不承擔任何保證。
• 專利條款（v3）：GPL 第 3 版增設專利保護條款。

Linux 核心長期採用 GPL-2.0（截至 2025 年），是 GPL 實務應用的經典案例之一。

GPL 對 Web3 開發有何影響？

GPL 會影響你是否能以閉源方式散布含開源程式碼的軟體，或在散布專案時是否必須公開原始碼。在 Web3 領域，節點客戶端、錢包、前端與智慧合約等皆可能受到 GPL 條款約束。

舉例來說，若你的 dApp 前端整合了 GPL 授權元件並向用戶散布可執行版本，則可能需要公開前端原始碼並保留所有原始聲明。這有助於促進協作透明度，但也可能限制閉源商業模式的彈性。

鏈上開源實踐能提升可稽核性與安全性。許多團隊選擇公開關鍵程式碼以建立信任，同時審慎評估授權條款與產品策略是否相容。

GPL 如何適用於智慧合約？

智慧合約通常以 Solidity 撰寫，並於檔案頂端以 SPDX-License-Identifier（如「SPDX-License-Identifier: GPL-3.0-or-later」）標註授權。GPL 對智慧合約的互惠授權要求主要包括：

第一，散布：編譯並部署合約至鏈上通常被視為公開散布。若合約包含或修改了 GPL 程式碼，公開部署時可能需開源你的修改。是否構成散布，應於設計階段依實際情境評估。

第二，連結與衍生：合約繼承或呼叫函式庫通常被認定為創建衍生作品。若你的合約繼承自 GPL 授權合約，散布時需遵守相同授權條款。

第三，常見做法：許多團隊會為核心合約選擇較寬鬆的 MIT 或 Apache 授權，以降低後續義務。若採用 GPL，應於程式庫中完整提供原始碼、版權聲明及建構說明，以利稽核與重用。

GPL 與 MIT、Apache 授權有何不同？

GPL、MIT 與 Apache 授權的主要差異在於互惠要求的強度。

• MIT：如同署名分享食譜——極為寬鬆，不要求衍生作品採用相同授權，適合閉源產品或雙重授權模式。
• Apache-2.0：類似 MIT，但增設專利授權與免責聲明，更符合企業需求。
• GPL：強制互惠授權，適合希望社群持續共享改進的專案；對閉源散布有較多限制。

總結：若需最大化開放協作並強制共享改進，建議選擇 GPL；若需開放與閉源商業化彈性，則以 MIT 或 Apache 為宜。

如何在專案中合規使用 GPL？

步驟 1：於程式庫根目錄放置 LICENSE 檔案（完整 GPL 內容），並於 README 中說明授權細節。

步驟 2：於每個原始檔頂端加入 SPDX-License-Identifier 標頭（如「SPDX-License-Identifier: GPL-3.0-or-later」），方便工具鏈辨識授權。

步驟 3：保留原作者的版權與授權聲明；針對自己的修改需註明日期、作者及簡要說明。

步驟 4：為散布的可執行檔提供原始碼取得方式——如發布原始碼、建構腳本與依賴文件，確保可重現性。

步驟 5：審查第三方依賴的授權相容性；如有需要，可採用更適合的 LGPL 函式庫。

步驟 6：上線前進行合規審查；涉及商業用途時應諮詢法律專業，降低風險。

GPL 各版本有何差異？

主要版本為 v2 與 v3：

• v2（如 Linux 核心）：最早且應用最廣的版本，未涵蓋現代專利或裝置鎖定議題。
• v3：強化專利授權，增設反 Tivoization（防止硬體阻止修改版）及 DRM 相關條款，更適應現代散布場景。

「Or later」與「Only」：選擇「GPL-3.0-or-later」可採用未來版本，彈性較高；「only」則限定於特定版本，有助於相容性管理。

此外，LGPL 適用於函式庫（允許較寬鬆的連結），AGPL 則將開源義務擴展至網路服務——Web3 後端服務與前端互動需特別留意 AGPL 的適用情境。

GPL 是否可用於商業用途？

可以——GPL 允許商業用途。但散布含有 GPL 程式碼的衍生作品時，必須開源程式碼並保留所有聲明。企業常見策略如下：

• 雙重授權：核心程式碼以 GPL 開源，同時為企業客戶提供商業授權版本。
• 服務模式：透過託管、支援、稽核或整合服務創造收益，同時確保程式碼合規（需注意 AGPL 對網路使用的特殊規定）。
• 元件隔離：將必須開放的部分與專有業務邏輯隔離；函式庫可採用 LGPL 或專有替代方案，降低互惠義務風險。

GPL 常見風險與誤解有哪些？

常見誤解如下：

• 「GPL 不能用於商業」——錯誤。GPL 允許商業用途，但散布衍生作品時需履行開源義務。
• 「未散布就無須合規」——並非如此。是否構成散布取決於情境，鏈上部署或網路服務可能屬於公開發布。
• 「GPL 可與 MIT/Apache 混用」——需特別注意。衍生關係可能要求全專案採用 GPL，以避免混用不相容授權。
• 「少量使用可規避義務」——無論是繼承、靜態或動態連結，整合方式仍可能構成衍生作品，必須進行合規審查。

風險包括侵權與合規爭議，可能影響募資、上線或合作。涉及資金或合約安全的專案應及早完成授權設計與原始碼稽核。

GPL 選擇建議與總結

若你的目標是促進社群協作、確保改進回饋社群並維持可稽核性，GPL 是穩健選擇。若需更高的閉源或雙重授權彈性，MIT 或 Apache 更為適合。智慧合約與前端應確保授權一致且可追蹤——於程式庫中納入 LICENSE 檔案與 SPDX 標頭，規範原始碼散布路徑。請留意版本差異、依賴相容性，以及你的情境是否構成散布或衍生。商業化前務必進行合規審查並尋求法律建議。明確的授權策略有助於在 Web3 生態實現可靠協作與合規。

FAQ

商業專案能否直接使用 GPL 授權程式碼？

可以——但你必須同步開源你的衍生程式碼。GPL 的「傳染性」機制意味著，若你基於 GPL 程式碼開發並銷售產品，必須依相同授權條款公開原始碼。這項要求與閉源商業模式不相容。若需保持程式碼私有，建議選用 Apache 或 MIT 授權的函式庫。

Web3 專案引用 GPL 智慧合約存在哪些法律風險？

主要風險是原作者可能因著作權侵權提起法律訴訟。雖然智慧合約相關法律仍在發展中，但許多司法轄區已認定 GPL 義務具備法律效力，違規可能導致賠償。此外，尋求募資或併購時，投資方也可能因 GPL 風險而猶豫。建議及早諮詢法律顧問，或選擇授權較寬鬆的方案以降低風險。

為何有人說 GPL「污染」專案？

這是針對 GPL「傳染性」特性的形象說法。一旦專案中包含 GPL 程式碼，即使只是間接引用，整個專案在某些情境下都需遵守 GPL 條款。對於希望程式碼保持專有的開發者而言，這種「強制開放」被視為專案被「污染」。這不是缺陷，而是 GPL 的設計初衷——保障自由軟體原則。

僅呼叫 GPL 函式庫的 API 是否需要開源專案？

這取決於你與函式庫的互動方式及適用的 GPL 版本。若僅以動態方式呼叫 API（如外部服務呼叫），通常無須開源專案。但若進行靜態連結或修改並使用 GPL 程式碼，則需依 GPL 條款公開原始碼。建議諮詢開源律師，釐清「衍生作品」的定義，以避免法律風險。

專案同時使用 GPL 與 MIT 授權程式碼會有什麼影響？

你必須同時遵守兩種授權，這會增加合規複雜度。GPL 要求所有衍生作品開源，MIT 則允許閉源使用，兩者條款存在衝突。實務上，專案需遵守較嚴格的 GPL 以確保相容性。建議避免混用授權，或依模組類型明確隔離授權，降低合規風險。