開放原始碼軟體歷史：從 GPL 到 SSPL

開放原始碼軟體的定義與起源

開放原始碼軟體的歷史，大多也是其授權條款的歷史，因為只有授權條款能決定你可以如何使用他人撰寫的程式碼。在有人將這些授權條款正式寫下來以前，程式碼早已公開分享。程式碼成為產品後，就不再公開分享；而授權條款的制定，是為了讓分享行為在法庭上也能站得住腳。

這是簡短版本。完整背景之所以重要，是因為你今天在伺服器上執行的軟體，仍然帶有那些決策留下的痕跡。其中一些決策是在 1983 年做出的。另一些則是在去年做出的，而這正是我們的自架服務指南中，有些應用程式現在會以兩個不同名稱、兩種版本提供的原因。

軟體在銷售前是以共享方式流通的

在 1950 年代和 1960 年代，軟體會隨機器一同提供。IBM 會隨系統提供原始碼，SHARE 等使用者群組則在 1955 年成立後，透過磁帶互相分享程式。兩項變化終結了這種模式。IBM 在 1969 年宣布將軟體與硬體分開定價，因而建立了獨立的軟體市場。接著，法律也跟上了。1980 年的 Computer Software Copyright Act 確認，程式在美國屬於受著作權保護的作品。1980 年之後，除非是你自行撰寫的程式碼，否則預設為封閉；分享這類程式碼需要取得作者的書面許可。

Homebrew Computer Club 與〈給嗜好者的公開信〉

Homebrew Computer Club 於 1975 年 3 月在加州 Menlo Park 的一間車庫舉行首次聚會。成員帶來硬體與紙帶，複製軟體也是聚會的一部分。Bill Gates 與 Paul Allen 撰寫的 Altair BASIC，透過複製的紙帶在與會者之間傳閱。1976 年 2 月，Gates 在俱樂部的電子報中回應，發表〈給嗜好者的公開信〉。

各位嗜好者應該都知道，你們大多數人正在竊取軟體。

他寫道，付費購買 BASIC 的 Altair 擁有者不到十分之一，而撰寫該軟體所使用的電腦時間，價值超過 40,000 美元。現代的整場爭論，早已出現在那封信中。複製軟體不需成本，且能讓所有進行複製的人受益。但撰寫軟體仍耗費了某個人一年的生命。下文介紹的每種授權，都是試圖同時回應這兩項事實。

1983 年的 GNU，以及作為法律創新的 GPL

Richard Stallman 在 1983 年 9 月透過 Usenet 宣布 GNU。Usenet 是網頁出現之前人們使用的新聞群組網路。GNU 代表「GNU's Not Unix」。這項計畫的目標，是建立一套任何人都能複製和修改的完整 Unix 相容系統。

Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it.

Free Software Foundation (FSF) 隨後於 1985 年成立。其 Free Software Definition 列出 4 項自由，編號從 0 開始：可基於任何目的執行程式、研究並修改程式、重新散布副本，以及散布修改後的版本。Freedom 1 要求提供原始碼，因為實際上沒有人能以可行的方式研究二進位檔。「Free」在此指的是自由，而不是價格。FSF 使用的原文說法是 free as in free speech，而不是 free beer。

真正的創新不是宣言，而是授權條款。GNU General Public License (GPL) 運用著作權來要求分享，而不是阻止分享。你取得這 4 項自由的條件是：任何你轉交軟體的人，也必須連同原始碼取得相同自由。Stallman 將此稱為 copyleft。它最初於 1985 年隨 GNU Emacs 發布，並在 1989 年成為 GPL version 1，之後於 1991 年 6 月發布 version 2。

GPL 能運作，是因為它以著作權法為基礎，而不是對抗著作權法。若沒有授權條款，你根本無權散布他人的程式碼。GPL 授予這項權利，並附加相關條件。因此，某個廠商若將修改後的 GPL 程式碼放入路由器中發布，卻拒絕提供原始碼，並不是違反承諾，而是侵犯著作權；著作權人可以據此提起訴訟。這就是 GPL 能夠執行的根本原因。從 Harald Welte 在 2000 年代處理的 gpl-violations.org 案件，到 Software Freedom Conservancy 於 2021 年對 Vizio 提起的訴訟，都屬於這類執行案例。後者主張，購買該電視的人也能要求取得原始碼。

Linux 完成了整個系統

到了 1991 年，GNU 專案已經具備編譯器、C 函式庫、shell 和大部分工具，但仍沒有可運作的 kernel，因為 GNU 自有的 kernel Hurd 的開發時間遠超過原先規劃。1991 年 8 月，一名在 Helsinki 就讀的學生在 comp.os.minix 新聞群組發文：

我正在開發一個（免費的）作業系統（只是興趣，不會像 gnu 那樣龐大且專業），適用於 386(486) AT 相容機。

Linux 0.01 於 1991 年 9 月推出，當時採用 Linus Torvalds 自行撰寫的授權條款，禁止銷售。1992 年初，他改用 GPLv2，之後也表示這是他做過的最佳決定之一。這份授權讓企業能夠放心參與貢獻：公司可以派工程師投入 kernel 開發，並確信競爭對手無法將這些改進轉為私有程式碼。

Berkeley 當時已經有一套自由 Unix。Linux 而不是 BSD（Berkeley Software Distribution）成為預設的自由 Unix，部分原因在於一場訴訟。Unix System Laboratories 於 1992 年控告 Berkeley Software Design，案件一直持續到 1994 年初。在這兩年期間，BSD 系統承受法律風險，而 Linux 沒有這項風險；使用者也就在此時開始加入。FSF 要求人們將整合後的系統稱為 GNU/Linux，因為 Linux 是 kernel，而周邊大部分工具都來自 GNU。多數人仍稱其為 Linux。這兩個名稱指的都是同一組軟體。

1998：開放原始碼重新命名，以及始終未癒合的分裂

1998 年 1 月，Netscape 宣布將公開其瀏覽器的原始碼。當時還沒有其他這麼大型的公司做過這件事，因此暴露出一個實際問題。「free software」在英文中容易被理解為「不需要付費的軟體」，而企業主管聽到的正是這個意思。1998 年 2 月，一群人在 Palo Alto 聚會，尋找更合適的術語；Christine Peterson 提議使用「open source」。幾週內，Eric Raymond 與 Bruce Perens 成立了 Open Source Initiative (OSI)。該組織採用了 Open Source Definition，其內容改編自 Perens 在 1997 年撰寫的 Debian Free Software Guidelines。

Open Source Definition 有 10 項標準。其中 2 項決定了現代大多數爭論：原始碼必須可取得，且授權條款不得限制誰可以使用程式，或限制使用程式的用途。若授權條款寫著「不得將本程式作為商業服務提供」，即使允許其他用途，也不符合這項標準。請記住這句話。這正是現今 source-available 授權條款跨越的界線。

1998 年出現的分裂，爭議在於理由，而不是哪些授權條款可以接受。FSF 的立場是倫理性的：無法修改程式的使用者，無法控制自己的電腦。Raymond 透過文章「The Cathedral and the Bazaar」向企業闡述 OSI 的立場，這個立場較為務實：開放式開發能產生更好的軟體，而企業可以據此採取行動。Stallman 的回應文章「Why Open Source Misses the Point of Free Software」至今仍刊載於 gnu.org，而他從未接受這個較新的術語。Perens 曾協助創立 OSI，但在 1999 年以該運動已偏離 free software 為由，辭去 OSI 董事會職務。

有必要準確說明兩者在實務上的差距有多小。FSF 的 free licences 清單與 OSI 的 approved licences 清單幾乎完全一致，包括 GPL、MIT、Apache 2.0 與 BSD。需要同時表達兩種含義的作者，會使用 FOSS（free and open source software）或 FLOSS（free/libre and open source software）。

企業如何學會發布程式碼

Red Hat 在 1999 年上市，顯示支援與套件化比銷售軟體副本更有利可圖。IBM 在 2001 年承諾投入 10 億美元於 Linux。Microsoft 的執行長在 2001 年將 Linux 稱為「癌症」；但同一家公司在 2016 年加入 Linux Foundation，成為白金會員，並於 2018 年以 75 億美元的股票收購 GitHub。IBM 在 2019 年以 340 億美元收購 Red Hat。這些事件都不是對授權條款改變看法，而是資金所在位置改變了。當作業系統是共用成本時，自行維護的費用很高，因此每個供應商都更願意在上層服務競爭。

企業持有權也可能產生相反的結果。Oracle 在 2010 年收購 Sun 時一併取得 MySQL 與 OpenOffice.org，但兩個社群後來都離開了。MariaDB 源自 MySQL，而 LibreOffice 則在 2010 年 9 月從 OpenOffice.org 分支而出。分支是使用者社群真正擁有的唯一表決方式，而授權條款正是讓這種表決成為可能的原因。

為什麼你現在自架的部分應用程式出現了分支

自 2018 年起，數家公司更改了已發布軟體的授權條款。每次的情況都相同：一家公司的幾乎所有開發人員都受僱於該公司，而規模大得多的雲端服務供應商則將相同軟體作為代管服務銷售，最後規模較小的公司認定授權條款是其無法競爭的原因。

• MongoDB 在 2018 年 10 月採用 Server Side Public License (SSPL)。SSPL 規定，如果你將該軟體以服務形式提供給他人，就必須發布所有用於提供該服務之軟體的原始碼。OSI 不接受它為開放原始碼授權，MongoDB 也在 2019 年撤回審查申請。
• Redis 在 2018 年與 2019 年對部分模組增加使用限制，之後在 2024 年 3 月發布的 7.4 版中，將主要伺服器改為雙重 source-available 授權。最後一個採用 BSD 授權的版本在數天後出現分支，成為 Valkey，由 Linux Foundation 負責管理，並獲得 Amazon、Google 與 Oracle 等公司支持。2025 年 5 月，Redis 為 Redis 8 增加 Affero General Public License version 3 (AGPLv3) 作為第三種選項。
• Elastic 在 2021 年 1 月將 Elasticsearch 與 Kibana 移出 Apache 2.0，改採 SSPL 與 Elastic License 雙重授權。Amazon 建立了 OpenSearch 分支。Elastic 在 2024 年 8 月增加 AGPLv3 作為第三種選項；OpenSearch 則在 2024 年 9 月移交給 Linux Foundation，成為 OpenSearch Software Foundation。
• HashiCorp 在 2023 年 8 月將 Terraform 與其他工具改用 Business Source License (BUSL)。BUSL 在有效期間並非開放原始碼授權，因為它禁止競爭性的正式環境使用。每個版本都會在固定日期轉為開放授權；Terraform 會在 4 年後轉換。OpenTofu 在數週內建立分支，現在同樣由 Linux Foundation 管理。

這件事的雙方都有合理立場，且雙方都不是出於惡意。一家公司支付 50 名員工的薪資，卻由規模大得多的企業轉售其成果，這是單靠善意無法解決的問題。使用者依 Apache 2.0 條款建立系統，卻在某天醒來後發現條款已經改變，同樣會面臨問題，而且事前沒有人徵詢他們的意見。請注意其中兩個案例接下來發生的事。分支站穩腳步後，Elastic 與 Redis 都重新加入了強 copyleft。Copyleft 回應了最初的抱怨，因為 AGPLv3 要求服務提供者發布其執行的修改內容。截至 2026 年 8 月，這兩個專案及其分支都仍在持續開發，這正是這些授權條款原本要允許的結果。

誰有權變更授權條款

只有單一方掌控整個專案的所有著作權時，專案才能重新授權。公司通常透過兩種方式取得這項控制權。著作權轉讓會將每項貢獻的所有權移轉給公司。貢獻者授權協議（CLA）則讓你保留所有權，但授予公司足以重新授權你所提交內容的廣泛權利。這兩種文件通常都會透過連結簽署；該連結由 bot 在你第一次提交 pull request 時發布。

Linux 沒有 CLA。貢獻內容依 GPLv2 搭配 Developer Certificate of Origin 提交，而著作權分散在數千名個人與公司之間。沒有人能重新授權 Linux，因為不可能取得所有人的簽名。任何擁有許多獨立著作權人的專案也受到相同保護。這種保護比承諾更可靠，因為它是關於各項內容由誰擁有的客觀事實。

因此，對於你打算依賴的軟體，應該問的不是它目前是否為開放原始碼，而是誰能變更其授權條款，以及對方是否能單獨完成這項變更。

基金會實際提供的保障

基金會持有資產，並制定決策方式的規則。Apache Software Foundation、Linux Foundation、其旗下的 Cloud Native Computing Foundation，以及 Software Freedom Conservancy，分別以不同形式執行這項工作。基金會並不會因為具備基金會身分就自動保持中立。會員必須支付席位費用，而大型基金會專案中，多數全職工作者的薪資由會員公司支付。基金會提供的保障範圍較小，但仍然十分重要：商標與發行流程不屬於單一供應商，因此任何單一公司都無法將專案轉為私有。

商標是許多人忽略的部分。程式碼受授權條款規範。名稱屬於商標，而商標不受程式碼授權條款涵蓋。你可以隨時 fork 程式碼，但通常不能繼續使用原有名稱。因此，本故事中的 fork 專案稱為 Valkey、OpenSearch、OpenTofu 和 Forgejo。

維護者問題

現代基礎架構建立在僅有 1 或 2 名無薪維護者的專案上，而各種故障正是讓這個問題浮現的原因。2014 年的 OpenSSL Heartbleed 漏洞，影響了承載全球大量加密網路流量的函式庫；當時維護該函式庫的只有少數幾人，幾乎沒有經費。2021 年 12 月的 Log4Shell，則讓全球的事件回應工作集中到 Apache Log4j 專案的一個小型志願者團隊。

2024 年 3 月發現的 XZ Utils 後門，是最鮮明的案例，因為攻擊目標不是程式碼，而是維護者。某個帳號花了約 2 年時間，持續對一個廣泛用於各 Linux 發行版的壓縮函式庫提供確實有用的貢獻。其他帳號向已經精疲力竭的唯一維護者施壓，要求其接受協助。新的共同維護者接著在發行封存檔中植入後門，目標是 SSH（secure shell）daemon 與 liblzma 連結的系統。一名開發者在調查登入為何比預期多花約半秒時發現了這個後門。這是運氣，而所有相關人員都曾公開如此表示。

資金已開始流入：GitHub Sponsors 自 2019 年起提供資助，另有 Open Collective、德國自 2022 年起設立的 Sovereign Tech Fund，以及 OpenSSF 的 Alpha-Omega project。不過資金分配不均，而且通常會流向原本就已知名的專案。監管措施也開始到位。European Union 的 Cyber Resilience Act 於 2024 年 12 月生效，其中大部分義務自 2027 年 12 月起適用。早期草案原本會讓製造商責任落到無薪志願者身上，因此在 foundations 與 distributions 長期遊說後，最終文本建立了較寬鬆的「open source software steward」類別。

開源軟體的歷史對 VPS 上軟體的意義

我們自架指南中的每個應用程式，都受到這些決策的影響。Nextcloud 的存在源自一次 fork：2016 年，ownCloud 的創辦人與多數團隊成員離開，依 AGPLv3 重新啟動專案；此後兩個產品一直並行發展。這段歷史是值得考慮的 Nextcloud 替代方案以及自架 Dropbox 替代方案的背景，後兩者都與它們競爭。

Git hosting 也有相同的發展模式。Gitea 本身於 2016 年起源於 Gogs 的 fork。2022 年底，專案的商標與網域移轉至一家公司；同年 12 月，Codeberg fork 出 Forgejo；2024 年，Forgejo 隨版本 9 從 MIT 改用 GPLv3。兩者都收錄於自架 Git server 選項中，而授權條款的差異正是它們持續分歧的重要原因。另一方面，多數 free software 都在 GitHub 上開發。GitHub 是 Microsoft 擁有的封閉平台，這是由來已久的爭論，雙方都有充分理由：請參閱GitHub 的實際用途。

在將伺服器交給某個專案之前，以下 4 項檢查值得花 10 分鐘。

• 閱讀 repository 中的 LICENSE 檔案，不要只看行銷頁面。即使檔案內容早已不再符合，頁面仍可能持續聲稱「open source」。
• 查找 CLA 或 copyright assignment。若存在，單一擁有者可以變更未來版本的條款。
• 確認 copyright 的持有者是誰：單一公司、許多貢獻者，或 foundation。
• 計算 active maintainer 的人數。只有 1 人的專案，對該 maintainer 本身與對你而言都是風險。

這些內容並不是要你避開單一供應商的軟體。許多這類軟體都很優秀，而能取得報酬往往正是它們得以持續維護的原因。這些檢查能讓你了解自己暴露於哪些風險中。決定哪些服務值得自架時，請將授權條款與記憶體需求並列比較。

你可以在面前的機器上閱讀這段歷史的一部分。Debian 或 Ubuntu 系統中的每個 package 都會附上自己的條款：

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

第一個數字表示有多少已安裝 package 具備 copyright 檔案。小型 VPS 通常是幾百個。第二個 command 會顯示 bash 的 copyright 檔案開頭，其中列出 GNU General Public License version 3。若檔案不存在，表示該 package 未依 Debian policy 建置。這種情況很少見；在信任該 package 前，值得再檢查一次。

FAQ

免費軟體與開放原始碼有何不同？

兩者涵蓋的授權條款幾乎相同，但對這些授權條款重要性的理由不同。「免費軟體」是較早使用的術語，源自 1985 年的 Free Software Foundation，其論點是倫理性的：使用者若無法修改程式，就無法掌控電腦。「開放原始碼」則是在 1998 年 2 月創造的術語，目的是讓企業更容易理解相同的授權條款，其論點較偏向實務面。GPL、MIT、BSD 與 Apache 2.0 授權條款都列在兩個組織的官方清單中。想同時表達兩者的人，會使用 FOSS 或 FLOSS。

可取得原始碼的軟體與開放原始碼相同嗎？

不相同。可取得原始碼表示你可以閱讀程式碼。依照 Open Source Definition，開放原始碼還表示授權條款不得限制軟體的使用者，或限制軟體的用途。SSPL 與 Business Source License 都限制競爭性的商業使用，因此依照該定義，兩者都不屬於開放原始碼，即使兩者都公開原始碼。如果你只在自己的環境中自行代管，這項限制可能永遠不會影響你。如果你想在其上建立產品，應先仔細閱讀授權條款內容。

公司可以收回已授予的開放原始碼授權嗎？

對於已經發布的程式碼，不能收回。該版本會繼續適用發布時採用的授權條款。這正是 Valkey 與 OpenTofu 等分支能從最後一個採用寬鬆授權的 commit 開始的原因。公司可以為未來版本採用新的條款，但前提是公司透過著作權讓與或貢獻者授權協議，掌握整個專案的著作權。擁有許多獨立著作權人的專案，包括 Linux 在內，任何人都無法為其重新授權。

自行代管的軟體應選擇哪種授權條款？

對於由你自行執行且不轉售的軟體，任何 OSI 核准的授權條款，例如 GPL、AGPL、MIT 或 Apache 2.0，都能滿足你的需求。更值得確認的是著作權由誰持有，因為這會決定日後條款是否可能在未經你同意的情況下變更。由基金會或許多獨立貢獻者持有的專案，無法針對使用者重新授權。由單一供應商持有、且採用貢獻者授權協議的專案則可以。兩者都可能是優良軟體，但只有其中一者能自行變更規則。