本翻譯可能無法反應當下現況。文章更動時間為 2021-10-24 ，原文為 英文。

您應該查閱 更動之處。 請參見 翻譯讀我 README 來瞭解維護本文翻譯所需之相關事宜。

GNU 專案

作者為 Richard Stallman

文章原載於 Open Sources 一書中。理查・史托曼先生 (Richard Stallman) 從來不是「開源」或「Open Source」的支持者，但基於不願讓自由軟體運動的想法在該書中完全缺席而寫下本文。

為何堅持我們使用的軟體應該自由前所未有地重要。

最早的軟體共享社群

1971年當我在 MIT 麻省理工學院的人工智慧實驗室（英文簡稱 AI Lab）工作時開始，我成了軟體共享社群的一員，而這個社群已經存在好些年了。分享軟體的行為不限於我們這個社群；這種行為跟電腦的發展史一樣久遠，好比分享食譜的歷史跟烹調食物的歷史同樣古老。但我們這個社群比起絕大多數人更常分享。

AI Lab 當時採用一種稱為 ITS (全名為 Incompatible Timesharing System，意思為「不相容分時系統」) 的分時作業系統，它由實驗室的黑客職員 (1) 設計，並且以 Digital PDP-10 的組合語言編寫。這種 PDP-10 電腦屬於那個世代的大型電腦之一。身為這個社群的一份子，也就是 AI Lab 的系統黑客職員，我的工作就是改善這套系統。

我們那時的軟體不叫「自由軟體」，因為這個詞語還不存在，但這個概念就是從那時候的軟體延續而來。每當其他大學或公司的人想要移植某程式或使用某程式時，我們都很高興讓他們利用。而當你看到某人在用你所不知道的程式，或是很有趣的程式，你都會向他們要源始程式碼，這樣你就能讀它、改它、甚至擷取你想利用的部份來創造新程式……等等。

(1) 部份的大眾媒體常將「黑客 Hacker」和「安全破壞客 Security Breaker」混為一談（譯註：臺灣媒體則將兩者混稱為駭客）。我們黑客不承認那種意思的用法，而且會繼續使用黑客一詞來指那些熱愛寫程式的人、樂於發揮有趣的慧黠想法的人，或是結合兩種特質的人。請讀我這篇《論黑客》文章。

社群崩解

1980年代初期，Digital 公司中止了 PDP-10 系列，情況有了劇烈變化。該系列機器在60年代期間優雅又強大的架構，先天上無法拓展成80年代逐漸成型的較大位址空間架構。這代表幾乎所有原先構成 ITS 的程式都慘遭淘汰。

在這短時間內，AI Lab 的黑客社群儼然瓦解。1981年，從實驗室分出來的 Symbolics 公司幾乎挖走所有 AI Lab 的黑客，殘餘的社群幾乎無以為繼。（Steve Levy 著作的《Hacker》，中譯本名為《黑客列傳》由 Jedi 與 Pluto 翻譯，書中談論這些故事情節，同時也清楚描繪出此社群輝煌時期的樣貌。）當 AI Lab 在1982年買下 PDP-10 的新機時，其管理員決定改用 Digital 的非自由分時系統取代 ITS。

該世代的新電腦，例如 VAX 或 68020，都有自己的作業系統，但是它們都不是自由軟體：你甚至必須簽署 NDA 不揭露協議書，才能取得可執行副本。

這代表使用電腦的第一步驟，就是要保證你絕對不會拿軟體幫助朋友鄰居。互助合作的社群被禁止。專有軟體的所有人設下規定：「如果你想要和朋友鄰居分享，那你就是偷盜。如果你想要有任何改變，請求我們實現。」

專有軟體的社會體系概念——你不能分享或更改軟體的社會——即反社會，那沒有道德、根本就是錯誤，或許有些讀者看到這裡會覺得很驚訝也不一定。不過，我們對於這種劃分民眾身份，並且讓使用者感到無助的體系還能說什麼？覺得我們想法令人訝異的讀者，或許以為專有軟體社會體系是個已知事實，或是根據專有軟體事業所推動的規則做出判斷。軟體發行商長久以來一直想盡辦法說服民眾在這個議題上就只能有一種看法。

當軟體發行商論及「行使」其「權利」，或「停止盜版」時，他們所講的這些話術是次要議題。這些論述的真正意涵是，在他們視為理所當然的未明說假設中，大眾只須要接受但不必理解。所以，請讓我們幫忙理清這一切。

第一個假設是，軟體公司對於自家軟體有一種不可質疑的自然權利，他們因而擁有支配所有軟體使用者的權力。（如果這真有個什麼自然權利，那麼無論這個權利對於民眾會造成多嚴重的傷害，我們都不能拒絕。）有趣的是，美國憲法與法律傳統觀點否認這種看法；著作權不是自然權利，而是政府賦予的人為壟斷權，可以限制使用者的自然權利使其不得複製。

另一個未明說的假設是，對軟體來說最重要的事情是它能讓你做些什麼——我們電腦使用者不應該在意我們能擁有什麼樣的社會型態。

第三個假設是，如果我們不給這些公司支配程式使用者的權力，那麼我們就不會有好用的軟體（或是永遠不會有這種功能的程式，或是可以辦到那些事情的程式）。這個假設看起來說得好像跟真的一樣，但是早在自由軟體運動開始之前，我們社會中就已經有很多好用的軟體但都沒有這些束縛的枷鎖。

如果我們拒絕接受這些假設，並且根據原來的常識性道德觀把這些使用者放在優先地位來判斷時，我們發現結論大不相同。電腦使用者應該能自由修改程式以符合自身需求、並自由分享軟體，因為幫助他人是社會存在的基礎。

這裡如果詳細敘述結論背後的演繹過程會讓篇幅過長，所以我在此請各位讀者前往 http://www.gnu.org/philosophy/why-free.html 和 http://www.gnu.org/philosophy/free-software-even-more-important.html 網頁探究。

嚴酷的道德抉擇

隨著我的社群消失，想一如往常不再可能。所以，我面對嚴酷的道德抉擇。

最簡單的選擇，就是加入專有軟體世界，簽下不揭露協議並保證我不會再幫助黑客同袍。這樣我大概也會開發必須保密不能揭露的軟體，然後對其他人施加壓力讓他們一起背叛同袍。

我可以這樣賺錢，或許也可寫程式自娛。但是我知道，一旦我職業生涯結束，再回過頭去看我那些年修築了高牆以便劃分人群，就會感受到我花了大把人生將世界變成一個更糟糕的地方。

我已體驗過身為不揭露條款終端接受方的經歷，有人拒絕將我們實驗室印表機的控制程式源始碼交給我或 MIT AI Lab。（這個控制程式缺乏某些功能，導致我們使用這臺印表機時遭受極大挫折。）所以我無法告訴我自己說保密條款是無辜的。我非常生氣他拒絕和我們分享；我無法就這樣轉過身去，然後對其他人做出一樣的事情。

另一種選擇，很直截了當但令人不開心，就是離開電腦界。這樣做我的技術能力就不會被濫用，但這些才能就無端浪費掉了。我雖然不會因為劃分和限制電腦使用者而感到罪惡，但這些事卻不會因為我不做而就此停止。

所以我開始探尋程式設計師能對這個議題做些什麼好事。我問我自己，是不是有我能寫的程式？不管是一個還是很多個，如此得以讓社群有機會再次復興。

答案很清楚：我們首先需要一套作業系統。作業系統是人們開始使用電腦的重大軟體。有了作業系統，你可以做很多事情；沒有作業系統，你就幾乎無法操作電腦。有了自由的作業系統，我們可以再次形成互助合作的黑客社群——並邀請任何人加入。此外，任何人都可以使用電腦，不會因為要用電腦而讓他或她的朋友在暗中離去。

身為作業系統開發者，我對這項工作有對應的技術能力。所以即便我無法將成功視為理所當然，我仍確知這項工作我適合出任。我選擇讓系統和 Unix 相容以便具有可攜性，如此 Unix 使用者就能輕鬆轉換過來。GNU 的命名遵循黑客傳統：遞迴式頭文字縮寫，代表「GNU's Not Unix」，意思是「GNU 並非 Unix」；它的英語發音為實唸出 g 子音的單音節字，華語（漢語官話）發音類似「革奴」。

一套作業系統可不只是一個內核心 (kernel) 而已，那樣幾乎沒有什麼其他程式可以跑。1970年代，每個值得一提的作業系統都有指令處理器（外表殼，shell）、組譯器、編譯器、直譯器、除錯器、文字編輯器、郵件程式……等等。ITS 有、Multics 有、VMS 也有、Unix 也一樣都有。GNU 作業系統也會收錄這些軟體。

後來我聽到希列爾長者 (Hillel) 所留下的這席話 (1)：

如果我不為我，誰來為我？
如果我只為我，我又是誰？
如果不是現在，更待何時？

發起 GNU 專案的決定基於類似的精神。

(1) 身為無神論者，我不跟隨任何宗教領袖，但我偶爾會欣賞他們之中所說的一些話。

如 Freedom 般自由

「自由軟體」有時候會被誤解——它跟價格一點也沒有關係。自由軟體講求的是自由。所以，在此附上自由軟體的定義。

對你，一位特定使用者，程式只有在滿足下列條件時才是自由軟體：

因為自由軟體英文 free software 中的「free」指的是自由，不是價格免費，所以銷售軟體副本這件事和自由軟體之間沒有任何衝突。事實上，銷售軟體副本的自由很關鍵：販賣自由軟體集合的 CD 光碟對社群相當重要，而銷售這些光碟也是募集自由軟體開發資金的重要方式。因此，那些人們無法自由納入這類大集合中的程式就不是自由軟體。

由於「free」英文帶有歧義，有些人一直在尋找替代用詞，但都沒有找到更好的。英語這個語言比起他者有更多單字和重音上的細微差別，但缺少只講述「freedom」自由意涵的簡單、不模糊單字——而「unfettered」無拘無束，則是最接近這個概念的單字。其他字詞如「liberated」、「freedom」和「open」這些，不是意義上有差別，就是有其他不足之處。

GNU 軟體與 GNU 系統

要開發出一套完整的系統可說是非常大的專案。為了讓目標更為可行，我決定一旦有可用的對應自由軟體，就調整這些軟體並使用之。舉例來說，我一開始就決定採用 TeX 作為主要的文書格式處理器；幾年過後，我決定採納 X 視窗系統而非另外為 GNU 撰寫其他視窗系統。

基於前述這些決定，還有其他等等這類的決定，GNU 系統不等同於所有 GNU 軟體的集合體。GNU 系統亦包含非 GNU 軟體，那些其他人或其他專案為了自身目的而開發的程式，但因為它們是自由軟體，我們便得以採用。

展開專案

1984年1月，我辭去 MIT 的工作並且開始寫 GNU 軟體。我必須離開 MIT，這樣 MIT 才無法干預我將 GNU 以自由軟體的形式散布出去。如果我還是 MIT 的員工，那麼 MIT 可以宣稱擁有我的工作成果，並施予他們自己的散布條款，或者甚至將成品轉為專有軟體也不一定。我不想要在做出大量勞力之後，看見成果在我期許的用途上變得一點用處也沒有，而這個期許就是：建立新的軟體分享社群。

不過，後來擔任 MIT AI 實驗室主任的 Winston 教授，仍親切地邀請我繼續使用實驗室的設備。

最早的路

在 GNU 專案開始不久後，我聽說自由大學 (Free University) 有套編譯器工具組 (Compiller Kit)，它也被稱為 VUCK。（「自由」的荷蘭語以 v 開頭。）這套工具組的設計可以處理許多語言，包括 C 和 Pascal，而且也支援多種目標機器。於是我寫了封信向作者詢問 GNU 是否能夠使用。

他嘲笑似地回覆說，雖然大學很自由，但編譯器不是。我因而下定決心，第一個要為 GNU 專案而寫的程式就是支援多語言、多平臺的編譯器。

我希望不必自己寫出整個編譯器，所以取得了 Pastel 編譯器的源始碼。Pastel 編譯器是個多平臺的編譯器，由 Lawrence Livermore 實驗室開發；它支援設計成系統型程式設計語言的擴充版 Pascal，並且也以該語言寫成。我加入了 C 前端，並且開始移植到 Motorola 68000 電腦上。但我後來發現這個編譯器需要好幾 MB 的堆疊空間時只能放棄，因為當年現有的 68000 Unix 系統只允許 64k 的空間而已。

我接著瞭解到 Pastel 編譯器的處理方式是將整分輸入檔先解析成語法樹，然後將整個語法樹轉換為「指令」鏈，接著生成整分輸出檔，整個過程從未釋放任何儲存空間。就這樣看來，結論是我必須從頭開始寫一個新的編譯器。這個新編譯器現在稱作 GCC，裡面沒有用到 Pastel 編譯器的任何部份，不過有我之前對 Pastel 編譯器所寫的 C 前端再設法修改過來的部份。但那是好幾年後才發生的事；在那之前，我先做了 GNU Emacs。

GNU Emacs

在1984年9月之時我開始做 GNU Emacs，直到1985年初，程式終於開始能用。有了 Emacs 後，我就能開始用 Unix 系統作編輯；因為我對於學習怎麼使用 vi 或 ed 一點興趣也沒有，所以在這之前我都是用其他機器編輯的。

此時，人們開始想要使用 GNU Emacs，所以問題來了，我要怎樣散布？當然，我把它放到我使用的 MIT 電腦的匿名 FTP 伺服器上。（這臺電腦，prep.ai.mit.edu，因而成為 GNU 的主要 ftp 散布站；電腦幾年後退役了，我們便將名稱轉到我們的新 ftp 伺服器上。）但是在當時，許多有興趣的人都無法連上網際網路，所以不能從 FTP 取得軟體副本。所以問題是，我要對他們說些什麼？

我可以這樣說：「去找個能上網的朋友，看他要不要幫你拷貝個軟體副本。」或者，我可以用我之前對原來 PDP-10 Emacs 所做的方法，告訴他們說：「寄給我一個磁帶並附上回郵信封，我會把 Emacs 放進去然後寄回。」但我當時沒有工作，所以我也在找方法利用自由軟體賺錢。我宣布我會郵寄磁帶給想要軟體的人，一次收費150美金。就這樣，我開啟了自由軟體的散布業務，成為今日散布整套 GNU/Linux 系統散布版的公司的始祖。

是不是每個人拿到的程式都是自由軟體？

如果有個程式是自由軟體，當它離開作者手中之後，不代表它必須對任何擁有副本的人都是自由軟體。舉例而言，公版軟體（沒有受到著作權保護的軟體）是自由軟體，但是任何人都可以拿它修改成專有軟體。和這相似，許多自由軟體受到著作權保護，但是用簡單的寬容式授權條款散布，而這種散布條款允許改作版本是專有軟體。

這個問題的經典案例是 X 視窗系統。它是 MIT 開發的，並且是用寬容式授權條款發行的自由軟體，它一下子就被各家電腦公司採用。他們把 X 加到自家的專有 Unix 系統上，只提供二進位形式，並且用同樣不可揭露的授權條款保護起來。這些 X 的副本就和 Unix 一樣不再是自由軟體。

X 視窗系統的開發者不認為這是個問題——他們預期這類事情的發生，而且刻意這樣做。他們的目標不是自由，只是「成功」，定義為：「擁有很多使用者」。他們不在意到底這群使用者有沒有自由，只在意使用者有沒有很多。

這讓情況變得很吊詭。當有人問說：「這個程式自由嗎？」，答案卻有所不同，因為有兩種不同的自由度計算法。如果你是根據 MIT 發行的散布條款所提供的自由度來判斷，你會說 X 是自由軟體。但如果你是用一般 X 使用者的角度來評量自由度的話，那麼你會說它是專有軟體。而大多數 X 使用者所運行的，都是 Unix 系統隨附的專有版本，不是自由的版本。

著作傳 (Copyleft) 和 GNU GPL

GNU 的目標是要給予使用者自由，不只是廣受歡迎而已。所以我們需要利用散布條款來防止 GNU 軟體被轉為專有軟體。這個方法我們稱為「著作傳（唸作ㄔㄨㄢˊ）」，英文為「Copyleft」。(1)

著作傳使用著作權法，但是以相反於常見作法的方式使用之：並非限制程式的利用，而是維持程式的自由。

著作傳的中心思想是我們給予任何人執行程式、複製程式、修改程式、散布修改後版本的權利——但不允許自行對程式加入限制。所以，「自由軟體」定義的關鍵：自由，任何人只要取得軟體副本都能得到保障；自由成為軟體不可分割的權利。

一份有效的著作傳式授權條款，必須維持修改後版本仍保有自由。這樣就能確保那些根據我們作品改作而成的新作，在公開發表之後得以讓我們社群取用。如果有工作的程式設計師願意以志工身分改善 GNU 軟體時，著作傳也能防止他們的僱主說：「你不可以分享那些修改，因為我們要把它作為我們自己專有的軟體版本」。

如果我們希望確保程式的每個使用者都能得到自由，那麼修改內容必須維持自由的要求是必須的。將 X 視窗系統納為私有的公司，通常是做出改動以便移植到他們家的系統與硬體上。這些更改之處和 X 源始碼的廣大範圍相比之下很少量，但不是瑣碎不重要。如果做出更動是拒絕給予使用者自由的藉口，那麼任何人都能輕鬆利用這個藉口。

另一個相關議題是，自由軟體和非自由軟體源始碼間的結合。這樣的結合無可避免會不自由；非自由的部份所缺少的自由，就整體觀點來看依然缺失自由。如果授權條款允許這類結合，那麼無疑是在船上開個足以沉船的大洞。所以，著作傳的關鍵要求就是要塞住這個洞：任何附加到著作傳保護程式上、或是和著作傳保護程式相結合的任何東西，都必須得讓較大的結合後版本依然維持自由、受著作傳保護。

我們為大多數 GNU 軟體使用的特定著作傳式授權實作，是 GNU 通用公眾授權 (GNU General Public License)，或簡稱 GNU GPL。我們也有用於其他特定情況的不同類型著作傳式授權。GNU 手冊也一樣受到著作傳保護，但用的是更為簡單的著作傳式授權，因為 GNU GPL 很複雜這對於手冊這類著作來說沒有必要。(2)

(1) 在1984年或1985年的時候，Don Hopkins（一位很有想像力的同袍）曾寄給我一封信。在信封上他寫下好幾句有趣的話，其中一句是：「著作傳——保留所有權利。」（原文為 「Copyleft—all rights reversed.」）。我便採用「著作傳」命名我當時發展的散布概念。

(2) 我們的文件現在使用 GNU 自由文件授權 (Free Documentation License)。

自由軟體基金會

隨著有興趣使用 Emacs 的人逐漸增加，其他人也開始參與 GNU 專案，而我們決定是時候再次尋求資助了。所以在1985年我們成立了自由軟體基金會 (Free Software Foundation，簡稱 FSF)，做自由軟體開發的免稅慈善機構。FSF 也接手了 Emacs 磁帶的散布事業；後來更為擴展將其他自由軟體（包括 GNU 和非 GNU）加到磁帶業務中，也一併銷售手冊。

當年 FSF 的大多數收入來自自由軟體副本的銷售和相關服務（源始碼 CD、二進位檔 CD、印刷精美的手冊等，全都可以自由地再次散布和修改），還有豪華散布版（我們為顧客所選擇的平臺組建而成的全軟體集合散布版）。今日 FSF 仍然銷售手冊和其他物品，但主要資金來源是會員的會費。你可以前往 fsf.org 加入自由軟體基金會的會員。

自由軟體基金會的僱員撰寫和維護許多 GNU 軟體包。其中最著名的兩個分別是 C 函式庫和外表殼 (shell)。GNU/Linux 系統上運行的每個程式透過 GNU C 函式庫和 Linux 溝通，它是由自由軟體基金會員工之一的 Roland McGrath 所開發。而大多數 GNU/Linux 系統所使用的外表殼是 BASH，全名 Bourne Again Shell(1)，則是由基金會員工 Brian Fox 所開發。

我們資助這些程式的開發，因為 GNU 專案可不只是提供工具或開發環境而已。我們的目標是打造出完整的作業系統，而我們需要這些程式才能達到這個目標。

(1)「Bourne Again Shell」是對「Bourne Shell」作的文字遊戲，Bourne Shell 是 Unix 上常見的外表殼。

自由軟體支援服務

自由軟體理念思想反對特定的普遍商業作法，但不是反對商業。只要商業公司能尊重使用者的自由，我們便祝福他們成功。

銷售 Emacs 副本是自由軟體事業的作法之一。當 FSF 接手這項業務之後，我得找出其他討生活的方法。我發現可以銷售我之前開發的自由軟體的相關服務。這類業務包括教學，例如 GNU Emacs 程式是怎樣設計的、怎樣客製 GCC 等主題，還有軟體開發等，大多是希望將 GCC 移植到新平臺上。

今日有許多企業行號採用這些自由軟體的各種業務作法。有的透過 CD 散布自由軟體集合；也有的銷售支援服務，範圍包括回答使用者問題、修正臭蟲、添加重大新功能等。我們甚至開始看到有些自由軟體公司是因為要發展新的自由軟體產品而成立。

不過，要小心——有許多公司把自己和「開源」或「Open Source」這個詞彙關聯在一起，但實際上他們的業務著重於能配合自由軟體運作的非自由軟體。這些公司不是自由軟體公司，他們是專有軟體公司，他們的產品是要引誘使用者離開自由。他們稱呼這些程式為「加值軟體包」，表達他們希望大家採納的價值觀：方便，比起自由更重要。如果我們更注重自由，我們應該稱呼這些程式為「刪減自由」軟體包。

技術目標

GNU 的主要目標是自由軟體。就算 GNU 比起 Unix 而言沒有任何技術上的優勢，也會有社會上的優勢：能讓使用者之間互助合作；還有道德上的優勢：尊重使用者的自由。

但是將眾所皆知的良好實務標準套用到我們的工作上也是很自然的事——舉例而言，採用動態配置資料結構避免武斷固定大小的限制，以及只要合理之處就盡可能處理所有的 8 位元代碼等。

此外，我們放棄了 Unix 專注於小型記憶體大小的作法，決定不要支援 16 位元的機器（當時很清楚 32 位元在 GNU 系統完成之時將會是常態），並只有在記憶體用量超過 MB 時才會不遺餘力降低它。在那些不大需要處理極大型檔案的程式中，我們仍鼓勵程式設計師讀取整分輸入檔到核心中，接著掃描內容不要擔心 I/O 問題。

這些決定使得許多 GNU 程式在可靠性和速度上勝過它們在 Unix 上的競爭對手。

捐贈的電腦

隨著 GNU 專案的名聲慢慢大起來，人們開始將跑著 Unix 的電腦捐贈給專案使用。這些捐贈非常有用，因為開發 GNU 組件的最簡單方法就是在 Unix 上開發，接著一個一個替換掉系統上的組件。但是這引發一項道德議題：我們到底應不應該擁有 Unix 系統的副本。

Unix 是專有軟體，而 GNU 專案的哲學理念說過我們不應使用專有軟體。但是，如果我們套用「自我防衛而使用暴力合乎正義」的演繹推理過程，我的結論是：因為要開發自由版替代品以協助他人停止使用專有軟體，所以必須使用專有軟體的情況合乎情理。

但是，即便這是合乎正義的邪惡，它依然是種邪惡。今日我們不再保有任何 Unix 系統副本，因為我們已經能用自由的作業系統取代。如果我們無法以自由的作業系統取代機器上的作業系統，那我們會改為撤換那臺機器。

GNU 工作列表

隨著 GNU 專案繼續發展，可用的和有人開發的系統組件數量逐漸增加，如果能有一份清單列出欠缺的組件名單會很有用。我們利用這份清單募集開發者撰寫缺失的拼圖一角。這份清單後來被熟知為「GNU 工作列表」。除了缺少的 Unix 組件之外，我們也在清單中列出其他各種好用的軟體和文件專案，所有我們認為真正完善的系統應該具備的一切。

今日 (1)，GNU 工作列表中已經幾乎沒有什麼 Unix 組件——那部份的工作已經完成，只剩下幾個不見得必要的組件。但是這份清單充滿許多有些人稱為「應用程式」的專案。只要能吸引到小族群使用者人數以上的程式都是加入作業系統中的好東西。

甚至遊戲都列在工作列表之中——從列表創立之初就包在裡面。Unix 包含遊戲，所以自然而然 GNU 應該也要有。但是對遊戲來說，能不能在 GNU 上也有得玩不是個議題，所以我們沒有遵循 Unix 上有的遊戲列表。反之，我們列出許多使用者可能會喜歡的不同種類遊戲名單。

(1) 時間點為1998年。到了2009年，我們已不再維護這樣一份冗長的工作列表。社群開發自由軟體的速度之快以至於我們無法跟得上記錄的腳步。我們改為維護「高優先專案」列表，一份我們非常想要鼓勵人們撰寫的專案名單，長度較短。

GNU 函式庫 GPL

GNU C 函式庫使用一種特殊的著作傳式授權，稱為 GNU 函式庫通用公眾授權 (1)，允許專有軟體和函式庫連結。為什麼要有這條例外條款？

這無關原則；我們沒有原則說要賦予專有軟體產品收納我們程式碼的資格。（那為什麼要貢獻那些預期會拒絕和我們分享的專案？）讓 C 函式庫使用 LGPL，或是讓任何函式庫使用 LGPL，是個策略問題。

C 函式庫的用途很廣；每套專有系統或編譯器都隨附 C 函式庫。因此，只給自由軟體使用我們的 C 函式庫，並不會為自由軟體生態帶來任何優勢——只會讓人不願使用我們的函式庫。

唯有一套系統是個例外：GNU 系統（包括 GNU/Linux），而 GNU C 函式庫是它唯一的 C 函式庫。所以 GNU C 函式庫的散布條款能決定是否可以在 GNU 系統上編譯專有軟體。允許 GNU 系統上有專有軟體不合道德，但是就策略面而言禁止專有軟體似乎反而阻礙人們使用 GNU 系統，鼓勵不到自由軟體的開發。那就是為什麼使用 LGPL 對於 C 函式庫而言是個好策略。

至於其他函式庫，決策需要根據各個案例的不同之處加以考慮。當某個函式庫對於協助撰寫某類程式有特殊作用時，那麼可以將它以 GPL 發行，限制只能讓自由軟體取用，如此就能協助其他自由軟體開發者，讓他們有優勢對抗專有軟體。

說到 GNU Readline，那是一套開發來提供 BASH 作指令列編輯的函式庫。Readline 是以原本的 GNU GPL 授權發行，而非函式庫 GPL。這樣可能確實減少 Readline 被使用的次數，但對我們來說沒有什麼損失。目前，至少有個好用的應用程式因為要利用 Readline 而特地做成自由軟體，那真是社群的一大收穫。

專有軟體的開發者有金錢給予的優勢；而自由軟體開發者需要為彼此創造優勢。我希望有一天我們會有許許多多受 GPL 保護、無法和專有軟體平行運作的函式庫，能一同提供好用的模組作為建構新自由軟體的磚塊，全部加總起來成為更巨大的優勢以利自由軟體向前發展。

(1) 這個授權條款目前已經改稱為 GNU 寬鬆通用公眾授權 (Lesser General Public License)，避免造成所有函式庫都該使用這個授權條款的想法。請參閱為何你不應該讓你下個函式庫使用 LGPL 深入瞭解更多資訊。

搔個癢？

艾力克・雷蒙 (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 還未有的組件。

GNU Hurd

到了1990年，GNU 系統幾近完成；唯一缺少的重要組件是內核心。我們決定要將我們的內核心實作成跑在 Mach 上的伺服器程序集合。Mach 是先在卡內基梅隆大學 (Carnegie Mellon University) 開發，後來在猶他大學 (University of Utah) 開發的微核心 (microkernel)；而 GNU Hurd 是跑在 Mach 上的一群伺服器（解釋：如果要說一群 GNU 的話，因為 gnu 是牛羚，所以英語要講 a herd of GNUs，而 Hurd 正好和 herd 同音），能執行 Unix 內核心的許多工作。開發的啟動有所延遲，因為我們在等 Mach 採自由軟體授權發行，這件事他們先前有承諾過。

選擇這樣設計的其中一個原因是，希望避開工作中看起來最艱難的部份：在沒有來源階段除錯器 (source-level debugger) 的幫助下為內核心程式除錯。這部份的工作在 Mach 中已經完成，所以我們打算以使用者層級程式的方法對 Hurd 伺服器用 GDB 除錯。但這卻花上很長一段時間才逐漸行得通，多執行序的伺服器彼此間傳送訊息反而讓除錯變得極為困難。我們耗費很多年的時間才讓 Hurd 能穩固地運作。

Alix

GNU 的內核心起初沒有打算叫作 Hurd。最早的名字是 Alix——當時我最心愛的女人。Alix 是一位 Unix 系統管理員，她曾提過自己的名字剛好很合 Unix 系統版本的常見命名規則；她以說笑話的方式向朋友們說：「真該有人用我的名字幫核心命名的。」我什麼話也沒說，只是下定決心要做一個名為 Alix 的內核心來給她驚喜。

好景不常。Michael Bushnell（現在改名 Thomas），內核心的主要開發者，更偏好 Hurd 這個名稱，然後把 Alix 重新定義為內核心的其中一部分——捕捉系統呼叫並傳送訊息給 Hurd 伺服器來處理它們的這部分。

後來，Alix 和我分手，她還改了名字；另外，Hurd 設計也改了，C 函式庫會直接傳訊息給伺服器，所以 Alix 組件也從設計中消失了。

而在這些事發生之前，Alix 的其中一位朋友曾偶然發現 Hurd 源始碼中有個 Alix，所以跟她提過這件事。因此，她確實因緣際會知道曾有個內核心是用她的名字命名的。

Linux 和 GNU/Linux

GNU Hurd 不適合一般工作生產使用，我們也不知道它到底能不能走到那步。以能力為基礎的設計反而因為設計的彈性而造成直接問題，我們也不清楚到底有沒有個解決方案。

幸好，還有另一個內核心。1991年林納思・托瓦茲 (Linux Torvalds) 開發了一個 Unix 相容的內核心，稱之為 Linux。一開始它是專有軟體，不過在1992年時改為自由軟體；如果我們把 Linux 和沒那麼完整的 GNU 系統結合在一起，就成了一套完整的自由作業系統。（當然，把它們搭在一起本身也是個很重要的工作。）因為有了 Linux，我們今日才得以真正運行一套 GNU 系統。

我們將這樣的系統版本稱為 GNU/Linux，表達這是個 GNU 系統和 Linux 內核心的結合成果。請不要與世推移跟著把整套系統稱為「Linux」，因為這種講法表示把我們的工作成果全都歸功在別人名下。請平等提及我們的貢獻。

我們未來的挑戰

我們已經證明我們有能力開發廣泛的自由軟體。這不表示我們勢不可擋而且無人能敵。還有許多挑戰讓自由軟體的未來不明朗；要達成這些挑戰須要恆心和毅力，有時得持續很多年。這需要大家展現出那種珍重自由、不願讓任何人奪走的決心。

下面四個小節討論將分別探討這些挑戰。

祕密硬體

硬體製造商越來越傾向讓硬體規格成為機密。這使得要撰寫出自由驅動程式好讓 Linux 和 XFree86 能支援新硬體變得更為困難。雖然我們今日已經有完整的自由系統，但只要我們無法支援明日的電腦，我們明日就無法擁有完整的自由系統。

有兩種處理這類問題的辦法。程式設計師可以逆向工程以理解該如何支援這個硬體。剩下的我們，則可以選擇自由軟體能支援的硬體；只要我們的人數增加，祕密規格就成了自我毀滅的策略。

逆向工程是個大工程；我們有決心堅定的程式設計師來承擔這些事嗎？有的——只要我們能建造出自由軟體是行事準則、非自由的驅動程式無法容許的強烈感受。那麼我們之中會有許多人願意多花一些錢，或甚至多花一點時間，來讓我們可以使用自由的驅動程式嗎？會的，只要保有自由的決心能夠廣泛傳播。

（2008年註：這個議題也延伸到 BIOS。有個自由的 BIOS，LibreBoot（coreboot 的散布版）；問題在於要取得機器的規格，如此 LibreBoot 才得以支援這些設備而不必用到非自由的「Blob」）

非自由函式庫

在自由作業系統上運行的非自由函式庫是個為自由軟體開發者設計的圈套。函式庫的迷人特性是誘餌；如果你用了這套函式庫，你就掉進圈套裡，因為你的程式無法有用地成為自由作業系統中的一部分。（嚴格來說，我們可以收錄你的程式，但它卻因為缺少函式庫而無法執行。）更糟的是，如果有個採用專有函式庫的程式變得廣受歡迎，還會誘使其他沒料想到問題的程式設計師一起落入圈套中。

這問題的第一個實例是1980年代的 Motif 工具組。雖然那時還沒有自由的作業系統，但很明顯 Motif 會衍生後續問題。GNU 專案以兩個作法回應：邀請各自由軟體專案像支持 Motif 一樣地支持自由的 X Toolkit widget 元件，以及四處詢問是否有人可以撰寫 Motif 的自由替代品。這項工作花了許多年；由 Hungry Programmers 開發的 LessTif，只在1997年就足以成熟支援絕大多數的 Motif 應用程式。

在1996年到1998年之間，另一個叫作 Qt 的非自由 GUI 圖形介面工具組函式庫，則被用於 KDE 桌面這套實用的自由軟體集合中。

自由的 GNU/Linux 系統無法使用 KDE，因為我們無法利用這些函式庫。但是，有些商業型 GNU/Linux 系統的散布商對忠守自由軟體沒那麼嚴謹，便將 KDE 加到他們的系統中——更多功能、但較少自由的系統於焉誕生。KDE 那群人很積極鼓勵程式設計師採用 Qt，而這數百萬個新手「Linux 使用者」也從沒接觸過這樣做會有問題的想法。

自由軟體社群以兩項專案回應：GNOME 與 Harmony。

GNOME，全名為 GNU 網路物件模型環境 (GNU Network Object Model Environment)，是 GNU 的桌面專案。該專案由 Miguel de Icaza 於1997年創立，在 Red Hat 公司的支持之下開發。GNOME 專案試圖提供類似的桌面功能，但是完全採用自由軟體。此外，它還有一些技術上的優點，例如廣泛支援許多語言，不單只有 C++ 而已。不過它的主要重點還是自由：不須要用到任何非自由軟體。

Harmony 是個相容的替代函式庫，設計希望能在不使用 Qt 的情況下執行 KDE 軟體。

1998年11月時，Qt 的開發者宣布更動授權條款，實現之後應該能讓 Qt 變成自由軟體。雖然我們沒有辦法確定，不過我相信這件事有部份受到社群對 Qt 非自由的問題做出堅強回應的影響。（新授權條款不方便而且不平等，所以能避免使用 Qt 的話還是比較好。）

[後記：2000年9月，Qt 以 GNU GPL 授權重新發行，明確解決了前述這些問題。]

如果下個誘人的非自由函式庫出現時我們該如何因應？整個社群會明瞭跳脫圈套的必要性嗎？或是我們之中有許多人願意捨棄自由將就方便，最終產生更遠大的問題？我們的未來取決於我們的理念思想。

軟體專利

我們所面對的最可怕威脅來自軟體專利。軟體專利能限制自由軟體不能實作某些演算法和功能，時間長達 20 年之久。LZW 壓縮演算法於1983年申請到專利，但我們仍然不能發行可製作適當壓縮的 GIF 圖片檔的自由軟體。[直到2009年所有相關專利才全數過期。] 在1998年時，有個能製作 MP3 壓縮音訊的自由程式因為受到專利訴訟威脅而從散布版中移除。[直到2017年，這些專利才全數過期，看我們到底等了多久。]

有一些辦法可以處理專利：我們可以搜尋專利無效的證據，我們也可以改尋求其他方式來完成同件事情。但是這些方法不見得每次都管用；有些時候這兩種方法都辦不到，專利可迫使所有自由軟體都欠缺某些使用者想要的功能。在長時間等待後，專利終於過期，但那時候我們能做些什麼？

我們之中因為自由的價值而重視自由軟體的人，無論如何都會願意留下來和自由軟體待在一起；我們會努力設法在缺少專利功能的情況下完成事情。但那些認為自由軟體在技術上較進步而偏好自由軟體的人，在專利拖住自由軟體發展之時卻會說這是自由軟體的失敗。所以，雖然談論「市集」開發模型在實務上很有效、以及說有些自由軟體很穩定很有力的觀點等，對於推動自由軟體很有用處，但我們不該就停在那裡。我們必須進一步談論自由和原則問題。

自由文件

我們的自由作業系統最缺乏的一部分不是軟體——真正缺乏的是能收錄到我們系統中的優質自由手冊。文件是任何軟體包必要的一部分；當重要的自由軟體包沒有隨附良好的自由手冊時，那是一塊大缺陷。我們今日還有許多這樣子的缺陷。

自由文件，好比自由軟體，同樣關乎自由，而非價格。自由文件的判斷準則約略與自由軟體相同：給予所有使用者特定的自由。必須允許再次散布（包含商業銷售），無論媒體採用線上或紙本，如此手冊便得以伴隨程式副本。

允許修改也很關鍵。至於常理，我認為人們不一定得有權修改所有種類的文章和書籍。例如，我認為你或我都不應當有權利修改和本文相同類型的文章，因為本篇文章描述的是我們的動作行為和我們的想法觀點。

但自由軟體的文件必須可以自由修改有個特別原因。當人們行使其權利修改軟體，加入或更動軟體功能，如果他們一併對手冊的刪改下苦心——就能為修改後的程式提供準確且有用的文件。若是非自由的手冊，便不允許程式設計師費此用心完成作業，也就無法滿足我們社群所需。

有些禁止修改的限制不會造成什麼問題。例如，要求保留原始作者的著作權聲明、散布條款、或是作者名單，這些都合理。要求修改後版本納入聲明表示該作品有經過修改一樣沒有問題，甚至是要求不可以刪除或修改某整個段落也相同，只要這些段落講的是非技術相關主題就行。這些限制不成問題，因為它們無法阻止用心的程式設計師把手冊編修得更符合修改後的程式版本。換句話說，這些限制無法阻止自由軟體社群完整利用這份手冊。

然而，必須要可以修改手冊中所有關於技術 的內容，並且能接著將成果載於所有常見媒體、透過所有尋常管道散布；否則，這類限制確實會阻礙社群，這樣一來這份手冊就不自由，我們需要撰寫其他手冊。

自由軟體開發者是否能覺知到自由手冊，並且有決心製作出全面的自由手冊呢？再一次，我們的未來取決於我們的理念思想。

我們必須談論自由

今日估計約有上千萬人使用 GNU/Linux 系統，例如 Debian GNU/Linux 和 Red Hat「Linux」。自由軟體已發展出實務上的優勢，讓使用者們純粹基於實務因素群集至此。

這件事帶來的好處很明顯：有越多人對開發自由軟體有興趣，就有越多顧客會尋求自由軟體業務，也更能鼓勵公司開發商業的自由軟體而非專有軟體產品。

但是對自由軟體產生興趣的速度，遠比體認到自由軟體的理念思想還快，而這將招致禍害。要知道我們面對上述挑戰與對抗威脅的能力，取決於我們願意為自由挺身而出的堅定意志。若要確使我們的社群能有這樣的意志，我們必須將理念散播給剛來到社群中的使用者知道。

但是我們越來越難辦到：吸引新使用者進入我們社群所下的功夫，遠勝於向他們教導我們社群的公民學所費的苦工。我們需要兩者兼為，而且我們要在兩者所做的努力間維持平衡。

「開源」

1998年，要教育新使用者有關自由之事變得更加困難，因為社群有一部分人決定停止使用「自由軟體」這個詞語，改說成「開源軟體」(open source software)。

有些人喜歡用這個詞，主要是因為英語中的「free」也有「免費」的含意，所以想避免混淆——很有道理。其他人，不一樣，他們希望把驅使自由軟體和 GNU 專案發展的原則精神丟在一旁，然後用這個詞語去吸引執行長、企業用戶等，而這群人大多有著：利益高於自由、高於社群、高於原則的想法。所以，「開源」這個巧辯詞聚焦在產出高品質、強大軟體的可能性上，但是迴避自由、社群、原則這些想法。

各種「Linux」雜誌就是明確的範例——書中充斥著能在 GNU/Linux 上運作的專有軟體廣告。如果有下一個 Motif 或是 Qt 出現，這些雜誌難道會警告程式設計師該遠離它嗎？還是會幫它打廣告？

商業支持確實對社群有各種貢獻；商業以外的其餘貢獻也相同，都很有用。但如果要讓我們減少談論自由與原則來贏得商業支持會是個災難；這使得先前社群的拓展與公民學教育之間的不平衡變得更為傾斜。

「自由軟體」和「開源軟體」描述的是差不多相同類別的軟體，但講的是軟體的不同特點、和不同的價值觀。GNU 專案持續使用「自由軟體」一詞來傳達自由的想法，不只是技術上的作法，這很重要。

嘗試！

尤達大師的格言（「沒有所謂『嘗試』」，原文為「There is no “try”」）聽起來乾淨俐落，但對我來說不太管用。我大部分在做事的時候都還對我到底能不能完成這項工作而焦慮，而且也不確定是否由我來做的話成果足不足以達成目標。但不管怎樣我都還是試了，因為沒有人站在敵人和我的城市之間，其中就只有我而已。我自己也很驚訝，有的時候我成功了。

而有時候我失敗了，我有的城市淪陷了。接著我發現另一座城市遭受威脅，所以得趕快準備下一場戰鬥。隨著時間過去，我學會尋找威脅，並挺身走到敵人與我的城市之間，呼叫其他黑客前來和我一起聯手。

時至今日，我常不是唯一的那一位。每當我看見一群黑客挖掘壕溝嚴守陣線之時，便鬆了一口氣並有股喜悅油然而生，我於是領悟，這座城市保得住——此時此刻。但一年一年過去危險也越來越大，現在微軟已明確鎖定我們社群。我們不能將未來的自由視為理所當然。別視為理所當然！如果你想要保住你的自由，你必須準備起身抵抗。