![[image of What's GNU]](/graphics/whats-gnu-sm.jpg)
[
捷克语
| 简体中文
| 繁体中文
| 英语
| 法语
| 印度尼西亚语
| 意大利语
| 朝鲜语
| 俄罗斯语
| 西班牙语
]
最初发表在 "Open Sources" 这本书
[
捷克语
| 简体中文
| 繁体中文
| 英语
| 法语
| 印度尼西亚语
| 意大利语
| 朝鲜语
| 俄罗斯语
| 西班牙语
]
当我於一九七一年开始为麻省理工学院（MIT）人工智能实验室工作时，我成为那时已经存在多年的一个软件共享社团的成员。软件的共享其实并不局限於我们的特定社团；它与计算机是同龄的，如同食谱的共享与烹调同样悠久一样。但是我们比大多数人做的更多。
人工智能实验室使用一个名叫 ITS（不兼容分时系统）的分时操作系统，它是由实验室员工电脑黑客们 (1) 为当年的一种大计算机数位 PDP-1 设计并用汇编语言编写的。作为社团的一个成员，人工智能实验室的一个员工电脑系统黑客，我的工作是来改进这个系统。
我们没有称我们的软件为「自由软件」，因为这个术语当时还不存在；但我们的软件的确是「自由软件」。不论何时，当来自其他大学或公司的人想要移植或使用程序时，我们都乐於提供。如果你看到某人正在使用一个你不熟悉但却有趣的程序时，你总可以要求参阅其源码，因此你可以读它、修改它、或者对它加以拆解拼装制成一个新的程序。
(1) 一部分大众传播媒体混淆地将「黑客」一词用来表示「安全破坏者」。我们作为黑客拒绝认可这个含义，并继续用这个词表示「那些喜爱编程并享受在其中变得更擅长於编程的人。」这种情形在一九八○年代初期，当 Digital 公司不再继续其 PDP-10 系列时彻底地改变了。此系列的架构在六○年代著实优雅且有力，但却无法自然地扩充到在八○年代成为可能的较大的定址空间。这意味著几乎所有构成 ITS 的程序都已经被淘汰了。
人工智能实验室黑客社团在不久以前已经崩溃了。一九八一年，抽资脱离的 Symbolics 公司已经从人工智能实验室雇佣走了几乎所有的黑客，人口减少的社团已不能维持其自身。（Steve Levy 所著的《黑客》叙述了这些事件并给出了该社团在鼎盛时的美景。）当人工智能实验室於一九八二年购买一台新的 PDP-10 时，其管理层决定使用 Digital 的非自由分时系统而不是 ITS 。
VAX 或 68020 等当代的现代计算机，拥有其自己的操作系统，但它们均不是自由软件：即使只是获得一个可执行代码拷贝，你也必须签署一个保密协议。
这意味著使用计算机的第一步是承诺不去帮助你的邻居。一个互助的社团被禁止了。私有软件拥有者制定的规则是，「如果你与你的邻居共享，你就是一个侵犯版权者。如果你需要任何更改，求我们来做。」
认为私有软件社会体制 -- 不允许你去共享或改变软件 -- 是反社会的、也是不道德的，并且是完全错误的思想，也许对一些读者来说会产生惊讶。可是我们对於一个建立在分割公众并让使用者无助之上的体制又能够说些什么呢？对上述思想感到惊讶的读者或许将私有社会体制视为理所当然，或者使用私有软件行业暗示的条款来判断它。软件出版者长时间辛苦地努力去使人们信服，只有一种方式来看待这个问题。
当软件出版者谈到「坚持」他们的「权利」或「阻止侵犯版权」时，他们实际所「说」的是次要的。这些声明真正的讯息是他们将未阐明的假设视为理所当然；公众被认为应当无异议地接受这些。还是让我们来仔细检查这些吧。
一个假设就是，软件公司有毫无疑问的自然权利去拥有软件并因而有在其所有用户之上的权利。（如果这是一个自然权利，那么无论它对公众造成多大危害，我们也不能反对。）有趣的是，美国宪法和法律惯例否决这种观点；版权不是一个自然权利，而是一个人为的，政府强加的限制用户复制的自然权利的垄断。
另一个未申明的假设是，关於软件的唯一重要事情是它允许你作些什么工作 -- 我们计算机用户不应该在意我们被允许去拥有哪种社会。
第三个假设是，如果我们不提供软件公司在用户之上的程序的权利，我们将没有可以使用的软件（或，将决不会有一个程序来做这个或那个特定的工作）。这个假设在自由软件运动证明我们能够不必受其束缚而制造丰富的有用软件之前，也许看起来像是有理的。
如果我们拒绝接受这些假设，并基於普通常识下的道德来判断这些问题，当把用户放在首位，我们得到了非常不同的结论。计算机用户应该可以自由地去修改程序以适应他们的需求，并自由地共享软件，因为帮助别人是社会的基础。
这儿没有该结论背后广泛推理的空间，因此读者可参阅下边网页， http://www.gnu.org/philosophy/why-free.html 。
随著我的社团没有了，要像以前那样继续是不可能了。取而代之的情况是，我面对一个赤裸的道德抉择。
加入私有软件世界是较容易的选择，签署保密协议并承诺不去帮助我的黑客伙伴。极有可能我也去开发在保密协议下散布的软件，因而对其他人增加压力迫使他们也去背叛他们的伙伴。
按此方式，我可能已经挣了钱，并或许自己开心地写代码。但是我知道在我的事业终点，我将回望筑墙隔开人们的这些年，会感到我竟投入了我的生命以使这个世界变成更坏的地方。
当有人拒绝给我和 MIT 人工智能实验室有关的我们打印机的控制程序源码时，我已经经历了处在保密协议的接受端。（该程序某些特色的缺少使得打印机的使用极其困难。）因此我不能告诉我自己保密协议是无害的。当他拒绝让我们分享其代码时，我非常生气；我不能够转过身来，然后自己也对每个人做这同样的事情。
另一个直截了当但不愉快的选择，是离开计算机领域。那样的话，我的技术将不会被滥用，但仍会被浪费。我将不会因隔离和限制计算机用户而被指责，虽然如此，这种情形仍然会继续发生。
所以我找寻一个程序员可以做一些好事的方法。我问我自己，有没有一个或一些程序我可以写，进而有可能再次形成一个社团。
答案是清晰的：我们首先需要的是一个操作系统。它是开始使用一台计算机的至关重要的软件。有了操作系统，你可以做很多事情；没有操作系统，你完全不能运行计算机。有了自由操作系统，我们能够再次拥有一个互助的黑客社团 -- 并邀请任何人参加。任何人都能够使用计算机而不必从图谋剥夺他或她的朋友开始。
作为一个操作系统开发者，我有做这个工作的恰当技能。所以即使我不能把成功当作必然，我认识到我被选择来从事这项工作。我选择将该系统做成与 Unix 兼容因而它可被移植，并使 Unix 用户可以容易地转换到它。 GNU 这个名字，依照黑客的传统选中，作为一个递归的「GNU's Not Unix」首字母缩写。
一个操作系统指的不仅仅是一个内核，刚足够运行其他程序。在一九七○年代，每个可以称作操作系统的系统包括命令处理器，汇编程序，编译器，解释程序，调试除错器，文本编辑器，邮件程序，以及其它许多程序。 ITS 、 Multics 、 VMS 和 Unix 都有这些。 GNU 操作系统也将包括它们。
后来我听到希勒尔的这些话 (1)：
我不为我谁为我？ 我只为我我为何？ 若非现在要何时？
决定开始 GNU 工程正是基於一个类似的精神。
(1) 作为一个无神论者，我不跟随任何一个宗教领袖，但我有时候发现我钦佩他们中的一个说过的话。
「自由软件」这个术语有时被错误地理解 -- 它与价格完全无关【在英语中，自由与免费同字（free），因此在自由软体运动中，一般以首字母大写来表自由（Free）】。自由软件是关於自由。因此这里是自由软件的定义：对你，一个特定的用户，一个程序是自由软件，当：
由於 "free" 所指的是自由，而非价格，卖拷贝和自由软件之间并没有矛盾。事实上，贩卖拷贝的自由是至关重要的：以光碟型式卖出的自由软件收藏对於社团是重要的。同时，出售它们是为自由软件发展筹集资金的重要方法。因此，一个人们没有自由将它加入到这些收藏的程序就不是自由软件。
由於「自由」的含糊性，人们用了很长时间找寻其它选择，但是从没有人找到一个合适的选择。英语比其它语言有更多的单词和细微差别，但它缺少一个简单的、明确的单词用来表示「自由」，就像自由自在 -- 「无拘无束的」，使得这个字成为最接近此一含义的单词。诸如「解放的」，「自由自在」和「开放」等其它选择，都要么有错误的含义或一些其它缺点。
开发一个完整系统是一个很大的工程。为了使其达成，我决定只要有可能就去改写并使用现有的自由软件。例如，在最初我决定用 TeX 作为主要的文本格式化程序；一些年后，我决定用 X Window 系统而不是为 GNU 写另一个视窗系统。
由於这项决定， GNU 系统与所有 GNU 软件的堆积不同。 GNU 系统包括非 GNU 软件程序，这些程序是由其他人或工程为了他们自己的目的而开发的。我们之所以能用它们是因为它们是自由软件。
我於一九八四年一月辞去我在 MIT 的工作并开始编写 GNU 软件。离开 MIT 是必要的，这样可以使 MIT 无法干涉将 GNU 作为自由软件而散布。如果我还在职， MIT 也许已经要求拥有这些作品，并可能强加他们自己的发行条款，或将它们变成私有软件包。我没有意图做大量工作而仅仅看到它变得没有用，因为做这件事情的既成目的是：创造一个新的共享软件社团。
尽管如此， Winston 教授，后来的 MIT 人工智能实验室领导人，友善地邀请我继续使用实验室的设施。
开始 GNU 工程的不久之前，我听说了叫做 VUCK 的自由大学编译工具箱。（荷兰单词「自由」，写作为一个字母 V）这是一个设计来处理多种语言的编译器，包括 C 和 Pascal ，并支持多重目标机器。我曾写信给其作者询问 GNU 是否可以使用它。
他嘲弄地回答了，声明该大学是自由的而该编译器不是。因此我决定我的第一个为了 GNU 工程而写的程序将是一个多种语言，多种平台的编译器。
因为希望避免自己编写整个编译器的必要，我得到了在 Lawrence Livermore 实验室开发的多平台编译程序 Pascal 的源码。它支持并且用一种设计成为一个系统编程语言的 Pascal 扩充版本来编写。我加入一个 C 的前端，并开始将它移植到 Motorola 68000 计算机。但是当我发现该编译器需要百万字节的堆栈空间时，我不得不放弃。可用的 68000 Unix 系统仅仅允许 64k 字节。
我随后了解到 Pascal 编译器的运行是，分析整个输入文件成为一个语法树，转换整个语法树成一个「指令」链，然后生成完整的输出文件，而不曾释放任何存储空间。到了这个地步，总结下来我仍必须从头开始写一个新的编译器。那个新的编译器就是现在所知的 GCC；其中没有一点 Pascal 编译器的内容，不过我仍设法改编和使用我已写好的 C 前端。但那是几年后的事了；首先，我开发 GNU Emacs 。
我於一九八四年九月开始著手 GNU Emacs ，它於一九八五年初开始有用。这使得我可以开始使用 Unix 系统作编辑；因为没有兴趣学习使用 vi 或 ed ，直到那时我是在其它类型机器上做我的编辑的。
这时候，人们开始想用 GNU Emacs，因此出现了该如何发行它的问题。当然，我将它放在我用的 MIT 计算机的匿名 FTP 服务器上。（这台计算机， prep.ai.mit.edu ，因此成为主要的 GNU FTP 散布站点；当它一些年后退役时，我们将其名字转到我们新的 FTP 服务器。）但是在那时，一些感兴趣的人不在 Internet 上，不能通过 FTP 获得拷贝。所以问题是，我该对他们说什么？
我兴许会说，「找一个上网的朋友做一个拷贝给你。」或者我兴许会像我为原来的 PDP-10 Emacs 所做的：告诉他们，「邮寄给我一盘磁带和一个贴足邮资的回信封，我会将 Emacs 放在磁带上寄回去。」但是我没有工作，我正在寻找从自由软件挣钱的方法。所以我宣布我会邮寄一盘磁带给任何想要的人，并收取 $150 。用这种方法，我开始了自由软件发行的事业，它是现今发行整个基於 Linux 的 GNU 系统的公司的先驱。
如果一个程序在它离开其作者双手时是自由软件，这并非必要地意味著它对於每一个拥有其一份拷贝的人都将是自由的。例如，公众领域软件（没有被版权保护的软件）是自由软件；但是任何人可以制作一个由它修改而来的私有版本。同样地，许多自由程序被版权保护但是基於简单许可证加以发行，允许私有的修改版本。
这个问题的典型例证是 X Window 系统。由 MIT 开发，并用一个许可证方式作为自由软件发表，它很快即被不同的计算机公司所采用。他们将 X 以仅二进制形式的方式加到他们的私有 Unix 系统中，并被同样的保密协议控制著。这些 X 的拷贝，就像 Unix 一样，再也不是自由软件。
X Window 系统的开发人员根本不认为这是一个问题 -- 他们期望并有意使其发生。他们的目标不是自由，而仅仅是「成功」，那种定义为「有许多用户」的成功。他们不在意这些用户是否拥有自由，只是希望他们人数众多。
这导致一个矛盾的情形，两种不同的自由量计算方法对同一个问题「这是自由程序吗？」给出不同的回答。如果你基於 MIT 许可证的发行条款给出的自由作判断，你就会说 X 是自由软件。但是如果你以 X 一般用户的自由来衡量，你就不得不说它是私有软件。大多数 X 用户当时正在使用的是随 Unix 系统而来的私有版本，而不是自由版本。
GNU 的目标是给用户自由，而不是仅仅成为流行。所以我们需要使用可以阻止 GNU 软件被转变成私有软件的发行条款。我们所用的方法被称之为「copyleft」。(1)
Copyleft 利用著作权法，但却翻转它惯常的目的而为我们所适用：它成为一种保持软件自由的手段，而不是将软件私有化的方法。
Copyleft 的中心思想是我们给予每个人运行该程序，拷贝程序，修改程序和散布其修改版本的许可 -- 但是没有增加他们自己的限制的许可。因此，定义「自由软件」的至关重要的自由是藉由每个人拥有一个拷贝而获得保证；这些自由因此成为不能剥夺的权利。
对於一个有效的 copyleft ，修改后的版本必须也是自由的。这确保了建立在我们工作基础之上的作品，一旦散布，对我们社团就成为可利用的。当有工作的程序员们志愿改善 GNU 软件时， copyleft 防止他们的雇主们说，「你不能共享这些修改，因为我们正准备使用它们来制作该程序的我们的私有版本。」
如果我们要确保程序每个用户的自由，修改必须是自由的这个需求是必要的。那些私有化 X Window 系统的公司通常作了一些修改以将其移植到它们的系统和硬件。这些改动与 X 的大规模相比而言是较小的，但是它们并非微不足道。如果进行修改是拒绝用户自由的一个藉口，任何人来利用该藉口将是非常容易的。
一个相关议题涉及到结合一个自由程序与非自由代码。如此的结合将不可避免地是非自由的；非自由部分的任何缺乏自由，将也是整个的缺乏。允许这样的组合将打开一个大得足够沉掉一艘船的洞。因此， copyleft 的一个至关紧要的需求是堵上这个洞：任何加到或与一个 copyleft 的程序所组合而成的程序必须也使更大的组合版本也是自由的和 copyleft 的。
我们为大多数 GNU 软件使用的 copyleft 的明确实现是 GNU 一般公众许可证，或简称 GNU GPL 。我们在特定场合下有其它种类 copyleft 可以使用。 GNU 手册也是 copyleft 的，但使用一个非常简化的 copyleft 类型，因为 GNU GPL 的复杂性对其手册是不需要的。
(1) 在一九八四或一九八五年， Don Hopkins （一个非常有想像力的朋友）寄给我一封信。在信封上他写了一些有趣的话，包括这个：「著作权没有：撤回所有权利」（Copyleft: all rights reversed）。【这里采用刘琼云译作《黑客伦理与资讯时代精神》（The Hacker Ethic, and the spirit of information age）第七十一页的译法，但在此仍用版权一词。是对「版权所有 翻印必究」（Copyright: all rights reserved）一句的对应感谢石头成提供的信息。】我用单词「copyleft」来命名我当时正在发展的散布概念。
随著使用 Emacs 兴趣的增长，其他人加入了 GNU 工程，我们决定这是再次寻求资金的时候了。在一九八五年，我们创立了自由软件基金会，一个免税的为自由软件发展的慈善团体。 FSF 也接手了 Emacs 磁带发行工作；后来它通过往磁带上增加其它自由软件（既有 GNU 也有非 GNU ），也通过出售自由手册扩展了该业务。
FSF 接受捐款，但是其大部分收入常常来自销售 -- 自由软件的拷贝，和其它相关的服务。今天它卖源码的 CD-ROMs ，二进制代码的 CD-ROMs ，精细打印的手册（均有再散布和修改的自由），以及豪华发行（这儿我们为你选择的平台制作完整的软件收藏）。
自由软件基金会员工们已经编写和维护了一系列的 GNU 软件包。两个值得注意的是 C 库和外壳(shell)。 GNU C 库是每个运行於 GNU/Linux 系统的程序使用来与 Linux 通信的。它是由自由软件基金会的一个成员， Roland McGrath 开发的。被大多数 GNU/Linux 系统使用的外壳程序是 BASH ， the Bourne Again Shell (1) ，它们是由 FSF 员工 Brian Fox 开发的。
我们资助了这些程序的开发因为 GNU 工程不仅仅是关於工具或开发环境。我们的目标是一个完整操作系统，而这些工具对於这个目标是需要的。
(1) 「Bourne again Shell」是一个对名为「Bourne Shell」的 Unix 常用 shell 的玩笑。
自由软件哲学抵制一种特定的分布广泛的商业实践，但是它不是反商业的。当商业活动尊重用户的自由时，我们祝愿它们成功。
销售 Emacs 拷贝展示了一种自由软件生意。当 FSF 接手该工作时，我需要另一种谋生方法。我在销售我所开发的自由软件相关服务中找到了它。它包括教学，主题诸如如何对 GNU Emacs 编程，如何定制 GCC，和通常是移植 GCC 到新平台的软件开发。
今天，这每一种的自由软件生意被许多的公司实践著。有些公司发行CD-ROM 的自由软件收藏；其它的则贩卖从回答用户问题到改正程序错误，到增加大的新功能等不同层次上的服务。我们甚至开始看到基於发起新的自由软件产品的自由软件公司。
值得特别注意的是，许多公司尽管将它们自己与「open source」发生联系，实际上它们的生意基於与自由软件合作的非自由软件。它们是私有软件公司而不是自由软件公司，其产品诱惑用户远离自由。它们称此为「增值」，反映了它们希望我们采用的价值观念：便利在自由之上。如果我们更珍惜自由，我们应该称它们为「减去自由的」产品。
GNU 的首要目标是作为自由软件。即便 GNU 不比 Unix 有技术优势，它却有一个允许用户合作的社会优点，和一个与道德有关的优点，也就是尊重用户的自由。
但是应用众所周知的好的经验标准於该工作是自然的 -- 例如，动态地分配数据结构以避免武断的固定大小限制，并在任何有意义之处处理所有可能的 8 位代码。
另外，我们放弃了小内存大小的 Unix 设计，决定不支持 16 位机器（ 32 位机器在 GNU 系统被完成时成为主流是很清楚的），并且不为了减少内存使用而作任何努力，除非超过了百万字节。在处理非常大但不是至关紧要的文件的程序中，我们鼓励程序员们将整个文件读入核心，然后浏览其内容而不必顾虑输入输出的问题。
这些决定使得许多 GNU 程序在可靠性和速度上超越了它们在Unix 上相当的其它程序。
随著 GNU 工程名声的增长，人们开始提供捐赠运行 Unix 的计算机给此工程。这些是非常有用的，因为开发 GNU 部件的最轻松方法是在一个 Unix 系统上做，并一个一个地替换该系统的部件。但是这种作法产生了一个道德问题：我们拥有 Unix 拷贝从根本上来说是否正确。
Unix 从以前到现在都是私有软件，而 GNU 工程的哲学则说我们不该使用私有软件。但是，应用与推论出 「自我防卫中的暴力是正当的」 相同的论理，我的结论是：在开发将用来帮助其他人停止使用私有软件包的自由软件代替品的关键时刻，使用私有软件包是合理的。
但是，尽管这是一个可合理化的罪恶，它仍然是罪恶。今天我们不再有任何 Unix 拷贝，因为我们已经用自由操作系统代替了它们。如果我们不能替换一台计算机的操作系统为自由操作系统，我们则替换该计算机。
随著 GNU 工程的进行，以及越来越多的系统部件被发现和开发，最终使得做一个剩余差距列表成为一件有意义的事情。我们用它来招聘开发者编写遗漏的部分。这个列表成为众所周知的 GNU 任务列表。除了遗漏的 Unix 部件之外，我们列出了额外的各种各样的其它有用的软件和文档工程，我们认为，这些是一个真正完整的系统所应当拥有的。
今天，几乎已经没有什么 Unix 部件还留在 GNU 任务列表中 -- 那些工作都已经被完成了，只除了一些无关紧要的。但是该列表满是可以叫做「应用」的工程。任何吸引多於一个有限用户种类的程序都将是加到操作系统的有益之物。
即便是游戏也被包括在任务列表上 -- 而且是从最初就开始了。Unix 包括游戏，所以 GNU 自然地也应该包括。但是对游戏来说兼容性不是一个问题，所以我们没有跟著 Unix 已有的游戏列表走。作为代替，我们列出了一系列不同种类的用户可能会喜欢的游戏。
GNU C 库使用一个称做 GNU 较少一般公众许可证（LGPL）的特殊种类的 copyleft，它允许私有软件可以链接到该库。为什么让此成为例外？
这不是一个原则问题；没有一个原则说私有软件产品有资格包含於我们的代码中。（为什么要对一个断言拒绝与我们共享的工程作贡献呢？）对 C 库或任何库使用 LGPL，是一个策略上的事情。
C 库做的是原生工作；每个私有系统或编译器都带有 C 库。因此，只将我们的 C 库给自由软件用并不会给自由软件带来任何好处 -- 这将只会阻止使用我们的库。
有一个系统是这个的例外：在 GNU 系统中（这包括 GNU/Linux），GNU C 库是唯一的 C 库。所以 GNU C 库的发行条款决定了它是否可以用来为 GNU 系统编译一个私有程序。允许私有应用在 GNU 系统上运行没有与道德相关的理由，但是从战略上看，不接受它们似乎是更多地阻碍使用 GNU 系统，而不是鼓励自由应用的开发。
这就是为什么使用 LGPL 对於 C 库是一个好的策略。对於其它库，策略性的决定需要一个案例一个案例地个别考虑。当一个库做的是一种能帮助编写特定种类程序的特殊工作时，那么将其用 GPL 发行，限制其只能被用於自由软件，是一种帮助其它自由软件开发者的方法。这给了他们在面对私有软件的竞争时的一个优势。
考虑一下 GNU Readline 这一个被开发用来为 BASH 提供命令行编辑的库。 Readline 是用普通的 GNU GPL 发行的，而不是 LGPL。这可能真的减少了 Readline 的使用量，但是这对我们没有损失。因为在此同时，至少有一个有用的应用软件被特别地做成自由软件从而可以使用 Readline，那是对於社团的真正收获。
私有软件开发者们有金钱供给的优势；自由软件开发者们则需要相互获得优势。我希望有一天我们将拥有对私有软件不存在的类似可利用的巨大且受 GPL 保护的库集合，提供作为新自由软件建筑区块的有用模组，并且进一步强化对於将来自由软件开发的优势。
Eric Raymond 说「每个好的软件作品都开始於抓一个开发者的个人痒。」也许那有时会发生，但是许多 GNU 软件的基本部分是为了有一个完整的自由操作系统软件而被开发的。它们来自於一个愿景和一个工程，而不是来自於冲动。
例如，我们开发了 GNU C 库是因为一个类 Unix 系统需要一个 C 库，开发了Bourne-Again Shell（bash) 因为一个类 Unix 系统需要一个外壳，以及开发了 GNU tar 因为一个类 Unix 的系统需要一个 tar 程序。对我自己的程序也同样是如此 -- GNU C 编译器，GNU Emacs，GDB 和 GNU Make。
一些 GNU 程序被开发来应付对我们自由的特定威胁。因而，我们开发了 gzip 来代替因 LZW 专利而使社团失去的 Compress 程序。我们发现人们开发 LessTif，近期更开始了 GNOME 和 Harmony，来解决因某些私有软件库（见下文）所带来的问题。因为用户们不应该在秘密和自由之间作选择，我们正在开发 GNU Privacy Guard 以代替流行的非自由加密软件。
当然，编写这些程序的人们变得对这项工作发生兴趣，许多人由於他们自己的需要和兴趣而给它们增加了许多功能。但是那并不是这些程序之所以存在的原因。
在 GNU 工程刚开始时，我设想我们将开发整个 GNU 系统，然后完整地散布。但那并不是它如何发生的。
由於 GNU 系统的每个部件都是在 Unix 系统上实作出的，因此远在一个完备的 GNU 系统实际存在之前，每个部件都可以在 Unix 系统上运行。这些程序有的变得流行，使用者开始扩充并且移植它们到许多不兼容的 Unix 版本，有时也会移植到其它的系统。
这个过程使得这些程序更加强而有力，并且吸引了 GNU 工程的资金和贡献者。但是这或许也延迟了数年来完成一个最小运转系统，因为 GNU 开发者们的时间被投入到维护这些部件和给已有部件增加功能当中，而不是转移到编写一个接一个遗漏的部件上。
一九九○年， GNU 系统几乎已经完成；唯一主要遗漏的部件是其内核。我们已经决定将内核实现成在 Mach 之上运行的服务器进程集合。 Mach 是在 Carnegie Melon 大学，后在犹他大学开发的微核； GNU HURD 是一个运行於 Mach 之上的服务器集合（或称为「角马兽群」），并且负责 Unix 内核的各种任务。开发的启动由於我们等待 Mach 如其许诺的那样被作为自由软件发行而延误。
选择该设计的一个原因是为了避免此工作中看来似乎是最困难的一部分：在没有一个源码层次的调试除错器的条件下调试除错内核程序。在 Mach 中，这部分的工作已经被完成，因此我们期待著像用户程序般使用 GDB 来调试除错 HURD 服务器。但是这花了很长时间才成为可能，而相互发送讯息的多线程服务器最后仍旧难以进行调试除错。这使得让 HURD 能够稳固地工作的进程延长了很多年。
GNU 内核原本并不设想被称作 HURD。它的原名是 Alix -- 按我当时的情人命名。她，一个 Unix 系统管理员，指出她的名字是如何适用於一个 Unix 系统版本的普通命名模式；作为一个笑话，她对她的朋友们说，「有人应该按我的名字命名一个内核。」我没说什么，但已决定用一个名叫 Alix 的内核使她惊奇。
事情并没有保持不变。 Michael Bushnell （现在的 Thomas），内核的主要开发者，属意 HURD 这个名字，并重新定义 Alix 来指内核中的某个特定部分 -- 该部分就是捕获系统呼叫并以发送讯息给 HURD 服务器来处理它们。
最终， Alix 和我分手了，她改了名字；与此无关地， HURD 设计被改变因而使得 C 库得以直接发送消息给服务器，这导致 Alix 部件从设计中消失。
但是在这些事情发生前，她的一个朋友在 HURD 源码中偶然见到 Alix 这个名字，并向她提及此事。所以该名字已经起了作用。
GNU Hurd 还没有准备好可以作为产品使用。幸运的是，另一个内核已经可以取得。在 一九九一年，Linus Torvalds 开发了一个与 Unix 兼容的内核并称之为 Linux 。大约在一九九二年，将 Linux 与不是非常完整的 GNU 系统相结合产生了一个完整的自由软件操作系统。（当然，结合它们本身也是一件重要的工作。）由於 Linux ，我们今天因此可以实际运行一个 GNU 系统的版本。
我们称此版本的系统为 GNU/Linux ，以表达它是 GNU 系统和以 Linux 作为内核的组合。
我们已经证明了我们开发系列广泛自由软件的能力。这并非意味著我们是无敌的和无法被停止的。一些挑战使得自由软件的将来充满不确定性；与它们会战将需要坚实的努力和耐力，有时持续数年。这将会需要那种人们在当他们珍惜他们的自由，并且不让任何人将其夺走时所显示的决心。
下边四个段落讨论这些挑战。
硬件厂商愈加倾向於对硬件规范保密。这使得编写让 Linux 和 XFree86 能支持新硬件的自由驱动程序变得困难。现在我们已经完成了自由操作系统，但是如果不能支持明天的计算机，我们将会在明天失去它们。
有两种方法来应付这个问题。程序员可以采用逆向工程的手段来了解如何支持这些硬件。其他的人则可以选用被自由软件支持的硬件；随著我们的人数增加，规范的保密将成为一个弄巧成拙的策略。
反向工程是件大工作；我们会有程序员具备足够的决心去担负这件工作吗？是的 -- 如果我们已经建立了一个认为自由软件是一个原则问题的坚固信念，则非自由驱动程序就是无法忍受的。我们中的大多数人会花额外的钱，或甚至一点额外的时间，从而可以使用自由驱动程序吗？是的，如果拥有自由的决心是广泛传播的。
一个运行於自由操作系统之上的非自由库的行为就像是一个针对自由软件开发者的陷阱。库中的那些吸引人的功能是诱饵；如果你使用该库，你就跌入了陷阱，因为你的程序不能有用地成为自由操作系统的一个部分。（严格来说，我们可以包含你的程序，但没有了该库它就无法 运行 。）更糟糕的是，如果一个使用私有软件库的程序流行起来，它可引诱其他不怀疑的程序员们落入陷阱。
这个问题的第一个例子是八○年代的 Motif 工具箱。尽管当时还没有自由操作系统，但是 Motif 以后会对自由操作系统造成什么问题是很清楚的。 GNU 工程以两种方式做了回应：通过请求个别的自由软件工程在支持 Motif 的同时也支持自由 X 工具箱小部件，并请求一些人编写替代 Motif 的自由软件。该工作花费许多年时间；由 Hungry 程序员们开发的 LessTif，在一九九七年才成为够强而得以支持大多数 Motif 应用程序。
在一九九六年和一九九八年间，另一个非自由 GUI 工具箱库，叫做 Qt ，被用在 KDE 桌面这一包含大量自由软件的集合中。
自由 GNU/Linux 系统无法利用 KDE，因为我们不能使用其库。尽管如此，一些不严格坚持自由软件的商业 GNU/Linux 系统发行商将 KDE 加入到他们的系统中 -- 产生了一个具有更强能力，但却更少自由的系统。 KDE 小组积极地鼓励更多的程序员们使用 Qt ，成百万的新「Linux 用户」从来都不知道有这样一个问题的存在。情形相当糟糕。
自由软件社团以两种方法对这个问题作出回应： GNOME 和 Harmony 。
GNOME 即 GNU 网络对象模型环境（Network Object Model Environment），是 GNU 的桌面工程。从一九九七年开始，由 Miguel de Icaza 在 Red Hat Software 支持下开发，GNOME 开始提供类似的桌面工具，排外地只使用自由软件。它也有技术上的优势，如支持多种语言，而不仅仅是 C++。但是它的主要目的是自由：不需要使用任何非自由软件。
Harmony 是一个兼容替代库，设计用来在没有 Qt 的情况下也有可能运行 KDE 软件。
在一九九八年十一月， Qt 的开发者们宣布了一个许可证的改变，当其实施后，应该会使得 Qt 成为自由软件。虽然没办法确信，但是我想这应该部分归功於社团对於 Qt 是非自由软件时所造成的问题的坚定回应。（新的许可证既不方便也不公正，所以仍旧值得去避免使用 Qt 。）
[后记：在二○○○年九月， Qt 以 GNU GPL 加以发行，因此实际上解决了这个问题]
我们将如何回应下一个诱人的非自由库呢？整个社团会了解需要远离陷阱吗？或者我们中的许多人将为了方便而放弃自由，从而产生一个大的问题？我们的未来将取决於我们自身的哲学。
我们面临的最坏威胁来自於软件专利，它可以对自由软件的演算法和功能加以限制多达二十年。 LZW 压缩算法专利是一九八三年申请的，因此我们仍旧不能散布自由程序来产生适当的压缩 GIFs 。在一九九八年，一个用来产生 MP3 压缩音效的自由软件程序由於担心专利官司威胁而被从发行中拿掉。
但仍有办法应付专利：我们可以研究寻找证据证明一个专利是无效的，也可以寻找其它方法来完成工作。但是这每一种方法只有在某些时起候才起作用；当它们都失败时，一个专利可能会迫使所有的自由软件缺少某些用户想要的功能。当这发生时我们可以做些什么呢？
我们中的那些因自由的缘故而重视自由软件的人们无论如何都将与自由软件待在一起。我们将设法不用专利保护的功能而完成工作。但是那些因为他们认为自由软件的技术出众而重视它的人们，有可能在专利抑制自由软件时认为这是自由软件的失败。因而，虽然讨论软件开发的「大教堂」模式的实际效力和一些自由软件的可靠性和能力是有用的，但我们必定不能停在那儿。我们必须探讨自由和原则。
我们自由操作系统的最大不足不是在软件中 -- 而是缺乏我们可以包括在我们系统中的好的自由手册。文档资料是任何软件包的基本部分；当一个重要的自由软件包没有与好的自由手册一起出现，那将是一个大的缺陷。今天我们有许多这样的缺陷。
自由文档资料，如同自由软件，是自由问题，不是价格问题。自由手册的标准几乎与自由软件完全相同：它是为了给予所有用户确定的自由。重新发行（包括商业销售）必须被许可，不论是在线还是书面形式，因而手册能够伴随每个程序的每个拷贝。
允许修改也是至关紧要的。作为一个普通规则，我不相信人们拥有修改所有种类文章和书籍的许可是至关紧要的。例如，我不认为你或我应该被迫给予修改像本文这样描述我们行为和我们观点文章的许可权。
但是有一个特殊的原因关於为什么修改自由软件文档资料的自由是至关紧要的。当人们行使他们修改软件的权利，并且增加或改变其功能时，如果他们是尽职的，则他们也将修改文档资料 -- 因而他们能随著修改过的程序一起提供正确和可用的文档资料。一个不允许程序员们尽职并完成该工作的手册不符合我们社团的需要。
加诸在修改应该如何完成的某些限制并不会造成问题。例如，保持原作者的版权声明，发行条款，或作者列表的要求是可以的。要求修改后的版本包括它们修改版本的声明也是没有问题的，即使有整节没有删除或修改，只要这些节涉及非技术主题。这些类型的限制不是问题，因为它们不阻止尽职程序员修改手册以适应修改过的程序。换种说法，它们不妨碍自由软件社团完全利用该手册。
尽管如此，必须有可能修改手册的所有 *技术* 内容，并将结果以所有常规媒体形式通过所有常规渠道发行；否则，这些约束就阻碍了社团，手册不是自由的，此时我们需要另一个手册。
自由软件开发者们将有知晓和决心去生产一个全系列的自由手册吗？我们的未来将再次取决於哲学。
估计当今有数千万的用户使用诸如 Debian GNU/Linux 和 Red Hat Linux 的 GNU/Linux 系统。自由软件已经发展到了这样实用的优势，使得用户纯粹为了实用原因而聚集到它身边。
这种现象的好结果是明显的：更多开发自由软件的兴趣，更多自由软件商业的用户，以及更多鼓励公司开发商业自由软件而不是私有软件产品的能力。
但是对软件的兴趣增长快於对其所基於的哲学的了解，这带来了麻烦。我们面对上边描述的挑战和威胁的能力依赖於坚决主张自由的意志。为了确定我们的社团拥有这个意志，我们需要在新的用户来到社团时向他们传播这样的思想。
但是我们正在这点上失败：吸引新用户加入社团的努力大大超越了教育他们成为我们社团的好公民的努力。我们需要做这两件事，而且我们也需要保持这两个努力的平衡。
当一九九八年社团的一部分决定停止使用术语「自由软件」并改为说「开放源码软件」时，教导新用户有关自由的观念变得更加困难。
一些喜欢该术语的人意欲避免「自由」与「白送」的混淆 -- 这是一个正当的目标。可是其他人，打算将激励了自由软件运动和 GNU 工程的原则精神抛到一边，反而迎合行政和商业用户，而这些用户中的许多人持有一种将利润置於自由，社团和原则之上的意识形态。因而，「开放源码」的花言巧语集中在制作高质量，强有力软件的潜能上，但是避开自由，社团以及原则的思想。
「Linux」杂志是其一个清晰的例子 -- 它们被与 GNU/Linux 合作运行的私有软件广告所充斥。当下一个 Motif 或 Qt 出现时，这些杂志将警告程序员们远离它还是为它们登载广告呢？
商业支持可以许多方式为社团作贡献；其它种类的支持也都一样，它是有益的。但是为了赢得他们的支持而少说自由和原则可能损失惨重；它使得前述「超越和公民意识教育」之间的失衡变得愈加糟糕。
「自由软件」和「开放源码」或多或少地描述了同一软件类别，但是它们谈论的软件和价值则是不同的事情。GNU 工程继续使用「自由软件」这个术语，来表达不仅仅是技术，自由也是重要的思想。
Yoda 大师的哲学「没有『尝试』」（There is no try）】听起来幽雅，但是它对我不起作用。我已经在「担忧我是否可以完成任务的顾虑中，以及不确信如果完成了任务，我所做的是否足以达到目标」中，做了我的大部分工作。但是无论如何我尝试了，因为在敌人和我的城市之间除了我之外没有别人。令我自己惊讶的是，有时我成功了。
有时我失败了；我的城市中有些已经陷落。随后我发现另一个受威胁的城市，并为另一场战斗做好准备。随著时间的消逝，我已经学会寻找威胁并把我自己放在它们和我的城市之间，召唤其他黑客来加入我。
现在，我常常不是唯一的一个。当我看见一大群黑客努力坚持下去时的感觉是一种安慰和乐趣，我意识到，目前，这个城市也许能幸存。但是危险每年都变得更大，并且现在 Microsoft 已经明确地将目标对准我们社团。我们不能把自由的将来视为理所当然。别把它看作是理所当然！如果你想要保持你的自由，你必须准备好去捍卫它。
请将有关 自由软体基金会 与 GNU 的 查询 与 问题（以英语）送到 gnu@gnu.org ；
或（以中文）送到 chliu@gnu.org ，
您也可以使用 其它方法联系 自由软体基金会。
请将有关 GNU 中文翻译小组 的意见（以英语或中文）送到 chinese-coordinators@gnu.org ，
有关 GNU 中文网页 的意见（以英语或中文）送到 chinese-translators@gnu.org ，
有关 原始英语网页 的意见（以英语）送到 webmasters@www.gnu.org ，
其它问题则（以中文）送到 chliu@gnu.org 。
Copyright (C) 1998, 2001 Richard Stallman.
Permission is granted to make and distribute verbatim copies of this
transcript as long as the copyright and this permission notice appear. 允许在不变更文件内容的前提下刊登本文副本在任何形式的媒体中，但需保留版权宣告和此声明。
翻译：朱 庆九 博士。
验证：马 雪萍、刘 昭宏。
朱博士的原译本 在此 。
本文另有一份由李极光先生所完成的译本，待出版后我们会互相参酌，并将两位翻译人员列为共同作者。
Updated: $Date: 2003/07/23 13:12:06 $ $Author: chstoneliu $