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

1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
2. 对于 GNU 许可证的一般了解
3. 在您的程序中使用 GNU 许可证
4. 依据 GNU 许可证分发程序
5. 在编写其他程序时采用依据 GNU 许可证发布的程序
6. 将作品与依据 GNU 许可证发布的代码相结合
7. 关于违反 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 项目贡献程序，请写信至 <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，遵循类似的策略可能是一个好主意。如果您需要更多信息，请联系 <licensing@gnu.org>。

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

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

您可以在其他许可证中合法使用GPL条款（可能是修改过的），只要您以其他名称来称呼您的许可证，并且不包括 GPL 的引言preamble，只要您对最后的使用说明进行了足够多的修改，使其措辞明显不同，没有提到 GNU（尽管您描述的实际过程可能与其类似）。

如果您想在修改后的许可证中使用我们的引言，请写信至 <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）