本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。
- 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
- 对于 GNU 许可证的一般了解
- 在您的程序中使用 GNU 许可证
- 依据 GNU 许可证分发程序
- 在编写其他程序时采用依据 GNU 许可证发布的程序
- 将作品与依据 GNU 许可证发布的代码相结合
- 关于违反 GNU 许可证的问题
3、在您的程序中使用 GNU 许可证
3.1 如何从 (L)GPLv2 升级到 (L)GPLv3？
首先，在您的软件包中包含新版本的许可证。如果您在项目中使用 LGPL v3，请确保一同包含了 GPL v3 和 LGPL v3 的副本，因为 LGPL v3 现在被写成在 GPL v3 基础上的一系列附加许可。
其次，将所有现有的 v2 许可证 通知 （通常位于每个文件的顶部）替换为“如何使用 GNU 许可证”上新的推荐文本。它更加面向未来，因为它不再包括 FSF 的邮政地址。
当然，任何涉及软件包许可证的描述性的文本（如在 README中）也应该被适当更新。
3.2 您能一步一步地指导我如何将GPL应用到我的程序吗？
请参阅 GPL 说明书页面。
3.3 为什么我要使用 GNU GPL，而不是其他自由软件许可证？（同 1.3）
使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过，在某些特殊情况下，最好使用一个更宽松的许可证。
3.4 为什么 GPL 要求程序的每个副本必须包含 GPL 许可证副本？（同 2.14）
作品包含许可证副本至关重要，因此获得程序副本的每个人都可以知道他们的权利是什么。
包括一个指向许可证的 URL，而不是将许可证本身包含在内，这是一种看起来很诱人的做法。但是您不能确定该 URL 在五年或十年后仍然有效。二十年后，我们今天所知道的 URL 们可能已不复存在。
不管网络将发生什么样的变化，确保拥有该程序副本的人员能够继续看到 GPL 许可证的唯一方法是，将许可证的副本包含在该程序中。
3.5 只需将 GNU GPL 的副本放在我的存储库中就可以了吗？
仅将 GNU GPL 的副本放在存储库中的文件中，并不能明确地声明可以依据 GNU GPL 使用同一存储库中的代码。如果没有这样的声明，并不能完全清楚地表明许可证中的权限真的可以适用于任何特定的源文件。一个明确的声明将消除所有的疑问。
文件仅包含许可证文本，而没有一个声明规定某些其他文件被该许可证覆盖，类似于文件包含一个其他任何地方都不会调用的子例程。但这种相似之处并不完美：律师和法院可能应用常识得出结论，因为您希望以 GPL 方式许可代码，所以您必定要将GNU GPL 的副本放在那里。或许律师和法院不会这样做。但为什么要留下不确定性呢？
每个源文件中都应该包括声明文本。只要能够伴随代码，程序的 README 文件中的清晰声明从法律上来说就足够了，但是它们很容易分离。所以，为什么要给您的代码许可证带来不确定性的风险呢？
这与 GNU GPL 的具体内容无关。对于任何自由许可证来说都是正确的。
3.6 为什么要在每个源文件中放置许可证 通知 ？
您应该在每个源文件的起始处放置通知，说明它所携带的许可证，以避免代码与其许可证被断开的风险。如果您存储库的 README 文件声明源文件遵循 GNU GPL，如果有人将该文件复制到另一个程序，会发生什么呢？ 其他上下文可能无法表明该文件的许可证是什么。它似乎有一些其他许可证，或根本没有许可证（这将使代码变成非自由软件）。
在每个源文件的开始添加版权声明和许可证通知很容易，造成这种混乱的可能性不大。
这与 GNU GPL 的具体内容无关。对于任何自由许可证来说都是正确的。
3.7 如果作品不是很长，那该怎么办？（同 2.15）
如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行，那么您可以使用一个宽松的许可证，而不是像 GNU GPL 这样的左版许可证（除非代码特别重要）。我们建议这种情况使用 Apache 许可证 2.0。
3.8 为了节省空间，我是否可以省略 GPL 的引言部分，或者省略如何在自己的程序上使用 GPL 的 指导 部分吗？（同 2.21）
引言和指导是 GNU GPL 的组成部分，不能省略。事实上，GPL 是受版权保护的，其许可证规定只能逐字复制整个 GPL。（您可以使用法律条款制作另一个许可证，但该许可证不再是 GNU GPL。）
引言和指导部分共约 1000 字，不到 GPL 总文字数量的 1/5。除非软件包本身很小，否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下，您可以使用一个简单的 全权 许可证，而不是 GNU GPL。
3.9 如何获得我的程序的版权，以便依据 GPL 发布？
根据 《伯尔尼公约》 ，所有书写成文的内容都将自动受版权保护。所以你没有必要做任何事情来“获得”你所写代码的版权——只要没有其他人声称拥有你的作品。
不过，在美国注册版权是一个很好的主意。这将给你在美国应对侵权者带来更多的影响力。
其他人可能声称拥有版权的情况是，如果您是雇员或学生；那么雇主或学校可能会声称你为他们做了工作，并且版权属于他们。他们是否存在有效的权利主张将取决于你所居住地方的法律，以及你的雇佣合同和你所做的工作。如果有任何疑问，最好咨询律师。
如果您认为雇主或学校可能会提出权利主张，您可以通过获得公司或学校适当授权的官员签署的版权免责声明来明确解决该问题。（您的直接上司或教授通常无权签署此免责声明。）
3.10 如果我的学校想将我自己的程序应用到学校的专有软件产品，我该怎么办？
现在许多大学试图通过限制他们所开发的知识和信息的使用来筹集资金，其实际上与商业业务有所不同。 （参见刊载于 2000 年 3 月 《大西洋月刊》 的 《受缚的大学》 ，该文章对这个问题及其影响进行了一般性的讨论。）
如果您在某种程度上认为您的学校可能拒绝允许您的程序作为自由软件发布，最好尽早提出这个问题。程序越接近于有用的作品，行政部门越有动机从你手里拿回该程序，并在没有你的情况下完成它。在更早的阶段，你有更多的影响力。
所以我们建议你在程序只进行一半的时候接触他们，说：“如果你同意将它作为自由软件发布，我会完成它。”不要以为这是虚张声势。要取得胜利，你必须有勇气说：“我的程序如果不能成为自由软件，我宁愿不把它写出来。”
3.11 我想发布一个我依据 GNU GPL 编写的程序，但是我想在非自由程序中使用相同的代码。
发布一个非自由程序总是有道德上的污点，但从法律上来说没有任何障碍阻止你这样做。如果您是代码的版权所有者，您可以在不同时间以各种不同的非独占许可证发布。
3.12 依据 GPL 分发的程序的开发人员是否可以将其授权给另一方专用？
不可以，因为公众已经有权利使用遵循 GPL 的该程序，这个权利是不能撤销的。
3.13 美国政府可以依据 GNU GPL 发布一个程序吗？
如果这个程序是由美国联邦政府雇员在雇用过程中编写的，那么它是处于公有领域，这意味着它不受版权保护。由于GNU GPL是基于版权的许可证，所以这样的程序不能依据 GNU GPL 发布。（它仍然可以是自由软件，公有领域的程序是自由软件。）
不过，当美国联邦政府机构使用承包商来开发软件时，那就是不同的情况。合同可以要求承包商依据 GNU GPL 进行发布（GNU Ada 是以这种方式开发的）。或者合同可以将版权 分配 给政府机构，然后政府机构可以依据 GNU GPL 发布该软件。
3.14 美国政府可否对遵循 GPL 的程序进行改进并发布？
可以。如果这些改进是由美国政府雇员在雇佣期间编写的，那么这些改进属于公有领域。不过，GNU GPL 仍然涵盖了整体的改进版本。在这种情况下没有问题。
如果美国政府使用承包商来完成这项工作，那么改进本身可以被 GPL 覆盖。
3.15 程序里为什么要说“GPL 的版本 3 或任何更新的版本”？
随着时间的推移，我们会不断更改 GPL——有时要澄清一下，有时允许以前不允许的某些用途，有时会收紧要求。（最后两次更改是在 2007 年和 1991 年。）当我们更新 GPL 时，在每个程序中使用这个“间接指针”可以让我们有可能针对整个 GNU 软件集合更改分发条款。
如果每个程序缺少间接指针，我们将被迫与许多版权持有者进行长时间的讨论，这在事实上是不可能实现的。在实践中，为 GNU 软件制定统一分发条款的机会将为零。
假设一个程序里说“GPL 的版本 3 或任何更新的版本”，并且一个新版本的 GPL 被发布。如果新的 GPL 版本提供了额外的许可，那么该权限将立即提供给程序的所有用户。但是，如果新的 GPL 版本要求更严格，则不会对使用当前版本的程序形成限制，因为该程序仍然可以依据 GPL 版本 3 进行使用。当程序里说“GPL 的版本 3 或任何更新的版本”，用户将被永远允许使用它，甚至可以依据 GPL 版本 3 的条款进行更改，即使在后续版本的 GPL 可用后也是如此。
如果GPL的新版本中更严格的要求不需要被现有软件遵守，那么它还有用吗？一旦 GPL 版本 4 可用，大多数遵循 GPL 的程序的开发人员将发布其程序的后续版本，阐明其采用“GPL 的版本 4 或任何更新的版本”。那么用户将不得不遵循 GPL 版本 4 中更严格的要求，以便使用程序的后续版本。
然而，开发人员没有义务这样做；如果这是他们的偏好，开发人员可以继续被允许使用以前版本的 GPL。
3.16 使用一个声明某个程序只能依据最新版本的 GNU GPL 进行使用的许可证是个好主意吗？
您不应该这样做，原因是它可能会导致未来某一天自动撤回用户以前拥有的一些权限。
假设一个程序是在 2000 年依据“最新的 GPL 版本”进行发布。当时，人们可以依据 GPL 版本 2 使用它。在 2007 年发布 GPL 版本 3 的那一天，每个人都将被迫不得不依据 GPL 版本 3 使用该程序。
有些用户甚至可能不知道 GPL 版本 3——但是他们将被要求使用它。他们可能会无意中违反该程序的许可证，只因为他们没有得到 GPL 版本 3发布的消息。这不是个对待别人的好方法。
除非因为违规，我们认为收回已经授予的权限是错误的做法。如果您的自由可以被撤销，那么这不是真正的自由。因此，如果您获得遵循某个版本许可证的某个版本程序的副本，则应始终具有该版本许可证授予的权限。依据“GPL 的版本 N 或任何更新的版本”进行发布维护了该原则。
3.17 有没有一些方法可以让使用我的程序的人们得到的输出物遵循 GPL？例如，如果我的程序用于开发硬件设计，我可以要求这些设计必须是自由的吗？
一般来说，这在法律上是不可能的；针对人们通过使用您的程序获取数据形成的输出物如何使用，版权法并没有赋予您任何发言权。如果用户使用您的程序输入或转换自己的数据，输出物的版权属于他，而不是您。更一般来说，当程序将其输入物转换成其他形式时，输出物的版权状态将继承其得以生成的输入物的版权状态。
所以您对输出物的使用拥有发言权的唯一方式是输出物的实质部分（或多或少）是从您程序的文本中复制出来。例如，如果我们在这种具体情况下没有例外，那么Bison的一部分输出物（参见问题 5.2）将被 GNU GPL 所涵盖。
所以，即使没有技术原因，您也可以人为制作一个程序，将某些文本复制到其输出物中。但是，如果复制的文本没有实际用途，用户可以简单地从输出物中删除该文本，并且仅使用其余的内容。那么他就不必满足重新分发所复制文本的条件。
3.18 手册为什么不使用 GPL 许可证？（同 1.7）
手册也可以使用 GPL 许可证，但对于手册来说，最好使用 GFDL（自由文本授权，GNU Free Documentation License）许可证。
GPL 是为软件程序设计的，它包含许多复杂的条款，对于程序来说至关重要；但对于图书或手册来说，这将是麻烦和不必要的。例如，任何人如果（以 GPL）出版纸质图书，就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”，或提供书面文件，表明将稍后发送“源代码”。
同时，GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款，例如，出售封面文字。 背书 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的，但该修改版本不能被标记为“该标准”。
使用 GFDL，我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要，因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由，它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” ，使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。
3.19 GPL 如何适用于字体？
字体许可是一个复杂的问题，需要认真考虑。以下许可证例外是试验性的，但被批准用于一般用途。我们欢迎关于这个问题的建议——请参阅这个解释性文章，并写邮件到 [email protected] 。
要使用此例外，请将该文本添加到软件包中的每个文件的许可证通知中（尽可能），在文本末尾说明该文件依据 GNU GPL 分发：
作为一个特殊的例外，如果您创建一个使用此字体的文档，并将该字体或该字体未更改的部分嵌入到文档中，则此字体本身不会导致生成的文档被 GNU 通用公共许可证 覆盖。然而，这个例外不会使文档可能被 GNU 通用公共许可证涵盖的任何其他原因无效。如果您修改此字体，您可以将此例外扩展到您的字体版本，但是您没有义务这样做。如果您不想这样做，请从您的版本中删除此例外声明。
3.20 我正在编写一个网站维护系统（有人称之为“内容管理系统”）或者是其他一些从模板生成网页的应用程序。我应该为这些模板使用什么许可证？
模板很小，不值得使用 左版 来保护它们。在小作品上使用左版通常是无害的，但模板是一种特殊情况，因为它们与应用程序用户提供的数据结合使用，并且其组合被分发。因此，我们建议您以简单的许可条款许可您的模板。
一些模板调用 JavaScript 函数。由于 JavaScript 通常是不一般的作品，因此它值得用左版保护。由于模板与用户数据相结合，因此模板 + 用户数据 + JavaScript 可能被版权法看作是一个作品。需要在 JavaScript（受左版保护）和用户代码（通常遵循不兼容的条款）之间划清界限。
以下是执行此操作的 JavaScript 代码的一种例外：
作为 GPL 的一个特殊例外，仅对此代码进行函数调用并且为此目的通过引用将其包括在内的 HTML 文件，将被视为版权法意义下的单独作品。此外，此代码的版权所有者可以让您将该代码与依据 GNU LGPL 发布的自由软件库相结合。您可以按照此代码所遵循的 GNU GPL 条款以及此库所遵循的 LGPL 条款复制和分发这样一个系统。如果您修改此代码，则可以将此例外扩展到您的代码版本，但是您没有义务这样做。如果您不想这样做，请从您的版本中删除此例外声明。
3.21 我可以发布一个使用非自由工具开发的遵循 GPL 的程序吗？
您使用什么程序来编辑、编译、研究、记录源代码，通常对于该源代码的许可问题没有任何影响。
但是，如果将非自由库与源代码链接，那么它就是一个您需要进行处理的问题。它不阻碍依据GPL发布源代码，但是如果这些库不符合 “系统库” 例外情况，那么您应该附加一个明确的通知，允许您的程序与它们进行链接。有关使用 GPL 不兼容库的 FAQ 条目提供了如何执行此操作的更多信息。
3.22 我使用公钥加密来对我的代码进行签名，以确保其真实性。GPL v3 是否强制要求我发布我的私人签名密钥？
否。只有在您将遵循 GPL 的软件传递给用户产品之中，您才需要发布签名密钥，并且其硬件会在功能启动之前检查该软件来获得有效的密码签名。在这种具体情况下，您将被要求提供密钥给任何拥有该设备的人员，使其按照要求在设备上签名并安装修改后的软件，以便其运行。如果具体每个设备使用不同的密钥，那么您只需要为每个购买者提供相应的密钥。
3.23 GPL v3 是否要求投票人能够修改在投票机中运行的软件？（同 2.41）
不要求。企业分发包含遵循 GPL v3 软件的设备，最多只需要为拥有目标代码副本的人提供软件的源代码和安装信息。使用投票机（如同任何其他信息亭一样）的选民不能拥有它，甚至不能暂时拥有，所以选民也不能拥有二进制软件。
不过，请注意，投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由软件，并不意味着您可以信任计算机，并进行投票。我们认为电脑不值得信任，不能被用作投票。投票应在纸上进行。
3.24 GPL v3 中的担保和免责声明似乎是依据美国法律的。我可以将自己的免责声明添加到我自己的代码中吗？
可以。GPL v3 第 7 节允许您添加自己的免责声明，具体来说是 7（a）。
3.25 我的程序具有非视觉性的交互式用户界面。如何遵守 GPL v3 中的 适当法律声明 要求？
所有您需要做的是确保适当法律声明对于您界面中的用户来说唾手可得。例如，如果您已经编写了一个音频接口，您可以包括一个大声朗读该声明的命令。
