關於 GNU 專案 - GNU 專案 - 自由軟體基金會

GNU 專案

第一個軟體分享社群

當我於 1971 年開始在麻省理工學院人工智慧實驗室工作時，我成為了一個存在多年的軟體分享社群的一份子。軟體分享並不侷限於我們特定的社群；它和電腦一樣古老，就像食譜分享和烹飪一樣古老。但我們比大多數人做得更多。

人工智慧實驗室使用一個名為 ITS（不相容分時系統）的分時作業系統，它是實驗室的駭客員工為數位PDP-10 設計並以組合語言編寫的，PDP-10 是那個時代的大型電腦之一 [1]。作為這個社群的成員，一位人工智慧實驗室的系統駭客員工，我的工作是改進這個系統。

我們當時沒有稱我們的軟體為「自由軟體」，因為這個術語還不存在；但它實際上就是自由軟體。每當其他大學或公司的人想要移植和使用一個程式時，我們都很樂意讓他們使用。如果你看到有人使用一個不熟悉但有趣的程式，你總是可以要求查看原始碼，這樣你就可以閱讀它、修改它，或者擷取其中的一部分來製作一個新的程式。

社群的崩潰

情況在 1980 年代初期發生了劇烈的變化，當時數位公司停止了 PDP-10 系列的生產。它的架構在 60 年代優雅而強大，但無法自然地擴展到 80 年代變得可行的更大位址空間。這意味著幾乎所有組成 ITS 的程式都過時了。

人工智慧實驗室的駭客社群早已崩潰，就在不久之前。1981 年，衍生公司 Symbolics 從人工智慧實驗室挖走了幾乎所有的駭客，人口稀少的社群無法維持自身。（史蒂夫·列維的著作《駭客》描述了這些事件，並清晰地描繪了這個社群鼎盛時期的景象。）當人工智慧實驗室在 1982 年購買了一台新的 PDP-10 時，其管理者決定使用數位公司的非自由分時系統，而不是 ITS。

那個時代的現代電腦，例如 VAX 或 68020，都有自己的作業系統，但它們都不是自由軟體：你甚至必須簽署保密協議才能取得可執行副本。

這意味著使用電腦的第一步就是承諾不幫助你的鄰居。合作社群被禁止。專有軟體的擁有者制定的規則是：「如果你與你的鄰居分享，你就是海盜。如果你想要任何更改，就乞求我們來做。」

專有軟體社會系統——這個系統說你不被允許分享或更改軟體——是反社會的，是不道德的，簡直是錯誤的，這個觀點可能會讓一些讀者感到驚訝。但是，對於一個建立在分裂公眾和讓使用者無助的基礎上的系統，我們還能說什麼呢？覺得這個想法令人驚訝的讀者可能已經將專有軟體社會系統視為理所當然，或者根據專有軟體企業提出的條款來判斷它。軟體發行商長期以來一直在努力說服人們，只有一種看待這個問題的方式。

當軟體發行商談論「執行」他們的「權利」或「阻止盜版」時，他們實際說什麼是次要的。這些聲明的真正訊息在於他們想當然的、未經聲明的假設，而這些假設卻要求公眾不經檢視地接受。因此，讓我們檢視它們。

一個假設是，軟體公司擁有對軟體的所有權以及因此擁有對所有使用者的權力，這是毋庸置疑的自然權利。（如果這是一項自然權利，那麼無論它對公眾造成多大的損害，我們都不能反對。）有趣的是，美國憲法和法律傳統拒絕這種觀點；版權不是一項自然權利，而是一種人為的、政府強加的壟斷，它限制了使用者複製的自然權利。

另一個未經聲明的假設是，關於軟體的唯一重要的事情是它允許你做什麼工作——我們電腦使用者不應該關心我們被允許擁有什麼樣的社會。

第三個假設是，如果我們不給予公司對程式使用者的權力，我們就沒有可用的軟體（或者永遠不會有程式來完成這個或那個特定的工作）。在自由軟體運動證明我們可以製作大量有用的軟體而無需給它加上枷鎖之前，這個假設似乎是合理的。

如果我們拒絕接受這些假設，並在將使用者放在首位的情況下，根據普通的常識道德來判斷這些問題，我們將得出截然不同的結論。電腦使用者應該可以自由地修改程式以適應他們的需求，並且可以自由地分享軟體，因為幫助他人是社會的基礎。

這裡沒有篇幅來詳盡闡述這個結論背後的理由，因此我建議讀者參考「為何軟體不應有所有者」和「自由軟體現在更加重要」。

一個嚴峻的道德選擇

隨著我的社群消失，像以前一樣繼續下去是不可能的。相反，我面臨著一個嚴峻的道德選擇。

簡單的選擇是加入專有軟體世界，簽署保密協議並承諾不幫助我的駭客同伴。我很可能也會開發在保密協議下發布的軟體，從而增加其他人背叛其同伴的壓力。

我可以通過這種方式賺錢，也許還能從編寫程式碼中自娛自樂。但我知道，在我的職業生涯結束時，我會回顧多年來建造牆壁來分隔人們，並感到我的一生都在讓世界變得更糟。

我已經體驗過成為保密協議的接收方，當時有人拒絕給我以及麻省理工學院人工智慧實驗室提供我們印表機控制程式的原始碼。（這個程式中缺少某些功能，使得印表機的使用極其令人沮喪。）所以我不能告訴自己保密協議是無辜的。當他拒絕與我們分享時，我非常生氣；我不能轉過身來對其他人做同樣的事情。

另一個選擇，直接但令人不快，是離開電腦領域。這樣我的技能就不會被濫用，但它們仍然會被浪費。我不會因為分裂和限制電腦使用者而受到譴責，但這仍然會發生。

所以我尋找一種程式設計師可以為善事做些事情的方法。我問自己，有沒有我可以編寫的程式或程式，以便再次使社群成為可能？

答案很明確：首先需要的是作業系統。這是開始使用電腦的關鍵軟體。有了作業系統，你可以做很多事情；沒有作業系統，你根本無法執行電腦。有了自由作業系統，我們可以再次擁有一個合作駭客社群——並邀請任何人加入。任何人都可以使用電腦，而無需從陰謀剝奪他或她的朋友開始。

作為一名作業系統開發人員，我擁有勝任這項工作的正確技能。因此，即使我不能認為成功是理所當然的，我也意識到我被選中來做這項工作。我選擇使系統與 Unix 相容，以便它具有可移植性，並且 Unix 使用者可以輕鬆地切換到它。 GNU 這個名稱是按照駭客傳統選擇的，作為「GNU's Not Unix」的遞迴首字母縮寫。它的發音是一個音節，帶有硬音 g。

作業系統不僅僅意味著一個核心，勉強足以執行其他程式。在 1970 年代，每個名副其實的作業系統都包括命令處理器、組譯器、編譯器、直譯器、除錯器、文字編輯器、郵件程式等等。 ITS 有它們，Multics 有它們，VMS 有它們，Unix 也有它們。 GNU 作業系統也將包含它們。

後來我聽說了這些話，歸功於希列爾 [2]

如果我不為自己，誰會為我？
如果我只為自己，我是什麼？
如果不是現在，更待何時？

啟動 GNU 專案的決定是基於類似的精神。

自由如自由

術語「自由軟體」有時會被誤解——它與價格無關。它關乎自由。因此，以下是自由軟體的定義。

對於您，特定使用者而言，如果滿足以下條件，則程式是自由軟體

您有權出於任何目的隨意執行該程式。
您有權修改程式以滿足您的需求。（為了使這種自由在實踐中有效，您必須可以存取原始碼，因為在沒有原始碼的情況下修改程式極其困難。）
您有權重新發行副本，無論是免費還是收費。
您有權發行程式的修改版本，以便社群可以從您的改進中受益。

由於「自由」指的是自由，而不是價格，因此銷售副本和自由軟體之間沒有矛盾。事實上，銷售副本的自由至關重要：在 CD-ROM 上銷售的自由軟體集合對於社群來說非常重要，並且銷售它們是為自由軟體開發籌集資金的重要途徑。因此，人們不能自由地將程式包含在這些集合中就不是自由軟體。

由於「free」的歧義，人們長期以來一直在尋找替代方案，但沒有人找到更好的術語。英語比任何其他語言都擁有更多的詞彙和細微差別，但它缺少一個簡單、明確的詞來表示「free」，如自由——「unfettered」是意義最接近的詞。諸如「liberated」、「freedom」和「open」之類的替代方案要么含義錯誤，要么存在其他缺點。

GNU 軟體和 GNU 系統

開發整個系統是一個非常龐大的專案。為了使它能夠實現，我決定改編和使用現有的自由軟體組件，只要有可能。例如，我從一開始就決定使用 TeX 作為主要的文字格式器；幾年後，我決定使用 X Window System，而不是為 GNU 重新編寫另一個視窗系統。

由於這些決定以及其他類似的決定，GNU 系統與所有 GNU 軟體的集合並不相同。 GNU 系統包含非 GNU 軟體的程式，這些程式是由其他人或專案為了他們自己的目的而開發的，但我們可以因為它們是自由軟體而使用它們。

專案的開始

1984 年 1 月，我辭去了在麻省理工學院的工作，開始編寫 GNU 軟體。離開麻省理工學院是必要的，這樣麻省理工學院就不會干預以自由軟體的形式發行 GNU。如果我繼續留在職位上，麻省理工學院可能會聲稱擁有這項工作的所有權，並且可能會強加他們自己的發行條款，甚至將這項工作變成專有軟體套件。我無意做大量的工作，卻眼睜睜地看著它對其預期目的變得毫無用處：創建一個新的軟體分享社群。

然而，當時的麻省理工學院人工智慧實驗室負責人溫斯頓教授好心地邀請我繼續使用實驗室的設施。

最初的步驟

在 GNU 專案開始之前不久，我聽說了自由大學編譯器套件，也稱為 VUCK。（荷蘭語中「自由」一詞是用 v 寫成的。）這是一個旨在處理多種語言（包括 C 和 Pascal）並支援多個目標機器的編譯器。我寫信給它的作者，詢問 GNU 是否可以使用它。

他輕蔑地回應說，大學是自由的，但編譯器不是。因此，我決定我在 GNU 專案中的第一個程式將是一個多語言、多平台的編譯器。

為了避免需要自己編寫整個編譯器，我取得了 Pastel 編譯器的原始碼，這是一個在勞倫斯利弗莫爾實驗室開發的多平台編譯器。它支援並使用 Pascal 的擴展版本編寫，旨在成為一種系統程式設計語言。我添加了一個 C 前端，並開始將其移植到 Motorola 68000 電腦。但當我發現編譯器需要數兆位元組的堆疊空間，而可用的 68000 Unix 系統只允許 64k 時，我不得不放棄。

然後我意識到 Pastel 編譯器的工作方式是將整個輸入檔案解析為語法樹，將整個語法樹轉換為一連串的「指令」，然後生成整個輸出檔案，而從不釋放任何儲存空間。在這一點上，我得出結論，我必須從頭開始編寫一個新的編譯器。這個新的編譯器現在被稱為 GCC；其中沒有使用 Pastel 編譯器的任何部分，但我設法改編並使用了我編寫的 C 前端。但那是幾年後的事了；首先，我致力於 GNU Emacs。

GNU Emacs

我於 1984 年 9 月開始 GNU Emacs 的工作，並在 1985 年初開始可以使用。這使我能夠開始使用 Unix 系統進行編輯；由於對學習使用 vi 或 ed 沒有興趣，在那之前我一直在其他類型的機器上進行編輯。

在這一點上，人們開始想要使用 GNU Emacs，這引發了如何發行它的問題。當然，我將它放在我使用的麻省理工學院電腦上的匿名 ftp 伺服器上。（這台電腦 prep.ai.mit.edu，因此成為主要的 GNU ftp 發行站點；當它在幾年後退役時，我們將名稱轉移到我們的新 ftp 伺服器。）但是在當時，許多感興趣的人不在網際網路上，無法通過 ftp 取得副本。所以問題是，我會對他們說什麼？

我可以說，「找一個在網路上並且願意為你製作副本的朋友。」或者我可以像我對原始 PDP-10 Emacs 所做的那樣：告訴他們，「寄給我一個磁帶和一個SASE，我會把它連同 Emacs 一起寄回給你。」但我沒有工作，我正在尋找從自由軟體中賺錢的方法。因此，我宣布我將向任何想要的人郵寄磁帶，費用為 150 美元。通過這種方式，我開始了一項自由軟體發行業務，這是今天發行整個 GNU/Linux 系統發行版的公司的前身。

程式對每個使用者都是自由的嗎？

如果一個程式在離開其作者之手時是自由軟體，這並不一定意味著它對於擁有其副本的每個人都將是自由軟體。例如，公有領域軟體（未受版權保護的軟體）是自由軟體；但任何人都可以製作它的專有修改版本。同樣，許多自由程式都受版權保護，但在簡單的許可授權下發行，這些許可授權允許專有修改版本。

這個問題的典範例子是 X Window System。它在麻省理工學院開發，並以許可授權作為自由軟體發行，很快被各種電腦公司採用。他們將 X 以僅二進位形式添加到他們的專有 Unix 系統中，並受相同的保密協議約束。這些 X 副本與 Unix 一樣，都不是自由軟體。

X Window System 的開發人員不認為這是一個問題——他們期望並打算這樣做。他們的目標不是自由，只是「成功」，定義為「擁有許多使用者」。他們不在乎這些使用者是否擁有自由，只在乎他們應該數量眾多。

這導致了一種自相矛盾的情況，在這種情況下，兩種不同的計算自由量的方法對「這個程式是自由的嗎？」這個問題給出了不同的答案。如果你根據麻省理工學院發行版的發行條款提供的自由來判斷，你會說 X 是自由軟體。但如果你衡量 X 的普通使用者的自由，你將不得不說它是專有軟體。大多數 X 使用者都在執行 Unix 系統附帶的專有版本，而不是自由版本。

著作權保護和 GNU GPL

GNU 的目標是給予使用者自由，而不僅僅是受歡迎。因此，我們需要使用發行條款來防止 GNU 軟體變成專有軟體。我們使用的方法稱為「著作權保護」 [3]。

著作權保護使用版權法，但將其翻轉過來以服務於與其通常目的相反的目的：它不是限制程式的手段，而是成為保持程式自由的手段。

著作權保護的核心思想是，我們允許每個人執行程式、複製程式、修改程式和發行修改後的版本——但不允許他們添加自己的限制。因此，定義「自由軟體」的關鍵自由得到了每個擁有副本的人的保證；它們成為不可剝奪的權利。

對於有效的著作權保護，修改後的版本也必須是自由的。這確保了基於我們工作的成果，如果發布，將可供我們的社群使用。當作為程式設計師工作的程式設計師自願改進 GNU 軟體時，著作權保護可以防止他們的雇主說，「你不能分享這些更改，因為我們將使用它們來製作我們程式的專有版本。」

如果我們想確保每個程式使用者的自由，則更改必須是自由的要求至關重要。將 X Window System 私有化的公司通常會對其進行一些更改，以將其移植到他們的系統和硬體。這些更改與 X 的巨大範圍相比很小，但它們並非微不足道。如果進行更改是拒絕使用者自由的藉口，那麼任何人都可以很容易地利用這個藉口。

一個相關的問題涉及將自由程式與非自由程式碼結合使用。這種組合不可避免地會是非自由的；非自由部分缺乏的任何自由也將在整體上缺乏。允許這種組合將會打開一個足以擊沉一艘船的大洞。因此，著作權保護的一個關鍵要求是堵住這個洞：任何添加到或與受著作權保護的程式組合的東西都必須使更大的組合版本也是自由且受著作權保護的。

我們為大多數 GNU 軟體使用的著作權保護的具體實施是 GNU 通用公共授權，或簡稱 GNU GPL。我們還有其他類型的著作權保護，用於特定情況。 GNU 手冊也受著作權保護，但使用更簡單的著作權保護類型，因為 GNU GPL 的複雜性對於手冊來說是不必要的 [4]。

自由軟體基金會

隨著人們對使用 Emacs 的興趣日益濃厚，其他人也加入了 GNU 專案，我們認為現在是再次尋求資金來支持 GNU 作業系統開發的時候了。因此，在 1985 年，我引入了關心這個目標的朋友，並創建了自由軟體基金會（FSF），這是一個免稅慈善機構，用於自由軟體開發。 FSF 還接管了 Emacs 磁帶發行業務；後來，它通過在磁帶中添加其他自由軟體（GNU 和非 GNU）以及銷售自由（尊重自由）手冊來擴展這項業務。

FSF 的大部分收入曾經來自銷售自由軟體副本和其他相關服務（原始碼 CD-ROM、二進位檔 CD-ROM、精美印刷的手冊，所有這些都具有重新發行和修改的自由），以及豪華發行版（我們為客戶選擇的平台構建整個軟體集合的發行版）。今天，FSF 仍然銷售手冊和其他裝備，但其大部分資金來自會員費。您可以在 fsf.org 加入 FSF。

自由軟體基金會的員工編寫和維護了許多 GNU 軟體套件。其中兩個著名的套件是 C 程式庫和 shell。 GNU C 程式庫是每個在 GNU/Linux 系統上運行的程式用來與 Linux 通訊的程式庫。它是由自由軟體基金會的一名員工 Roland McGrath 開發的。大多數 GNU/Linux 系統上使用的 shell 是 BASH，Bourne Again SHell [5]，它是由 FSF 員工 Brian Fox 開發的。

我們資助這些程式的開發，因為 GNU 專案不僅僅是關於工具或開發環境。我們的目標是一個完整的作業系統，而這些程式是實現該目標所必需的。

自由軟體支援

自由軟體哲學拒絕一種特定的廣泛商業慣例，但它並不反對商業。當企業尊重使用者的自由時，我們希望他們成功。

銷售 Emacs 副本展示了一種自由軟體業務。當 FSF 接管這項業務時，我需要另一種謀生方式。我在銷售與我開發的自由軟體相關的服務中找到了它。這包括教學，科目例如如何編寫 GNU Emacs 程式以及如何客製化 GCC，以及軟體開發，主要是將 GCC 移植到新平台。

今天，每種自由軟體業務都被許多公司實踐。有些公司在 CD-ROM 上發行自由軟體集合；其他公司則銷售支援，支援層級從回答使用者問題、修復錯誤到添加主要新功能不等。我們甚至開始看到基於推出新的自由軟體產品的自由軟體公司。

但請注意——許多將自己與術語「開放原始碼」聯繫起來的公司實際上是將他們的業務建立在與自由軟體協同工作的非自由軟體之上。這些不是自由軟體公司，它們是專有軟體公司，它們的產品引誘使用者遠離自由。他們稱這些程式為「增值套件」，這表明了他們希望我們採用的價值觀：便利性高於自由。如果我們更重視自由，我們應該稱它們為「自由縮減」套件。

技術目標

GNU 的主要目標是成為自由軟體。即使 GNU 沒有比 Unix 更優越的技術優勢，它也將具有社會優勢，允許使用者合作，以及道德優勢，尊重使用者的自由。

但將已知的良好實踐標準應用於這項工作是很自然的——例如，動態分配資料結構以避免任意的固定大小限制，以及在任何有意義的地方處理所有可能的 8 位元程式碼。

此外，我們拒絕了 Unix 專注於小記憶體大小的做法，決定不支持 16 位元機器（很明顯，到 GNU 系統完成時，32 位元機器將成為常態），並且除非記憶體使用量超過 1 兆位元組，否則不努力減少記憶體使用量。對於處理非常大的檔案並非至關重要的程式，我們鼓勵程式設計師將整個輸入檔案讀入核心，然後掃描其內容，而無需擔心 I/O。

這些決定使許多 GNU 程式在可靠性和速度方面超越了它們的 Unix 對應程式。

捐贈的電腦

隨著 GNU 專案的聲譽日漸提高，人們開始主動向該專案捐贈運行 Unix 的機器。這些機器非常有用，因為開發 GNU 組件最簡單的方法是在 Unix 系統上進行開發，然後逐個替換該系統的組件。但它們引發了一個道德問題：我們是否完全有權擁有 Unix 副本。

Unix 曾經是（現在仍然是）專有軟體，而 GNU 專案的哲學認為我們不應該使用專有軟體。但是，應用導致自衛暴力是正當的結論的相同推理，我得出結論，當使用專有套件對於開發可以幫助其他人停止使用專有套件的自由替代品至關重要時，使用專有套件是合法的。

但是，即使這是一種可以原諒的罪惡，它仍然是一種罪惡。今天我們不再擁有任何 Unix 副本，因為我們已經用自由作業系統替換了它們。如果我們無法用自由作業系統替換機器的作業系統，我們就替換了機器。

GNU 任務清單

隨著 GNU 專案的進行，以及越來越多的系統組件被發現或開發出來，最終製作一份剩餘空白的清單變得很有用。我們用它來招募開發人員來編寫缺失的部分。這個清單被稱為 GNU 任務清單。除了缺失的 Unix 組件外，我們還列出了各種其他有用的軟體和文件專案，我們認為，一個真正完整的系統應該具備這些專案。

今天 [6]，GNU 任務清單中幾乎沒有剩餘任何 Unix 組件——除了少數不重要的組件外，這些工作都已完成。但該清單上滿是一些人可能稱之為「應用程式」的專案。任何吸引多個狹隘使用者群體的程式都將是添加到作業系統中的有用事物。

甚至遊戲也包含在任務清單中——並且從一開始就包含在內。 Unix 包含遊戲，因此 GNU 自然也應該包含遊戲。但相容性並不是遊戲的問題，因此我們沒有遵循 Unix 所擁有的遊戲清單。相反，我們列出了一系列使用者可能喜歡的不同類型的遊戲。

GNU 寬鬆通用公共授權條款

GNU C 程式庫使用一種稱為 GNU 寬鬆通用公共授權條款 [7]的特殊著作權保護，它允許將專有軟體與該程式庫連結。為什麼要做出這個例外？

這不是原則問題；沒有任何原則說專有軟體產品有權包含我們的程式碼。（為什麼要為一個基於拒絕與我們分享的專案做出貢獻？）對於 C 程式庫或任何程式庫使用 LGPL 是一個策略問題。

C 程式庫完成了一項通用工作；每個專有系統或編譯器都帶有一個 C 程式庫。因此，僅向自由軟體提供我們的 C 程式庫不會給自由軟體帶來任何優勢——它只會阻止人們使用我們的程式庫。

有一個系統是這種情況的例外：在 GNU 系統（這包括 GNU/Linux）上，GNU C 程式庫是唯一的 C 程式庫。因此，GNU C 程式庫的發行條款決定了是否可以在 GNU 系統上編譯專有程式。在 GNU 系統上允許專有應用程式沒有道德理由，但從策略上看，禁止它們似乎比鼓勵自由應用程式的開發更不利於 GNU 系統的使用。這就是為什麼對於 C 程式庫來說，使用寬鬆通用公共授權條款是一個好的策略。

對於其他程式庫，策略決策需要根據具體情況考慮。當一個程式庫完成一項特殊工作，可以幫助編寫某些類型的程式時，那麼根據 GPL 發行它，僅限於自由程式，是一種幫助其他自由軟體開發人員的方式，使他們在與專有軟體競爭時具有優勢。

考慮 GNU Readline，這是一個為 BASH 提供命令列編輯功能的程式庫。 Readline 在普通的 GNU GPL 而不是寬鬆通用公共授權條款下發行。這可能會減少 Readline 的使用量，但這對我們來說沒有損失。同時，至少有一個有用的應用程式被專門製作成自由軟體，以便它可以使用 Readline，這對社群來說是一個真正的收穫。

專有軟體開發人員擁有金錢提供的優勢；自由軟體開發人員需要為彼此創造優勢。我希望有一天我們能擁有大量的 GPL 覆蓋的程式庫，這些程式庫沒有專有軟體可用的同類程式庫，提供有用的模組作為新的自由軟體的建構模組，並為進一步的自由軟體開發增加主要優勢。

解決個人需求？

Eric Raymond 說「每個好的軟體作品都始於解決開發人員的個人需求。」也許有時會發生這種情況，但許多 GNU 軟體的必要組成部分是為了擁有一個完整的自由作業系統而開發的。它們來自願景和計畫，而不是衝動。

例如，我們開發 GNU C 程式庫是因為類 Unix 系統需要 C 程式庫，開發 BASH 是因為類 Unix 系統需要 shell，開發 GNU tar 是因為類 Unix 系統需要 tar 程式。我的個人程式——GNU C 編譯器、GNU Emacs、GDB 和 GNU Make 也是如此。

部分 GNU 程式的開發是為了應對對於我們自由的特定威脅。因此，我們開發了 gzip 以取代 Compress 程式，這個程式因為 LZW 專利而從社群中消失。我們找到了人們來開發 LessTif，並且最近開始了 GNOME 和 Harmony，以解決某些專有函式庫所造成的問題（見下文）。我們正在開發 GNU Privacy Guard 以取代流行的非自由加密軟體，因為使用者不應該需要在隱私和自由之間做出選擇。

當然，撰寫這些程式的人們對這項工作產生了興趣，而且許多人為了他們自己的需求和興趣，為這些程式添加了許多功能。但這並不是這些程式存在的理由。

意料之外的發展

在 GNU 專案開始之初，我曾想像我們會開發整個 GNU 系統，然後將其作為一個整體發布。但事實並非如此。

由於 GNU 系統的每個組件都是在 Unix 系統上實作的，因此每個組件都可以在完整的 GNU 系統存在之前，很久就在 Unix 系統上執行。其中一些程式變得流行起來，使用者開始擴展它們並將它們移植到各種不相容的 Unix 版本，有時也移植到其他系統。

這個過程使這些程式變得更加強大，並為 GNU 專案吸引了資金和貢獻者。但這可能也延遲了最小可用系統的完成時間好幾年，因為 GNU 開發人員的時間被用於維護這些移植版本以及為現有組件添加功能，而不是繼續編寫一個又一個缺失的組件。

GNU Hurd

到 1990 年，GNU 系統幾乎完成了；唯一主要的缺失組件是核心。我們已決定將我們的核心實作為一組在 Mach 之上運行的伺服器進程。Mach 是在卡內基美隆大學，然後在猶他大學開發的微核心；GNU Hurd 是一組伺服器（即一群 GNUs），它們在 Mach 之上運行，並執行 Unix 核心的各種工作。由於我們在等待 Mach 作為自由軟體發布（正如承諾的那樣），因此開發的開始被延遲了。

選擇這種設計的原因之一是為了避免似乎是這項工作中最困難的部分：在沒有原始碼級偵錯器的情況下偵錯核心程式。這部分工作已經在 Mach 中完成了，我們期望使用 GDB 將 Hurd 伺服器作為使用者程式進行偵錯。但是，實現這一目標花費了很長時間，而且多執行緒伺服器之間互相發送訊息，結果證明非常難以偵錯。使 Hurd 穩定運作已經持續了很多年。

Alix

GNU 核心最初不應該被稱為 Hurd。它的原始名稱是 Alix——以當時我的愛人命名。她是一位 Unix 系統管理員，她指出她的名字如何符合 Unix 系統版本的通用命名模式；作為一個玩笑，她告訴她的朋友們，「應該有人以我的名字命名一個核心。」我什麼也沒說，但決定用一個名為 Alix 的核心給她一個驚喜。

情況並非如此。核心的主要開發者 Michael（現在是 Thomas）Bushnell 更喜歡 Hurd 這個名字，並重新定義 Alix 以指代核心的某個部分——負責捕獲系統呼叫並透過向 Hurd 伺服器發送訊息來處理它們的部分。

後來，Alix 和我分手了，她改了名字；與此同時，Hurd 的設計也發生了變化，使得 C 函式庫可以直接向伺服器發送訊息，這使得 Alix 組件從設計中消失了。

但在這些事情發生之前，她的一個朋友在 Hurd 原始碼中看到了 Alix 這個名字，並向她提起了。所以她確實有機會找到一個以她的名字命名的核心。

Linux 和 GNU/Linux

GNU Hurd 不適合生產環境使用，而且我們不知道它是否會適合。基於能力的設計存在問題，這些問題直接源於設計的靈活性，而且目前尚不清楚是否存在解決方案。

幸運的是，另一個核心可用。在 1991 年，Linus Torvalds 開發了一個與 Unix 相容的核心，並將其命名為 Linux。它最初是專有的，但在 1992 年，他將其變成了自由軟體；將 Linux 與尚未完全完成的 GNU 系統結合起來，就產生了一個完整的自由作業系統。（當然，將它們結合起來本身就是一項重要的工作。）正因為有了 Linux，我們今天才能實際運行 GNU 系統的一個版本。

我們將這個系統版本稱為 GNU/Linux，以表達它是 GNU 系統與 Linux 作為核心的組合。請不要養成將整個系統稱為「Linux」的習慣，因為那意味著將我們的工作歸功於其他人。請給予我們同等的提及。

我們未來面臨的挑戰

我們已經證明了我們開發廣泛自由軟體的能力。這並不意味著我們是無敵且不可阻擋的。有幾個挑戰使自由軟體的未來充滿不確定性；應對這些挑戰需要堅定的努力和毅力，有時會持續數年。這將需要人們在珍視自己的自由，並且不允許任何人奪走自由時所展現的那種決心。

以下四個章節討論了這些挑戰。

秘密硬體

硬體製造商越來越傾向於將硬體規格保密。這使得編寫自由驅動程式變得困難，以至於 Linux 和 XFree86 無法支援新的硬體。我們今天有完整的自由系統，但如果我們無法支援未來的電腦，我們明天將不會有它們。

有兩種方法可以應對這個問題。程式設計師可以進行逆向工程，以找出如何支援硬體。我們其他人可以選擇自由軟體支援的硬體；隨著我們人數的增加，規格保密將會成為一種適得其反的政策。

逆向工程是一項龐大的工作；我們是否會有足夠決心的程式設計師來承擔它？是的——如果我們已經建立起一種強烈的感覺，即自由軟體是一項原則問題，而非自由驅動程式是不可容忍的。而且，我們是否會有大量的人願意花費額外的金錢，甚至只是一點點額外的時間，以便我們可以使用自由驅動程式？是的，如果擁有自由的決心是廣泛存在的[8]。

非自由函式庫

在自由作業系統上運行的非自由函式庫，對於自由軟體開發人員來說，就像一個陷阱。該函式庫的吸引人的功能是誘餌；如果你使用該函式庫，你就會掉入陷阱，因為你的程式無法有效地成為自由作業系統的一部分。（嚴格來說，我們可以包含你的程式，但它在缺少該函式庫的情況下將無法運行。）更糟糕的是，如果一個使用專有函式庫的程式變得流行起來，它可能會將其他毫無戒心的程式設計師誘入陷阱。

這個問題的第一個例子是 80 年代的 Motif 工具組。儘管當時還沒有自由作業系統，但很明顯 Motif 後來會對它們造成什麼問題。GNU 專案以兩種方式做出了回應：要求各個自由軟體專案同時支援自由的 X Toolkit 小工具和 Motif，並要求有人編寫一個自由的 Motif 替代品。這項工作花費了很多年；由 Hungry Programmers 開發的 LessTif，直到 1997 年才變得足夠強大，可以支援大多數 Motif 應用程式。

在 1996 年至 1998 年間，另一個非自由的 GUI 工具組函式庫，稱為 Qt，被用於大量的自由軟體中，即桌面 KDE。

自由的 GNU/Linux 系統無法使用 KDE，因為我們無法使用該函式庫。然而，一些不嚴格遵守自由軟體原則的 GNU/Linux 系統商業發行商，將 KDE 添加到他們的系統中——產生了一個功能更多，但自由度更低的系統。KDE 團隊積極鼓勵更多的程式設計師使用 Qt，數百萬新的「Linux 使用者」從未接觸過這其中存在問題的想法。情況看起來很嚴峻。

自由軟體社群以兩種方式回應了這個問題：GNOME 和 Harmony。

GNOME，GNU 網路物件模型環境，是 GNU 的桌面專案。GNOME 由 Miguel de Icaza 於 1997 年啟動，並在 Red Hat Software 的支持下開發，旨在提供類似的桌面設施，但完全使用自由軟體。它也具有技術優勢，例如支援多種語言，而不僅僅是 C++。但其主要目的是自由：不要求使用任何非自由軟體。

Harmony 是一個相容的替代函式庫，旨在使在不使用 Qt 的情況下運行 KDE 軟體成為可能。

在 1998 年 11 月，Qt 的開發人員宣布更改授權條款，當條款實施後，應該會使 Qt 成為自由軟體。沒有辦法確定，但我認為這部分歸因於社群對 Qt 在非自由時所構成問題的堅決回應。（新的授權條款不方便且不公平，因此避免使用 Qt 仍然是可取的[9]。）

我們將如何回應下一個誘人的非自由函式庫？整個社群是否會理解需要遠離陷阱？還是我們中的許多人會為了方便而放棄自由，並產生一個重大問題？我們的未來取決於我們的哲學。

軟體專利

我們面臨的最嚴重威脅來自軟體專利，它可能會使演算法和功能在長達二十年的時間內對自由軟體關閉。LZW 壓縮演算法專利於 1983 年申請，我們仍然無法發布自由軟體來產生適當的壓縮 GIF[10]。在 1998 年，一個用於產生 MP3 壓縮音訊的自由程式，在專利訴訟的威脅下被從發行管道中移除[11]。

有一些方法可以應對專利：我們可以尋找證據證明專利無效，而且我們可以尋找替代方法來完成工作。但是，這些方法中的每一種都只能在某些時候起作用；當兩者都失敗時，專利可能會迫使所有自由軟體都缺少使用者想要的某些功能。經過漫長的等待，專利到期了，但在那之前我們該怎麼辦？

那些為了自由而珍視自由軟體的人，無論如何都會堅持使用自由軟體。我們將設法在沒有專利功能的情況下完成工作。但是，那些因為期望自由軟體在技術上更優越而珍視它的人，當專利阻礙它時，很可能會認為它是失敗的。因此，儘管談論「市集」開發模型的實際有效性，以及某些自由軟體的可靠性和強大功能是有用的，但我們絕不能止步於此。我們必須談論自由和原則。

自由文件

我們的自由作業系統中最大的缺陷不是在軟體方面——而是我們可以在系統中包含的良好自由手冊的缺乏。文件是任何軟體套件的重要組成部分；當一個重要的自由軟體套件沒有附帶良好的自由手冊時，這是一個主要的缺口。我們今天有很多這樣的缺口。

自由文件，就像自由軟體一樣，是一個自由問題，而不是價格問題。自由手冊的標準與自由軟體的標準幾乎相同：這是關於給予所有使用者某些自由。必須允許重新發行（包括商業銷售）、線上和紙本，以便手冊可以隨附程式的每個副本。

修改的許可也很關鍵。作為一般規則，我不認為人們必須有權限修改所有種類的文章和書籍。例如，我不認為你或我有義務允許修改像本文這樣的文章，這些文章描述了我們的行為和觀點。

但是，有一個特殊的原因，為什麼修改自由對於自由軟體的文件至關重要。當人們行使他們修改軟體的權利，並添加或更改其功能時，如果他們盡責，他們也會更改手冊——以便他們可以為修改後的程式提供準確且可用的文件。不允許程式設計師盡責地完成工作的非自由手冊，無法滿足我們社群的需求。

對於修改方式的一些限制不會造成問題。例如，保留原始作者的著作權聲明、發行條款或作者列表的要求是可以接受的。要求修改後的版本包含它們已被修改的通知，甚至包含不得刪除或更改的整個章節，只要這些章節處理非技術主題，也沒有問題。這些種類的限制沒有問題，因為它們不會阻止盡責的程式設計師使手冊適應修改後的程式。換句話說，它們不會阻止自由軟體社群充分利用手冊。

但是，必須可以修改手冊的所有技術內容，然後通過所有常見媒體、通過所有常見管道發行結果；否則，這些限制會阻礙社群，手冊不是自由的，而且我們需要另一本手冊。

自由軟體開發人員是否會有意識和決心來製作完整的自由手冊？再次強調，我們的未來取決於哲學。

我們必須談論自由

今天的估計是，有數千萬使用者使用 Debian GNU/Linux 和 Red Hat「Linux」等 GNU/Linux 系統。自由軟體已經發展出如此實際的優勢，以至於使用者僅僅因為實際原因而蜂擁而至。

這帶來的好處是顯而易見的：更多對開發自由軟體的興趣、更多自由軟體企業的客戶，以及更多鼓勵公司開發商業自由軟體而不是專有軟體產品的能力。

但是對軟體的興趣增長速度快於對其所基於的哲學的意識，這導致了麻煩。我們應對上述挑戰和威脅的能力，取決於堅定捍衛自由的意願。為了確保我們的社群擁有這種意願，我們需要在新使用者加入社群時，向他們傳播這個理念。

但是我們沒有做到這一點：吸引新使用者加入我們社群的努力，遠遠超過了教導他們我們社群公民義務的努力。我們需要同時做到這兩件事，而且我們需要保持這兩項努力的平衡。

「開放原始碼」

在 1998 年，當社群的一部分人決定停止使用「自由軟體」這個術語，而改說「開放原始碼軟體」時，教導新使用者關於自由變得更加困難。

一些贊成這個術語的人，旨在避免將「自由」與「免費」混淆——這是一個有效的目標。然而，其他人則旨在拋開激勵自由軟體運動和 GNU 專案的原則精神，轉而呼籲高階主管和商業使用者，他們中的許多人持有將利潤置於自由、社群、原則之上的意識形態。因此，「開放原始碼」的言論重點是製作高品質、強大軟體的潛力，但避開了自由、社群和原則的理念。

「Linux」雜誌是這方面的一個明顯例子——它們充斥著適用於 GNU/Linux 的專有軟體廣告。當下一個 Motif 或 Qt 出現時，這些雜誌會警告程式設計師遠離它，還是會刊登它的廣告？

商業的支持可以在許多方面為社群做出貢獻；在其他條件相同的情況下，它是有用的。但是，透過更少地談論自由和原則來贏得他們的支持可能是災難性的；它使先前外展和公民教育之間的失衡變得更糟。

「自由軟體」和「開放原始碼」或多或少地描述了同一類軟體，但對軟體以及價值觀說了不同的事情。GNU 專案繼續使用術語「自由軟體」，以表達自由而不僅僅是技術的重要性。

嘗試！

尤達的格言（「沒有『嘗試』這回事」）聽起來很簡潔，但它對我不起作用。我大部分的工作都是在擔心我是否能完成這項工作，以及不確定即使我完成了，是否足以實現目標的情況下完成的。但我還是嘗試了，因為在敵人和我所在的城市之間，只有我一個人。令我自己驚訝的是，我偶爾會成功。

有時我失敗了；我的一些城市淪陷了。然後我找到了另一個受到威脅的城市，並準備好迎接另一場戰鬥。隨著時間的推移，我學會了尋找威脅，並將自己置於它們和我的城市之間，呼籲其他駭客來加入我。

如今，通常我不僅僅是一個人。當我看到一支駭客軍團正在挖掘壕溝以守住陣線時，我感到如釋重負和喜悅，而且我意識到，這座城市可能會倖存下來——至少目前是這樣。但是危險每年都在增加，現在微軟已經明確地將我們的社群作為目標。我們不能認為自由的未來是理所當然的。不要認為它是理所當然的！如果你想保持你的自由，你必須準備好捍衛它。

腳註

大眾媒體將「駭客」用來表示「安全破壞者」是一種混淆。我們駭客拒絕承認這種含義，並繼續使用這個詞來表示熱愛程式設計的人、享受有趣的聰明才智的人，或兩者的結合。請參閱我的文章「論駭客。」
PDP 機器特別有助於駭客行為，因為它們是多用途、完全互動的，這與大型主機形成鮮明對比，並且允許軟體和資訊的共享。
作為一個無神論者，我不追隨任何宗教領袖，但我有時發現我很欣賞其中一位領袖所說的一些話。
在 1984 年或 1985 年，Don Hopkins（一位非常有想像力的人）寄給我一封信。在信封上，他寫了幾句有趣的諺語，包括這句：「Copyleft—all rights reversed.」（反著作權—所有權利倒轉。）我用「copyleft」（反著作權）這個詞來命名我當時正在開發的發行概念。
我們現在為文件使用 GNU 自由文件許可證。
「Bourne Again Shell」（再次出生的 Bourne Shell）是對「Bourne Shell」這個名稱的雙關語，「Bourne Shell」是 Unix 上常用的 shell。
那是 1998 年寫的。在 2009 年，我們不再維護一個長期的任務列表。社群開發自由軟體的速度如此之快，以至於我們甚至無法追蹤所有這些軟體。相反，我們有一個高優先級專案列表，這是一個簡短得多的列表，列出了我們真正希望鼓勵人們編寫的專案。
這個許可證最初被稱為 GNU Library General Public License（GNU 函式庫通用公共許可證），我們將其重新命名，以避免給人一種所有函式庫都應該使用它的想法。請參閱為什麼你不應該為你的下一個函式庫使用 Lesser GPL 以獲取更多資訊。
2008 年註：這個問題也延伸到 BIOS。有一個自由 BIOS，LibreBoot（coreboot 的一個發行版）；問題在於獲取機器的規格，以便 LibreBoot 可以在沒有非自由「blobs」（二進位大型物件）的情況下支援它們。
在 2000 年 9 月，Qt 在 GNU GPL 下重新發布，這基本上解決了這個問題。
截至 2009 年，GIF 專利已到期。
截至 2017 年，MP3 專利已到期。看看我們不得不等待多久。