Richard Stallman 著
夏 昊 洪 峰 译
最初的软件共享群体
1971年，当我开始在麻省理工学院人工智能（AI）实验室工作时，我成了那里
的软件共享群体的一分子，这个软件共享群体已经存在多年。其实，软件的共享并
不限于我们这一特定的群体，它的历史与计算机一样长久，这两者之间的关系就像
人类很早就交换食谱与烹饪一样。但我们做得比大多数人都做得更多。
AI实验室当时使用了一种称为ITS（Incompatible Timesharing System，非兼
容分时系统）的分时操作系统，这是我们实验室工作人员专为Digital PDP-10（那
个时代的大型计算机）设计的操作系统，而且是用汇编语言开发的。作为这个群体
的成员，我是一个AI实验室的系统黑客，我的工作就是完善这一系统。
当时我们并不把我们的软件称为“自由软件”（free software），因为这个词
语当时还不存在，但事实上那就是自由软件。每当其他大学或者公司的人要求移植
或者使用我们的某个程序时，我们总是应允的。如果你看到某人在使用一个陌生而
且有趣的程序时，你总可以要求查看它的源代码，以便可以读代码、对源代码进行
修改、或者套用原代码的一部分来创作新程序。
群体的崩溃
八十年代年代初，Digital公司停止了对PDP-11系列的开发，那时情况发生了巨
变。以六十年代的标准来看，PDP-11系列的体系结构是精巧和强大的，但无法自然
地适应八十年代的技术所允许的更大寻址空间。这意味着，几乎我们所有的程序，
包括ITS，都一下子报废了。
在这前不久，AI实验室的黑客群体已经分崩离析。1981年，从实验室分离出去
了一个公司，名为“Symbolics”，几乎雇走了所有的黑客，剩下的群体盛况难再。
Steve Levy编写过《黑客》一书，这本著作十分传神地描述了这个群体鼎盛时期的
情况。当AI实验室于1982年购置了一台新的PDP-11机器时，系统管理员决定使用
Digital的非自由分时系统，而不是ITS。
那个时代的流行计算机系统，如VAX和68020，都有自己的操作系统，但这些系
统都不是自由软件：即使为了获得机器码可执行程序的拷贝，也应该签署不公开协
议（nondisclosure agreement）。
这就意味着，你开始使用计算机的第一步就是要保证不帮助你身边的人。相互
协作的群体是被禁止的。专有软件（proprietary software）所有者制订的规则是：
“与他人共享软件就是盗版行为；如果你需要对程序作任何修改，磕头央求我们吧。”
专有软件社会系统（即声明用户不能分享或修改软件的系统）的观念是反社会
的、不道德的、完全错误的。这一观点可能会让一些读者惊诧不已。但是，对于一
个基于分裂公众、使用户孤立无援的价值系统，我们还能说些什么呢？对这一观点
感到难以接受的读者，可能早已对专有软件熟视无睹，或者从专有软件工业的角度
出发才作出了这样的判断。这也难怪，因为软件出版商已经长期为此努力工作，以
使人确信对于这一事情只能有一个观察角度。
当软件出版商谈到“确保”他们的“权益”，或“禁止盗版行为”时，他们实
际上所说的东西是次要的。他们在版权声明中真正传递的信息却是他们认为不言自
明的假设，公众似乎应该不加批判地接受之。现在让我们来逐条地检查这些假设。
假设之一，是软件公司具备无可置疑的自然权力占有软件，从而有权凌驾于所
有用户之上。如果这确实是一种自然权力的话，那么无论它对公众有多大的伤害，
我们都无法反对。有趣的是，美国的宪法和司法传统拒绝这种看法；版权并非一种
自然权力，而是一种人为的、由政府强行实施的一种垄断，以限制用户拷贝的自然
权力。
另一种没有挑明的假设是，软件的唯一重要意义在于软件可以允许用户做什么
——而我们计算机用户不应该关心我们必须接受什么样的社会。
第三种假设是，如果不允许某个公司凌驾于其软件产品的用户之上，我们就不
会有任何可用的软件，或者永远不会有所需要的软件去完成这样或那样的特别任务。
这个假设一度显得颇有道理，但是后来的自由软件运动表明，我们可以创造出足够
多的有用软件，而无须加以一连串的限制。
如果我们拒绝接受上述假设，并将用户置于优先的地位，从普通的、常识性的
道德价值出发审视这些问题，我们就会得到截然不同的结论。计算机用户应该可以
自由地修改程序以适应他们自己的需求，可以自由地共享软件，因为帮助他人是社
会存在的基础。
这里没有足够的篇幅容纳得出这一结论的详细逻辑推理，因此我推荐你阅读我
们的Web主页，http://www.gnu.org/philosophy/why-free.html。
艰难的道德选择
虽然我原来的群体已经消失，但继往开来并非不可能，只是我面临一个道德选
择。
一条简单的出路是加入专有软件世界，签署不公开协议，并许诺不再帮助我同
事中的黑客。这样做的结果很可能是我也开发软件，而且软件也以不公开协议的形
式发布，从而对其他不愿意背叛同伴的人进一步施加压力。
我有可能由此而发财，而且也从编写代码中获得乐趣。但我明白，在我的职业
生涯结束时，我回过头来看到的景象将是这些年来筑起高墙林立，并将人们分隔开
来，我会觉得自己的一生努力的结果会把这个世界搞得更糟。
在此之前，我已有过接受不公开协议的经验。当时，别人拒绝向MIT人工智能
实验室和我提供我们打印机的控制程序的源代码。该程序缺乏某些功能，打印机的
使用起来极端麻烦。因此，我不能对自己说不公开协议是清白的。他拒绝与我们共
享代码，当时我非常愤怒。我不可能转头对其他每一个人都如法炮制同一作法。
另一种选择，直截了当但令人不快，是离开计算机领域。如果那样，我的技能
就不会被滥用，但我的才能仍然会被浪费掉。我个人不会成为分隔、限制计算机用
户的帮凶，但社会上的分隔和限制依旧在发生。
因此，我要寻求一种解决之道，使我作为一个程序员能够做些好事。我扪心自
问，我是否能写出一个或一些程序，能使我所珍视的群体再生呢？
答案很清楚：最急需的首先是一个操作系统。这是开始使用计算机最至关重要
的软件——有了操作系统，可以做许多事情；没有操作系统，你连计算机都使用不
了。一个自由的操作系统，会使我们可以再度拥有一个相互合作的黑客群体，而且
进一步邀请其他任何人参与进来。每个人都可以安心使用计算机，而无须变成剥夺
自己朋友权益的同谋。
作为操作系统开发人员，我拥有的技能正适合这项工作。因此，尽管我不认为
成功唾手可得，但是我觉得这是我的天赋。我决定将系统设计得与UNIX兼容以便移
植，同时也便于UNIX用户的移民到这一新的操作系统上来。我按照一项偷拇�
选择了GNU这个名字，GNU是“Gnu''s not UNIX”（GNU不是UNIX）的递归同义
词。
操作系统并不仅仅意味着一个恰好只能运行其他程序的内核。在70年代，任何
排得上号的操作系统都包括有命令解释器、汇编器、编译器、解释器、调试器、文
本编辑器和电子邮件软件包等等。ITS包括这些东西，Multics有，VMS有，UNIX有，
GNU操作系统也应该含有这些东西。很久之后我看到了以下的诗句，据传来自Hillel*：
如果我不为自己打算，谁会为我考虑？
如果我只为自己打算，我又变成了什么东西？
如果现在不动手，还要等到什么时候？
启动GNU工程的决定，正是基于同样的精神。
* 脚注：作为无神论者，我不盲从任何宗教领袖，但有时我不得不赞赏他们中某些
人的箴言。
Freedom中的自由
“free software”这种术语有时会被误解——事实上它和价格毫无关系。它
的涵义是自由。这是自由软件的定义所决定的。对于你，某个特定的用户来说，如
果某个程序称为自由软件，那么：
你拥有运行该程序的自由，而且可以用于任何目的。
你拥有修改该程序以适应你个人需要的自由。（为了在实践中使这一自由成为
可能，你必须能够获得源代码，因为没有源代码而试图修改程序是极端困难的。）
你拥有再发行拷贝的自由，可以是无偿的，也可以收费。
你拥有发行该程序修改后版本的自由，从而使社团可以从你所作的改进中获益。
因为这里“free”的涵义是自由而非价格，自由软件和销售拷贝之间并没有矛
盾。事实上，销售拷贝的自由是至关重要的：把自由软件收集到CD-ROM上出售对整
个社团都很重要，而销售它们又是为开发自由软件筹集资金的重要手段。因此，如
果人们无法将某个程序自由地收集到这些集合中时，这个软件就不是自由软件。
由于“free”一词具有歧义，人们长久以来都在寻找另外的词来替代它，但直
到现在还没有找到其合适的替代词。英语的单词与单词之间的细微差别比世界上其
他的语言更多，然而它却缺少一个简单明了、没有歧义的单词表示自由（freedom）
中的“free”。“unfettered”（除去镣铐的）也许是词意与之最接近的词了。其
他诸如“liberated”（被解放的）、“freedom”（自由的）和 “open”（开放
的）也被考虑过，但是这样替代词要么语义不对，要么就是存在其他缺陷。
GNU软件与GNU系统
开发一个操作系统是一个非常庞大的工程。考虑到可行性，我决定只要有可能
就采用和使用现成的自由软件。例如，最初我就决定使用TeX作为主要的文本格式
化工具；几年之后，我决定使用X Window系统，而不是另起炉灶为GNU写一个窗口
系统。
由于这些决定，GNU系统不等价于所有GNU软件的集合。GNU系统中包括非
GNU软件、由其他人或者其他开发项目出于各自目的而编写的程序，但正因为它们
是自由软件，所以我们可以使用。
工程之发轫
1984年1月，我辞去了在MIT的职务，开始专心致志编写GNU 软件。离开MIT是
必要的，这样MIT就无法干涉我将GNU作为自由软件发行。如果我继续在学校的工作，
那么MIT可以声称拥有我的工作成果，可以实施他们自己的软件发行条件，甚至可
以将它们变成专有软件。我无意在付出大量的劳动后，最终只是看到结果对自己的
初衷没有帮助。我的初衷是：创造一个新的软件共享群体。
不过，当时MIT人工智能实验室的领导，温斯顿教授（Prof. Winston），却友
善地邀请我继续使用实验室的设备。
最初的步骤
启动GNU工程之前不久，我听说荷兰自由大学有一种编译器软件包（又称VUCK，
荷兰语中表示“自由”的词以字母“V”开始）。这是一个为处理多种编程语言（
包括C和Pascal）而设计的编译器，并且支持多种目标机。我给它的创作者写了一
封信，询问GNU工程是否可以使用它。
他的回信不无嘲弄，声称大学是自由的，但他的编译器不是。因此我决定为GNU
开发的第一个程序是一个支持多语言、多平台的编译器。
我希望避免单枪匹马地开发整个编译器，我获取了在劳伦斯·利福摩实验室（
Laurence Livermore Lab）开发的多平台编译器，即Pastel的源代码。它支持Pascal，
本身就是专为系统编程而设计，而且是Pascal语言的一个扩展版本。我加上了一个C
的前端（frontend），然后开始将它移植到摩托罗拉68000计算机计算机上去。但我
不得不放弃，因为我后来发现该编译器需要许多兆字节的栈空间，而当时的68000
UNIX系统只支持64K。
于是，我判定该Pascal编译器的设计思想是将整个输入文件处理成为一个语法
树，将整个语法树转化为一连串的“指令”，然后生成整个输出文件，在全过程之
中不会释放任何内存。从那时起，我决心从头开始编写一个完整的编译器。这个新
编译器现在的名字就是GCC，它完全没有使用任何Pastel编译器的代码，但我设法用
上了我原来编写的C前端，不过这却是几年以后的事情了。我首先完成了GNU Emacs。
GNU Emacs
我开发GNU Emacs的工作始于1984年，1985年初GNU Emacs便可以开始使用了。
这使我可以在UNIX机器上进行编辑工作。而在此之前，因为没有兴趣使用vi或ed，
我的文本编辑工作都是在其他系统上完成的。
这时，人们开始希望能使用GNU Emacs，这就引发了如何发行的问题。我将它放
到了我所使用的MIT机器的匿名FTP服务器上（prep.ai.mit.edu这台计算机从此成为
GNUFTP发行的主站点。几年之后机器不复使用时，我们将它的名字转到新的FTP服务
器上）。但在当时，许多有兴趣使用GNU Emacs的人都不在因特网上，也就无法利用
FTP以获得Emacs的拷贝。那么，我应该告诉他们什么呢？
我可以说：“找一个能上网的朋友，他会帮助你获得拷贝的”。或者按照我最
初在PDP-10上发行Eamcs的方式，对他们说：“寄给我一盘磁带和一个邮资已附的回
信信封，我会把Eamcs寄回给你的”。但当时我没有工作，正在寻找通过自由软件挣
钱的方法。 因此我宣布会为所有希望得到它的人邮寄一份，定价是150美元。这样，
我开始了商业性自由软件的发行业务，这也是当今众多销售完整的、基于Linux的GNU
系统的公司之滥觞。
程序对每个使用者都自由吗？
一个程序作为自由软件离开原作者之手后，并不一定意味着它对于每个拥有拷
贝的人都是自由软件。举例来说，公用领域软件（public domain software，没有
版权的软件）是自由软件，但任何人都可以将它稍作修改的版本变成专有软件。同
理，许多自由软件虽然有版权声明，但发行许可证过于简单宽纵，以至有人可以将
它修改成为专有软件。
这个问题的例证之一是X Window系统。X Window系统是在MIT开发出来的，它以
一种比较宽容的许可证发布之后，很快就被很多计算机厂商所采用。他们将二进制
码的X Window系统附加到各自专有的UNIX系统中，加上了与UNIX同样的不公开协议。
这些X Window系统的拷贝与UNIX一样，它们并不是自由软件。
X Window系统的开发者事先并不认为这是一个问题——他们的意图正是这样，
并且期望这样的情况发生。他们的目的并非自由，而只是“成功”，即“拥有许多
用户”。他们不关心这些用户是否拥有自由，而只要用户数量众多就可以了。
这导致了一个自相矛盾的情况：对“这个程序自由吗？”这一问题，按照两种
不同的自由程度计算方法会得出不同的答案。如果你按照基于MIT发行版发行条件来
进行判断它所提供的自由，那么可以认为X Window系统是自由软件；但如果考虑一
般X Window系统用户的自由，你不得不认为它是专有软件。绝大多数X Window系统
用户以前是在使用UNIX系统附带的专有版本，而不是自由版本。
Copyleft与GNU GPL
GNU 的目的是给用户以自由, 而不仅是为了争取大量用户。因此我们必须使用
某种发行条件，以避免将GNU软件变成专有软件。我们使用的方法称为“Copyleft”
（版权所无）（注）。
注：在1984和1985年，唐·霍普金斯（Don Hopkins，一个非常富于想象力的家
伙）给我寄了一封信。在信封上他写了一些逗乐的话，其中包括：“版权所无——
所有权力都被逆转（copyleft-all rights reversed）”。于是，我就使用了Copy-
left一词以命名当时我正考虑的软件发行概念。
Copyleft利用了版权法，但反其道而行之，以达到与通常相反的目的：将一种
将软件私有化的手段转变成了保持软件自由的手段。
Copyleft的中心思想，是我们给予任何人运行、拷贝、修改以及发行改变后程
序的许可，但不准许附加他们自己的限制。从而保障了每个人都有获得“自由软件”
的软件拷贝的自由，它们成为了不可异化的权力。
要保证Copyleft的有效性，那么修改后的版本出必须也是自由的。这保障了在
我们工作的基础上所完成的成果一旦公布后，也能为我们的社团所用。当专业编程
人员自愿帮助改进GNU软件时，“Copyleft”可以防止他们的雇主声称：“你不能
和人共享这些改动，因为我们会用它创建我们自己专有软件的版本。”
所以为确保程序对每位用户都自由，那么所作改动也必须保持自由这个前提是
必不可少的。将X Window系统私有化的那些公司通常对程序做了某些修改，以便将
X Window System移植到他们的系统和硬件上。这些改动与整个X Window系统的广
泛内容相比并不算大，但并非微不足道，如果这些修改可以作为拒绝给用户以自由
的借口，人们都会轻而易举地利用这一借口。
一个相关的问题涉及到将自由的程序与不自由的代码相组合。这样一个组合将
不可避免地失去自由性；无论不自由的部分缺乏何种自由，都会使整个程序丧失自
由。一旦允许这种漏洞存在，那么所造成的损失可以大于再沉一艘“泰坦尼克”号。
因此，“Copyleft”的一个关键要求是封堵这一漏洞：任何添加或者组合到自由软
件上的部分都不允许附加其他限制，从而保证其结果的整体是自由的、版权所无的
（Copylefted）。
作为Copyleft的一种特定实现形式，我们用“GNU公众许可证（简称GPL）”来
标明绝大多数GNU软件的许可证。我们还有在特殊情况下使用的其它种类的“Copy-
left”许可证。GNU的使用手册也采取了Copyleft许可证，但使用的一种大大简化
的方式，因为手册不需要GNU GPL那样的复杂度。
自由软件基金会（The Free Software Foundation）
随着人们使用Emacs的兴趣日益增加，其他人也开始参与GNU工程，我们觉得这
是再次寻求资助的时机。所以我们在1985年创办了自由软件基金会（FSF），这是
一个完全致力于自由软件开发的免税福利机构。FSF同时也接管了Emacs磁带发行
业务，接着FSF在磁带上增加了GNU的和其他非GNU的自由软件，并出售自由软件的
使用手册，FSF的业务得到了进一步的扩展。
FSF接受捐赠，但它的绝大多数收入来源于销售自由软件拷贝以及其他服务。
今天它销售的产品包含含有源代码的光盘，可执行程序的光盘、印制精美的使用
手册（全都包括修改和再发行的自由）及其豪华版（我们为客户指定的平台制作
完整的软件包）。
自由软件基金会的雇员编写了并维护着数量相当多的GNU 软件包。其中值得
一提的两种是C Library和shell（命令解释器）。任何运行于GNU/Linux系统之
上的程序都用GNU C Library作为与Linux内核通信的中介。它是由自由软件基金
会的一位工作人员Roland McGrath开发的。绝大多数GNU/Linux系统上使用的shell
都是BASH (Bourne Again Shell)*，它由FSF雇员Brian Fox开发。
* 脚注：Bourne Again Shell (Bourne Shell再世)是对UNIX上常见的shell
“Bourne Shell”开的玩笑。
我们资助了这些程序的开发，因为GNU工程的注意力并不只局限于工具和开发
环境。我们的目的是一个完整的操作系统，而这些程序是实现这一目的所必须的。
自由软件的支持
自由软件的哲学拒绝一种广为流传的特定商业行为，但它并非反对商业，如果
商业机构尊重用户的自由，那么我们希望他们成功。
销售Emacs的拷贝就展示了一种自由软件的商业运作方式。当FSF接管了这项业
务后，我需要另一种方法养家糊口。解决办法是围绕我原来开发的自由软件来销售
服务。这包括教授如何使用GNU Emacs编程、如何定制GCC之类的课题，以及怎样开
发软件（主要是将GCC移植到新的平台上）。
今天，上述的每一种自由软件业务模式都被一些公司采用。其中一些发行自由
软件的集合（收集在CD-ROM上），另一些销售支持（技术服务），支持级别很广泛，
从回答用户的问题到解决软件中的臭虫，乃至增加重大的新特性。我们甚至开始看
到市场上出现了发行自由软件新产品的公司。
但要注意，一些将自己与“开源软件”（Open Source）概念相联系起来的公
司，事实上是将他们的业务建筑在与自由软件一起工作的非自由软件上。这不是自
由软件公司，而是专有软件的公司，他们推出产品诱惑用户远离自由。他们美其名
曰“增值”，这个名字也反映出了他们希望我们接受他们的价值观：方便超越自由。
如果我们相比之下更珍视自由的话，我们可以把他们的产品称之为“减少自由”的
增值品。
技术目标
GNU的基本目标在于自由软件。即使GNU在技术上对UNIX无优势可言，它仍然具
有社团意义上的优势，允许用户相互合作，还有道德意义上的优势，尊重用户的自
由。
但使用广为接受的技术质量标准来评判我们的成果，那也是自然而然的。例如，
动态地分配数据结构以避免任意固定尺寸限制，同时在任何有意义的场合下都正确
处理所有可能的8位代码。
在此之外，我们决定不支持16位的机器（当时已经清楚，GNU系统完成之时，
32位的机器即将普及），不致力缩减内存使用量除非超过1兆字节，这就否定了当时
UNIX对小内存的关注，当处理大文件并非关键问题时，我们鼓励程序员将整个输入
文件读入内存，然后遍历它的内容而不用去顾及输入/输出。
这些决定使许多GNU程序同时在可靠性和速度上都超越了它们的UNIX竞争对手。
捐赠的计算机
随着GNU工程的声誉日益增长，人们开始向工程捐赠运行UNIX的机器。它们非
常有用，因为开发GNU元件最简便的方式莫过于先在UNIX系统上编程，然后将系统
的元件逐一替换，但它们也引发了一个伦理方面的问题：我们拥有一个UNIX拷贝是
否正确。UNIX过去是，现在也是专有软件。GNU工程的哲学认为我们不应该使用专
有软件。然而，与在正当防卫中使用暴力相似，我按照这一推理得出了一个结论：
我确信，在为开发自由软件去替代专有软件，和帮助他人停止使用专有软件时，如
果需要使用专有软件的确是问题的关键的话，那么使用专有软件是合乎情理的。
但是，即使这样做是有理的罪恶，它毕竟仍然是一种罪恶。今天我们不再拥有
任何版本的UNIX，因为我们已经使用了自由的操作系统替代了它们。如果我们不能
使用自由的操作系统去替代机器上的操作系统，那么我们会替换机器本身。
GNU任务清单
随着GNU工程的进展，越来越多的系统元件被发现或者被开发出来。最后，列
出一个剩下课题的清单对我们来说有了意义。我们使用这份任务清单招集开发者以
编写剩余所欠缺的部分。这一清单以GNU任务清单命名。除了尚缺的UNIX组成部分，
我们还包括了各种各样的、我们认为一个真正完整的系统应该具备的其他有用软件
以及文档项目。
时至今日，几乎没有任何UNIX的成分还遗留在GNU任务清单之中——那些工作已
经完成，某些不重要的除外。但清单现在充满了可以称为“应用程序”的项目。任
何程序，只要它的适用而不仅限于很小一部分用户，都可以成为操作系统的有用组
成部分。甚至游戏程序也包括在任务清单之内——从工程一开始就这样。UNIX包括
了游戏程序，自然GNU自然也该这样。但游戏没有兼容性问题，因此我们无须原样
照搬UNIX的游戏。相反，我们列举了用户有可能会喜欢的各种类型的游戏。
GNU Library GPL
GNU C Library使用了一种特殊的“Copyleft”方式，称为“GNU Library
General Public License”（LGPL），允许专有软件可以同Library链接，为什么要
留这样一个例外呢？这并非一个原则问题；没有任何原则允许专有软件有权包括我
们的代码（何必要为一个早已决心拒绝与我们共享的项目费力？）。对于C Library
应用GPL，或者任何Library应用GPL，属于策略问题。
C Library完成的是普遍性的工作；任何专有系统或者编译器都伴随着一个C
Library，因此，限制我们的C Library只能为自由软件使用不会为自由软件带来任
何优势 -- 这只能阻碍它被采用。
有一种系统是例外：在GNU系统上（包括GNU/Linux），GNU C Library是唯一的
C Library。因此，GNU C Library 的发行条件决定是否有可能为GNU系统编译专有
软件，并没有任何道义上的理由允许GNU系统上的专有应用程序存在，但从策略上看，
不允许它们的存在更多地是阻碍GNU系统的使用，而不是鼓励自由应用的发展。
这就是为何 C Library应用 Library GPL是一个好策略的缘由。对于其它的
Library，则必须视具体情况具体分析，再作策略性的决定。如果一个 Library具有
特定的功能，足以帮助我们编写某种类型的程序，那么以GPL将它发布、并仅限于自
由程序使用，则不失为帮助其他自由软件开发者的一种手段，可以给予他们某种优
势去与专有软件竞争。
考虑GNU Readline，这是专为BASH命令行编辑功能所开发的 Library。Readline
是在通常的GNU GPL下发布的，而不是Library GPL。这或许降低了Readline被使用
的频率，但对我们不构成损失。同时，至少有一个有用的应用程序，因为要使用
Readline，所以被特别地转化成了自由软件。这是自由软件社团的一个真正胜利。
专有软件开发人员具有资金上的优势，而自由软件开发人员则需要相互之间共享长
处。我希望将来某天我们拥有大量的GPL涵盖的Library具有专有软件无法媲美的优
势，以提供有用的模块能为构建新的自由软件添砖加瓦，并为未来的自由软件运动
增添某种优势。
搔痒乎？
Eric Raymond 说：“每一项好的软件开发工作始于某个开发人员的搔痒”。
这在某些场合下是真的，但是许多GNU软件的基础部分是为了拥有一个完整的自由
操作系统为开发的。它们来自一种观点和计划，而不是一时的冲动。
例如，我们之所以开发了GNU C Library是因为一个类UNIX的操作系统需要一
个C Library，我们开发了BASH是因为类UNIX的操作系统需要一个外壳，我们开发
了GNU tar 是因为一个类UNIX的操作系统需要一个tar 程序。我之所以开发GNU C
Compiler、GNU Emacs、GDB和GNU Make也是出于同样的道理。
有些GNU程序是为了应付对我们的自由的威胁而开发的，因此，我们开发了
gzip 提替代Compress 程序，因为Compress采用了LZW专利，自由软件社团不能使
用它。我们找到了人开发LessTif，而且最近又找到了人开发 GNOME 和 Harmony，
以对付专有Library 的威胁（下面即将谈到）。我们正在开发 GNU Privacy Guard
来替代流行的非自由的加密软件，因为用户不应该被迫在隐私和自由之间作出选择。
当然，编写这些程序的人也开始对工作产生兴趣，而且各种人按照他们自己的需求
和兴趣给程序增添了许多特性。但是，这不是这些程序存在的原因。
不期望的发展
在GNU项目开始时，我想象我们将先开发完整个GNU系统，然后再发布它。但
后来所发生的情况不是这样。
由于GNU系统的每一个元件都是在UNIX系统上实现的，每一个元件都可以在
UNIX系统上运行，而且在完成GNU系统之前早就大名鼎鼎。其中的有些软件变得非
常流行，用户开始对它们进行扩充并移植——移植到各种不兼容的UNIX版本上，
有时是到其他平台上。
这一进程使得这些程序功能更加强大，并为GNU工程吸引了更多的基金和捐赠。
但是它也许将一个最小的可以运行的系统的完成时间拖延了几年，因为GNU开发人
员的时间花在了维护那些移植版本上，或者为已有元件的增添新的特性，而没有把
精力花在编写GNU系统上面尚未完成的那些元件上。
GNU HURD
到1990年时，GNU 系统几乎接近完成。主要所缺的东西就是一个内核。我们
决定设计一组运行在 Mach的基础上的服务器来作为我们的内核。Mach是在卡内基
·梅隆大学开发出来的微内核，后来在尤他大学得到了发展。GNU HURD是运行在
Mach之上的一组服务器的集合（或者称为“herd of gnus”），这些服务器完成
UNIX 内核所完成的各种不同的任务。Mach曾经许诺它将作为自由软件发行，由于
我们等待这一宣布，因此开发GNU HURD的启动时间被迫推迟了。
选择该设计的原因之一，是希望避免看似最为困难的工作：调试一个内核程
序而没有相应的源代码级调试器。这部分工作在Mach中已经完成了，而我们期望
用GNU调试器（GDB）调试作为用户程序的HURD服务器。 但我们耗费了许多时间
才使它成为可能，而且相互之间发送信息的多线程服务器也是非常难以调试的。
使HURD稳定运行这一工作已多花了几年的时间。
Alix
GNU内核一开始并不准备叫做HURD。它最初的名称叫做Alix——当时我所爱女
人的名字。她，作为一个UNIX系统管理员，曾经指出她的名字是如何吻合UNIX系
统版本的命名规范；她对朋友说过这样的玩笑话：“会有人用我的名字命名一个
系统内核。”当时我没有说什么，但决心用一个名叫Alix的内核让她大吃一惊。
这个名字并没延续下来。Michael Buchneil，内核的主要开发者（现在是Thomas），
更喜欢HURD这个名字，并把Alix重新定义为内核的一个组成部分——通过向各
HURD服务器发送信息而捕提系统调用并进行处理的那部分。
最后，Alix和我分手了，她也改了姓名；同时与之无关的是HURD的设计也作
了修改， C Library会向服务器直接发送信息，也就使Alix元件从设计中消失了。
但在这些事情发生前，她的一个朋友在HURD源代码中看到了Alix，并且告诉了她。
所以这个名字还是起过作用的。
Linux与GNU/ Linux
GNU HURD还不能投入正式使用。 幸运的是，有另一个内核可用。 1991年，
Linus Torvalds 开发了一个与UNIX兼容的内核并称之为Linux。 1992年左右，
Linux与尚未大功告成的GNU系统融合成为一个完整的自由操作系统（当然，两者
之间的结合本身就是一项非常艰巨的工作）。有了Linux，我们今天有了一个真
正的可以运行的GNU系统版本。
我们称这个系统版本为GNU/Linux，以表示它由GNU系统与作为内核的Linux组
合而成。
我们将来的挑战
我们已经证实，我们自己有能力开发一整套的自由软件。但这并不意味着我们
就不可战胜，或者势不可遏，我们正面临着几个挑战，它们使得自由软件前途难卜；
迎接这些挑战需要持续不懈的努力和耐力，也许会要以年来计算。这要求人们表现
出在珍视自由而不让任何人夺走它时的那种决心。
下面四个小节讨论这些挑战。
秘而不宣的硬件
硬件生产商日益趋向将硬件规格说明秘而不宣。这给编写自由的驱动程序以让
Linux与X Free86支持新硬件带来了困难。今天我们拥有完整的自由系统，但如果
我们不能支持明天的计算机，我们明天就会失去它。
有两种方式来对付这一问题。一是程序员可以通过反向工程搞清楚如何支持硬
件。另外，我们其他的人可以选择使用那些自由软件所支持的硬件，当我们的人数
增加时，保密的规格说明书就会不攻自破。
实施反向工程是一项繁重的工作，我们是否有程序员具有足够的决心去承担它
呢？会有的——如果我们能够建立这样一种强烈的感性认识，即自由软件是一个原
则问题，而非自由的驱动程序是不可容忍的。另外，我们大家会花费额外的金钱，
甚或是一点额外的时间以使用自由的驱动程序吗？会的，如果坚持自由的决心被广
泛接受的话。
非自由的Library
在自由的操作系统上运行的非自由的Library是针对自由软件开发人员的一个陷
井。这些Library吸引人的功能是诱饵；如果你使用了这些Library，你就掉进了陷
井，因为你的程序便不能成为自由操作系统的一个有用组成部分（严格地说，我们
可以收集你的程序，但它离开了Library而无法继续“运行”）。甚至更糟的是，如
果一个使用专有Library的程序流行起来的话，它会引诱其他不存疑心的程序员自投
罗网。
这个问题的第一个例证是80年代的 Motif工具包。尽管当时尚没有自由的操作
系统，但情况已经很清楚，Motif日后会给它们带来问题。GNU工程的回应有两种方
式：其一是请求各个自由软件项目同时支持Motif和自由的X toolkit widget（X工
具包窗口组件）；其二是请求人们编写一个自由的Motif替代品。这个工作花费了许
多年。Lesstif由“饥饿的程序员小组”（the Hungry Programmers）开发，直到
1997年才强大到足以支持绝大多数Motif应用程序。
大约是在相同的时间，另一个非自由的GUI工具包Library开始流行起来。这就
是Troll Technologies公司的Qt。最后，Qt被用于一系列重要的自由软件，KDE桌面
系统。
自由的GNU/Linux系统无法使用KDE，因为我们无法使用其Library。然而，某
些不那么遵从自由软件原则的GNU/Linux商业发行商将KDE添加到了他们的系统中—
—结果得到了一个功能增强但自由减少的系统。KDE开发小组正积极地鼓励更多的程
序员使用Qt，而数以百万计的新“Linux用户”从未有机会得到提醒，从而认识这样
做是有问题的。情况相当严峻。
自由软件社团以两种解决方法作出了反应：GNOME与Harmony。
GNOME，即“GNU网络化对象模式环境”，是GNU的桌面环境项目，在1997年由
Mignel de Icaza发起，在Red Hat（红帽子软件公司）的支持下开展。GNOME的目
标是用完全的自由软件实现与KDE相近的功能。它也有技术上的优势，例如支持一
组不同的语言，而不仅仅是C++。但它的主要目的在于自由：不再需要使用任何非
自由软件。Harmony是一个与KDE兼容的Library，使得不用Qt就运行KDE软件成为
可能。
在1998年11月，Qt的开发者宣布更改许可证协议，一旦实施，将使Qt成为自由
软件。虽然无法肯定，但我认为这部分上是由于整个社团对Qt作为非自由软件而显
示的强烈不满的态度使之作出了这个决定。（新的许可证不方便也不公正，因此将
来避免使用Qt还是可取的。）
我们将如何应对下一个诱人的非自由Library呢？整个自由软件社团都能理解
不受诱惑而掉进陷阱的需要吗？或者我们中的许多人会因放弃自由、追求方便而产
生一个重大问题吗？我们的前途取决于我们的哲学。
软件专利
我们面临最严重的危胁来自软件专利，它可以在长达二十年之久的时间内禁止
算法和特性为自由软件所用。LZW压缩算法的专利是1983年申请的，因此我们仍旧
无法发行自由软件以产生正确压缩的GIF文件。1998年，一个生成MP3压缩声音文件
的自由程序迫于起诉的威胁而撤消了发行。
对付专利也有多种办法：我们可以搜集某项专利无效的证据，我们也可以寻求
其它的途径以完成工作。但这两种方法都只适用于部分情况。当两者都失败时，一
个专利也许会迫使所有自由软件都缺乏用户希望的一些特性。这种情况一旦发生，
我们应该如何处理？
我们当中为自由的缘故而珍视自由软件的人总会坚持与它站在一起。我们会想
方设法完成任务，而不用已申请专利的特性。但那些因为期望自由软件有技术优势
而重视它的人，则有可能因为一项专利拖它的后腿而认为自由软件是失败的。因此，
尽管探讨“大教堂""开发模式的实用有效性以及自由软件的可靠性和力量大有裨益，
我们不应仅此而满足。我们必须谈自由，谈原则。
自由文档
我们的自由操作系统中最大的不足并不在软件——而是我们可以包括在系统中
优秀的自由文档不足。文档是任何软件包中基本的组成部分之一；一个重要的自由
软件包没有相应的优秀自由文档，那是一个大漏洞。今天我们有许多这样的漏洞。
自由文档如同自由软件，是自由的问题而不是价格问题。自由文档的判断准则
很大程度上与自由软件相同：给予所有的用户某种自由。再发行（包括商业销售）
必须被准许，无论是联机形式还是印刷品，以便使用手册能与每个自由软件的拷贝
相依为伴。
准许修改也是很关键的。但是从整体上来说，我并不认为准许人们修改所有的
文章与书籍是不可或缺的。例如，我就不认为，你或者我有必要授权别人随意改动
阐述我们的行动和观点的文章，就象这一篇。
但准许修改自由软件文档是有特殊理由的，当人们使用自己的权利修改软件，
并增加或修改其特性时，如果他们尽责，他们也会修改文档 -- 从而能够为修改后
的程序提供精确可用的文档。如果使用手册不允许程序员尽心尽力，善于始善终（
修改文档的话），那就不适应我们社团的需求。
某些种类的限制修改不会构成任何问题。例如，要求保存原作者的版权公告、
发行条件，或者所有作者的列表等，都是可以的。要求改动后的版本作出声明，以
表明它们已经改动也没有问题，甚至可以要求整个的章节不被删除或者修改也可以
接受，只要这些章节围绕非技术问题。
这类限制之所以不构成问题，是因为它们不妨碍尽责的程序员修改使用手册，
以适应修改后的程序。换言之，它们不阻碍自由软件社团最大限度地利用文档。
然而，必须能够修改手册的所有“技术”内容，然后通过所有普通的介质和所
有普通的渠道，来发布修改后的结果；否则，这些限制就会阻碍社团，手册就不再
自由，我们就需要另一份使用手册。
自由软件的开发者会有意识和决心以制作一整套的自由手册吗？再说一次，我
们的前途取决于我们的哲学。
我们必须谈论自由
今天估计约有一千万左右的用户在使用GNU/Linux系统，例如Debian GNU/Linux
与Red Hat Linux。自由软件已取得了这样的实际优势，以致于大量的用户为了纯
粹实用的理由蜂拥而至。
这一情况的良好影响是显而易见的：具有开发自由软件兴趣的人更多了，自由
软件产业的顾客也更多了，还有更强的能力以鼓励公司来开发商业化的自由软件而
不是专有的软件产品。
但人们对自由软件的兴趣增长，比对自由软件的哲学基础的认知来得更迅速，
这会引起麻烦。我们迎接上述机遇与挑战的能力取决于我们坚持自由的意志和毅力。
为了保证我们的社团具备这样的意志和毅力，我们有必要在新用户加入社团的时候
将这一观念贯输给他们。
但是我们这样的尝试正在失败：吸收新用户加入这一我们社团的努力要远大于
将我们社团宗旨传授给他们的努力。这两方面的工作都不可偏废，而且我们需要把
一碗水端平。
“开源软件”（Open Source）
向新用户传授自由的概念在1998年变得更为困难，因为社团的一部分决定停止
使用“自由软件”，而代之以“开源软件”（open-source software）。
倾向于这一说法的有些人希望能避免free的歧义性，即避免将“自由”与“免
费”相混淆——这是一个合理的目标。但是，另一些人的目的则是把激励自由软件
运动与GNU工程的原则精神搁置一旁，转而去吸引公司经理们和商业用户们，他们
中许多人所持的意识形态置利润于自由之上、社会之上、原则之上。因此，“开源
软件”的词义着重于创造强大的、高质量软件的潜力，而回避了自由、社会和原则
这些概念。
“Linux”杂志是这一倾向的明显代表——它上面充斥着可在GNU/Linux上运行
的专有软件的广告。当下一个Motif或Qt出现时，这些杂志是警告程序员们对它们
敬而远之，还是为它们敲锣打鼓呢？
来自公司的支持可以在很多方面为社团做出贡献，如果其他条件不变，它是大
有裨益的。然而，通过少提自由与原则以获取它们的支持将会是灾难性的；它会使
在自由软件外延的影响与对自由软件内涵的认识之间业已存在的不平衡进一步恶化。
“自由软件”与“开源软件”多多少少描述了软件的同一范畴，但强调了软件
的不同侧面和价值观。GNU工程将继续使用“自由软件”这一名词，以表示自由、
而不仅仅是技术，才是重要的。
尝试！
Yoda的哲学（没有“尝试”可言）听起来不无道理，但它不适用于我。当我忧
郁自己是否有能力完成工作、而且我不能肯定我所做的一切是否能够达到预期的目
标时，我已经完成了绝大部分工作。但无论如何，我仍旧尝试了，因为除了我以外，
没有其他人站在敌人和我的城市之间。让我自己吃惊的是，有时我成功了。
有时我会失败，我的一些城市会陷落。接着我发现另一座城市正面临威胁，我
得随之做好投入下一场战斗的准备。随着时光流逝，我学会了探察威胁，并将自己
置身于它们和我的城市之间，并呼吁其他黑客来与我并肩战斗。
时至今日，我常常不是唯一的战士。看见成群结队的黑客掘土加固战壕，我既
感到宽慰，也感到快乐，我明白城市会继续矗立在这里——至少现在如此。但失陷
的危险与岁俱增。现在微软已明确地表示将我们的社团列为打击目标。我们不能奢
望未来的自由会从天上掉下来。天上是不会掉馅饼的！如果你希望维护你的自由，
那么你必须做好准备捍卫它。