GNU GPL 许可证常见问题解答（六）

会员服务 ·

GNU GPL 许可证常见问题解答（六） | Linux 中国

2018 年 7 月 11 日 Linux中国

致谢

转载自　|　
https://www.gnu.org/licenses/gpl-faq.html
　作者　|　Fsf

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

☉ 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题 [2]

☉ 对于 GNU 许可证的一般了解 [3]

☉ 在您的程序中使用 GNU 许可证 [4]

☉ 依据GNU许可证分发程序 [5]

☉ 在编写其他程序时采用依据 GNU 许可证发布的程序 [6]

☉ 将作品与依据 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 v2	GPL v2 或更高版本	GPL v3 或更高版本	仅 LGPL v2.1	LGPL 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 程序动态链接。这些库也与解释器联系在一起。如果解释器与这些库静态链接，或者如果它被设计为与这些特定库动态链接[7]，那么也需要以与 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，允许它们与这些程序进行链接。但是，如果这只是你的打算的话，最好明确地这么说。

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

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

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

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。但是，您可以通过向插件的许可证添加例外声明来解决该法律问题，并允许将其与非自由主程序链接。

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

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

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

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

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

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

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 软件与和其不兼容库的问题[10]。

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。在这两种情况下，您应该将此文本放在您授予此权限的每个文件中。

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

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

如果您使用 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[11]，因此对自由软件世界的贡献为零。

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 通常的方式接收源代码。

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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。