关于 GNU 许可证的常见问题

“GPL”代表什么？ (#WhatDoesGPLStandFor)

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

自由软件是否意味着使用 GPL？ (#DoesFreeSoftwareMeanUsingTheGPL)

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

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

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

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

大多数 GNU 软件包都使用 GNU GPL 许可证，但也有少数 GNU 程序（以及程序的部分内容）使用较为宽松的许可证，例如 LGPL。我们这样做是出于策略考虑。

为程序使用 GPL 是否使其成为 GNU 软件？ (#DoesUsingTheGPLForAProgramMakeItGNUSoftware)

任何人都可以使用 GNU GPL 发布程序，但这并不使其成为 GNU 软件包。

使程序成为 GNU 软件包意味着明确地为 GNU 项目做出贡献。这发生在程序的开发者和 GNU 项目同意这样做的时候。如果您有兴趣为 GNU 项目贡献程序，请写信至 <[email protected]>。

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

您应该报告它。首先，尽可能核实事实。然后告知特定受 GPL 保护的程序的发布者或版权所有者。如果发布者是自由软件基金会，请写信至 <[email protected]>。否则，程序的维护者可能是版权所有者，或者可以告诉您如何联系版权所有者，因此请向维护者报告。

为什么 GPL 允许用户发布其修改后的版本？ (#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions)

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

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

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

GPL 是否要求将修改后的版本的源代码公开发布？ (#GPLRequireSourcePostedPublic)

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

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

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

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

可以。

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

不可以。GPL 允许一个人在该人选择这样做时制作和重新分发程序的副本。该人也有权不选择重新分发该程序。

在 GPLv2 中，“对任何第三方有效的书面报价”是什么意思？ 这是否意味着世界上任何人都可以获得任何 GPL 授权程序的源代码？ (#WhatDoesWrittenOfferValid)

如果您选择通过书面报价提供源代码，则任何向您请求源代码的人都有权收到它。

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

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

GPLv2 说，修改后的版本如果发布，必须“授权给所有第三方”。这些第三方是谁？ (#TheGPLSaysModifiedVersions)

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

我是否必须声明我对受 GPL 保护的程序的修改拥有版权？ (#RequiredToClaimCopyright)

您无需声明您对更改拥有版权。但是，在大多数国家/地区，默认情况下会自动发生这种情况，因此如果您不希望您的更改受版权保护，则需要明确地将您的更改置于公共领域。

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

GPL 对将某些代码翻译成不同的编程语言有何规定？ (#TranslateCode)

根据版权法，作品的翻译被认为是一种修改。因此，GPL 对修改后的版本的规定也适用于翻译后的版本。翻译受原始程序的版权保护。

如果原始程序带有自由许可证，则该许可证允许翻译它。如何使用和许可翻译后的程序由该许可证决定。如果原始程序是根据某些版本的 GNU GPL 许可的，则翻译后的程序必须受相同版本的 GNU GPL 保护。

如果一个程序将公共领域的代码与受 GPL 保护的代码结合在一起，我可以获取公共领域的这部分代码并将其用作公共领域的代码吗？ (#CombinePublicDomainWithGPL)

如果您能够找出哪个部分是公共领域的部分并将其与其余部分分开，则可以这样做。如果代码是由其开发者置于公共领域的，则无论它在哪里，它都属于公共领域。

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

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

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

是的。您可以为分发程序的副本收取任何您希望的费用。根据 GPLv2，如果您通过下载分发二进制文件，则必须提供“等效访问”来下载源代码——因此，下载源代码的费用不得高于下载二进制文件的费用。如果分发的二进制文件是根据 GPLv3 许可的，那么您必须以相同的方式通过相同的位置免费提供对源代码的等效访问。

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

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

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

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

如果我收费分发 GPL 授权的软件，我是否还需要免费向公众提供？ (#DoesTheGPLRequireAvailabilityToPublic)

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

GPL 是否允许我根据保密协议分发副本？ (#DoesTheGPLAllowNDA)

不可以。GPL 表示，任何从您那里收到副本的人都有权重新分发副本，无论是否修改。您不得以任何更具限制性的方式分发作品。

如果有人要求您签署接收 FSF 版权的 GPL 保护软件的 NDA，请立即通过写信至 [email protected] 通知我们。

如果违规行为涉及受 GPL 保护且有其他版权所有者的代码，请像对待任何其他 GPL 违规行为一样，通知该版权所有者。

GPL 是否允许我在保密协议下分发修改版或测试版？ (#DoesTheGPLAllowModNDA)

不允许。GPL 规定，您的修改版本必须包含 GPL 中声明的所有自由。因此，任何从您那里收到您的版本副本的人都有权重新分发该版本的副本（修改过的或未修改过的）。您不得在更严格的基础上分发作品的任何版本。

GPL 是否允许我在保密协议下开发修改版本？ (#DevelopChangesUnderNDA)

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

您也可以在 GPL 下向客户发布您的更改，但同意在客户同意之前不向任何人发布。在这种情况下，也没有任何受 GPL 保护的代码是在保密协议下或任何其他限制下分发的。

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

我想让我的工作获得认可。我想让人们知道我写了什么。如果我使用 GPL，我还能获得认可吗？ (#IWantCredit)

您当然可以为您的工作获得认可。根据 GPL 发布程序的一部分是在您自己的名字中编写版权声明（假设您是版权所有者）。GPL 要求所有副本都带有适当的版权声明。

GPL 是否允许我添加条款，要求在使用受 GPL 保护的软件或其输出的学术论文中进行引用或致谢？ (#RequireCitation)

不，GPL 条款不允许这样做。虽然我们承认正确的引用是学术出版物的重要组成部分，但引用不能作为 GPL 的附加要求。要求在使用了 GPL 软件的研究论文中进行引用超出了 GPLv3 第 7(b) 节下可接受的附加要求范围，因此将被视为 GPL 第 7 节下的附加限制。而且，无论是否在 GPL 或其他许可条款下获得许可，版权法都不允许您对软件的输出提出此类要求。

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

在作品中包含许可协议的副本至关重要，这样每个获得程序副本的人都可以知道自己的权利是什么。

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

确保拥有程序副本的人即使在网络中发生的所有变化之后仍然能够看到许可协议的唯一方法是在程序中包含许可协议的副本。

仅仅在我的存储库中放置一份 GNU GPL 的副本就足够了吗？ (#LicenseCopyOnly)

仅仅将 GNU GPL 的副本放在您存储库中的一个文件中，并不能明确声明同一存储库中的代码可以在 GNU GPL 下使用。如果没有这样的声明，就不完全清楚许可协议中的权限是否真的适用于任何特定的源文件。明确说明这一点可以消除所有疑问。

一个仅包含许可协议的文件，而没有声明某些其他文件受该许可协议的约束，类似于一个仅包含一个从未在其他任何地方调用的子程序的文件。这种相似性并不完美：律师和法院可能会运用常识并得出结论，您一定是因为想以这种方式许可代码才在那里放置 GNU GPL 的副本。或者他们可能不会。为什么要留下不确定性？

该声明应在每个源文件中。只要代码随附，程序 README 文件中的明确声明在法律上就足够了，但它们很容易被分开。为什么要冒您的代码许可协议不确定的风险？

这与 GNU GPL 的具体细节无关。对于任何自由许可协议都是如此。

为什么我应该在每个源文件中放置许可协议通知？ (#NoticeInSourceFile)

您应该在每个源文件的开头放置一个通知，说明它所使用的许可协议，以避免代码与其许可协议断开连接的风险。如果您的存储库的 README 文件说源文件是在 GNU GPL 下的，如果有人将该文件复制到另一个程序会发生什么？其他上下文可能不会显示该文件的许可协议是什么。它可能看起来具有其他许可协议，或者根本没有许可协议（这将使代码成为非自由代码）。

在每个源文件的开头添加版权声明和许可协议声明很简单，并且可以避免这种混乱。

这与 GNU GPL 的具体细节无关。对于任何自由许可协议都是如此。

如果作品不是很长怎么办？ (#WhatIfWorkIsShort)

如果整个软件包包含的代码很少——我们使用的基准是少于 300 行——您不妨对其使用宽松的允许性许可协议，而不是像 GNU GPL 这样的 copyleft 许可协议。（除非该代码特别重要。）对于这种情况，我们推荐使用 Apache License 2.0。

我可以省略 GPL 的前言或关于如何在您自己的程序上使用它的说明以节省空间吗？ (#GPLOmitPreamble)

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

前言和说明加起来大约有 1000 个单词，不到 GPL 总大小的 1/5。除非软件包本身非常小，否则它们不会使软件包的大小发生实质性的比例变化。在这种情况下，您不妨使用简单的完全许可协议，而不是 GNU GPL。

说两个许可协议“兼容”是什么意思？ (#WhatIsCompatible)

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

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

如果您只是想在同一系统中安装两个单独的程序，则不需要它们的许可协议兼容，因为这不会将它们组合成一个更大的作品。

说一个许可协议“与 GPL 兼容”是什么意思？ (#WhatDoesCompatMean)

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

所有 GNU GPL 版本都允许私下进行此类组合；它们也允许分发此类组合，前提是该组合是在相同的 GNU GPL 版本下发布的。如果另一个许可协议也允许这样做，则它与 GPL 兼容。

GPLv3 比 GPLv2 与更多许可协议兼容：它允许您与具有 GPLv3 本身没有的特定类型附加要求的代码进行组合。第 7 节包含有关此内容的更多信息，包括允许的附加要求列表。

我可以编写使用非自由库的自由软件吗？ (#FSWithNFLibs)

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

因此，请考虑：您能否找到一种不使用此库即可完成工作的方法？您可以为该库编写一个自由的替代品吗？

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

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

我可以将 GPL 程序与专有系统库链接吗？ (#SystemLibraryException)

两个版本的 GPL 都对其 copyleft 有一个例外，通常称为系统库例外。如果您想使用的与 GPL 不兼容的库符合系统库的标准，那么您无需执行任何特殊操作即可使用它们；分发整个程序的源代码的要求不包括这些库，即使您分发了包含它们的链接可执行文件。

关于什么是“系统库”的标准在不同版本的 GPL 之间有所不同。GPLv3 在第 1 节中明确定义了“系统库”，将其排除在“相应源代码”的定义之外。GPLv2 在第 3 节的末尾附近以稍微不同的方式处理此问题。

我可以通过哪些方式链接或组合受 AGPLv3 保护的代码和受 GPLv3 保护的代码？ (#AGPLGPL)

这些许可证都明确允许与在另一个许可证下发布的代码进行链接。您可以始终将GPLv3许可的模块与AGPLv3许可的模块链接，反之亦然。无论某些模块是否为库，情况都是如此。

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

如果您希望您的程序链接到不受系统库例外约束的库，则需要提供允许这样做的权限。以下是两个示例许可证声明，您可以用来做到这一点；一个用于GPLv3，另一个用于GPLv2。在任何一种情况下，您都应该将此文本放在您授予此权限的每个文件中。

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

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

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

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

版权所有 (C) [年份] [版权持有者姓名]

本程序是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；可以是许可证的第 3 版，也可以是（由您选择）任何更高版本。

本程序的发布是为了希望它有用，但不作任何担保；甚至没有对适销性或特定用途适用性的暗示保证。有关详细信息，请参阅 GNU 通用公共许可证。

您应该已收到随本程序一起提供的 GNU 通用公共许可证副本；如果没有，请参阅 <https://gnu.ac.cn/licenses>。

根据 GNU GPL 第 3 版第 7 节的附加许可

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

如果您使用的是 GPLv2，则可以为许可证条款提供自己的例外。以下许可证声明将执行此操作。同样，您必须用适合您程序的文本替换所有括号中的文本。如果不是每个人都可以分发您打算链接的库的源代码，则应删除花括号中的文本；否则，只需删除花括号本身即可。

版权所有 (C) [年份] [版权持有者姓名]

本程序是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；可以是许可证的第 2 版，也可以是（由您选择）任何更高版本。

本程序的发布是为了希望它有用，但不作任何担保；甚至没有对适销性或特定用途适用性的暗示保证。有关详细信息，请参阅 GNU 通用公共许可证。

您应该已收到随本程序一起提供的 GNU 通用公共许可证副本；如果没有，请参阅 <https://gnu.ac.cn/licenses>。

将 [您的程序名称] 与其他模块静态或动态链接，是基于 [您的程序名称] 创建一个组合作品。因此，GNU 通用公共许可证的条款和条件涵盖整个组合。

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

请注意，制作 [您的程序名称] 的修改版本的人员没有义务为他们的修改版本授予此特殊例外；是否这样做是他们的选择。GNU 通用公共许可证允许在没有此例外的情况下发布修改版本；此例外还使得可以发布带有此例外的修改版本。

我如何获得我的程序的版权，以便在 GPL 下发布？(#HowIGetCopyright)

根据伯尔尼公约，所有书写的内容从固定形式的那一刻起都会自动获得版权。因此，您无需执行任何操作即可“获得”您所写内容的版权，只要没有人可以声称拥有您的作品即可。

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

如果发生其他人可能声称拥有版权的情况，那就是如果您是雇员或学生；那么雇主或学校可能会声称您为他们完成了这项工作，并且版权属于他们。他们是否拥有有效的索赔将取决于诸如您居住地的法律以及您的雇佣合同和您从事的工作类型等情况。如果有任何可能的疑问，最好咨询律师。

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

如果我的学校可能想将我的程序变成它自己的专有软件产品，该怎么办？(#WhatIfSchool)

如今，许多大学试图通过限制对其开发的知识和信息的使用来筹集资金，实际上与商业企业的行为几乎没有区别。（有关此问题及其影响的一般性讨论，请参阅 2000 年 3 月的《大西洋月刊》“被保留的大学”。）

如果您看到您的学校有可能拒绝允许您的程序作为自由软件发布，那么最好尽早提出这个问题。程序越接近有用的工作状态，管理部门就越有可能想要从您那里夺走它并在没有您的情况下完成它。在早期阶段，您有更多的影响力。

因此，我们建议您在程序只完成一半时与他们联系，说：“如果您同意将其作为自由软件发布，我将完成它。”不要认为这是虚张声势。为了获胜，您必须有勇气说：“我的程序将拥有自由，否则永远不会诞生。”

您能给我关于如何将 GPL 应用于我的程序的逐步说明吗？(#CouldYouHelpApplyGPL)

请参阅GPL 说明页面。

我听说有人在另一个许可证下获得了 GPL 许可的程序的副本。这可能吗？(#HeardOtherLicense)

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

假设您的副本是由版权持有者放入的，并且您合法获得了该副本，那么您的副本中附带的许可证就是适用于您的副本的许可证。

我想在 GNU GPL 下发布我编写的程序，但我想在非自由程序中使用相同的代码。(#ReleaseUnderGPLAndNF)

发布非自由程序在道德上总是有缺陷的，但在法律上，您这样做没有任何障碍。如果您是代码的版权持有者，您可以随时在各种不同的非独占许可下发布它。

GPL 许可的程序的开发人员是否受 GPL 约束？开发人员的行为是否会违反 GPL？(#DeveloperViolate)

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

但是，如果开发人员所做的事情如果由其他人来做就会违反 GPL，那么开发人员肯定会在社区中失去道德地位。

在 GPL 下分发程序的开发人员以后可以将其许可给另一方专有使用吗？(#CanDeveloperThirdParty)

不能，因为公众已经有权根据 GPL 使用该程序，并且该权利不能撤销。

我可以使用 GNU Emacs 等 GPL 许可的编辑器来开发非自由程序吗？我可以使用 GCC 等 GPL 许可的工具来编译它们吗？(#CanIUseGPLToolsForNF)

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

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

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

在使用 GPL 许可的程序的源代码时，我是否拥有“合理使用”的权利？(#GPLFairUse)

是的，您有。“合理使用”是指无需任何特殊许可即可允许的使用。由于您不需要开发人员的许可即可进行此类使用，因此无论开发人员在许可证或其他地方对其如何说明，您都可以这样做——无论是 GNU GPL 还是任何其他自由软件许可证。

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

美国政府可以在 GNU GPL 下发布程序吗？(#GPLUSGov)

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

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

美国政府可以发布对 GPL 覆盖程序的改进吗？ (#GPLUSGovAdd)

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

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

GPL 对于与受保护作品进行静态链接和动态链接的模块是否有不同的要求？(#GPLStaticVsDynamic)

没有。将受 GPL 保护的作品与其他模块进行静态或动态链接，是基于受 GPL 保护的作品创建一个组合作品。因此，GNU 通用公共许可证的条款和条件适用于整个组合。另请参阅 如果我将与 GPL 不兼容的库与 GPL 软件一起使用，会出现哪些法律问题？

LGPL 对于与受保护作品进行静态链接和动态链接的模块是否有不同的要求？(#LGPLStaticVsDynamic)

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

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

(2) 如果你动态链接到用户计算机上已有的 LGPL 库，则无需传达该库的源代码。另一方面，如果你自己随应用程序一起传达可执行的 LGPL 库，无论是静态链接还是动态链接，你都必须以 LGPL 规定的方式之一传达该库的源代码。

有没有办法我可以 GPL 由我的程序产生的输出？例如，如果我的程序用于开发硬件设计，我可以要求这些设计必须是自由的吗？(#GPLOutput)

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

因此，你对输出的使用有发言权的唯一方法是，如果输出的很大一部分是从你的程序中的文本（或多或少）复制而来的。例如，如果我们没有在这种特定情况下做出例外，Bison（见上文）的部分输出将受 GNU GPL 保护。

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

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

一般来说，程序的输出不受程序代码版权的保护。因此，程序代码的许可不适用于输出，无论你是将其管道传输到文件、制作屏幕截图、屏幕录像还是视频。

例外情况是，当程序显示来自程序的完整屏幕的文本和/或艺术作品时。那么，该文本和/或艺术作品的版权就涵盖了输出。输出音频的程序，例如视频游戏，也属于此例外。

如果艺术作品/音乐受 GPL 保护，那么无论你如何复制它，GPL 都适用。然而，合理使用仍然可能适用。

请记住，某些程序，尤其是视频游戏，可能具有与底层 GPL 游戏分开许可的艺术作品/音频。在这种情况下，艺术作品/音频的许可证将决定视频/流媒体可能发生的条款。另请参阅：我可以使用 GPL 来做软件以外的事情吗？

如果我向受 GPL 保护的程序添加一个模块，我是否必须使用 GPL 作为我的模块的许可证？(#GPLModuleLicense)

GPL 规定整个组合程序必须根据 GPL 发布。因此，你的模块必须可以在 GPL 下使用。

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

如果一个库在 GPL 下发布（不是 LGPL），这是否意味着任何使用它的软件都必须在 GPL 或与 GPL 兼容的许可下？(#IfLibraryIsGPL)

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

如果一个编程语言解释器在 GPL 下发布，这是否意味着为由它解释而编写的程序必须在与 GPL 兼容的许可下？(#IfInterpreterIsGPL)

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

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

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

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

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

你可以将你的程序链接到这些库，并将编译后的程序分发给其他人。当你这样做时，运行时库是 GPLv3 定义的“系统库”。这意味着你无需担心将它们的源代码包含在程序的相应源代码中。GPLv2 在第 3 节中提供了类似的例外。

你不能以编译的 DLL 形式随程序分发这些库。为了防止不择手段的分销商试图将系统库例外用作漏洞，GPL 规定库只有在不与程序本身一起分发的情况下才能有资格作为系统库。如果你将 DLL 与程序一起分发，它们将不再有资格享受此例外；那么遵守 GPL 的唯一方法是提供它们的源代码，而你无法做到这一点。

编写只能在 Windows 上运行的免费程序是可能的，但这不是一个好主意。这些程序将被 Windows “陷阱”，因此对自由世界没有任何贡献。

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

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

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

GPLv3 在第 10 节中说了类似的话。广告条款提供了这样的进一步限制，因此与 GPL 不兼容。

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

一个程序及其插件何时被视为一个单独的组合程序？(#GPLPlugins)

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

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

使用共享内存与复杂的数据结构进行通信，实际上与动态链接是等效的。

如果我编写一个插件以与 GPL 覆盖的程序一起使用，那么这对我可以用来分发我的插件的许可证有什么要求？(#GPLAndPlugins)

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

如果主程序和插件是一个单独的组合程序，则表示您必须在 GPL 或 GPL 兼容的自由软件许可下许可该插件，并以符合 GPL 的方式分发其源代码。一个与插件分离的主程序对插件没有任何要求。

在为非自由程序编写插件时，我可以使用 GPL 吗？ (#GPLPluginsInNF)

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

如果它们形成一个单独的组合程序，则表示 GPL 覆盖的插件与非自由主程序的组合将违反 GPL。但是，您可以通过在插件的许可证中添加例外情况来解决该法律问题，从而允许将其与非自由主程序链接。

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

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

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

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

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

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

您有一个 GPL 许可的程序，我想将它与我的代码链接以构建专有程序。我与您的程序链接的事实是否意味着我必须将我的程序 GPL 化？(#LinkingWithGPL)

不完全是。这意味着您必须在与 GPL 兼容的许可证下发布您的程序（更准确地说，与您链接的组合中的其余代码接受的一个或多个 GPL 版本兼容）。然后，该组合本身可以在这些 GPL 版本下使用。

如果这样，我是否有机会在 Lesser GPL 下获得您的程序的许可？(#SwitchToLGPL)

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

您始终可以选择不使用我们的代码。

分发旨在与 Linux 内核链接的非自由驱动程序是否违反 GPL？(#NonfreeDriverKernelLinux)

Linux（GNU/Linux 操作系统中的内核）是在 GNU GPL 版本 2 下分发的。分发旨在与 Linux 链接的非自由驱动程序是否违反 GPL？

是的，这是一种违规行为，因为它实际上构成了一个更大的组合作品。用户应该将这些部件组合在一起的事实并没有真正改变任何事情。

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

我如何允许仅在受控接口下将专有模块与我的 GPL 覆盖的库链接？(#LinkingOverControlledInterface)

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

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

作为特殊例外，ABC 的版权所有者允许您将 ABC 程序与根据 GNU LGPL 发布的自由软件程序或库以及仅通过 ABCDEF 接口与 ABC 通信的独立模块组合。您可以在遵守 GNU GPL 中关于 ABC 的条款以及相关代码的许可的情况下复制和分发这样的系统，前提是当 GNU GPL 要求分发源代码时，您包括其他代码的源代码，并且您不修改 ABCDEF 接口。

请注意，制作 ABC 修改版本的人没有义务为他们的修改版本授予此特殊例外；是否这样做是他们的选择。GNU 通用公共许可证允许发布没有此例外的修改版本；此例外也使得发布保留此例外的修改版本成为可能。如果您修改了 ABCDEF 接口，则此例外不适用于您的 ABC 修改版本，并且您必须在分发修改版本时删除此例外。

此例外是 GNU 通用公共许可证第 3 版（“GPLv3”）第 7 节下的额外许可

此例外允许通过指定的接口（“ABCDEF”）与不同许可的模块链接，同时确保用户仍然可以像在 GPL 下通常那样接收源代码。

只有程序的版权所有者才能合法授权此例外。如果您自己编写了整个程序，那么假设您的雇主或学校没有主张版权，您就是版权所有者——因此您可以授权此例外。但是，如果您想在您的代码中使用其他作者的其他 GPL 覆盖的程序的部分，则您不能为它们授权此例外。您必须获得这些程序的版权所有者的批准。

我编写了一个应用程序，该应用程序与许多具有不同许可证的不同组件链接。我非常困惑我的程序需要满足什么许可要求。请您告诉我我可以使用哪些许可证？(#ManyDifferentLicenses)

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

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

“聚合”和其它类型的“修改版本”之间有什么区别？(#MereAggregation)

“聚合”由许多单独的程序组成，这些程序在同一张 CD-ROM 或其他媒体上一起分发。GPL 允许您创建和分发聚合，即使其他软件的许可证是非自由或与 GPL 不兼容的。唯一的条件是您不能在禁止用户行使每个程序各自许可证授予他们的权利的许可证下发布聚合。

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

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

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

在确定两个软件是否构成一个单独的作品时，代码位于一个或多个容器中的事实是否会有任何影响？ (#AggregateContainers)

不，容器的参与不会改变对它们是否是单独作品还是聚合的分析。

为什么 FSF 要求 FSF 版权程序的贡献者将版权分配给 FSF？如果我拥有 GPL 许可的程序的版权，我是否也应该这样做？如果应该，该怎么做？(#AssignCopyright)

我们的律师告诉我们，为了在法庭上更好地执行GPL，对抗违反者，我们应该尽可能地保持程序的版权状态简单。为此，我们要求每位贡献者要么将贡献的版权转让给FSF，要么放弃对贡献的版权。

我们还要求个人贡献者从其雇主（如果有）那里获得版权免责声明，以便我们能够确保这些雇主不会声称拥有这些贡献的所有权。

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

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

我可以修改GPL并制定修改后的许可证吗？(#ModifyGPL)

可以制作GPL的修改版本，但这往往会产生实际后果。

您可以在另一个许可证中合法使用GPL条款（可能经过修改），前提是您使用另一个名称称呼您的许可证，并且不包含GPL序言，并且您要充分修改末尾的使用说明，使其在措辞上明显不同，并且不提及GNU（尽管您描述的实际程序可能类似）。

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

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

请不要修改GPL，而应使用GPL第3版提供的例外机制。

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

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

这些要求是将您收到的GPL涵盖的代码包含在您自己的程序中的条件。

我可以将GPL用于软件以外的其他东西吗？(#GPLOtherThanSoftware)

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

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

LGPL如何与Java一起使用？(#LGPLJava)

请参阅本文了解详细信息。它的工作方式与设计、预期和期望的一样。

考虑这种情况：1）X根据GPL发布了项目V1。2）Y根据V1的修改和新代码为V2的开发做出了贡献。3）X想将V2转换为非GPL许可证。X需要Y的许可吗？(#Consider)

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

我想将GPL涵盖的软件合并到我的专有系统中。我没有使用该软件的许可，除了GPL给我的许可。我可以这样做吗？(#GPLInProprietarySystem)

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

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

但是，在许多情况下，您可以将GPL涵盖的软件与您的专有系统一起分发。为了有效地做到这一点，您必须确保自由程序和非自由程序保持一定的距离通信，并且它们没有以使其有效地成为单个程序的方式进行组合。

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

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

如果人们分发GPL涵盖的软件，称其为用户知道部分专有的系统的“一部分”，用户可能会对其关于GPL涵盖的软件的权利感到不确定。但是，如果他们知道他们收到的是一个免费程序加上另一个程序，并排在一起，那么他们的权利将是明确的。

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

抱歉，我们不会做出这样的例外。这样做是不对的。

我们追求的目标不是最大限度地增加用户数量。相反，我们试图将关键自由赋予尽可能多的用户。总的来说，专有软件项目阻碍而不是帮助自由事业。

我们偶尔会为帮助在GPL以外的许可下制作自由软件的项目而制定许可证例外。但是，我们必须看到充分的理由来证明这将推动自由软件事业。

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

我想将GPL涵盖的软件合并到我的专有系统中。我可以通过在GPL涵盖的部分和专有部分之间放置一个在GPL兼容的宽松许可（例如X11许可）下的“包装器”模块来做到这一点吗？(#GPLWrapper)

否。X11许可证与GPL兼容，因此您可以将模块添加到GPL涵盖的程序中，并将其置于X11许可证下。但是，如果将它们都合并到更大的程序中，则整个程序将包含GPL涵盖的部分，因此必须作为一个整体在GNU GPL下获得许可。

专有模块A仅通过X11许可的模块B与GPL涵盖的模块C通信的事实在法律上无关紧要；重要的是模块C包含在整个程序中。

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

GCC运行时库例外涵盖了libgcc、libstdc++、libfortran、libgomp、libdecnumber以及其他与GCC一起分发的库。该例外旨在允许人们在他们选择的条款下分发使用GCC编译的程序，即使这些库的部分作为编译过程的一部分包含在可执行文件中。要了解更多信息，请阅读我们的关于GCC运行时库例外的常见问题解答。

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

有两个原因。首先，一个普遍的原因。如果我们允许公司A制作一个专有文件，并且允许公司B分发与该文件链接的GPL涵盖的软件，那么其效果将是在GPL中打开一个足以让卡车驶过的大洞。这将为隐瞒对GPL涵盖的软件的所有修改和扩展的源代码提供全权委托。

让所有用户都可以访问源代码是我们的主要目标之一，因此我们绝对要避免这种情况。

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

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

如果程序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涵盖的程序的修改版本吗？(#ModifiedJustBinary)

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

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

是的。一般规则是，如果你分发二进制文件，你必须同时分发完整的相应源代码。关于你收到获取源代码的书面要约的情况的例外是相当有限的。

我想通过物理介质分发二进制文件，但不附带源代码。我可以通过 FTP 提供源代码吗？ (#DistributeWithSourceOnInternet)

GPL 第 3 版允许这样做；请参阅选项 6(b) 了解详细信息。在第 2 版下，你当然可以自由地通过 FTP 提供源代码，并且大多数用户将从那里获取。但是，如果他们中的任何一个人更希望通过邮寄方式在物理介质上获取源代码，你必须提供这种方式。

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

我的朋友收到了一份 GPL 许可的二进制文件，并附带了提供源代码的要约，他为我复制了一份。我可以使用该要约来获取源代码吗？ (#RedistributedBinariesGetSource)

是的，你可以。该要约必须对拥有附带二进制文件副本的每个人开放。这就是为什么 GPL 说你的朋友必须在给你二进制文件副本的同时给你一份要约副本——这样你才能利用它。

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

是的。第 6(d) 条允许这样做。但是，你必须提供人们可以遵循的清晰说明来获取源代码，并且你必须注意确保源代码在你分发目标代码期间始终可用。

我想以二进制形式分发 GPL 许可程序的扩展版本。分发原始版本的源代码就足够了吗？ (#DistributeExtendedBinary)

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

自由软件的一个主要思想是，用户应该能够访问他们使用的程序的源代码。那些使用你的版本的人应该能够访问你的版本的源代码。

GPL 的一个主要目标是通过确保对自由程序的改进本身也是自由的，来建立自由世界。如果你发布 GPL 许可程序的改进版本，你必须在 GPL 下发布改进的源代码。

我想分发二进制文件，但分发完整的源代码很不方便。如果我向用户提供与“标准”版本的差异以及二进制文件，可以吗？ (#DistributingSourceIsInconvenient)

这是一个善意的请求，但这种提供源代码的方法实际上不起作用。

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

因此，你需要提供完整的源代码，而不仅仅是差异，以及二进制文件。

我可以在网络服务器上提供二进制文件，但只向订购的人发送源代码吗？ (#AnonFTPAndSendSources)

如果你在网络服务器上提供目标代码，你也必须在网络服务器上提供相应的源代码。最简单的方法是在同一服务器上发布它们，但如果你愿意，你也可以提供从另一个服务器甚至 版本控制系统获取源代码的说明。无论你做什么，源代码都应该像目标代码一样容易访问。这都在 GPLv3 的第 6(d) 条中指定。

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

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

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

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

GPL 是否要求我提供可以构建以匹配我分发的二进制文件的确切哈希值的源代码？ (#MustSourceBuildToMatchExactHashOfBinary)

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

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

GPL 允许任何人制作修改版本并使用它，而无需将其分发给他人。这家公司所做的就是这种情况的一个特例。因此，该公司不必发布修改后的源代码。当修改后的程序根据 GNU Affero GPL 的条款许可时，情况就不同了。

将此与网站包含或链接到在用户访问网站时分发给用户的单独 GPL 许可程序的情况进行比较（通常用 JavaScript 编写，但也使用其他语言）。在这种情况下，必须根据 GPL 的条款向用户发布正在分发的程序的源代码。

一家公司正在网站上运行根据 GNU Affero GPL (AGPL) 许可的程序的修改版本。AGPL 是否说他们必须发布其修改后的源代码？ (#UnreleasedModsAGPL)

GNU Affero GPL 要求修改后的软件版本向通过计算机网络与之交互的所有用户提供接收源代码的机会。该公司所做的事情属于该含义，因此该公司必须发布修改后的源代码。

在一个组织或公司内部制作和使用多个副本是否属于“分发”？ (#InternalDistribution)

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

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

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

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

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

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

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

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

如果分发的程序没有包含其他人的 GPL 许可作品，那么该公司没有违反 GPL（有关更多信息，请参见“GPL 许可程序的开发者是否受 GPL 约束？”）。但是它对你可以使用该程序做什么做了两个矛盾的声明：你可以重新分发它，而且你不能。在接受副本之前，要求澄清该程序的使用条款是有意义的。

为什么一些 GNU 库是在普通 GPL 而不是 Lesser GPL 下发布的？ (#WhySomeGPLAndNotLGPL)

对任何特定库使用 Lesser GPL 都构成了对自由软件的退让。这意味着我们部分放弃了捍卫用户自由的尝试，以及分享基于 GPL 许可软件构建的内容的一些要求。就其本身而言，这些都是更糟糕的改变。

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

最好在每个库上尝试使用 LGPL 一段时间，看看它是否有帮助，如果 LGPL 没有帮助，则改回 GPL。但这不可行。一旦我们对特定库使用 LGPL，改回去将很困难。

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

为什么程序应该说“GPL 第 3 版或任何更高版本”？ (#VersionThreeOrLater)

我们有时会不时地（以数年为间隔）更改 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。

使用一个声明某个程序只能在最新版本的 GNU GPL 下使用的许可，这是一个好主意吗？ (#OnlyLatestVersion)

你不应该这样做的原因是，有一天它可能会导致自动撤销用户以前拥有的某些权限。

假设一个程序在 2000 年以“最新 GPL 版本”发布。当时，人们可以在 GPLv2 下使用它。当我们在 2007 年发布 GPLv3 时，每个人都将被迫改为在 GPLv3 下使用它。

有些用户甚至可能不知道 GPL 第 3 版——但他们将被要求使用它。他们可能会因为没有收到消息而无意中违反程序的许可。这是一种对待人们的糟糕方式。

我们认为，除了因违规外，收回已授予的权限是错误的。如果你的自由可以被撤销，那么它就不是真正的自由。因此，如果你在某个许可版本下获得了某个程序版本的副本，你始终应该拥有该许可版本授予的权利。在“GPL 第 N 版或任何更高版本”下发布坚持了该原则。

为什么你不将 GPL 用于手册？ (#WhyNotGPLForManuals)

可以使用 GPL 用于手册，但 GNU 自由文档许可证 (GFDL) 更适合用于手册。

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

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

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

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

GPL 如何应用于字体？ (#FontException)

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

要使用此例外，请将此文本添加到软件包中每个文件的许可声明中（在可能的范围内），在说明该文件根据 GNU GPL 分发的文本的末尾。

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

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

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

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

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

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

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

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

但是，如果你将非自由库与源代码链接在一起，那将是你需要处理的问题。这并不妨碍在 GPL 下发布源代码，但如果库不符合“系统库”例外情况，你应该附加一个明确的通知，允许将你的程序与它们链接。关于使用与 GPL 不兼容的库的常见问题解答条目提供了有关如何执行此操作的更多信息。

是否有 GPL 的其他语言的翻译？ (#GPLTranslations)

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

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

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

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

热心的人有时会主动为我们做翻译工作。如果问题是找到人来完成这项工作，那么这将解决它。但实际问题是错误的风险，而主动提供帮助并不能避免风险。我们不可能批准非律师编写的翻译。

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

• 将人们推荐给非官方翻译。这意味着我们允许人们编写 GPL 的翻译，但我们不批准它们在法律上有效且具有约束力。

  未经批准的翻译不具有法律效力，并且应明确说明。它应标记如下

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

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

  但是，在商业活动中使用 GNU 软件的企业以及进行公共 ftp 分发的人员，应该检查真正的英文 GPL，以确保其允许的内容。

• 发布仅在单个国家/地区有效的翻译。

  我们正在考虑发布仅在一个国家/地区正式有效的翻译的想法。这样，如果出现错误，它将仅限于该国家/地区，并且造成的损害不会太大。

  要进行翻译，仍然需要一位有同情心且有能力的律师付出大量的专业知识和努力，因此我们不能保证很快就会进行任何此类翻译。

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

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

但是，当扩展解释器以提供与其他设施的“绑定”（通常但不一定是库）时，被解释的程序会通过这些绑定有效地链接到它使用的设施。JNI 或 Java 本机接口是这种设施的一个例子；以这种方式访问的库与调用它们的 Java 程序动态链接。

因此，如果这些设施是在与 GPL 不兼容的许可下发布的，则情况类似于以任何其他方式与与 GPL 不兼容的库链接。这意味着

1. 如果您正在编写代码并以GPL协议发布，您可以声明一个明确的例外，允许将其与那些不兼容GPL的工具进行链接。
2. 如果您根据GPL协议编写并发布了该程序，并且您专门设计它与这些工具一起工作，人们可以将其视为一个隐含的例外，允许他们将其与这些工具进行链接。但如果您打算这样做，最好明确说明。
3. 您不能使用别人的受GPL保护的代码，或者在其中添加此类例外。只有该代码的版权持有者才能添加例外。

谁有权执行GPL？(#WhoHasThePower)

由于GPL是一个版权许可，它可以由软件的版权持有者执行。如果您发现违反GPL的行为，您应该通知相关受GPL保护的软件的开发人员。他们要么是版权持有者，要么与版权持有者有联系。

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

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

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

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

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

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

当然，如果您的软件不是自由的，它就不是对我们社区的贡献，并且重视自由的人会拒绝使用它。只有愿意放弃自由的人才会使用您的软件，这意味着它实际上会起到诱导人们失去自由的作用。

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

我刚发现一家公司有一份GPL程序的副本，并且需要花钱才能获得它。他们没有在互联网上提供，难道不是违反了GPL吗？(#CompanyGPLCostsMoney)

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

GPL要求的是，他必须有如果他愿意向您分发副本的自由。一旦版权持有人确实将该程序的副本分发给某人，该人就可以自行决定将该程序重新分发给您或任何其他人。

我可以发布一个带有许可证的程序，该许可证声明您可以在GPL下分发其修改版本，但您不能在GPL下分发原始版本吗？(#ReleaseNotOriginal)

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

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

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

将副本转移到多数控股的子公司是否构成发行？(#DistributeSubsidiary)

是否将副本转移到此子公司或从该子公司转移构成“发行”，这需要在每个案例中根据相应司法管辖区的版权法来决定。GPL不能也不可能凌驾于当地法律之上。美国版权法对此点并非完全明确，但似乎不认为这是发行。

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

软件安装程序可以要求人们单击同意GPL吗？如果我根据GPL获得一些软件，我是否需要同意任何事情？(#ClickThrough)

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

仅同意GPL不会对您施加任何义务。您不需要同意任何事情来仅使用在GPL下许可的软件。只有当您修改或分发软件时，您才有义务。如果您真的不喜欢单击同意GPL，没有什么可以阻止您修改受GPL保护的软件来绕过此操作。

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

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

一些GPL软件的分销商在其伞式最终用户许可协议中或作为其下载过程的一部分，要求我“声明并保证”我位于美国或我打算按照相关的出口管制法律分发该软件。他们为什么要这样做，这是否违反了这些分销商在GPL下的义务？(#ExportWarranties)

这不是违反GPL。这些分销商（几乎所有都是销售自由软件发行版和相关服务的商业企业）正在努力降低他们自己的法律风险，而不是控制您的行为。如果他们明知地将软件出口到某些国家/地区，或者如果他们将软件提供给他们知道会进行此类出口的各方，那么美国的出口管制法可能会让他们承担责任。通过要求他们的客户和其他他们分发软件的对象提供这些声明，他们可以在以后被监管机构询问他们知道他们分发的软件将最终流向何处时保护自己。他们不是在限制您对软件的使用，而只是在防止他们自己因您的任何行为而受到指责。由于他们没有对软件施加额外的限制，因此他们没有违反GPLv3的第10节或GPLv2的第6节。

FSF反对将美国出口管制法应用于自由软件。这些法律不仅与软件自由的总体目标不兼容，而且没有达到合理的政府目的，因为目前自由软件应该而且始终可以从几乎每个国家的各方获得，包括没有出口管制法律并且不参与美国主导的贸易禁运的国家/地区。因此，没有哪个国家的政府实际上因美国出口管制法而被剥夺了自由软件，而就我们而言，没有哪个国家的公民应该被剥夺自由软件，无论他们政府的政策如何。从我们这里可以获得由FSF发布的所有GPL许可的软件副本，而无需对您居住地或您打算做什么做出任何表示。与此同时，FSF理解位于美国的商业分销商遵守美国法律的愿望。他们有权选择向谁分发自由软件的特定副本；除非他们添加超出GPL允许的合同限制，否则行使该权利不会违反GPL。

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

不可以。在这种情况下，要求继续支付费用会限制用户运行程序的能力。这是在GPL之上的附加要求，而许可证禁止这样做。

我如何从（L）GPLv2升级到（L）GPLv3？(#v3HowToUpgrade)

首先，在您的软件包中包含新版本的许可证。如果您在您的项目中使用LGPLv3，请务必包含GPLv3和LGPLv3的副本，因为LGPLv3现在是作为GPLv3之上的附加权限集编写的。

其次，将您所有现有的v2许可证通知（通常在每个文件的顶部）替换为GNU许可证操作指南上提供的新的推荐文本。它更具前瞻性，因为它不再包含FSF的邮政地址。

当然，任何描述性文本（例如在README中）中谈论的软件包许可证也应进行适当的更新。

GPLv3如何使BitTorrent分发更轻松？(#BitTorrent)

由于GPLv2是在软件的对等分发变得普遍之前编写的，因此当您以这种方式共享代码时，很难满足其要求。确保在BitTorrent上分发GPLv2目标代码时符合要求的最佳方法是在同一个torrent中包含所有相应的源代码，这成本高昂。

GPLv3通过两种方式解决了这个问题。首先，下载此torrent并作为该过程的一部分将数据发送给其他人的人无需执行任何操作。这是因为第9节说：“仅由于使用对等传输接收副本而发生的受保护作品的辅助传播也不需要接受[许可证]。”

其次，GPLv3的第6(e)节旨在通过告诉接收者在公共网络服务器上的可用位置，为分销商（最初种子torrent的人）提供一种清晰直接的方式来提供源代码。这确保了每个想获得源代码的人都可以这样做，并且对分销商几乎没有麻烦。

什么是tivoization？GPLv3如何防止它？(#Tivoization)

某些设备使用可以升级的自由软件，但其设计方式不允许用户修改该软件。有很多不同的方法可以做到这一点；例如，有时硬件会对已安装的软件进行校验和检查，如果与预期的签名不匹配，则会关闭。制造商通过向您提供源代码来遵守GPLv2，但您仍然没有自由修改您正在使用的软件。我们称这种做法为“tivoization”（蒂沃化）。

当人们分发包含在GPLv3许可下的软件的用户产品时，第6节要求他们向您提供修改该软件所必需的信息。“用户产品”是许可证中专门定义的术语；用户产品的示例包括便携式音乐播放器、数字录像机和家庭安全系统。

GPLv3是否禁止DRM？ (#DRMProhibited)

它不禁止；您可以使用根据GPLv3发布的代码来开发您喜欢的任何类型的DRM技术。但是，如果您这样做，第3节指出，该系统将不被视为有效的技术“保护”措施，这意味着如果有人破坏了DRM，她也可以自由分发她的软件，而不受DMCA和类似法律的阻碍。

像往常一样，GNU GPL并不限制人们在软件中做什么，它只是阻止他们限制他人。

我可以使用GPL来许可硬件吗？ (#GPLHardware)

任何可以受版权保护的材料都可以根据GPL许可。GPLv3还可以用于许可受其他类似版权的法律（例如半导体掩模）保护的材料。因此，例如，您可以在GPL下发布物理对象或电路的图纸。

在许多情况下，版权不涵盖根据图纸制造物理硬件。在这些情况下，无论您使用什么许可证，您对图纸的许可都不能控制制造或销售物理硬件。当版权涵盖制造硬件时，例如IC掩模，GPL会以一种有用的方式处理这种情况。

我使用公钥密码术来签署我的代码以确保其真实性。GPLv3是否真的会迫使我发布我的私钥？ (#GiveUpKeys)

不会。您唯一需要发布签名密钥的情况是，您在用户产品中传递GPL许可的软件，并且其硬件在软件运行前会检查该软件的有效加密签名。在那种特定情况下，您将被要求按需向任何拥有该设备的人提供密钥，以便在该设备上签名并安装修改后的软件，使其可以运行。如果设备的每个实例都使用不同的密钥，那么您只需要向每个购买者提供该实例的密钥。

GPLv3是否要求选民能够修改在投票机中运行的软件？ (#v3VotingMachine)

不会。分发包含在GPLv3许可下的软件的公司的最多要求是向拥有目标代码副本的人提供该软件的源代码和安装信息。使用投票机的选民（如任何其他自助服务亭）不会拥有它，即使是暂时的，因此选民也不会拥有其中的二进制软件。

但是请注意，投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由的，并不意味着您可以信任该计算机进行投票。我们认为计算机不能被信任用于投票。投票应该在纸上进行。

GPLv3是否具有“专利报复条款”？ (#v3PatentRetaliation)

实际上，是的。第10节禁止传递软件的人对其他被许可人提起专利诉讼。如果有人仍然这样做，第8节解释了他们将如何失去他们的许可证以及随之而来的任何专利许可证。

我可以在根据与GPL不兼容的许可证许可的文档中使用受GPL保护的源代码片段吗？ (#SourceCodeInDocumentation)

如果这些片段足够小，您可以根据合理使用或类似法律将其纳入，那么可以。否则，不行。

GPLv3第6节的开头说，我可以在“第4节和第5节的条款下”以目标代码形式传递受保护的作品，前提是我还满足第6节的条件。这是什么意思？ (#v3Under4and5)

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

我的公司拥有许多专利。多年来，我们以“GPL第2版或任何更高版本”的条款为项目贡献了代码，并且该项目本身也以相同的条款分发。如果用户决定在GPLv3下使用该项目的代码（包含我的贡献），这是否意味着我已经自动向该用户授予了GPLv3的明确专利许可？ (#v2OrLaterPatentLicense)

不会。当您传递GPL许可的软件时，您必须遵循许可证的特定版本的条款和条件。当您这样做时，该版本定义了您必须承担的义务。如果用户也可以选择使用更高版本的GPL，那仅仅是他们拥有的额外许可——它不要求您也履行更高版本的GPL的条款。

不要认为这意味着您可以用您的专利威胁社区。在许多国家/地区，根据GPLv2分发软件会为接收者提供隐含的专利许可，以行使他们在GPL下的权利。即使没有，任何考虑积极执行其专利的人都是社区的敌人，我们将捍卫自己免受这种攻击。

如果我分发一个链接到我修改过的LGPLv3许可的库的专有程序，那么为了确定我正在进行的明确专利许可授权的范围，什么是“贡献者版本”——它只是库，还是整个组合？ (#LGPLv3ContributorVersion)

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

GPLv3是否与GPLv2兼容？ (#v2v3Compatibility)

不兼容。许多要求已从GPLv2更改为GPLv3，这意味着GPLv2的精确要求在GPLv3中不存在，反之亦然。例如，GPLv3的终止条件比GPLv2的终止条件宽松得多，因此与GPLv2的终止条件不同。

由于这些差异，这两个许可证不兼容：如果您尝试将根据GPLv2发布的代码与根据GPLv3发布的代码组合在一起，您将违反GPLv2的第6节。

但是，如果代码根据GPL“第2版或更高版本”发布，则与GPLv3兼容，因为GPLv3是它允许的选项之一。

GPLv2是否要求提供安装信息？ (#InstInfo)

GPLv3明确要求重新分发包括所有必要的“安装信息”。GPLv2没有使用该术语，但它确实要求重新分发包含用于控制可执行文件的编译和安装的脚本以及完整且对应的源代码。这涵盖了GPLv3称为“安装信息”的部分，但不是全部。因此，GPLv3关于安装信息的要求更强。

“纠正”违反GPLv3的行为是什么意思？ (#Cure)

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

GPLv3中的保证和责任免责声明似乎是针对美国法律的。我可以将我自己的免责声明添加到我自己的代码中吗？ (#v3InternationalDisclaimers)

可以。第7节允许您添加自己的免责声明，特别是7(a)。

我的程序具有非视觉性质的交互式用户界面。我如何遵守GPLv3中的适当法律声明要求？ (#NonvisualLegalNotices)

您需要做的就是确保您的界面中用户可以方便地获得适当的法律声明。例如，如果您编写了音频界面，则可以包含一个大声朗读通知的命令。

如果我在我公司给同事一份GPLv3许可的程序副本，我是否将该副本“传递”给了该同事？ (#v3CoworkerConveying)

只要您们都在公司工作中使用该软件，而不是个人使用，那么答案是否定的。副本属于公司，不属于您或您的同事。此复制是传播，而不是传递，因为公司没有向其他人提供副本。

如果我分发GPLv3许可的程序，我是否可以提供用户修改程序后失效的保修？ (#v3ConditionalWarranty)

可以。正如如果用户修改了设备内部的软件，则不需要对设备进行保修一样，您也不需要提供涵盖某人使用GPLv3许可的软件可能进行的所有活动的保修。

为什么您决定将GNU Affero GPLv3编写为单独的许可证？ (#SeparateAffero)

GPLv3的早期草案允许许可方在第7节中添加类似Affero的要求以发布源代码。但是，一些开发和依赖自由软件的公司认为此要求过于繁重。他们希望避免使用此要求的代码，并表示担心检查代码是否有此额外要求的管理成本。通过将GNU Affero GPLv3作为单独的许可证发布，并在其中和GPLv3中添加允许这些许可证下的代码相互链接的规定，我们在实现所有最初目标的同时，更容易确定哪些代码具有源代码发布要求。

为什么您在GPLv3中发明了新术语“传播”和“传递”？ (#WhyPropagateAndConvey)

GPLv2中使用的术语“分发”是从美国版权法中借用的。多年来，我们了解到，一些司法管辖区在其自己的版权法中使用了相同的词，但赋予了它不同的含义。我们发明了这些新术语，以便尽可能清楚地表达我们的意图，无论在何处解释许可证。它们在世界上任何版权法中都没有使用，我们直接在许可证中提供了它们的定义。

我想在GPL下许可我的代码，但我也想明确表示它不能用于军事和/或商业用途。我可以这样做吗？ (#NoMilitary)

不可以，因为这两个目标相互矛盾。GNU GPL专门设计为防止添加进一步的限制。GPLv3在第7节中允许非常有限的一组限制，但用户可以删除任何其他添加的限制。

更一般地说，限制谁可以使用程序或用于什么的许可证不是自由软件许可证。

GPLv3中的“传递”是否与GPLv2中的“分发”含义相同？ (#ConveyVsDistribute)

是的，或多或少。在执行GPLv2的过程中，我们了解到一些司法管辖区在其自己的版权法中使用了“分发”一词，但赋予了它不同的含义。我们发明了一个新术语，以明确我们的意图，并避免这些差异可能引起的任何问题。

GPLv3将“向公众提供”作为传播的一个示例。这是什么意思？提供是一种传递形式吗？ (#v3MakingAvailable)

“向公众提供”的一个示例是将软件放在公共Web或FTP服务器上。在您执行此操作之后，可能需要一段时间才会有人真正从您那里获得该软件——但是由于它可能立即发生，因此您也需要立即履行GPL的义务。因此，我们定义传递包括此活动。

既然分发和向公众提供是 GPLv3 中也属于传播的形式，那么有哪些不构成传播的传播示例呢？ (#PropagationNotConveying)

为自己制作软件副本是不构成传播的主要形式。你可能会这样做，以便在多台计算机上安装软件，或制作备份。

为了优化性能，将 GPL 许可的二进制文件预链接到系统上的各种库是否算作修改？ (#Prelinking)

否。预链接是编译过程的一部分；它不会引入任何超出编译其他方面要求的许可要求。如果你允许将程序链接到库，那么也可以预先链接它们。如果你分发预链接的目标代码，则需要遵守第 6 节的条款。

如果有人在笔记本电脑上安装了 GPL 许可的软件，然后将笔记本电脑借给朋友，而没有提供该软件的源代码，他们是否违反了 GPL？ (#LaptopLoan)

否。在我们调查过此问题的司法管辖区中，这种借贷不被视为传播。笔记本电脑的所有者在 GPL 下没有任何义务。

假设两家公司试图通过一家公司发布签名软件，另一家公司发布只能运行第一家公司签名软件的用户产品来规避提供安装信息的要求。这是否违反 GPLv3？ (#TwoPartyTivoization)

是的。如果两个当事方试图共同规避 GPL 的要求，他们都可能因版权侵权而被追究责任。尤其如此，因为传播的定义明确包括使某人对次要侵权负责的活动。

如果我在 FTP 服务器上提供二进制文件，并通过指向版本控制系统（如 CVS 或 Subversion）中源代码存储库的链接来提供源代码，我是否符合 GPLv3？ (#SourceInCVS)

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

在用户产品中传播 GPLv3 覆盖的软件的人是否可以使用远程证明来防止用户修改该软件？ (#RemoteAttestation)

否。“安装信息”的定义（当软件在用户产品内部传播时必须与源代码一起提供）明确指出：“这些信息必须足以确保修改后的目标代码的持续运行在任何情况下都不会仅仅因为进行了修改而被阻止或干扰。” 如果设备以某种方式使用远程证明，则安装信息必须为你提供某种方式，使你修改后的软件能够将自身报告为合法的。

GPLv3 中“网络通信的规则和协议”是什么意思？ (#RulesProtocols)

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

这些规则不包括任何与通过网络传输的数据没有直接关系的内容。例如，如果网络上的服务器向你的设备发送用户消息，仅仅因为你修改了软件使其不显示消息，你对网络的访问也不应被拒绝。

根据 GPLv3 提供安装信息的发行商无需为产品提供“支持服务”。你所说的“支持服务”是什么样的？ (#SupportService)

这包括许多设备制造商提供的帮助你安装、使用或排除产品故障的服务。如果设备依赖于访问 Web 服务或类似技术才能正常运行，那么这些服务通常应该仍然可用于修改后的版本，但须遵守第 6 节中关于访问网络的条款。

在 GPLv3 和 AGPLv3 中，“无论本许可证的任何其他规定如何”是什么意思？ (#v3Notwithstanding)

这仅仅意味着以下条款优先于许可证中可能与它们冲突的任何其他条款。例如，如果没有此文本，某些人可能会声称你不能将 GPLv3 下的代码与 AGPLv3 下的代码组合，因为 AGPL 的附加要求将被归类为 GPLv3 第 7 节下的“进一步限制”。此文本明确表明我们预期的解释是正确的，你可以进行组合。

此文本仅解决许可证不同条款之间的冲突。当两个条件之间没有冲突时，你必须同时满足这两个条件。这些段落并未赋予你无视许可证其余部分的空白授权，而是划定了非常有限的例外情况。

在 AGPLv3 下，当我根据第 13 节修改程序时，它必须提供什么相应的源代码？ (#AGPLv3CorrespondingSource)

“相应的源代码”在许可证的第 1 节中定义，你应该提供它所列出的内容。因此，如果你的修改版本依赖于其他许可证（如 Expat 许可证或 GPLv3）下的库，则相应的源代码应包括这些库（除非它们是系统库）。如果你修改了这些库，则必须为它们提供你修改后的源代码。

第 13 节第一段的最后一句话仅是为了加强大多数人自然会假设的内容：即使与 GPLv3 下的代码的组合是通过第 13 节中的特殊例外处理的，相应的源代码仍应包括以这种方式与程序组合的代码。这句话并不意味着你仅需要提供 GPLv3 下覆盖的源代码；相反，这意味着此类代码不排除在相应的源代码定义之外。

在 AGPLv3 中，“通过计算机网络与[软件]远程交互”算作什么？ (#AGPLv3InteractingRemotely)

如果程序明确设计为接受用户请求并通过网络发送响应，则它符合这些标准。属于此类别的程序的常见示例包括 Web 和邮件服务器、交互式 Web 应用程序以及在线游戏的服务器。

如果程序并非明确设计为通过网络与用户交互，而是在恰好这样做的环境中运行，则它不属于此类别。例如，应用程序不需要仅仅因为用户通过 SSH 或远程 X 会话运行它而提供源代码。

GPLv3 的“你”的概念与 Apache 许可证 2.0 中的“法律实体”的定义相比如何？ (#ApacheLegalEntity)

它们实际上是相同的。Apache 许可证 2.0 中“法律实体”的定义在各种法律协议中非常标准，以至于如果法院在没有明确定义的情况下不以相同的方式解释该术语，那将非常令人惊讶。我们完全期望他们在查看 GPLv3 并考虑谁有资格成为被许可人时也这样做。

在 GPLv3 中，“程序”指的是什么？是指所有根据 GPLv3 发布过的程序吗？ (#v3TheProgram)

术语“程序”是指根据 GPLv3 许可的特定作品，并且由特定的被许可人从上游许可人或分发商处接收。程序是你收到的给定 GPLv3 许可实例中的特定软件作品，如你所收到的那样。

“程序”不能指“所有根据 GPLv3 许可的作品”；这种解释由于多种原因而毫无意义。我们已经发布了对“程序”一词的分析，以供那些希望了解更多信息的人使用。

如果我只复制 GPL 覆盖的程序并运行它们，而不分发或传播给其他人，许可证对我有什么要求？ (#NoDistributionRequirements)

没有。GPL 对此活动不施加任何条件。

如果某些网络客户端软件在 AGPLv3 下发布，它是否必须能够向与其交互的服务器提供源代码？ (#AGPLv3ServerAsUser)

AGPLv3 要求程序向“所有通过计算机网络远程与其交互的用户”提供源代码。你是否将该程序称为“客户端”或“服务器”并不重要，你需要问的问题是，是否有合理的期望认为某人会通过网络远程与该程序交互。

对于在 AGPL 下许可的运行代理服务器的软件，我如何向与该代码交互的用户提供源代码？ (#AGPLProxy)

对于代理服务器上的软件，你可以通过向该类代理用户传递消息的正常方法提供源代码。例如，Web 代理可以使用着陆页。当用户最初开始使用代理时，你可以将他们定向到包含源代码以及你选择提供的任何其他信息的页面。

AGPL 说你必须向“所有用户”提供该提议。如果你知道某个用户已经看到了当前版本的软件的提议，则不必再次向该用户重复该提议。

各种 GNU 许可证之间如何兼容？ (#AllCompatibility)

各种 GNU 许可证之间享有广泛的兼容性。你可能无法组合使用这些许可证中的两个许可证下的代码的唯一时间是，当你想要使用仅在旧版本许可证下的代码与在新版本下的代码时。

下面是 GNU 许可证各种组合的详细兼容性矩阵，为特定情况提供易于使用的参考。它假设其他人已在这些许可证之一下编写了一些软件，并且你希望以某种方式将该软件中的代码合并到你正在发布的项目中（无论是你自己的原创作品，还是其他人软件的修改版本）。在表格顶部的列中找到你的项目许可证，然后在左侧的行中找到其他代码的许可证。它们相遇的单元格会告诉你是否允许这种组合。

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

在矩阵中，每个声明为 GPLv3 的地方，关于兼容性的相同声明也适用于 AGPLv3。

跳过兼容性矩阵

跳过脚注

1：在这种情况下，您必须遵循 GPLv2 的条款来合并代码。您不能利用 GPL 较新版本的条款。

2：虽然您可以使用 GPLv2 或更高版本发布您的原始作品和/或您在 GPLv2 或更高版本下收到的作品的修改版本，但您正在使用的仅限 GPLv2 的代码必须保持在仅限 GPLv2 下。只要您的项目依赖于该代码，您就无法将您自己的代码的许可升级到 GPLv3 或更高版本，并且作为一个整体（您的项目和其他代码的任何组合）的作品只能在 GPLv2 的条款下传递。

3：如果您有能力在 GPLv2 或任何更高版本下发布该项目，您可以选择在 GPLv3 或任何更高版本下发布它——一旦您这样做，您将能够合并在 GPLv3 下发布的代码。

4：如果您有能力在 LGPLv2.1 或任何更高版本下发布该项目，您可以选择在 LGPLv3 或任何更高版本下发布它——一旦您这样做，您将能够合并在 LGPLv3 下发布的代码。

5：在这种情况下，您必须遵循 LGPLv2.1 的条款来合并代码。您不能利用 LGPL 较新版本的条款。

6：如果您这样做，只要项目包含仅在 LGPLv2.1 下发布的代码，您就无法将项目的许可升级到 LGPLv3 或更高版本。

7：LGPLv2.1 允许您将代码重新许可在自 GPLv2 以来的任何 GPL 版本下。 如果在这种情况下，您可以将 LGPL 许可的代码切换为使用适当版本的 GPL（如表格所示），则可以进行此组合。

8：LGPLv3 是 GPLv3 加上在这种情况下您可以忽略的额外权限。

9：由于 GPLv2 不允许与 LGPLv3 组合，因此在这种情况下您必须在 GPLv3 的条款下传递该项目，因为它允许这种组合。