Fsf 发布的文章

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据GNU许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

7 关于违反 GNU 许可证的问题

7.1 如果发现了可能违反 GPL 许可证的行为，我该怎么办？

您应该进行报告。 首先，尽可能检查事实。然后告诉发行者或版权所有者涉及的具体 GPL 程序。如果是自由软件基金会，请写信给 mailto:[email protected]。此外，程序的维护者可能是版权所有者，他可能会告诉您如何联系版权所有者，因此将其报告给维护者。

7.2 谁有权力执行 GPL 许可证？（同 1.10）

由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循 GPL 的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”。

7.3 我听说有人依据另一个许可证获得了 GPL 程序的副本。这可能吗？

GNU GPL 不允许用户将其他许可证附加到程序。但是，程序的版权持有人可以依据几个不同的许可证并行发布。其中一个可能是 GNU GPL。

对于您的副本中的许可证来说，假设由版权所有者放置，并且您合法地获得该副本，则是适用于您的副本的许可证。

7.4 遵循 GPL 的程序的开发者是否受 GPL 的约束？开发者的行为是否会违反 GPL？

严格来说，GPL 是开发者授予其他人使用、分发和更改程序的许可。开发者本身并不受其约束，所以无论开发者做什么，都不是 GPL 的“违规”。

但是，如果开发者做某些违反 GPL 的行为，那么开发者一定会失去在社区的道德地位。

7.5 我刚刚发现一家公司有一份 GPL 程序的副本，获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗？（同 4.12）

不会，GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且（一个特殊情况之外），即使有人决定再分发该程序，GPL 也不会要求他必须特意向您或其他人分发副本。

GPL 要求的是，如果他愿意，他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人，如果某人认为合适，那么该人可以将程序再分发给您或任何其他人。

7.6 我可以在如果客户不继续支付订阅费用就停止运行的设备上使用遵循 GPL 的软件吗？

不可以。在这种情况下，继续支付费用的要求限制了用户运行程序的能力。 这是在 GPL 之上的额外要求，GPL 禁止这种行为。

7.7 “纠正” （ cure ） 违反 GPL v3 的行为意味着什么？

纠正违规行为意味着调整您的做法以符合许可证的要求。

7.8 如果有人在笔记本电脑上安装遵循 GPL 的软件，然后将笔记本电脑借给朋友，而不提供软件的源代码，他们是否违反了 GPL？

在我们调查这个问题的司法管辖区，这种借用不会被算作、 传递 （ convey ） 。笔记本电脑的所有者不会依据 GPL 承担任何义务。

7.9 假设两家公司试图通过让一家公司发布已签约的软件，另一家公司发布仅运行第一家公司签约软件的用户产品，以此来规避提供安装信息的要求。这是否违反了 GPL v3？

是的。如果双方通过一起工作来逃避 GPL 的要求，就可以追究它们的侵权行为。这是特别真实的情形，因为 传递 （ convey ） 的定义明确地包括会使某人对二次侵权负责的活动。

译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据GNU许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

6 将作品与依据 GNU 许可证发布的代码相结合

6.1 GPL v3 是否与 GPL v2 兼容？

不兼容。许多要求已经从 GPL v2 变为 GPL v3，这意味 GPL v2 中的精确要求并不体现在 GPL v3 中，反之亦然。例如，GPL v3 的终止条件比 GPL v2 的终止条件更为宽泛，因此与 GPL v2 的终止条件不同。

由于这些差异，两个许可证不兼容：如果您试图将依据 GPL v2 发布的代码与依据 GPL v3 发布的代码组合，则将违反 GPL v2 的第 6 部分。

但是，如果代码依据 GPL “v2 或更高版本”发布，则与 GPL v3 兼容，因为 GPL v3 是其允许的选项之一。

6.2 GPL v2 是否有提供安装信息的要求？

GPL v3 明确要求再分发中包含完整的必要的“安装信息”。GPL v2 不使用该术语，但它需要再分发中包含用于控制可编译和安装可执行文件的脚本以及完整和相应的源代码。这涵盖了 GPL v3 中称为“安装信息”的部分内容，但不包括所有内容。因此，GPL v3 对安装信息的要求较强。

6.3 各种 GNU 许可证之间如何相互兼容？

各种 GNU 许可证彼此之间具有广泛的兼容性。下面是唯一的一种您不能将遵循两种 GNU 许可证的代码结合起来的情况：将遵循旧版本许可证的代码与遵循该许可证新版本的代码进行结合。

以下是 GNU 许可证的各种结合的详细兼容性矩阵，以便为特定情况提供易于使用的参考。它假设有人依据其中一个许可证编写了一些软件，而您希望以某种方式将该软件的代码结合到您要发布的项目（您自己的原始作品或其他人的软件的修改版本）中。在表顶部的列中找到项目的许可证，并在左侧的一行中找到其他代码的许可证。它们交叉的单元格会告诉您这种结合是否被允许。

当我们说“复制代码”时，我们的意思就是：您正在从一个源代码中获取一段代码（无论是否修改），并将其插入到自己的程序中，从而基于第一部分代码形成一个作品。当您编译或运行代码时，“使用库”意味着您不直接复制任何源代码，而是通过链接、导入或其他典型机制将源代码绑定在一起。

矩阵中每个标明 GPL v3 的地方，其关于兼容性的声明也同样适用于 AGPL v3。

兼容性矩阵

我希望依据以下许可证许可我的代码
仅 GPL v2GPL v2 或更高版本GPL v3 或更高版本仅 LGPL v2.1LGPL v2.1 或更高版本LGPL v3 或更高版本
我希望复制遵循右侧许可证的代码：仅 GPL v2可以可以 【2】不可以可以，结合作品只能遵循GPL v2 【7】可以，结合作品只能遵循GPL v2 【7】【2】不可以
GPL v2 或更高版本可以 【1】可以可以可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v3 【8】
GPL v3不可以可以，结合作品需遵循GPL v3 【3】可以可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【8】
仅 LGPL v2.1可以，需依据GPL v2传递复制后代码 【7】可以，需依据GPL v2或更高版本传递复制后代码 【7】可以，需依据GPL v3传递复制后代码 【7】可以可以 【6】可以，需依据GPL v3传递复制后代码 【7】【8】
LGPL v2.1 或更高版本可以，需依据GPL v2传递复制后代码 【7】【1】可以，需依据GPL v2或更高版本传递复制后代码 【7】可以，需依据GPL v3传递复制后代码 【7】可以 【5】可以可以
LGPL v3不可以可以，结合作品需遵循GPL v3 【8】【3】可以，结合作品需遵循GPL v3 【8】可以，结合作品需遵循GPL v3 【7】【8】可以，结合作品需遵循LGPL v3 【4】可以
我希望使用遵循右侧许可证的库：仅 GPL v2可以可以 【2】不可以可以，结合作品只能遵循GPL v2 【7】可以，结合作品只能遵循GPL v2 【7】【2】不可以
GPL v2 或更高版本可以 【1】可以可以可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v2或更高版本 【7】可以，结合作品需遵循GPL v3 【8】
GPL v3不可以可以，结合作品需遵循GPL v3 【3】可以可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【7】可以，结合作品需遵循GPL v3 【8】
仅LGPL v2.1可以可以可以可以可以可以
LGPL v2.1 或更高版本可以可以可以可以可以可以
LGPL v3不可以可以，结合作品需遵循GPL v3 【9】可以可以可以可以

角注：

  1. 在这种情况下，当结合代码时，您必须遵守 GPL v2 的条款。您不能适用更高版本的条款。
  2. 在这种情况下，您可以依据 GPL v2 或更高版本发布您的项目（您的原始作品和/或您收到并修改的作品），请注意，您使用的其他代码仍然只能遵循 GPL v2。只要您的项目依赖于该代码，您将无法将项目的许可证升级到 GPL v3 或更高版本，整个作品（您的项目和其他代码的任意结合）只能依据 GPL v2 的条款传递。
  3. 如果您有能力依据 GPL v2 或任何更高版本发布项目，您可以选择依据 GPL v3 或更高版本发布该项目，一旦您执行此操作，您就可以结合依据 GPL v3 发布的代码。
  4. 如果您有能力依据 LGPL v2.1 或任何更高版本发布项目，您可以选择依据 LGPL v3 或更高版本发布该项目，一旦您这样做，您就可以结合依据 LGPL v3 发布的代码。
  5. 在这种情况下结合代码时，您必须遵守 LGPL v2.1 的条款。您不能适用更高版本 LGPL 中的条款。
  6. 如果这样做，只要项目包含仅依据 LGPL v2.1 发布的代码，您将无法将项目的许可证升级到 LGPL v3 或更高版本。
  7. LGPL v2.1 允许您将遵循自 GPL v2 之后任何版本 GPL 的代码进行重新许可。如果在这种情况下可以将遵循 LGPL 的代码切换为使用适当版本的 GPL（如表所示），则可以进行此种结合。
  8. LGPL v3 是 GPL v3 加上在这种情况下可以忽略的额外权限。
  9. 由于 GPL v2 不允许与 LGPL v3 结合，因此在这种情况下，您必须依据 GPL v3 的条款传递项目，因为它允许此种结合。

6.4 “聚合” （ aggregate ） 与其他类型的“修改版本”有什么区别？（同 2.25）

“聚合”由多个单独的程序组成，分布在同一个 CD-ROM 或其他媒介中。GPL 允许您创建和分发聚合，即使其他软件的许可证不是自由许可证或与 GPL 不兼容。唯一的条件是，发布“聚合”所使用的许可证不能禁止用户去行使“聚合”中每个程序对应的许可证所赋予用户的权利。

两个单独的程序还是一个程序有两个部分，区分的界限在哪里？这是一个法律问题，最终由法官决定。我们认为，适当的判断标准取决于通信机制（exec、管道、rpc、共享地址空间内的函数调用等）和通信的语义（哪些信息被互换）。

如果模块们被包含在相同的可执行文件中，则它们肯定是被组合在一个程序中。如果模块们被设计为在共享地址空间中链接在一起运行，那么几乎肯定意味着它们组合成为一个程序。

相比之下，管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。所以当它们用于通信时，模块们通常是单独的程序。但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以视为这两个部分合并成了一个更大的程序。

6.5 我在使用 GPL 程序的源代码时是否具有 “合理使用” （ fair use ） 权限？（同 4.17）

是的，您有。“合理使用”是在没有任何特别许可的情况下允许的使用。由于您不需要开发人员的许可来进行这种使用，无论开发人员在许可证或其他地方对此怎么说，您都可以执行此操作，无论该许可证是 GNU GPL 还是其他自由软件许可证。

但是，请注意，没有全世界范围普适的合理使用原则；什么样的用途被认为“合理”因国而异。

6.6 美国政府可否对遵循 GPL 的程序进行改进并发布？（同 3.14）

可以。如果这些改进是由美国政府雇员在雇佣期间编写的，那么这些改进属于公有领域。不过，GNU GPL 仍然涵盖了整体的改进版本。在这种情况下没有问题。

如果美国政府使用承包商来完成这项工作，那么改进本身可以被 GPL 覆盖。

6.7 GPL 对于与其所覆盖的作品进行静态或动态链接的模块有不同的要求吗？

没有。将 GPL 覆盖的作品静态或动态地链接到其他模块是基于 GPL 覆盖的作品构建结合作品。因此，GNU GPL 的条款和条件将覆盖整个结合作品。另请参阅：6.24 如果我在 GPL 软件中使用了与 GPL 不兼容的库，会出现什么法律问题？

6.8 LGPL 对于与其所覆盖的作品进行静态或动态链接的模块有不同的要求吗？

为了遵守 LGPL（任何现有版本：v2、v2.1 或 v3）：

（1）如果您静态链接到 LGPL 库，您还必须以对象（不一定是源代码）格式提供应用程序，以便用户有机会修改库并重新链接应用程序。

（2）如果您动态链接已经存在于用户计算机上的 LGPL 库，则不需要传递库的源代码。另一方面，如果您自己将可执行的 LGPL 库与您的应用程序一起传递，无论是静态还是动态链接，还必须以 LGPL 所提供的方式之一来传递库的源代码。

6.9 如果库依据 GPL（而不是 LGPL）发布，这是否意味着使用它的任何软件必须遵循 GPL 或与 GPL 兼容的许可证？

是的，因为程序实际上与库进行了链接。因此，GPL 的条款适用于整个结合作品。与库链接的软件模块可能遵循与GPL兼容的不同许可证，但整体作品必须遵循 GPL。另见：“2.23 许可证与 GPL 兼容是什么意思？”

6.10 您有一个遵循 GPL 的程序，我想将它与我的代码进行链接，来构建一个专有程序。那么事实上，我链接到您的程序意味着我必须让我的程序遵循 GPL 许可证？

不完全是。这意味着您必须依据与 GPL 兼容的许可证（更准确地说，与您链接的结合作品中所有其他代码所适用的一个或多个 GPL 版本相兼容）发布您的程序。然后，结合作品本身就可以遵循这些 GPL 版本。

6.11 如果是这样的话，有没有机会依据 LGPL 获得您的程序许可？

您可以这么要求，但绝大多数的作者都会坚定不移地说不。GPL 的想法是，如果要将我们的代码包含在程序中，您的程序也必须是自由软件。GPL 的意图是给您施加压力，让您以能够使其成为我们社区一部分的方式来发布您的程序。

您始终拥有不使用我们代码的合法选择。

6.12 我们构建专有软件的项目不能使用遵循 GPL 的某个 GNU 程序。您会为我们提供例外吗？ 这将意味着该程序拥有更多用户。

对不起，我们没有这样的例外。这样做是不对的。

最大化用户数量不是我们的目标。相反，我们正在努力为尽可能多的用户提供至关重要的自由。一般来说，专有软件项目是阻碍而不是实现软件自由的原因。

我们偶尔提供许可证例外来协助一个依据 GPL 以外的许可证生产自由软件的项目。不过，我们必须看到一个很好的理由，即这个项目为什么会推动自由软件的发展。

我们有时也会改变软件包的分发条款，这显然是为自由软件事业服务的正确方法；但是我们对此非常谨慎，所以您必须向我们展示非常有说服力的理由。

6.13 如果一个编程语言解释器是依据 GPL 发布的，这是否意味着由它解释的程序必须遵循与 GPL 兼容的许可证？

当解释器只是解释一种语言时，答案是否定的。被解释程序对于解释器来说只是数据；根据版权法，像GPL这样的自由软件许可证不能限制您使用解释器的数据。您可以使用任何数据（被解释程序），以任何您喜欢的方式运行它，并且没有任何要求规定您必须将数据授权给任何人。

然而，当解释器被扩展以向 其他程序 （ facilities ） （通常但不一定是库）提供 “绑定” （ bindings ） 时，被解释程序通过这些绑定有效地与其使用的程序相关联。因此，如果这些程序是依据 GPL 发布的，则使用它们的被解释程序必须以与 GPL 兼容的方式发布。JNI（Java Native Interface）是这种绑定机制的一个例子；以这种方式访问​​的库与调用它们的 Java 程序动态链接。这些库也与解释器联系在一起。如果解释器与这些库静态链接，或者如果它被设计为与这些特定库动态链接，那么也需要以与 GPL 兼容的方式发布。

另一个类似且非常常见的情况是为库提供解释器，它们能够自我解释。例如，Perl 带有许多 Perl 模块，Java 实现带有许多 Java 类。这些库和调用它们的程序总是动态链接在一起。

结果是，如果您选择在程序中使用遵循 GPL 的 Perl 模块或 Java 类，则必须以与 GPL 兼容的方式发布该程序，无论结合后的 Perl 或 Java 程序所依之运行的 Perl 或 Java 解释器中使用什么样的许可证。

6.14 如果编程语言解释器遵循与 GPL 不兼容的许可证，我可以在其上运行遵循 GPL 的程序吗？

当解释器解释一种语言时，答案是肯定的。被解释程序对于解释器来说只是数据；GPL 不会限制您处理程序时所使用的工具。

然而，当解释器被扩展以向 其他程序 （ facilities ） （通常但不一定是库）提供“绑定”时，被解释程序通过这些绑定有效地与其使用的程序相关联。JNI（Java Native Interface）是此种程序的一个例子；以这种方式访问​​的库与调用它们的 Java 程序动态链接。

因此，如果这些程序是依据与 GPL 不兼容的许可证发布的，则情况就像以任何其他方式跟与 GPL 不兼容的库链接。这意味着：

  1. 如果您正在编写代码并将其依据 GPL 发布，您可以声明一个 明确例外 （ explicit exception ） ，允许将其链接到与 GPL 不兼容的程序。
  2. 如果您依据 GPL 编写并发布程序，并且专门设计了与这些程序配合使用的功能，人们可以将其作为 隐性例外 （ implicit exception ） ，允许它们与这些程序进行链接。但是，如果这只是你的打算的话，最好明确地这么说。

您不能把别人遵循 GPL 的代码用于这种方式，或者添加这样的例外。只有该代码的版权所有者才能添加例外。

6.15 如果我将一个模块添加到遵循 GPL 的程序中，我必须使用 GPL 作为我的模块的许可证吗？

GPL 规定，整个结合后的程序必须依据 GPL 发布。所以你的模块必须可以依据 GPL 进行使用。

但是，您可以提供使用您代码的额外授权。如果您愿意，您可以依据比 GPL 更为宽松但与 GPL 兼容的许可证发布模块。许可证列表页面提供了与 GPL 兼容许可证的部分列表。

6.16 什么时候程序和插件会被认为是单一的结合程序？

这取决于主程序如何调用其插件。如果主程序使用 fork 和 exec 来调用插件，并通过共享复杂的数据结构或来回传送复杂的数据结构来建立 密切通信 （ intimate communication ） ，可以使它们成为一个单一的结合程序。如果主程序使用简单的 fork 和 exec 来调用插件并且不建立它们之间的密切通信，插件被认为是一个单独的程序。

如果主程序动态地链接插件，并且它们彼此进行函数调用并共享数据结构，我们相信它们形成了一个单一的结合程序，它必须被视为主程序和插件的扩展。如果主程序动态地链接插件，但是它们之间的通信仅限于使用某些选项调用插件的“main”功能，并等待它返回，这是一种 临界案例 （ borderline case ） 。

使用共享内存与复杂数据结构进行通信几乎等同于动态链接。

6.17 如果我写了一个用于遵循 GPL 程序的插件，那么对可用于分发我的插件的许可证有什么要求？

请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序 ？”以确定插件和主程序是否被视为单个结合程序，以及何时将其视为单独的作品。

如果主程序和插件是单个结合程序，则这意味着您必须依据 GPL 或与 GPL 兼容的自由软件许可证授权插件，并以符合 GPL 的方式将源代码进行分发。与其插件分开的主程序对插件没有要求。

6.18 在为非自由程序编写插件时，可以应用 GPL 许可证吗？

请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序？”以确定插件和主程序是否被视为单个结合程序，以及何时被视为单独的程序。

如果它们组成单一的结合程序，这意味着遵循 GPL 的插件与非自由主程序的结合将违反 GPL。但是，您可以通过向插件的许可证添加例外声明来解决该法律问题，并允许将其与非自由主程序链接。

另请参阅正在编写的使用非自由库的自由软件的问题。

6.19 我可以发布一个旨在加载遵循 GPL 的插件的非自由程序吗？

请参阅 “6.16 什么时候程序和插件会被认为是单一的结合程序？”以确定插件和主程序是否被视为单个结合程序，以及何时被视为单独的程序。

如果它们组成单一的结合程序，则主程序必须依据 GPL 或与 GPL 兼容的自由软件许可证发布，并且当主程序为了与这些插件一起使用而被分发时，必须遵循 GPL 的条款。

然而，如果它们是单独的作品，则插件的许可证对主程序没有要求。

另请参阅正在编写的使用非自由库的自由软件的问题。

6.20 我想将遵循 GPL 的软件纳入我的专有系统。我只依据 GPL 给予我的权限来使用该软件。我可以这样做吗？（同 5.6）

您不能将遵循 GPL 的软件纳入专有系统。GPL 的目标是授予每个人复制、再分发、理解和修改程序的自由。如果您可以将遵循 GPL 的软件整合到非自由系统中，则可能会使遵循 GPL 的软件不再是自由软件。

包含遵循 GPL 程序的系统是该 GPL 程序的扩展版本。GPL 规定，如果它最终发布的话，任何扩展版本的程序必须依据 GPL 发布。这有两个原因：确保获得软件的用户获得自己应该拥有的自由，并鼓励人们回馈他们所做的改进。

但是，在许多情况下，您可以将遵循 GPL 的软件与专有系统一起分发。要有效地做到这一点，您必须确保自由和非自由程序之间的通信 保持一定距离 （ arms length ） ，而不是将它们有效地结合成一个程序。

这种情况与“纳入”遵循 GPL 的软件之间的区别，是一部分实质和一部分形式的问题。实质上是这样的：如果两个程序结合起来，使它们成为一个程序的两个部分，那么您不能将它们视为两个单独的程序。所以整个作品必须遵循 GPL。

如果这两个程序保持良好的分离，就像编译器和内核，或者像编辑器和shell一样，那么您可以将它们视为两个单独的程序，但是您必须恰当执行。这个问题只是一个形式问题：您如何描述您在做什么。为什么我们关心这个？因为我们想确保用户清楚地了解软件集合中遵循 GPL 的软件的自由状态。

如果人们分发遵循 GPL 的软件，将其称为系统（用户已知其中一部分为专有软件）的“一部分”，用户可能不确定其对遵循GPL的软件所拥有的权利。但是如果他们知道他们收到的是一个自由程序加上另外一个程序，那么他们的权利就会很清楚。

6.21 我想将遵循 GPL 的软件纳入我的专有系统。我是否可以通过在 GPL 覆盖的部分和专有部分之间，放置一个遵循与 GPL 兼容的宽松许可证（如 X11 许可证）的 “封装” （ wrapper ） 模块来实现？

不可以，X11 许可证与 GPL 兼容，因此您可以向遵循 GPL 的程序添加一个模块，并让其遵循 X11 许可证。但是，如果要将它们整合到一个更大的程序中，那么这个整体将包含 GPL 覆盖的部分，所以它必须在 GNU GPL 下作为一个整体获得许可。

专有模块 A 仅通过遵循 X11 许可证的模块 B 与遵循 GPL 的模块 C 通信，该事实在法律上是无关紧要的；重要的是模块 C 包含在整体作品中。

6.22 我可以编写使用非自由库的自由软件吗？

如果您这样做，您的程序将无法在一个自由的环境中完全使用。如果您的程序依赖于一个非自由库来做某件工作，那么在自由软件世界里就不能做这个工作。如果这依赖于一个非自由库来运行，它不能是自由操作系统（例如 GNU）的一部分；这完全成为了自由软件世界里的禁区。

所以请考虑：你可以找到一种方法来完成这项工作，而不使用这个库吗？你可以为该库编写一个自由软件替代选择吗？

如果程序已经使用非自由库编写，那么改变决定也许已经太晚了。您也可以按照目前状态来发布程序，而不是不发布。但是请在 README 文件中提到，对非自由库的需求是一个缺点，并建议更改程序以便在没有非自由库的情况下执行相同的工作。请建议任何想要在程序上进行大量进一步工作的人首先将其从依赖非自由库中解脱出来。

请注意，将某些非自由库与遵循 GPL 的自由软件相结合也可能存在法律问题。有关更多信息，请参阅有关 GPL 软件与和其不兼容库的问题。

6.23 我可以将遵循 GPL 的程序与专有系统库链接吗？

每个版本的 GPL 相对于其 左版 （ copyleft ） 都有一个例外，通常称为系统库例外。如果您要使用的与 GPL 不兼容的库符合系统库的标准，则使用它们不需要做特别的工作；分发整个程序的源代码的要求不包括那些库，即使您分发包含它们的链接可执行文件。

作为 “系统库” （ system library ） 的标准在不同版本的 GPL 之间有所不同。GPL v3 在第 1 节中明确定义“系统库”，将其从 “相应源代码” （ Corresponding Source ） 的定义中排除。GPL v2 在第 3 部分的末尾进行，处理这个问题略有不同。

6.24 如果我在遵循 GPL 的软件中使用了与 GPL 不兼容的库，会出现什么法律问题？

如果您希望程序与未被系统库例外所涵盖的库链接，则需要提供许可来执行此操作。以下是您可以使用的两个许可证通知示例；一个用于 GPL v3，另一个用于 GPL v2。在这两种情况下，您应该将此文本放在您授予此权限的每个文件中。

只有该程序的版权持有人才能合法地按照这些条款发布其软件。如果您自己编写了整个程序，假设您的雇主或学校没有声明版权，您就是版权所有者，因此您可以授权该例外。但是，如果您想在代码中使用其他作者的其他遵循GPL的程序的一部分，那么您无法将例外授权给他们。您必须获得这些程序的版权所有者的批准。

当其他人修改程序时，他们不需要为他们的代码设置同样的例外——是否这样做是他们自己的选择。

如果您打算链接的库不是自由软件，请参阅使用非自由库编写自由软件部分。

如果您使用 GPL v3，您可以通过在第 7 节下授予额外权限来实现此目标。以下许可证通知将会执行此操作。您必须使用适合您程序的文本替换括号中的所有文本。如果不是每个人都可以为您打算链接的库分发源代码，则应该删除大括号中的文本；否则，只需删除大括号。

Copyright (C) [年份] [著作权人名称]

本程序为自由软件；您可以根据自由软件基金会发布的 GNU GPL 许可证的条款再分发和/或修改它；无论是依据本许可证的版本3，或（根据您的选择）任何更高版本。

本程序基于希望其有用的目标而分发，但不提供任何担保；甚至也没有适销性或适用于特定用途的默示担保。有关详细信息，请参阅 GNU GPL 许可证。

您应该已经收到本程序以及 GNU GPL 许可证的副本；如果没有，请参阅 http://www.gnu.org/licenses。

依据 GNU GPL v3 第7节的额外许可

如果您通过将[与库的名称]（或库的修改版本）链接或结合来修改本程序，或任何被覆盖的作品，其中包含被[库许可证的名称]的条款所覆盖的部分，则该程序的许可人授予您额外许可来传递所产出的作品。{这种结合的非源代码形式的相应源代码应包括所使用的[库名称]部分的源代码以及被覆盖的作品的源代码。}

如果您使用 GPL v2，您可以为许可证条款提供自己的例外。以下许可证通知将这样做。同样，您必须使用适合您程序的文本替换括号中的所有文本。如果不是每个人都可以为您打算链接的库分发源代码，则应该删除大括号中的文本；否则，只需删除大括号。

Copyright (C) [年份] [著作权人名称]

本程序为自由软件；您可以根据自由软件基金会发布的 GNU GPL 许可证的条款再分发和/或修改它；无论是依据许可证的 v2，或（根据您的选择）任何更高版本。

本程序基于希望其有用的目标而分发，但不提供任何担保；甚至也没有适销性或适用于特定用途的默示担保。有关详细信息，请参阅 GNU GPL 许可证。

您应该已经收到本程序以及 GNU GPL 许可证的副本；如果没有，请参阅 http://www.gnu.org/licenses。

将[您的程序名称]与其他模块静态或动态链接是以[您的程序名称]为基础构建结合作品。因此，GNU GPL 许可证的条款和条件将覆盖整个结合作品。

另外，作为一个特殊例外，[您的程序名称]的版权持有人可以让您将[您的程序名称]与依据 GNU LGPL 发布的自由程序或库以及依据[库的许可证名称]标准发布的[库名称]中包含的代码相结合（或具有相同许可证的此类代码的修改版本）。您可以按照[您的程序名称]所依据的 GNU GPL 的条款和其他有关代码的许可证复制和分发此系统{前提是当 GNU GPL 要求分发源代码时将其他代码的源代码包含在内}。

注意，对[您的程序名称]做出修改版本的人没有义务为其修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU GPL 许可证允许发布一个没有此例外的修改版本；该例外也使得发布一个带有该例外的修改版本成为可能。

6.25 我正在使用 Microsoft Visual C ++（或 Visual Basic）编写 Windows 应用程序，我将依据 GPL 发布它。依据GPL，是否允许将我的程序与 Visual C ++（或 Visual Basic）运行时库动态链接？

您可以将您的程序链接到这些库，并将编译后的程序分发给其他程序。执行此操作时，运行时库是 GPL v3 所定义的“系统库”。这意味着您不需要担心将库的源代码包含在程序的相应源代码中。GPL v2 在第 3 节中提供了类似的例外。

您可能不会随同您的程序以编译后的 DLL 形式分发这些库。为了防止不道德的分发者试图将系统库例外作为漏洞进行利用，GPL 表示，只有库不与程序本身一起分发，库才能被认定为系统库。如果您随同您的程序分发 DLL，则它们将不再符合此例外的资格；那么遵守 GPL 的唯一方法就是提供它们的源代码，而您无法做到。

可以编写只在 Windows 上运行的自由程序，但这不是一个好主意。这些程序将被 Windows “围困” （ trapped ） ，因此对自由软件世界的贡献为零。

6.26 我想修改遵循 GPL 的程序，并将它们与 Money Guzzler Inc. 的可移植性库链接。我无法分发这些库的源代码，因此，任何想要更改这些版本的用户都必须单独获取这些库。为什么 GPL 不允许这样做？

有两个原因。第一、一般性的原因。如果我们允许 A 公司制作一个专有文件，B 公司分发与该文件相关的遵循 GPL 的软件，其效果等同于将 GPL 撕开一个大洞。对于保持 GPL 软件各种修改和扩展的源代码来说，这如同一张署名空白纸。

让所有用户能够访问源代码是我们的主要目标之一，所以这个结果绝对是我​​们想要避免的。

更具体地说，根据我们对条款的理解，与 Money Guzzler 库链接的程序版本不会是真正的自由软件——它们不会附带完整的让用户能够更改和重新编译程序的源代码。

6.27 如果模块 Q 的许可证具有与 GPL 不兼容的要求，但是只有当 Q 自身分发时，而不是在较大程序中包含 Q 时，该要求才适用，是否可以使得该许可证与 GPL 兼容？可以将 Q 与遵循 GPL 的程序结合使用吗？

如果程序 P 依据 GPL 被发布，这意味着“任何和所有部分”都可以依据 GPL 进行使用。如果您集成了模块 Q，并依据 GPL 发布结合程序 P + Q，则表示可以依据 GPL 使用 P + Q 的任何部分。P + Q 的一部分是 Q，所以依据 GPL 发布 P + Q 意味着，Q 的任何部分可以依据 GPL 进行使用。换句话说，依据 GPL 获得 P + Q 的用户可以删除 P，所以 Q 仍然遵循 GPL。

如果模块 Q 的许可证允许您授予该许可，则其与 GPL 兼容。否则，它不与 GPL 兼容。

如果 Q 的许可证在不明确的条件下表示，您必须在自己再分发 Q 时做某些事情（与 GPL 不兼容），那么不允许您依据 GPL 分发Q。因此，您也不能依据 GPL 发布 P + Q。所以您不能将 P 与 Q 进行链接或结合。

6.28 在面向对象的语言（如 Java）中，如果我在不修改的情况下使用遵循 GPL 的类，并对其进行子类化，GPL 会以什么方式影响较大的程序？

子类化将会创建衍生作品。因此，当您创建遵循 GPL 的类的子类时，GPL 的条款会影响整个程序。

6.29 分发一个意图链接到 Linux 内核的非自由驱动程序会违反 GPL 吗？

Linux（GNU / Linux 操作系统中的内核）依据 GNU GPL v2 进行分发。分发一个意图链接 Linux 的非自由驱动程序违反 GPL 吗？

是的，这是一种违规行为，因为这样做形成了更大的结合作品。用户期望把这些片段放在一起的事实并不会改变任何事情。

在代码实体部分拥有版权的 Linux 的每个贡献者都可以执行 GPL，我们鼓励他们对那些分发非自由 Linux 驱动程序的人采取行动。

6.30 如何允许在受控接口下将专有模块与我的 GPL 库链接起来？

在声明该文件依据 GNU GPL 进行分发的文本末尾，将以下文本添加到软件包中每个文件的许可证通知中：

将 ABC 与其他模块静态或动态链接是基于 ABC 创建结合作品。因此，GNU GPL 许可证的条款和条件将覆盖整个结合作品。

作为一个特殊的例外，ABC 的版权所有者可以将 ABC 程序与自由软件程序或依据 GNU LGPL 发布的库以及通过 ABCDEF 界面与 ABC 通信的独立模块相结合。您可以根据 ABC 的 GNU GPL 条款和其他代码的许可证复制和分发此系统，前提是您在 GNU GPL 需要分发源代码时提供该代码的源代码，并且您没有修改 ABCDEF 界面。

请注意，制作 ABC 修改版本的人没有义务为其修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU GPL 许可证允许发布不含此例外的修改版本；此例外也使得发布一个带有该例外的修改版本成为可能。如果您修改了 ABCDEF 界面，此例外不适用于您修改的 ABC 版本，并且您必须在分发修改后的版本时删除此例外。

此例外是依据 GNU GPL 许可证第3版（“GPL v3”）第7节的额外权限。

此例外允许通过指定接口（“ABCDEF”）与遵循不同许可证的模块进行链接，同时确保用户仍然会按照 GPL 通常的方式接收源代码。

只有该程序的版权持有者才能合法授权此例外。如果您自己编写了整个程序，假设您的雇主或学校没有声明版权，您就是版权所有者，因此您可以授权该例外。但是，如果您想在代码中使用其他作者的其他遵循 GPL 程序的一部分，那么您无法对他们的例外进行授权。您必须获得这些程序的版权所有者的批准。

6.31 考虑这种情况：1）X 发布遵循 GPL 的项目的 V1 版本。2）基于对 V1 的修改和新代码开发，Y 对 V2 的改进做出贡献。3）X 想将 V2 转换为非 GPL 许可证。X 需要 Y 的许可吗？

需要。Y 需要依据 GNU GPL 发布其版本，因为它基于 X 的版本 V1。没有任何要求规定 Y 为其代码适用任何其他许可。因此，X 必须获得 Y 的许可才能依据另一个许可证发布该代码。

6.32 我已经编写了一个与许多不同组件链接的应用程序，它们具有不同的许可证。我对我的程序有什么许可要求感到很困惑。您能告诉我可以使用哪些许可证吗？

为了回答这个问题，我们需要看一下你的程序使用的每个组件的列表，该组件的许可证和一个简短的（几句话应该足够）说明你的库如何使用该组件的描述。两个例子是：

  • 为了让我的软件工作，它必须链接到遵循 LGPL 的 FOO 库。
  • 我的软件进行系统调用（使用我建立的命令行）来运行 BAR 程序，该程序遵循 GPL，“具有允许与 QUUX 链接的特殊例外”。

6.33 可以在依据与 GPL 不兼容的许可证进行许可的文档中使用遵循 GPL 的源代码片段吗？

如果片段足够小，依据“合理使用”或类似的法律，您可以将它们纳入其中，那么可以。否则，不可以。

译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据GNU许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

5 在编写其他程序时采用依据 GNU 许可证发布的程序

5.1 我可以在同一台电脑上安装一个遵循 GPL 许可证的程序和一个不相关的非自由程序吗？（同 2.3）

可以。

5.2 我可以使用遵循 GPL 许可证的编辑器（例如 GNU Emacs）来开发非自由程序吗？我可以使用遵循 GPL 许可证的工具（例如 GCC）来编译它们吗？

可以，因为编辑器和工具的版权并不覆盖您所编写的代码。从法律上来说，使用它们不会对适用于您代码的许可证施加任何限制。

有些程序出于技术原因将其自身某些部分复制到输出文件中，例如，Bison 将标准解析器程序复制到其输出文件中。在这种情况下，输出文件中复制的文本遵循其在源代码中所遵循的相同许可证。同时，源自程序输入部分的输出部分继承输入部分的版权状态。

正因为如此，Bison 也可以用来开发非自由程序。这是因为我们决定明确允许在 Bison 输出文件中不受限制地使用 Bison 标准解析器程序。我们之所以做出这个决定，是因为还有其他与 Bison 相媲美的工具已被许可用于非自由程序。

5.3 有没有一些方法可以让使用我的程序的人们得到的输出物遵循 GPL？例如，如果我的程序用于开发硬件设计，我可以要求这些设计必须是自由的吗？（同 3.17）

一般来说，这在法律上是不可能的；针对人们通过使用您的程序获取数据形成的输出物如何使用，版权法并没有赋予您任何发言权。如果用户使用您的程序输入或转换自己的数据，输出物的版权属于他，而不是您。更一般来说，当程序将其输入物转换成其他形式时，输出物的版权状态将继承其得以生成的输入物的版权状态。

所以您对输出物的使用拥有发言权的唯一方式是输出物的实质部分（或多或少）是从您程序的文本中复制出来。例如，如果我们在这种具体情况下没有例外，那么Bison的一部分输出物（参见问题 5.2）将被 GNU GPL 所涵盖。

所以，即使没有技术原因，您也可以人为制作一个程序，将某些文本复制到其输出物中。但是，如果复制的文本没有实际用途，用户可以简单地从输出物中删除该文本，并且仅使用其余的内容。那么他就不必满足重新分发所复制文本的条件。

5.4 在什么情况下，遵循 GPL 的程序其输出文件也必须遵循 GPL 呢？

程序的输出文件通常不受程序代码的版权保护。因此，程序代码的许可证不适用于输出文件，无论是将其导入文件，还是制作屏幕截图、屏幕录像或视频。

例外情况是，程序全屏显示来源于程序的文本和/或艺术品。该文本和/或艺术品的版权则会覆盖其输出文件。输出音频的程序（例如视频游戏）也将适用于此例外。

如果艺术品/音乐遵循 GPL，则无论您如何进行复制，GPL 都适用。不过， 合理使用 （ fair use ） 可能仍然适用。

请记住，一些程序，特别是视频游戏，可以具有与底层遵循 GPL 的游戏分开许可的艺术品/音频。在这种情况下，艺术品/音频的许可证将规定视频/流媒体可以依之产生的条款。另请参阅：1.6 我可以将GPL应用于软件以外的其他作品吗？

5.5 如果我将我的程序移植到 GNU/Linux，这是否意味着我必须将其作为遵循 GPL 或其他自由软件许可证的自由软件进行发布？

一般来说，答案是否定的——这不是法律规定。具体来说，答案取决于您要使用哪些库以及许可证。大多数系统库都使用 GNU LGPL 许可证，或者使用 GNU GPL 加上允许将库与任何东西链接的例外声明。这些库可以在非自由程序中使用；但是在 LGPL 的情况下，它确实有一些必须遵循的要求。

一些库依据 GNU GPL 单独发布；您必须使用与 GPL 兼容的许可证才能使用这些库。但是这些通常是更特定的库，而在另一个平台不会有任何类似它们的库，所以您可能不会想要简单地移植使用这些库。

当然，如果您的软件不是自由软件，它不会对我们的社区做出贡献，而重视软件自由的人也会拒绝使用它。只有愿意放弃软件自由的人才会使用您的软件，这意味着它将有效地成为人们失去软件自由的诱因。

如果您希望有一天回头看您的职业生涯，觉得它有助于发展一个善良和自由的社会，您需要使您的软件成为自由软件。

5.6 我想将遵循 GPL 的软件纳入我的专有系统。我只依据 GPL 给予我的权限来使用该软件。我可以这样做吗？

您不能将遵循 GPL 的软件纳入专有系统。GPL 的目标是授予每个人复制、再分发、理解和修改程序的自由。如果您可以将遵循 GPL 的软件整合到非自由系统中，则可能会使遵循 GPL 的软件不再是自由软件。

包含遵循 GPL 程序的系统是该 GPL 程序的扩展版本。GPL 规定，如果它最终发布的话，任何扩展版本的程序必须依据 GPL 发布。这有两个原因：确保获得软件的用户获得自己应该拥有的自由，并鼓励人们回馈他们所做的改进。

但是，在许多情况下，您可以将遵循 GPL 的软件与专有系统一起分发。要有效地做到这一点，您必须确保自由和非自由程序之间的通信保持 一定距离 （ arms length ） ，而不是将它们有效地结合成一个程序。

这种情况与“纳入”遵循 GPL 的软件之间的区别，部分是实质问题，部分是形式问题。实质上是这样的：如果两个程序结合起来，使它们成为一个程序的两个部分，那么您不能将它们视为两个单独的程序。所以整个作品必须遵循 GPL。

如果这两个程序保持良好的分离，就像编译器和内核，或者像编辑器和 shell 一样，那么您可以将它们视为两个单独的程序，但是您必须恰当执行。这个问题只是一个形式问题：您如何描述您在做什么。为什么我们关心这个？因为我们想确保用户清楚地了解软件集合中遵循 GPL 的软件的自由状态。

如果人们分发遵循 GPL 的软件，将其称为系统（用户已经知晓其中一部分为专有软件）的“一部分”，用户可能不确定其对遵循 GPL 的软件所拥有的权利。但是如果他们知道他们收到的是一个自由程序加上另外一个程序，那么他们的权利就会很清楚。

5.7 如果我分发了一个与我修改后的遵循 LGPL v3 的库相链接的专有程序，那么为了确定我正在做出的明确的专利许可授权的范围， “贡献者版本” （ contributor version ） 是什么？它仅是库，还是整个组合？

“贡献者版本”仅是您的库版本。

5.8 依据 AGPL v3，当我根据第 13 节修改程序时，必须提供什么样的 相应源代码 （ Corresponding Source ） ？

“相应源代码”在许可证的第 1 节中定义，您应该提供其列出的内容。因此，如果您的修改版本取决于遵循其他许可证的库，例如 Expat 许可证或 GPL v3，则相应源代码应包括这些库（除非是系统库）。如果您修改了这些库，则必须提供您修改后的源代码。

第 13 节第一段的最后一句只是为了强化大多数人所自然地认为的那样：尽管在第 13 节中通过特殊例外来处理与遵循 GPL v3 的代码相结合的情况，相应源代码仍然应该包括以这种方式与程序相结合的代码。这句话并不意味着您只需提供 GPL v3 所涵盖的源代码；而是意味着这样的代码不会从相应源代码的定义中排除。

5.9 在哪里可以了解更多有关 GCC 运行时库例外的信息？

GCC 运行时库例外包含 libgcc、libstdc ++、libfortran、libgomp、libdecnumber 以及与 GCC 一起分发的其他库。这个例外是为了让人们根据自己选择的条件分发用 GCC 编译的程序，即使这些库的一部分作为编译过程的一部分被包含在可执行文件中。要了解更多信息，请阅读有关 GCC 运行时库例外的常见问题。

译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据GNU许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

4 依据GNU许可证分发程序

4.1 我可以仅用二进制形式发布一个遵循 GPL 的程序的修改版本吗？

不可以。GPL 的要旨是所有修改版本必须是自由软件——这意味着修改版本的源代码必须可供用户使用。

4.2 我从网上下载了二进制文件。如果我分发该副本，我必须也要获取源代码并分发？

是的。一般规则是，如果您分发二进制文件，则还必须分发完整的相应源代码。您收到索取源代码书面文件的例外情况非常有限。

4.3 我想通过物理媒体分发二进制文件，但不附带源代码。我可以通过 FTP 提供源代码吗？

GPL v3 允许这种行为；有关详细信息，请参阅条款 6（b）。依据 GPL v2，您可以径自通过 FTP 提供源代码，大多数用户将从那里获得。然而，如果他们中的任何人宁愿通过邮件获取以物理媒体承载的源代码，那么您需要为之提供。

如果您通过 FTP 分发二进制文件，则应通过 FTP 分发源代码。

4.4 我的朋友获取了一个遵循 GPL 的二进制文件和承诺提供源代码的书面文件，并为我提供了副本。我可以自己使用这个书面文件来获取源代码吗？

是的，你可以。该书面文件必须对拥有其所相伴的二进制文件的所有人开放。这就是为什么 GPL 说你的朋友必须给你一份这个书面文件的副本以及这个二进制文件的副本，所以你可以使用该书面文件索取源代码。

4.5 我可以将二进制文件放在我的互联网服务器上，并将源代码放在不同的网站上吗？

可以。第 6（d）条允许这样做。但是，您必须提供明确指示，以利于人们依次来获取源代码，并且必须注意，只要你的目标代码还在分发，就要确保源代码仍然可用。

4.6 我想以二进制形式分发一个遵循 GPL 的程序的扩展版本，是否分发原始版本的源代码就足够了？

不可以，您必须提供与二进制文件对应的源代码。对应的源代码意味着用户可以从中重建相同的二进制文件。

自由软件的一部分理念是用户应该可以访问他们使用的程序的源代码。使用您的版本的用户应该可以访问您的版本的源代码。

GPL 的一个主要目标是建立自由世界，确保对自由程序的改进本身是自由的。如果您发布一个改进版本的遵循 GPL 的程序，您必须依据 GPL 发布改进的源代码。

4.7 我想分发二进制文件，但不太方便分发完整的源代码。我是否可以向用户提供来自与该二进制文件对应的“标准”版本的diff？

这是一个很好的想法，但是这种提供源代码的方法并没有真正做到这一点。

一年之后想要获取源代码的用户可能无法从当时的其他站点获取正确的版本。标准分发站点可能有一个较新的版本，但相同的diff 可能无法与该版本一起使用。

所以你需要为二进制文件提供完整的源代码，而不仅仅是 diff。

4.8 我可以在网络服务器上发布二进制文件，但是仅向索取的用户发送源代码吗？

如果您在网络服务器上提供二进制对象代码，则必须在网络服务器上提供对应源代码。执行此操作的最简单方法是将它们发布在同一台服务器上，但如果需要，您可以提供从其它服务器甚至版本控制系统获取源代码的说明。不管你做什么，源代码都应该像目标代码一样容易访问。这些全部在 GPL v3 的第 6（d）节中进行了具体说明。

您提供的源代码必须完全对应于二进制文件。特别是，您必须确保它们是相同版本的程序——不是旧版本，也不是新版本。

4.9 如何确保每个下载二进制文件的用户都能获得源代码？

你不必确定这一点。只要您使源代码和二进制文件可用，以便用户可以看到可用的内容并获取所需的内容，那么您已经完成了所需的操作。是否下载源代码取决于用户。

我们对再分发者的要求旨在确保用户可以获得源代码，而不是强迫用户即使在不需要的情况下也要下载源代码。

4.10 GPL 要求我提供可以构建成与我正在分发的二进制文件的精确哈希值相匹配的二进制文件的源代码吗？

完全对应的源代码意味着二进制文件依赖该源代码生成，但这并不意味着您的工具必须能够创建一个与您正在分发的二进制文件的精确哈希值相同的二进制文件。在某些情况下，可能（几乎）不可能使用正在分发的二进制文件的精确哈希值从源代码构建二进制文件——考虑以下示例：系统可能会将时间戳放在二进制文件中；或者程序可能是针对不同的（甚至未发行的）编译器版本构建的。

4.11 我是否可以发布一个遵循某许可证的程序，该许可证表示您可以依据 GPL 分发修改后的版本，但是您不能分发遵循 GPL 的原始版本？

不可以，这样的许可证是自相矛盾的。我们来看看它对用户的影响。

假设我从原始版本（称为版本 A）开始，添加一些代码（让我们假设它是 1000 行），并依据 GPL 发布修改版本（称为 B 版本）。GPL 说任何人都可以再次更改 B 版本，并依据 GPL 发布修改结果。我（或其他人）可以删除那 1000 行代码，生成与版本 A 代码相同的但遵循 GPL 的 C 版本。

通过在许可证中明确表示我不允许删除版本 B 中的那些行，重制成与遵循 GPL 的 A 版本相同的东西，您可以尝试阻止该路径。但实际上许可证表示现在我不能完全以 GPL 允许的所有方式使用版本 B。换句话说，许可证实际上不允许用户发布诸如遵循 GPL 的 B 版本这样的修改版本。

4.12 我刚刚发现一家公司有一份 GPL 程序的副本，获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗？

不会，GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且（一个特殊情况之外），即使有人决定再分发该程序，GPL 也不会要求他必须特意向您或其他人分发副本。

GPL 要求的是，如果他愿意，他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人，如果某人认为合适，那么该人可以将程序再分发给您或任何其他人。

4.13 一家公司正在网站上运行一个 GPL 程序的修改版本。GPL 规定他们是否必须发布修改后的源代码？

GPL 允许任何人进行修改并使用修改版本，而无需将其分发给他人。（这里所说的）这家公司的做法是一个特例。 因此，公司不必发布修改后的源代码。

人们必须能够自由地对程序进行修改并自用，而无需发布这些修改。然而，将程序放在服务器上以供公众访问很难说是“自用”，因此要求在这种特殊情况下发布源代码是合法的。希望解决这个问题的开发人员可以为其程序适用 GNU Affero GPL，该许可证专门为网络服务器使用场景而设计。

4.14 在一个组织或公司中制作和使用多个副本构成“分发”吗？

不构成，在这种情况下，组织只是为自己制作副本。因此，公司或其他组织可以开发修改后的版本，并通过自己的设施安装该版本，但不得允许员工向外发布该修改版本。

但是，当组织将副本转移给其他组织或个人时，即构成分发。特别是，向承包商提供副本以便在场外使用，构成了分发。

4.15 如果有人窃取包含 GPL 程序的 CD，GPL 是否授予小偷再分发该版本的权利？

如果该版本已经在其他地方被发布，那么依据 GPL，这个小偷可能确实有权利制作副本并将其再分发，但是如果小偷因为窃取 CD 而被监禁，那么他们可能必须等到释放才能这样做。

如果相关版本未被公开发布并被公司视为其商业秘密，则根据其他情况，发布该版本可能会违反商业秘密法。GPL 对此没有进行改变。如果公司试图发布其版本，并仍将其视为商业秘密，则会违反 GPL，但如果公司尚未发布此版本，则不会发生此类违规。

4.16 如果一家公司将副本作为商业秘密分发会构成违规吗？

如果该公司向您分发副本并声称是商业秘密，则该公司违反了 GPL，必须停止分发。请注意这与上述盗窃案有何不同；该公司没有故意在副本被盗后分发副本，所以在这种情况下，该公司没有违反 GPL。

4.17 我在使用 GPL 程序的源代码时是否具有 “合理使用” （ fair use ） 权限？

是的，您有。“合理使用”是在没有任何特别许可的情况下允许的使用。 由于您不需要开发人员的许可来进行这种使用，无论开发人员在许可证或其他地方对此怎么说，您都可以执行此操作，无论该许可证是 GNU GPL 还是其他自由软件许可证。

但是，请注意，没有全世界范围普适的合理使用原则；什么样的用途被认为“合理”因国而异。

4.18 将副本移至控股的附属公司会构成分发吗？

副本移至/移自附属公司是否构成“分发”需要根据恰当管辖区的版权法依据个案确定。GPL 没有也不能逾越当地法律。美国版权法关于这一点的规定并不完全清楚，但似乎并不将此视为分发。

如果在某些国家，这被视为分发，而附属公司必须得到再分发程序的权利，这不会有实际的区别。附属公司由母公司控制；无论有没有权利，除非母公司决定这样做，否则附属公司不会再分发该程序。

4.19 软件安装程序可以要求用户通过点击来同意 GPL 协议吗？如果我获得一些遵循 GPL 的软件，我必须同意什么吗？

一些软件安装系统有一个地方要求您点击或以其他方式表示同意 GPL 的条款。这不是必须的，也不是禁止的。无论是否点击， GPL 的规则保持不变。

只是同意 GPL 不要求您承担任何义务。仅使用依据 GPL 进行许可的软件，您不需要同意任何事项。只有您修改或分发软件时，您才有义务。如果点击同意 GPL 真的打扰了你，没有任何东西能阻止你修改该 GPL 软件把这个步骤删除掉。

4.20 我想将 GPL 软件与某种安装软件捆绑在一起。该安装程序是否需要具有与 GPL 兼容的许可证？

不需要。安装程序及其安装的文件是单独的作品。因此，GPL 的条款不适用于安装软件。

4.21 GPL 软件的一些分发者要求将我囊括在其伞式的最终用户许可协议（EULA）中或作为下载过程的一部分，以“代表和保证”我位于美国，或者我打算依据相关出口管制法律分发软件。为什么他们这样做，是否违反了分发者在 GPL 下的义务？

这不违反 GPL。那些分发者（几乎都是销售自由软件分发版本和相关服务的商业企业）正在努力降低自己的法律风险，而不是控制您的行为。如果分发者故意将软件出口到某些国家或将软件提供给可能会进行这种出口行为的第三方，美国的出口管制法可能会要求分发者承担责任。分发者通过向客户和被分发软件的其他人要求做出这些声明，一旦被监管机构问及他们是否知道其分发的软件流至何方，分发者可以借此保护自己。分发者并不限制您可以用软件做什么，只是避免他们对您所做的任何事情负责。因为分发者没有对软件施加额外的限制，所以他们不违反 GPL v3 的第 10 节或 GPL v2 的第 6 节。

自由软件基金会（FSF）反对将美国出口管制法律适用于自由软件。这些法律不仅与软件自由的总体目标不符，而且达不到合理的政府目的，因为目前几乎每个国家都可以使用自由软件并且应该一直都能使用，包括没有出口管制法律的国家以及参与美国领导的贸易禁运的国家。所以没有一个国家的政府实际上被美国的出口管制法律剥夺了使用自由软件的权利，就我们而言，不管其政府的政策如何，每个国家的公民都不应该被剥夺使用自由软件的权利。自由软件基金会发布的所有 GPL 软件的副本可以通过我们获得，而不对您居住地点或您打算做什么进行任何限制。同时，自由软件基金会理解位于美国的商业分发者遵守美国法律的愿望。他们有权选择将自由软件的特定副本分发给谁；该权利的行使不违反 GPL，除非他们增加超出 GPL 许可的合同限制。

4.22 GPL v3 第 6 节的开头说，如果我也符合第 6 节的条件，我可以“按照第 4 节和第 5 节的规定”，以目标代码的形式传递其覆盖的作品。这是什么意思？

这意味着您传递源代码的所有权限和条件也适用于传递目标代码：您可以收取费用，您必须保持版权声明不变，等等。

4.23 我公司拥有很多专利。多年来，我们遵循“GPL 第 2 版或更新版本”的项目提供了代码，项目本身已按相同的条款进行了分发。如果用户决定将项目代码（包含我公司的贡献）适用 GPL v3，那意味着我已经自动向该用户授予 GPL v3 中的明确专利许可？

不是，当您 传递 （ convey ） 遵循 GPL 的软件时，您必须遵守该许可证特定版本的条款和条件。当您这样做时，该版本定义了您拥有的义务。如果用户也可以选择使用更新版本的 GPL，那仅仅是他们拥有的额外权限——它不需要您满足 GPL 更新版本条款的要求。

不要因为答案是 NO 就认为可以用你的专利来威胁社区（LCTT 译注：感谢“西米宜家”的指正）。在许多国家，根据 GPL v2 分发软件为接收人提供了隐含的专利许可，以行使 GPL 中的权利。即使没有，任何考虑强制执行专利的人都是社区的敌人，我们将捍卫自己免受这种攻击。

4.24 如果我分发了一个遵循 GPL v3 的程序，我可以提供一个一旦用户修改程序则无效的保修吗？

可以。就像用户一旦修改设备中的软件就不需要保证设备安全一样，您不需要提供涵盖所有可能通过遵循 GPL v3 的软件进行的活动的保修。

4.25 如果我给公司同事一份遵循 GPL v3 的程序的副本，是否构成了我将该副本 “传递” （ convey ） 给该同事？

只要您在公司的工作中使用软件，而不是个人使用该软件，那么答案是否定的。副本属于公司，不属于您或同事。这种复制是 传播 （ propagation ） 而不是 传递 （ convey ） ，因为公司没有将副本提供给他人。

4.26 如果我通过链接至版本控制系统（例如 CVS 或 Subversion）中的源代码存储库方式提供源代码，而在 FTP 服务器上提供二进制文件，这种做法符合 GPL v3 吗？

只要源码签出过程不会变得繁重或存在其他限制，这是可以接受的。任何可以下载目标代码的人也应该可以使用公开的自由软件客户端从版本控制系统中签出源代码。应向用户提供清晰方便的说明，说明如何获取其下载的确切目标代码的源代码——毕竟，他们可能不一定需要最新的开发代码。

4.27 在 用户产品 （ User Product ） 中传递遵循 GPL v3 的软件的用户，是否可以使用远程认证来防止用户修改该软件？

不可以。当软件在用户产品中传递时，必须与源文件一起提供的“安装信息”的定义中明确表示：“该信息必须足以确保修改的目标代码的继续运行在任何情况下都不会仅仅因为修改过而被阻止或干扰。“如果设备以某种方式使用远程认证，则安装信息必须为您修改的软件报告自身的合法性提供一些方法。

4.28 GPL v3 中的“通过网络进行通信的规则和协议”是什么意思？

这是指可以通过网络发送的流量规则。例如，如果每天可以发送到服务器的请求数量或者您可以在某处上传的文件大小有限制，如果不遵守这些限制，则可能会拒绝您对这些资源的访问。

这些规则不包括任何与网络上传播的数据无关的内容。例如，如果网络上的服务器将用户消息发送到您的设备，则您对网络的访问无法被拒绝，因为您修改了该软件以使其不显示消息。

4.29 依据 GPL v3 提供安装信息的分发者不需要为产品提供“支持服务”。 所谓的“支持服务”具体是指哪些？

这其中包括设备制造商提供的帮助您安装、使用或排除故障的服务。如果设备依赖于访问 Web 服务或类似技术才能正常运行，则通常仍然可以使用修改版本，但须符合第 6 节中关于访问网络的条款。

译者介绍：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据 GNU 许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

3、在您的程序中使用 GNU 许可证

3.1 如何从 (L)GPLv2 升级到 (L)GPLv3？

首先，在您的软件包中包含新版本的许可证。如果您在项目中使用 LGPL v3，请确保一同包含了 GPL v3 和 LGPL v3 的副本，因为 LGPL v3 现在被写成在 GPL v3 基础上的一系列附加许可。

其次，将所有现有的 v2 许可证 通知 （ notice ） （通常位于每个文件的顶部）替换为“如何使用 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 为什么要在每个源文件中放置许可证 通知 （ notice ） ？

您应该在每个源文件的起始处放置通知，说明它所携带的许可证，以避免代码与其许可证被断开的风险。如果您存储库的 README 文件声明源文件遵循 GNU GPL，如果有人将该文件复制到另一个程序，会发生什么呢？ 其他上下文可能无法表明该文件的许可证是什么。它似乎有一些其他许可证，或根本没有许可证（这将使代码变成非自由软件）。

在每个源文件的开始添加版权声明和许可证通知很容易，造成这种混乱的可能性不大。

这与 GNU GPL 的具体内容无关。对于任何自由许可证来说都是正确的。

3.7 如果作品不是很长，那该怎么办？（同 2.15）

如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行，那么您可以使用一个宽松的许可证，而不是像 GNU GPL 这样的左版许可证（除非代码特别重要）。我们建议这种情况使用 Apache 许可证 2.0。

3.8 为了节省空间，我是否可以省略 GPL 的引言部分，或者省略如何在自己的程序上使用 GPL 的 指导 （ instructions ） 部分吗？（同 2.21）

引言和指导是 GNU GPL 的组成部分，不能省略。事实上，GPL 是受版权保护的，其许可证规定只能逐字复制整个 GPL。（您可以使用法律条款制作另一个许可证，但该许可证不再是 GNU GPL。）

引言和指导部分共约 1000 字，不到 GPL 总文字数量的 1/5。除非软件包本身很小，否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下，您可以使用一个简单的 全权 （ all-permissive ） 许可证，而不是 GNU GPL。

3.9 如何获得我的程序的版权，以便依据 GPL 发布？

根据 《伯尔尼公约》 （ Berne Convention ） ，所有书写成文的内容都将自动受版权保护。所以你没有必要做任何事情来“获得”你所写代码的版权——只要没有其他人声称拥有你的作品。

不过，在美国注册版权是一个很好的主意。这将给你在美国应对侵权者带来更多的影响力。

其他人可能声称拥有版权的情况是，如果您是雇员或学生；那么雇主或学校可能会声称你为他们做了工作，并且版权属于他们。他们是否存在有效的权利主张将取决于你所居住地方的法律，以及你的雇佣合同和你所做的工作。如果有任何疑问，最好咨询律师。

如果您认为雇主或学校可能会提出权利主张，您可以通过获得公司或学校适当授权的官员签署的版权免责声明来明确解决该问题。（您的直接上司或教授通常无权签署此免责声明。）

3.10 如果我的学校想将我自己的程序应用到学校的专有软件产品，我该怎么办？

现在许多大学试图通过限制他们所开发的知识和信息的使用来筹集资金，其实际上与商业业务有所不同。 （参见刊载于 2000 年 3 月 《大西洋月刊》 （ Atlantic Monthly ） 的 《受缚的大学》 （ The Kept University ） ，该文章对这个问题及其影响进行了一般性的讨论。）

如果您在某种程度上认为您的学校可能拒绝允许您的程序作为自由软件发布，最好尽早提出这个问题。程序越接近于有用的作品，行政部门越有动机从你手里拿回该程序，并在没有你的情况下完成它。在更早的阶段，你有更多的影响力。

所以我们建议你在程序只进行一半的时候接触他们，说：“如果你同意将它作为自由软件发布，我会完成它。”不要以为这是虚张声势。要取得胜利，你必须有勇气说：“我的程序如果不能成为自由软件，我宁愿不把它写出来。”

3.11 我想发布一个我依据 GNU GPL 编写的程序，但是我想在非自由程序中使用相同的代码。

发布一个非自由程序总是有道德上的污点，但从法律上来说没有任何障碍阻止你这样做。如果您是代码的版权所有者，您可以在不同时间以各种不同的非独占许可证发布。

3.12 依据 GPL 分发的程序的开发人员是否可以将其授权给另一方专用？

不可以，因为公众已经有权利使用遵循 GPL 的该程序，这个权利是不能撤销的。

3.13 美国政府可以依据 GNU GPL 发布一个程序吗？

如果这个程序是由美国联邦政府雇员在雇用过程中编写的，那么它是处于公有领域，这意味着它不受版权保护。由于GNU GPL是基于版权的许可证，所以这样的程序不能依据 GNU GPL 发布。（它仍然可以是自由软件，公有领域的程序是自由软件。）

不过，当美国联邦政府机构使用承包商来开发软件时，那就是不同的情况。合同可以要求承包商依据 GNU GPL 进行发布（GNU Ada 是以这种方式开发的）。或者合同可以将版权 分配 （ assign ） 给政府机构，然后政府机构可以依据 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 中包含了帮助免费手册的出版商从销售副本中获利的条款，例如，出售封面文字。 背书 （ Endorsements ） 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的，但该修改版本不能被标记为“该标准”。

使用 GFDL，我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要，因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由，它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” （ invariant ） ，使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。

3.19 GPL 如何适用于字体？

字体许可是一个复杂的问题，需要认真考虑。以下许可证例外是试验性的，但被批准用于一般用途。我们欢迎关于这个问题的建议——请参阅这个解释性文章，并写邮件到 [email protected] 。

要使用此例外，请将该文本添加到软件包中的每个文件的许可证通知中（尽可能），在文本末尾说明该文件依据 GNU GPL 分发：

作为一个特殊的例外，如果您创建一个使用此字体的文档，并将该字体或该字体未更改的部分嵌入到文档中，则此字体本身不会导致生成的文档被 GNU 通用公共许可证 （ GNU General Public License ） 覆盖。然而，这个例外不会使文档可能被 GNU 通用公共许可证涵盖的任何其他原因无效。如果您修改此字体，您可以将此例外扩展到您的字体版本，但是您没有义务这样做。如果您不想这样做，请从您的版本中删除此例外声明。

3.20 我正在编写一个网站维护系统（有人称之为“内容管理系统”）或者是其他一些从模板生成网页的应用程序。我应该为这些模板使用什么许可证？

模板很小，不值得使用 左版 （ copyleft ） 来保护它们。在小作品上使用左版通常是无害的，但模板是一种特殊情况，因为它们与应用程序用户提供的数据结合使用，并且其组合被分发。因此，我们建议您以简单的许可条款许可您的模板。

一些模板调用 JavaScript 函数。由于 JavaScript 通常是不一般的作品，因此它值得用左版保护。由于模板与用户数据相结合，因此模板 + 用户数据 + JavaScript 可能被版权法看作是一个作品。需要在 JavaScript（受左版保护）和用户代码（通常遵循不兼容的条款）之间划清界限。

以下是执行此操作的 JavaScript 代码的一种例外：

作为 GPL 的一个特殊例外，仅对此代码进行函数调用并且为此目的通过引用将其包括在内的 HTML 文件，将被视为版权法意义下的单独作品。此外，此代码的版权所有者可以让您将该代码与依据 GNU LGPL 发布的自由软件库相结合。您可以按照此代码所遵循的 GNU GPL 条款以及此库所遵循的 LGPL 条款复制和分发这样一个系统。如果您修改此代码，则可以将此例外扩展到您的代码版本，但是您没有义务这样做。如果您不想这样做，请从您的版本中删除此例外声明。

3.21 我可以发布一个使用非自由工具开发的遵循 GPL 的程序吗？

您使用什么程序来编辑、编译、研究、记录源代码，通常对于该源代码的许可问题没有任何影响。

但是，如果将非自由库与源代码链接，那么它就是一个您需要进行处理的问题。它不阻碍依据GPL发布源代码，但是如果这些库不符合 “系统库” （ system library ） 例外情况，那么您应该附加一个明确的通知，允许您的程序与它们进行链接。有关使用 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 中的 适当法律声明 （ Appropriate Legal Notices ） 要求？

所有您需要做的是确保适当法律声明对于您界面中的用户来说唾手可得。例如，如果您已经编写了一个音频接口，您可以包括一个大声朗读该声明的命令。

目录

  • break -- 在指定的行或函数处设置断点，缩写为 b
  • info breakpoints -- 打印未删除的所有断点，观察点和捕获点的列表，缩写为 i b
  • disable -- 禁用断点，缩写为 dis
  • enable -- 启用断点
  • clear -- 清除指定行或函数处的断点
  • delete -- 删除断点，缩写为 d
  • tbreak -- 设置临时断点，参数同 break，但在程序第一次停住后会被自动删除
  • watch -- 为表达式（或变量）设置观察点，当表达式（或变量）的值有变化时，暂停程序执行
  • step -- 单步跟踪，如果有函数调用，会进入该函数，缩写为 s
  • reverse-step -- 反向单步跟踪，如果有函数调用，会进入该函数
  • next -- 单步跟踪，如果有函数调用，不会进入该函数，缩写为 n
  • reverse-next -- 反向单步跟踪，如果有函数调用，不会进入该函数
  • return -- 使选定的栈帧返回到其调用者
  • finish -- 执行直到选择的栈帧返回，缩写为 fin
  • until -- 执行直到达到当前栈帧中当前行后的某一行（用于跳过循环、递归函数调用），缩写为 u
  • continue -- 恢复程序执行，缩写为 c
  • print -- 打印表达式 EXP 的值，缩写为 p
  • x -- 查看内存
  • display -- 每次程序停止时打印表达式 EXP 的值（自动显示）
  • info display -- 打印早先设置为自动显示的表达式列表
  • disable display -- 禁用自动显示
  • enable display -- 启用自动显示
  • undisplay -- 删除自动显示项
  • help -- 打印命令列表（带参数时查找命令的帮助），缩写为 h
  • attach -- 挂接到已在运行的进程来调试
  • run -- 启动被调试的程序，缩写为 r
  • backtrace -- 查看程序调用栈的信息，缩写为 bt
  • ptype -- 打印类型 TYPE 的定义

break

使用 break 命令（缩写 b）来设置断点。

用法：

  • break 当不带参数时，在所选栈帧中执行的下一条指令处设置断点。
  • break <function-name> 在函数体入口处打断点，在 C++ 中可以使用 class::function 或 function(type, ...) 格式来指定函数名。
  • break <line-number> 在当前源码文件指定行的开始处打断点。
  • break -N break +N 在当前源码行前面或后面的 N 行开始处打断点，N 为正整数。
  • break <filename:linenum> 在源码文件 filename 的 linenum 行处打断点。
  • break <filename:function> 在源码文件 filename 的 function 函数入口处打断点。
  • break <address> 在程序指令的地址处打断点。
  • break ... if <cond> 设置条件断点，... 代表上述参数之一（或无参数），cond 为条件表达式，仅在 cond 值非零时暂停程序执行。

详见官方文档。

info breakpoints

查看断点，观察点和捕获点的列表。

用法：

  • info breakpoints [list...]
  • info break [list...]
  • list... 用来指定若干个断点的编号（可省略），可以是 2， 1-3， 2 5 等。

disable

禁用一些断点。参数是用空格分隔的断点编号。要禁用所有断点，不加参数。

禁用的断点不会被忘记，但直到重新启用才有效。

用法：

  • disable [breakpoints] [list...]
  • breakpoints 是 disable 的子命令（可省略），list... 同 info breakpoints 中的描述。

详见官方文档。

enable

启用一些断点。给出断点编号（以空格分隔）作为参数。没有参数时，所有断点被启用。

用法：

  • enable [breakpoints] [list...] 启用指定的断点（或所有定义的断点）。
  • enable [breakpoints] once list... 临时启用指定的断点。GDB 在停止您的程序后立即禁用这些断点。
  • enable [breakpoints] delete list... 使指定的断点启用一次，然后删除。一旦您的程序停止，GDB 就会删除这些断点。等效于用 tbreak 设置的断点。

breakpoints 同 disable 中的描述。

详见官方文档。

clear

在指定行或函数处清除断点。参数可以是行号，函数名称或 * 跟一个地址。

用法：

  • clear 当不带参数时，清除所选栈帧在执行的源码行中的所有断点。
  • clear <function>, clear <filename:function> 删除在命名函数的入口处设置的任何断点。
  • clear <linenum>, clear <filename:linenum> 删除在指定的文件指定的行号的代码中设置的任何断点。
  • clear <address> 清除指定程序指令的地址处的断点。

详见官方文档。

delete

删除一些断点或自动显示表达式。参数是用空格分隔的断点编号。要删除所有断点，不加参数。

用法： delete [breakpoints] [list...]

详见官方文档。

tbreak

设置临时断点。参数形式同 break 一样。

除了断点是临时的之外，其他同 break 一样，所以在命中时会被删除。

详见官方文档。

watch

为表达式设置观察点。

用法： watch [-l|-location] <expr> 每当一个表达式的值改变时，观察点就会暂停程序执行。

如果给出了 -l 或者 -location，则它会对 expr 求值并观察它所指向的内存。例如，watch *(int *)0x12345678 将在指定的地址处观察一个 4 字节的区域（假设 int 占用 4 个字节）。

详见官方文档。

step

单步执行程序，直到到达不同的源码行。

用法： step [N] 参数 N 表示执行 N 次（或由于另一个原因直到程序停止）。

警告：如果当控制在没有调试信息的情况下编译的函数中使用 step 命令，则执行将继续进行，直到控制到达具有调试信息的函数。 同样，它不会进入没有调试信息编译的函数。

要执行没有调试信息的函数，请使用 stepi 命令，详见后文。

详见官方文档。

reverse-step

反向单步执行程序，直到到达另一个源码行的开头。

用法： reverse-step [N] 参数 N 表示执行 N 次（或由于另一个原因直到程序停止）。

详见官方文档。

next

单步执行程序，执行完子程序调用。

用法： next [N]

与 step 不同，如果当前的源代码行调用子程序，则此命令不会进入子程序，而是将其视为单个源代码行，继续执行。

详见官方文档。

reverse-next

反向步进程序，执行完子程序调用。

用法： reverse-next [N]

如果要执行的源代码行调用子程序，则此命令不会进入子程序，调用被视为一个指令。

参数 N 表示执行 N 次（或由于另一个原因直到程序停止）。

详见官方文档。

return

您可以使用 return 命令取消函数调用的执行。如果你给出一个表达式参数，它的值被用作函数的返回值。

用法： return <expression> 将 expression 的值作为函数的返回值并使函数直接返回。

详见官方文档。

finish

执行直到选定的栈帧返回。

用法： finish 返回后，返回的值将被打印并放入到值历史记录中。

详见官方文档。

until

执行直到程序到达当前栈帧中当前行之后（与 break 命令相同的参数）的源码行。此命令用于通过一个多次的循环，以避免单步执行。

用法：until <location> 或 u <location> 继续运行程序，直到达到指定的位置，或者当前栈帧返回。

详见官方文档。

continue

在信号或断点之后，继续运行被调试的程序。

用法： continue [N] 如果从断点开始，可以使用数字 N 作为参数，这意味着将该断点的忽略计数设置为 N - 1(以便断点在第 N 次到达之前不会中断)。如果启用了非停止模式（使用 show non-stop 查看），则仅继续当前线程，否则程序中的所有线程都将继续。

详见官方文档。

print

求值并打印表达式 EXP 的值。可访问的变量是所选栈帧的词法环境，以及范围为全局或整个文件的所有变量。

用法：

  • print [expr] 或 print /f [expr] expr 是一个（在源代码语言中的）表达式。

默认情况下，expr 的值以适合其数据类型的格式打印；您可以通过指定 /f 来选择不同的格式，其中 f 是一个指定格式的字母；详见输出格式。

如果省略 expr，GDB 再次显示最后一个值。

要以每行一个成员带缩进的格式打印结构体变量请使用命令 set print pretty on，取消则使用命令 set print pretty off。

可使用命令 show print 查看所有打印的设置。

详见官方文档。

x

检查内存。

用法： x/nfu <addr> 或 x <addr> n、f 和 u 都是可选参数，用于指定要显示的内存以及如何格式化。addr 是要开始显示内存的地址的表达式。

n 重复次数（默认值是 1），指定要显示多少个单位（由 u 指定）的内存值。

f 显示格式（初始默认值是 x），显示格式是 print('x'，'d'，'u'，'o'，'t'，'a'，'c'，'f'，'s') 使用的格式之一，再加 i（机器指令）。

u 单位大小，b 表示单字节，h 表示双字节，w 表示四字节，g 表示八字节。

例如：

x/3uh 0x54320 表示从地址 0x54320 开始以无符号十进制整数的格式，双字节为单位来显示 3 个内存值。

x/16xb 0x7f95b7d18870 表示从地址 0x7f95b7d18870 开始以十六进制整数的格式，单字节为单位显示 16 个内存值。

详见官方文档。

display

每次程序暂停时，打印表达式 EXP 的值。

用法： display <expr>, display/fmt <expr> 或 display/fmt <addr> fmt 用于指定显示格式。像 print 命令里的 /f 一样。

对于格式 i 或 s，或者包括单位大小或单位数量，将表达式 addr 添加为每次程序停止时要检查的内存地址。

详见官方文档。

info display

打印自动显示的表达式列表，每个表达式都带有项目编号，但不显示其值。

包括被禁用的表达式和不能立即显示的表达式（当前不可用的自动变量）。

undisplay

取消某些表达式在程序暂停时的自动显示。参数是表达式的编号（使用 info display 查询编号）。不带参数表示取消所有自动显示表达式。

delete display 具有与此命令相同的效果。

disable display

禁用某些表达式在程序暂停时的自动显示。禁用的显示项目不会被自动打印，但不会被忘记。 它可能稍后再次被启用。

参数是表达式的编号（使用 info display 查询编号）。不带参数表示禁用所有自动显示表达式。

enable display

启用某些表达式在程序暂停时的自动显示。

参数是重新显示的表达式的编号（使用 info display 查询编号）。不带参数表示启用所有自动显示表达式。

help

打印命令列表。

您可以使用不带参数的 help（缩写为 h）来显示命令的类别名的简短列表。

使用 help <class> 您可以获取该类中的各个命令的列表。使用 help <command> 显示如何使用该命令。

详见官方文档。

attach

挂接到 GDB 之外的进程或文件。该命令可以将进程 ID 或设备文件作为参数。

对于进程 ID，您必须具有向进程发送信号的权限，并且必须具有与调试器相同的有效的 uid。

用法： attach <process-id> GDB 在安排调试指定的进程之后做的第一件事是暂停该进程。

无论是通过 attach 命令挂接的进程还是通过 run 命令启动的进程，您都可以使用的 GDB 命令来检查和修改挂接的进程。

详见官方文档。

run

启动被调试的程序。

可以直接指定参数，也可以用 set args 设置（启动所需的）参数。

例如： run arg1 arg2 ... 等效于

set args arg1 arg2 ...
run

还允许使用 >、 < 或 >> 进行输入和输出重定向。

详见官方文档。

backtrace

打印整体栈帧信息。

  • bt 打印整体栈帧信息，每个栈帧一行。
  • bt n 类似于上，但只打印最内层的 n 个栈帧。
  • bt -n 类似于上，但只打印最外层的 n 个栈帧。
  • bt full n 类似于 bt n，还打印局部变量的值。

where 和 info stack(缩写 info s) 是 backtrace 的别名。调用栈信息类似如下：

(gdb) where
#0  vconn_stream_run (vconn=0x99e5e38) at lib/vconn-stream.c:232
#1  0x080ed68a in vconn_run (vconn=0x99e5e38) at lib/vconn.c:276
#2  0x080dc6c8 in rconn_run (rc=0x99dbbe0) at lib/rconn.c:513
#3  0x08077b83 in ofconn_run (ofconn=0x99e8070, handle_openflow=0x805e274 <handle_openflow>) at ofproto/connmgr.c:1234
#4  0x08075f92 in connmgr_run (mgr=0x99dc878, handle_openflow=0x805e274 <handle_openflow>) at ofproto/connmgr.c:286
#5  0x08057d58 in ofproto_run (p=0x99d9ba0) at ofproto/ofproto.c:1159
#6  0x0804f96b in bridge_run () at vswitchd/bridge.c:2248
#7  0x08054168 in main (argc=4, argv=0xbf8333e4) at vswitchd/ovs-vswitchd.c:125

详见官方文档。

ptype

打印类型 TYPE 的定义。

用法： ptype[/FLAGS] TYPE-NAME | EXPRESSION

参数可以是由 typedef 定义的类型名， 或者 struct STRUCT-TAG 或者 class CLASS-NAME 或者 union UNION-TAG 或者 enum ENUM-TAG。

根据所选的栈帧的词法上下文来查找该名字。

类似的命令是 whatis，区别在于 whatis 不展开由 typedef 定义的数据类型，而 ptype 会展开，举例如下：

/* 类型声明与变量定义 */
typedef double real_t;
struct complex {
    real_t real;
    double imag;
};
typedef struct complex complex_t;

complex_t var;
real_t *real_pointer_var;

这两个命令给出了如下输出：

(gdb) whatis var
type = complex_t
(gdb) ptype var
type = struct complex {
    real_t real;
    double imag;
}
(gdb) whatis complex_t
type = struct complex
(gdb) whatis struct complex
type = struct complex
(gdb) ptype struct complex
type = struct complex {
    real_t real;
    double imag;
}
(gdb) whatis real_pointer_var
type = real_t *
(gdb) ptype real_pointer_var
type = double *

详见官方文档。

参考资料

译者：robot527 校对：mudongliang， wxy

  1. 1
  2. 2