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

GPL、MIT 與 Apache：各授權條款要求您做什麼

GPL、MIT 與 Apache 2.0 以不同方式回答同一個問題：當您再散布軟體時，對其他人負有哪些義務？MIT 只要求保留著作權聲明，沒有其他要求。Apache 2.0 除了要求保留該聲明，也要求所有接觸程式碼的人遵守專利授權安排。GPL 則要求您以取得軟體時相同的授權條款，公開您在其上建置之內容的原始碼。

在某個專案變更授權條款並分裂成兩個版本之前，這看起來像是律師才需要處理的問題。到了那一天，它就成了維運問題。您必須在兩個套件儲存庫之間做選擇，還可能遇到彼此停止通訊的用戶端函式庫。本指南討論的是授權條款及其運作方式，而不是促成這些授權條款的運動。因此，每個段落最後都會回到與您直接相關的情境：您必須負責執行升級。

GPL 為何存在：沒有人獲准修理的印表機

約在 1980 年，MIT Artificial Intelligence Lab 收到一台 Xerox 9700 雷射印表機。實驗室曾修改較早型號印表機的軟體，讓它在列印工作卡住時通知使用者。但新印表機沒有提供原始碼，而實驗室索取原始碼的要求也因 nondisclosure agreement 遭到拒絕。當時在實驗室任職的程式設計師 Richard Stallman，將這次拒絕視為普遍問題，而不是單純的一次不愉快經驗，並於 27 September 1983 宣布 GNU project。

Copyleft 建立在著作權法之上，而不是對抗著作權法。根據預設，你完全沒有權利複製他人的程式碼。GPL 授予你這項權利，但附帶一項條件：如果你將程式提供給他人，就必須依相同條款提供原始碼，讓對方能做實驗室當時無法做的事。這項條件之所以能執行，是因為如果沒有該授權，你原本就沒有取得使用許可。

Stallman 先為 GNU Emacs 撰寫授權條款，接著將其一般化，於 25 February 1989 發布 GPL version 1。GPL version 2 隨後於 June 1991 發布，至今仍是你所使用的大多數系統軟體採用的授權。Lesser GPL 是為函式庫推出的，因此採用 copyleft 的函式庫可以由任何授權條款下的程式連結使用，而不會使該程式也必須採用 GPL。

有一項細節決定 GPL 對自架服務使用者的影響。義務會在散布時觸發，而不是在使用時觸發。你可以修改 GPL 程式，在自己的伺服器上執行，並以此向公眾提供服務，而且不必向任何人提供任何內容，因為你從未交付程式副本。AGPL 的存在正是為了處理這項落差。

寬鬆授權的傳統：BSD，接著是 MIT

Berkeley 採取了不同的做法。Computer Systems Research Group 以一份要求保留著作權聲明並排除所有保固責任的授權條款發布其 Unix 相關成果。原始版本共有 4 項條款，其中第 4 項是廣告條款，要求所有提及軟體功能的廣告資料都必須致謝該大學。這種做法無法擴展。Stallman 統計出，NetBSD 在 1997 年的版本中有 75 項獨立的致謝要求。UC Berkeley 於 1999 年 7 月 22 日，透過其 Office of Technology Licensing 的 William Hoskins 所發出的信函，撤銷了這項條款。

保留下來的是 3-clause BSD licence。它新增禁止使用貢獻者姓名為產品背書的規定；2-clause 版本則連這項規定也移除了。MIT licence 的文字源自 1980 年代的 MIT，當時用於 X Window System；實務上，它與 2-clause BSD 發揮相同作用。

兩者的動機不同。一所由公帑資助的大學希望其成果能廣泛使用，包括讓公司採用。GNU project 則希望建立一個無法被封閉的公有資源。這兩種立場都是真誠的，也都有失效模式。寬鬆授權的程式碼可能被私有化，而你不會得到任何回饋。Copyleft 程式碼則可能遭到律師不接受這項條件的公司拒用。

Berkeley 還帶來第二項教訓，也是本文不斷回到的主題。AT&T 的 Unix System Laboratories 於 1992 年因 BSD 程式碼起訴 Berkeley Software Design，案件在 1994 年初和解。長達 2 年的時間裡，沒有人能確定 BSD 適合安全地以此為基礎進行建置；在 Linux 持續成長的同時，採用進度也停滯不前。法律不確定性讓採用停滯的速度，比缺少某項功能更快。

Apache 2.0 為何加入專利授權

Apache Group 的第一份授權條款，是衍生自 BSD 4-clause、同樣存在廣告條款問題的版本。2000 年的 Version 1.1 移除了該條款。2004 年 1 月發布的 Version 2.0 則是重新撰寫，而不是在原版本上修補。

重要的新增內容是專利。MIT 與 BSD 完全沒有提及專利。貢獻者可以明確授予你使用其程式碼的著作權許可，但仍持有涵蓋該程式碼所執行功能的專利，之後可能起訴使用者。Apache 2.0 彌補了這項缺口：每位貢獻者都會授予涵蓋其貢獻內容的專利授權；任何人若主張該作品侵害其專利而提起訴訟，也會失去自己對該作品的專利授權。這項威脅是相互的，因此實務上沒有人會提起這類訴訟。

2.0 的其餘內容屬於管理規範，這也是企業偏好它的原因。授權條款定義了 NOTICE 檔案，讓著作權標示集中在同一處，不必散落於整個原始碼樹。授權條款可以透過引用套用，不必貼入每個原始碼檔案。貢獻內容也受到明確條款規範。商標則不在授權範圍內。法律人員審查 Apache 2.0 相依套件時，通常能在條文中找到所有需要確認的答案，因此核准流程可以例行化；這大致就是「企業預設選項」的含義。

GPLv3 的變更，以及 Linux 為何仍採用 GPLv2

TiVo 出貨了一款執行 Linux 的錄影機，並依 GPLv2 的要求發布 kernel source。硬體接著在開機時驗證 cryptographic signature，拒絕執行未獲其識別的 kernel。你可以閱讀 source、修改 source，再進行編譯，但無法在它原本所屬的裝置上執行。這符合 licence 的字面要求，卻違背了 licence 的目的，這種做法後來被稱為 tivoisation。

GPL version 3 於 29 June 2007 發布，直接回應了這個問題。當你在消費性裝置中傳遞 binary 時，也必須提供「Installation Information」：也就是安裝修改版本並讓它執行所需的 keys 或 instructions。Version 3 也加入明確的 patent grant、因應 Microsoft 與 Novell 於 November 2006 簽訂的 patent agreement 而制定的條款，以及與 Apache 2.0 的單向相容性。

Linux 沒有跟進。kernel 僅採用 GPL version 2，沒有「or any later version」的選項條款，其 COPYING file 也明確如此載明。Linus Torvalds 曾公開反對針對簽署硬體的 anti-tivoisation 條款。實際上的障礙比理念分歧更大：kernel 擁有數千名 copyright holders，因此即使所有人都願意，也無法蒐集 relicence 所需的許可。這個單一事實是 project 能擁有的最強保障；當你查看由單一公司擁有的 project 時，值得記住這一點。

另一個 2007 licence 對你的影響更大。GNU Affero GPL version 3 於同年 November 發布，將 source obligation 延伸至透過 network 與程式互動的人員。若你為公眾執行修改過的 AGPL service，就必須向這些 users 提供 source。這就是許多 self-hosted web software 採用 AGPL 的原因。Nextcloud 是其中一個例子；如果你正在比較 Nextcloud 的 self-hosted 替代方案，每個候選 project 的 repository 中所載的 licence，比 feature list 更能告訴你它未來五年的發展。

實際上可以組合哪些授權條款？

相容性是單向的，從寬鬆授權條款指向 copyleft 授權條款。

• MIT 和 BSD 程式碼可以納入任何專案，包括封閉產品。
• Apache 2.0 程式碼可以納入 GPLv3 專案，組合後的作品採用 GPLv3。
• Apache 2.0 程式碼不能納入僅允許 GPLv2 的專案。Apache 2.0 的專利終止與賠償條款屬於額外條件，而 GPLv2 不允許加入這些條件。FSF 與 ASF 都公布了這項結論。
• 你不能自行將 GPL 程式碼改用寬鬆授權條款。只有著作權持有人可以這麼做，因此問題仍回到：著作權持有人是誰。

再授權時代：SSPL、BUSL，以及它們不是什麼

觸發原因在於商業利益。某家公司擁有產品的著作權，雲端服務供應商大規模將該產品作為託管服務銷售，卻幾乎沒有回饋，於是該公司修改授權條款以阻止這種作法。Redis Labs 在 2018 年 8 月率先採取明顯行動，為旗下數個模組加上 Commons Clause，並沿用 Apache 2.0。MongoDB 接著在 2018 年 10 月 16 日，將授權從 AGPLv3 改為 Server Side Public License。

SSPL 是只重寫其中一節的 AGPL。若你以服務形式向第三方提供該程式，就必須公開所有用來提供該服務的軟體原始碼，包括周邊的管理與編排軟體。這項義務的適用範圍沒有明確界線，也沒有法院進行過審理。OSI 從未核准此授權，而 MongoDB 在 2019 年 3 月撤回申請。Debian 早在 2018 年 12 月便表示，採用 SSPL 的軟體不應納入其套件庫；Fedora 也在 2019 年 1 月裁定該授權不屬於自由授權，之後 Red Hat 將 MongoDB 從 Fedora 及 Red Hat Enterprise Linux 移除。再授權的直接結果就是發行版停止打包該軟體，因此後續更新會改由供應商套件庫依供應商的時程提供。

Business Source License 是另一種做法。它源自 MariaDB 的創辦人，1.1 版發布於 2017 年。它不是 copyleft，也不是開放原始碼授權。原始碼公開，除供應商明確排除的用途外皆可免費使用；通常被排除的是執行競爭性的託管服務。每個版本會在變更日自動轉換為真正的開放原始碼授權，而變更日距離該版本發布不得超過四年。轉換後的授權必須與 GPLv2 相容。HashiCorp 在 2023 年 8 月 10 日將 Terraform 及其他產品改用 BUSL 1.1。Outline 也採用此授權；如果你正在從 自架 Notion 替代方案中挑選產品，這點值得注意：為自己的團隊執行是允許的，但以它建立服務則不允許。

這兩種授權都沒有不誠實之處。兩者都明確表示自己是 source available。依 OSI 的定義，兩者都不是開放原始碼授權，而這項差異最終由你承擔，而不是由它們原本針對的雲端服務供應商承擔。

OpenSearch：授權分叉讓營運方付出什麼代價

Elastic 於 2021 年 1 月 14 日宣布，Elasticsearch 和 Kibana 將從 Apache 2.0 改用 SSPL 或 Elastic License，自 release 7.11 起生效。Version 7.10.2 是最後一個採用 Apache 2.0 的版本。約一週後，AWS 表示將建立並維護兩者的 Apache 2.0 分叉版本。該分叉於 2021 年 4 月 12 日命名為 OpenSearch，Kibana 則改名為 OpenSearch Dashboards。OpenSearch 1.0 於 2021 年 7 月 12 日正式發布，基於 Elasticsearch 7.10.2 與 Kibana 7.10.2 建置。

看看這讓叢集營運人員付出了什麼代價。套件名稱和套件儲存庫都改變了。操作手冊中每個提到 Kibana 的地方，都必須改成 OpenSearch Dashboards。Plugin 名稱也變更了。接著分裂影響到應用程式程式碼：從 Elastic 官方 client libraries 的 version 7.13 起，client 會檢查連線對象，若對方不是 Elasticsearch，就拒絕繼續執行，並回報 server 是 unknown product。你不任職的公司所做的授權決策，最後變成自己應用程式內一次失敗的呼叫。

之後局勢又改變了兩次。Elastic 於 2024 年 8 月 29 日加入 AGPLv3，作為第三種授權選項，因此目前的 Elasticsearch 再次成為 OSI 核准的 open source 軟體。2024 年 9 月 16 日，AWS 將 OpenSearch 移交給由 Linux Foundation 主持的 OpenSearch Software Foundation，讓這個分叉擁有不隸屬單一公司的治理組織。分裂 5 年後，兩個專案都是 open source、都有人維護，而截至 2026 年 8 月，OpenSearch 已進入 3.x 系列。

結論就是這個教訓。授權改回來了，分叉卻保留下來。一旦生態系中每樣東西都有兩套，撤銷原本的文件作業並不會讓它們重新合併。

決定重新授權會造成多大傷害的數字，是從公告到出現可實際部署的穩定分叉之間的時間差。

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

每個時間差都從供應商公開公告日計算到分叉首次穩定發布日，日期如下所列。OpenSearch 1.0 花了 179 天，因為分叉必須重新命名和建置，且沒有更早的分叉可供參考。OpenTofu 花了 153 天。Valkey 花了 27 天，因為它是從 Redis 7.2.4 分叉而來，並維持 protocol 和 on-disk format 不變。重點在於趨勢：現在可信的分叉可在數週內推出，且從第一天起就有 foundation 和受聘維護人員參與。

Valkey 與 OpenTofu：相同模式，更快完成

Redis Ltd 在 2024 年 3 月 20 日將 Redis 的授權從 3-clause BSD 改為 RSALv2 或 SSPLv1 二選一。8 天後，Linux Foundation 宣布 Valkey；該專案從 Redis 7.2.4 分支，並繼續採用 BSD 3-clause。Valkey 7.2.5 於 2024 年 4 月 16 日發布，使用相同的通訊協定與資料檔案，因此對多數營運者而言，遷移只涉及套件名稱。之後 Redis 在 2025 年 5 月於 Redis 8 加入 AGPLv3 作為第三種選項，依 OSI 定義再次成為開放原始碼軟體；Valkey 則繼續由自身的治理架構管理。這種發展模式與 Elasticsearch 十分接近。

Terraform 走過相同的路線，只多了一章。OpenTofu 從最後一個採用 Mozilla Public License 2.0 的版本分支，於 2023 年 9 月加入 Linux Foundation，並在 2024 年 1 月 10 日發布 1.6.0。2024 年 4 月 3 日，HashiCorp 的律師向該專案寄發停止侵害及撤回通知，聲稱該分支將 BUSL 授權 Terraform 版本中的程式碼複製進去。OpenTofu 於 2024 年 4 月 11 日發布詳細回應予以否認，並指出爭議程式碼源自兩個專案共同採用的 MPL 授權歷史。此後未再有公開進展。這起事件真正值得記住的風險是：單憑一項指控，就可能讓採用決策停滯一季；這與 30 年前 Berkeley 訴訟造成的效果相同。

並非每個分支都始於授權問題。Forgejo 在 2022 年從 Gitea 分支，原因是 Gitea 的開發轉由一家公司管理；這是治理爭議，而非授權爭議。Forgejo 在版本 8 系列持續採用 MIT，之後從 2024 年的版本 9.0 起改採 GPLv3 或更新版本，避免其成果被重新納入商業控制的產品。如果你正在評估自架 Git 伺服器選項，這一對是目前最清楚的實例：同一份程式碼，兩種理念。

採用前應執行的測試

在第一次安裝前先回答以下4個問題，不要等到安裝後才確認。

1. 誰持有著作權？重新授權需要取得每位著作權人的許可，因此由數百名獨立貢獻者共同開發、且未辦理權利讓與的專案，實際上無法重新授權。若所有權利都由單一公司持有，則可在董事會議中重新授權。
2. 是否有 CLA？CLA 授予哪些權利？若貢獻者授權協議允許公司依其選擇的任何條款，重新授權你的貢獻，這就是上述每次重新授權所採用的確切機制。DCO（developer certificate of origin）是 Linux kernel 在 2004 年採用的 sign-off 行，完全不會移轉任何權利。由 foundation 持有的 CLA 比由公司持有的更安全，因為公司可能被出售。
3. 誰持有商標？Elastic 保留了 Elasticsearch 這個名稱，因此 fork 必須重新命名，所有提到 Kibana 的 runbook 也都必須重寫。
4. 重新授權對你而言會造成哪些成本？盤點資料格式、client libraries、需要重寫的設定，以及是否已經存在相容的 fork。

以下2個命令可在幾秒內回答其中一部分問題。

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

每個 Debian 和 Ubuntu 套件都會在 /usr/share/doc/<package>/copyright 提供一個檔案。該檔案記錄的是你所安裝版本的授權，而不是專案目前使用的授權。在 Ubuntu 24.04 中，bash 的該檔案會列出 GNU General Public License version 3。請在 source checkout 中執行第二個命令，以取得該授權檔案本身的歷史記錄。若該檔案在最近2年內有 commit，請先閱讀相關內容，再以此專案為基礎建置任何項目。若命令沒有輸出，表示 repository 使用了其他檔名作為授權檔案；請列出根目錄內容並尋找。

沒有任何授權能讓你免於所有結果，而只憑意識形態選擇，往往會在之後措手不及。優先選擇著作權分散於多位持有人，或由 foundation 持有的專案，並將資料保留在可匯出的格式中。接著確認你會移轉到哪個 fork，並在真正需要前先記下名稱。對每個候選專案執行這項檢查，所需時間不到1小時；在決定 2026 年要自架哪些服務 時，這正是升級與移轉的差別。

FAQ

MIT 授權條款與 BSD 授權條款相同嗎？

實際上，MIT 與 2-clause BSD 授權條款相同：保留著作權聲明與免責聲明，之後即可自由使用，包括建立封閉式產品。3-clause BSD 授權條款多出一項限制：未經許可，不得使用貢獻者的姓名為產品背書。較早的 4-clause 版本還要求在廣告材料中列出致謝內容；UC Berkeley 已於 1999 年 7 月 22 日撤除該條款，因此目前幾乎沒有仍採用它的授權條款。

我可以將 Apache 2.0 程式碼放入 GPLv2 專案嗎？

不可以。Apache 2.0 加入了 GPLv2 不允許附加的條件，主要是專利終止條款，因此合併後的作品無法同時符合兩種授權條款。FSF 與 ASF 都公布了這項結論。反向則可行：Apache 2.0 程式碼可以納入 GPLv3 專案，結果採用 GPLv3。這也是 Apache 2.0 程式碼不能合併至 Linux kernel 的原因，因為 Linux kernel 僅採用 GPL version 2。

SSPL 是開放原始碼授權條款嗎？

不是，而且這項結論會產生實際影響。OSI 從未核准 SSPL，MongoDB 也在 2019 年 3 月撤回申請。Debian 於 2018 年 12 月表示，SSPL 軟體不應納入其套件庫；Fedora 於 2019 年 1 月裁定該授權條款並非自由授權條款，之後 Red Hat 將 MongoDB 從 Fedora 與 Red Hat Enterprise Linux 移除。對你而言，這表示原本由發行版維護的套件，現在改由供應商 repository 提供，並依照供應商的支援時程更新。Business Source License 同樣是可取得原始碼，而不是開放原始碼；不過每個版本都會在 4 年內轉換為開放原始碼授權條款。

授權條款變更會套用到我目前執行的版本嗎？

不會。隨版本發布而授予的授權，不能從已發布的副本撤回，這正是 fork 能夠存在的原因。OpenSearch 是以 Elasticsearch 7.10.2 為基礎建立，而該版本是 Elastic 以 Apache 2.0 發布的最後一個版本。你失去的是未來，因為下一個安全修補程式會依照新條款發布。固定使用最後一個採寬鬆授權的版本，可以爭取幾個月，但不能視為長期方案。