🎯 重點摘要：開源授權條款主要分兩大類——寬鬆型（Permissive）與強傳染型 / 著佐權（Copyleft）。寬鬆型（MIT、Apache-2.0、BSD）幾乎不設限，商用閉源也行；著佐權型（GPL、AGPL、SSPL）則要求「衍生作品也要同樣開源」，用來保護自由不被封閉剝奪。選對 License 就像選對朋友：寬鬆型讓你自由飛翔，強傳染型讓自由不被偷走。
為什麼要在意 License？
講個現實場景：你在 GitHub 找到一個超好用的函式庫，直接 npm install 或 pip install 裝進專案，沒看 License，幾個月後公司想把這套東西打包成商業產品賣出去……結果發現那個函式庫是 GPL 授權，代表你的整個產品源碼也得公開。這時候你只能重寫、重找，或硬著頭皮開源。
所以，選 License 不是形式，而是決定你、你的使用者、以及未來商業化的命運。 這篇文章幫你搞懂兩大陣營的本質差異，並提供實戰選擇建議。
兩大類授權條款的核心差異
先來一張對照表，把概念先釘在腦海裡：
| 特性 | 寬鬆型 Permissive | 強傳染型 Copyleft（著佐權） |
|---|---|---|
| 代表條款 | MIT、Apache-2.0、BSD-3、ISC | GPL v2/v3、AGPL v3、SSPL、MPL |
| 商用閉源 | ✅ 完全允許 | ❌ 衍生作品必須同樣開源 |
| 修改後是否要開源 | ❌ 不強制 | ✅ 必須同條款釋出 |
| 專利保護 | Apache-2.0 有明確條款 | GPL v3 有專利授權條款 |
| 傳染範圍 | 幾乎沒有 | 依條款而定（GPL 較寬、AGPL 更嚴） |
| 社群哲學 | 「你愛怎麼用都行，只要保留版權聲明」 | 「自由不能被偷走，衍生品也要自由」 |
| 常見場景 | 函式庫、工具、商業產品內嵌 | 作業系統核心、資料庫、雲端服務防剝奪 |
第一大類：寬鬆型（Permissive License）
寬鬆型授權的哲學很簡單：作者給你最大自由，你幾乎可以為所欲為，只要記得說一聲「這東西是誰寫的」。 它不要求衍生作品開源，也不禁止商業閉源，這讓它成為企業與商業軟體最愛的選擇。
MIT License — 最簡潔的寬鬆之王
MIT 只有兩段話，核心精神就是：你可以複製、修改、合併、發行、再授權、商業使用，只要保留原始版權聲明和免責聲明。沒有傳染性，沒有專利戰，沒有複雜條件。
💡 實戰心得：如果你寫了一個小工具、函式庫，想讓更多人用、甚至被大公司內嵌，MIT 是最安全的起點。像 React（早期）、jQuery、Node.js（早期）都是 MIT 授權，這讓它們快速滲透整個產業。
Apache License 2.0 — 企業最愛的進階版
Apache-2.0 比 MIT 多了幾個關鍵保護：
- 明確專利授權：貢獻者自動授予使用者專利使用權，防止「先貢獻後告專利」的陷阱。
- 商標保護：衍生作品不能隨便用原專案名稱做宣傳。
- 修改聲明：若修改了源碼，必須標註修改內容。
這讓 Apache-2.0 在 Google、Amazon、Microsoft 這類大企業特別受歡迎。像 Android（AOSP 部分）、Kubernetes、TensorFlow 都是 Apache-2.0 授權。
BSD 系列（BSD-2 / BSD-3）
BSD 是 MIT 的前輩，條件幾乎一樣，但 BSD-3 有一個額外限制：未經書面同意，不得用原作者或貢獻者名字為衍生產品背書。這在商業行銷上很實用，避免品牌被濫用。FreeBSD、OpenBSD、PostgreSQL 都是 BSD 系列。
寬鬆型的風險：自由的代價
寬鬆型最大的「缺點」其實也是它的特性：有人可以把你的開源代碼改一改，打包成閉源產品賣錢，而你完全無權要求他開源。 這在商業世界很常見，比如某些雲端服務商直接拿開源資料庫（如 MySQL、MongoDB 早期版本）做成 SaaS，不貢獻回去。這也是為什麼後來出現了更嚴格的著佐權條款。
第二大類：強傳染型 / 著佐權（Copyleft License）
著佐權的哲學剛好相反：如果你用了我的自由代碼，你做的東西也要自由。 它透過「傳染條款」確保開源的精神不被封閉剝奪。這不是惡意，而是一種防禦機制。
GPL — 自由軟體基金會（FSF）的旗艦
GPL（GNU General Public License）是最著名的著佐權條款，由 Richard Stallman 在 1989 年推出。它的核心規則：
- 如果你分發了基於 GPL 代碼的衍生作品（無論修改與否），整個衍生作品也必須以 GPL 授權釋出。
- 使用者有權取得完整源碼。
- 不能加上額外限制（例如「只能用在非商業用途」）。
GPL v2 和 v3 的差異主要在專利條款（v3 更明確）與「Tivoization」防護（v3 禁止用硬體鎖限制修改）。Linux 核心（GPL v2）、GCC、Bash、Emacs 都是 GPL 家族。
AGPL — 當雲端來襲的防禦升級
GPL 有一個漏洞：如果你把 GPL 代碼部署在伺服器上（例如做成 SaaS 服務），使用者只透過網路使用，而你從不「分發」二進制檔案，那麼你技術上不需要提供源碼。這讓許多雲端公司（如 AWS 早期對 MongoDB、ElasticSearch 的做法）可以「免費搭便車」。
AGPL（Affero GPL）修補了這個漏洞：只要透過網路與使用者互動，也視為分發，必須提供源碼。 MongoDB 後來從 AGPL 改為 SSPL，ElasticSearch 也改為雙授權（Elastic License + SSPL），都是為了防止雲端剝奪。
SSPL — MongoDB 的「雲端防剝奪」條款
SSPL（Server Side Public License）由 MongoDB 提出，條件比 AGPL 更嚴格：如果你把 SSPL 授權的軟體做成「服務」提供給第三方（例如 SaaS），你不僅要開源衍生代碼，連整個服務架構（包括管理介面、API 層、監控系統）都得開源。 這讓大型雲端服務商幾乎無法直接「包裝」而不開源，保護了原作者的商業利益。
MPL — Mozilla 的折衷方案
MPL（Mozilla Public License）是一種「文件級」著佐權：你可以把 MPL 代碼和閉源代碼混在同一個專案裡，只要修改的 MPL 文件本身 保持開源，其他新寫的閉源檔案可以不開源。這讓 Firefox、Thunderbird 這類大型專案既能保持開源，又能與商業模組共存。
實戰：我該選哪一種？
這沒有標準答案，但有幾個實用判斷框架：
選寬鬆型（MIT / Apache-2.0）的情境
- 你想最大化採用率，讓企業、學術、個人都能無痛使用。
- 你不在意別人閉源商用，甚至希望被廣泛內嵌（例如成為業界標準）。
- 你沒有足夠法律資源去追蹤衍生作品的授權狀態。
- 你的商業模式不是靠「賣軟體本身」，而是靠服務、支援、託管（例如 Red Hat 模式）。
選著佐權（GPL / AGPL / SSPL）的情境
- 你明確想保護自由不被剝奪，確保所有衍生作品也回饋社群。
- 你的商業模式是「開源核心 + 企業版功能」或「雙授權」（像 MySQL、Qt 那樣）。
- 你擔心雲端服務商直接打包你的產品做 SaaS，不貢獻回來。
- 你有法律與社群支持，可以執行授權條款（例如 FSF 或大型基金會）。
混合與雙授權策略
很多成熟專案採用「雙授權」或「混合授權」：
- MySQL：GPL（社群版）+ 商業授權（企業版），讓企業可以閉源使用。
- Qt：GPL / LGPL / 商業授權三選一，讓不同需求的使用者各取所需。
- Elastic / MongoDB：從寬鬆授權（Apache-2.0 / AGPL）改為更嚴格的 SSPL 或雙授權，防止雲端剝奪。
這告訴我們：授權不是一成不變的，你可以根據專案階段、商業需求與社群反應調整。 但要注意，一旦公開釋出，已經下載的版本就無法「收回」授權，只能對未來版本調整。
常見誤解與陷阱
誤解一：「GPL 會讓我的專案不能商用」
錯。GPL 完全允許商業使用，只要求衍生作品同樣開源。如果你的商業模式是賣服務、賣支援、賣託管，而不是賣「閉源軟體本身」，GPL 完全沒問題。Red Hat 就是最好的例子：他們用 GPL 的 Linux 做成商業產品（RHEL），靠訂閱與支援賺錢。
誤解二：「MIT 就代表沒有任何限制」
不完全對。MIT 仍要求你保留原始版權聲明與免責聲明。如果你直接刪除版權聲明再發行，技術上已違反 MIT。雖然實務上很少有人追究，但在企業併購或盡職調查（Due Diligence）時，這會成為法律風險點。
誤解三：「只要我不修改，就不用開源」
對 GPL 來說，如果你只是「使用」而不「分發」二進制檔案（例如內部使用、伺服器部署），那確實不觸發開源義務。但只要你把包含 GPL 代碼的產品交給客戶（無論免費或收費），就必須提供源碼。AGPL 則更嚴格：連網路服務也算分發。
陷阱：多重授權混合（License Compatibility）
如果你把 MIT 代碼和 GPL 代碼混在一起，整個專案通常會被 GPL 的傳染性「拉過去」，變成必須以 GPL 釋出。反過來，如果你把 GPL 代碼放進 MIT 專案，也會讓 MIT 專案變成 GPL。這在大型專案特別容易出錯，建議用工具（如 fossology、scancode）掃描依賴樹的授權狀況。
選擇建議：給不同角色的實戰指南
給個人開發者 / 小團隊
如果你只是想分享代碼、建立個人品牌，MIT 是最簡單、最受歡迎的起點。如果你明確不希望商業公司閉源剝奪你的勞動成果，選 GPL v3。如果你做的是資料庫或雲端服務，考慮 AGPL 或 SSPL。
給企業 / 商業產品團隊
在選擇第三方函式庫時，法律與合規團隊通常會要求避開 GPL（尤其是內嵌在商業產品中），優先選 MIT、Apache-2.0、BSD。如果必須使用 GPL 組件，通常會採用「動態連結」或「獨立進程」的方式隔離，避免傳染。但這在技術與法律上都有灰色地帶，建議諮詢專業法律意見。
給基金會 / 大型開源專案
如果你的目標是成為業界標準（如 Linux、Kubernetes），寬鬆授權（Apache-2.0）更容易吸引企業貢獻。如果你明確想保護自由（如 GNU 專案），GPL 是核心信仰。如果你同時想吸引商業貢獻又想保護自由，考慮 MPL 或雙授權策略。
快速參考：常見條款一覽
| 條款 | 類型 | 傳染性 | 商用閉源 | 專利條款 | 代表專案 |
|---|---|---|---|---|---|
| MIT | 寬鬆 | 無 | ✅ | 無明確 | React、jQuery、Express |
| Apache-2.0 | 寬鬆 | 無 | ✅ | ✅ 明確授權 | Kubernetes、TensorFlow、Android (AOSP) |
| BSD-3 | 寬鬆 | 無 | ✅ | 無明確 | FreeBSD、PostgreSQL |
| GPL v2 | 著佐權 | 強（檔案級） | ❌ 衍生必須 GPL | 無（v3 有） | Linux 核心、GCC |
| GPL v3 | 著佐權 | 強（檔案級） | ❌ 衍生必須 GPL | ✅ 明確授權 | Bash、GIMP |
| AGPL v3 | 著佐權 | 強（含網路服務） | ❌ 衍生必須 AGPL | ✅ 明確授權 | MongoDB（舊版）、iText |
| SSPL | 著佐權 | 極強（含服務架構） | ❌ 衍生必須 SSPL | 無 | MongoDB（新版）、ElasticSearch |
| MPL 2.0 | 混合 | 文件級 | ✅（非 MPL 檔案可閉源） | ✅ 明確授權 | Firefox、Thunderbird |
小結：選對條款，讓自由與商業共存
開源授權條款不是非黑即白的道德判斷，而是一種設計工具。寬鬆型讓你的代碼像空氣一樣流動，進入每個角落；著佐權型則像護城河，確保自由的成果不被封閉剝奪。
我的建議是：先想清楚你想保護什麼，再選條款。 如果你想最大化影響力與商業採用，MIT 或 Apache-2.0 是穩健選擇。如果你想確保所有衍生作品也回饋社群，GPL v3 是經典。如果你做的是雲端服務，AGPL 或 SSPL 才是現實的防禦。
無論選哪一個，記得把 License 檔案（通常是 LICENSE 或 COPYING）放在專案根目錄，並在每個源碼檔案頂部加上簡短的版權聲明。這不只是法律要求，也是對未來自己與使用者的一份尊重。
✅ 快速行動清單：寫新專案前，先問自己三個問題——
① 我希望別人怎麼用我的代碼？（自由使用 / 必須開源）
② 我的商業模式是什麼？（賣軟體 / 賣服務 / 純分享）
③ 我有沒有法律資源去執行授權條款？（個人 / 企業 / 基金會）
答案出來，License 自然就選對了。