GNU操作系统与自由软件运动

unix-linux

http://www.blogchina.com/new/display/?id=11665

什么是自由软件？（附加）
作者：Richard Stallman

“自由软件”实际上指的是一种自由，而不是价格。为了理解这个概念，你应该想想“自由言论”，而不是“免费啤酒”。

“自由软件”是指用户运行、拷贝、研究、改进软件的自由，更准确地说，是指三种层次的自由：

研究程序运行机制，并根据你自己的需要修改它的自由
重新分发拷贝，以使其他人能够共享软件的自由
改进程序，为使他人受益而散发它的自由
你也许或花钱、或免费得到了GNU软件的拷贝，然而，不管你如何得到拷贝，你都有复制和更改软件的自由，在GNU计划中，我们使用“copyleft”来合法地保护每个人的自由。

关于“自由软件”、“copylefted软件”以及其他种类软件之间的相互关系的描述请参见Categories of Free Software。

当谈论自由软件时，最好避免使用诸如“赠送（give away）”或“免费（for free）”之类的词，这是因为这些词隐含了有关价格的问题，而不是自由。一些诸如“盗版（piracy）”之类的常用词体现了我们希望你不要赞同的意见。关于这些术语的使用请参见Confusing Words and Phrases that are Worth Avoiding。



GNU操作系统与自由软件运动　
夏昊 洪峰　译

最初的软件共享群体

　　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）所有者制订的规则是：
"与他人共享软件就是盗版行为；如果你需要对程序作任何修改，磕头央求我们吧。"

　　专有软件社会系统（即声明用户不能分享或修改软件的系统）的观念是反社会
的、不道德的、完全错误的。这一观点可能会让一些读者惊诧不已。但是，对于一
个基于分裂公众、使用户孤立无援的价值系统，我们还能说些什么呢？对这一观点
感到难以接受的读者，可能早已对专有软件熟视无睹，或者从专有软件工业的角度
出发才作出了这样的判断。这也难怪，因为软件出版商已经长期为此努力工作，以
使人确信对于这一事情只能有一个观察角度。

　　当软件出版商谈到"确保"他们的"权益"，或"禁止盗版行为"时，他们实
际上所说的东西是次要的。他们在版权声明中真正传递的信息却是他们认为不言自
明的假设，公众似乎应该不加批判地接受之。现在让我们来逐条地检查这些假设。

　　假设之一，是软件公司具备无可置疑的自然权力占有软件，从而有权凌驾于所
有用户之上。如果这确实是一种自然权力的话，那么无论它对公众有多大的伤害，
我们都无法反对。有趣的是，美国的宪法和司法传统拒绝这种看法；版权并非一种
自然权力，而是一种人为的、由政府强行实施的一种垄希?韵拗朴没Э奖吹淖匀?BR>权力。

　　另一种没有挑明的假设是，软件的唯一重要意义在于软件可以允许用户做什么
--而我们计算机用户不应该关心我们必须接受什么样的社会。

　　第三种假设是，如果不允许某个公司凌驾于其软件产品的用户之上，我们就不
会有任何可用的软件，或者永远不会有所需要的软件去完成这样或那样的特别任务。
这个假设一度显得颇有道理，但是后来的自由软件运动表明，我们可以创造出足够
多的有用软件，而无须加以一连串的限制。

　　如果我们拒绝接受上述假设，并将用户置于优先的地位，从普通的、常识性的
道德价值出发审视这些问题，我们就会得到截然不同的结论。计算机用户应该可以
自由地修改程序以适应他们自己的需求，可以自由地共享软件，因为帮助他人是社
会存在的基础。

　　这里没有足够的篇幅容纳得出这一结论的详细逻辑推理，因此我推荐你阅读我
们的Web主页，http://www.gnu.org/philosophy/why-free.htm。

艰难的道德选择

　　虽然我原来的群体已经消В??掏??床⒎遣豢赡埽?皇俏颐媪僖桓龅赖卵?BR>择。

　　一条简单的出路是加入专有软件世界，签署不公开协议，并许诺不再帮助我同
事中的黑客。这样做的结果很可能是我也开发软件，而且软件也以不公开协榈男?BR>式发布，从而对其他不愿意背叛同伴的人进一步施加压力。

　　我有可能由此而发财，而且也从编写代码中获得乐趣。但我明白，在我的职业
生涯结束时，我回过头来看到的景象将是这些年来筑起高墙林立，并将人们分隔开
来，我会觉得自己的一生努力的结果会把这个世界搞得更糟。

　　在此之前，我已有过接受不公开协议的经验。当时，别人拒绝向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软件、由其他人蛘咂渌??⑾钅砍鲇诟髯阅康亩?嘈吹某绦颍???蛭???BR>是自由软件，所以我们可以使用。

工程之发轫

　　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工程的哲学认为我们不应该使用专
有软件。然而，与在正当防卫中使用暴力相似，我按照这一推理得出了一个结论：
我确信，在为开发自由软件去替代专有软件，和帮助他人停止使用专有软件时，如
果需要使用专有软件的确是问题的关键的话，那么使用专有软件是合乎情理的。

　　但是，即使这样做是有理的锒瘢??暇谷匀皇且恢肿锒瘛＝裉煳颐遣辉儆涤?BR>任何版本的UNIX，因为我们已经使用了自由的操作系统替代了它们。如果我们不能
使用自由的操作系统去替代机器上的操作系统，那么我们会替换机器本怼?/P>

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工程吸引了更多的基金和捐赠。
但是它也许将一个最小目梢栽诵械南低车耐瓿墒奔渫涎恿思改辏?蛭狦NU开发人
员的时间花在了维护那些移植版本上，或者为已有元件的增添新的特性，而没有把
精力花在编写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。然???BR>些不那么遵从自由软件原则的GNU/Linux商业发行商将KDE添加到了他们的系统中-
-结果得到了一个功能增强但自由减少的系统。KDE开发小组正积极地鼓励更多的程
序员使用Qt，而数以百万计的新"Linux用户"从未有机会得到提醒，从而认识这样
做是有问题的。情况相当严峻。

　　自由软件社团粤街纸饩龇椒ㄗ鞒隽朔从Γ篏NOME与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呢？整个自由软件社团都能理解
不受诱惑而掉进陷阱的需要吗？或者我们中的许多人会因放弃自由、追求方便而产
生一个重大问题吗？我们的前途取决于我们的哲学。

软件专利

　　我们面临最严重的危胁来自软件专利，它可以在长达二十年之久的时间内禁止
算法吞匦晕?杂扇砑??谩?ZW压缩算法的专利是1983年申请的，因此我们仍旧
无法发行自由软件以产生正确压缩的GIF文件。1998年，一个生成MP3压缩声音文件
的自由程序迫于起诉的威胁而撤消了发行。

　　对付专利也有多种办法：我们可以搜集某项专利无效的证据，我们也可以寻求
其它的途径以完成工作。但这两种方法都只适用于部分情况。当两者都失败时，一
个专利也许会迫使所有自由软件都缺乏用户希望的一些特性。这种情况一旦发生，
我们应该如何处理？

　　我们当中为自由的缘故而珍视自由软件的人总会坚持与它站在一起。我们会想
方设法完成任务，而不用已申请专利的特性。但那些因为期望自由软件有技术优势
而重视它的人，则有可能因为一项专利拖它的后腿而认为自由软件是失败的。因此，
尽管探讨"大教堂"开发模式的实用有效性以及自由软件的可靠性和力量大有裨益，
我们不应仅此而满足。我们必须谈自由，谈原则。

自由文档

　　我们的自由操作系统中最大的不足并不在软件--而是我们可以包括在系统中
优秀的自由文档不足。文档是任何软件包中基本的组成部分之一；一个重要的自由
软件包没有相应的优秀自由文档，那是一个大漏洞。今天我们有许多这样的漏洞。

　　自由文档如同自由软件，是自由的问题而不是价格问题。自由文档的判断准则
很大程度上与自由软件相同：给予所有的用户某种自由。再发行（包括商业销售）
必须被准许，无论是联机形式还是印刷品，以便使用手册能与每个自由软件的拷贝
相依为伴。

　　准许修改也是很关键的。但是从整体上来说，我并不认为准许人们修改所有的
文章与书籍是不可或缺的。例如，我就不认为，你或者我有必要授权别人随意改动
阐述我们的行动和观点的文章，就象这一篇。

　　但准许修改自由软件文档是有特殊理由的，当人们使用自己的权利修改软件，
并增加或修改其特性时，如果他们尽责，他们也会修改文档 -- 从而能够为修改后
的程序提供精确可用的文档。如果使用手册不允许程序员尽心尽力，善于始善终（
修改文档的话），那就不适应我们社团的需求。

　　某些种类的限制修改不会构成任何问题。例如，要求保存原作者的版权公告、
发行条件，或者所有作者的列表等，都是可以的。要求改动后的版本作出声明，以
表明它们已经改动也没有问题，甚至可以要求整个的章节不被删除或者修改也可以
接受，只要这些章节围绕非技术问题。

　　这类限制之所以不构成问题，是因为它们不妨碍尽责的程序员修改使用手册，
以适应修改后的程序。换言之，它们不阻碍自由软件社团最大限度地利用文档。

　　然而，必须能够修改手册的所有"技术"内容，然后通过所有普通的介质和所
有普通的渠道，来发布修改后的结果；否则，这些限制就会阻碍社团，手册就不再
自由，我们就需要另一份使用手册。


　　自由软件的开发者会有意识和决心以制作一整套的自由手册吗？再说一次，我
们的前途取决于我们的哲学。

我们必须谈论自由

　　今天估计约有一千万左右的用户在使用GNU/Linux系统，例如Debian GNU/Linux
与Red Hat Linux。自由软件已取得了这样的实际优势，以致于大量的用户为了纯
粹实用的理由蜂拥而至。

　　这一情况的良好影响是显而易见的：具有开发自由软件兴趣的人更多了，自由
软件产业的顾客也更多了，还有更强的能力以鼓励公司来开发商业化的自由软件而
不是专有的软件产品。

　　但人们对自由软件的兴趣增长，比对自由软件的哲学基础的认知来得更迅速，
这会引起麻烦。我们迎接上述机遇与挑战的能力取决于我们坚持自由的意志和毅力。
为了保证我们的社团具备这样的意志和毅力，我们有必要在新用户加入社团的时候
将这一观念贯输给他们。

　　但俏颐钦庋?某⑹哉?谑О埽何?招掠没Ъ尤胝庖晃颐巧缤诺呐?σ?洞笥?BR>将我们社团宗旨传授给他们的努力。这两方面的工作都不可偏废，而且我们需要把
一碗水端平。

"开源软件"（Open Source）

　　向新用户传授自由的概念在1998年变得更为困难，因为社团的一部分决定停止
使用"自扇砑?，而代之以"开源软件"（open-source software）。

　　倾向于这一说法的有些人希望能避免free的歧义性，即避免将"自由"与"免
费"相混淆--这是一个合理的目标。但是，另一些人的目的则是把激励自由软件
运动与GNU工程的原则精神搁置一旁，转而去吸引公司经理们和商业用户们，他们
中许多人所持的意识形态置利润于自由之上、社会之上、原则之上。因此，"开源
软件"的词义着重于创造强大的、高质量软件的潜力，而回避了自由、社会和原则
这些概念。

　　"Linux"杂志是这一倾向的明显代表--它上面充斥着可在GNU/Linux上运行
的专有软件的广告。当下一个Motif或Qt出现时，这些杂志是警告程序员们对它们
敬而远之，还是为它们敲锣打鼓呢？

　　来自公司的支持可以在很多方面为社团做出贡献，如果其他条件不变，它是大
有裨益的。然而，通过少提自由与原则以获取它们的支持将会是灾难性的；它会使
在自由软件外延的影响与对自由软件内涵的认识之间业已存在的不平衡进一步恶化。
　　"自由软件"与"开源软件"多多少少描述了软件的同一范畴，但强调了软件
的不同侧面和价值观。GNU工程将继续使用"自由软件"这一名词，以表咀杂伞?BR>而不仅仅是技术，才是重要的。

尝试！

　　Yoda的哲学（没有"尝试"可言）听起来不无道理，但它不适用于我。当我忧
郁自己是否有能力完成工作、而且我不能肯定我所做的一切是否能够达到预期的目
标时，我已经完成了绝大部分工作。但无论如何，我仍旧尝试了，因为除了我以外，
没有其他人站在敌人和我的城市之间。让我自己吃惊的是，有时我成功了。

　　有时我会失败，我的一些城市会陷落。接着我发现另一座城市正面临威胁，我
得随之做好投入下一场战斗的准备。随着时光流逝，我学会了探察威胁，并将自己
置身于它们和我的城市之间，并呼吁其他黑客来与我并肩战斗。

　　时至今日，我常常不是唯一的战士。看见成群结队的黑客掘土加固战壕，我既
感到宽慰，也感到快乐，我明白城市会继续矗立在这里--至少现在如此。但失陷
的危险与岁俱增。现在微软已明确地表示将我们的社团列为打击目标。我们不能奢
望未来的自由会从天上掉下来。天上是不会掉馅饼的！如果你希望维护你的自由，
那么你必须做好准备捍卫它。

Berkeley Unix 二十年历史之回顾
-----从AT&T拥有版到自由可再发行版

早期历史

1973年11月，在Purdue大学召开的"操作系统原理研讨会"上，Ken Thompson 和Dennis Ritchie发表了第一篇关于Unix的论文。 当时California大学Berkeley分校的Bob Fabry教授也正好在会场上，他立刻对此发生了兴趣，并得到了一份操作系统的拷贝，准备在Berkeley分校进行实验。

当时，Berkeley仅有大型的计算机主机系统在做一些批处理工作。因此这项事业的第一个定单是得到一台PDP-11/45计算机，以运行当时的Unix Version 4。 Berkeley的计算机系、数学系和统计系共同出资购买了这台PDP-11/45。 在1974年元月份，第四版本（Version 4）的Unix 磁带交付学校使用，学校当时指定当时上研究生的Keith Standiford将这个操作系统安装到了这台机器上。

尽管身在Purdue的Ken Thompson没有参与在Berkeley安装这一操作系统，因为他要负责在其他地方的安装系统，但是在Berkeley安装的系统上出现了几次奇怪的系统崩溃，因此很快就需要像他这样富有经验的专家来帮助解决。 当时Berkeley仅有一台300-波特率的声频耦合式的调制解调器，且没有自动应答功能，所以Thompson需要事先通过电话通知机房的Standiford，让他将电话线插入调制解调器中。 通过这种方法，Thompson可以从新泽西州远程地对崩溃了的系统进行调试。

许多次系统崩溃的原因在于磁盘控制器不能可靠地执行叠加搜索，与通常的文档搜索不同，Berkeley 的PDP-11/45计算机是Thomspson所遇到的首批在同一个控制器上有两个磁盘的系统之一！ Thompson的远程调试也是后来延续的Berkeley和Bell实验室之间合作的第一个例子，Bell实验室的研究人员乐意助人，他们同意将他们的工作成果与Berkeley进行分享，这极大地加快了Berkeley软件的改进工作。

尽管Unix很快就开始运行起来，而且很可靠，但Berkeley计算机系、数学系和统计系之间的冲突很快就导致了新的问题：数学系和统计系想运行DEC的RSTS系统。经过多次讨论后，他们达成了妥协，每个系可以有每班8个小时的时间运行计算机系统，即Unix运行8个小时后，再运行16个小时的RSTS。 为促进公平性，运行时间段的切换每天进行，因此第一天Unix从上午8点运行到下午4点，然后是从第二天的下午4点到第二天的午夜，接着是第三天的凌晨到上午8点。 尽管这个时间表异乎寻常，但是学习操作系统课程的学生们更喜欢在Unix系统上做项目，而不是在批处理机上。

Eugene Wong教授和Michael Stonebraker教授都感到在批处理环境限制下的工作很别扭，因此他们的INGRES数据库项目成为第一组从批处理机移至Unix交互环境下开发的项目，但他们很快就发现了缺乏机器运行时间，而且在PDP-11/45上的需要在奇数小时才能进行工作的确让人忍受不了，因此在1974年的春天，他们购买了一台PDP-11/40以运行新的Unix Version 5。 随着1974年秋天第一个INGRES分发版的发行，INGRES项目小组成为计算机系中第一个发行软件的小组，在随后的六年中，他们一共交付了几百份INGRES磁带，大大地帮助了Berkeley在设计和建立真正系统领域树立起了良好的信誉。
尽管INGRES项目组后来不再使用PDP-11/45，但对使用机器的学生来讲，仍然存在运行机器时间的不足，为了弥补这种缺陷，Michael Stonebraker教授和Bob Fabry教授，从1974年6月开始着手为计算机系购买两台供教学使用的PDP-11/45。 1975年初，钱已到位，但几乎在同时，DEC发布了PDP-11/70，一种显得比PDP-11/45更高档的机器，因此原本计划在1975年秋天购买两台PDP-11/45的钱转而购买了一台PDP-11/70。 PDP-11/70交付学校使用时，碰巧Ken Thompson决定作一年的休假。California Berkely分校是Ken Thompson的母校，Ken Thompson决定去Berkely分校当访问教授。 后来Thompson 同Jeff Schriebman与Bob Kridle三人一道在新安装的PDP-11/70上合作开发了后来的Unix Version 6。

1975年的秋天，来了两位当时还不出名的研究生，他们是Bill Joy和Chuck Haley，两人立刻都对这一新的系统产生了兴趣，最初他们开始在一个Pascal系统上工作，该系统由Thompson在PDP-11/70机房调试时与机器集成在一起，他们扩展了并有效地改进了Pascal解释器，并使它成为学生们一个可选的一个编程系统，因为它具有极好的错误恢复机制和快速编译时间及运行时间（compile and execute time）。

随着Model 33 teletypes被ADM-3屏幕终端所取代，Joy和Haley开始感到ed编辑器存在的局限性，他们从伦敦的Queen Mary学院George Coulouris教授那里得到了一个名为em的编辑器，并开始着手开发一种每次一行的编辑器，名为ex。

1976年夏末，Thompson离开了Berkeley，而此时Joy和Haley开始对Unix的内核发生了浓厚的兴趣，在细心的Schriebman教授关照下，他们将来自 Bell实验室的经过了"五十次变化"磁带的修正和改进部分第一次成功地安装到了系统上。 他认真地研究了源代码，并建议完成几处小的改进，以在某种程度上解决内核瓶颈的问题?
早期发行版本

在人们对Pascal编译器上错误恢复工作感兴趣的同时，人们也开始提出了系统拷贝的需求。在1971年初，Joy完成恕?erkeley Software Distribution"的合并。 这个第一发行版包括Pascal系统，而且在Pascal源代码的一个难懂的子目录下，附上了编辑器ex。 过了一年，Joy作为发行组的秘书，寄出了大约三十份免费的系统拷贝。

这时出现了一些ADM-3a终端，它们提供屏幕定址光标的功能，Joy最终开始编写vi，为Berkeley带来一种基于屏幕的编辑器，但很快他就发现自己遇到了麻烦。在学校里，经费捉襟见肘是常有的事，老的设备从不会立刻被替换掉，Joy没有进行优化和更新几个不同终端的支持工作，而是决定采用一个小的解释器以重画屏幕，从而加强屏幕管理，此解释器由终端特性描述所驱动，此项工作的后来的结果是产生了termcap。

到1978年中期，软件发行版显然需要升级了，用户社团一直在不断扩大，在用户反馈意见的基础上，修改后的Pascal系统已明显变得更加健壮，并且它被分成了两个分支，以使其能运行在PDP-11/34s上，更新的结果就产生了"第二版Berkeley软件发行版"，这一名称很快就被简称为2BSD，其中包含了增强的Pascal系统，vi和为几种终端而开发的termcap。 Bill Joy又一次单枪匹马地将各发行版集中在一起，回答用户的电话询问，并根据用户的反馈意见对系统中作了改进。过了一年，将近有75份磁带交付给了用户。 尽管Joy在随后的一年里转而工作于其他的项目，但是2BSD发行版的发行工作没有停止，而且越来越兴旺。 这一发行版的最后一版称为2.11BSD，这是一个完整的系统，至今仍运行在世界各个角落的几百台PDP-11上。

VAX Unix

1978年初，Richard Fateman教授开始寻找一台能够有较大地址空间的机器，以便他能继续在Macsyma 小组里的工作（最初开始于PDP-10上），那时刚问世的VAX-11/780满足了他的要求并且符合其财政预算，Fateman和其他十三个系里的同事共同提出了一份NSF提案，并将其他系的资金合并在一起，最终购买了一台VAX计算机。

最初的VAX运行的是DEC的VMS操作系统，但系里已习惯使用Unix环境，并想继续使用Unix， 所以在VAX到来不久， Fateman得到了由Bell实验室的John Reiser和Tom London开发的将Unix移植到VAX的32/V的拷贝。

尽管32/V在VAX机上提供了UnixVersion 7环境，但它不能很好地利用VAX硬件的虚拟内存能力，正象PDP-11系列中的早期机器一样，它是一种完全基于转换（swap-based）的系统。对于Berkeley的Mascsyma小组来说，缺少虚拟内存就意味着进程地址空间受限于物理内存的大小，在新的VAX机器上，最初物理内存为1 MB。

为了减轻这个问题所带来的矛盾， Fateman与Domenico Ferrari教授进行了讨论，Domenico Ferrari教授是Berkeley系统委员会的成员，他开始调查让Fateman的小组为Unix写一个虚拟内存系统的可能性。Ferrari教授有一位学生，名叫Ozalp Babaoglu，他开始寻找一些关于在VAX机器上实现设置分页系统的方法。 由于VAX机缺少参照位（reference bits），因此他的工作变得非常复杂。

当Babaoglu接近于完成他的第一个方法时，他与Bill Joy取得了联系，请Bill Joy帮助他理解Unix内核的复杂内容。 与Babaoglu的交流使Joy对其工作发生了兴趣，并帮助Babaoglu将代码集成到32/V中，后来又接着帮助进行调试工作。

不幸的是，Berkeley仅有一台VAX机， 这台机器既要用于系统开发，又要用于一般的工作。因此，在圣诞节的假期后几个星期里，具有忍耐心的用户群体发现他们自己开始交替地登录到32/V和"虚拟VAX/Unix"系统上。他们在后一种系统上运行时有时会突然中止，几分钟后紧随着就出现了32/V登录提示信息。到1979年元月，大部分臭虫被解决，32/V便已被载入历史而废弃了。

Joy看到32位的VAX很快会取代并淘汰掉16位PDP-11，于是开始将2BSD软件移植到VAX机器上，当时Peter Kessler和我移植了Pascal系统。Joy 移植了 ex和vi编辑器、C Shell和其它2BSD发行版中大量的小程序。1979年末，一个完整的发行版本被集成在一起。这个发行版本包括了虚拟内存内核，标准32/V实用程序，以及2BSD中的一些附加程序。1979年12月，Joy 首先发布了将近100份拷贝的3BSD，即Berkeley的第一个VAX发行版。

Bell实验室的最后版本为32/V，以后来自AT&T的所有Unix版本，从最初的System III到后来的System V，都由注重稳定性的商业版本的不同组织管理。伴随着Unix的商业化，Bell实验室的研究员开始感到作为兴起的Unix研究的源头有些力不从心了。当研究社团继续修改Unix系统时，他们发现需要有一个组织能开发研究版。 由于Berkeley对Unix开发的介入很早，且具有发布基于Unix实用程序的历史，Berkeley很快步入并取代了先前Bell实验室的角色。

DARPA 支持

此时，在国防部高级研究项目署（Defense Advanced Research Projects Agency，DAPRA） 的规划者们的办公室里展开了一场对Berkeley工作起着重大影响的讨论，DARPA的早期成果之一是成功地建立了一个覆盖全国范围的计慊??纾?粤?铀?械闹饕?芯恐行摹?在那时，他们发现许多研究中心使用的计算机已经接近最后使用期限，并开始更新，而更新过程中最为耗费资金的部分是将研究软件移植到新机器上。 另外，许多地点不能共享他们的软件，因为硬件和操作系统不??
因为研究目的广泛而且不同研究小组的计算需求不同，他们无意依赖于单一某个生产厂商，因此仅选择一家硬件供应商是不切实际的，因此DAPRA的规划者们认为最好的解决方法是在操作系统这个级别进行统一工作。 经过多次讨论后，因为Unix被证实具有可移植性，所以规划者们决定采用Unix作为标准。

在1979年秋，Bob Fabry应DARPA对Unix发生的兴趣，写了一份提议书，建议说Berkeley可以开发了一种增强版本的3BSD给DARPA使用。Bob Fabry将其提案作了一份拷贝并带到了DARPA图象处理和VLSL 承包商的会议上，并给了ARPAnet的开发者代表，Bolt Beranek和Newman。当时有一种保守的看法是Berkeley是否能研制出一种工作系统，但是1979年12月3BSD的发布后，这些疑虑便烟消云散了。

随着3BSD版本日趋增长的良好信誉，更加确定了Bob Fabry的断言。Bob Fabrvy和DARPA签订了一份从1980年4月开始，共18个月的合同，这份合同要求Berkeley按DARPA 承包商的需要增加一些特性。在这份合同的赞助下，Bob Fabry建立了一个小组，命名为计算机系统研究小组（Computer System Research Group），或简称为CSRG。他立刻雇用了Laura Tong负责项目管理，Fabry转而将注意力放在找到一个项目领导者以管理软件开发，Fabry认为Joy刚刚通过他的博士学位（Ph. D）资格考试，他会将精力集中于完成学位上，而不会考虑软件开发的位置，但Joy有他的自己的想法。三月上旬的一天晚上，Joy给Fabry打了一个电话，表示他有兴趣负责进一步开发Unix。 尽管 Fabry对这个想法感到惊讶， 但Fabry考虑后还是立创鹩α薐oy的请求。

于是项目立刻开展起来，Tong建立了一套发行系统，能够比从前Joy的发行系统处理更大容量的定单。Fabry开始同AT&T的Bob Guffy及California大学的律师合作，制定所有人都能接受的正式Unix版本的条款。Joy集成了Jim kulp的作业控制机制，并增加了自动重启动功能，1K块文件系统，及宰钚耉AX机器（VAX-11/750）的支持。到1980年10月时，推出了一个粉饰一新的发行版本，称为4BSD，其中包括Pascal编译器，Franz Lisp系统，和一个增强的邮件处理系统。在其9个月生命期中，差不多发行了150份拷贝。版权的控制是以大学为单位的，而不是以每台机器为基础来计算，因此该发行版在近500台机器上运行。

随着发行版数量快速而且广泛地增加，以及Berkeley的 Unix的能够指望具有可见性，几个尖锐的问题开始冒了出来，Stanford研究院的David Kashtan 写了一篇论文，描述了他在运行VMS和Berkeley Unix 的测试结果。这些测试显示出在VAX机运行Unix系统的几个性能问题。于是Joy将他未来的计划暂时搁置在一旁，在长达几个月的时间中，他系统地优化了Unix的内核。后来他又花了几个星期写了一篇应答文章，说明在Kashtan的测试点上运行Unix时的性能可以达到良好的状态，并能等同于VMS。

后来Berkeley没有继续发行4BSD，而是在优化后的系统加上Robert Elz的自动配置代码，在1981年的6月发布了4.1BSD。 在随后的两年时间里，大约交付了400份的发行版。最初Berkeley准备之称为5BSD，但是遭到AT&T的抵制， 因为AT&T觉得用户会将它与他们的Unix版本 -- Unix System V相混淆。所以，为了解决该问题，Berkeley同意改变其将来版本的命名规定，将版号仅保留在4BSD上，以后只增加小的版本号。

4.2BSD

4.1BSD发布后，许多关于性能的疑问被解决，DAPRA非常满意第一个合同的结果。紧接着又与Berkeley签订了一个为期两年的合同，并且合同资助额翻了五倍，合同金额的一半用于Unix项目的开发，其余部分用于计算机系的其它研究。合同的目的是要能在系统上完成主要工作，使DAPRA的研究社团能够很好利用它进行工作。

根据DAPRA社团的需要，Berkeley很快就制定出了对系统的进行修改的工作目标，在新系统中，特别强调要求包含一个更快速的文件系统，以使其吞吐量能够适应磁盘技术所达到的速度，支持处理几个GB地址空间的需求，提供灵活的进程间通信机制，以允许研究者能在分布式系统上工作，并能集成网络支持功能，以使运行新系统的机器能很容易地加入到ARPAnet中。

为帮助定义这一新系统，Duane Adams作为DAPRA在Berkeley的合同监督人，组成了一个小组称为"掌舵委员会"（Steering Committee），以协助指导设计工作，并确保研究社团的需求能得到满足。这个委员会在1981年4月到1983年1月间每年聚会两次，它的成员包括了Caifornia 大学Berkeley分校的Bob Fabry、Bill Joy和Sam Leffler；Bolt的Alan Nemeth、Rob Gurwitz、Beranek和Newman； Bell实验室的Denis Ritchie； Stanford大学的Keith Lantz；Carnegie-Mellon大学的Rick Rashid； MIT的Bert Halstead；Information Sciences Institute的Dan Lynch；DARPA的Duane Adms和Bob Baker； 以及California大学Los Angeles分校的Jerry Popek。从1984年开始，这种会议增加了几个工作室，规模得到了扩大，而且人数也越来越多。

1981年7月，在新系统中建议所包含特性的原始文档提交给了"掌舵委员会"和Berkelely以外的人员，引起了许多长时间的争论。 1981年夏天，我开始介入到CSRG的工作中，并参与了新的文件系统的设计工作。在那个夏天，Joy集中精力于设计进程间通信机制的原型版本。1981年秋天，Sam Leffler加入到CSRG中，并作为一名全职人员与Bill Joy一同工作。

当Rob Gurwitz在Berkeley发布了早期的TCP/IP协议后，Joy将其集成到系统中并优化了其性能，此项工作使得Joy和Letfller清楚地意识到新系统应不仅针对DARPA标准网络协议，还要支持更多的东西。 为此，他们重新设计了软件的内部结构，精炼了接口，以使得多种网络协议能够被同时使用。

在完成内部重构和将TCP/IP协议集成到IPC 功能的原型中时，还创建了几个简单的应用程序，可以让本地用户存取远程资源，这些程序包括rcp，rsh，rlogin和rwho，它们当时是作为暂时性的实用程序设计的，而且当时就希望最终要用更为合理的实用程序去替代它们 （所以在命令前加了一个"r"前缀以示区别）。该系统被称为4.1a只在内部使用，于1982年4月发布。当时谁也没有指望它会被广泛地发行，不过这一系统原始拷贝使大家更加迫切期待着4.2版本尽快问世。

4.1a系统在它完成之前早就作废。但是在创建新系统提案的修订版时，用到了来自用户的有价值的反馈信息，这一新系统的提案称为"4.2BSD系统手册"，该文档发表于1982年2月，它包括了将在4.2BSD中实现的使用系统功能的用户接口提案的简要描述。

在开发4.1a的同时，我完成了新文件系统的设计，并在1982年6月底将它集成到4.1a内核中。这一开发的最终结果是4.1b的诞生，但只是运行在Berkeley选定的几台用于开发机器上。Joy觉得系统中还存在几个重要的悬而未决的问题需要解决，因此最好是避免发行，即使在Berkeley内部也不发行，最关键的问题是它要求每台机器的文件系统被转储和备份，并完成从4.1a到4.1b的转换。 在文件系统的稳定性被证实后，Leffler继续添加与新文件系统相关的系统调用，而Joy则花时间修订了进程间通信机制功能。

在1982年的春末，Joy 宣布他开始进入Sun Microsystems公司工作，夏天过后，他将工作分开，一部分时间为Sun工作，另一部分时间为Berkeley工作，他花费了大量的时间修订了进程间通信机制，并重组了Unix的内核源码以减小对机器的依赖性。Joy离开后，Leffler接管了整个项目的开发，开发的最后完成期限已被设定，而且Berkeley汛鹩?APRA社团将在1983年春天发行完成的版本。由于时间所迫，Berkeley对开发所剩下的工作进行了评定，并设定了各项工作的优先级，特别需要指出的是，增强虚拟内存和进程间通信中最复杂部分的设计都降至低的优先级（后来被完全搁置）。 同时，在Unix系统完成一年后，Unix社团的期望值也更为高涨，Berkeley决定在最终的系统完成之前，需要推出一个中间状态的版本，以使人们保持对它的关注。这个系统就是4.1c，在1983年四月发布，许多厂商使用该版本准备将4.2移植到他们的硬件上。从4.1c版本开始，Berkeley 聘用了Pauline Schwartz接管发行工作。

1983年6月， Bob Fabry将CSRG的管理控制权变给了Domenico Ferrari教授和Susan Graham，并开始休假，以结束他前四年紧张而狂乱的生活。 Leffler继续完成系统，实现了新的信号机制，加入了网络支持功能，重做了单独的 I/O系统以简化安装过程，集成了从Robert Elz处得到的磁盘配额功能 （disc quota），更新所有文档，跟踪从4.1c版本后出现的臭虫。在1983年8月，Berkeley发布了正式的系统，这就是4.2BSD。
当4.2BSD完成后， Leffler离开Berkeley去了Lucasfilm，他的位置由Mike Karels取代，Karels早期发行2.9BSD PDP-11软件时积累的经验为他的新工作提供了理想的背景。1984年12月，我获得了博士学位，并加入Karels的工作组，成为CSRG的一名全职工作人员。

4.2BSD的知名度是令人印象深刻的，在18个月内，就签发了1000多份站点许可证。可以说，随后发布了更多数量的4.2BSD的发行版，其数量超过了Berkeley先前所有软件发行版数量的总和。 大部分的Unix厂商愿意发行4.2BSD，而不是商业版本的AT&T的System V，原因在于System V既无网络功能，又无Berkeley的快速文件系统。 BSD版的Unix在商业市场上占主导地位的情况只持续了几年，随后又回到最初的状态，因为后来System V中集成了网络功能和其它一些4.2BSD所增强改进部分，所以厂商们通常又回到最初的选择。不过，后来的BSD开发成果仍继续集成到System V中。

4.3BSD

4.1BSD发布后，很快招来了许多的批评，大部分人是报怨系统运行太慢，这个问题并不奇怪，是因为新的功能并没有被优化，而且内核中的许多数据结构与这些新的功能的用途不很协调。Karels和我在第一年的项目工作中主要集中精力于优化系统，使系统变得更加漂亮。

我们花了近两年的时间优化系统和精炼联网功能的代码。 在1985年6月的Usenix会议上宣布了4.3BSD将在那个夏天末发布的消息。 但是，我们的发布计划由于BBN中的一些人的原因而突然中断，他们指出我们从来没有用他们最终版本的联网代码更新4.2BSD，而我们仍在使用他们许多年前提供的非常粗糙的初始原型。他们对DARPA报怨说，Berkeley实现接口，而BBN则希望实现协议，所以Berkeley应该在4.3BSD中用BBN的设计结果取代TCP/IP代码。

Mike Karel拿到了BBN代码，并对其自从BBN将初始原型交付Berkeley以来的工作进行了评估。 他决定最好的计划是将BBN代码中体现好的想法集成到Berkeley的基础代码中，而不是替换Berkeley的代码基础。 保留Berkeley代码基础的原因在于，在4.2BSD广为发行之后，代码基础已经得到了大量的测试和改进。 但是，作为折衷方案，他提出在4.3BSD发行版本中包含两者的代码，由4.3BSD的用户自己在内核中选择使用哪一种代码。

在考虑了Mike Karel的决定后，DARPA认为发布两套代码基础会导致不必要的互操作性问题，并最终决定只发布一套代码。为了决定选择究竟采用哪套代码基础，他们将两者都交给了Ballistics 研究实验室的Mike Muuse作为独立的第三方进行评估。 经过一个月的评估，Mike Muuse提供了一份评估报告，报告中认为Berkeley的代码更为有效，但BBN代码在处理堵塞（Congestion）时效率更高。但是有一点最关键：Berkeley在所有测试中均无故障，而BBN代码仅在一些严格条件下运行时会死机。DARPA最后决定4.3BSD应该采用Berkeley代码基础。

修饰一新的4.3BSD系统终于在1986年6月正式发布。就像先期所预料的那样，它平息了许多用户对其性能上报怨，情况与4.1BSD发布后平息了对4BSD版本报怨的情形非常类似。 尽管许多的厂商已开始走回头路，转回到了 System V上，但4.3BSD的大部分成果被集成到他们的系统中，特别是联网的子系统。

在1986年10月，Keith Bostic加入了CSRG。 他以前一直努力将4.3BSD移植到PDP-11上。骋用他的一个条件是，允许他完成他这个项目。 那时Kanel和我都不相信能得到一个系统，可以在VAX上编译成250KB，并满足PDP-11 的64KB地址空间的要求，但我们同意Bostic可以尝试实现他的这一设想。 让我们大为惊奇的是，移植工作非常地成功，他使用了一个复杂的叠加集（set of overlays）和在PDP-11上的辅加处理器语句（auxiliary states states），其结果是发布了2.11BSD，由Casey Leedom和Bostic完成，该系统到1998年还运行在一些现存的PDP-11上。

同时，情况越来越清楚地表明VAX体系已经步入其生命的晚年，当时的确是考虑用其它的机器运行BSD的时候。 有人提出由Computer Consoles公司制造的一种新体系的时间已经来临，并被称为Power 6/32。不幸的是，在公司决定改变其战略方向时，该体系便死掉了。但是他们的确提供了几台机器给CSRG使用，让我们能够完成该项工作。于是由Bill Joy开始，将BSD内核分解为依赖于机器的部分和独立于机器的两部分，此项工作的结果导致了1988年6月4.3BSD-Tahoe的发布，这一版本名字中的Tahoe来自Computer Console公司在开发过程中使用的名字，他们原计划将它最终发布为Power 6/32用于机器上。 尽管Power 6/32有用的生命期不长，但将BSD内核分为"依赖于机器"和"独立于机器"两部分是非常有价值的，它可使BSD移植到众多的体系结构中。

Networking，Release 1

到4.3BSD-Tahoe版本的发布时，所有的BSD用户必须先得到一份AT&T的源代码许可证，这是因为Berkeley 从来没有仅以二进制方式发行过BSD系统，发行版本总是包含了系统每个部分完整的源码。 Unix系统和BSD系统的历史表明，给用户提供源代码具有强大的威力。 用户们不是被动地使用系统，而是可以积极地修改臭虫，提高性能和功能，完善功能，甚至添加一些崭新的持性。

随着AT&T源代码许可证的费用增加，一些希望能够使用BSD代码为PC市场制造独立的基于TCP/IP联网产品的厂商们发现，按照每个二进制拷贝交费是行不通的。于是他们要求Berkeley将联网的代码和实用程序从BSD发行版中分离出来，并且给他们签发许可证条款，而不需要AT&T的源代码许可证。 显然，TCP/IP联网代码不存在于32/V中，所以它完全是由Berkeley和Berkeley的一些贡献者开发的， BSD最初的联网代码和支持性实用程序在1989年6月作为"Networking Release 1"发布，这是第一套由Berkeley发布的"自由可再发行"（freely-redistributable）的代码。

这个许可证的条款是宽大的，它允许被授权的用户以源代码或二进制形式发布修改过的、或未修改过的代码，并且可以不向Berkeley申报财务报告和版税，唯一的要求是在源代码文件中原封不动地保留Berkeley的版权声明，并且含有Berkeley代码的产品需在文档中声明其产品包括来自于加州大学和其贡献者的代码。 尽管从Berkeley那里得到一份磁带需付1000美元的费用，但任何人都可自由地从已经获得了Berkeley拷贝的人那里获得新的拷贝，实际上，许可证条款公布后不久，就有几个大的站点已将代码存放在匿名FTP机器上。因为许可证的条款如此宽容，所以几百个组织购买了磁带拷贝，CSRG当然很高兴，因为这笔收入有利于今后进一步的开发工作。

4.3BSD-Reno

同时，基础系统的开发仍在继续。虚拟内存系统（virtual memory system）的接口是在4.2BSD体系的文档中首次得到了描述的，虚拟内存系统最终被BSD采用。在大多数情况下，CSRG常常是试图发现一些现成的代码，并将其集成到系统中，而不是从头编写代码。 所以，我们没有设计一个新的虚拟内存系统，而是四处寻找已有的代码。 我们的第一个选择来自Sun Microsystems的SunOS系统中的虚拟内存低常?」芤欢扔幸恍┕赜?un想将代码提供给Berkeley的讨论，但后来便不了了之。于是我们作出了第二种选择，将 Cornegie-Mellon大学的MACH操作系统的虚拟内存系统集成到BSD中，Utah大学的Mike Hibler完成了将MACH的核心技术与4.2BSD体系手册中描述的用户接口进行合并（该接口也被SunOS选用）。

当时另外一个主要的补充是加进了与Sun兼容的网络文件系统（NFS）版本。 同样，CSRG也是避免了去动手编写实际的NFS代码，此项工作是由加拿大的Geulph大学的Rick Mocldem完成的。

尽管那时我们没有完整特性的4.4BSD可发布，但是CSRG仍决定发布一个过渡性版本，以取得另外的对这两个主要附加项功能的反馈和经验。此授权的过砂姹境莆?.3BSD-Reno，并在1990年早些时候发布，该版本是在内华达州的一个大的赌城被命名的，似乎向用户提供了某种暗示，表明运行过渡版本是多少有些赌博意味的。

Networking，Release 2

在一次CSRG的小组每周例会上，Keith Bostic提出了自由可再发行版（freely-redistributable）普及性的主题，并要求做一个扩展版以包括更多的BSD代码。Mike karel和我向Bostic指出，要发行系统中的那些大的部分是一项巨大的工作，但我们同意，如果他能处理怎样重新实现几百个实用程序和巨大的C Library，那我们就可以解决内核。karel和我私下里都觉得讨论到此结束，不会再有什么结果。

但这并没有妨碍 Bostic进行技术上的探索和大量的基于网络的开发工作，他要求其成员依据发布的描述从头改写Unix的实用程序。 作为补偿，他们仅要求能在Berkeley 贡献者列表上每一相应改写的实用程序旁列出他们的姓名。 此项工作开始进展很慢，并且大部分工作是琐碎的实用程序。 但是完整实用程序列表的不断增长，Bostic持续在一些像Usenix这样一些公众场合下向外寻找的贡献者。 贡献者的比例也保持继续增长，因此列表上的实用程序数量很快就在18个月内超过100个，几乎所有的重要实用程序和库都被重写。

后来，Bostic自豪地走进Mike karels和我的办公室，手里拿着清单，他想知道我们如何对内核做工作。 我们重新设定了我们的工作任务，Kavels，Bostic和我花了几个月的时间回顾整个发行版本，一个一个文件地看，去掉最初从32/V版本中产生的代码，当所有不必要的文件清除后，我们发现仅有6个内核程序仍然具有32/V版本的影响，而且重写起来很费劲。当时我们想如果我们能重写这6个文件，那么我们就能发布一个完整的系统，我们决定先是发布我们现有的程序。 但是，我们的确从Canifornilia大学行政管理部门的较高层人士那里寻求过对我们扩展版本的许可。经过多次内部讨论，并验证了我们对具有专有权利的代码的判断方法后，学校准许我们继续进行工作。

我们最初的想法是给我们第二个自由可再发行版本起一个全新的名字，但是我们知道要得到一个全新的版权并由大学律师批准，势必会有不必要地浪费资源屯涎邮奔洌??晕颐蔷龆ǎ?掳姹境莆狽etworking Release 2，因为我们可以在Networking Release 1版权许可证协议的基础上作一些修正。 于是，我们的第二个经过大量扩充的自由可再发行版本在1991年6月推出，Networking Release第二版的条款和花费与Networking Release第一版相同。和以前一样，几百个个人和组织付了每套1000$的费用从Berkeley购买了发行包。

在Networking Release 2发行版到完整的功能系统之间的间隙得到弥补以后，也就是在版本发布后的6个月时间内，Bill Jolitz已经重写了那6个漏掉的文件，他很快就发布了完整的可运行在386PC体系上的编译过和可启动的系统，他称之为386/BSD。 Jolitz的386/BSD发行版本几乎全是在网络上完成的。他把它放在匿FTP站点上，让任何需要使用它的人都能自由地下载。几个星期内，他就有了大量的追随者。

不幸的是，要保证一份全职工作的需要就意味着Jolitz不能够分出更多的时间来处理大量的臭虫和改进386/BSD。 所以，在386/BSD版本发布的几个月内，一群具有敏锐目光的386/BSD用户成立了一个小组，他们收集资源以帮助维护和增强后来的系统。他们的版本后来成为NetBSD 。 NetBSD小组侧重于支持尽可能多的平台，并继续按照CSRG所创立的研究风格进行开发。 直到1998年时，他们的发行版本仍仅能在网上传播，没有任何介质，他们的小组继续以最关键的核心技术用户为对象。有关NetBSD项目的详情，可参见http://www.netbsd.org。

在NetBSD小组成立后几个月，FreeBSD小组成立，其宗旨是仅支持PC体系并追寻一个数量更多（但更少技术化）的高级用户组，正如Linux所做的那样。 他们建立了精致的安装脚本并开始以低成本的CD-ROM发行他们的系统。 系统易于安装、强大的网上促销，以及像在Comdex上这样一些关键的贸易展览会上频频露面，这一切有机地结合在一起，掀起了又快又大的增长浪潮。 毫无疑问地，现在的FreeBSD的安装数量在所有Release 2派生系统中最多。

在Linux逐渐风靡的过程之中，FreeBSD也从Linux那里得到了帮助。它增加了一个Linux仿真模式，允许Linux binaries可运行在FreeBSD平台上，这个特性允许FreeBSD用户使用不断扩大的Linux应用程序，从而使FreeBSD变得更加健壮⒖煽浚?低承阅芨?谩８眯∽樽罱??枇艘桓觥?reeBSD 商店" （ 网址是 http://www.freebsdmall.com ）。它将许多的FreeBSD社团组织在一起，提供咨询服务、派生产品、图书及新闻札记等。
在90年代中期，从NetBSD小组中分离出OpenBSD小组，他们的技术宗旨在于提高系统的安全性，他们的市场目标是使得系统更易于使用并且更广泛地被采用，因此他们借用了FreeBSD发行版本便于安装的许多特性，并开始生产并销售CD-ROM。有关OpenBSD项目详细情况，可见http://www.openbsd.org。

官司

在一些小组组织起来，在Networking Release 2 磁带的基础上建立并发行自由可再发行的版本时，一家名为BSDI（Berkeley Software Design, Incorporated）的公司成立，以开发和发行以BSD代码为基础的商用的版本（更多有关BSDI的信息见http://www.bsdi.com），跟其他小组一样，他们也从那6个漏掉的文件开始的，也就是Bill Jolitz重写后放在386/BSD上的那6个文件。BSDI开始在1992年1月以每套995美元的价钱销售他们的系统，包括源代码和二进制代码。他们开始作广告， 宣称他们的价格只是System V的源代码加上二进制代码系统的99%，感兴趣的用户可致电1-800-ITS-Unix。

在BSDI的销售战役打响后不久，他们收到了来自Unix系统实验室（USL）的来信，这是一家AT&T拥有其大部分产权的机构，它主要从事开发和销售Unix。信中要求BSDI停止他们的Unix销售，特别是停用热线电话号码，尽管那个电话号码立刻被停用，并在广告中的广告词也进行了变动，解释其产品不是Unix，但是USL仍然对BSDI的作法不满并诉诸于法庭，控告BSDI销售他们的产品。 诉讼状中称BSDI产品包含了USL的代码的所有权和商业机密， USL希望能得到直到诉讼解决前使BSDI停止销售的禁令，宣称他们不能忍受由于BSDI继续销售发行版本而导致商业机密泄露所带来的损失。

在最初听到禁令时，BSDI坚决地认为他们只是简单使用了由加州大学发布的自由可再发行版本的源代码加上6个附加文件，他们愿意讨论任何有关6个附加文件的内容，但不相信他们应该对加州大学发布的文件负责。 法官同意BSDI的争辩，并且告诉USL，他们可以以6个文件为基础再陈述的诉状，或者是撤消此案。 USL意识到如果他们只陈述那6个文件，将会经历相当困难的时间处理这个官司，于是决定改写诉状，同时控告BSDI和California大学。 如以前一样，USL要求停止发行California大学的Networking Release 2，并停止在BSDI的产品中销售它。

在听说了即将发出禁令后的几个星期后，Berkeley开始了认真的准备工作。所有CSRG成员都宣誓作证，因为几乎他们所有人都受雇于BSDI，辩护、反辩护、再反辩护在律师之间来回穿梭进行，Keith Bostic和我本人不得不写下几百页的材料以供在各种辩护中使用。

在1992年12月， 新泽西州的地方法官Dickinson R. Debevoise听到了禁令的争议。尽管法官通常发布禁令非常快速，他仍然决定为之提供咨询。六个星期后的一个周五，他发表了一份长达40页的意见书，在文章中他否认禁令，并对起诉书械乃?观点（除了两点之外）表示反对。两点保留集中在最近的版权和丧失商业机密的可能性上。他还建议此案在联邦法院受理进行之前应先在州立法院系统进行?

California大学得此启示后，便立刻在接下来的那个星期的周一的上午向加州州立法院提出了对USL的反诉，通过首先在加州法院立案，加州大学已经为其进一步在州立法院的活动进行了本地化工作。宪法规定，所有州立法院的立案只能在一个州内完成审理，以防止诉讼当事人在各个州对同一案件进行50次立案。 结果是如果USL想在某个州立法院状告加州大学，则必须到加州法院上诉，而不是在他们的所在地新泽西州。

加州大学的诉状中宣称，USL未履行义务，没有向其提供付款，因其在System V中使用了BSD代码，而此项是他们与加州大学鉴定的许可证中规定的义务之一，若此指控成立，加州大学将要求USL打印出所有文档，并附加合适的信誉声明，以通知他们的版权授权用户（Licensees）他们造成的疏忽，并要在主要的出版物例如《Wall street Journal》和《Fortune》杂志上刊登整版的广告，以告知商界他们的疏忽大意。
在州立法院立案后不久，Novell公司从AT&T收购了USL。 Novell公司的执行总裁 Ray Noorda公开表示他愿意在市场上而不是在法庭上竞争。1993年夏天，双方开始协商。不幸的是，双方分歧很深，以致于对话进展缓慢。 USL方面在Ray Noorda的推动下，许多坚持不让的地方开始被取消，双方最终在1994年1月和谈成功。其结果是从Networking Release 2含有的18000个文件中去掉3个文件，并对其他文件做了一些小改动。 另外，加州大学同意在将近70个文件中加入USL版权声明，尽管那些文件仍继续被自由地再发行。

4.4BSD

在经历这番曲折后，1994年6月推出了一个新版本，称为4.4BSD-Lite。其砜芍さ奶蹩钣隢etworking Releases的条款相同。 特别之处是，许可证条款允许自由再发行源代码和二进制代码，只要在不触动加州大学的版权的完整性，并且其他人在使用代码时必须收到相同的信用声明。 同时，完整的系统被命名为4.4BSD-Encumbered发行，它仍然要求用户拥有USL源代码的许可证。

诉讼结果还规定USL不得再控告任何使用4.4BSD-Lite作为系统基础的组织。因此，当时所有的发行BSD的小组，如BSDI、NetBSD和FreeBSD等，都不得不重新开始将他们的源代码改为以4.4BSD-Lite源代码为基础，并在此基础上再合并他们的增强和提高部分。虽然这些重新集成的工作导致了不同BSD系统的开发在短期内被延迟，但幸运的是，在Networking Release 2发布后三年中，如同CSRG所做的那样，所有不同小组的开发可以再次步调一致。

4.4BSD-Lite, Release 2

由4.4BSD-Encumbered和4.4BSD-Lite版本获得的经费用于非全日制工作人员修改臭虫和增强性能等工作，这些变化持续了两年，直到臭虫报告的比例下降和特性增强已不再需要才停止。 所有的这些变化都体现在1995年6月发布的最后版本的4.4BSD-Lite Release 2中。这些变动中的大部分实际上都被用于其它系统的源代码基础中。
随着4.4BSD-Lite Release 2的发布，CSRG小组也被解散了。在领导了将近20年BSD发行的航程后，我们感觉到应该让其它有新思想和没有条条框框限制的人来接管此类工作，虽然好象最好要有一个独立的中心权威来监督系统开发，但有几个不同宗旨的小组的确可以保证尝试许多不同的方式。 因为系统是以源代码形式发布的，最好的主意是由某个或某些小组的成果易于被其他小组接纳。若某一个小组工作特别有成效，那么它的系统必将占据主导地位。

今天，开源软件运动得到更多的关注和尊重，尽管Linux系统是其中最有名的一个，但是在Linux发行版本中约半数的实用程序源自于BSD发行版本，Linux发行版本也在很大程度上依赖于由FSF（自由软件基金会，Free Software Foundation）开发的实用程序，例如编译器、调试器及其它工具。 总之，CSRG，FSF和Linux 内核开发者已经创建了自开源软件出现后并以此为基础的平台。我很自豪有机会帮助过启动开源软件运动。 我希望有一天，它会成为无论什么地方用户和公司开发和购买软件时更愿意采用的方式。

Linux的边界

今天，Linux有好几百万用户、数以千计的开发人员和一个正在增长的市场。它已应用到嵌入式系统中，用于控制机器人设备、甚至应用到了航天飞机上。尽管我可说我以前就知道这一切都会发生，这是它主导世界的全部计划的一部分。但说老实话，这一切仍有些出乎我的意料。比起由100个用户增加到100万用户，我对于由最初所发展的100个用户更重视。

Linux所取得的成功，不是因为当初所制定的广泛的可移植性和广泛的有效性目标决定的，而是由于它是建立在一个良好的设计原则和良好的发展模式上。这一坚实的基础使得可移植性和有效性更加容易实现。


与其他有强大的商业背景的公司的产品（如Java或Windows NT） 相比，Linux是有区别的。 Java令人激动不已的成就使许多人确信"一旦写成，随处运行"是一个有价值的目标。我们正进入一个计算时代，范围越来越广泛的硬件投入应用，所以这的确是一个重要的价值。 但是，"一旦写成，随处运行"并不是Sun的发明?梢浦残允羌扑慊?ひ党て诿蚊乱亚蟮哪勘辍＠?纾?⑷砉?镜背跻蚕Ｍ鸚indows NT成为可移植的操作系统，希望它不但可在Intel机器上运行，而且也可在基于RISC芯片的工作站环境上运行。Linux以前从来没有过这么值得炫耀的初始目标，但具有讽刺意味的是，它的跨平台代码变成了一种非常成功的媒质。

Linux鸪醯哪勘曛皇嵌ㄎ辉贗ntel 386一个体系上。 今天， Linux可运行于从PalmPilot 到Alpha工作站等任何一个体系上。它被广泛地移植到PC机的操作系统上。如果你编写了一个在Linux上运行的程序，那么它就能在相当广泛机型范围内可以做到"一旦写成，随处运行"。 所以， 看一看当初Linux的设计时所作出的决定、 Linux发展进程中所做的努力，以及如何管理Linux，使后来出现的版本与当初版本不完全相同，是件有意思的事情。

Amiga和Motorola

Linux是一个"类Unix"操作系统， 但它不是Unix的一个版本。 这使得Linux具有了与FreeBSD不同的继承性。 我的意思是说：FreeBSD的创立者是从Berkeley Unix的源代码起步的，FreeBSD的内核就是那个源代码的直系后代，所以FreeBSD是Unix 的一个版本， 它是Unix 家族的一个成员。 另一方面， Linux的目标则是提供一个与Unix兼容的界面，但是它的内核是从头编写的，并没有参考Unix的源代码。 所以Linux本身并不是Unix的一个移植版本，它是一个新的操作系统。

将这一新的操作系统移植到其他平台上的确不是我最初考虑过的主意。最初我只是想在我的386机器上运行它。

从Linux被移植到DEC的Alpha机器上开始，经过认真的努力，Linux内核代码具备了可移植性。然而，Alpha平台上Linux版本并不是Linux的第一个移植版本。
Linux的第一个移植版本是一个工作小组将Linux内核移植到Motorola 68K系列平台上后实现的。Motorola 68K是早期在Sun、 Apple和Amiga的计算机上使用的芯片。

yeee

长啊，真xx的长