关于 GNU GPL v2.0 的常见问题解答 - GNU 项目

关于 GNU GPL 第 2 版的常见问题解答

本页面包含关于 GNU 通用公共许可证 (GPL) 第 2 版的常见问题解答。当前版本的 GPL 的常见问题解答请参见这里。要了解有关自由软件基金会的其他许可证的更多信息，请参阅我们的许可证页面。

阅读完本常见问题解答后，您可以通过我们的测验来测试您对自由软件许可的了解。

关于 GPL、GNU 项目和自由软件基金会的基本问题
对 GPL 的一般理解
在您的程序中使用 GPL
根据 GPL 发布程序的发行
在编写其他程序时使用根据 GPL 发布的程序
将工作与根据 GPL 发布的代码相结合
关于违反 GPL 的问题

“GPL” 代表 “通用公共许可证”。最广泛使用的此类许可证是 GNU 通用公共许可证，简称 GNU GPL。当人们理解此处指的是 GNU GPL 时，可以进一步简称为 “GPL”。

自由软件意味着使用 GPL 吗？

完全不是——还有许多其他的自由软件许可证。我们有一个不完整的列表。任何向用户提供某些特定自由的许可证都是自由软件许可证。

为什么我应该使用 GNU GPL 而不是其他自由软件许可证？

使用 GNU GPL 将要求所有发布的改进版本都是自由软件。这意味着您可以避免与您自己作品的专有修改版本竞争的风险。但是，在某些特殊情况下，最好使用更宽松的许可证。

所有 GNU 软件都使用 GNU GPL 作为其许可证吗？

大多数 GNU 软件包都使用 GNU GPL，但是有一些 GNU 程序（和程序的部分）使用较宽松的许可证，例如 Lesser GPL。当我们这样做时，这是一个策略问题。

将 GPL 用于程序会使其成为 GNU 软件吗？

任何人都可以根据 GNU GPL 发布程序，但这并不意味着它是一个 GNU 软件包。

使该程序成为 GNU 软件包意味着明确地为 GNU 项目做出贡献。只有当程序的开发人员和 GNU 项目同意这样做时才会发生。如果您有兴趣为 GNU 项目贡献程序，请致信 <[email protected]>。

如果我发现可能违反 GPL 的行为，我应该怎么做？

为什么 GPL 允许用户发布其修改版本？

自由软件的一个关键方面是用户可以自由地合作。绝对必须允许希望互相帮助的用户与其他用户共享他们的错误修复和改进。

有些人提出了 GPL 的替代方案，要求修改后的版本必须经过原始作者。只要原始作者能够满足维护的需求，这在实践中可能会运作良好，但是如果作者停止（或多或少）去做其他事情或不关注所有用户的需求，此方案就会失效。除了实际问题外，该方案不允许用户互相帮助。

有时，对修改版本的控制被提议为防止用户制作的各种版本之间混淆的一种手段。根据我们的经验，这种混淆不是一个主要问题。GNU 项目之外已经制作了许多 Emacs 版本，但是用户可以区分它们。GPL 要求版本的制作者在其上署名，以将其与其他版本区分开来，并保护其他维护者的声誉。

GPL 是否要求将修改版本的源代码发布到公众？

GPL 不要求您发布修改后的版本。您可以自由地进行修改并私下使用它们，而无需发布它们。这也适用于组织（包括公司）；一个组织可以进行修改后的版本并在内部使用，而无需在组织外部发布它。

但是，如果您以某种方式向公众发布修改后的版本，则 GPL 要求您以 GPL 的形式向程序的用户提供修改后的源代码。

因此，GPL 允许以某些方式发布修改后的程序，而不是以其他方式发布；但是，是否发布该版本的决定由您决定。

我可以在同一台计算机上拥有一个受 GPL 保护的程序和一个不相关的非自由程序吗？

是的。GPL 中的 “单纯聚合” 条款明确说明了此权限，但这仅加强了我们认为无论如何都是正确的观点。

如果我知道某人拥有受 GPL 保护的程序的副本，我可以要求他给我一个副本吗？

否。GPL 允许他在他选择这样做时制作和重新分发该程序的副本。当他选择不重新分发该程序时，他也有权不重新分发该程序。

这个“对任何第三方都有效的书面要约”是什么意思？这是否意味着世界上每个人都可以获得任何 GPL 许可的程序的源代码，无论如何？

如果您选择通过书面报价提供源代码，那么任何向您索取源代码的人都有权接收它。

如果您以商业方式分发没有附带源代码的二进制文件，则 GPL 表示您必须提供书面报价，以便以后分发源代码。当用户以非商业方式重新分发他们从您那里收到的二进制文件时，他们必须传递此书面报价的副本。这意味着没有直接从您那里获得二进制文件的人仍然可以收到源代码的副本以及书面报价。

我们要求报价对任何第三方都有效的原因是为了使以这种方式间接收到二进制文件的人可以向您订购源代码。

GPL 规定，修改后的版本如果发布，必须“许可……给所有第三方”。这些第三方是谁？

第 2 节说，您分发的修改后的版本必须根据 GPL 许可给所有第三方。“所有第三方” 指的是绝对的每个人——但这不要求您为他们做任何实际的事情。这仅表示他们从您那里获得了 GPL 下的版本许可。

我是否需要在对受 GPL 保护的程序进行的修改中声明版权？

您不需要声明对您的更改拥有版权。但是，在大多数国家/地区，这通常会自动发生，因此如果您不希望它们受到版权保护，则需要明确地将您的更改放入公共领域。

无论您是否声明对您的更改拥有版权，无论哪种方式，您都必须在 GPL 下发布整个修改后的版本。（如果您发布了修改后的版本）

如果一个程序将公共领域代码与受 GPL 保护的代码结合在一起，我是否可以将公共领域部分作为公共领域代码使用？

如果您可以弄清楚哪部分是公共领域部分并将其余部分分开，则可以这样做。如果代码是由其开发者放入公共领域的，那么无论它在哪里，它都属于公共领域。

GPL 是否允许我出售该程序的副本以获取报酬？

是的，GPL 允许每个人都这样做。出售副本的权利是自由软件定义的一部分。除非在一种特殊情况下，否则您可以收取的费用没有限制。（一个例外是，必须附带仅二进制发布的源代码的书面报价。）

GPL 是否允许我收取从我的分发站点下载该程序的费用？

是的。您可以为分发该程序的副本收取任何您想要的费用。如果您通过下载分发二进制文件，则必须提供下载源代码的 “等效访问”——因此，下载源代码的费用不得高于下载二进制文件的费用。

GPL 是否允许我要求任何接收该软件的人必须向我支付费用和/或通知我？

否。实际上，这样的要求会使程序变为非自由的。如果人们在获得程序的副本时必须付费，或者如果他们必须通知任何特定的人，那么该程序不是自由的。请参阅自由软件的定义。

GPL 是一种自由软件许可证，因此它允许人们使用甚至重新分发该软件，而无需为此向任何人支付费用。

您可以向人们收取费用以从您那里获取副本。您不能要求人们在从其他人那里获得副本时向您付费。

如果我付费分发 GPL 许可的软件，是否也必须免费向公众提供？

否。但是，如果有人支付您的费用并获得了副本，则 GPL 会赋予他们向公众发布该副本的自由，无论是否收取费用。例如，有人可以支付您的费用，然后将其副本放在网站上供公众使用。

GPL 允许我在保密协议下分发副本吗？

不是。GPL规定，任何从你那里收到副本的人都有权再分发副本，无论是否经过修改。你不允许以更具限制性的方式分发该作品。

如果有人要求你签署保密协议（NDA）才能接收自由软件基金会（FSF）拥有版权的GPL许可软件，请立即写信至[email protected]通知我们。

GPL 是否允许我在保密协议下分发修改后的或测试版本？

不是。GPL规定，你的修改版本必须保留GPL中声明的所有自由。因此，任何从你那里收到你的版本副本的人都有权再分发该版本的副本（无论是否经过修改）。你不得以更具限制性的方式分发该作品的任何版本。

GPL 是否允许我在保密协议下开发修改后的版本？

是的。例如，你可以接受开发变更的合同，并同意在客户同意之前不发布你的变更。这是允许的，因为在这种情况下，没有GPL许可的代码在保密协议下分发。

你也可以根据GPL将你的变更发布给客户，但同意在客户同意之前不将其发布给其他人。在这种情况下，也没有GPL许可的代码在保密协议或任何其他限制下分发。

GPL将赋予客户再分发你的版本的权利。在这种情况下，客户可能会选择不使用该权利，但他们拥有该权利。

我想为我的工作获得荣誉。我想让人们知道我写了什么。如果我使用 GPL，我还能获得荣誉吗？

为什么 GPL 要求在程序的每个副本中都包含 GPL 副本？

将许可证副本与作品一起提供至关重要，这样每个获得该程序副本的人都可以知道他的权利是什么。

很可能你会想包含一个指向许可证的URL，而不是许可证本身。但是你无法确定该URL在五年或十年后仍然有效。二十年后，我们今天所知的URL可能不再存在。

确保拥有程序副本的人，无论网络发生什么变化，都能够继续查看许可证的唯一方法是在程序中包含许可证的副本。

如果作品的长度不比许可证本身长多少怎么办？

如果一个单独的程序如此短小，你最好使用一个简单的全许可许可证，而不是GNU GPL。

为了节省空间，我可以省略 GPL 的序言，或者关于如何在您自己的程序上使用它的说明吗？

序言和说明是GNU GPL的组成部分，不得省略。事实上，GPL受版权保护，其许可证仅允许逐字复制整个GPL。（你可以使用法律条款来创建另一个许可证，但它不会是GNU GPL。）

序言和说明加起来大约有5000个字符，不到GPL总大小的1/3。除非软件包本身很小，否则它们不会使软件包的大小发生实质性的变化。在这种情况下，你最好使用简单的全许可许可证，而不是GNU GPL。

说两个许可证“兼容”是什么意思？

为了将两个程序（或其大部分）组合成更大的作品，你需要获得以这种方式使用这两个程序的许可。如果这两个程序的许可证允许这样做，则它们是兼容的。如果没有办法同时满足两个许可证，则它们是不兼容的。

对于某些许可证，组合的方式可能会影响它们是否兼容——例如，它们可能允许将两个模块链接在一起，但不允许将其代码合并到一个模块中。

仅仅为了在同一系统中安装两个单独的程序，其许可证不必兼容，因为这不会将它们组合成更大的作品。

说一个许可证“与GPL兼容”是什么意思？

这意味着另一个许可证和GNU GPL是兼容的；你可以将根据另一个许可证发布的代码与根据GNU GPL发布的代码组合到一个更大的程序中。

GPL允许这种组合，前提是它根据GNU GPL发布。如果另一个许可证也允许这样做，则它与GPL兼容。

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

如果你这样做，你的程序将无法在自由环境中完全使用。如果你的程序依赖于非自由库来完成某项工作，则它无法在自由世界中完成该工作。如果它依赖于非自由库才能运行，则它不能成为GNU等自由操作系统的一部分；它完全被自由世界禁止使用。

因此请考虑：你是否可以找到一种方法在不使用此库的情况下完成工作？你是否可以为该库编写一个自由的替代品？

如果该程序已经使用非自由库编写，那么可能为时已晚，无法更改该决定。你最好按原样发布该程序，而不是不发布它。但是请在README中提及需要非自由库是一个缺点，并建议更改程序以在不使用非自由库的情况下完成相同的工作。请建议任何打算对该程序进行大量进一步工作的人首先使其摆脱对非自由库的依赖。

请注意，将某些非自由库与GPL许可的自由软件结合使用也可能存在法律问题。有关更多信息，请参阅关于带有GPL不兼容库的GPL软件的问题。

如果我将 GPL 不兼容的库与 GPL 软件一起使用，会出现哪些法律问题？

如果你链接的库属于GPL中的以下例外

但是，作为一种特殊的例外，分发的源代码不必包括通常（以源代码或二进制形式）与可执行文件运行所在的操作系统主要组件（编译器，内核等）一起分发的任何内容，除非该组件本身随可执行文件一起提供。

那么你无需执行任何特殊操作即可使用它们；对整个程序分发源代码的要求不包括这些库，即使你分发包含它们的链接可执行文件。因此，如果你需要的库来自专有操作系统的主要部分，则GPL表示人们可以将你的程序与它们链接，而没有任何条件。

版权所有 (C) yyyy <版权所有者的姓名>
本程序是自由软件；你可以根据自由软件基金会发布的GNU通用公共许可证条款重新分发和/或修改它；无论是许可证的第 2 版还是（由你选择）任何更高版本。
分发本程序是为了希望它有用，但不作任何保证；甚至不保证适销性或适用于特定目的的隐含保证。有关更多详细信息，请参阅 GNU 通用公共许可证。
你应该已收到与本程序一起的 GNU 通用公共许可证的副本；如果没有，请参阅 <https://gnu.ac.cn/licenses/>。

将ABC静态或动态地与其他模块链接正在制作基于ABC的组合作品。因此，GNU通用公共许可证的条款和条件涵盖了整个组合。

此外，作为一项特殊的例外，ABC的版权所有者允许你将ABC程序与根据GNU LGPL发布的自由软件程序或库以及DEF在XYZ许可下标准版本中包含的代码（或此类代码的修改版本，许可不变）组合。你可以按照GNU GPL对于ABC和相关其他代码的许可条款复制和分发此类系统，前提是你包含GNU GPL要求分发源代码时和分发源代码时所涉及的其他代码的源代码。

请注意，对ABC进行修改的人员没有义务为他们的修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU 通用公共许可证允许发布没有此例外的修改版本；此例外还使发布带有此例外的修改版本成为可能。

你应该将此文本放入应用例外的每个文件中。

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

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

为了根据 GPL 发布我的程序，我如何获得该程序的版权？

根据伯尔尼公约，从任何作品以固定形式出现时起，所有书面作品都会自动获得版权。因此，你无需做任何事情来“获得”你所写内容的版权——只要没有人能声称拥有你的作品。

但是，在美国注册版权是一个非常好的主意。它将使你在美国处理侵权者时更有影响力。

如果某人可能会声称拥有版权，那么当你是一名雇员或学生时；那么雇主或学校可能会声称你为他们做了这项工作，并且版权属于他们。他们是否拥有有效的索赔权取决于你所居住地的法律、你的雇佣合同以及你所从事的工作类型等情况。如果有任何疑问，最好咨询律师。

如果你认为雇主或学校可能对你的作品提出版权主张，你可以让公司或学校的适当授权官员签署一份版权免责声明，从而明确解决这个问题。（你的直属上司或教授通常没有资格签署此类免责声明。）

如果我的学校可能想把我的程序变成它自己的专有软件产品怎么办？

如今，许多大学试图通过限制其开发的知识和信息的使用来筹集资金，实际上与商业公司的行为没什么不同。（关于这个问题及其影响的全面讨论，请参阅《大西洋月刊》2000年3月号的“被束缚的大学”一文。）

如果你认为你的学校可能会拒绝允许你的程序以自由软件的形式发布，最好尽早提出这个问题。程序越接近可用的状态，管理部门就越有可能想把你手中的程序拿走并在没有你的情况下完成它。在早期阶段，你拥有更多的筹码。

因此，我们建议你在程序完成一半时就去找他们，说：“如果你们同意以自由软件的形式发布这个程序，我就会完成它。”不要把这看作是虚张声势。要取得成功，你必须有勇气说：“我的程序要么自由，要么永远不会诞生。”

您能否给我逐步说明如何将 GPL 应用于我的程序？

请参阅 GPL 指南页面。

我听说有人以其他许可证获得了 GPL 许可的程序的副本。这有可能吗？

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

GPL 覆盖的程序的开发者是否受 GPL 约束？开发者的行为是否会违反 GPL？

严格来说，GPL 是开发者授权他人使用、分发和更改程序的许可证。开发者本身不受其约束，因此无论开发者做什么，都不会“违反” GPL。

但是，如果开发者做了其他人做会违反 GPL 的事情，开发者肯定会在社区中失去道德地位。

根据 GPL 分发程序的开发人员是否可以在以后将该程序许可给另一方以供独占使用？

不，因为公众已经拥有在 GPL 下使用该程序的权利，并且该权利不能被撤销。

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

是的，因为编辑器和工具的版权不涵盖你编写的代码。使用它们在法律上不会对你用于代码的许可证施加任何限制。

一些程序出于技术原因将其自身的部分内容复制到输出中——例如，Bison 将标准解析器程序复制到其输出文件中。在这种情况下，输出中复制的文本受与源代码中相同的许可证约束。同时，输出中从程序输入派生的部分继承输入的版权状态。

碰巧的是，Bison 也可以用于开发非自由程序。这是因为我们决定明确允许在 Bison 输出文件中无限制地使用 Bison 标准解析器程序。我们做出这个决定是因为有其他与 Bison 类似的工具已经允许用于非自由程序。

我在使用 GPL 许可程序的源代码时是否具有“合理使用”权利？

是的，你可以。“合理使用”是指在无需特殊许可的情况下允许使用的行为。由于你无需开发者的许可即可进行此类使用，因此无论开发者在许可证或其他地方如何说，你都可以这样做——无论该许可证是 GNU GPL 还是任何其他自由软件许可证。

但是请注意，没有全球通用的合理使用原则；哪些类型的使用被认为是“合理的”因国家/地区而异。

美国政府可以根据 GNU GPL 发布程序吗？

如果程序是由美国联邦政府雇员在其工作期间编写的，则该程序属于公共领域，这意味着它不受版权保护。由于 GNU GPL 基于版权，因此不能在 GNU GPL 下发布此类程序。（但它仍然可以是自由软件；公共领域程序是自由的。）

但是，当美国联邦政府机构使用承包商开发软件时，情况就不同了。合同可以要求承包商在 GNU GPL 下发布它。（GNU Ada 就是以这种方式开发的。）或者，合同可以将版权分配给政府机构，然后该机构可以在 GNU GPL 下发布该软件。

美国政府可以发布对 GPL 许可程序的改进吗？

是的。如果改进是由美国政府雇员在其工作期间编写的，则改进属于公共领域。但是，改进后的版本作为一个整体仍然受 GNU GPL 的约束。这种情况没有问题。

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

有没有什么办法可以让我根据使用我的程序获得的结果进行 GPL 许可？例如，如果我的程序用于开发硬件设计，我是否可以要求这些设计必须是自由的？

一般来说，这在法律上是不可能的；版权法不允许你对人们使用你的程序从他们的数据中生成的输出提出任何要求。如果用户使用你的程序来输入或转换他自己的数据，则输出的版权属于他，而不属于你。更一般地说，当程序将其输入转换为某种其他形式时，输出的版权状态继承自生成它的输入的版权状态。

因此，你对输出的使用拥有发言权的唯一方式是，输出的实质性部分（或多或少）是从你的程序中的文本复制的。例如，如果我们没有在这个特定情况下做出例外，那么 Bison 的部分输出（见上文）将受 GNU GPL 的约束。

你可以人为地使程序将某些文本复制到其输出中，即使没有技术原因这样做。但是，如果复制的文本没有实际用途，用户可以简单地从输出中删除该文本，而仅使用其余部分。然后，他就不必遵守有关复制文本的重新分发的条件。

在哪些情况下，GPL 程序的输出也受 GPL 保护？

仅当程序将其自身的一部分复制到输出中时。

如果我向 GPL 许可的程序添加一个模块，我是否必须使用 GPL 作为我的模块的许可证？

GPL 表示整个组合程序必须在 GPL 下发布。因此，你的模块必须在 GPL 下可用。

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

如果一个库是根据 GPL（而不是 LGPL）发布的，这是否意味着任何使用它的程序都必须受 GPL 保护？

是的，因为该程序实际上链接到该库。因此，GPL 的条款适用于整个组合。与库链接的软件模块可以在各种与 GPL 兼容的许可证下，但整个作品必须在 GPL 下许可。另请参阅：说许可证“与 GPL 兼容”是什么意思？

如果编程语言解释器是根据 GPL 发布的，这是否意味着编写为由它解释的程序必须使用与 GPL 兼容的许可证？

当解释器仅解释一种语言时，答案是否定的。对于解释器而言，被解释的程序只是数据；基于版权法的自由软件许可证（如 GPL）不能限制你对解释器使用的数据。你可以以任何方式在任何数据（解释程序）上运行它，并且没有关于将该数据许可给任何人的要求。

但是，当扩展解释器以提供与其他设施（通常但不一定总是库）的“绑定”时，被解释的程序实际上通过这些绑定链接到它使用的设施。因此，如果这些设施在 GPL 下发布，则使用它们的解释程序必须以与 GPL 兼容的方式发布。JNI 或 Java 本机接口是这种绑定机制的一个示例；以这种方式访问的库与调用它们的 Java 程序动态链接。这些库也与解释器链接。如果解释器与这些库静态链接，或者如果它被设计为与这些特定的库动态链接，那么它也需要以与 GPL 兼容的方式发布。

另一个类似且非常常见的情况是为解释器提供库，这些库本身也被解释。例如，Perl 附带许多 Perl 模块，而 Java 实现附带许多 Java 类。这些库和调用它们的程序始终动态地链接在一起。

一个结果是，如果你选择在程序中使用 GPL 的 Perl 模块或 Java 类，则无论组合的 Perl 或 Java 程序将在其上运行的 Perl 或 Java 解释器中使用什么许可证，都必须以与 GPL 兼容的方式发布该程序。

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

GPL 允许这样做，因为该运行时库通常伴随你正在使用的编译器或解释器。因此，它属于 GPL 第 3 节中的例外情况。

这并不意味着将程序编写为仅在 Windows 上运行是一个好主意。这样做会导致一个自由软件，但它被“困住”了（在这种情况下，是被 Windows 而不是 Java 困住了，但效果是一样的）。（历史记录：截至 2006 年 12 月，Sun 正处于在 GNU GPL 下重新发布其 Java 平台的过程中。）

为什么最初的 BSD 许可证与 GPL 不兼容？

因为它施加了 GPL 中没有的特定要求；即对程序的广告的要求。GPL 指出

你不得对接收者行使本文授予的权利施加任何进一步的限制。

广告条款提供了这样的进一步限制，因此与 GPL 不兼容。

修订后的 BSD 许可证没有广告条款，从而消除了这个问题。

何时将程序及其插件视为单个组合程序？

这取决于主程序如何调用其插件。如果主程序使用 fork 和 exec 来调用插件，并且它们通过共享复杂的数据结构或来回传输复杂的数据结构来建立密切的通信，那么这可以使它们成为一个单一的组合程序。如果主程序使用简单的 fork 和 exec 来调用插件，并且它们之间没有建立密切的通信，则插件将成为一个单独的程序。

如果主程序动态链接插件，并且它们之间相互调用函数并共享数据结构，我们认为它们构成一个单一的组合程序，必须被视为是主程序和插件的扩展。如果主程序动态链接插件，但它们之间的通信仅限于使用一些选项调用插件的“main”函数并等待其返回，那么这是一个边界情况。

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

如果一个以 GPL 发布的程序使用了插件，那么插件的许可证有什么要求？

请参阅此问题以确定何时将插件和主程序视为一个单一的组合程序，以及何时将它们视为单独的作品。

如果主程序和插件是一个单一的组合程序，那么这意味着您必须根据 GPL 或与 GPL 兼容的自由软件许可证许可该插件，并以符合 GPL 的方式分发其源代码。与插件分离的主程序对插件没有任何要求。

当为非自由程序编写插件时，我可以使用 GPL 吗？

请参阅此问题以确定何时将插件和主程序视为一个单一的组合程序，以及何时将它们视为单独的程序。

如果它们构成一个单一的组合程序，这意味着将受 GPL 保护的插件与非自由主程序组合使用将违反 GPL。但是，您可以通过在插件的许可证中添加一个例外来解决该法律问题，允许将其与非自由主程序链接。

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

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

请参阅此问题以确定何时将插件和主程序视为一个单一的组合程序，以及何时将它们视为单独的程序。

如果它们构成一个单一的组合程序，那么主程序必须在 GPL 或与 GPL 兼容的自由软件许可证下发布，并且当主程序与这些插件一起分发使用时，必须遵循 GPL 的条款。

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

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

您有一个 GPL 许可的程序，我想将其与我的代码链接以构建一个专有程序。我与您的程序链接是否意味着我必须对我的程序进行 GPL 许可？

是的。

如果是这样，我是否有可能获得在较宽松的 GPL 下的您的程序的许可证？

您可以询问，但大多数作者会坚定地拒绝。GPL 的理念是，如果您想在您的程序中包含我们的代码，那么您的程序也必须是自由软件。它旨在对您施加压力，让您以使其成为我们社区一部分的方式发布您的程序。

您始终可以选择不使用我们的代码，这是一个合法的替代方案。

我如何才能在受控接口下允许专有模块与我的 GPL 覆盖的库链接？

将此文本添加到包中每个文件的许可证声明中，在声明该文件根据 GNU GPL 分发的文本末尾。

将ABC静态或动态地与其他模块链接正在制作基于ABC的组合作品。因此，GNU通用公共许可证的条款和条件涵盖了整个组合。
此外，作为一项特殊例外，ABC 的版权持有者允许您将 ABC 程序与根据 GNU LGPL 发布的自由软件程序或库以及仅通过 ABCDEF 接口与 ABC 通信的独立模块组合使用。您可以按照 GNU GPL 对 ABC 的条款以及相关其他代码的许可证复制和分发此类系统，前提是当 GNU GPL 要求分发源代码时，您包含该其他代码的源代码。
请注意，对ABC进行修改的人员没有义务为他们的修改版本授予此特殊例外；是否这样做是他们自己的选择。GNU 通用公共许可证允许发布没有此例外的修改版本；此例外还使发布带有此例外的修改版本成为可能。

我编写了一个与许多不同组件链接的应用程序，这些组件具有不同的许可证。我对我的程序必须遵守的许可要求感到非常困惑。您能告诉我可以使用哪些许可证吗？

为了回答这个问题，我们需要查看您的程序使用的每个组件的列表、该组件的许可证以及简要描述（每个组件几句话就足够了），说明您的库如何使用该组件。以下是两个示例：

为了使我的软件工作，它必须链接到 FOO 库，该库在 Lesser GPL 下可用。
我的软件进行系统调用（使用我构建的命令行）来运行 BAR 程序，该程序在“GPL，具有允许与 QUUX 链接的特殊例外”下获得许可。

“仅仅聚合”和“将两个模块组合成一个程序”之间有什么区别？

仅仅是两个程序的聚合意味着将它们并排放置在同一个 CD-ROM 或硬盘上。我们在它们是单独的程序而不是单个程序的一部分的情况下使用此术语。在这种情况下，如果其中一个程序受 GPL 保护，则它对另一个程序没有影响。

组合两个模块意味着将它们连接在一起，使其形成一个更大的程序。如果任何一部分受 GPL 保护，则整个组合也必须在 GPL 下发布——如果您不能或不愿这样做，则您不得将它们组合在一起。

什么构成将两个部分组合成一个程序？这是一个法律问题，最终将由法官决定。我们认为，适当的标准取决于通信机制（exec、管道、rpc、共享地址空间内的函数调用等）和通信的语义（交换的信息类型）。

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

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

为什么 FSF 要求 FSF 版权程序的贡献者将版权转让给 FSF？如果我对一个 GPL 许可的程序持有版权，我是否也应该这样做？如果应该，如何做？

我们的律师告诉我们，为了在法庭上针对违规者最好地执行 GPL，我们应尽量保持该程序的版权状态尽可能简单。我们通过要求每位贡献者将其贡献的版权转让给 FSF，或放弃其版权并将其置于公共领域来实现此目的。

当然，如果所有贡献者都将其代码置于公共领域，则没有版权可用来执行 GPL。因此，我们鼓励人们转让大型代码贡献的版权，而仅将小的更改置于公共领域。

如果您想努力对您的程序执行 GPL，那么您最好也遵循类似的策略。如果您想了解更多信息，请联系 <[email protected]>。

我可以修改 GPL 并创建一个修改后的许可证吗？

您可以在另一个许可证中使用 GPL 条款（可能会修改），前提是您以另一个名称调用您的许可证并且不包含 GPL 前言，并且前提是您足够修改末尾的使用说明，使其在措辞上明显不同，并且不提及 GNU（尽管您描述的实际过程可能相似）。

如果您想在修改后的许可证中使用我们的前言，请写信至 <[email protected]> 以获得许可。为此，我们需要检查实际的许可证要求，以查看我们是否批准它们。

尽管我们不会对您以这种方式制定修改后的许可证提出法律异议，但我们希望您三思而后行，不要这样做。此类修改后的许可证几乎肯定与 GNU GPL 不兼容，并且这种不兼容会阻止模块的有用组合。仅仅是不同自由软件许可证的激增本身就是一个负担。

如果我使用根据 GNU GPL 获得的软件，我是否可以将原始代码修改为一个新程序，然后商业分发和销售该新程序？

您可以在商业上出售修改后的程序的副本，但只能根据 GNU GPL 的条款进行。因此，例如，您必须按照 GPL 中的描述向程序的用户提供源代码，并且他们必须被允许按照 GPL 中的描述重新分发和修改它。

这些要求是在您自己的程序中包含您收到的受 GPL 保护的代码的条件。

我可以使用 GPL 用于软件以外的东西吗？

您可以将 GPL 应用于任何类型的工作，只要清楚什么是该工作的“源代码”。GPL 将此定义为对工作进行更改的首选形式。

但是，对于手册和教科书，或者更笼统地说，任何旨在教授某个主题的工作，我们建议使用 GFDL 而不是 GPL。

LGPL 如何与 Java 一起使用？

请参阅此文章了解详情。它按照设计、预期和期望的方式工作。

考虑这种情况：1. X 以 GPL 发布了项目 V1。 2. Y 在 V1 的基础上，通过修改和新代码为 V2 的开发做出了贡献。 3. X 想要将 V2 转换为非 GPL 许可证。X 是否需要 Y 的许可？

是的。由于 Y 是基于 X 的版本 V1，因此 Y 需要根据 GNU GPL 发布其版本。没有要求 Y 同意其代码的任何其他许可。因此，X 必须在根据其他许可证发布该代码之前获得 Y 的许可。

我想将 GPL 覆盖的软件整合到我的专有系统中。我可以这样做吗？

您不能将受 GPL 保护的软件合并到专有系统中。GPL 的目标是授予每个人复制、重新分发、理解和修改程序的自由。如果您可以将受 GPL 保护的软件合并到非自由系统中，它也会使受 GPL 保护的软件变得不自由。

包含受 GPL 保护的程序的系统是该程序的扩展版本。GPL 表示，如果该程序的任何扩展版本被发布，则必须在 GPL 下发布。这有两个原因：确保获得软件的用户获得他们应该拥有的自由，并鼓励人们回报他们所做的改进。

但是，在许多情况下，您可以将受 GPL 保护的软件与您的专有系统一起分发。为了有效执行此操作，您必须确保自由程序和非自由程序保持适当的距离进行通信，它们不会以使它们实际上成为一个单一程序的方式组合在一起。

这与“合并”受 GPL 保护的软件之间的区别部分是实质性的，部分是形式上的。实质部分是：如果两个程序组合在一起，以至于它们实际上成为一个程序的两部分，那么您就不能将它们视为两个单独的程序。因此，GPL 必须涵盖所有内容。

如果这两个程序保持良好分离，例如编译器和内核，或者像编辑器和 shell，那么您可以将它们视为两个单独的程序——但您必须正确地执行此操作。问题仅仅是形式上的：您如何描述您正在做的事情。我们为什么关心这个？因为我们要确保用户清楚地了解集合中受 GPL 保护的软件的自由状态。

如果人们分发受 GPL 保护的软件，称其为用户知道部分是专有的系统的“一部分”，则用户可能不确定他们对受 GPL 保护的软件的权利。但是，如果他们知道他们收到的是一个自由程序和另一个程序，并排放置，那么他们的权利将是明确的。

在 GPL 下使用某个 GNU 程序不符合我们制作专有软件的项目。您会为我们破例吗？这将意味着该程序会有更多的用户。

抱歉，我们不会做出此类例外。这不合理。

最大化用户数量不是我们的目标。相反，我们正在努力将关键的自由赋予尽可能多的用户。一般来说，专有软件项目阻碍而不是帮助自由事业。

我们偶尔会为协助在 GPL 以外的许可证下制作自由软件的项目而做出许可证例外。但是，我们必须看到充分的理由说明这将如何促进自由软件事业。

当这似乎是为自由软件事业服务的正确方式时，我们有时也会更改软件包的分发条款；但我们对此非常谨慎，因此您必须向我们展示非常有说服力的理由。

我想将 GPL 覆盖的软件整合到我的专有系统中。我可以通过在 GPL 覆盖的部分和专有部分之间放置一个 “包装器” 模块，该模块使用 GPL 兼容的宽松许可（例如 X11 许可）来实现吗？

不。X11 许可证与 GPL 兼容，因此您可以向受 GPL 保护的程序添加一个模块，并将其置于 X11 许可证下。但是，如果您要将它们都合并到一个更大的程序中，那么整个程序将包含受 GPL 保护的部分，因此必须整体根据 GNU GPL 许可。

专有模块 A 仅通过 X11 许可的模块 B 与受 GPL 保护的模块 C 通信这一事实在法律上无关紧要；重要的是模块 C 包含在整体中的事实。

libstdc++ 异常是否允许动态链接？

是的。此例外的目的是允许人们使用 gcc 编译专有软件。

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

这有两个原因。

首先，一个普遍的原因。如果我们允许 A 公司制作一个专有文件，并允许 B 公司分发与该文件链接的受 GPL 保护的软件，其结果将在 GPL 中开一个足够卡车通过的洞。这将为扣留对受 GPL 保护的软件的所有类型的修改和扩展的源代码提供空白支票。

让所有用户都能访问源代码是我们的主要目标之一，因此这种结果绝对是我们想要避免的。

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

如果模块 Q 的许可证有一个与 GPL 不兼容的要求，但是该要求仅在 Q 单独分发时适用，而不是在 Q 被包含在更大的程序中时适用，这是否使该许可证与 GPL 兼容？我可以将 Q 与 GPL 覆盖的程序组合或链接吗？

如果程序 P 在 GPL 下发布，这意味着 它的任何和每个部分 都可以在 GPL 下使用。如果您集成模块 Q，并在 GPL 下发布组合程序 P+Q，这意味着 P+Q 的任何部分都可以在 GPL 下使用。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 链接或组合。

我是否可以仅以二进制形式发布 GPL 许可程序的修改版本？

不。GPL 的全部意义在于，所有修改后的版本都必须是自由软件——特别是，修改版本的源代码对用户是可用的。

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

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

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

如果有人订购，您应该通过邮购在物理介质上提供源代码。除了邮购选项外，您还可以为人们提供通过 FTP 复制相应源代码的方法，但是通过 FTP 访问源代码不足以满足 GPL 第 3 条的要求。

当用户订购源代码时，您必须确保将源代码提供给该用户。如果特定用户可以通过匿名 FTP 方便地从您那里获取源代码，那很好——这可以完成工作。但是并非每个用户都可以进行此类下载。其余用户也同样有权从您那里获得源代码，这意味着您必须准备好通过邮寄方式将其发送给他们。

如果 FTP 访问足够方便，也许没有人会选择邮购副本。如果是这样，您将永远不必邮寄副本。但您不能假设会这样。

当然，最简单的方法是首先将源代码与二进制文件一起发送。

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

我的朋友获得了一个带有源代码供应报价的受 GPL 保护的二进制文件，并为我复制了一份。我可以使用该报价来获取源代码吗？

是的，您可以。该报价必须向所有拥有其随附二进制文件副本的人开放。这就是为什么 GPL 说您的朋友必须在提供二进制文件的副本时一并给您一份报价——以便您可以利用它。

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

GPL 说您必须提供“从同一地点”复制源代码的访问权限；也就是说，在二进制文件旁边。但是，如果您与另一个站点达成协议以保持必要的源代码可用，并在二进制文件旁边放置指向源代码的链接或交叉引用，我们认为这符合“来自同一地点”的条件。

但是请注意，找到某个碰巧今天拥有适当源代码的站点，并告诉人们去那里查找是不够的。明天，该站点可能已删除该源代码，或者只是将其替换为同一程序的较新版本。那么您将不再符合 GPL 的要求。要合理地努力遵守，您需要与另一个站点达成积极的安排，从而确保只要您保持二进制文件可用，源代码就将在那里可用。

我想以二进制形式分发 GPL 许可程序的扩展版本。分发原始版本的源代码是否足够？

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

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

GPL 的主要目标是通过确保对自由程序的改进本身也是自由的，从而建立自由世界。如果您发布 GPL 保护的程序的改进版本，您必须在 GPL 下发布改进的源代码。

我想分发二进制文件，但分发完整的源代码很不方便。如果我给用户提供与“标准”版本不同的二进制文件是否可以？

这是一个善意的请求，但这种提供源代码的方法并不能真正完成工作。

一年后想要源代码的用户可能无法在那时从另一个站点获得正确的版本。标准分发站点可能有一个较新的版本，但相同的差异可能不适用于该版本。

因此，您需要提供完整的源代码，而不仅仅是与二进制文件一起的差异。

我想让二进制文件可以通过匿名 FTP 获取，但只向订购的人发送源代码。

如果您想通过匿名 FTP 分发二进制文件，您仍然必须通过第 3 条中列出的选项之一提供源代码。这不应该很困难。如果您愿意，您可以提供书面的源代码报价；第 3(b) 条允许这样做。但是，如果您可以找到一个站点来分发您的程序，您肯定可以找到一个有空间存放源代码的站点。

无论您如何分发源代码，您提供的源代码都必须与二进制文件完全对应。特别是，您必须确保它们是同一程序版本的，而不是较旧的版本，也不是较新的版本。

您可以在不同的计算机上提供源代码和二进制文件，前提是它们同样容易获取，并且您在二进制文件旁边有信息说明在哪里可以找到源代码。

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

您不必确保这一点。只要您提供源代码和二进制文件，以便用户可以看到可用的内容并获取他们想要的内容，您就完成了对您的要求。是否下载源代码取决于用户。

我们对重新分发者的要求旨在确保用户可以获得源代码，而不是强迫用户下载源代码，即使他们不想要它。

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

GPL 允许任何人制作修改后的版本并使用它，而无需将其分发给其他人。这家公司正在做的是这种情况的特例。因此，该公司不必发布修改后的源代码。

人们必须有自由进行修改并私下使用它们，而无需发布这些修改，这一点至关重要。但是，将程序放在服务器机器上供公众访问绝对不是“私人”使用，因此在那种特殊情况下要求发布源代码是合法的。我们正在考虑在 GPL 版本 3 中做类似的事情，但我们还没有确切的措辞。

与此同时，您可能希望为设计用于网络服务器使用的程序使用 Affero GPL。

在一个组织或公司内制作和使用多个副本是“分发”吗？

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

但是，当组织将副本转移到其他组织或个人时，这就是分发。特别是，向承包商提供副本以供场外使用就是分发。

如果有人偷了一张包含 GPL 许可程序版本的 CD，GPL 是否赋予他重新分发该版本的权利？

如果该版本已在其他地方发布，那么窃贼可能确实有权根据 GPL 制作副本并重新分发它们，但是如果他因偷窃 CD 而被监禁，他可能必须等到获释后才能这样做。

如果相关版本是未发布的，并且被公司视为其商业秘密，那么发布它可能违反商业秘密法，具体取决于其他情况。GPL 不会改变这一点。如果该公司试图发布其版本，但仍然将其视为商业秘密，那将违反 GPL，但是如果该公司尚未发布此版本，则不会发生此类违规行为。

如果一家公司将其他开发人员的 GPL 许可作品的副本作为商业秘密分发给我怎么办？

该公司违反了 GPL，将不得不停止分发该程序。请注意这与上述盗窃案例有何不同；当副本被盗时，该公司并非故意分发副本，因此在这种情况下，该公司并未违反 GPL。

如果一家公司将其自己的 GPL 许可作品的副本作为商业秘密分发给我怎么办？

如果分发的程序没有合并任何其他人的受 GPL 保护的作品，那么该公司没有违反 GPL（有关更多信息，请参阅“受 GPL 保护的程序的开发人员是否受 GPL 约束？”）。但是，它正在就您可以使用该程序做什么做出两个相互矛盾的声明：您可以重新分发它，并且您不能。在接受副本之前，要求澄清该程序的使用条款是有道理的。

为什么一些 GNU 库是根据普通 GPL 而不是较宽松的 GPL 发布的？

对任何特定库使用 Lesser GPL 都构成了对自由软件的退让。这意味着我们部分放弃了捍卫用户自由的尝试，以及一些分享在受 GPL 保护的软件之上构建的内容的要求。就其本身而言，这些变化都是不好的。

有时，局部退让是一种好策略。有时，对库使用 LGPL 可能会导致该库的更广泛使用，从而对其进行更多改进，更广泛地支持自由软件等等。如果这种情况在很大程度上发生，这对自由软件可能是一件好事。但是这种情况会发生多少呢？我们只能推测。

在每个库上尝试一段时间 LGPL 许可，看看是否有帮助，如果 LGPL 没有帮助，再改回 GPL 许可，这看起来不错。但这实际上不可行。一旦我们对某个特定的库使用 LGPL 许可，再改回去就很难了。

因此，我们决定在具体情况下逐个决定每个库使用哪个许可。关于我们如何判断这个问题，有一个详细的解释。

为什么程序应该说“GPL 第 2 版或任何更高版本”？

我们会不时地，以数年为间隔，修改 GPL——有时是为了澄清它，有时是为了允许以前不允许的某些使用方式，有时是为了收紧一些要求。（上次修改是在 1991 年。）在每个程序中使用这种“间接指针”使我们能够在更新 GPL 时更改整个 GNU 软件集合的分发条款。

假设一个程序说“GPL 第 2 版或任何更高版本”，并且发布了新版本的 GPL。如果新的 GPL 版本提供了额外的许可，那么该许可将立即提供给该程序的所有用户。但是，如果新的 GPL 版本有更严格的要求，它不会限制当前版本的程序的使用，因为它仍然可以在 GPL 第 2 版下使用。当一个程序说“GPL 第 2 版或任何更高版本”时，用户始终被允许根据 GPL 第 2 版的条款使用它，甚至更改它——即使在更高版本的 GPL 可用之后也是如此。

如果新版本 GPL 中更严格的要求对于现有软件不必遵守，那么它有什么用呢？一旦 GPL 第 3 版可用，大多数受 GPL 覆盖的程序的开发人员将发布其程序的后续版本，指定“GPL 第 3 版或任何更高版本”。然后，用户将不得不遵守 GPL 第 3 版中更严格的要求，对于该程序的后续版本。

但是，开发人员没有义务这样做；如果他们愿意，开发人员可以继续允许使用先前版本的 GPL。

为什么你们不将 GPL 用于手册？

可以使用 GPL 用于手册，但 GNU 自由文档许可证（GFDL）对于手册来说更好。

GPL 是为程序设计的；它包含许多对于程序至关重要的复杂条款，但对于书籍或手册来说，这些条款会显得繁琐和不必要。例如，任何以纸质形式出版该书的人都必须在每份印刷副本中包含该书的机器可读“源代码”，或提供书面承诺在以后发送“源代码”。

同时，GFDL 具有帮助自由手册的出版商从销售副本中获利的条款——例如封面文字。关于认可部分的特殊规则使得可以将 GFDL 用于官方标准。这将允许修改后的版本，但它们不能被标记为“标准”。

使用 GFDL，我们允许更改手册中涵盖其技术主题的文本。能够更改技术部分非常重要，因为更改程序的人应该相应地更改文档。这样做的自由是一种道德上的必然。

我们的手册还包括声明我们关于自由软件的政治立场的章节。我们将这些标记为“不变的”，这样它们就不能被更改或删除。GFDL 为这些“不变的部分”提供了规定。

GPL 如何应用于字体？

字体许可是一个复杂的问题，需要认真考虑。以下许可例外是实验性的，但已批准用于通用。我们欢迎对此主题的建议——请参阅这篇解释性文章，并写信给<[email protected]>。

要使用此例外，请在软件包中每个文件的许可声明末尾（在尽可能的情况下），添加此文本，该文本表示该文件根据 GNU GPL 分发

作为特殊例外，如果您创建使用此字体的文档，并将此字体或此字体的未更改部分嵌入到文档中，则此字体本身不会导致生成的文档受 GNU 通用公共许可证的约束。但是，此例外并不使文档可能受 GNU 通用公共许可证约束的任何其他原因无效。如果您修改此字体，您可以将此例外扩展到您的字体版本，但您没有义务这样做。如果您不希望这样做，请从您的版本中删除此例外声明。

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

模板足够小，不值得使用版权保护来保护它们。通常在小型作品上使用版权保护是无害的，但模板是一种特殊情况，因为它们与应用程序用户提供的数据相结合，并且组合后的结果会被分发。因此，我们建议您在简单的允许条款下许可您的模板。

一些模板调用 Javascript 函数。由于 Javascript 通常是非平凡的，因此值得使用版权保护。由于模板将与用户数据组合，因此模板+用户数据+ Javascript 可能被认为是版权法下的一项作品。需要在 Javascript（受版权保护）和用户代码（通常在不兼容的条款下）之间划清界限。

这是针对 Javascript 代码执行此操作的例外情况

作为 GPL 的特殊例外，任何仅对此代码进行函数调用，并为此目的通过引用包含它的 HTML 文件，在版权法上应被视为单独的作品。此外，此代码的版权所有者允许您将此代码与根据 GNU LGPL 发布的自由软件库相结合。您可以按照此代码的 GNU GPL 条款和库的 LGPL 条款复制和分发此类系统。如果您修改此代码，您可以将此例外扩展到您的代码版本，但您没有义务这样做。如果您不希望这样做，请从您的版本中删除此例外声明。

我可以使用我使用非自由工具开发的程序根据 GPL 发布吗？

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

但是，如果您将非自由库与源代码链接，则这是您需要处理的问题。这并不妨碍您在 GPL 下发布源代码，但是如果这些库不符合“系统库”例外情况，您应该附加一个明确的声明，允许将您的程序与它们链接。FSF 可以为您提供有关如何执行此操作的建议。

是否有 GPL 的其他语言翻译版本？

将 GPL 翻译成英语以外的其他语言会很有用。人们甚至编写了翻译并发送给我们。但是，我们不敢批准它们为官方有效。这带来的风险太大了，我们不敢接受。

法律文件在某些方面类似于程序。翻译它就像将程序从一种语言和操作系统翻译到另一种语言和操作系统。只有精通两种语言的律师才能做到这一点——即使如此，也存在引入错误的风险。

如果我们正式批准 GPL 的翻译，我们将允许每个人按照翻译中所说的他们可以做的任何事情去做。如果翻译完全准确，那很好。但是，如果翻译中存在错误，则结果可能是我们无法修复的灾难。

如果一个程序有错误，我们可以发布一个新版本，最终旧版本或多或少会消失。但是，一旦我们允许每个人按照特定的翻译行事，如果我们稍后发现它有错误，我们就无法收回该许可。

乐于助人的人有时会主动为我们翻译。如果问题是要找到人来做这项工作，那么这将解决问题。但实际问题是错误的风险，而主动翻译并不能避免这种风险。我们不可能授权由非律师撰写的翻译。

因此，目前，我们不批准 GPL 的翻译在全球范围内有效且具有约束力。相反，我们正在做两件事

将人们推荐给非官方翻译。这意味着我们允许人们编写 GPL 的翻译，但我们不批准它们在法律上有效且具有约束力。
未经批准的翻译没有法律效力，并且应该明确说明这一点。它应该标记如下

此 GPL 翻译是非正式的，未获得自由软件基金会的正式批准，不具有法律效力。要完全确定允许的内容，请参阅原始 GPL（英文）。

但是，未经批准的翻译可以作为如何理解英文 GPL 的提示。对于许多用户来说，这已经足够了。

但是，在商业活动中使用 GNU 软件的企业以及进行公共 ftp 分发的人员，应该需要查看真正的英文 GPL，以确保其允许的内容。
发布仅对单个国家/地区有效的翻译。
我们正在考虑发布仅对一个国家/地区正式有效的翻译的想法。这样，如果出现错误，它将仅限于该国家/地区，并且造成的损害不会太大。

仍然需要一位同情和有能力的律师的大量专业知识和努力才能完成翻译，因此我们不能保证很快会有任何此类翻译。

如果编程语言解释器具有与 GPL 不兼容的许可证，我可以在其上运行受 GPL 保护的程序吗？

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

但是，当扩展解释器以提供与其他设施（通常是库，但不一定是）的“绑定”时，被解释的程序实际上是通过这些绑定链接到它使用的设施的。JNI 或 Java Native Interface 就是这种设施的一个示例；以这种方式访问的库与调用它们的 Java 程序动态链接。

因此，如果这些设施是在与 GPL 不兼容的许可证下发布的，那么情况就像以任何其他方式与与 GPL 不兼容的库链接一样。这意味着

如果您正在编写代码并根据 GPL 发布它，您可以声明一个明确的例外，允许将其与那些与 GPL 不兼容的设施链接。
如果您编写并根据 GPL 发布了该程序，并且您专门将其设计为与那些设施一起使用，那么人们可以将此视为允许他们将其与那些设施链接的隐含例外。但是，如果这是您的意图，最好明确说明。

谁有权执行 GPL？

由于 GPL 是一种版权许可证，因此软件的版权持有者可以对其进行强制执行。如果您发现有违反 GPL 的行为，您应该通知相关 GPL 许可软件的开发者。他们要么是版权持有者，要么与版权持有者有关联。

此外，我们鼓励用户使用任何可用的法律机制来获取完整且对应的源代码，这是他们的权利，并强制完全遵守 GNU GPL。毕竟，我们开发 GNU GPL 的目的是让所有用户都能自由地使用软件。

在 Java 等面向对象的语言中，如果我使用一个未经修改的 GPL 类，并对其进行子类化，那么 GPL 会以何种方式影响更大的程序？

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

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

一般来说，答案是否定的——这不是法律要求。具体而言，答案取决于您想使用哪些库以及它们的许可证是什么。大多数系统库要么使用GNU 宽通用公共许可证 (GNU Lesser GPL)，要么使用 GNU GPL 加上允许将库与任何内容链接的例外。这些库可以在非自由程序中使用；但在使用宽通用公共许可证的情况下，它确实有一些您必须遵守的要求。

一些库仅在 GNU GPL 下发布；您必须使用与 GPL 兼容的许可证才能使用这些库。但这些通常是更专业的库，您在其他平台上不会找到类似的库，因此您可能不会发现自己想要使用这些库进行简单的移植。

当然，如果您的软件不是自由的，那么它就不是对我们社区的贡献，重视自由的人会拒绝使用它。只有愿意放弃自由的人才会使用您的软件，这意味着它实际上会成为诱使人们失去自由的工具。

如果您希望有一天回顾自己的职业生涯，并感觉到它为良好且自由的社会的发展做出了贡献，那么您需要使您的软件自由。

我刚刚发现一家公司拥有 GPL 许可的程序的副本，并且获得它需要花钱。他们不将其发布在互联网上，难道不是违反 GPL 吗？

不是的。GPL 不要求任何人使用互联网进行分发。它也不要求任何特定的人重新分发该程序。而且（除了一种特殊情况外），即使有人有时决定重新分发该程序，GPL 也没有说他必须向您或任何其他特定的人分发副本。

GPL 要求的是他必须有自由权在他愿意的情况下向您分发副本。一旦版权持有者确实向某人分发了程序副本，那么该人就可以将该程序重新分发给您或任何其他人，只要他认为合适。

我可以发布一个带有许可证的程序，该许可证说您可以根据 GPL 分发它的修改版本，但不能根据 GPL 分发原始版本本身吗？

不是的。这样的许可证是自相矛盾的。让我们看看它对我作为用户的含义。

假设我从原始版本（称之为版本 A）开始，添加一些代码（假设是 1000 行），并在 GPL 下发布该修改后的版本（称之为版本 B）。GPL 规定任何人都可以再次更改版本 B，并在 GPL 下发布结果。因此，我（或其他人）可以删除这 1000 行，生成与版本 A 代码相同但受 GPL 保护的版本 C。

如果您尝试阻止这条路径，通过在许可证中明确说明我不允许通过从版本 B 中删除这些行来在 GPL 下重现与版本 A 相同的内容，实际上该许可证现在表示我不能以 GPL 允许的所有方式充分使用版本 B。换句话说，该许可证实际上不允许用户在 GPL 下发布修改后的版本，如版本 B。

将副本移至多数控股和控制的子公司是否构成发行？

将副本移入或移出此子公司是否构成“分发”是一个问题，应根据相应司法管辖区的版权法在每种情况下决定。GPL 不会也不能凌驾于当地法律之上。美国版权法在这一点上并不完全明确，但似乎不认为这是分发。

如果在某些国家，这被认为是分发，并且子公司必须获得重新分发该程序的权利，这不会产生实际影响。子公司由母公司控制；无论是否有权利，除非母公司决定这样做，否则它不会重新分发该程序。

软件安装程序可以要求人们点击以同意 GPL 吗？如果我根据 GPL 获得一些软件，我是否必须同意任何事情？

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

仅仅同意 GPL 并不会对您施加任何义务。您无需同意任何内容即可仅仅使用在 GPL 下获得许可的软件。只有当您修改或分发该软件时，您才有义务。如果您真的不喜欢点击 GPL，没有什么能阻止您破解 GPL 许可的软件来绕过它。

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

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

关于 GNU GPL 第 2 版的常见问题解答

目录

关于 GPL、GNU 项目和自由软件基金会的基本问题

对 GPL 的一般理解

在您的程序中使用 GPL

根据 GPL 发布程序的发行

在编写其他程序时使用根据 GPL 发布的程序

将工作与根据 GPL 发布的代码相结合

有关违反 GPL 的问题