如果您维护一个 FSF 版权的软件包，当合并其他人编写的具有法律意义的变更时，需要遵循某些法律程序。这可以确保 FSF 拥有发布该软件包的合法权利，并在必要时在法庭上捍卫其 GPL 覆盖状态的立场。
GNU 软件包不一定要拥有 FSF 版权；这取决于作者，通常是在软件包被命名为 GNU 时决定。当版权转让给 FSF 时，FSF 有权采取行动阻止有关该软件包的 GPL 违规行为（否则，法律行动将由作者负责）。它还允许我们在必要时授予软件包额外的权限，例如例外情况。此外，拥有版权使我们能够升级软件包的许可证，即使它最初是在 “仅限 GPLv2” 下发布的（而不是 FSF 建议的 “或更高版本” 许可选项）。本节的其余部分讨论的是软件包拥有 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）。
您可以为在软件包工作上为您提供重要帮助的人员申请帐户；在有充分理由的特殊情况下，我们会这样做。
为了让贡献者知道应该签署文件，您需要要求他们提供必要的文件。如果您不太了解他们，并且您不知道他们是否习惯我们处理版权文件的方式，那么最好通过类似这样的消息来提出这个问题
您是否愿意将版权转让给自由软件基金会，以便我们可以将其安装在 软件包 中？
或者
您是否愿意签署一份版权免责声明，将此变更放入公共领域，以便我们可以将其安装在 软件包 中？
如果贡献者随后想要更多信息，您可以发送给他们文件 /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] 交谈，我们将与律师合作决定该怎么做。