GNU 软件维护者须知，最后更新于 2023 年 6 月 8 日。
版权所有 © 1992、1993、1994、1995、1996、1997、1998、1999、2000、2001、2002、2003、2004、2005、2006、2007、2008、2009、2010、2011、2012、2013、2014、2015、2016、2017、2019、2022 自由软件基金会。
本文件允许在 GNU 自由文档许可证 1.3 版或自由软件基金会发布的任何后续版本的条款下复制、分发和/或修改；无不变节、无封面文本、无封底文本。许可证的副本包含在名为“GNU 自由文档许可证”的部分中。
| • 前言 | ||
| • 获取帮助 | ||
| • GNU 账户和资源 | ||
| • 卸任 | ||
| • 招募开发者 | ||
| • 法律事项 | ||
| • 清理 | ||
| • 平台 | ||
| • 不应接受的补丁 | ||
| • 邮件 | ||
| • 旧版本 | ||
| • 发行版 | ||
| • 网页 | ||
| • 道德和哲学思考 | ||
| • 幽默 | ||
| • 其他政治 | ||
| • 术语 | ||
| • 访谈和演讲 | ||
| • 托管 | ||
| • 捐赠 | ||
| • 自由软件目录 | ||
| • 使用校对员列表 | ||
| • 建议的回复 | ||
| • GNU 自由文档许可证 | ||
| • 索引 |
本文件包含为 GNU 项目维护 GNU 程序的维护人员的指南和建议。 每个人都有权更改和重新分发 GNU 软件； 你不需要关注此文件来获得许可。 但是，如果你想维护一个用于广泛分发的版本，我们建议你遵循这些指南。 如果你是 GNU 维护者或想成为 GNU 维护者，那么遵循这些指南至关重要。
除了本文档之外，请阅读并遵循《GNU 编码标准》（请参阅目录中的 GNU 编码标准）。你还可以查看“新 GNU 维护者的提示”（https://gnu.ac.cn/software/maintainer-tips），其中列出了你作为新维护者需要做的最重要的事情。
请将对本文档的更正或建议发送至 [email protected]。如果你提出建议，请尽可能提供建议的新措辞。我们首选 Texinfo 源的上下文差异，但如果你觉得困难，你可以为此文档的其他版本制作差异，或以任何明确的方式提出它。本文档的源存储库位于 https://savannah.gnu.org/projects/gnustandards。
如果你想接收这些 GNU 文档每次更改的差异，请加入邮件列表 [email protected]，例如通过 https://lists.gnu.org/mailman/listinfo/gnustandards-commit 上的 Web 界面。存档也在此处提供。
本文档使用中性第三人称代词“person”（可以缩短为“perse”）、“per”、“pers” 和“perself”。这些代词（除了“perse”之外）是由 Marge Piercy 在 Woman on the Edge of Time 中推广，或许是发明的。它们的用法与“she”、“her”、“hers”和“herself”完全相同，只是它们适用于任何性别。例如，“Person placed per new program under the GNU GPL, to maintain freedom for all users of per work, and this way perse knows perse has done the right thing.”（“某人将每个新程序置于 GNU GPL 之下，以维护每个人的工作的所有用户的自由，这样，某人知道某人做了正确的事情。”）
此版本的 GNU 维护者信息上次更新于 2023 年 6 月 8 日。
如果你有任何一般性问题，或者遇到不清楚如何完成某事或向谁寻求帮助的情况，你（作为 GNU 贡献者）可以随时写信给 [email protected]，这是一个由几位经验丰富的 GNU 人员组成的列表，他们自愿回答问题。任何与 GNU 相关的问题都适合 mentors 列表。
GNU 咨询委员会代表 RMS（Richard Stallman，首席 GNUisance）帮助协调 GNU 项目中的活动。 如果你有任何组织问题或疑虑，可以联系委员会 [email protected]。 请参阅 https://gnu.ac.cn/contact/gnu-advisory.html，了解当前委员会成员。 其他信息在 /gd/gnuorg/advisory 中。
如果你发现任何 GNU 计算机系统（fencepost.gnu.org、ftp.gnu.org、www.gnu.org、savannah.gnu.org、...）似乎已关闭，你可以在 https://hostux.social/@fsfstatus 上查看当前状态。 最有可能的是，如果可以在 FSF 端缓解该问题，则正在解决该问题。
FSF 系统管理员维护 GNU 网络和服务器硬件。 你可以通过电子邮件 [email protected] 联系他们。 请立即向他们报告 GNU 服务器中的任何故障。 除此之外，请尽量不要给他们带来不必要的负担。
本文档中提到的目录 /gd/gnuorg 在通用 GNU 服务器上可用，目前是 fencepost.gnu.org。 如果你是 GNU 软件包的维护者，你应该在那里拥有一个帐户。 如果你还没有帐户，请参阅 https://gnu.ac.cn/software/README.accounts.html。 此类 GNU 登录帐户包括电子邮件（请参阅 https://www.fsf.org/about/systems/sending-mail-via-fencepost）。
你可以为在软件包上为你提供重要帮助的人员请求帐户； 如果有充分的理由，我们将在特殊情况下执行此操作。
GNU 维护人员可用的其他资源在 https://gnu.ac.cn/software/devel.html 以及本文档中进行了描述。 简而言之
如果幸运的话，您将会在几十年内继续维护您的软件包。但有时，由于各种原因，维护者会决定卸任。
如果您是 GNU 软件包的官方维护者，并且您决定卸任，请通知 GNU 项目 ([email protected])。我们需要知道该软件包不再有维护者，以便我们可以寻找并任命新的维护者。
如果您有关于谁应该接任的想法，请将您的建议告知 [email protected]。新维护者的任命需要 GNU 项目的确认，但您对某人能够胜任这项工作的判断将具有很大的影响力。
作为您作为维护者的最后行动，在 savannah.gnu.org 下设置或更新软件包（请参阅 旧版本）将很有帮助。这将使新维护者更容易从您离开的地方接手，并确保如果我们需要一段时间才能找到新的维护者，源代码树不会丢失。
除非您的软件包非常小，否则您可能不会独自完成所有工作。大多数维护者会招募其他开发者来帮忙。
有时会有人主动提出帮忙。其中一些人将有能力，而另一些人则没有。您需要确定谁提供了有用的帮助，并鼓励这些人更多地参与。
一些提供帮助的人将支持 GNU 项目，而另一些人可能是出于其他原因感兴趣。有些人会支持自由软件运动的目标，但有些人可能不会。他们都欢迎来帮助工作——我们不会在人们为 GNU 软件包做出贡献之前询问他们的观点或动机。
因此，您不能期望所有贡献者都支持 GNU 项目，或关心其政策和标准。因此，您作为维护者的一部分工作是在出现这些问题时行使您的权力。无论其他人做了多少工作，您都负责发布的内容。当出现关键问题时，您应该冷静地陈述您的决定并坚持下去。
有时一个软件包有几个共同维护者，他们共同承担维护者的角色。与提供帮助的开发者不同，共同维护者实际上是共同被任命为该软件包的维护者，他们共同执行维护者的职能。如果您想推荐一些您的开发者作为共同维护者，请联系 [email protected]。
我们很乐意在 https://gnu.ac.cn/people/people.html 网页上感谢所有对 GNU 软件包做出重大贡献的人。请将您自己的条目发送至 [email protected]，并随时将其推荐给您的软件包上的其他重要开发者。
本章介绍了您在维护程序时出于法律原因应遵循的程序，以避免法律上的困难。
| • 版权文件 | ||
| • 具有法律意义的 | ||
| • 记录贡献者 | ||
| • 从其他软件包复制 | ||
| • 版权声明 | ||
| • 许可声明 | ||
| • 外部库 | ||
| • 致谢作者 |
如果您维护 FSF 版权的软件包，那么在纳入其他人编写的具有法律意义的更改时，需要遵循某些法律程序。这确保了 FSF 拥有分发该软件包的合法权利，并且在必要时有资格在法庭上捍卫其 GPL 覆盖的状态。
GNU 软件包不需要由 FSF 版权所有；这取决于作者，通常在软件包被命名为 GNU 时。当版权转让给 FSF 时，FSF 可以采取行动阻止关于该软件包的 GPL 违规行为。否则，法律行动由作者负责。本节的其余部分是关于软件包由 FSF 版权所有的情况。
在纳入重大更改之前，请确保编写更改的人已签署版权文件，并且自由软件基金会已收到并签署了这些文件。我们可能还需要此人雇主的免责声明，确认该工作不是此人工作的一部分，并且雇主不对此提出任何要求。但是，此人的雇佣合同副本，表明雇主不能对这项工作提出任何权利，通常就足够了。
如果雇主声称这项工作是此人工作的一部分，并且没有明确的依据表明该主张无效，那么我们必须认为它是有效的。那么这个人不能转让版权，但雇主可以。许多公司都这样做过。请要求相关经理联系 [email protected]。
要检查是否已收到文件，请查看 /gd/gnuorg/copyright.list。如果您无法直接在那里查看，[email protected] 可以为您检查。我们的职员还可以检查等待输入的文件，并在预计的文件到达时通知您。
本文档中提到的目录 /gd/gnuorg 在通用 GNU 服务器上可用，目前是 fencepost.gnu.org。 如果你是 GNU 软件包的维护者，你应该在那里拥有一个帐户。 如果你还没有帐户，请参阅 https://gnu.ac.cn/software/README.accounts.html。 此类 GNU 登录帐户包括电子邮件（请参阅 https://www.fsf.org/about/systems/sending-mail-via-fencepost）。
你可以为在软件包上为你提供重要帮助的人员请求帐户； 如果有充分的理由，我们将在特殊情况下执行此操作。
为了让贡献者知道应该签署文件的人，您需要要求其提供必要的文件。如果您不太了解此人，并且您不知道此人习惯于我们处理版权文件的方式，那么最好通过类似这样的消息来提出这个问题：
您是否愿意将版权转让给自由软件基金会，以便我们可以将其安装在 package 中？
或者
您是否愿意签署版权免责声明，将此更改放入公共领域，以便我们可以将其安装在 package 中？
如果贡献者随后想要更多信息，您可以将文件 /gd/gnuorg/conditions.text 发送给此人，其中解释了此人的选择（转让与放弃）及其后果。
一旦对话开始，贡献者准备好了解更多细节，您应该发送 /gd/gnuorg/Copyright/ 目录中找到的模板之一；它们也可以从 https://savannah.gnu.org/projects/gnulib 处的 gnulib 项目的 doc/Copyright/ 目录中获得。本节解释了您在哪些情况下应使用哪些模板。请不要使用此处列出的模板之外的任何模板，并且请不要更改措辞。
一旦对话开始，您可以通过电子邮件将确切的措辞和说明发送给贡献者。在执行此操作之前，请务必获取您将使用的模板的当前版本！我们偶尔会更改这些模板——不要一直使用旧版本。
对于较大的更改，请要求贡献者进行转让。向此人发送文件 request-assign.changes 的副本。（像所有“request-”文件一样，它位于 /gd/gnuorg/Copyright 和 gnulib 中。）
对于中小型更改，请通过发送文件 request-disclaim.changes 来请求个人免责声明。
如果贡献者可能会继续进行更改，则此人可能希望签署一份针对此人未来对该程序的所有更改的转让。因此，向此人提供该替代方案很有用。如果此人想这样做，请向此人发送 request-assign.future。
当您发送 request- 文件时，您无需在发送之前填写任何内容。只需将文件逐字发送给贡献者即可。该文件为他们提供了如何要求 FSF 将要签署的文件邮寄给他们的说明。request- 文件还提出了从贡献者的雇主处获得雇主免责声明的问题。
当贡献者通过电子邮件将表格发送给 FSF 时，FSF 会向此人发送一份电子版（通常为 PDF）转让文件。这或所需的任何回复，应在初始请求后的五个工作日内发生。如果在那段时间后 FSF 没有回复，请发送提醒。如果在一周后仍未收到回复，请写信至 [email protected]。
收到必要的表格后，贡献者需要签署它。居住在美国或意大利的贡献者可以使用 GPG 来签署其转让。位于其他任何地方的贡献者可以打印、签署，然后通过电子邮件（或传真）将扫描的副本发回给 FSF。（两种情况的具体说明都随转让表格一起发送。）如果他们愿意，他们可以使用邮政邮件。要强调的是，必要的区别在于这些国家的居民和非居民；国籍无关紧要。
对于不太常见的情况，我们有您应该发送给贡献者的模板文件。在发送之前，请务必在这些模板中填写人员姓名和程序名称，其中写着“人员姓名”和“程序名称”；否则此人可能会在没有注意到的情况下签署，这些文件将毫无用处。请注意，在某些模板中，有多个位置可以放置程序名称或人员姓名；请务必全部更改。所有模板都提出了雇主免责声明的问题。
如果手册仅随其描述的软件包一起分发，则无需为该手册单独索要法律文件。但是，如果我们有时单独分发手册（例如，如果我们将其作为书出版），那么我们需要单独的法律文件来处理手册中的更改。对于较小的更改，请使用 disclaim.changes.manual；对于较大的更改，请使用 assign.changes.manual。要涵盖手册的过去和未来更改，您可以使用 assign.future.manual。对于手册的翻译，请使用 assign.translation.manual。
对于程序字符串的翻译（例如 GNU Gettext 使用的字符串；请参阅GNU 编码标准中的国际化），请使用 disclaim.translation。如果您使用翻译项目（https://translationproject.org）的工具，请与 TP 协调员确认他们是否已将法律文件发送给贡献者；如果他们没有发送，则您应该发送这些法律文件。无论如何，您应等待 FSF 确认已收到并接受签名的法律文件后，再像往常一样集成新贡献者的材料。
如果贡献者不愿为较大的更改签署转让书，而愿意签署免责声明，这是可以接受的，因此如果这有助于您达成协议，您应该提供此替代方案。我们更倾向于为较大的更改签署转让书，以便我们可以对新文本强制执行 GNU GPL，但免责声明足以让我们使用该文本。
如果您维护一个程序集合，有时会有人贡献一个应该添加到该集合中的完整的单独程序或手册。那么您可以使用文件 request-assign.program、disclaim.program、assign.manual 和 disclaim.manual。我们非常希望为一个新的单独程序或手册签署转让书，除非它非常小，但如果贡献者坚持以这种方式处理此事，则免责声明是可以接受的。
当版权持有人已签署所有未来对软件包的更改的转让书，并贡献了由新文件组成的更改，这些新文件不需要对任何旧文件进行任何更改时，我们希望避免任何关于这些文件是否旨在作为软件包的更改并因此受该转让书约束的不确定性。解决此问题的方法是要求贡献者在给您的消息中说明这一点，例如，“我的模块‘frog’和‘kangaroo’旨在作为程序 Hoppers 的更改”。将该消息转发给 [email protected]，他们将永久保存该消息。此过程的一种变体：编写新文件的贡献者可以发送包含此类消息的新文件副本。
如果贡献者希望 FSF 仅发布笔名，这是可以的。贡献者应在回答 request- 表单时说明这一点，并说明所需的笔名。实际的法律文件将使用真实姓名，但 FSF 将仅发布笔名。当使用其他表格之一时，请填写真实姓名，但在将签名表格寄回之前，请让贡献者与 [email protected] 讨论笔名的使用问题。
尽管此处列出的模板之外还有其他模板，但它们用于特殊情况；请在未获得 [email protected] 的建议之前不要使用它们。
如果您不确定该怎么做，请向 [email protected] 寻求建议；如果贡献者向您询问有关法律文件的含义和后果的问题，而您不知道答案，您可以将它们转发给 [email protected]，我们将回答。
请不要尝试自己更改模板的措辞。如果您认为需要进行更改，请与 [email protected] 交谈，我们将与律师合作以决定该怎么做。
如果一个人贡献了大约 15 行以上在法律上对版权具有重要意义的代码和/或文本，我们需要为该贡献提供版权文件，如上所述。
仅几行的更改（大约少于 15 行）在法律上对版权没有重要意义。一系列重复的常规更改，例如重命名符号，即使该符号必须在许多地方重命名，在法律上也没有重要意义。但是请记住，同一个人的一系列小更改可能会累积成一项重要的贡献。重要的是一个人的总贡献；与贡献的哪些部分何时贡献无关。
版权不涵盖想法。如果某人贡献了想法但没有贡献文本，这些想法可能在道德上作为贡献很重要，值得赞扬，但它们在版权方面没有重要意义。同样，错误报告也不计入版权目的。
当对贡献在法律上对版权没有重要意义的人给予赞扬时，请注意明确说明这一事实。赞扬应该清楚地说明他们没有贡献重要的代码或文本。
当人们的贡献在法律上没有重要意义时，因为他们没有编写代码，请明确说明他们的贡献是什么。例如，您可以这样写
/* * Ideas by: * Richard Mlynarik <[email protected]> (1997) * Masatake Yamato <[email protected]> (1999) */
想法来源： 清楚地表明 Mlynarik 和 Yamato 在这里仅贡献了想法，而不是代码。如果没有 想法来源： 注释，几年后我们将很难确定他们是否贡献了代码，我们可能不得不找到他们并询问他们。
当您在更改日志文件中记录一个小补丁时，首先搜索同一人的先前更改，并查看过去的贡献加上新的贡献是否加起来对法律具有重要意义。如果是这样，您应该在安装新更改之前获得所有每个更改的版权文件。
如果不是这样，您可以安装小补丁。在补丁作者姓名后写入‘(微小更改)’，如下所示
2002-11-04 Robert Fenk <[email protected]> (tiny change)
请保持谁编写了哪些部分的正确记录。 这非常重要。这些记录应说明每个人编写了哪些文件或文件的一部分，以及每个人修订了哪些文件或文件的一部分。这应包括安装脚本以及手册和文档文件——所有内容。
这些记录不需要像更改日志那样详细。它们不需要区分在不同时间完成的工作，只需要区分不同的人。它们不需要比更改了哪些文件或文件的哪些部分更详细地描述更改。它们不需要说明文件或更改的功能或目的——版权注册处并不关心文本的功能，只关心谁编写或贡献了哪些部分。
该列表还应提及同一软件包中分发的某些文件是否真的是一个单独的程序。
只需要列出在法律上对版权具有重要意义的贡献（请参阅法律上的重要性）。可以省略小的贡献、错误报告、想法等。
例如，这将描述 GAS 的早期版本
Dean Elsner first version of all files except gdb-lines.c and m68k.c.
Jay Fenlason entire files gdb-lines.c and m68k.c, most of app.c,
plus extensive changes in messages.c, input-file.c, write.c
and revisions elsewhere.
Note: GAS is distributed with the files obstack.c and obstack.h, but
they are considered a separate package, not part of GAS proper.
请将这些记录保存在程序源代码目录中的名为 AUTHORS 的文件中。
如果您愿意，可以使用更改日志作为这些记录的基础。只需确保记录每个更改的正确作者（编写更改的人，而不是安装更改的人），并为那些对于版权目的而言过于琐碎的更改添加‘(微小更改)’。稍后，您可以从更改日志更新 AUTHORS 文件。如果仔细格式化更改日志条目，甚至可以自动完成此操作。
可以在 AUTHORS 中包含其他电子邮件地址、姓名和程序信息，例如错误报告信息。请参阅标准邮件列表。
本节解释了将其他软件包中的代码合并到您的软件包中时的法律考虑因素。将整个模块作为一个整体使用并保持其独立性是一个不同的问题；请参阅外部库。
| • 非 FSF 版权软件包 | ||
| • FSF 版权软件包 |
在这里，我们假设您的软件包不是 FSF 版权所有。
当您从另一个具有 GPL 兼容许可证的自由软件软件包复制在法律上重要的代码时，您应该查看该软件包的记录，以找出您正在复制的部分的作者，并将他们列为您所复制代码的贡献者。如果您所做的只是复制它，而不是编写它，那么就版权而言，您不是此代码的贡献者之一。
如果代码应该在公共领域中，请确保这是真的：该代码的所有作者都放弃了版权权益。然后，当将新文件复制到您的项目中时，请在文件的开头添加一个简短的注释，记录作者、公共领域状态和任何其他相关信息。
另一方面，当将某些公共领域代码合并到受 GPL（或 LGPL 或其他自由软件许可证）保护的现有文件中时，没有理由指出哪些部分是公共领域。说明整个文件受 GPL（或其他许可证）约束的通知在法律上是充分的。
使用不在公共领域中的代码，而是根据 GPL 兼容的自由许可证发布的代码，可能需要保留版权声明或其他步骤。当然，您应该遵循所述的要求。
上一节：非 FSF 版权软件包，上一级：从其他软件包复制 [目录][索引]
如果您正在维护 FSF 版权所有软件包，请在未首先验证我们是否拥有该代码的适当法律文件的情况下，不要复制任何代码。
如果您从另一个 FSF 版权所有软件包复制，那么我们大概拥有该软件包自己代码的法律文件，但您必须检查您正在复制的代码是否是外部库的一部分；如果是这种情况，我们没有该代码的法律文件，因此您不应复制它。在任何情况下，与该软件包的开发者进行双重检查也无妨。
当你复制我们尚未有相关论文的代码时，你需要获取这些代码的论文。如果代码不是作为对你的软件包的贡献而编写的，可能很难获取这些论文，但这并不意味着可以不获取。如果你无法获取代码的论文，你只能将其用作外部库（参见外部库）。
你应该在软件包中每个重要的文件中维护适当的版权声明和许可声明。（任何超过十行的文件都为此目的而言是重要的。）这包括用于构建或运行程序的头文件和接口定义、文档文件以及任何支持文件。如果某个文件已被明确置于公共领域，那么它应该有一个声明，明确说明它在公共领域，而不是版权声明。
即使是图像文件和声音文件，如果它们的格式允许，也应包含版权声明和许可声明。某些格式没有空间容纳文本注释；对于这些文件，请在同一目录的 README 文件中说明版权和复制权限。
更改日志文件应在末尾包含版权声明和许可声明，因为新内容会添加到开头，但末尾始终是末尾。
当文件是从发行版中的其他文件自动生成时，如果可能，自动程序复制其所生成文件的版权声明和许可声明是很有用的。或者，在开头添加一个声明，说明它是从哪个文件生成的。
版权声明看起来像这样
Copyright (C) year1, year2, year3 copyright-holder
按照国际惯例，“Copyright”一词必须始终使用英文。
版权所有者 可能是自由软件基金会（Free Software Foundation, Inc.），也可能是其他人；你应该知道你的软件包的版权所有者是谁。
如果可以使用，请将 ‘(C)’ 替换为带圆圈的 C 符号。例如，在 Texinfo 文件中使用 ‘@copyright{}’。但是，除非你知道带圆圈的 C 可以工作，否则请坚持使用括号内的 ‘C’。例如，程序的标准 --version 消息应默认使用括号内的 ‘C’，尽管消息翻译可以在已知可以使用该符号的语言环境中使用带圆圈的 C。或者，可以完全省略 ‘(C)’ 或带圆圈的 C；‘Copyright’ 一词就足够了。
要更新年份列表，请添加你对软件包进行重大更改的每一年。（这里我们假设你正在使用可公开访问的修订控制服务器，以便安装的每个修订版本也立即自动发布。）当你添加新年份时，不需要跟踪哪些文件在新的一年中发生了重大更改，哪些没有。建议更简单的方法是将新年份添加到软件包中的所有文件中，并在今年余下的时间里完成此操作。
但是，不要删除旧的年份数字；它们很重要，因为它们表明较旧的版本理论上何时可能会进入公共领域，如果电影公司不继续购买法律以进一步延长版权的话。如果你从其他程序中将文件复制到软件包中，请保留该文件附带的版权年份。
当且仅当：1）范围内的每一年（包括在内）确实是应该单独列出的“可版权”年份；并且 2）你在 README 文件中明确声明了此用法，你才可以使用范围（‘2008-2010’）而不是列出单个年份（‘2008, 2009, 2010’）。
对于定期从另一个项目（例如 ‘gnulib’）复制的文件，请保留原始文件中的版权声明。
版权声明可以跨多行，无论是在源文件中还是在任何生成的输出中。对于具有悠久历史的文件来说，这种情况经常发生，它们具有许多不同的出版年份。
对于受 FSF 版权保护的软件包，如果你已遵循获取法律文件的程序，则每个文件应只有一个版权所有者：自由软件基金会（Free Software Foundation, Inc.）。你应该编辑该文件的版权声明以列出该名称，并且仅列出该名称。
但是，如果贡献者并非都将其版权分配给单个版权所有者，则一个文件很容易拥有多个版权所有者。每个贡献重要文本的贡献者都是版权所有者。
在这种情况下，你应该始终包含以该文件主要版权所有者名义的版权声明。你也可以包含其他版权所有者的版权声明，对于贡献了大量内容的人和明确要求以其名义声明的人来说，这是一个好主意。（有时，你复制的代码的许可证可能要求保留某些版权声明。）但是，你不必为每个对该文件做出贡献的人都包含声明（这会相当不方便）。
有时，程序会有一个针对整个程序的总体版权声明。它可能在 README 文件中，或者可能在程序启动时显示。此版权声明应提及最近主要版本完成的年份；它可以提及以前主要版本完成的年份，但这并非必须。
每个重要的文件都需要许可声明以及版权声明。（如果没有许可声明允许复制和更改文件，则该文件是非自由的。）
软件包本身应包含 GPL 的完整纯文本副本（通常在名为 COPYING 的文件中）和 GNU 自由文档许可证（包含在你的文档中，因此不需要单独的纯文本版本）。如果软件包包含任何根据 Lesser GPL 分发的文件，它也应包含其纯文本版本的完整副本（通常在名为 COPYING.LESSER 的文件中）。
如果你对你的 GNU 软件包的许可问题有疑问，请写信至 [email protected]。
| • 哪个 | ||
| • 规范 | ||
| • 代码 | ||
| • 文档 | ||
| • 示例 | ||
| • 其他 |
通常，GNU 软件包应使用最新版本的 GNU GPL，并使用“或任何更高版本”的措辞。有关许可声明的确切措辞，请参见代码的许可声明。
有时，GNU 库可能会提供专有程序通过其他实现已经广泛可用的功能；例如，GNU C 库。在这种情况下，应使用 Lesser GPL（同样，有关通知措辞，请参见代码的许可声明）。但是，如果 GNU 库提供独特的功能，则应使用 GNU GPL。 https://gnu.ac.cn/licenses/why-not-lgpl.html 讨论了这种战略选择。
其中一些库需要与仅在 GPLv2 下发布的程序一起工作；也就是说，允许使用 GNU GPL 版本 2 但不允许使用更高版本。在这种情况下，GNU 软件包应在双重许可下发布：GNU GPL 版本 2（或任何更高版本）和 GNU Lesser GPL 版本 3（或任何更高版本）。以下是这种情况的声明
This file is part of GNU package.
GNU package is free software: you can redistribute it and/or
modify it under the terms of either:
* the GNU Lesser General Public License as published by the Free
Software Foundation; either version 3 of the License, or (at your
option) any later version.
or
* the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your
option) any later version.
or both in parallel, as here.
GNU package is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received copies of the GNU General Public License and
the GNU Lesser General Public License along with this program. If
not, see https://gnu.ac.cn/licenses/.
对于小型软件包，你可以使用“This program”而不是“GNU package”。
下一节：代码的许可声明，上一节：GNU 软件包的许可，上一级：许可声明 [目录][索引]
你可以从多个地方获取这些文件的官方版本。你可以使用对你最方便的那个。
savannah.gnu.org 上的 gnulib 项目，你可以通过匿名 Git 或 CVS 访问它。参见 https://savannah.gnu.org/projects/gnulib。许可的官方 Texinfo 来源也位于同一位置，因此你可以将其包含在你的文档中。受 GFDL 涵盖的手册应以这种方式包含 GFDL。有关 Texinfo 手册中的完整示例，请参见Texinfo中的GNU 示例文本。
通常，程序文件（包括构建脚本、配置文件和 makefile）的许可声明应引用 GPL，如下所示
此文件是 GNU package 的一部分。
GNU package 是自由软件：你可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它，无论是许可证的第 3 版，还是（由你选择）任何更高版本。
GNU package 的发布是为了希望它有用，但不作任何保证；甚至没有对适销性或特定用途适用性的暗示保证。有关详细信息，请参见 GNU 通用公共许可证。
你应该已收到随此程序一起提供的 GNU 通用公共许可证的副本。如果不是，请参见https://gnu.ac.cn/licenses/。
但是，在一个只有几个文件的小程序中，你可以使用这种方式替代。
本程序是自由软件：你可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；无论是许可证的第 3 版，还是（由你选择）任何后续版本。
本程序的发布是为了希望它能有用，但是不提供任何担保；甚至不提供适销性或适用于特定用途的暗示担保。有关详细信息，请参阅 GNU 通用公共许可证。
你应该已收到随此程序一起提供的 GNU 通用公共许可证的副本。如果不是，请参见https://gnu.ac.cn/licenses/。
在任何一种情况下，对于那些使用 Lesser GPL（参见GNU软件包的许可）的少数软件包，请在所有三个地方的“General”之前插入单词“Lesser”。 https://gnu.ac.cn/licenses/gpl-howto.html 更详细地讨论了 GPL 的应用。
文档文件也应具有许可声明。手册应使用 GNU 自由文档许可证。以下是使用 GFDL 所有功能，在版权行之后使用的许可声明示例。
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'', with the Front-Cover Texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled ``GNU Free Documentation License''. (a) The FSF's Back-Cover Text is: ``You have the freedom to copy and modify this GNU manual. Buying copies from the FSF supports it in developing GNU and promoting software freedom.''
如果 FSF 没有以纸质形式发布本手册，则省略 (a) 中关于从 GNU Press 获取副本的最后一句。如果 FSF 不是版权所有者，则将 ‘FSF’ 替换为适当的名称。
请根据您的手册调整不变章节列表。如果没有不变章节，则写上“with no Invariant Sections”。如果您的手册不是由 FSF 出版，并且少于 400 页，则可以省略封面文本。但是，如果它是 FSF 的版权，请始终询问 FSF 该怎么做。
有关 Texinfo 手册的完整示例，请参阅 Texinfo 中的 GNU 示例文本，有关如何使用 GNU FDL 的更多建议，请参阅 https://gnu.ac.cn/licenses/fdl-howto.html。
如果您编写了人们可能想购买纸质版的手册，请写信给 [email protected]，告知 FSF。我们可能想出版它。
如果手册超过 400 页，或者 FSF 认为它可能是纸质出版的好选择，则请包含 GNU GPL，如上面的声明所示。还请包括我们标准的不可变章节，其中解释了自由文档的重要性。请写信给 [email protected] 获取此章节的副本。
当您在一个软件包中一起分发多个手册时，它们的在线形式可以共享一个 GFDL 副本（请参阅第 6 节）。但是，除非它们设置为仅一起打印和发布，否则打印的（‘.dvi’，‘.pdf’，…）形式应各自包含 GFDL 的副本。因此，通常最简单的方法是在每个手册中包含 GFDL。
当文档中的代码示例超过两三行，并且足够具体以至于人们可能想复制和修改它时，我们建议将该示例的副本放在代码文件中，并根据某些自由软件许可证发布该文件。这意味着它将根据两个不同的许可证发布：在手册中根据 GFDL 发布，在代码示例文件中根据软件许可证发布。
如果该示例很重要且不平凡，并且有 40 行或更多行，我们建议根据与其相关的程序使用相同的许可证发布代码副本。否则，我们建议根据 X11 许可证发布它。
小的支持文件、简短的手册（少于 300 行）和粗略的文档（README 文件、INSTALL 文件等）可以使用像下面这样简单的全许可许可证
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.
此许可证的旧版本没有包含明确的保修免责声明的第二句话。没有迫切需要更新现有文件，但新文件应使用新文本。
如果您的软件包分发 Autoconf 宏，这些宏旨在由可能使用不兼容许可证的第三方软件包使用（因此分发），您也可以对这些宏使用上述全许可许可证。
这些类型的文件也可以置于公共领域。如果在美国发布，插入一个声明说明即可。否则，请使用 Creative Commons 的 CC0 - 请参阅 https://creativecommons.org/choose/zero/。
作为 FSF 版权所有的 GNU 软件包的维护者，您如何使用单独发布的通用自由模块？（我们也称它们为“库”，因为我们正在将它们用作库；它们是否打包为库无关紧要。）
要求他们的作者将版权转让给 FSF 是不合理的。他们编写这些模块并不是为了对 GNU 做贡献。我们只是碰巧想使用它们，就像任何开发人员可能做的那样。无缘无故地要求开发人员将他们的版权交给 FSF 是无礼的。在这些情况下，请不要要求这样做。
使用这些模块的正确方法是将您的软件包与它们链接，并说明它们不是您的软件包的一部分。有关此操作的机制，请参见下文。
为避免当前或未来的法律纠纷，您必须确保模块的许可证与当前和未来的 GPL 版本兼容。“GNU GPL 第 3 版或更高版本”是好的，任何包含允许在这些 GPL 版本下使用的权限的内容也是好的（包括“GNU GPL 第 2 版或更高版本”、“LGPL 第 n 版或更高版本”、“LGPL 第 2.1 版”、“GNU Affero GPL 第 3 版或更高版本”）。宽松的许可许可证也可以，因为它们与所有 GPL 版本兼容。
“仅限 GPL 第 2 版”显然是不可接受的，因为它与 GPL 第 3 版不兼容。“仅限 GPL 第 3 版”和“仅限 GPL 第 2 或 3 版”存在一个更微妙的问题：如果我们要制作 GPL 第 4 版，它们将与 GPL 第 4 版不兼容，因此该模块将成为将您的软件包许可证升级为“GPL 第 4 版或更高版本”的障碍。请勿使用此类模块。
您需要避免的一个库是 goffice，因为它仅允许 GPL 第 2 和 3 版。
因此，以下是安排您的软件包使用不相关的自由模块的机制。
使用此方法，没有必要将模块视为库并从中生成 ‘.a’ 文件。您可以按通常的方式直接与 ‘.o’ 文件链接。
这两种方法都会产生不规则性，我们的律师告诉我们要尽量减少这种不规则性。因此，仅对不是为您的软件包编写的通用模块使用这些方法。对于为您的软件包贡献而编写的任何内容，请签署文件。
严格来说，这不是一个法律问题，但它似乎与版权声明有关。
在任何 FSF 版权所有的 GNU 软件包中，文件的作者都不会在版权声明中命名。因此，最好在版权声明附近的顶部包含注释行 ‘Authors: 此文件的作者’，以便在与他们的贡献紧密关联的情况下给予他们署名权。
不要觉得有义务包含别人要求您包含的每一个更改。您必须判断哪些更改是改进——部分基于您认为用户会喜欢的内容，部分基于您自己对什么更好的判断。如果您认为更改不好，您应该拒绝它。
如果有人发送给您的更改很有用，但是以丑陋的方式编写或难以理解和维护，请毫不犹豫地要求他们在您合并更改之前清理他们的更改。由于我们能够完成的工作量有限，我们说服其他人帮助我们高效工作越多，GNU 的进步就越快。
如果贡献者不愿或不能使更改足够干净，则可以说“我无法以目前的形式安装此更改；只有您清理它，我才能这样做。”邀请他以另一种方式分发他的更改，或者寻找其他人来使它们足够干净以供您安装和维护。
你自己进行这些清理工作的唯一原因是：（1）清理工作很容易，比告诉作者需要清理什么更省事；或者（2）更改很重要，重要到值得花时间清理它。
当你要求别人清理更改时，GNU 编码标准是一个很好的发送给他们参考的东西（请参阅目录，出自GNU 编码标准）。Emacs Lisp 手册包含一个附录，其中给出了 Emacs Lisp 程序的编码标准；建议 Lisp 作者阅读它（请参阅提示和惯例，出自GNU Emacs Lisp 参考手册）。
大多数 GNU 软件包都在广泛的平台上运行。这些平台并非同等重要。GNU 软件包最重要的支持平台是 GNU 操作系统的自由变体，无论它使用哪个内核。
GNU 项目的实际工作是开发 GNU 操作系统；GNU 软件包应该使整个 GNU 系统更加强大，并鼓励人们切换到该系统。
请在你的工作中牢记这些目标。例如，你添加的每个新功能都应该在 GNU 上运行。如果新功能仅在 GNU 上运行（例如，在 GNU/Linux 上），那是可以接受的。但是，一个仅在其他系统上运行，而不在 GNU 上运行的功能，将破坏目标。
因此，当被要求实现这样的功能时，请拒绝，并说明这些原因，并要求贡献者也为 GNU 系统实现该功能。请参阅不应接受的补丁。
你自然会希望程序在它支持的所有平台上都能运行。但是你个人将无法访问这些平台中的大多数——那么你该如何处理它们呢？
不要担心试图访问所有这些平台。即使你确实可以访问所有这些平台，你自己在每个平台上测试程序也是低效的。相反，你应该在少数几个平台上测试程序，包括一些 GNU 的自由变体，并让用户在其他平台上测试它。你可以在实际发布之前的预测试阶段执行此操作；当没有理由预期会出现问题时，尤其是在一个主要可移植的软件包中，你可以直接发布并让用户告诉你是否引入了任何不可移植的内容。
在 GNU 或 GNU/Linux 上亲自测试程序非常重要，因为这些是 GNU 软件包最重要的平台。如果你无法访问这些平台之一，作为 GNU 维护者，你可以访问通用的 GNU 登录机器；请参阅https://gnu.ac.cn/software/README.accounts.html。
支持其他平台是可选的——当这样做看起来是个好主意时，我们会这样做，但我们不认为这是必须的。如果用户不照顾某个平台，你可能不得不取消对该平台的支持，除非并且直到用户前来帮助。相反，如果用户提供更改以支持其他平台，你可能会想要安装它们，但你不必这样做。如果你觉得这些更改复杂而丑陋，如果你认为它们会增加未来维护的负担，你可以并且应该拒绝它们。这包括自由或主要是自由的平台，例如 OpenBSD、FreeBSD 和 NetBSD，以及非自由平台，例如 Windows。
维护程序包括接收用户建议的补丁，并决定安装哪些补丁。在很大程度上，这是一个技术优缺点的问题，作为维护者，你将权衡并判断。
但是，有些补丁存在根本的道德问题，因此你不应接受它们，除非/直到这些问题得到解决。
| • 非 GNU 专属功能 | GNU 软件包中的每个功能都应该在 GNU 上运行。 | |
| • 与非自由软件的互操作 | 不要与非自由软件的互操作性比与自由软件的互操作性更好。 | |
| • 仓库中未安装的代码 | 将代码放入软件包仓库而不安装它。 |
下一篇：与非自由软件的互操作，上一级：不应接受的补丁 [目录][索引]
请不要编写或安装在 GNU 系统上功能较差或功能较少（或没有）的特性，而不是在某些非 GNU 系统上。
任何 GNU 程序的主要目的是增强 GNU 系统赋予用户自由的能力，因此 GNU 软件包的每个特性都应该在 GNU 操作系统的自由发行版上可用和有用（https://gnu.ac.cn/distros/）。为此，“功能”是指对用户有实质性用途的操作，而不是实现的细节。我们在下面进一步解释这一点。
仅在某些非 GNU 操作系统上运行或在某些非 GNU 操作系统上运行得更好的功能会破坏该主要目的；更糟糕的是，它会以 GNU 为代价来推广该非 GNU 系统。这种情况会直接违背将用户从这些系统中解放出来的目标，即使从“开源”哲学的角度来看，安装造成这种情况的功能也被认为是可取的。
由于计算机使用的自由是整体目标，我们需要明确地追求这种自由。我们需要用我们实际的决定——以及我们对这些决定的解释——表明我们正在为比“更好的软件”和“更方便”更深刻、更重要的东西而努力。这将使用户有机会反思我们选择一条与大多数程序员不同的道路的原因。请参阅https://gnu.ac.cn/philosophy/open-source-misses-the-point.html。
因此，当作为 GNU 维护者收到在 GNU 系统上不起作用的功能的贡献时，请解释此规则及其必要性。解释说，我们需要 GNU 软件包中的所有功能在 GNU 系统上正常工作，以便它们相互增强并使 GNU 系统更好。因此，更改不应以目前的形式安装。
这并不意味着更改永远不能安装。如果并且当在 GNU 系统上对相同功能提供同样良好的支持时，可以同时安装它。解释这一点是要求人们帮助编写代码以支持 GNU 上的该功能的好机会。还应告知贡献者有关如何在 GNU 上支持此功能的资源，以便他可以考虑完成该工作或招募其他人来帮助。
如果代码的某些部分是系统独立的，并且将完成在 GNU 系统上支持该功能的部分工作，你可以立即安装它们。或者，你可以将它们放入软件包仓库，而不实际安装它们，放在 ‘wip-name’ 分支中。将它们放在存储库中可能有助于并鼓励人们完成在 GNU 上实现该功能。
如果你认为它非常重要，你可以自己实现对 GNU 系统上该功能的支持。如果你认为将来在 GNU 上拥有该功能是非常可取的，你可以做出特殊的安排，将非 GNU 系统特定的代码放入软件包仓库，但不安装它——请参阅仓库中未安装的代码。
如果该功能在 GNU 上的效果至少与在非 GNU 系统上的效果一样好，那么实现或支持非 GNU 系统上的功能是可以的，即使它在不同系统上的实现方式不同，在其实现中使用不同的系统设施，或者在某些细节上对用户看起来不同。在每个系统上，以方便或传统的方式使这些功能工作是可以的。关键是程序和功能应该“在 GNU 上运行最佳”。
如果某些其他系统上的系统设施在没有任何特殊的应用程序代码的情况下提供了 GNU 上不可用的功能，则无需进行工作来阻止其运行。在这种情况下，我们应该努力在 GNU 中实现该功能。
我们不认为控制或配置特定操作的接口的细枝末节，或实现操作的细节是“功能”。同样，系统设施（包括系统附带的库）是实现功能的手段，但使用该设施本身并不是功能。
例如，编程平台通常提供一个接口来低级别控制计算机或操作系统。如果软件包也支持 GNU 系统上的相同功能，即使从系统到系统调用该功能的详细信息有所不同，也可以在非 GNU 系统上支持低级别控制的功能。但是，请务必使跨系统的该功能调用一致，以便支持多个系统上的特定操作。
主要用于与其他用户的计算机通信，或者在未设置为紧密耦合使用的计算机组之间通信的功能，则完全是另一回事。只有当一个通信功能与GNU系统的自由发行版互操作时，它才真正与GNU上的“相同功能”相同——例如，TCP/IP就是这样。对于非GNU系统来说，不可移植的、特定于系统的通信设施是对社区的滥用，因此请不要安装对它们的支持。这一点也适用于程序之间通信使用的文件格式，如果需要在不相关的计算机之间移动这些文件。（例外：如果可以做到，编写代码从这样的文件中提取用户的数据是值得赞赏的。）
最后，请注意不要让安装或支持非GNU系统的特定于系统的代码占用您太多时间。请参阅GNU编码标准中的GNU编码标准。
假设有人要求在某个非GNU系统上支持功能F，而功能F在GNU上可以工作。如果您愿意，您可以说是的，但您没有义务编写或维护该代码。您可以告诉他们，编写和维护该代码是他们的责任。如果他们为此编写了良好且简洁的代码，您可以批准安装它，但这并不意味着您或任何其他人有义务支持它。如果有一天代码出现位腐烂，如果用户不修复它，您可以删除它。
请参阅建议的回复，其中提供了一些您可以使用的文本，或者您可以根据需要进行修改，来拒绝这些补丁。它的目的是邀请他们在新的功能中同样良好地支持GNU系统。如果没有这种希望，那么简单地说“不，谢谢”就足够了。
在GNU程序中实现一些功能，使其能够方便地与广泛使用的非自由工具和应用程序协同工作是很常见的。但是，在某些情况下，您不应该实现与非自由程序（这里我们称之为ShackleMe）的合作。
请参阅建议的回复，其中提供了一些文本，如果您愿意，可以使用这些文本来表明您拒绝在没有对ShackleMe的自由竞争对手提供同样良好支持的情况下支持ShackleMe。其目的是邀请贡献者支持这些竞争对手。您可以根据需要对其进行修改以适应具体情况。
上一篇：与非自由软件的互操作，上一级：不应接受的补丁 [目录][索引]
当您想将非GNU功能的系统相关代码放入软件包仓库，而实际上不安装它时，您需要与GNU项目进行特殊安排。
要做到这一点，您可以写信给[email protected]，解释该功能、它对其他系统的依赖性以及阻止在GNU上支持它的障碍。他们将确保您理解情况和安排，并让您承诺如果该功能未完成，则以后以正确的方式让该分支消失。
实际上，这些特殊安排意味着您将代码放在软件包仓库中的一个不鼓励的分支中，以表明它未安装，您没有完成它的承诺，并且它可能会消失。将该分支命名为“ungnu-temp/name”。（如果该名称与您使用的版本控制系统不符，我们将制定解决方案。）
在该分支中放入一个README文件，说明如下
This code partially implements the what is it feature. We can't install it now because it needs to be finished, so that it runs on the GNU system. We invite you to write the missing code to implement this feature on GNU, so we can install the feature. Until then, this branch must not be merged into any branch that might ever be released. See the section "Don't Install a Feature Until It Works on GNU", in the GNU Maintainer's Guide, for explanation of the reasons for this.
不鼓励的分支“消失”是因为您不从程序的开发主干中合并更改。如果该分支过于过时以至于无法工作，您只需删除它即可。
本章描述了如何为您的软件包设置邮件列表，并提供了关于如何处理错误报告和随机请求的建议。
| • 标准邮件列表 | “[email protected]”和其他标准名称。 | |
| • 创建邮件列表 | 最好的方法是使用Savannah。 | |
| • 回复邮件 | 关于回复收到的邮件的建议。 |
一旦程序投入使用，您将收到关于它的错误报告。大多数GNU程序都有自己的特殊列表用于发送错误报告。广告中宣传的错误报告电子邮件地址应始终为“bug-package@gnu.org”，以帮助向用户表明该程序是GNU软件包，但如果您愿意，可以设置该列表转发到另一个站点。
我们还有一个包罗万象的列表，[email protected]，用于所有没有自己的特定列表的GNU程序。但是现在我们想给每个程序自己的错误报告列表，并停止使用bug-gnu-utils。
请参阅回复邮件，了解更多关于处理和跟踪错误报告的信息。
一些拥有许多用户的GNU程序有一个帮助列表，“help-package@gnu.org”，供人们向其他用户寻求帮助。如果您的程序有很多用户，您应该为此创建一个这样的列表。对于一个相当新的程序，它还没有庞大的用户群，最好不要为此烦恼。
如果您愿意，您还可以拥有一个邮件列表“info-package@gnu.org”，用于发布公告（请参阅公告）。您认为有用的任何其他邮件列表也可以创建。
软件包分发应在显眼的位置声明所有软件包的邮件列表的名称，并要求用户通过适当地报告错误来帮助我们。顶级的README文件和/或AUTHORS文件是好地方。邮件列表信息也应包含在手册和软件包网页中（请参阅网页）。
使用savannah.gnu.org上的Web界面是创建通过GNU邮件服务器上的Mailman管理的普通邮件列表的最简单方法。一旦您在Savannah上注册您的软件包，您就可以通过“邮件列表”菜单自己创建（和删除）列表，而无需等待任何其他人的干预。此外，通过Savannah创建的列表将具有合理的默认配置，以用于反垃圾邮件目的（见下文）。
要创建和维护简单的别名和非托管列表，您可以在主GNU服务器上编辑/com/mailer/aliases。如果您在那里没有帐户，请阅读https://gnu.ac.cn/software/README.accounts.html（请参阅GNU帐户和资源）。
但是，如果您不想学习如何做这些事情，可以请[email protected]帮助您。
您应该审核来自未订阅地址的邮件列表帖子，以防止将不需要的消息（“垃圾邮件”）传播给订阅者和列表存档。对于由Mailman控制的列表，您可以通过将Privacy Options - Sender Filter - generic_nonmember_action设置为Hold来完成此操作，然后定期（最好是每天）查看保留的消息，接受真实的消息并丢弃垃圾邮件。
通过Savannah创建的列表将具有此设置以及许多其他设置，以便自动删除垃圾邮件（短暂延迟后）。Savannah邮件列表页面描述了所有详细信息。您仍然应该查看保留的消息，以便批准任何真实的消息。
当您收到错误报告时，请记住，错误报告对您的工作至关重要。如果您不知道问题，就无法解决它们。因此，请始终感谢每个发送错误报告的人。
不过，您没有义务给出比这更多的回应。错误报告的主要目的是通过改进程序的下一个版本来帮助您为社区做出贡献。许多报告错误的人没有意识到这一点——他们认为重点是您单独帮助他们。有些人会要求您把重点放在这一点上，而不是改进程序。如果您遵从他们的意愿，您将无法专注于维护程序的工作。
例如，人们有时会以模糊（因此无用）的方式报告错误，当您要求提供更多信息时，他们会说：“我只是想看看您是否已经知道解决方案”（在这种情况下，错误报告将无助于改进程序）。发生这种情况时，您应该向他们解释错误报告的真正目的。（一个预先准备好的解释将使这更有效率。）
当人们要求您花时间帮助他们使用该程序时，执行他们要求的操作可能看起来“有帮助”。但是，这比改进程序要少得多的帮助，而改进程序才是维护人员的真正工作。
当您愿意并且有时间时，请尽一切努力帮助个别用户。但是请注意限制您花在这方面的时间量——不要让它蚕食您维护程序所需的时间！知道如何拒绝；当您时间紧迫时，只需回复“感谢您的错误报告——我会修复它”就足够了。
一些GNU软件包，如Emacs和GCC，提供了关于如何使错误报告有用的建议。复制和调整这些建议可能对您的软件包非常有用。
如果您想使用基于电子邮件的错误跟踪系统，请访问 https://bugs.gnu.org；这可以与常规的错误报告地址连接。或者，如果您想使用基于 Web 的错误跟踪系统，Savannah 支持此功能（请参阅 旧版本），但请不要拒绝通过常规电子邮件接收错误报告——我们不希望为用户提交报告设置不必要的障碍。
备份所有 GNU 源文件的备份文件非常重要。如果愿意，您可以使用源代码控制系统（如 Bazaar、RCS、CVS、Git、Subversion 等）来完成此操作。通过 Emacs 中的版本控制库可以轻松使用许多此类系统（请参阅 GNU Emacs 手册 中的 版本控制简介）。
先前修订的历史记录和日志条目对于软件包的未来维护者非常重要，因此即使您不公开访问，也要小心不要将任何您不希望有一天交给其他维护者的内容放入存储库或更改日志中。
GNU 项目提供了一个服务器，GNU 软件包可以使用它进行源代码控制和其他软件包需求：savannah.gnu.org。Savannah 由 [email protected] 管理。有关使用和贡献 Savannah 的更多详细信息，请参阅 https://savannah.gnu.org/maintenance。
这不是绝对要求，但强烈鼓励所有 GNU 维护者利用 Savannah，因为共享这样一个中心点有助于在 GNU 开发人员之间培养社区意识，并有助于跟上项目管理。请不要将 GNU 软件包的 Savannah 项目标记为私有；这在很大程度上违背了最初使用 Savannah 的目的。
如果您使用 Savannah，请订阅 [email protected] 邮件列表（https://lists.gnu.org/mailman/listinfo/savannah-announce）。这是一个低流量列表，用于通知 Savannah 用户系统升级、问题等。
在制作 GNU 软件发行版时，请遵循 GNU 约定。
| • 发行版 tar 文件 | ||
| • 发行版补丁 | ||
| • 二进制发行版 | ||
| • 在 ftp.gnu.org 上发行 | ||
| • 测试版本 | ||
| • 自动 FTP 上传 | ||
| • 公告 |
所有软件包都应提供 tar 文件用于发行其版本。程序 foo 的版本 m.n 的 tar 文件应命名为 foo-m.n.tar。它应该解压缩到名为 foo-m.n 的子目录中。Tar 文件不应解压缩到当前目录中的文件中，因为如果用户恰好解压缩到包含其他文件的目录中，这会很不方便。
以下是 Bison 的 Makefile 如何创建 tar 文件。此方法也适用于其他程序。
dist: bison.info
echo bison-`sed -e '/version_string/!d' \
-e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
-rm -rf `cat .fname`
mkdir `cat .fname`
dst=`cat .fname`; for f in $(DISTFILES); do \
ln $(srcdir)/$$f $$dst/$$f || { echo copying $$f; \
cp -p $(srcdir)/$$f $$dst/$$f ; } \
done
tar --gzip -chf `cat .fname`.tar.gz `cat .fname`
-rm -rf `cat .fname` .fname
如果使用 ln 安装，则无法在临时目录中安装指向其他文件系统的符号链接，因此如果 ln 失败，请使用 cp。
使用 Automake 是处理编写 dist 目标的好方法。
下一篇：二进制发行版，上一篇：发行版 tar 文件，上级：发行版 [目录][索引]
如果程序很大，则为每个版本创建一组相对于先前重要版本的差异很有用。
在差异集的前面，简要说明这是哪个版本以及它相对于哪个先前版本。还应说明人们还需要做些什么才能正确更新源代码（例如，在安装差异之前删除或重命名某些文件）。
拥有差异的目的是使其小巧。为了保持它们的小巧，请排除用户可以轻松更新的文件。例如，排除 info 文件、DVI 文件、标签表、Bison 或 Flex 的输出文件。在 Emacs 差异中，我们排除编译后的 Lisp 文件，留给安装程序重新编译修补后的源代码。
制作差异时，每个版本都应位于适当命名的目录中，例如 gcc-2.3.2 和 gcc-2.3.3。这样，从差异本身就可以清楚地看出哪个版本是哪个。
如果您使用 GNU diff 制作补丁，请使用 ‘-rc2P’ 选项。这会将任何新文件以“完全不同”的方式放入输出中。此外，补丁的上下文差异标题应使用传统的 Unix 格式以通用时间显示日期和时间，以便补丁接收者可以使用 GNU patch 的 ‘-Z’ 选项。例如，您可以使用以下 Bourne shell 命令来创建补丁
LC_ALL=C TZ=UTC0 diff -rc2P gcc-2.3.2 gcc-2.3.3 | \ gzip -9 >gcc-2.3.2-2.3.3.patch.gz
如果发行版包含子目录，则差异可能包含子目录中的某些文件。为了帮助用户可靠地安装此类补丁，请向他们提供有关如何运行 patch 的精确说明。例如，说
To apply these patches, cd to the main directory of the program and then use ‘patch -p1’. ‘-p1’ avoids guesswork in choosing which subdirectory to find each file in.
明智的做法是将您的补丁应用到旧版本的副本，并检查结果是否与新版本完全匹配。
下一篇：在 ftp.gnu.org 上发行，上一篇：发行版补丁，上级：发行版 [目录][索引]
一些软件包维护者发布用于专有系统（如 Microsoft Windows 或 MacOS）的预编译二进制文件。是否执行此操作完全取决于您；我们不要求您执行此操作，但我们也不反对。请不要让任何人让您感到有义务这样做。
如果您分发它们，请突出告知其用户，这些非自由平台践踏了他们的自由。最好将他们推荐到 https://gnu.ac.cn/philosophy/free-software-even-more-important.html。您可以说：“此程序尊重您的自由，但 Windows 不尊重。要获得自由，您需要停止使用 Windows 和其他剥夺您自由的软件。”
ftp.gnu.org 上的发行我们强烈建议使用 ftp.gnu.org 来分发官方版本。如果您也想从您自己的站点分发软件包，那也没关系。接受使用其他站点代替 ftp.gnu.org，前提是它允许来自任何地方的任何人的连接。
有关将新版本放在 ftp.gnu.org 上的程序详细信息，请参阅 自动 FTP 上传。
下一篇：自动 FTP 上传，上一篇：在 ftp.gnu.org 上发行，上级：发行版 [目录][索引]
当您发布程序的大幅更改的新主版本时，您可能希望将其作为预测试进行。这意味着您创建一个 tar 文件，但仅将其发送给您招募的一组志愿者。（使用合适的 GNU 邮件列表/新闻组来招募他们。）
我们通常使用服务器 alpha.gnu.org 进行预测试和预发布版本。有关将新版本放在 alpha.gnu.org 上的程序详细信息，请参阅 自动 FTP 上传。
一旦程序被广泛使用并且人们期望它能够稳定工作，在每个“真实”版本之前进行预测试版本是个好主意。
有三种方法可以处理预测试版本的版本号。一种方法是将它们视为要发布的版本之前的版本。
在这种方法中，如果您即将发布 4.6 版本但您想先进行预测试，请将其命名为 4.5.90。如果您需要进行第二次预测试，请将其命名为 4.5.91，依此类推。如果您真的很不幸，并且十次预测试还不够，在 4.5.99 之后，您可以前进到 4.5.990，依此类推。（您也可以使用 4.5.100，但 990 的优点是按正确的顺序排序。）
另一种方法是将日期附加到即将发布的版本号上。对于 2002 年 12 月 10 日发布的 4.6 版本的预测试，这将是 4.6.20021210。同一天进行的第二次预测试可能是 4.6.20021210.1。
对于不是正式预测试的开发快照，仅使用日期而不使用版本号也可以。
第三种方法是，如果软件包使用 Git，则运行 Gnulib 中的脚本 build-aux/git-version-gen 以生成测试发布版本号。它生成的版本号形式为 ‘version.commits-commithash’，其中 version 是最新的版本标签，commits 是自该标签以来的提交次数，commithash 是最新提交的哈希代码。
您永远不应该做的一件事是发布与计划的真实版本具有相同版本号的预测试。许多人只会查看版本号（在 tar 文件名、它解压缩到的目录名或他们可以找到的任何位置）来确定 tar 文件是否为最新版本。人们可能会以这种方式查看测试版本并将其误认为是真实版本。因此，在发布更改的代码时，请始终更改该数字。
为了将新版本上传到 ftp.gnu.org 或 alpha.gnu.org，您首先需要注册必要的信息。然后，您可以自己执行上传，无需系统管理员的干预。
总的想法是，版本在公开可用之前应进行加密签名。
| • 自动上传注册 | ||
| • 自动上传过程 | ||
| • FTP 上传发布文件三元组 | ||
| • FTP 上传指令文件 | ||
| • FTP 上传目录树 | ||
| • FTP 上传文件替换 | ||
| • FTP 上传独立指令 | ||
| • FTP 上传指令文件 - v1.1 | ||
| • FTP 上传指令文件 - v1.0 |
下一篇： 自动化上传流程，上一篇： 自动化 FTP 上传 [目录][索引]
以下是如何注册您的信息，以便您可以为您的 GNU 软件包执行上传操作
gpg --clearsign msgfile 对其进行 GPG 签名，最后将生成的 msgfile.asc 作为附件通过电子邮件发送至 [email protected]。可选但推荐：将您的密钥发送到 GPG 公钥服务器：gpg --keyserver keys.gnupg.net --send-keys keyid...，其中 keyid 是 gpg --list-public-keys 在日期之前的 pub 行报告的八个十六进制数字。有关 GPG 的完整信息，请参阅 https://gnu.ac.cn/software/gpg。
当管理员添加正确的 GPG 密钥作为授权上传相应软件包的文件时，他们会确认您的消息。
当上传成功或失败时，上传系统会将收据通过电子邮件发送到给定的电子邮件地址。
如果您以后需要更新您的 GPG 密钥，您必须将其重新提交给 Savannah 和 [email protected]，因为这些系统没有连接。
下一篇： FTP 上传发布文件三元组，上一篇： 自动化上传注册，上一篇： 自动化 FTP 上传 [目录][索引]
一旦您按照上一节中的描述注册了您的信息，您就可以并且应该为您的软件包执行 ftp 上传。有两种基本类型的上传（详细信息在以下章节中）
ftp.gnu.org 或 alpha.gnu.org 的文件：请参阅 FTP 上传发布文件三元组。在任何一种情况下，您都通过匿名 ftp 将文件上传到主机 ftp-upload.gnu.org。如果上传的目标是 ftp.gnu.org，则将文件放在目录 /incoming/ftp 中。如果上传的目标是 alpha.gnu.org，则将文件放在目录 /incoming/alpha 中。
上传每五分钟处理一次。当上传处理脚本运行时正在进行的上传会得到正确处理，因此无需担心上传时间。虚假和过时的上传文件会在 24 小时后自动删除。
如果处理您软件包的上传时出现问题，会将消息发送到您指定的上传电子邮件地址（请参阅 自动化上传注册）。当上传已成功处理时，您还会收到一条消息。
创建和传输必要文件的一种编程方法是使用 gnupload 脚本，该脚本可从 gnulib 项目的 build-aux/ 目录中获取，网址为 https://savannah.gnu.org/projects/gnulib。运行 gnupload --help 以获取描述和示例。（使用 gnupload，您指定一个目标，例如 ‘ftp.gnu.org:’pkgname，而不是使用 ‘ftp-upload’ 主机名。）
gnupload 调用程序 ncftpput 来执行实际传输；如果您碰巧没有安装 ncftp 软件包，则 gnulib 的 build-aux/ 目录中的 ncftpput-ftp 脚本可以用作替代品。它使用普通的命令行 ftp 程序。
如果您在上传时遇到困难，请发送电子邮件至 [email protected]。您可以在 https://lists.gnu.org/archive/html/ftp-upload-report 处查看已处理上传的存档。
下一篇： FTP 上传指令文件，上一篇： 自动化上传流程，上一篇： 自动化 FTP 上传 [目录][索引]
通常，目标是上传您的软件包的新版本，例如，源存档 foo-1.0.tar.gz。为此，您同时上传三个文件
文件的名称很重要。签名文件的名称必须与要分发的文件的名称相同，并附加一个 .sig 扩展名。指令文件的名称必须与要分发的文件的名称相同，并附加一个 .directive.asc 扩展名。如果您不遵循此命名约定，则上传将不会被处理。
下一篇： FTP 上传目录树，上一篇： FTP 上传发布文件三元组，上一篇： 自动化 FTP 上传 [目录][索引]
重申一下，（签名的）指令文件必须是每次上传的一部分。未签名的原始文件只是一个纯文本文件，您可以使用任何文本编辑器创建。它的名称必须是，例如，foo-1.0.tar.gz.directive，用于随附 foo-1.0.tar.gz 的上传。
创建文件后，运行 ‘gpg --clearsign foo-1.0.tar.gz.directive’，这将创建 foo-1.0.tar.gz.directive.asc；这是要上传的文件。
当作为上传发布文件的三元组的一部分时，指令文件必须始终包含指令 version、filename 和 directory。此外，comment 指令是可选的。这些指令可以按任何顺序给出。
继续我们的示例，即为名为 foo 的软件包将 foo-1.0.tar.gz 上传到 ftp.gnu.org，其值如下
version必须是值 ‘1.2’（截至 2012 年 5 月的当前版本）
version: 1.2
filename必须是要分发的文件名
filename: foo-1.0.tar.gz
directory指定上传的文件及其 .sig 配件的最终目标目录。这里我们将文件放在软件包的顶层目录中，这是最常见的做法
directory: foo
comment是可选的，如果存在则忽略
comment: let's hope this works!
将上述所有内容放在一起，我们的示例中指令文件 foo-1.0.tar.gz.directive 的完整内容将是
version: 1.2 directory: foo filename: foo-1.0.tar.gz comment: let's hope this works!
然后，您按照上面的说明 ‘gpg --clearsign’ 该文件，并（使用匿名 ftp）上传三个文件
到主机 ftp-upload.gnu.org，目录 /incoming/ftp（对于官方版本），或目录 /incoming/alpha（对于测试版本）。
系统验证签名后，文件 foo-1.0.tar.gz 和 foo-1.0.tar.gz.sig 将放置在 ftp.gnu.org 上的目录 gnu/foo/ 中。也就是说，我们将在 ‘https://ftp.gnu.org/gnu/foo/foo-1.0.tar.gz’ 上提供我们的版本（然后通过 ‘https://ftpmirror.gnu.org/foo/foo-1.0.tar.gz’ 从我们的许多镜像中提供）。唷。
上传未成功的一个常见原因是您的 GPG 签名未在上传系统中注册。没有任何东西可以使其自动发生。您必须按照上述说明向系统管理员发送电子邮件（请参阅 自动化上传注册）。
下一篇： FTP 上传文件替换，上一篇： FTP 上传指令文件，上一篇： 自动化 FTP 上传 [目录][索引]
您可以在软件包目录下创建任何您喜欢的目录层次结构。系统会自动创建您在 directory 指令中指定的任何中间目录。
稍微修改上面的示例，以下指令文件
version: 1.2 directory: foo/foo-1.0 filename: foo-1.0.tar.gz comment: creates per-version subdirectory as needed
会将 tar 文件放在软件包 foo 的 foo-1.0/ 子目录中，从而最终到达 ‘ftp.gnu.org:gnu/foo/foo-1.0/foo-1.0.tar.gz’。
但是，为了使用户的操作更简单，我们建议不要使用子目录，除非您的软件包的每个版本都包含许多单独的文件。
下一篇： FTP 上传独立指令，上一篇： FTP 上传目录树，上一篇： 自动化 FTP 上传 [目录][索引]
您可以通过包含指令行 replace: true 来替换已上传的现有文件。例如，您可能希望在发布目录中提供 README 文件，并随时更新它。完整的指令文件如下所示
replace: true version: 1.2 directory: foo filename: README comment: replaces an existing README
如果要替换的文件尚不存在也没关系；那么只会简单地添加新文件，即 replace 指令不起作用。
替换现有文件时，原始文件会存档到私有位置。没有对这些存档文件的自动或公共访问；如果您想检索或查看它们，请发送电子邮件至 [email protected]。
我们强烈建议不要替换实际的软件发布文件，例如 foo-1.0.tar.gz。版本应该是唯一的，并且永远存在。如果您有迫切的原因需要让特定发布文件不再可用，则可以按照下一节中的描述显式存档。
如果您想在通用名称（例如 foo-latest.tar.gz）下提供当前版本，则最好使用符号链接来完成，这也在下一节中描述。
下一篇： FTP 上传指令文件 - v1.1，上一篇： FTP 上传文件替换，上一篇： 自动化 FTP 上传 [目录][索引]
前面的章节描述了如何上传要公开发布的文件。也可以单独上传指令文件，以在上传目录上执行一些操作。支持的指令有
symlink创建符号链接。
rmsymlink删除符号链接。
archive使文件或目录离线。
至于上述指令，directory 和 version 指令仍然是必需的，comment 指令仍然是可选的，而 filename 指令是不允许的。
在指令中不应明确提及 .sig 文件。当您指定一个指令来操作文件时，其对应的 .sig 文件将自动处理。
当单独上传时，指令文件的名称并不重要。但它仍然必须使用 ‘gpg --clearsign’ 进行签名；应该上传的是生成的 .asc 文件。
以下是创建 foo-latest.tar.gz 符号链接的完整指令文件示例
version: 1.2 directory: foo symlink: foo-1.1.tar.gz foo-latest.tar.gz comment: create a symlink
如果您在单独上传中包含多个指令，则这些指令会按照它们在文件中指定的顺序执行。如果某个指令导致错误，则会中止进一步的上传执行。
删除不存在的符号链接（使用 rmsymlink）会导致错误。另一方面，尝试创建已经存在的符号链接（使用 symlink）不会导致错误。在这种情况下，symlink 的行为类似于命令 ln -s -f：在创建链接之前，任何现有的符号链接都会被删除。（但是不会替换现有的常规文件或目录。）
以下是删除符号链接的示例，例如，如果您决定不再维护 foo-latest 链接
version: 1.2 directory: foo rmsymlink: foo-latest.tar.gz comment: remove a symlink
以下是存档文件的示例，例如，意外上传的文件
version: 1.2 directory: foo archive: foo-1.1x.tar.gz comment: archive an old file; it will not be comment: publicly available any more.
archive 指令会导致指定的项目变得不可访问。只有当它们可用时会产生负面影响时才应使用此指令，例如，您错误地上传了某些内容。
如果仅仅想减少发布目录中的内容，另一种方法是发送电子邮件给 [email protected]，让他们将旧项目移动到 https://ftp.gnu.org/old-gnu/ 目录；这样它们仍然可用。但一般来说，我们建议将所有官方版本保留在主发布目录中。
下一篇：FTP 上传指令文件 - v1.0，上一篇：FTP 上传独立指令，上一级：自动 FTP 上传 [目录][索引]
v1.1 上传协议缺少 replace 指令；相反，文件替换是自动且静默完成的（显然是不希望的）。这是 v1.2 和 v1.1 之间唯一的区别。
上一篇：FTP 上传指令文件 - v1.1，上一级：自动 FTP 上传 [目录][索引]
对 v1.0 上传的支持已于 2012 年 5 月停止；请升级到 v1.2。
在 v1.0 中，指令文件包含一行，不包括 GPG 插入的 clearsigned 数据，该行指定要放置项目 (1) 和 (2) 的最终目标目录。
例如，foo-1.0.tar.gz.directive.asc 文件可能包含单行
directory: bar/v1
此目录行指示 foo-1.0.tar.gz 和 foo-1.0.tar.gz.sig 是包 bar 的一部分。如果您将三元组上传到 /incoming/ftp，并且系统可以成功验证签名，则文件 foo-1.0.tar.gz 和 foo-1.0.tar.gz.sig 将被放置在 ftp.gnu.org 站点的 gnu/bar/v1 目录中。
指令文件可用于创建当前不存在的目录树，只要它们位于您的软件包的软件包目录下（在上面的示例中，即 bar）。
当您有新版本时，请发布公告。对于官方新版本，包括仅为修复错误而发布的版本，我们强烈建议使用（审核的）GNU 常规公告列表 [email protected]。这样做可以使用户和开发人员更容易找到最新的 GNU 版本。另一方面，除非情况非常特殊，否则请不要在 info-gnu 上发布测试版本。
还请在您的 Savannah 项目站点的新闻部分发布版本公告。在这里，也可以为测试版本和任何其他值得关注的事件撰写新闻条目。除非条目的文本包含字符串 ‘::noplanet::’，否则来自 Savannah 的所有 GNU 项目的新闻提要都会在 https://planet.gnu.org (GNU Planet) 上聚合。您也可以直接发布项目，或安排来自其他位置的提要；请参阅 GNU Planet 网页上的信息。
如果您愿意，也可以维护自己的邮件列表（通常是 ‘info-package@gnu.org’）用于发布公告。当然，对于您自己的列表，您可以根据自己的判断决定哪些事件值得发布。（请参阅 邮件，了解如何设置以及有关处理您的软件包邮件的更多建议。）
在撰写公告时，请包括以下内容
https://gnu.ac.cn/software/package/’）。https://ftp.gnu.org/gnu/package/’）。提及 https://gnu.ac.cn/order/ftp.html 上的镜像列表以及 ‘https://ftpmirror.gnu.org/package/’ 将自动重定向到附近的镜像也很有用。您可能会发现 announce-gen 脚本对于创建公告很有用，该脚本可从 https://savannah.gnu.org/projects/gnulib 的 gnulib 项目的 build-aux/ 目录中获取。
下一篇：道德和哲学方面的考虑，上一篇：发行版，上一级：顶部 [目录][索引]
当我们称一个程序为 GNU 软件包时，我们会将其 GNU 主页（在 ‘https://gnu.ac.cn/software/’ 中命名为 package）列在 https://gnu.ac.cn/software/software.html 和 https://gnu.ac.cn/manual/manual.html 上。为了避免出现断开的链接，网站管理员会创建如下所示的临时主页
https://savannah.gnu.org/projects/package’，其中应提供简短的描述。此临时主页应尽快替换为真实主页。
一些 GNU 软件包只有简单的网页，但是您提供的有关信息越多越好。因此，请尽可能多地撰写内容，并将所有内容放在 www.gnu.org 上。但是，访问数据库的页面（包括邮件存档和错误跟踪）是一个例外；请将它们设置在方便您的任何站点上，并使 www.gnu.org 上的页面链接到该站点。
您的网页应遵循我们的惯例标准（请参阅 https://gnu.ac.cn/server/fsf-html-style-sheet.html）。总体目标是支持各种浏览器，专注于信息而不是视觉装饰，并使 gnu.org/software/ 在某些重要方面保持一致。
我们鼓励您使用标准的 www.gnu.org 模板作为您页面的基础：https://gnu.ac.cn/server/standards/boilerplate-source.html。此模板会因各种原因而时不时地发生细微变化。如果更改影响现有网页，网站管理员会通知您；然后您可以进行更改，或者他们也可以进行更改。
请在您的网页中遵循最佳的无障碍实践（请参阅 https://gnu.ac.cn/accessibility/accessibility.html）。
| • 网页托管 | ||
| • 网页的自由 | ||
| • 网页上的手册 | ||
| • 网页中的 CVS 关键字 |
维护您的项目网页的最佳方法是在 savannah.gnu.org 上注册该项目。然后，您可以使用 CVS 编辑页面，使用 Savannah 上提供的单独的 “网页存储库”，该存储库对应于 ‘https://gnu.ac.cn/software/package/’。您也可以将源文件保存在那里（使用各种版本控制系统中的任何一个），但是如果您愿意，可以将 savannah.gnu.org 仅用于您的 gnu.org 网页；只需注册一个“仅限 Web”的项目即可。
如果您不想使用该方法，请与 [email protected] 讨论其他可能的方法。例如，如果需要，您可以将页面邮寄给他们进行安装。但是，这对他们来说工作量更大，因此如果可以，请使用 Savannah。
请注意，GNU 网站管理员可能会修复您的网页中的技术细节（HTML、CSS、明显的错别字、页脚中损坏的链接等），并在更改后通知您。
如果您使用 Savannah，则可以使用名为 .symlinks 的特殊文件来创建 CVS 中不支持的符号链接。有关详细信息，请参阅 https://gnu.ac.cn/server/standards/README.webmastering.html#symlinks。
如果您使用 www.gnu.org 以外的站点，请确保该站点仅在自由软件上运行。（如果该站点使用未发布的自定义软件，则可以，因为这在微不足道的意义上是自由的：只有一个用户，并且它具有四种自由。）如果 GNU 软件包的网站在非自由软件上运行，公众会看到这一点，并且它将具有授予非自由程序合法性的作用。
如果您使用多个站点，则它们都应遵循该标准。除非遵循该标准，否则请不要链接到与您的软件包相关的站点，公众可能会认为该站点与您的软件包相关并且反映其开发人员的立场。
请确保可以使用 Lynx 浏览器以及启用 LibreJS 的 IceCat 浏览器完全使用该网站。它应该在 Tor 和不使用 Tor 的情况下都能工作。当然，该网站最好尽可能支持更多的其他浏览器。
从历史上看，由于专利问题，GNU 软件包的网页不包含 GIF 图像（请参阅 道德和哲学方面的考虑）。尽管 GIF 专利于 2006 年到期，但仍不建议使用 GIF 图像，因为 PNG 和 JPEG 格式通常更优越。请参阅 https://gnu.ac.cn/philosophy/gif.html。
请确保您网页中的任何 JavaScript 代码都采用自由许可协议，并以 LibreJS 可以识别的方式标明其许可协议。请参阅 https://gnu.org/philosophy/javascript-trap.html。如果页面中的 JavaScript 代码经过了压缩，或者由于任何其他原因不是源代码，则必须按照该页面中的描述指向其源代码。
下一节：网页中的 CVS 关键字，上一节：网页的自由，上级：网页 [目录][索引]
软件包的网页应包含其手册，格式包括 HTML、DVI、Info、PDF、纯 ASCII 和 Texinfo 源代码。所有这些都可以使用 Makeinfo 和其他程序从 Texinfo 自动生成。如果 Texinfo 本身是从其他源格式生成的，也请包含该源格式。
当只有一个手册时，将其放在名为 manual 的子目录中；manual/index.html 文件应包含指向该手册各种格式的链接。
如果软件包有多个手册，请将每个手册放在 manual 的一个子目录中，在每个子目录中设置 index.html 以链接到该手册的所有格式，并使 manual/index.html 通过其子目录链接到每个手册。
请参阅下面的部分，了解有关使创建所有这些不同格式和索引页面的工作更轻松的脚本的详细信息。
我们希望在 https://gnu.ac.cn/manual 页面上列出所有 GNU 手册，因此如果您的手册不在那里，请发送邮件至 [email protected]，要求他们添加您的手册，他们将根据您的 manual 目录的内容进行添加。
| • 调用 gendocs.sh |
gendocs.sh脚本 gendocs.sh 简化了为上面的网页部分生成 Texinfo 文档输出的任务。它有一个配套的模板文件，用作 HTML 索引页面的基础。两者都可从 Gnulib 开发中获得
https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/gendocs.sh https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/gendocs_template
还有一个简约的模板，可从以下位置获得
在包含 Texinfo 源的目录中，像这样调用脚本
gendocs.sh --email yourbuglist yourmanual "GNU yourmanual manual"
其中 yourmanual 是您的软件包的简称，yourbuglist 是错误报告的电子邮件地址（应为 bug-package@gnu.org）。脚本处理文件 yourmanual.texinfo （或 .texi 或 .txi）。例如
cd .../texinfo/doc # download gendocs.sh and gendocs_template gendocs.sh --email [email protected] texinfo "GNU Texinfo manual"
gendocs.sh 创建一个子目录 manual/，其中包含以所有标准输出格式生成的手册：Info、HTML、DVI 等，以及 Texinfo 源代码。然后，您需要将所有这些文件（保留子目录）移动到您的软件包的网页中。
您可以指定选项 -o outdir 来覆盖名称 manual。任何以前的 outdir 内容都将被删除。
第二个参数，带有描述，作为整体 manual/index.html 文件的 HTML <title> 的一部分包含在内。它应该包含被记录的软件包的名称，如所示。manual/index.html 是通过从 gendocs_template 文件中替换而创建的。（随意为您的目的修改通用模板。）
如果您有多个手册，您需要使用不同的参数多次运行此脚本，每次使用 -o 指定不同的输出目录，并将所有输出移动到您的网页。然后（手动）编写一个包含所有这些链接的整体 index.html。例如
cd .../texinfo/doc gendocs.sh --email [email protected] -o texinfo texinfo "GNU Texinfo manual" gendocs.sh --email [email protected] -o info info "GNU Info manual" gendocs.sh --email [email protected] -o info-stnd info-stnd "GNU info-stnd manual"
默认情况下，脚本使用 makeinfo 生成 HTML 输出。如果您更喜欢使用 texi2html，请使用 --texi2html 命令行选项，例如
gendocs --texi2html -o texinfo texinfo "GNU Texinfo manual"
模板文件将自动生成由 texi2html 生成的其他 HTML 输出的条目（即，按章节和章节分割）。
您可以设置环境变量 MAKEINFO、TEXI2DVI 等来控制要执行的程序，并设置 GENDOCS_TEMPLATE_DIR 来控制查找 gendocs_template 文件的位置。
像往常一样，运行 'gendocs.sh --help' 以获取所有选项、环境变量和更多信息的描述。
请将有关 gendocs 的错误报告、增强请求或其他信件发送至 [email protected]。
由于 www.gnu.org 通过 CVS 工作，因此您的手册中的 CVS 关键字（例如 $Log$）需要特殊处理（即使您碰巧不在 CVS 中维护您的手册）。
如果这些关键字最终以字面字符串的形式出现在生成的输出中，它们将被扩展。处理此问题的最稳健方法是为这些生成的文件关闭关键字扩展。对于现有文件，使用以下命令完成此操作
cvs admin -ko file1 file2 ...
对于新文件
cvs add -ko file1 file2 ...
请参阅 CVS 手册中的“关键字替换”部分，该手册可从 https://cvs.nongnu.org 获取。
在 Texinfo 源代码中，字面指定“美元”关键字的推荐方法是
@w{$}Log$
@w 阻止了 Texinfo 源代码本身的关键字扩展。此外，makeinfo 注意到 @w 并生成避免字面关键字字符串的输出。
GNU 项目对软件自由持坚定立场。很多时候，这意味着您需要避免某些技术，因为使用这些技术会与我们的长期目标相冲突。
软件专利威胁着自由软件的发展和编程自由。美国有如此多的软件专利，以至于任何大型程序都可能实现了数百种专利技术，这些技术是该程序的开发人员所不知道的。试图查找并避免所有这些专利是徒劳和适得其反的。但是，有一些专利我们知道可能会被用来威胁自由软件，因此我们会努力避免使用这些专利技术。如果您担心专利的危险并希望获得建议，请写信至 [email protected]，我们将尽力帮助您从律师那里获得建议。
有时，GNU 项目会坚定地反对某项特定的专利技术，以鼓励社会拒绝该技术。这就是为什么我们放弃 MP3 音频格式而支持未申请专利的 Ogg Vorbis 格式的原因。据报道，这些专利已经过期，但我们仍然更喜欢 Ogg 格式而不是 MP3 格式。请支持这项活动，使 Ogg Vorbis 成为 GNU 软件包及其网站音频分发的首选格式。
我们将在未来某个时候考虑使用 Ogg Opus。分发 Ogg Opus 文件也是可以的，但请继续分发 Ogg Vorbis，以免催促用户更改他们收听音频的软件。
我们找不到真正免受专利保护的现代压缩视频格式，因此我们使用未建立任何许可联盟的 Ogg Theora 和 WebM 格式。GNU 程序及其网站不应以 MPEG-2 或 MPEG 4 格式分发视频。
GNU 软件包不应推荐使用任何非自由程序，也不应需要非自由程序（例如非自由编译器或 IDE）来构建。因此，GNU 软件包不能用没有自由软件实现的编程语言编写。现在 GNU/Linux 系统已广泛可用，所有 GNU 软件包都应在 100% 自由的 GNU/Linux 系统上提供完整功能，并且不应需要任何非自由软件来构建或运行。《GNU 编码标准》对这个问题有更详细的说明。
同样，GNU 软件包不应要求使用非自由软件（包括 JavaScript）来协调其开发。例如，请不要使用 Transifex 来翻译您的软件，因为它要求您的翻译人员使用非自由的、基于 JavaScript 的编辑工具。相反，应使用没有任何道德问题的服务，例如 The Translation Project (https://translationproject.org)。
GNU 软件包不应将用户推荐给任何用于自由软件的非自由文档。自由软件附带自由文档的需求现在是 GNU 项目的一个主要关注点；为了表明我们对自由文档需求的认真态度，我们绝不能通过推荐使用非自由文档来与我们的立场相矛盾。
请不要在需要非自由软件的服务中托管有关您的软件包的讨论。例如，Google+ “社区”需要运行非自由 JavaScript 程序才能发布消息，因此它们不能在自由世界中使用。Google Groups 也存在同样的问题。在那里托管讨论会将那些遵守自由软件原则的人排除在外。
当然，您不能命令人们不要使用此类服务进行相互交谈。您能做的就是不要使它们合法化，并利用您的影响力引导人们远离它们。例如，在您说在哪里进行与该程序相关的讨论时，请不要列出这样的地方。
最后，有关软件自由的伦理问题经常会出现新的问题。我们要求 GNU 维护者，至少在涉及其软件包的特定事项上，在出现此类问题时与 GNU 项目的其余部分保持一致。
在 GNU 中，我们欣赏工作中的幽默。
GNU 是一个黑客项目，而 黑客意味着俏皮的聪明才智。甚至名称“GNU”也是一个俏皮的聪明才智的例子——它是 “GNU's Not Unix”的递归首字母缩写。
本着这种精神，我们珍视 GNU 软件包中偶尔出现的幽默。幽默在 GNU 软件包中不是强制性的；我们不会告诉维护者，“让用户微笑，否则！”但是当维护者这样做时，我们也会微笑。
如今，我们积极的幽默方法偶尔会遇到直接、全面的反对。有些人提倡甚至要求从软件包中删除笑话，仅仅因为它们是笑话。我们对这种观点不屑一顾。
笑话和其它写作一样，也会受到各种问题和批评的影响。有时，对幽默文本的反对是合理的，因此我们不会固执地为每一个笑话辩护到底。但是，仅仅因为它是一个笑话，并不能成为反对的理由。
有些人不喜欢任何略带色情或争议性的东西，包括笑话。如果这种态度盛行，将是极其可悲的，因此我们的政策是偶尔的略带色情的笑话是可以接受的。GNU 是一个 21 世纪的项目，而不是 19 世纪的项目。
GNU 项目支持软件自由的事业，即计算机用户应该控制他们的计算活动。这需要他们控制进行这些活动的软件，而这又需要他们使用自由软件进行这些活动，并有可能用自己的副本替换任何共享的副本。
它还支持计算机中的基本人权，包括互联网的使用；例如，反对审查制度。
一个 GNU 软件包不应严重倡导任何其他政治事业。这并不是说 GNU 项目反对其他那些事业。相反，它对这些事业是中立的，GNU 软件包也应保持中立。例如，如果你（比方说）是一个和平主义者，你不得在你开发的 GNU 软件包中倡导和平主义。反之，如果你想发动战争，你开发的 GNU 软件包也不应该倡导战争。
本章解释了几个术语问题，这些问题对于纠正关于 GNU 的两个广泛且重要的误解至关重要。
| • 自由软件和开源 | ||
| • GNU 和 Linux |
下一节：GNU 和 Linux，上一级：术语 [目录][索引]
“自由软件”和“开源”这两个术语，虽然描述的几乎是同一类软件，但代表的是基于根本不同价值观的观点。自由软件运动是理想主义的，提出了自由、伦理、原则以及什么构成一个美好社会的问题。 “开源”这个术语，于 1998 年首次提出，它与一种刻意回避这些问题的哲学相关联。有关详细解释，请参见 https://gnu.ac.cn/philosophy/open-source-misses-the-point.html。
GNU 项目与自由软件运动保持一致。这并不意味着所有 GNU 的贡献者和维护者都必须同意；你对这些问题的看法取决于你，并且当你代表自己发言时，你有权表达你的观点。
然而，由于“开源”一词获得了更大的宣传，GNU 项目需要克服一种普遍存在的错误印象，即 GNU 现在而且一直以来都是一个“开源”活动。因此，请在 GNU 软件版本、GNU 文档以及你作为 GNU 软件包维护者发布的公告和文章中使用 “自由软件” 一词，而不是 “开源” 或 “FOSS”。 最好也包括上面给出的 URL 的引用，以解释两者之间的差异。
GNU 项目成立的目的是开发一个自由的类 Unix 操作系统 GNU。这个系统的存在是我们最主要的成就。然而，广泛使用的 GNU 系统版本，其中 Linux 被用作内核，通常被简单地称为 “Linux”。结果，大多数用户都不知道 GNU 项目的主要成就——或者更准确地说，他们知道，但没有意识到这是 GNU 项目的成就和存在理由。即使是那些认为自己了解真实历史的人，也常常认为 GNU 的目标是开发 “工具” 或 “实用程序”。
为了纠正这种混乱，我们多年来一直努力区分 Linus Torvalds 编写的内核 Linux 和 GNU 与 Linux 的组合操作系统 GNU/Linux。由此产生的对 GNU 项目已完成工作的认识提高，有助于 GNU 项目的每一项活动招募更多支持和贡献者。
请在 GNU 软件版本、GNU 文档以及你作为 GNU 软件包维护者发布的公告和文章中始终如一地进行这种区分。 如果你想解释术语及其原因，可以参考 URL https://gnu.ac.cn/gnu/linux-and-gnu.html。
为了明确 Linux 是一个内核，而不是一个操作系统，请注意在这些材料中避免使用 “Linux 系统” 一词。 如果你想有机会对内核是 Linux 的系统发表声明，请写成 “内核是 Linux 的系统” 或 “以 Linux 作为内核的系统”。 这明确地对比了系统和内核，将帮助读者理解两者之间的区别。请避免使用 “基于 Linux 的系统” 等简化形式，因为这些形式未能突出内核和系统之间的区别，并可能鼓励读者忽略这种区别。
为了将 GNU 系统本身与 GNU/Linux 进行对比，你可以称之为 “GNU/Hurd” 或 “GNU/Hurd 系统”。 但是，当这种对比不是特别关注的焦点时，请将其仅称为 “GNU” 或 “GNU 系统”。
当提及作为 GNU 内核更高层的服务器集合时，请将其称为 “Hurd” 或 “GNU Hurd”。请注意，这使用空格，而不是斜杠。
有关此点的更多信息，请参见 https://gnu.ac.cn/gnu/gnu-linux-faq.html。
关于你的软件包的访谈和演讲是向公众宣传 GNU 系统和自由软件运动思想的重要渠道。请避免说“开源”，并避免称 GNU 系统为“Linux”，就像你在软件包本身中所做的那样（请参阅术语）。同样，避免宣传非自由程序（请参阅《GNU 编码标准》中的参考文献），就像你在软件包本身中所做的那样。
许多 GNU 用户对 GNU 持有错误的观念。在我们社区之外，大多数人认为它是 Linux。请利用你的机会纠正他们的错误。首先回答以下基本问题：
如果你感到一种社会压力，让你不要说这些话，那么你可能正在接触到一些不希望这些话被说出来的人。这正是我们最需要你支持的时候。
请不要包含任何公司、产品或服务的广告或宣传。即使该产品符合 FSF 认可的标准，在关于 GNU 软件包的演示中进行广告也是不合适的。同样，请不要包含公司标语。仅当主题需要时才提及公司。
一些 GNU 软件包实际上是特定公司的商业活动。在这种情况下，可以在开头说明。否则，请表明这是 GNU 项目的一个项目，并避免暗示它是任何公司的项目。
如果你受雇于一家公司来开发 GNU 软件包，可以谨慎地感谢该公司，但请不要超出此范围。
在你进行演讲或采访之前，请联系 GNU 项目领导层。我们可以就如何处理各种意外情况提供建议。
当你的访谈和演讲录音或文字记录发布时，请告诉我们。然后我们可以进行宣传。
请以对自由软件友好的格式发布它们：不要使用 Doc 或 Docx 格式，不要使用 Flash，不要使用 QuickTime，不要使用 MP3、MPEG2 或 MPEG4。纯文本、HTML 和 PDF 都是不错的选择。
我们建议使用 savannah.gnu.org 作为你的软件包的源代码存储库，但这不是必需的。有关 Savannah 的更多信息，请参阅 旧版本。
我们强烈建议你使用 ftp.gnu.org 作为版本的标准分发站点。这样做可以使开发人员和用户更容易找到最新的 GNU 版本。但是，如果你愿意，可以使用其他服务器，前提是它允许公众不受限制地访问（例如，不排除任何国家/地区）。
如果你使用公司的机器来保存你的程序的存储库，或者作为其版本分发站点，请在该站点的显眼位置放置此声明，以防止人们对软件包与公司之间的关系产生错误的印象
The programs <list of them> hosted here are free software packages of the GNU Project, not products of <company name>. We call them "free software" because you are free to copy and redistribute them, following the rules stated in the license of each package. For more information, see https://gnu.ac.cn/philosophy/free-sw.html. If you are looking for service or support for GNU software, see https://gnu.ac.cn/gethelp/ for suggestions of where to ask. If you would like to contribute to the development of one of these packages, contact the package maintainer or the bug-reporting address of the package (which should be listed in the package itself), or look on www.gnu.org for more information on how to contribute.
作为维护者，你可能希望接受对你工作的捐赠，尤其是在你为自己的任何托管/开发基础设施付费时。以下是一些文本，你可以根据自己的情况进行调整，并在你软件包的网站、README 或你认为有用的任何地方使用
We appreciate contributions of any size -- donations enable us to spend more time working on the project, and help cover our infrastructure expenses. If you'd like to make a small donation, please visit url1 and do it through payment-service. Since our project isn't a tax-exempt organization, we can't offer you a tax deduction, but for all donations over amount1, we'd be happy to recognize your contribution on url2. We are also happy to consider making particular improvements or changes, or giving specific technical assistance, in return for a substantial donation over amount2. If you would like to discuss this possibility, write to us at address. Another possibility is to pay a software maintenance fee. Again, write to us about this at address to discuss how much you want to pay and how much maintenance we can offer in return. If you pay more than amount1, we can give you a document for your records. Thanks for your support!
我们不推荐任何特定的支付服务。但是，GNU 开发人员不应使用需要他们签署专有软件许可的服务，例如 Google 的支付服务。还请避免使用需要用户运行非自由软件才能捐赠的站点。（这包括 JavaScript 软件，因此请使用 LibreJS 或禁用 JavaScript 尝试一下。）
在你网站上发布的文本中，请注意我们关心的术语问题（请参阅术语）。
我们不反对使用比特币来接收捐赠。
FSF 可以为有限数量的项目收集捐款；如果你想为你的项目提出这个建议，请写信给 [email protected]。FSF 需要监督这些资金的支出。
当然，鼓励人们加入 FSF (https://www.fsf.org) 或进行一般捐赠也是一件好事，可以代替或同时进行特定软件包的捐赠。
自由软件目录旨在成为符合特定标准的完整自由软件包列表。每个 GNU 软件包都应该在其中列出，因此请访问 https://gnu.ac.cn/help/directory.html#adding-entries 以获取有关如何为您的软件包编写条目的信息。如有任何关于自由软件目录的问题或建议，请联系 [email protected]。
如果您想在文档中寻找错误，或帮助提高写作质量，或者如果您不是英语母语者并希望获得撰写优秀英文文档的帮助，可以使用 GNU 校对人员邮件列表：[email protected]。
但是在使用列表时要小心，因为列表上有 200 多人。如果您只是要求列表上的每个人阅读您的作品，校对人员可能会付出巨大的重复劳动，并且您可能会收到同一错误的 100 次报告。这必须避免。
此外，列表上的人不希望收到来自它的大量邮件。因此，永远不要要求列表上的人向列表发送邮件！
以下是一些似乎合理的使用方法
请务必指定随机选择程序；否则，人们可能会使用并非真正随机的心理程序，例如“选择中间附近的部分”，并且您将无法获得均匀的覆盖率。
您可以将工作物理地分成 20 个单独的文件，或者描述一个虚拟划分，例如按章节（如果您的工作大约有 20 个章节）。如果您这样做，请务必明确说明 - 例如，您是否希望第一个章节标题之前的材料算作一个章节，或者不算？
下一节: GNU 自由文档许可证, 上一节: 使用校对人员列表, 上级: 顶部 [目录][索引]
如果您愿意，这里有一些您可以在适当情况下使用的回复。
这是一种拒绝安装代码以使您的软件包在专有操作系统 ShackleOS 上工作的方式。
您要求我们在 ShackleOS 上安装对执行 XYZ 的支持。在我们在 GNU 系统上支持 XYZ 之前，我们无法这样做。GNU 项目的政策是在我们为 GNU 系统提供同等支持之前，不为非自由操作系统添加特殊支持。
非自由系统会奴役用户。如果您已经习惯了这种奴役，您可能不会注意到这一点，但我们注意到了。自由软件运动旨在通过用自由软件（例如 GNU 系统）取代非自由系统来解放这些用户。
这个程序的目的不是取代 ShackleOS，但 GNU 系统的目标是。我们必须支持取代 ShackleOS 的努力，而不是削弱它。如果我们为 ShackleOS 实现比 GNU 更多或更好的支持，我们将自食其果。
因此，请使此功能在 GNU 上工作，然后我们可以安装它。
这是一种拒绝安装代码以使您的软件包与专有程序 ShackleMe 一起工作的方式。
您要求我们安装一个专门与 ShackleMe 一起使用的功能，但该程序是非自由的。GNU 项目的政策是在我们支持与同等自由程序进行同等或更好的互操作之前，不添加对与非自由程序互操作的特殊支持。
非自由程序会奴役用户。如果您已经习惯了这种奴役，您可能不会注意到这一点，但我们注意到了。GNU 项目的使命是通过用自由程序替换非自由程序来解放这些用户。
这个程序的目的不是取代 ShackleMe，但其他自由程序会或应该取代。我们必须支持他们取代 ShackleMe 的努力。如果我们与 ShackleMe 的互操作性超过与它们的互操作性，该程序将成为它们成功的额外障碍。我们将自食其果。
因此，请先使此功能与那些自由替代品良好地工作。一旦我们支持它们，我们也可以支持 ShackleMe。
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. https://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
本许可证的目的是使手册、教科书或其他功能性和有用的文档在自由的意义上自由：确保每个人都拥有复制和重新分发它的有效自由，无论是否修改，无论是商业用途还是非商业用途。其次，本许可证为作者和出版商保留了一种为他们的工作获得认可的方式，同时不被认为对他人所做的修改负责。
本许可证是一种“反版权”，这意味着文档的衍生作品本身必须在相同的意义上是自由的。它补充了 GNU 通用公共许可证，该许可证是为自由软件设计的反版权许可证。
我们设计此许可证是为了将其用于自由软件的手册，因为自由软件需要自由文档：自由程序应附带提供与软件相同的自由的手册。但是，此许可证不仅限于软件手册；它可以用于任何文本作品，无论主题或是否以印刷书籍形式出版。我们主要建议将此许可证用于以指导或参考为目的的作品。
本许可证适用于任何手册或其他作品，以任何媒介形式，其中包含版权所有者放置的声明，声明该作品可以根据本许可证的条款分发。此类声明授予全球范围内的、免版税的、无限期的许可，以按照此处规定的条件使用该作品。“文档”（如下所述）是指任何此类手册或作品。任何公众成员都是被许可人，并被称为“您”。如果您以需要版权法许可的方式复制、修改或分发作品，则表示您接受该许可。
文档的“修改版本”是指任何包含文档或其一部分的作品，无论是逐字复制，还是经过修改和/或翻译成其他语言。
“次要部分”是指文档中命名的附录或前言部分，该部分专门处理文档的出版商或作者与文档的总体主题（或相关事项）的关系，并且不包含任何可能直接属于该总体主题的内容。（因此，如果文档部分是数学教科书，则次要部分可能不会解释任何数学。）该关系可能是与主题或相关事项的历史联系，或者是关于它们的法律、商业、哲学、伦理或政治立场。
“不变部分”是某些次要部分，其标题在声明该文档在本许可证下发布的声明中被指定为不变部分的标题。如果某个部分不符合上述次要部分的定义，则不允许将其指定为不变部分。文档可能包含零个不变部分。如果文档未标识任何不变部分，则没有不变部分。
“封面文本”是在声明该文档在本许可证下发布的声明中被列为封面文本或封底文本的某些简短文本段落。封面文本最多可以有 5 个字，封底文本最多可以有 25 个字。
文档的“透明”副本是指机器可读副本，以规范可供公众使用的格式表示，适合使用通用文本编辑器或（对于由像素组成的图像）通用绘图程序或（对于绘图）某些广泛可用的绘图编辑器直接修订文档，并且适合输入文本格式化程序或自动翻译成适合输入文本格式化程序的各种格式。以其他透明文件格式制作的副本，其标记或缺少标记的目的是为了阻碍或阻止读者随后的修改，则不是透明的。如果将图像格式用于任何大量的文本，则该格式不是透明的。不是“透明”的副本称为“不透明”。
适用于透明副本的格式示例包括没有标记的纯 ASCII、Texinfo 输入格式、LaTeX 输入格式、使用公开可用的 DTD 的 SGML 或 XML，以及符合标准的简单 HTML、PostScript 或 PDF（专为人工修改而设计）。透明图像格式的示例包括 PNG、XCF 和 JPG。不透明格式包括只能由专有文字处理器读取和编辑的专有格式、DTD 和/或处理工具不普遍可用的 SGML 或 XML，以及某些文字处理器仅为输出目的而生成的机器生成的 HTML、PostScript 或 PDF。
对于印刷书籍，“标题页”是指标题页本身，以及为了清晰地容纳本许可证要求出现在标题页上的材料所需的后续页面。对于没有标题页的格式的作品，“标题页”是指最突出地出现作品标题的文本附近，位于正文的开头之前。
“出版商”是指向公众分发文档副本的任何个人或实体。
“标题为 XYZ”的部分是指文档的命名子单元，其标题正好是 XYZ，或者在用另一种语言翻译 XYZ 的文本之后的括号中包含 XYZ。（此处，XYZ 代表下面提到的特定节名称，例如“致谢”、“献词”、“推荐”或“历史”。）当您修改文档时，“保留”该部分的“标题”是指根据本定义，它仍然是一个“标题为 XYZ”的部分。
文档可能在声明本许可证适用于文档的声明旁边包含担保免责声明。这些担保免责声明被认为是通过引用包含在本许可证中的，但仅限于免除担保：这些担保免责声明可能具有的任何其他含义均无效，并且对本许可证的含义没有影响。
您可以以任何媒介形式复制和分发文档，无论是商业用途还是非商业用途，前提是本许可证、版权声明和声明本许可证适用于文档的许可证声明在所有副本中均被复制，并且您没有向本许可证的条件添加任何其他条件。您不得使用技术措施来阻碍或控制您制作或分发的副本的阅读或进一步复制。但是，您可以接受报酬以换取副本。如果您分发的副本数量足够多，则还必须遵守第 3 节中的条件。
您也可以在上述相同条件下借出副本，并且您可以公开展示副本。
如果您出版的文档印刷版（或通常带有印刷封面的媒体副本）数量超过 100 份，并且该文档的许可证声明要求有封面文本，则您必须将这些副本装在带有清晰且易于辨认的封面上，这些封面应带有所有封面文本：正面封面文本应位于正面封面上，背面封面文本应位于背面封面上。两个封面还必须清晰且易于辨认地标明您是这些副本的出版者。正面封面必须以同等突出且可见的方式呈现完整的标题及其所有单词。您还可以在封面上添加其他材料。对封面进行更改的复制，只要它们保留文档的标题并满足这些条件，在其他方面可以视为逐字复制。
如果任何一个封面的所需文本过多而无法清晰显示，则应将列出的第一个文本（尽可能多地合理放置）放在实际封面上，并将其余文本继续放在相邻的页面上。
如果您出版或分发的文档不透明副本数量超过 100 份，则必须在每个不透明副本中包含一个机器可读的透明副本，或在每个不透明副本中或随附的说明中声明一个计算机网络位置，公众可通过该位置使用公共标准网络协议下载该文档的完整透明副本，且不包含添加的材料。如果您使用后一种选项，则必须在开始批量分发不透明副本时采取合理谨慎的步骤，以确保该透明副本在该声明的位置保持可访问状态，至少直到您向公众分发（直接或通过您的代理商或零售商）该版本最后一个不透明副本的一年后为止。
建议（但不是必须）您在重新分发大量副本之前与文档的作者联系，让他们有机会为您提供该文档的更新版本。
您可以根据上述第 2 和 3 节的条件复制和分发文档的修改版本，前提是您必须在完全相同的本许可下发布修改版本，并且修改版本承担文档的角色，从而向拥有副本的任何人授予修改版本的发布和修改许可。此外，您必须在修改版本中执行以下操作：
如果修改版本包括符合辅助部分条件的新前言部分或附录，并且不包含从文档中复制的任何材料，您可以选择将这些部分中的部分或全部指定为不变部分。为此，请将它们的标题添加到修改版本的许可声明中的不变部分列表中。这些标题必须与任何其他部分的标题不同。
您可以添加一个标题为“认可”的部分，前提是它仅包含各方对您的修改版本的认可，例如，同行评审的声明或文本已被某个组织批准为标准的权威定义。
您可以在修改版本的封面文本列表末尾添加最多五个单词的一段文字作为正面封面文本，以及最多 25 个单词的一段文字作为背面封面文本。任何一个实体只能添加一段正面封面文本和一段背面封面文本（或通过安排）。如果文档已经包含同一封面的封面文本，该文本之前由您或您代表其行事的同一实体安排添加，则您不能再添加另一个文本；但是，在获得之前添加旧文本的出版商的明确许可后，您可以替换旧文本。
文档的作者和出版商不通过本许可允许使用其名称进行宣传，或声明或暗示认可任何修改版本。
您可以根据上述第 4 节中为修改版本定义的条款，将本许可证下发布的文档与其他文档合并，前提是您在合并版本中包含所有原始文档的所有不变部分，并且将它们全部列为合并版本许可声明中的不变部分，并且您保留其所有免责声明。
合并版本只需要包含本许可的一个副本，并且多个相同的不变部分可以用一个副本替换。如果有多个名称相同但内容不同的不变部分，请通过在其末尾添加原始作者或该部分的出版商（如果已知）的名称，或唯一的数字（在括号内），使每个此类部分的标题都是唯一的。在合并版本的许可声明中对不变部分列表中的节标题进行相同的调整。
在合并版本中，您必须合并各个原始文档中任何标题为“历史记录”的部分，形成一个标题为“历史记录”的部分；同样地，合并任何标题为“致谢”的部分，以及任何标题为“献词”的部分。您必须删除所有标题为“认可”的部分。
您可以创建一个由本文档和本许可下发布的其他文档组成的集合，并将各个文档中的本许可副本替换为该集合中包含的单个副本，前提是您在所有其他方面都遵循本许可中对每个文档进行逐字复制的规则。
您可以从此类集合中提取单个文档，并在本许可下单独分发，前提是您在提取的文档中插入本许可的副本，并在有关该文档的逐字复制的所有其他方面都遵循本许可。
将文档或其衍生作品与存储或分发介质的卷上的其他单独且独立的文档或作品汇编在一起，如果该汇编产生的版权未用于限制汇编用户的合法权利，则该汇编被称为“聚合”，超过了单个作品允许的范围。当文档包含在聚合中时，本许可不适用于聚合中本身不是文档衍生作品的其他作品。
如果第 3 节的封面文本要求适用于这些文档副本，那么如果文档小于整个聚合的一半，则文档的封面文本可以放在聚合内的文档两侧的封面上，或者如果文档采用电子形式，则放在封面的电子等效物上。否则，它们必须出现在括住整个聚合的印刷封面上。
翻译被视为一种修改，因此您可以根据第 4 节的条款分发文档的翻译版本。用翻译替换不变部分需要其版权持有者的特殊许可，但除了这些不变部分的原始版本之外，您还可以包含一些或全部不变部分的翻译。您可以包含本许可的翻译版本，以及文档中的所有许可声明和任何免责声明，前提是您还包含本许可的原始英文版本以及这些声明和免责声明的原始版本。如果本许可的翻译版本与原始版本之间或声明或免责声明之间存在分歧，则以原始版本为准。
如果文档中的某个部分标题为“致谢”、“献词”或“历史记录”，则保留其标题的要求（第 4 节）通常需要更改实际标题。
您不得复制、修改、再许可或分发本文档，除非本许可明确规定。任何其他复制、修改、再许可或分发的尝试均无效，并将自动终止您在本许可下的权利。
但是，如果您停止所有违反本许可的行为，则您从特定版权持有者处获得的许可将被恢复 (a) 临时恢复，除非版权持有者明确且最终终止您的许可，并且 (b) 永久恢复，如果版权持有者在停止违规行为后 60 天之前，未能通过某种合理的方式通知您违规行为。
此外，如果版权持有人通过某种合理方式通知您侵权行为，并且这是您第一次收到该版权持有人关于违反本许可证（针对任何作品）的通知，且您在收到通知后 30 天内纠正了侵权行为，那么您从该版权持有人处获得的许可将永久恢复。
根据本节终止您的权利不会终止根据本许可证从您那里获得副本或权利的各方的许可。 如果您的权利已被终止且未永久恢复，则收到部分或全部相同材料的副本不会赋予您任何使用它的权利。
自由软件基金会可能会不时发布 GNU 自由文档许可证的新修订版本。 这些新版本在精神上与当前版本相似，但在细节上可能会有所不同，以解决新的问题或疑虑。 请参阅 https://gnu.ac.cn/licenses/。
每个版本的许可证都有一个唯一的版本号。 如果文档指定本许可证的特定编号版本“或任何后续版本”适用于它，您可以选择遵循该指定版本或自由软件基金会发布的任何后续版本（而非草案）的条款和条件。 如果文档未指定本许可证的版本号，您可以选择自由软件基金会发布的任何版本（而非草案）。 如果文档指定代理人可以决定可以使用本许可证的哪些未来版本，则该代理人公开声明接受某个版本，即永久授权您为该文档选择该版本。
“大型多人协作站点”（或“MMC 站点”）是指任何发布受版权保护作品，并为任何人编辑这些作品提供突出便利的万维网服务器。 任何人都可以编辑的公共维基就是此类服务器的一个例子。 站点中包含的“大型多人协作”（或“MMC”）是指 MMC 站点上发布的任何一组受版权保护的作品。
“CC-BY-SA”是指知识共享公司发布的知识共享署名-相同方式共享 3.0 许可证，这是一家主要营业地位于加利福尼亚州旧金山的非营利公司，以及该组织发布的该许可证的未来 Copyleft 版本。
“合并”是指将文档的全部或部分作为另一文档的一部分发布或重新发布。
如果 MMC 已获得本许可证许可，并且所有首次在本许可证下发布在 MMC 之外的其他地方，随后全部或部分合并到 MMC 中的作品 (1) 没有封面文本或不变章节，并且 (2) 因此在 2008 年 11 月 1 日之前合并，则该 MMC“有资格获得重新许可”。
如果 MMC 有资格获得重新许可，则 MMC 站点的运营者可以在 2009 年 8 月 1 日之前的任何时间，在同一站点上根据 CC-BY-SA 重新发布站点中包含的 MMC。
要在您编写的文档中使用本许可证，请将本许可证的副本包含在文档中，并在标题页之后添加以下版权和许可声明
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
如果您有不变章节、封面文本和封底文本，请将“with…Texts.”行替换为以下内容
with the Invariant Sections being list their titles, with
the Front-Cover Texts being list, and with the Back-Cover Texts
being list.
如果您有不包含封面文本的不变章节，或者这三者的其他组合，请合并这两个选项以适应实际情况。
如果您的文档包含重要的程序代码示例，我们建议您同时根据您选择的自由软件许可证（例如 GNU 通用公共许可证）发布这些示例，以允许它们在自由软件中使用。
上一篇： GNU 自由文档许可证，上一级： 顶部 [目录][索引]
| 跳转到： | $ / A B C D E F G H I L M O P Q R S T U V W |
|---|
| 跳转到： | $ / A B C D E F G H I L M O P Q R S T U V W |
|---|