为什么自由软件需要自由文档

自由操作系统最大的缺陷不是在软件本身,而是缺乏我们可以包含在这些系统中的好的自由手册。我们许多最重要的程序都没有完整的手册。文档是任何软件包的必要组成部分;当一个重要的自由软件包没有附带自由手册时,这是一个主要的缺失。我们今天有很多这样的缺失。

很久以前,我曾经想学 Perl。我得到了一份自由手册的副本,但我发现它很难读。当我向 Perl 用户询问其他选择时,他们告诉我有一些更好的入门手册——但那些不是自由的(不尊重自由的)。

为什么会这样?好的手册的作者是为 O'Reilly Associates 编写的,他们以限制性条款出版这些手册——不允许复制,不允许修改,不提供源文件——这使得它们不自由,从而将它们排除在自由世界之外。

这不是第一次发生这种事,而且(对我们社区的巨大损失而言)远非最后一次。自那时以来,专有手册出版商已经引诱了许多作者限制他们的手册。很多次我都听到 GNU 用户兴致勃勃地告诉我他正在编写一本手册,他期望以此来帮助 GNU 项目——然后我的希望破灭了,因为他接着解释说他与出版商签署了一份合同,该合同会限制该手册,以至于我们无法使用它。

鉴于编写好的英语是程序员中罕见的技能,我们无法承受以这种方式丢失手册。



自由文档,就像自由软件一样,是关于自由的问题,而不是价格。这些手册的问题不是 O'Reilly Associates 对印刷版收取费用——这本身没有问题。(自由软件基金会也出售自由 GNU 手册的印刷版。)但 GNU 手册以源代码形式提供,而这些手册仅以纸质形式提供。GNU 手册附带复制和修改的许可;Perl 手册则没有。这些限制是问题所在。

自由手册的标准与自由软件的标准几乎相同:这是给予所有用户某些自由的问题。必须允许再分发(包括商业再分发),以便手册可以随程序的每一份副本一起提供,无论是在线还是纸质版。修改的许可也非常重要。

一般来说,我不认为人们必须有权修改所有类型的文章和书籍。写作的问题不一定与软件的问题相同。例如,我认为你或我没有义务允许修改像这篇文章这样的描述我们行为和观点的文章。

但是,对于自由软件的文档而言,修改的自由至关重要有一个特殊的原因。当人们行使修改软件的权利并添加或更改其功能时,如果他们尽职尽责,他们也会更改手册——这样他们就可以为修改后的程序提供准确且可用的文档。如果手册禁止程序员尽职尽责并完成工作,或者更准确地说,如果他们更改了程序,则要求他们从头开始编写新的手册,那么该手册就不能满足我们社区的需求。

虽然全面禁止修改是不可接受的,但对修改方法的一些限制不会造成问题。例如,保留原始作者的版权声明、分发条款或作者列表的要求是可以接受的。要求修改后的版本包括他们已被修改的通知也没有问题,即使有整个部分可能无法删除或更改,只要这些部分处理非技术主题即可。(一些 GNU 手册就有这些。)

这些类型的限制不是问题,因为实际上,它们不会阻止尽职尽责的程序员使手册适应修改后的程序。换句话说,它们不会阻止自由软件社区充分利用手册。

但是,必须可以修改手册的所有技术内容,然后通过所有常用媒体、通过所有常用渠道分发结果;否则,这些限制会阻止社区,手册不是自由的,因此我们需要另一本手册。

不幸的是,当存在专有手册时,通常很难找到人来编写另一本手册。障碍在于许多用户认为专有手册已经足够好——因此他们没有看到编写自由手册的必要性。他们没有看到自由操作系统存在需要填补的空白。

为什么用户认为专有手册足够好?有些人没有考虑这个问题。我希望这篇文章能对此有所改变。

其他用户认为专有手册可以接受的原因与许多人认为专有软件可以接受的原因相同:他们纯粹从实用的角度来判断,而不是以自由为标准。这些人有权发表自己的意见,但是由于这些意见源于不包括自由的价值观,因此对于我们这些重视自由的人来说,它们不是指导。

请传播关于此问题的消息。我们继续将手册输给专有出版。如果我们传播专有手册是不够的消息,也许下一个想通过编写文档来帮助 GNU 的人会意识到,在为时已晚之前,他首先必须使其自由。

我们还可以鼓励商业出版商出售自由的、具有著作权保留的手册,而不是专有的手册。你可以通过在购买手册之前检查手册的分发条款,并优先选择具有著作权保留的手册而不是非著作权保留的手册来帮助实现这一点。

[注意:我们维护一个 页面,其中列出了其他出版商提供的自由书籍]。