本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据GNU许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 GNU 许可证的问题7 关于违反 GNU 许可证的问题7.1 如果发现了可能违反 GPL 许可证的行为，我该怎么办？您应该进行报告。 首先，尽可能检查事实。然后告诉发行者或版权所有者涉及的具体 GPL 程序。如果是自由软件基金会，请写信给 mailto:license-violation@gnu.org。此外，程序的维护者可能是版权所有者，他可能会告诉您如何联系版权所有者，因此将其报告给维护者。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 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据GNU许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 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】可以可以可以可以角注：在这种情况下，当结合代码时，您必须遵守 GPL v2 的条款。您不能适用更高版本的条款。在这种情况下，您可以依据 GPL v2 或更高版本发布您的项目（您的原始作品和/或您收到并修改的作品），请注意，您使用的其他代码仍然只能遵循 GPL v2。只要您的项目依赖于该代码，您将无法将项目的许可证升级到 GPL v3 或更高版本，整个作品（您的项目和其他代码的任意结合）只能依据 GPL v2 的条款传递。如果您有能力依据 GPL v2 或任何更高版本发布项目，您可以选择依据 GPL v3 或更高版本发布该项目，一旦您执行此操作，您就可以结合依据 GPL v3 发布的代码。如果您有能力依据 LGPL v2.1 或任何更高版本发布项目，您可以选择依据 LGPL v3 或更高版本发布该项目，一旦您这样做，您就可以结合依据 LGPL v3 发布的代码。在这种情况下结合代码时，您必须遵守 LGPL v2.1 的条款。您不能适用更高版本 LGPL 中的条款。如果这样做，只要项目包含仅依据 LGPL v2.1 发布的代码，您将无法将项目的许可证升级到 LGPL v3 或更高版本。LGPL v2.1 允许您将遵循自 GPL v2 之后任何版本 GPL 的代码进行重新许可。如果在这种情况下可以将遵循 LGPL 的代码切换为使用适当版本的 GPL（如表所示），则可以进行此种结合。LGPL v3 是 GPL v3 加上在这种情况下可以忽略的额外权限。由于 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 不兼容的库链接。这意味着：如果您正在编写代码并将其依据 GPL 发布，您可以声明一个 明确例外 （ explicit exception ） ，允许将其链接到与 GPL 不兼容的程序。如果您依据 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 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据GNU许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 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 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据GNU许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 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 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 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 许可证 通知 （ 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 如何适用于字体？字体许可是一个复杂的问题，需要认真考虑。以下许可证例外是试验性的，但被批准用于一般用途。我们欢迎关于这个问题的建议——请参阅这个解释性文章，并写邮件到 licensing@gnu.org 。要使用此例外，请将该文本添加到软件包中的每个文件的许可证通知中（尽可能），在文本末尾说明该文件依据 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 -- 在指定的行或函数处设置断点，缩写为 binfo breakpoints -- 打印未删除的所有断点，观察点和捕获点的列表，缩写为 i bdisable -- 禁用断点，缩写为 disenable -- 启用断点clear -- 清除指定行或函数处的断点delete -- 删除断点，缩写为 dtbreak -- 设置临时断点，参数同 break，但在程序第一次停住后会被自动删除watch -- 为表达式（或变量）设置观察点，当表达式（或变量）的值有变化时，暂停程序执行step -- 单步跟踪，如果有函数调用，会进入该函数，缩写为 sreverse-step -- 反向单步跟踪，如果有函数调用，会进入该函数next -- 单步跟踪，如果有函数调用，不会进入该函数，缩写为 nreverse-next -- 反向单步跟踪，如果有函数调用，不会进入该函数return -- 使选定的栈帧返回到其调用者finish -- 执行直到选择的栈帧返回，缩写为 finuntil -- 执行直到达到当前栈帧中当前行后的某一行（用于跳过循环、递归函数调用），缩写为 ucontinue -- 恢复程序执行，缩写为 cprint -- 打印表达式 EXP 的值，缩写为 px -- 查看内存display -- 每次程序停止时打印表达式 EXP 的值（自动显示）info display -- 打印早先设置为自动显示的表达式列表disable display -- 禁用自动显示enable display -- 启用自动显示undisplay -- 删除自动显示项help -- 打印命令列表（带参数时查找命令的帮助），缩写为 hattach -- 挂接到已在运行的进程来调试run -- 启动被调试的程序，缩写为 rbacktrace -- 查看程序调用栈的信息，缩写为 btptype -- 打印类型 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 在程序指令的地址处打断点。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 清除指定程序指令的地址处的断点。详见官方文档。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 * 详见官方文档。参考资料Debugging with GDB译者：robot527 校对：mudongliang， wxy
本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据 GNU 许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 GNU 许可证的问题2、对于 GNU 许可证的一般了解2.1 为什么 GPL 允许用户发布其修改版本？自由软件的一个关键特点是用户可以自由合作。绝对有必要允许希望彼此帮助的用户与其他用户分享他们对错误的修复和改进。有些人提出了 GPL 的替代方案，需要原作者批准修改版本。只要原作者持续进行维护，这种做法在实践中可能会不错，但是如果作者停止维护（或多或少会）去做别的事情，或并不打算去满足所有用户的需求，这种替代方案就会失败。除了实践上的问题之外，该方案也不允许用户之间互相帮助。有时候对修改版本的控制，是为了防止用户制作的各种版本之间造成混淆。根据我们的经验，这种混乱不是一个大问题。在 GNU 项目之外出现了许多版本的 Emacs，但用户仍可以将它们区分开。GPL 要求版本创造者将他/她的名字标注其上，以区别于其他版本，并保护其他维护者的声誉。2.2 GPL 是否要求将修改版本的源代码公开发布？GPL 不要求您发布修改后的版本或其中的任何一部分。您可以自由地进行修改并私人使用它们，而无需进行发布。这也适用于组织（包括企业）；组织可以制作修改版本，在内部使用它，并且绝不将修改版本发布到组织之外。但是，如果您以某种方式向公众发布修改后的版本，依据 GPL 许可证，GPL 要求您保证程序的用户可以获得修改后源代码。因此，GPL 给你以某些特定方式发布修改后的程序的授权，而不是以其他方式发布；但是，是否发布修改版本的决定取决于您。2.3 我可以在同一台电脑上安装一个遵循 GPL 许可证的程序和一个不相关的非自由程序吗？可以。2.4 如果我知道某些人有一个遵循 GPL 许可证的程序的副本，我可以要求他们给我一个副本吗？不可以，GPL 给人们制作和再分发程序副本的授权，倘若有人选择这样做的话。那个人也有权选择不去再分发该程序。2.5 GPL v2 中的“ 书面文件 （ written offer ） 对任何第三方有效”是什么意思？ 这是否意味着世界上每个人都可以获得任何遵循 GPL 许可证的程序的源代码？如果您选择通过书面文件提供源代码，那么任何向您索求源代码的人都有权收到。如果您对不附带源代码的二进制文件进行商业分发，GPL 要求您必须提供一份书面文件，表明将稍后分发源代码。当用户非商业性地再分发他们从您那里获取的二进制文件时，他们必须传递这份书面文件的副本。这意味着不能直接从您那里获取二进制文件的人，仍然可以收到源代码副本以及该书面文件。我们要求书面文件对任何第三方有效的原因是，以这种方式间接收到二进制代码的人可以从您那里订购源代码。2.6 GPL v2 中规定，发布后的修改版本必须“授予…所有第三方许可”。这些第三方是谁？第 2 节中规定，依据 GPL，您分发的修改版本必须授权给所有第三方。 “所有第三方”当然是指所有人，但这并不要求您为他们做任何事情。这仅仅意味着他们依据 GPL 从您那里获得了您的修改版本的许可。2.7 GPL 允许我出售程序的副本以获利吗？是的，GPL 允许每个人这样做。销售副本的权利是自由软件定义的一部分。除了一种特殊情况之外，对您可以收取什么样的价格是没有限制的。（这种例外情况是：二进制版本必须附有表明将提供源代码的书面文件。）2.8 GPL 允许我从我的分发网站收取下载程序的费用吗？允许。您可以对您分发程序副本收取任何您想收取的费用。如果您通过下载分发二进制文件，则必须提供“等同的访问权限”来让人们下载源代码，因此，下载源代码的费用可能不会超过下载二进制文件的费用。2.9 GPL 允许我要求任何接收软件的人必须向我支付费用和/或通知我吗？不允许。实际上，这样的要求会使程序变成非自由软件。如果人们在获得程序副本时必须支付费用，或者他们必须特别通知任何人，那么这个程序就不是自由软件。请参阅自由软件的定义。GPL 是自由软件许可证，因此允许人们使用甚至再分发软件，而不需要向任何人支付费用。您可以向用户收取费用，以获取您的副本。当他们从别人那里获得副本时，您不能要求人们向您支付费用。2.10 如果我收费分发遵循 GPL 的软件，我是否还需要向公众免费提供？不需要。不过，如果有人向您支付费用并获得副本，GPL 给予他们免费或收费向公众发布的自由。例如，有人可以向您支付费用，然后把他的副本放在一个网站上，让公众去获取。2.11 GPL 允许我根据保密协议分发副本吗？不允许。GPL 规定，任何从您那里获取副本的人都有权再分发已修改或未修改的副本。您不得在任何更严格的基础上分发作品。如果有人要求您签署保密协议（NDA），以获取来自 FSF 的遵循 GPL 的软件，请立即通知我们 mailto:license-violation@fsf.org。如果违规行为涉及其他版权所有者的遵循 GPL 的代码，请通知该版权所有者，就像您对其他任何类型的 GPL 违规行为所做的工作一样。2.12 GPL 允许我根据保密协议分发程序的修改版或测试版吗？不可以。GPL 规定，您的修改版本必须具备 GPL 中规定的所有自由。因此，从您那里获取您的版本副本的任何人都有权再分发该版本的副本（已修改或未修改）。您不得在更严格的基础上分发该作品的任何版本。2.13 GPL 是否允许我根据保密协议开发程序的修改版本？可以。例如，您可以接受一份合同来开发修改版本，并同意不得发布您的修改版本，直到客户同意才可以发布。这是允许的，因为这种情况下不处于 GPL 协议之下的代码是依据 NDA 分发的。您还可以依据 GPL 将您的修改版本发布给客户，但须同意不将其发布给其他任何人，除非客户同意。也同样在这种情况下，不处于 GPL 协议之下的代码是以保密协议或任何其他限制条款分发的。GPL 将给予客户再分发您的版本的权利。在这种情况下，客户可能会选择不行使这项权利，但他确实拥有这项权利。2.14 为什么 GPL 要求程序的每个副本必须包含 GPL 许可证副本？作品包含许可证副本至关重要，因此获得程序副本的每个人都可以知道他们的权利是什么。包括一个指向许可证的 URL，而不是将许可证本身包含在内，这是一种看起来很诱人的做法。但是您不能确定该 URL 在五年或十年后仍然有效。二十年后，我们今天所知道的 URL 们可能已不复存在。不管网络将发生什么样的变化，确保拥有该程序副本的人员能够继续看到 GPL 许可证的唯一方法是，将许可证的副本包含在该程序中。2.15 如果作品不是很长，那该怎么办？如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行，那么您可以使用一个宽松的许可证，而不是像 GNU GPL这样的 Copyleft 许可证（除非代码特别重要）。我们建议这种情况使用 Apache License 2.0。2.16 我是否需要将我对遵循 GPL 的程序所做的修改声明版权？您不需要对您的修改声明版权。不过，在大多数国家/地区，默认情况下会自动获得版权，因此，如果您不希望修改受到版权限制，您需要将修改明显地放置于公有领域。无论您是否对您的修改声明版权，依据 GPL，您都必须将修改版本作为整体发布（参见：2.2 GPL 是否要求将修改版本的源代码公开发布？）。2.17 GPL 对于将某些代码翻译成不同的编程语言是如何规定的？根据著作权法，翻译工作被认为是一种修改。因此，GPL 对修改版本的规定也适用于翻译版本。2.18 如果一个程序将公有领域代码与遵循 GPL 的代码相结合，我可以取出公有领域的部分，并作为公有领域代码来使用吗？您可以这样做，如果您能弄清楚哪个部分是公有领域的部分，并将其与其他部分区分开。如果代码曾经由其开发人员放置在公有领域，那么它就是公有领域代码，无论它现在究竟在哪里。2.19 我想要因我的作品获得声誉。我想让人们知道我写了什么，如果我使用 GPL，我还能获得声誉吗？您一定能获得这份作品的声誉。遵循 GPL 发布的程序的一部分是以您自己名义撰写的版权声明（假设您是版权所有者）。GPL 要求所有副本携带恰当的版权声明。2.20 GPL 允许我添加条款，要求在使用遵循 GPL 的软件或其输出物的研究论文中包含引用或致谢吗？不可以，根据 GPL 的规定，这是不允许的。虽然我们认识到适当的引用是学术出版物的重要组成部分，但引用不能作为对 GPL 的附加要求。对使用 GPL 软件的研究论文要求包含引用，超出了 GPL v3 第 7（b）条中可接受的附加要求，因此将被视为对 GPL 第 7 节的额外限制。而且版权法也不允许您在软件的输出物中设置这样的要求，无论该软件是依据 GPL 还是其他许可证的条款获得许可。2.21 为了节省空间，我是否可以省略 GPL 的引言部分，或者省略如何在自己的程序上使用GPL的 指导 （ instructions ） 部分吗？引言和指导是 GNU GPL 的组成部分，不能省略。事实上，GPL 是受版权保护的，其许可证规定只能逐字复制整个 GPL。（您可以使用法律条款制作另一个许可证，但该许可证不再是 GNU GPL。）引言和指导部分共约 1000 字，不到 GPL 总文字数量的 1/5。除非软件包本身很小，否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下，您可以使用一个简单的 全权 （ all-permissive ） 许可证，而不是 GNU GPL。2.22 两个许可证“兼容”是指什么？为了将两个程序（或它们的实质部分）组合成一个更大的作品，您需要有以组合方式使用这两个程序的权限。如果两个程序的许可证允许这种使用方式，则它们是兼容的。如果没有办法同时满足这两个许可证，则它们是不兼容的。对于一些许可证，组合的方式可能会影响它们是否兼容，例如，它们可能允许将两个模块链接在一起，但不允许将其代码合并到一个模块中。如果您只想在同一个系统中安装两个独立的程序，那么它们的许可证并不是必须兼容的，因为它们没有组合成更大的作品。2.23 许可证与 GPL 兼容是什么意思？这意味着其他许可证和 GNU GPL 兼容；在一个更大的程序中，您可以将根据其他许可证发布的代码与根据 GNU GPL 发布的代码进行组合。所有 GNU GPL 版本都允许进行这种组合；它们还允许分发这些组合，只要该组合在相同的 GNU GPL 版本下发布。其他许可证如果允许这样做，则其与 GPL 兼容。与 GPL v2 相比，GPL v3 与更多的许可证兼容：它允许您与具有特定类型附加要求（GPL v3 本身不包含）的代码进行组合。GPL v3 第 7 节中有关于此问题的更多信息，包括了允许的附加要求的列表。2.24 为什么原始的 BSD 许可证与 GPL 不兼容？因为它规定了 GPL 不包含的具体要求，即对程序广告的要求。GPL v2 第 6 节规定：您不得对接受者行使本协议授予的权利施加进一步的限制。GPL v3 在第 10 节中提到类似的内容。广告条款正好提供了这样一个限制，因此与 GPL 不兼容。修订的 BSD 许可证没有广告条款，从而消除了这个问题。2.25 “ 聚合 （ aggregate ） ”与其他类型的“修改版本”有什么区别？“聚合”由多个单独的程序组成，分布在同一个 CD-ROM或其他媒介中。GPL 允许您创建和分发聚合，即使其他软件的许可证不是自由许可证或与 GPL 不兼容。唯一的条件是，发布“聚合”所使用的许可证不能禁止用户去行使“聚合”中每个程序对应的许可证所赋予用户的权利。两个单独的程序还是一个程序有两个部分，区分的界限在哪里？这是一个法律问题，最终由法官决定。我们认为，适当的判断标准取决于通信机制（exec、管道、rpc、共享地址空间内的函数调用等）和通信的语义（哪些信息被互换）。如果模块们被包含在相同的可执行文件中，则它们肯定是被组合在一个程序中。如果模块们被设计为在共享地址空间中链接在一起运行，那么几乎肯定意味着它们组合成为一个程序。相比之下，管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。所以当它们用于通信时，模块们通常是单独的程序。但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以视为这两个部分合并成了一个更大的程序。2.26 为什么 FSF 要求为 FSF拥有版权的程序做出贡献的贡献者将版权 分配 （ assign ） 给 FSF？如果我持有 GPL 程序的版权，我也应该这样做吗？如果是，怎么做？ （同1.11）我们的律师告诉我们，为了最大限度地向法院要求违规者强制执行 GPL，我们应该让程序的版权状况尽可能简单。为了做到这一点，我们要求每个贡献者将贡献部分的版权分配给 FSF，或者放弃对贡献部分的版权要求。我们也要求个人贡献者从雇主那里获得版权放弃声明（如果有的话），以确保雇主不会声称拥有这部分贡献的版权。当然，如果所有的贡献者把他们的代码放在公共领域，也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权，只把小规模的修改放在公共领域。如果您想要在您的程序中执行 GPL，遵循类似的策略可能是一个好主意。如果您需要更多信息，请联系mailto:licensing@gnu.org。2.27 如果我使用遵循 GNU GPL 的软件，那么允许我将原始代码修改为新程序，然后在商业上分发和销售新程序吗？您被允许在商业上出售修改程序的副本，但仅限于在 GNU GPL 的条款之下这么做。因此，例如，您必须依照 GPL 所述，使得程序用户可获取源代码，并且，用户也依照 GPL 所述，被允许再分发和修改程序。这些要求是将遵循 GPL 的代码包含在您自己的程序中的条件。2.28 我可以将 GPL 应用于软件以外的其他作品吗？ （同1.6）您可以将 GPL 应用于任何类型的作品，只需明确该作品的“源代码”构成即可。GPL 将“源代码”定义为作品的首选形式，以便在其中进行修改。不过，对于手册和教科书，或更一般地，任何旨在教授某个主题的作品，我们建议使用 GFDL，而非 GPL。2.29 我想依据 GPL 授权我的代码，但我也想明确指出，它不能用于军事和/或商业用途。我可以这样做吗？不可以，因为这两个目标相互矛盾。GNU GPL 被专门设计为防止添加进一步的限制。GPL v3 在第 7 节允许非常有限的一组附加限制，但是用户可以删除任何其他添加的限制。2.30 我可以依据 GPL 来对硬件进行许可吗？任何可以受版权保护的 材料 （ material ） 都可以依据GPL进行许可。GPL v3 也可以用于受其他类似版权法的法律保护的材料，如半导体掩模。因此，作为一个例子，您可以依据 GPL 发布物理对象的图纸或电路。在许多情况下，版权不涵盖依照图纸制作的物理硬件。在这种情况下，无论您使用什么许可证，您对图纸的许可都不能对制造或销售物理硬件施加任何控制。当版权不涵盖利用 IC 掩膜等进行硬件制作时，GPL 能以有效的方式处理这种情况。2.31 将遵循 GPL 的二进制文件 预链接 （ prelinking ） 到系统上的各种库，以优化其性能，将被视为修改吗？不。 预链接 （ prelinking ） 是编译过程的一部分；与编译过程所涉及的其他各个方面相比，预链接没有引入更多的许可证要求。如果您被允许将程序链接到各种库，那么也可以预链接到各种库。如果您分发预链接后的目标码，则需要遵循第 6 节的条款。2.32 LGPL 如何与 Java 配合使用？详情请参阅这篇文章。LGPL 如同被设计、被预想、被期待的那样去工作。2.33 为什么你们在 GPL v3 中发明新的术语“ 传播 （ propagate ） ”和“ 传递 （ convey ） ”？（译者注：convey 这个词汇在一个 GPL 译本中被翻译为“转发”，此处，我们认为“转发”一词在计算机领域存在一定的歧义，因此，采用“传递”的翻译。）GPL v2 中使用的“分发”一词来自美国版权法。多年来，我们了解到，一些司法管辖区在自己的版权法中使用了同一个词，但却给出了不同的含义。我们发明了这些新术语，无论在何处对许可证进行解释，都使我们的意图尽可能清楚。这些新术语没有使用在世界上的任何版权法中，我们直接在许可证中提供了它们的定义。2.34 在GPL v3中的“ 传递 （ convey ） ”与GPL v2中的“ 分发 （ distribute ） ”意思一样吗？是的，差不多是一个意思。在执行 GPL v2 的过程中，我们了解到一些司法管辖区在自己的版权法中使用了“分发”这个词，但给出了不同的含义。我们发明了一个新的术语，以使我们的意图清晰，避免这些差异可能引起的任何问题。2.35 如果我只复制遵循 GPL 的程序并运行它们，而不分发或传递给其他人，许可证对我施加什么要求？没有要求。GPL 不对此活动附加任何条件。 2.36 GPL v3将“向公众提供”作为 传播 （ propagate ） 的一个例子。这是什么意思？ 是提供一种可获取的传递形式吗？“向公众提供”的一个例子是将该软件放在公共网页或FTP服务器上。在您这样做之后，在任何人从您那里真正获取软件之前，可能会需要一段时间，但是由于这种情况可能会立即发生，您也需要能够立即履行 GPL 的义务。因此，我们将“ 传递 （ convey ） ”定义为包括这一活动。2.37 鉴于分发和向公众提供作为传播形式，同样也构成了 GPL v3 中的“ 传递 （ conveying ） ”，那么有哪些传播的例子不构成传递吗？为自己制作软件的副本是不构成“传递”的主要传播形式。您可以依此在多台计算机上安装软件，或进行备份。2.38 GPL v3 如何让 BitTorrent 分发变得更容易？因为 GPL v2 是在软件的点对点分发普及之前编写的，所以当您利用这种方式分享代码时，很难满足 GPL v2 的要求。在 BitTorrent 上分发 GPL v2 目标代码时，确保您合规的最佳方法是将所有相应的源代码包含在相同的 种子文件 （ Torrent ） 中，但这种方式代价高昂。GPL v3 以两种方式解决了这个问题。首先，作为该过程的一部分，下载此种子文件并将数据发送给其他人的人不需要做任何事情。因为第 9 节规定：“受保护作品的辅助传播如果仅仅是使用点对点传输来接收副本，不需要接受[本许可证]。”第二，通过告知接收人在公共网络服务器上哪里可获取，GPL v3 的第 6（e）节旨在给予分发者（最初制作种子文件的人）一种清晰、直观的方式来提供源代码。这样可以确保每个想要获取源代码的人都可以如此获取，而且分发者几乎不用担心。2.39 什么是 TiVo化 （ tivoization ） ？ GPL v3 对此如何防止？一些设备使用可升级的自由软件，但被设计为用户不能修改该软件。有很多不同的方式可以做到这一点；例如，有时硬件校验所安装的软件，如果与预期签名不匹配，则关闭软件。制造商通过提供源代码来遵循GPL v2，但是您仍然无法自由修改您使用的软件。我们称这种做法为 TiVo 化 （ tivoization ） 。当人们分发包含遵循 GPL v3 软件的“ 用户产品 （ User Products ） ”时，第 6 节要求他们为您提供修改该软件所需的信息。“用户产品”是该许可证特别定义的术语；“用户产品”的示例包括便携式音乐播放器、数字录像机和家庭安全系统。2.40 GPL v3 是否禁止 DRM？不禁止，您可以使用遵循 GPL v3 发布的代码来开发您喜欢的任何类型的 DRM 技术。不过，如果您这样做，第 3 节规定，系统不会被视为一种有效的技术“保护”措施，这意味着如果有人破坏了 DRM，他也可以自由分发他的软件，不受《美国数字千禧版权法》（DMCA）和类似法律的限制。像往常一样，GNU GPL 并不限制人们在软件中怎么做，只是阻止他们限制他人。2.41 GPL v3 是否要求投票人能够修改在投票机中运行的软件？不要求。企业分发包含遵循 GPL v3 软件的设备，最多只需要为拥有目标代码副本的人提供软件的源代码和安装信息。使用投票机（如同任何其他信息亭一样）的选民不能拥有它，甚至不能暂时拥有，所以选民也不能拥有二进制软件。不过，请注意，投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由软件，并不意味着您可以信任计算机，并进行投票。我们认为电脑不值得信任，不能被用作投票。投票应在纸上进行。2.42 GPL v3 是否包含“专利报复条款”？实际上，是的。第 10 节禁止传递该软件的人向其他被许可人发起专利诉讼。如果有人这样做，第 8 节解释他们将如何丧失许可证权益以及与之伴随的所有专利许可。2.43 在 GPL v3 和 AGPL v3中，当说到“尽管有本许可证的其他规定”时，是什么意思？这仅仅意味着以下条款胜过许可证中可能与之冲突的其他任何内容。例如，如果没有该文本，有些人可能声称，您不能将遵循 GPL v3 的代码与遵循 AGPL v3 的代码结合在一起，因为 AGPL 的附加要求将被归类为 GPL v3 第 7 节下的“进一步限制”。该文本明确表示我们的预期解释是正确的，您可以进行组合。该文本仅解决许可证不同条款之间的冲突。当两个条件之间没有冲突的时候，您必须同时满足它们。这些段落不允许您轻率地忽略许可证的其余部分，它们只是强调了一些非常有限的例外。2.44 在 AGPL v3 中，怎么才算是“通过计算机网络远程与[软件]进行交互”？如果程序被明确设计为接受用户请求并通过网络发送响应，则它符合这些标准。属于此类程序的常见示例包括网络和邮件服务器、交互式网络应用程序和在线游戏的服务器。如果程序没有被明确设计为通过网络与用户进行交互，而是恰好在这样做的环境中运行，那么它不属于此类。例如，仅仅因为用户通过 SSH 或远程 X 会话来运行的应用程序不需要提供源代码。2.45 GPL v3 中“ 您 （ you ） ”的概念如何与 Apache License 2.0 中“ 法律实体 （ Legal Entity ） ”的定义相比较？它们是完全相同的。Apache License 2.0 中“法律实体”的定义在各种法律协议中是非常标准的，因此，如果法院在缺乏明确定义的情况下没有以同样的方式解释该术语，将会令人非常惊讶。我们完全期待他们在看 GPL v3 时也会如此，并考虑到谁有资格作为被许可人。2.46 在 GPL v3 中，“ 该程序 （ the Program ） ”是指什么？ 是每个依据 GPL v3 发布的程序？术语“该程序”是指依据 GPL v3 进行许可的特定作品，由特定被许可人从上游许可人或分发者那里接收。“该程序”是您在 GPL v3 许可的指定情境下接受到的特定软件作品。“该程序”并不意味着“依据 GPL v3 进行许可的所有作品”；由于一些原因，这种解释没有任何意义。针对那些想要了解更多的人，我们已经发表了对“该程序”一词的分析。2.47 如果某些网络客户端软件依据 AGPL v3 发布，是否必须能够向与之交互的服务器提供源代码？AGPL v3 需要该程序向“所有通过计算机网络进行远程交互的用户”提供源代码。至于您将程序称为“客户端”还是“服务器”，那无关紧要。您需要询问的问题是，是否存在合理的期望让一个人通过网络远程与该程序交互。2.48 对于一个运行在代理服务器上的依据 AGPL 进行许可的软件来说，如何向与该软件交互的用户提供源代码书面文件？对于代理服务器上的软件，您可以通过向此类代理的用户传递消息的常规方法来提供源代码书面文件。例如，Web 代理可以使用登录页。当用户最初开始使用代理时，您可以将他们引导到包含源代码书面文件以及您选择提供的任何其他信息的页面。AGPL 规定，您必须向“所有用户”提供书面文件。如果您知道某个用户已经被展示过书面文件，对于当前版本的软件，您不必再重复向该用户提供。
本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题对于 GNU 许可证的一般了解在您的程序中使用 GNU 许可证依据 GNU 许可证分发程序在编写其他程序时采用依据 GNU 许可证发布的程序将作品与依据 GNU 许可证发布的代码相结合关于违反 GNU 许可证的问题1、关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题1.1 “GPL” 代表什么意思？“GPL” 代表“ 通用公共许可证 （ General Public License ） ”。 最常见的此类许可证是 GNU 通用公共许可证，简称 GNU GPL。 如果人们能够自然而然地将其理解为 GNU GPL，可以进一步缩短为“GPL”。1.2 自由软件是否意味着必须使用 GPL？根本不是的，还有许多其他自由软件许可证。我们有一个不完整的列表。任何为用户提供特定自由的许可证都是自由软件许可证。1.3 为什么我要使用 GNU GPL，而不是其他自由软件许可证？使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本进行竞争的风险。不过，在某些特殊情况下，最好使用一个更宽松的许可证。1.4 所有 GNU 软件都使用 GNU GPL 作为其许可证吗？大多数 GNU 软件包都使用 GNU GPL，但是有一些 GNU 程序（以及程序的一部分）使用更宽松的许可证，例如 LGPL（ 较宽松公共许可证 （ Lesser GPL ） ）。我们这样做是基于战略考虑。1.5 如果一个程序使用 GPL 许可证，是否会使其成为 GNU 软件？任何人都可以依据 GNU GPL 发布一个程序，但并不能使其成为 GNU 软件包。让程序成为 GNU 软件包意味着将其明确地贡献给 GNU 项目。当程序的开发人员和 GNU 项目都同意这样做时，才会发生这种情况。如果您有兴趣向 GNU 项目贡献程序，请写信至 mailto:maintainers@gnu.org 。1.6 我可以将 GPL 应用于软件以外的其他作品吗？您可以将 GPL 应用于任何类型的作品，只需明确该作品的“源代码”构成即可。 GPL 将“源代码”定义为作品的首选形式，以便在其中进行修改。不过，对于手册和教科书，或更一般地，任何旨在教授某个主题的作品，我们建议使用 GFDL，而非 GPL。1.7 手册为什么不使用 GPL 许可证？手册也可以使用 GPL 许可证，但对于手册来说，最好使用 GFDL（ 自由文本授权 （ GNU Free Documentation License ） ）许可证。GPL 是为软件程序设计的，它包含许多复杂的条款，对于程序来说至关重要；但对于图书或手册来说，这将是麻烦和不必要的。例如，任何人如果（以 GPL ）出版纸质图书，就要么必须为每份印刷版本配置该图书的机器可读形式“源代码”，或提供书面文件，表明将稍后发送“源代码”。同时，GFDL 中包含了帮助免费手册的出版商从销售副本中获利的条款，例如，出售封面文字。 背书 （ Endorsements ） 部分的特殊规则使得 GFDL 可以作为官方标准。修改版本的手册是被允许的，但该修改版本不能被标记为“该标准”。使用 GFDL，我们允许对手册中涵盖其技术主题的文本进行修改。能够修改技术部分非常重要，因为修改程序的人理所当然地要去修改对应的文档。人们有这样做的自由，它是一种道德责任。我们的手册还包括阐述我们对自由软件政治立场的部分。我们将它们标记为 “不变量” （ invariant ） ，使得它们不被更改或删除。 GFDL 中也为这些“不变部分”做出了规定。1.8 GPL 被翻译成其他语言了吗？将 GPL 翻译成英文以外的语言将是有用的。人们甚至进行了翻译，并将文本发送给我们。但我们不敢将翻译文本批准为正式有效。其中的风险如此之大，以至于我们不敢接受。法律文件在某种程度上就像一个程序。翻译它就像将程序从一种语言和操作系统转换到另一种语言。只有同时熟练使用这两种语言的律师才能做到这一点——即便如此，也有引入错误的风险。如果我们正式批准 GPL 的翻译文本，我们将不得不给予所有人许可，让他们可以去做翻译文本规定可以做的任何事情。如果这是一个完全准确的翻译，那没关系。但如果翻译错误，后果可能是我们无法解决的灾难。如果一个程序有 bug，我们可以发布一个新的版本，最终旧版本将会逐渐消失。但是，一旦我们给予每个人去根据特定翻译文本行事的许可，如果我们稍后发现它有一个错误，我们无法收回该权限。乐意提供帮助的人有时会为我们做翻译工作。如果问题是要找人做这个工作的话，那问题就解决了。但实际的问题是错误的风险，做翻译工作不能避免风险。我们无法授权非律师撰写的翻译文本。因此，目前我们并不认可GPL的翻译文本是全球有效和具有约束力的。相反，我们正在做两件事情：将非正式的翻译指引给人们。这意味着我们允许人们进行GPL的翻译，但是我们不认可翻译文本具有法律效力和约束力。 未经批准的翻译文本没有法律效力，应该如此明确地表述。翻译文本应标明如下：This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English). 本 GPL 翻译文本是非正式的，没有被自由软件基金会（FSF）正式批准为有效。若要完全确定何种行为被允许，请参阅原始 GPL（英文）。但未经批准的翻译文本可以作为如何理解英文 GPL 的参考。对于许多用户来说，这就足够了。不过，在商业活动中使用 GNU 软件的企业，以及进行公共 ftp 发行的人员，需要去核查实际的英文 GPL，以明确其允许的行为。发布仅在单个国家/地区有效的翻译文本。 我们正在考虑发布仅在单个国家正式生效的翻译文本。这样一来，如果发现有错误，那么错误将局限于这个国家，破坏力不会太大。 即便是一个富有同情心和能力的律师来做翻译，仍然需要相当多的专门知识和努力，所以我们不能很快答应任何这样的翻译。1.9 为什么有一些 GNU 库依据普通 GPL 而不是 LGPL 来发布？对于任何特定库使用 LGPL 构成了自由软件的倒退。这意味着我们部分放弃了捍卫用户自由权利的努力，对基于 GPL 软件所构建产品的分享要求也降低了。在它们自身而言，这是更糟糕的变化。有时一个小范围的倒退是很好的策略。某种情况下，使用 LGPL 的库可能会带来该库的广泛使用，从而进一步改善该库，为自由软件带来更广泛的支持，诸如此类。如果在相当大的程度上出现这种情况，这可能对自由软件很有好处。但它发生的几率有多少呢？我们只能推测。在每个库上用一段时间的 LGPL，看看它是否有帮助，如果 LGPL 没有帮助，再将其更改为 GPL。这种做法听起来很好，但却是不可行的。一旦我们对特定库使用了 LGPL，那就很难进行改变。因此，我们根据具体情况决定每个库使用哪个许可证。对于我们如何判断该问题，有一段很长的解释。1.10 谁有权力执行 GPL 许可证？由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循GPL的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”1.11 为什么 FSF 要求为 FSF 拥有版权的程序做出贡献的贡献者将版权 分配 （ assign ） 给 FSF？如果我持有 GPL 程序的版权，我也应该这样做吗？如果是，怎么做？我们的律师告诉我们，为了最大限度地向法院要求违规者强制执行 GPL，我们应该让程序的版权状况尽可能简单。为了做到这一点，我们要求每个贡献者将贡献部分的版权分配给 FSF，或者放弃对贡献部分的版权要求。我们也要求个人贡献者从雇主那里获得版权放弃声明（如果有的话），以确保雇主不会声称拥有这部分贡献的版权。当然，如果所有的贡献者把他们的代码放在公共领域，也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权，只把小规模的修改放在公共领域。如果您想要在您的程序中执行 GPL，遵循类似的策略可能是一个好主意。如果您需要更多信息，请联系 mailto:licensing@gnu.org。1.12 我可以修改 GPL 并创建一个修改后的许可证吗？您可以制作GPL的修改版本，但这往往会产生实践上的后果。您可以在其他许可证中合法使用GPL条款（可能是修改过的），只要您以其他名称来称呼您的许可证，并且不包括 GPL 的 引言 （ preamble ） ，只要您对最后的使用说明进行了足够多的修改，使其措辞明显不同，没有提到 GNU（尽管您描述的实际过程可能与其类似）。如果您想在修改后的许可证中使用我们的引言，请写信至 mailto:licensing@gnu.org，以获得许可。我们需要查看实际的许可证要求，才能决定我们是否能够批准它们。虽然我们不会以这种方式对您修改许可证提出法律上的反对意见，但我们希望您三思而行，别去修改许可证。类似这些修改后的许可证几乎肯定与 GNU GPL 不兼容，并且这种不兼容性阻碍了模块之间的有用组合。不同自由软件许可证的扩散本身就是一个负担。请使用 GPL v3 提供的 例外 （ exception ） 机制，而不是去修改 GPL。1.13 为什么你们决定将 GNU Affero GPL v3 作为一个单独的许可证？GPLv3 的早期草案在第 7 节中允许许可人在发布源代码时添加一个类似 Affero 的要求。但是，一些开发和依赖自由软件的公司认为这个要求太过繁重。他们希望避免使用遵循这个要求的代码，并且对检查代码是否符合这个附加要求所带来的管理成本表示担忧。通过将 GNU Affero GPL v3 作为单独的许可证发布，在该许可证以及 GPL v3 中允许遵循该许可证的代码链接到彼此，我们完成了所有最初的目标，同时更容易确定哪些源代码需要遵循发布要求。（题图：pycom.io）译者：薛亮，北京集慧智佳知识产权管理咨询股份有限公司互联网事业部高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。