而不久前，人工智能实验室的黑客社区已经解体了。1981年，从实验室分拆出来的Symbolics公司雇佣了几乎全部实验室黑客，减员的社区无以为续。（Steve Levy的《黑客》一书描述了这些事件，并给出了社区鼎盛时期的清晰写照。）当人工智能实验室在1982年购买了一台新的PDP-10后，其管理员决定使用Digital公司的非自由分时系统来代替ITS。

那时的新计算机，象VAX或68020，都有它们自己的操作系统，但是都不是自由软件：即使只是要一份可执行文件的副本，你都需要签署保密协议。

这表示使用计算机的第一步是承诺不会帮助别人。互助的社区被禁止了。专有软件的所有者制定了规则：“如果你和别人分享软件，你就是从事盗版。如果你想做软件更改，请乞求所有者吧。”

专有软件的社会系统—不能分享或更改软件的系统—是反社会的，因为它不道德、它完全错误。这样的想法可能令某些读者吃惊。但是对一个以分裂公众、使其用户无助为基础的系统，我们还能怎么说呢？那些对此吃惊的读者也许接受了专有软件的社会系统，或者按照专有软件行业推荐的术语来做了判断。软件发布商长期以来一直努力让人们相信：对这个问题只有一个看法。

当软件发布商说到“加强”他们的“权利”或者“打击盗版”时，他们说的其实是次要问题。他们的真正想法是让公众接受这些说法背后的假设是理所当然的、无需审视的。那么，就让我们审视一下这些假设。

其中一个假设是软件公司对软件拥有无可质疑的自然所有权，进而拥有超越其用户的权力。（如果这是自然权利，那么无论这对公众造成什么伤害，我们都无法反驳。）有意思的是，美国宪法和法律惯例拒绝这个观点；版权不是自然权利，而是人为的、政府强加的垄断，它用来限制用户拷贝复制的自然权利。

另一个隐含的假设是软件唯一的重要性在于它能让你做什么—软件用户不必去关心应该拥有什么样的社会。

第三个假设是如果不让软件公司有超越其用户的权力，那么我们就没有可用的软件（或者就没有能够执行特定任务的程序）。该假设看起来是可能的，直到自由软件运动证明：我们可以创造大量有用的软件而不用在其上横加锁链。

如果我们拒绝接受这些假设，把用户放在首位，并根据常识性的道德来判断，那么我们就可以得出不同的结论。计算机用户应该能够自由地修改软件来适应自己的需求，也应该能够自由地分享软件，因为互相帮助是社会的基础。

鉴于篇幅限制，我们不在此对结论背后的推理做详细论述，我为读者提供以下网页做参考： http://www.gnu.org/philosophy/why-free.html和 http://www.gnu.org/philosophy/free-software-even-more-important.html。

严酷的道德抉择

社区不复存在，我无法维持原样。反过来，我面临着严酷的道德抉择。

容易的选择是加入专有软件的世界、签署保密协议并发誓不再帮助我的黑客伙伴。我极有可能也在开发按照保密协议发布的软件，因此也让其他人面临背叛伙伴的压力。

我可能因此发财，也可能编程时乐在其中。但是我知道在我结束职业生涯之时，当我回顾那些建造围墙、隔离大众的岁月之时，我会感到我的一生是在让这个世界变得更糟糕。

当有人拒绝把控制打印机的源代码给我和MIT人工智能实验室的时候（由于缺少一些功能，该程序让使用打印机的人非常恼火），我就已经体会到了作为保密协议接收方的感受。

另一个选择，直截了当却令人不快，就是离开计算机行业。那样也许我的技术不会被滥用，但还是浪费了。我自己可能不会因为分化和限制计算机用户而遭受谴责，可这种事还是会发生。

我因而探索一条程序员能够做些好事的道路。我扪心自问，我能不能写一些程序，从而使再建社区成为可能？

答案显而易见：首先需要的是一个操作系统，它是使用电脑的关键软件。有了操作系统，你就可以做许多事情；没有它，你根本无法运行电脑。有了自由的操作系统，我们就能够再次建立互助黑客的社区—并邀请人们加入。这样，人们就可以使用电脑而不必因此失去朋友。

作为操作系统开发者，我正好具备这个技能。即使不能确保成功，我还是意识到我义不容辞。我选择让这个系统和Unix兼容，这样Unix用户就能够轻易切换过来。选择GNU作为名字是延续黑客的传统1，它是“GNU's Not Unix（GNU并非Unix）”的首字母同义递归。它的发音是带g的单音节。

操作系统并不是仅仅有内核，而无法运行其他程序。在70年代，每个称得上叫操作系统名字的系统都包括命令行、汇编器、编译器、解释器、调试器、文本编辑器、邮件服务，还有很多。ITS有、Multics有、VMS有、Unix也有这些。GNU系统也应该有。

我后来听到Hillel曾经说过（1)：

我不为我，谁会为我？
我只为我，我又是谁？
若非现在，更待何时？

决定开始GNU项目正是基于同样的情怀。

（1)作为一个无神论者，我并不追捧任何宗教领袖，但是我有时会钦佩他们的一些警句。

Free是freedom所指的自由

“自由软件（free software）”这一术语时常被误解—它无关价格，它关乎自由。这里，我们给出自由软件的定义。

一个软件对作为用户的你是自由软件，如果：

无论为何目的，你都有自由按照自己的意愿运行该软件。
你有自由按照自己的需要修改该软件。（要实现这个自由，你必须可以访问源代码，因为没有源代码而去修改程序是极端困难的。）
你有自由去分发软件拷贝，无论是否收费。
你有自由发布该程序的修改版，以让社区获益于你的改进。

由于“free”指的是自由，而不是价格，所以自由软件和销售其拷贝并无矛盾。事实上，销售拷贝的自由非常关键：使用CD-ROM的方式收集和销售自由软件对社区很重要，它是为开发自由软件募集资金的一个重要手段。因此，如果一个软件不能自由地以这种方式收集和销售，那么它就不是自由软件。

因为“free”带有歧义，人们长久以来一直在找替换它的词，但是没有找到更好的。英语比其他语言有更多的词汇和更微妙的词义差别，但是它没有一个简单、清晰的词来表达freedom一词中的“自由”—“unfettered”是意思上最接近的一个词。象“liberated”、“freedom”和“open”这些词或者意思不对，或者有其他不足。

GNU软件和GNU系统

开发整个系统是一个非常大的工程。要达成目标，我决定尽可能改造和利用现有的自由软件。比如，我一开始就决定使用TeX作为主要的文本排版工具；几年后，我又决定使用X Window系统而不是另外再为GNU编写一个窗口管理系统。

由于这些决定，以及类似的其他决定，GNU系统和全部GNU软件集合并不相同。GNU系统包含一些非GNU的程序，这些程序来自其他人和为其他目的的项目，但是因为它们是自由软件，所以我们就可以使用。

工程启动

1984年元月，我从MIT离职并开始编写GNU软件。离开MIT是必须的，这样MIT就不会干扰GNU以自由软件的形式发布。如果我还是MIT的员工，MIT就可能声称是这些软件的拥有者，进而可能加入他们自己的发布条款，甚至还会把它们变成专有软件。我决不会花了大力气而看到结果对最初的目的毫无用处：我们是要创建新的共享软件社区。

而当时MIT人工智能实验室的领导，Winston教授，还是友好地邀请我继续使用实验室的设施。

最初的几步

GNU工程开始不久，我听说了自由大学编译器工具包，又叫VUCK。（荷兰语的“自由”一词以v开头。）这是一个为处理多种语言而设计的编译器，它可以处理C语言和Pascal语言，还可以支持多个目标计算机。我写信问其作者GNU是否可以使用该工具包。

他带着嘲弄的口吻回答，大学是自由的，但编译器不是。我因此决定我的第一个GNU程序就是做一个支持多语言、多平台的编译器。

带着避免自己编写整个编译器的希望，我拿到了由Lawrence Livermore实验室开发的一个多平台的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，这就提出了如何发布GNU Emacs的问题。当然，我把它放在我用的MIT电脑的匿名ftp服务器上。（该电脑，prep.ai.mit.edu，因此变成了主要的GNU ftp发布站点；当它几年后退役时，我们把它的名字转到了新的ftp服务器上。）但是，在那个时候，许多对GNU Emacs感兴趣的人并没有上网，因而无法通过ftp获得软件拷贝。问题是，我应该对他们说什么？

我可能说，“找一个联网并愿意给你一份拷贝的朋友。”或者我会按照对原始 PDP-10 上的 Emacs 的做法来做：告诉他们，“邮寄一个磁带和一个SASE给我，我会用它们把 Emacs 邮寄回去。”但是我并无工作，而且我当时正在寻找用自由软件赚钱的方法。所以我声明，需要的人只要付 150 美元，我就会把带有 Emacs 的磁带邮寄过去。这样，我就创立了一个发布自由软件的行业，它是今天这些发布完整 GNU/Linux 系统的公司的先驱。

程序对每个用户都自由吗？

如果一个程序离开了其作者、成了自由软件，并不必然意味着对每个拥有该程序拷贝的用户，它都是自由软件。例如，公有领域软件（没有版权的软件）是自由软件；但是任何人都能用它制作一个修改版的专有软件。同样地，许多自由软件有版权但是使用简单的许可证发布，这些许可证允许制作修改版的专有软件。

X Window系统就是这个问题的一个范例。它由MIT开发，并使用随意许可证发布为自由软件。随后，许多公司改写了X Window系统，并把它以二进制形式添加到其专有的Unix系统中，而且用同样的保密协议加以保护。这些X Window系统的拷贝就和Unix一样不再是自由软件了。

X Window系统的开发者认为这不是问题—他们知道并愿意这样的事发生。他们的目的不是自由，只是“成功”，就是“拥有很多用户。”他们不关心这些用户是否拥有自由，只希望用户数目庞大。

这导致一个矛盾的情形：当回答“这个程序是否是自由软件？”的问题时，两种不同的计算自由的方法会给出不同的答案。如果你用MIT的发布许可证来判断时，你会说X系统是自由软件。但是，如果你测量使用X系统的用户获得的自由平均数时，你会说它是专有软件。因为大多数X系统的用户使用的是其Unix系统带的专有版本，而非自由软件版本。

Copyleft和GNU GPL

GNU的宗旨是给用户自由，而不只是变得流行。所以我们需要使用禁止让GNU软件变成专属软件的发布条款。我们所用的方法叫做“copyleft”。（1）

Copyleft利用版权法律，但是将其反转以服务于与其对立的目的：不是限制一个程序，而是要使之保持自由。

Copyleft的中心思想在于赋予任何人运行程序、复制程序、修改程序和发布修改其版本的许可—但是不允许添加他们自己的限制。因此，每个拥有软件拷贝的人都保有定义着“自由软件”的关键自由；这些权利变得不可剥夺。

作为一个有效的copyleft，软件的修改版也必须是自由的。这就保障了在我们的基础上所作的工作，如果发布，就变得社区共享。有工作的程序员如果自愿改善GNU软件，那么copyleft就会禁止她的雇主说：“你不能分享这些更改，因为它们将被用于发布我们的专有版本。”

如果我们要保障所有用户的自由，那么要求对程序的更改也必须是自由的是个基本条件。那些将X Window私有化的公司通常就是对X Window做了些改动以移植到他们的系统和硬件上。相对于X系统来说，这些改动是小的，但不算微不足道。如果更改是剥夺用户自由的借口的话，任何人都可以轻易借此占便宜。

还有就是合并自由软件和非自由软件的问题。这样的合并本来注定是非自由的；非自由部分缺失自由会导致整体也缺失自由。允许这样的合并会使自由的大堤毁于蚁穴。所以，copyleft的一个关键要求就是堵住这个漏洞：任何加入或合并到copyleft程序的结果必须是合并后的大程序也是自由和copyleft的。

大多数GNU软件采用的copyleft的具体实现是GNU通用公共许可证，简称GNU GPL。我们也有针对其他特别情况的其他copyleft实现。GNU手册也是copyleft的，不过手册不必用象GNU GPL这样复杂的许可证，所以它们用的是较简单的copyleft。（2)

（2）我们目前使用GNU Free Documentation License来授权文档。

自由软件基金会

当人们使用 Emacs 的兴趣起来后，其他人开始加入 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(1)，它是由 FSF 的员工 Brian Fox 开发的。

我们资助这些程序的开发是因为GNU工程不仅有工具或开发环境，我们的目标是完整的操作系统，而这些程序是完成目标需要的。

(1) “Bourne Again Shell”是对“Bourne Shell”这一名称表达敬意，后者是Unix系统上常用的shell。

自由软件技术支持

自由软件的哲学拒绝一类特定的广为人知的商业实践，但是它并不反对商业。当商业尊重用户的自由时，我们希望它们能够成功。

销售Emacs的拷贝就展示了一种这样的自由软件商业模式。当FSF接手了该业务，我就需要找另一种谋生的手段。我发现我可以销售针对我开发的自由软件的技术服务。这包括教授，比如如何针对GNU Emacs编程和如何定制GCC；还包括软件开发，多数情况是将GCC移植到新的平台。

现如今，不少公司都在进行诸如此类的自由软件商业实践。它们有的发行自由软件CD-ROM，有的做各类技术支持，从回答用户问题到修复缺陷，以至添加新功能。我们甚至开始看到开发新自由软件产品的自由软件公司。

不过，请注意—有些公司号称自己“开源”，实际从事和自由软件相关的非自由软件的业务。它们不是自由软件公司，它们是专有软件公司。它们的产品诱使用户远离自由。它们号称其软件是“增加价值的软件包”，并希望我们接纳其价值：让好用超过自由。如果我们更珍视自由，我们就应该把这些软件叫做“消减自由的软件包”。

技术目标

GNU的首要目标是做自由软件。即使GNU技术上并不比Unix高明，它也有社区的优势——允许用户合作，它还有道德上的优势——尊重用户的自由。

但是，在工作中采用好的经验和标准是自然的—比如，动态分配数据结构可以避免固定的内存使用，只要合理就尽可能地采用8比特编码。

另外，我们摈弃了Unix的小内存思路，决定不支持16位的计算机（很清楚，当GNU系统完成时，32位的计算机应该是标准设备），而且没有必要在内存使用未超过1兆字节时就减少内存用量。对于不常使用非常大的文件的程序，我们鼓励程序员把输入文件全读入内存，然后再处理其内容而不再操心输入输出（I/O）。

这些决定使许多GNU程序在可靠性和速度上都超过了其Unix对手。

捐赠电脑

随着GNU工程的声誉高涨，人们开始捐赠一些运行Unix的电脑给GNU工程。这很有用，因为开发GNU部件最简单的方法就是在Unix的机器上开发，然后一个一个在该机器上把该部件用GNU部件代替。但是这里有一个道德的问题：我们是否可以有一份Unix拷贝。

Unix是专有软件，而GNU工程的哲学说我们不应该使用专有软件。但是，使用和“用武力自卫是合法的”一致的推理，我认定使用专有软件开发自由软件是合法的：当这样做对开发专有软件的自由替代是关键的时候，因为这样才能帮助人们摆脱专有软件。

但是，即使有争议的做恶，还是一种做恶。今天，我们不再有任何Unix拷贝，因为我们已经用自由的操作系统代替了它们。如果我们不能用自由软件替换掉机器里的操作系统，我们就把机器替换掉。

GNU任务列表

随着GNU工程的前进，越来越多的系统组件被开发或被发掘出来。最后，我们发现制作一个组件缺失列表会很有用处。我们利用该列表来雇佣开发人员编写缺失的软件。这就是GNU任务列表。除了缺失的Unix部件，我们还列出了其他一些有用的软件和文档项目，我们认为它们是一个完整的系统所必须的。

今天(1)，GNU任务列表上已经没什么Unix部件了—这部分工作已经完成，除了一些不重要的组件。但是，有人会称这个列表上的项目是“应用软件”。它们是对一部分用户有吸引力的操作系统之上的软件。

即使游戏也在任务列表上—从一开始就在。Unix带有游戏，所以GNU自然也应该有。但游戏不必是兼容的，所以我们的游戏和Unix的游戏并不相同。相反，我们列出了一些用户可能喜欢的不同种类的游戏。

(1)当时是1998年。在2009年我们不再维护很长的任务列表。社区开发自由软件的速度是如此之快，我们甚至无法全部跟踪。所以，我们使用了高优先级项目列表，一个非常短的项目列表；我们真的鼓励用户来编写这些软件。

GNU软件库GPL

GNU C库使用一种特别的copyleft，它叫做GNU库通用公共许可证(1)，它允许使用该库连接专有软件。为什么有这样一个例外？

这不是原则的问题；没有原则说专有软件有权包含我们的代码。（我们为什么要为注定会拒绝和我们分享代码的项目做贡献？）C库或其他任何库使用LGPL许可证是战略问题。

C库完成的是普遍性的任务；每个专有系统或编译器都有自己的C库。所以，我们的C库只供自由软件使用并不会给自由软件更多的优势—它可能只会让大家避免使用我们的库。

有一个系统是例外：在GNU系统上（包括GNU/Linux），GNU C库是唯一的C库。所以GNU C库的发布条款决定着是否可以在GNU系统上编译专有软件。道德上没有理由在GNU系统上允许专有软件，但是战略上不允许专有软件可能更加不利于自由软件的发展。这就是为什么C库使用LGPL是一个好的战略。

对于其他库，战略决定需要具体情况具体分析。如果一个库是帮助特定的程序完成特定的任务，那么它以GPL发布，只能用于自由软件。这样会帮助自由软件开发者有超越专有软件的优势。

以GNU Readline为例，它是为编辑BASH命令行而开发的库。它以常规的GNU GPL，而不是以LGPL发布。这样可能减少了Readline的使用量，但这不是我们的损失。同时，至少能够使用Readline使自由软件变得特别，从而使社区获得优势。

专有软件开发者有金钱带来的优势；自由软件开发者需要互相帮助的优势。我希望有一天我们拥有大量的GPL的库而专有软件没有，这些库是开发新的自由软件的材料，它们加在一起构成了进一步开发自由软件的主要优势。

(1)该许可证现在叫做GNU宽通用公共许可证，以避免大家误以为全部库都可以使用该许可证。参看为什么你的下一个库不应该使用LGPL许可证来了解更多信息。

解决痛点？2

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（即GNU驾驭者）是运行在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编写支持新硬件的自由驱动软件变得困难起来。今天我们有了完整的自由软件系统，但是如果不能支持未来的计算机，我们明天就会失去这个自由软件系统。

有两种方法对付这个问题。程序员可以通过逆向工程了解这些硬件的工作原理。其他人可以选择使用那些被自由软件支持的硬件；随着我们的人数增长，保守硬件规格的秘密就变成是固步自封。

逆向工程是一个艰巨的任务；我们的程序员是否有足够的决心担起重任？是的—如果我们强烈地感觉到自由是一个原则问题，而非自由的驱动软件是无法容忍的。会有很多人愿意花额外的钱、甚至花一点额外的时间让我们用上自由的驱动软件吗？是的，如果我们想要自由软件的决心广泛传播。

（2008年注：此问题还扩展到Bios程序。这里有一个自由的BIOS软件，LibreBoot（coreboot的一个发行版）；问题在于获得计算机的规格以便LibreBoot能够不使用非自由的“blobs”软件包也能够支持这些计算机。）

非自由软件库

运行在自由操作系统里的非自由软件库是自由软件开发者的一个陷阱。这些软件库看上去很美的功能是诱饵；如果你使用了该软件库，你就落入了陷阱，因为你的程序不能再作为自由软件的部件来使用。（严格来说，我们可以包含你的程序，但是它没有了非自由软件库将无法运行。）更糟糕的是，如果使用专有软件库的程序变得流行起来，它就会诱惑其他未起疑心的程序员落入同样的陷阱。

第一个这样的例子是80年代的Motif工具包。虽然那时还没有自由的操作系统，但是很明显Motif将会导致什么样的问题。GNU工程做出了两个回应：一方面请求个别自由软件项目支持Motif工具包的同时也支持自由的X工具包，另一方面请求黑客编写替代Motif的工具包。该工作持续了许多年；直到1997年，由匈牙利程序员开发的LessTif，才变得足够强大来代替Motif的大部分功能。

从 1996 年到 1998 年，另一个非自由 GUI 工具包，叫做 Qt，被一个实际上是自由软件的集合，KDE 桌面所使用。

自由的GNU/Linux系统当时无法使用KDE，因为我们不能使用那个工具包。然而，一些商业的GNU/Linux发行商没有坚持自由软件的理念，将KDE添加到他们的系统—生产了有更多功能、但更少自由的系统。KDE团队积极鼓励更多的程序员使用Qt软件库，数百万的新“Linux用户”从来没有被告知这里有问题。情况变得严峻。

自由软件社区对此做出了两个回应：GNOME和Harmony。

GNOME（GNU Network Object Model Environment，GNU网络对象建模环境）是GNU的桌面项目。它在1997年由Miguel de Icaza开始，并由Red Hat Software支持开发，GNOME致力于提供相似的桌面支持，但完全使用自由软件。它在技术上也要领先，比如支持多种编程语言，而不是只支持C++。但是主要的目的还是自由：不必依赖任何非自由软件。

Harmony是一个兼容性替代库，其设计用来运行KDE软件而无需使用Qt。

在1998年11月，Qt的开发者宣布更改授权协议，新协议实际上要使Qt变成自由软件。虽然无法核实，不过我还是认为这一举动有一部分是由于我们社区对Qt作为非自由软件的有力回应。（新的授权协议不方便也不对等，所以最好还是避免使用Qt。）

[后续注：在2000年9月，Qt按照GNU GPL发布，这就从根本上解决了这个问题。]

我们会如何回应下一个非自由软件库的诱惑？整个自由社区是否都会理解我们应该躲开陷阱？抑或有人会为了好用而放弃自由，从而制造大麻烦？我们的未来要靠我们的哲学。

软件专利

我们面临的最恶劣的威胁是软件专利，它可以用算法和功能点限制自由软件最长达 20 年。LZW 压缩算法于 1983 年启用专利，我们至今不能发布可以生成适当压缩的 GIF 图片的自由软件。[在 2009 年，这些专利过期。]在 1998 年，由于受到专利的威胁，一个生成 MP3 格式的音频压缩自由软件从发行版中被移除了。[在 2017 年，这些专利过期。看看我们等了多长时间。]

我们有些方法来对付专利：我们可以寻找专利是无效的证据，我们还可以寻找其他的方法替代专利限制的方法。但是这些方法不总是有效；当上述两种方法都失败时，专利可能迫使自由软件无法具备用户需要的某些功能。经过长时间的等待，专利会过期，但是在此之前我们怎么办？

因为自由的原因而珍视自由软件的人们总是会和自由软件保持一致。我们会设法在没有这些功能的情况下完成工作。但是还有那些因为期待自由软件功能优越而喜欢自由软件的人，他们可能在看到专利的限制后会觉得自由软件是个失败。因此，当我们谈论“集市（bazaar）”开发模式的实际有效性的时候，在我们谈论自由软件的可靠性和强大功能的时候，我们不要停留在这些话题上。我们必须要谈论自由和原则。

自由文档

自由软件操作系统的最大不足不是软件—而是缺少优秀的自由文档。文档是软件包的基本组成部分；一个重要的自由软件包没有相应的优质自由文档，就是差距。这样的差距我们目前有很多。

自由文档，和自由软件一样，关乎自由，而不是价格。自由文档的标准和自由软件大同小异：它给予所有用户自由。文档必须能够重新发布（包括商业销售），无论是在线还是纸质，这样每个软件拷贝就都能带有文档。

文档允许修改也很关键。作为一般性规则，我不认为有必要允许人们修改所有种类的文章和书籍。比如，我不认为你或我应该被允许修改本文，本文描述的是我们的行动和看法。

但是拥有修改自由软件文档的自由是关键的，是有特别的原因的。当人们实践修改软件的权利—添加或改变软件的功能时，如果他们是尽责的，他们还会修改文档—这样他们就会为修改后的软件提供准确和可用的文档。非自由的文档不允许程序员尽责并完成文档工作，不符合我们社区的需要。

然而，必须要允许修改文档的所有技术内容，并允许从所有常规渠道以所有常规媒体发布；否则，就限制了社区，文档就不是自由的，我们就会需要另一个文档。

自由软件的开发者有没有觉悟和决心来写出全方位的自由文档？我们的未来又一次依赖于我们的哲学。

我们必须论及自由

估计当今有一千万GNU/Linux用户，他们使用诸如Debian GNU/Linux和Red Hat“ Linux”系统。自由软件已经发展得如此优越，以至于用户仅仅因为其实用性就蜂拥而至。

好的效果是显而易见的：更多开发自由软件的兴趣、更多自由软件行业的客户和对开发商用自由软件而不是专有软件的公司的更有力的鼓舞。

但是对软件兴趣的高涨超过了对其哲学基础的认知，这会导致麻烦。我们面对上述挑战和威胁的能力依赖于我们坚定地站在自由这一边。要使社区有同样的意志，我们需要向新加入社区的伙伴传播我们的理念。

但是我们正在此处失败：我们吸引新用户的努力大大超过了教育他们成为合格社区公民的努力。我们要两手都抓，也要两手一样硬。

“开源”

在1998年，教育新用户自由的理念变得更加困难，当时部分社区成员决定使用“开源”代替“自由软件”。

其中一些人的目的是避免“自由”和“免费”的混淆—这是个合理的目的。不过，另一些人，却意在把激励自由软件运动和GNU工程的精髓抛在一边，去迎合行政和商业用户，其中很多人的理念是盈利超越自由、超越社区、超越原则。因此，“开源”一词聚焦于制作高质量、强功能的软件的能力，而回避自由、社区和原则的理念。

“Linux”杂志就是一个明确的例子—其中塞满了工作在GNU/Linux系统之上的专有软件的广告。当再有Motif或Qt之类的软件出现，这些杂志是该警告程序员远离它们呢，还是会为它们打广告呢？

商业的支持能够在很多方面为社区做贡献；其他条件合适时，这是有用的。但是通过少说自由和原则来获取它们的支持是灾难性的；这使前面提到的增加用户和教育公民的不平衡变得更糟。

“自由软件”和“开源”描述的是大致同一类软件，但是它们表述的却是这些软件的不同层面和价值。GNU工程继续使用“自由软件”一词，来表达自由而不只技术是重要的，这一理念。

尝试！

犹大的名言（“不存在‘尝试’”）听来优雅，但是对我不适用。带着是否能够完成任务的焦虑、带着完成目标是否已足够的怀疑，我完成了大部分工作。无论如何，我尝试了，因为在敌人和我的城池之间只有我自己。令我吃惊的是，我有时也能取胜。

我有时也失败；一些城池沦陷了。然后我找到另一个面临威胁的城池，并准备好另一场战役。天长日久，我学会了发现威胁并置身于威胁和城池之间，呼唤其他黑客来加入我的阵营。

现如今，我通常不再是一个人。看到大量的黑客挖战壕、守阵线的感觉是轻松和快乐。我意识到城池—眼下安全了。但是危险与年俱增，目前Microsoft明确把矛头指向我们的社区。我们不能视自由的未来为理所当然。不能认为自由是理所当然！如果要保持自由，你必须准备好捍卫自由。

译注

这里的意思是起名字时，在新名字里包含旧名字以体现对旧名字的敬意。
原文是Scratching an itch?:意思是瘙到痒处。这里指解决一个闹心的问题，故译为解决痛点。

以上是关于GNU工程的主要内容，如果未能解决你的问题，请参考以下文章

GNU工程的发展历程

GNU开发工具——CMake工程实践

GNU是个什么？是个标准，软件还是编译器还是一个总称

cflow察看工程函数调用关系

Makefile构建Golang项目

makefile 工程管理