这是针对英文原版页面的中文翻译。

GNU GPL v2.0 常见问题

“GPL”代表什么？

“GPL”代表“通用公共许可证”。其中最广泛使用的许可证是GNU通用公共许可证，简写为GNU GPL。它可以进一步简写为“GPL”，前提是大家明白这是指向GNU GPL。

自由软件是不是就意味着要用GPL？

绝不是那样—还有许多其他的自由软件许可证。我们有一个不完全的列表。为用户提供某些具体自由的许可证就是一个自由软件。

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

使用GNU GPL要求所有发布的改进版本都必须是自由软件。这意味着你可以避免和一个你自己的作品的专有修改版竞争。不过，在某些特殊的情况下，使用更宽泛的许可证会更好。

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

大多数GNU软件包使用GNU GPL，但是也有一些GNU程序（或部分程序）使用更宽泛的许可证，比如LGPL。我们这样做是战略性的。

使用GPL的软件就会变成GNU软件吗？

任何人都可以按照GNU GPL发布软件，但是这并不会使发布的软件变成GNU软件包。

把一个软件变成GNU软件包意味着明确地把它贡献给GNU工程。这在软件的开发者和GNU工程达成共识才行。如果你想为GNU工程贡献软件，请写信给<maintainers@gnu.org>。

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

你应该报告这个情况。首先，尽量查看事实情况。然后，告知出版者或版权持有者具体的GPL软件。如果他们是自由软件基金会，请写信给<license-violation@gnu.org>。如果不是，软件的维护者可能就是版权持有者、或者她能够告诉你谁是版权持有者，所以请报告给软件维护者。

为什么GPL允许用户公开他们的修改版？

自由软件的一个关键特点是用户有自由合作。允许愿意互相帮助的用户分享问题修复和软件改进是绝对必要的。

有些人建议不同于GPL的方法，就是要求改进版由原始作者通过。只要原始作者跟得上维护的需求，这个建议可能在实践上很不错，但是如果原作者（或多或少）停下来去干别的事或者没能顾及所有用户的需求，这个建议就没办法了。除了实际操作的问题，该建议也没有允许用户互相帮助。

有时，为了防止各种用户修改版的混淆，人们还建议对修改版进行控制。就我们的经验来说，混淆不是大问题。Emacs在GNU工程之外有很多版本，但是用户还是可以区分。GPL要求版本制作者署名，这样就可以区分版本并保护版本维护者的声誉。

GPL是否要求修改版的源代码公开？

GPL不要求你发布你的修改版或者任何一部分修改版。你有自由修改并自用，而不必发布。这个规则也适用于机构（包括公司）；机构可以做出修改版并在内部使用而不向其他外部组织发布。

但是如果你以某种方式把修改版向公众发布，GPL就要求你向用户提供修改版的源代码。

因此，GPL允许程序按某些方式发布，而不允许用其他的方式发布；但是，是不是发布由你来决定。

我是否可以在同一个电脑上使用一个GPL程序和另一个无关的非自由程序？

可以。GPL 的 “简单聚合” 条款明确允许这么做，但是这只是强调我们相信实际上真的这么做了。

如果我知道有人有一份GPL软件的拷贝，我是否可以要求他们给我一份？

不。GPL允许一个人制作和发行软件的拷贝，只是当这个人选择这样做的时候。这个人也有权利选择不发行该软件。

GPLv2中的“对任何第三方都有效的书面承诺”怎么理解？它是否意味着任何人都可以得到任何GPL程序的源代码？

如果你书面承诺提供源代码，那么提出源代码需求的人应该有资格得到源代码。

如果你商业发布二进制却不带源代码，那么GPL说你必须提供书面的在晚些时候发布源代码的承诺。当用户非商业性的再发布你的二进制时，他们必须附带这个书面承诺的拷贝。这意味着没有从你处获得二进制的用户仍然可以从你处获得源代码的拷贝，只要提供了此书面承诺。

我们要求此书面承诺对第三方有效的理由在于，间接获得二进制的用户也能够从你处获得源代码。

GPL说如果发布修改版，它就必须对所有第三方进行“许可证授权…。谁是第三方？

第2节说你发布的修改版必须对所有第三方使用GPL授权。“所有第三方”是指任何人—但是这并不要求你亲自为他们做事。这只是说他们对你的版本拥有来自你的许可证，是GPL。

我是否要对我的修改版声明版权？

我们并不要求你对你的修改声明版权。不过，在大多数国家，版权是默认就有的，所以如果你不想你的修改被版权限制，那么你需要明确地把它置于公开领域。

无论你是否对你的修改声明版权，你都必须作为整体按照GPL发布你的修改（如果你要发布你的修改版的话）。

如果一个程序合并了公有领域的代码和GPL的代码，我是否可以抽出其中的公有领域代码并按照公有领域的方式使用？

如果你能够区别哪些是公有领域部分和哪些不是，那么你可以这样做。如果该代码是被其开发者放到公有领域的，那么无论它在哪里，它都是公有领域的。

GPL是否允许销售软件的拷贝来赚钱？

是的，GPL允许任何人这样做。销售拷贝的权利是包含在自由软件的定义中。除了一个特殊的情况，你的收费没有限制。（这个例外就是对于仅有二进制发布的软件，你必须提供书面的源代码可获取承诺。）

GPL是否允许我对从我的发行网站下载软件进行收费？

是。你可以对你发行的拷贝按你所需报价。按照 GPLv2，如果你提供的是二进制发布，那么你还必须提供“对等的”源代码下载—。因此，下载源代码的费用不能高过下载二进制的费用。如果二进制是按照 GPLv3 来发布的，那么你必须按照同样的方式在同样的地方提供对等的源代码下载，而且不能收取额外的费用。

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

不。事实上，这种要求会让程序变成非自由的。如果人们不得不付费才能得到一份程序拷贝，或者他们必须通知某个具体的人，那么这个程序是非自由的。参看自由软件的定义。

GPL是一份自由软件许可证，因此它允许人们使用乃至再发布软件而不要求必须付费才能这样做。

你可以向人们收费来给出你的软件拷贝。但是当人们从其他人那里获得拷贝时，你不能要求人们向你付费。

如果我收费发行GPL软件，那么我是否被要求同时也要免费公布该软件？

不。但是如果有人付费获得拷贝，GPL给予她向公众发布的自由，收不收费都可以。例如，有人付费给你，然后将拷贝发布到一个公开的网站上。

GPL是否允许使用保密协议发行软件？

不。GPL说的是，从你处获得软件拷贝的任何人都有权再发布该拷贝，无论是否修改。你不得再限制该作品的发布。

如果你在获取FSF有版权的GPL软件时，有人要求你签署NDA，那么请立刻写信到license-violation@fsf.org通知我们。

如果违反事件涉及到其他的GPL代码持有人，请通知该版权持有者，就和你对付其他形式的GPL违反案例一样。

GPL是否允许使用保密协议发行修改版或beta版软件？

不。GPL说的是，修改版必须使用GPL所述的全部自由。因此，从你处获得修改版的人有权重新发布该软件（无论是否修改）。你不能使用带有更多限制的条款发布该软件的任何版本。

GPL是否允许使用保密协议开发修改版软件？

是的。例如，你可以签署一个开发修改版的合同，并同意只有在客户同意时才能发布你的修改。我们允许这样做是因为此时GPL的代码并没有按照NDA发布。

你也可以将你的修改按照GPL发布给你的客户，但是只有在客户同意时才能把它们发布给其他人。此时，GPL代码也没有按照NDA发布，或者说也没有按照任何附加条款发布。

GPL会赋予该客户再发布此版本的权利。此时，该客户可能会选择不执行该权利，但是她拥有该权利。

我想从我的工作中获得荣誉。我想让人们知道我写的代码。如果使用GPL，我还能这样做吗？

你当然可以从你的工作中获得荣誉。按照GPL发布程序的一个要求就是在版权声明处写上你的名字（假设你是版权拥有者）。GPL要求所有的拷贝都带有适当的版权声明。

为什么GPL要求在每个软件拷贝里都要包含一份GPL拷贝？

在每个拷贝里都包含许可证是关键性的，这样每个获得拷贝的人都知道他们的权利是什么。

包含一个指向许可证的URL而非许可证本身也许看起来很不错。但是你无法保证该URL五年或十年之后的有效性。20年后，今天我们所用的URL可能不再存在了。

无论网络发生什么变化，唯一能够确保拥有拷贝的人们还能看到许可证的方法就是在程序中包含许可证的拷贝。

如果软件作品不是很长会怎么样？

如果一个程序非常真的那么短小，那么你可以使用简单的全权许可许可证，而不必使用 GNU GPL。

为了节省空间，我是否可以不要GPL的前言或者如何在程序中使用GPL的部分？

前言和指导是构成完整GNU GPL许可证的组成部分，它们不应该被省略。事实上，GPL受版权保护，它只允许全文逐字复制。（你可以使用其法律术语制作另一个许可证，但是那就不是GNU GPL了。）

前言和指导加起来不过5000多字，不到GPL全文的1/3。除非软件包本身特别小，这点篇幅不会造成软件大小的显著变化。如果软件包本身很小，那么你可以使用一个简单全权许可证而不用GNU GPL。

怎么理解两个许可证是“兼容的”？

为了把两个程序（或者其主要部分）合成一个较大的程序，你需要某种许可才能做得到。如果这两个程序的许可证允许这么做，那么它们就是兼容的。如果无论如何都不能同时满足两个许可证，那么它们就是不兼容的。

对有些许可证来说，程序合成的方式也会影响许可证是否兼容—例如，它们可能允许把两个模块连接在一起，但是不允许把两个代码合成一个模块。

如果你只是想把两个程序安装到同一个系统中，那么它们的许可证没有必要是兼容的，因为安装并不是把它们合成一个大的程序。

许可证和“GPL兼容”是什么意思？

这就是说该许可证和GNU GPL兼容；你可以把按照该许可证发布的代码和按照GNU GPL发布的代码合成一个大的程序。

GNU GPL的所有版本本身都允许这么做；这些版本还允许这些组合的发布，前提是该组合是按照同版本的GNU GPL发布的。如果一个许可证也允许这么做，那么它就是和GPL兼容的。

我是否可以用非自由的库编写自由软件？

如果你这样做，那么你的程序将不能在自由的环境下全功能运行。如果你的程序依靠非自由库来完成某些工作，那么它就不能在自由的环境下做这些工作。如果它依靠非自由库才能工作，那么它就不能作为像GNU这样的自由操作系统的一部分；它超出了自由世界的极限。

所以，请你再考虑一下：你是否可以不使用非自由库来完成同样的工作？你是否可以写一个自由的库来代替那个非自由库？

如果你的软件已经使用了非自由库，那么改变这个可能有点晚了。你还是可以按照程序的现状来发布它，这比不发布要好一些。但是，请在README中说明该程序的一个不足是使用了非自由库，并把避免使用非自由库而完成同样的事情作为一个任务推荐给大家。请建议那些想继续为该程序工作的伙伴首先要做的就是摆脱那个非自由的库。

请注意，把某些非自由库和GPL自由软件合并起来可能还有法律问题。请参看关于GPL软件和GPL不兼容库的问题来了解更多信息。

GPL软件使用非GPL兼容库会有什么法律问题？

如果你连接的库是在以下 GPL 例外之中：

不过，作为特别例外，这样发布的源代码不必包含其运行之上的操作系统的常规内容（比如编译器和内核等，既不必包括源代码，也不必包括二进制），除非该部件本身就带有这些可执行文件。

那么你就不必为使用该程序做其他事情；发布整个程序源代码的要求不包括这些库，即使你发布的可执行文件的连接中包括它们。因此，如果该库需要和专有操作系统主要部分一起工作，GPL 认为人们可以连接你的库，没有额外条件。

如果你的程序连接了不在此例外之内的库，那么你需要在 GPL 之外增加你自己的例外。下面的版权声明和许可证声明就是让程序 连接 FOO 的许可：

Copyright (C) 四位阿拉伯数字年份 <版权持有人姓名>

本软件是自由软件；你可以按照由自由软件基金会发布的GNU通用公共许可证来再发布该软件或者修改该软件；你可以使用该许可证的第2版，或者（按照你的选择）使用该许可证的任何更新版本。

本程序的发布是希望它能发挥作用，但是并无担保；甚至也不担保其可销售性或适用于某个特殊的目的。请参看GNU通用公共许可证来了解详情。

该程序应该同时附有一份GNU通用公共许可证的拷贝；如果没有，请参看<https://www.gnu.org/licenses>。

把其他模块静态或动态地和ABC连接都构成基于ABC的组合作品。因此，整个组合都遵循GNU通用公共许可证的条款。

另外，作为一个特例，ABC 的版权持有者赋予你把 ABC 和自由软件或按照GNU LGPL发布的库合并的权利，其中 DEF 标准发布代码使用 XYZ 许可证（或者该代码的修改版，许可证不变）。你可以复制和发布该系统，其许可证条款是 ABC 使用的GNU GPL许可证和其他代码（假定你按照GNU GPL的发布要求包含了其他程序的源代码使用）的相关许可证。

请注意，修改 ABC 的人没有义务为他们的修改版赋予该特例；这是他们的选择。GNU通用公共许可证允许无特例发布修改版；该特例也使发布的修改版继续带有此特例成为可能。

你应当把这段文字放在每个适用该例外的文件中。

只有程序的版权持有者才能在法律上有效地授权该例外。如果你自己写了整个程序，并假定你的雇主或学校没有声称对此拥有版权，那么你就是版权持有者—因此你就可以做出此例外的授权。但是如果你想在你的程序中使用其他人的GPL程序，那么你不能代表其他人做出此例外的授权。你必须获得其他版权持有者的批准。

当其他人修改此程序时，他们不必对自己的代码做同样的例外声明—他们有权选择。

如果你要连接的库是非自由库，请同时参看使用非自由库撰写自由软件的部分。

我如何才拥有我的程序的版权从而可以把它按GPL发布？

按照伯尔尼公约，任何写出来的东西在其形式固定时就自动获得版权。所以，你对自己写的东西不必做任何事就“获得”其版权—只要没有其他人声称拥有你的作品。

不过，注册版权在美国是一个好主意。这对你处理在美国的侵权更有利。

其他人可能声称对你的作品拥有版权的情况是你是一个雇员或学生；此时，雇主或学校可能会主张你是为他们工作的，所以他们拥有版权。他们的主张是否有效取决于当地的法律、雇佣合同和工作性质等。如果有疑问，最好是咨询律师。

如果你觉得雇主或学校可能会有所主张，那么你可以通过让公司或学校的授权人签署版权免除声明来解决此问题。（你的上司或教授通常没有权利签署这样的免除声明。）

如果我的学校想把我的程序变成它的专有软件，那么我应该怎么办？

当下，许多大学会通过限制使用它们开发的知识和信息来获取资金，这种行为和商业公司没什么分别。（请同时参看“被收买的大学”，Atlantic月刊，2000年3月号，来了解关于此问题及其影响的一般性讨论。）

如果你看出你的学校可能会拒绝你把你的程序发布为自由软件，那么你越早提出这个问题越好。程序越接近正常工作的水平，学校管理方越倾向于剥夺你的程序并自己完成该程序。越在早期，你越有发言权。

所以，我们建议你在程序早期时就和校方讨论这个问题，比如，“如果你让我将程序按自由软件发布，那么我就完成它。”不要认为这是一种虚张声势。要想站到上风，你必须有勇气说出，“我的程序要么拥有自由，要么就不存在。”

能否提供一个手把手的GPL应用指导？

参看GPL指南页面。

我听说有人获得了一份按照其他许可证发布的GPL程序。这可能吗？

GNU GPL没有赋予用户为程序附加其他许可证的权利。但是，程序的版权持有者可以同时按照多个许可证发布自己的程序。其中一个可以是GNU GPL。

假设程序的版权持有者添加了许可证并且你从合法途径获得该程序的拷贝，那么你得到的程序拷贝带有的许可证就是你的拷贝适用的许可证。

我愿意把我写的程序按照GNU GPL发布，但是我也想在非自由软件里使用同样的代码。

虽然把程序发布为非自由软件总是一个道德污点，但是法律并没有阻碍你这么做。如果你是自己代码的版权持有者，那么你可以在不同时间按照不同的非排他许可证发布。

GPL程序的开发者和GPL绑定了吗？该开发者的活动会是违反GPL的吗？

严格来说，GPL是由开发者对其他人发布的的许可证，用于这些人使用、发布和改变该程序。开发者本人并不受到许可证的限制，所以无论开发者做什么，这都不是“违反”GPL。

不过，如果开发者做了某些若是用户做的话就会违反GPL的事，那么该开发者就必然会在社区就会失去道德上的立足之地。

开发并按照GPL发布了程序的开发者以后是否可以把该程序按照排他协议授权给第三方？

不行，因为公众已经有了按照GPL使用该程序的权利，并且该权利不可撤回。

我可否使用GPL下的编辑器，比如GNU Emacs，开发非自由软件？我可否使用GPL下的工具，比如GCC，编译非自由软件？

是的，因为编辑器和工具的版权并不包括你编写的代码。从法律上说，使用这些工具并不对你代码的许可证带来任何限制。

有些程序由于技术的原因会在输出时复制它自身的一部分—比如，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（不是LGPL）发布，是否意味着所有使用该库的软件都要使用GPL或GPL兼容的许可证？

是的，因为该程序实际上连接了该库。因此，GPL条款适用于整个组合。和该库连接的各个软件模块可能遵循各种GPL兼容的许可证，但是整个组合必须按照GPL许可证发布。请同时参看：许可证和“GPL兼容”是什么意思？

如果一个编程语言解释程序是按照GPL授权的，那么用该解释器编写的程序都要按照GPL兼容的许可证授权吗？

如果解释器只是解释一种语言，那么回答是否。被解释的程序对解释器来说，只是数据；像GPL这样的自由软件许可证，根据版权法，不能限制该解释器的数据。你可以用它来运行任何数据（被解释的程序）、以任何方式、而且没必要把数据按照某种许可证授权给任何人。

然而，当该解释器提供了对其他设施（通常是，但也不一定，库）的“绑定”，被解释的程序实际上就是使用这些绑定连接到了这些设施。因此，如果这些设施是按照GPL发布的，那么被解释的程序也必须按照和GPL兼容的方式发布。JNI或Java Native Interface就是这种机制的一个例子；当Java程序是和它调用的库动态地连接在一起的。这些库也和解释器连接在一起。如果解释器和这些库是静态连接，或者是动态连接到这些具体的库，那么它也应该按照和GPL兼容的方式发布。

另一个类似和常见的例子是解释器带有的库本身也是被解释的。比如，Perl带有很多Perl模块，Java带有很多Java类。这些库和调用它们的程序总是动态连接在一起的。

结果就是，如果你选择使用遵循GPL的Perl模块或Java类，那么你的程序必须按照GPL兼容方式发布，无论程序运行的Perl或Java解释器是按照什么许可证发布的。

我使用Microsoft Visual C++编写一个Windows应用，我要把它以GPL发布。GPL是否允许我的程序动态连接Visual C++运行库？

GPL 允许这么做，因为这些运行时库通常和你使用的编译器或解释器是配在一起的。所以，这个情况属于 GPL 第3节的例外。

但是这并不意味着编写一个只运行在 Windows 系统上的程序是一件好事。虽然这样的程序是自由软件，但是它是 “陷阱”（在这个例子中，它是一个 Windows 陷阱，不过效果和 Java 陷阱一样）。（历史注记：在2006年12月 Sun 公司正在 把 Java 平台按照 GNU GPL 发布。）

为什么原始的BSD许可证和GPL不兼容？

因为它强加了一个GPL没有的条款；就是，要求对程序做广告的条款。GPLv2第6节的陈述是：

你不能对被授权者获得的权利强加任何额外的限制。

广告条款正是这种额外的限制，因此它和GPL不兼容。

修正的BSD许可证没有这个广告条款，它就没有这个问题。

什么时候一个程序和它的插件会被认为是一个单一的结合在一起的程序？

这依赖于主程序如何调用插件。如果主程序使用fork和exec调用插件，那么它们之间通过共享或交换复杂数据结构而建立了密切的通信，这样它们就是一个单一的结合在一起的程序。如果主程序使用的是简单的fork和exec调用插件，并没有建立密切的通信，那么插件就是一个单独的程序。

如果主程序动态连接了插件，而且它们之间互相调用函数并共享数据结构，那么我们认为它们构成了一个单一的组合程序，主程序和插件必须被当作一个扩展来对待。如果主程序动态连接了插件，但是它们之间的通信限于调用插件的‘主’函数及其参数并等待其返回，那么这就是个可以算单一组合程序也可以算两个独立程序的临界情况。

使用共享内存来交换复杂数据结构的情况和动态连接基本类似。

如果一个按照 GPL 授权的程序使用插件，那么对插件的许可证有什么要求？

请参考这个问题来确定什么时候插件和主程序是一个单一的组合程序以及什么时候他们是独立的两个程序。

如果主程序和插件是一个单一的组合程序，那么就意味着插件必须按照GPL或GPL兼容的自由软件许可证发布，包括其源代码。如果主程序和插件是独立的两个程序，那么主程序的许可证对插件没有要求。

我为非自由软件写的插件可以使用GPL许可证吗？

请参考这个问题来确定什么时候插件和主程序是一个单一的组合程序以及什么时候他们是独立的两个程序。

如果它们构成了一个单一的组合程序，那么组合GPL的插件和非自由主程序是违反GPL的。不过，你可以通过给插件的许可证添加一个例外来解决这个法律问题，例外就是允许把它和非自由的主程序连接在一起。

请同时参考这个问题我在使用一个非自由的库来编写自由软件。

一个非自由软件是否可以加载GPL插件？

请参考这个问题来确定什么时候插件和主程序是一个单一的组合程序以及什么时候他们是独立的两个程序。

如果它们构成一个一个单一的组合程序，那么主程序就必须按照GPL或GPL兼容的自由软件许可证发布，这时发布的主程序如果要使用这些插件，那么GPL的条款必须被遵循。

不过，如果它们是独立的作品，那么插件的许可证对主程序没有要求。

请同时参考这个问题我在使用一个非自由的库来编写自由软件。

你有一个GPL程序，我想把该程序和我的代码连接起来并构造一个专有软件。该连接是否意味着我必须要把我的程序按照GPL授权？

可以。

如果是这样，我有没有办法按照LGPL得到一份你的软件？

你可以这样问，但是大多数作者都会坚定地回答不。GPL的思想就是如果你想在程序中包含我们的代码，那么你的程序也必须是自由软件。它就是要让你的程序成为社区的一部分。

你当然总是可以合法地不用我们的代码。

我如何才能允许只在可控的接口下连接专有模块和GPL库？

请把以下文字添加到你发布的每个文件的许可证声明里，文字的最后说此文件以GNU GPL发布：

把其他模块静态或动态地和ABC连接都构成基于ABC的组合作品。因此，整个组合都遵循GNU通用公共许可证的条款。

作为一个特例，ABC的版权持有者允许你将ABC和自由软件或以GNU LGPL发布的库组合，而且这些库只通过ABCDEF接口和ABC通信。你可以对ABC按照GNU GPL发布、对其他相关代码按照其相关许可证发布，前提是你按照GNU GPL的发布要求提供了相关的源代码并且你没有更改ABCDEF接口。

请注意，修改 ABC 的人没有义务为他们的修改版赋予该特例；这是他们的选择。GNU通用公共许可证允许无特例发布修改版；该特例也使发布的修改版继续带有此特例成为可能。

只有程序的版权持有者才能在法律上有效地授权该例外。如果你自己写了整个程序，并假定你的雇主或学校没有声称对此拥有版权，那么你就是版权持有者—因此你就可以做出此例外的授权。但是如果你想在你的程序中使用其他人的GPL程序，那么你不能代表其他人做出此例外的授权。你必须获得其他版权持有者的批准。

我写的应用连接了许多不同的部件，这些部件有多种许可证。我对自己的应用该使用什么许可证很迷惑。你是否能够告诉我可以使用什么许可证？

要回答这个问题，我们需要看看程序使用的部件的列表、这些部件的许可证以及你的程序如何使用这些部件的简述（几句话就行）。两个例子如下：

• 要正常使用我的软件，必须把它和FOO库连接在一起，该库使用LGPL许可证。
• 我们的程序需要通过系统调用（使用我的命令行）来运行BAR程序，该程序使用的许可证是“GPL，并带有允许连接QUUX的例外”。

“聚合版”和其他“修改版”有什么不同？

简单聚合两个程序就是说把两个程序并列在一张光盘或一个硬盘里。我们使用这个名词来描述有多个程序的情况，而不是一个程序的多个组成部分。在这种情况下，如果一个程序是 GPL 授权，它对其他程序没有影响。

组合两个模块意味着把它们连接在一起构成一个单独的大程序。如果每个模块都按照 GPL 授权，那么整个程序也必须按照 GPL 授权——如果你没法做到或者不想这么做，那么你可能不该组合它们。

究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。

如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。

反过来，pipes、sockets和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。

为什么FSF要求对FSF有版权软件的贡献者把版权赋予FSF？如果我有GPL软件的版权，我也需要这样做吗？如果需要，我应该怎么做？

我们的律师告诉我们，如果要在法庭上面对违反者处于最有利于GPL的执法位置，我们就应当是程序的版权状态越简单越好。我们的方式是，请每位贡献者或者把版权赋予FSF，或者对版权做出免责声明。

我们还请个人贡献者从其雇主（如果有的话）获得版权免责声明，这样我们就可以确保雇主们不再对此主张版权。

当然，如果所有的贡献者都把代码放到公有领域，那么就没有必要对无版权的代码进行GPL执法了。所以，我们鼓励人们对大型代码贡献主张版权，而把小型的代码置于公共领域。

如果你想对你的程序进行GPL执法，那么你最好也使用类似的政策。请联系<licensing@gnu.org>来了解更多信息。

我是否可以修改GPL并制作一个修改版的许可证？

你可以合法地在另一个许可证里使用GPL的术语（可能是改过的术语），假定你的许可证叫另一个名字并且不带有GPL的前言，而且你修改过的操作指导也和GPL有足够明显的区别，你也没有提及GNU（虽然实际的操作流程和GPL是类似的）。

如果你想在修改版的许可证中使用我们的前言，请写信到<licensing@gnu.org>获得许可。为此，我们会希望检查实际的许可证要求来决定是否批准。

虽然我们对这样的修改版不会提起法律上的反对，但是我们还是希望你再考虑一下，最好不要这样做。这种修改版的许可证几乎可以肯定和GNU GPL不兼容，而这种不兼容会阻止软件模块的合理组合。不同自由软件许可证的数目增加本身只是一种负担。

如果我通过GNU GPL获得了一个软件，那么我是否可以修改该软件的代码，把它变成一个新的程序，然后再按照商业程序发行和销售？

我们允许你商业化销售修改版的软件，但是只有在遵循 GNU GPL 条款的情况下。因此，举个例子，你必须按照 GPL 的要求使用户可以拿到源代码，并且用户也必须能够再发布和修改该程序。

这些要求是在你的程序里包含 GPL 代码所必须的。

GPL可以不用于软件吗？

你可以将 GPL 用于任何作品，只要能说清楚什么是该作品的“源代码”就行。GPL 将源代码定义为修改作品的首选形式。

然而，对于手册和教材，或者任何用于教育的一般性作品，我们推荐使用 GFDL 而不是 GPL。

LGPL和Java如何在一起运作？

请参看此文了解详情。LGPL 可以按照既定的、期望的和预想的方式运作。

考虑这个情况：1) X按照GPL发布了V1。2) Y在V1的基础上贡献了修改和新代码，开发了V2。3) X想要把V2变成非GPL许可证。X需要Y的许可吗？

是的。由于 Y 是基于 X 的 V1 版本做出的，所以 Y 要按照 GNU GPL 发布。Y 不必就其代码同意使用任何其他的许可证。所以，X 要想按照其他协议发布 V2，必须要获得 Y 的许可。

我想在我的专有系统中合并GPL软件。我只按照GPL授予的方式使用该软件。我可以这样做吗？

你不能把 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 和 GPL 许可证模块 C 通过 X11 许可证模块 B 通讯这件事在法律上并不相关；重要的是模块 C 被包含在整个软件中。

libstdc++ 例外允许动态连接吗？

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

我想修改GPL程序并把它们和Money Guzzler Inc的可移植库连接在一起。我不能发布这些库的源代码，所以每个想修改的用户都要单独获得这些库。为什么GPL不允许这样做？

有两个原因。

第一，常规的原因。如果我们允许甲公司制作一个专有文件，而乙公司发布一款连接着此文件的GPL软件，那么这个漏洞就会使整个GPL许可证陷入泥潭。这将成为人们拒不发布对GPL软件的修改和扩展的护身符。

让所有用户都有权获得源代码是我们的主要目标之一，因此我们绝对要避免上述情况的出现。

更具体地来说，和 Money Guzzler 的库连接在一起的程序不是我们所定义的真正意义上的自由软件——它们没有全部的源代码，因而用户也无法修改和再编译整个程序。

如果模块Q的许可证要求和GPL不兼容，不过该要求只适用于单独发布Q的情况，而不是当Q被包含在一个大型程序中，那么该许可证和GPL兼容吗？我是否可以把Q和GPL程序联合或连接起来？

一个程序 P 按照 GPL 发布就意味着“其任意部分”都可以按照 GPL 来使用。如果你集成了模块 Q，并且将组合程序 P+Q 按照 GPL 发布，那么 P+Q 的任意部分都可以按照 GPL 来使用。P+Q 的一个部分就是 Q，所以 Q 的任意部分也是可以按照 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 发布二进制，那么你也应该通过 FTP 发布源代码。

我从朋友那里获得了GPL软件的二进制和提供源代码的承诺。我可否使用该承诺获得源代码？

是的，你可以这样做。此承诺对所有拥有与之一起发布的二进制软件的用户都是有效的。这正是 GPL 指明你的朋友在提供二进制软件时必须提供该承诺的理由——这样你就可以利用该承诺获得源代码了。

我可否把二进制放在我的网络服务器上并把源代码放在另外的网络服务器上？

GPL 指明说你必须提供 “从同一个地方” 访问源代码和二进制。不过，如果你安排了另一个位置访问源代码，并把链接或参考索引和二进制放在一起，那么我们认为也满足 “从同一个地方” 的要求。

不过，请注意，找一些碰巧存放了相应源代码的网站并告诉人们去那里查找源代码并不满足要求。过些日子，那个网站可能会删除这些代码，或者使用了更新的版本，那么你的发布就不符合 GPL 的要求了。要做合规努力，你需要和其他网站达成正向协议，确保那些网站保留源代码的时间和你发布二进制的时间一样长久。

我想发布一个GPL程序扩展版的二进制。源代码只发布该程序的原始版可以吗？

不行，你必须提供和二进制代码对应的源代码。用户必须能够使用源代码构造出同样的二进制。

自由软件的意义包含用户可以获得他们使用的程序的源代码。使用你发布版本软件的用户应该获得该版本的源代码。

GPL 的一个主要目的就是构建一个自由社会，其中就包含确保修改后的软件也是自由的。如果你要发布一个 GPL 软件的改进版本，那么你就必须按照 GPL 来发布。

我想发布二进制，但是发布完整的源代码太不方便了。只发布我的代码和“标准”版的差异加上二进制可以吗？

这是一个善意的请求，但是用这种方法提供源代码是行不通的。

如果一个用户想要获取一年前的源代码，那么他很有可能无法从那个网站取得合适的版本。标准发布可能有了较新的版本，但是同样的差异文件可能已经没法用了。

因此，在发布二进制时，你必须提供相应的完整源代码，而不是差异文件。

我可否把二进制放在网络服务器上，但是只为订购了源代码的人提供源代码？

如果你想通过匿名 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程序的开发者和GPL绑定了吗？”）。但是它在你如何使用该程序的问题上作出了自相矛盾的陈述：你既可以再发布之，又不可以再发布之。在你接受程序拷贝之前，你最好是要求它就如何使用该程序作出明确解释。

为什么有些GNU库是按照普通的GPL发布，而不是按照LGPL发布？

对具体的库采用宽 GPL 许可证实际上自由软件的倒退。这意味着我们部分放弃了对用户自由的保护，也部分放弃了一些 GPL 软件应有的要求。就事论事，这些放弃都是坏事。

有时，局部的倒退是一个不错的策略。在适当的情况下，对库采用 LGPL 会让这些库被更广泛地使用，因此就更多地改善了这些库、更多地支持了自由软件等等。如果范围很大，那么这就是对自由软件有益的事。但是它究竟会怎么发展呢？我们拭目以待。

如果能够对每个库都试行一段时间的 LGPL 来看看效果如何，若是没有什么帮助再改回 GPL 是最好的。但是这个做不到。一旦我们对一个具体的库使用了 LGPL，那么我们就很难再改回来。

因此，我们对哪个库使用什么许可证采用的是具体情况具体分析的原则。请参看我们关于如何判断的详细解释。

为什么程序应该写上GPL“版本 3或任何以后的版本”？

不定期的，每隔几年，我们会修改一下 GPL——有时是使之更清晰，有时是放开一些以前不允许的用例，还有时是收紧一些要求。（最近的两次修订是在2007年和1991年。）在程序中使用这样的“间接说明”可以让我们能够在更新 GPL 后随着就更新了整个 GNU 软件集的发布条款。

如果没有这个间接说明，那么我们将不得不和众多版权持有者就更改进行冗长的讨论，实际上这是个不可能完成的任务。这样的话，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如何应用于字体？

字体的许可证是一个需要认真考虑的复杂问题。以下许可证例外是实验性的，但是已经获准常规性的使用。我们欢迎对此问题的建议——请参看此文的解释并写信给licensing@gnu.org。

要使用该例外，请在软件包（最大的范围内）的每个文件的许可证声明前添加以下文字，在文字的最后说明此文件使用 GNU GPL 授权发布：

作为例外，如果你的文档使用了这个字体，并且将字体或部分字体没有改变地嵌入到文档中，那么，该字体本身并不导致此文档就是要遵循 GNU GPL 许可证。不过，此例外并不排除该文档可能需要遵循 GNU GPL 的其他理由。如果你修改了该字体，那么你也可以此例外推广到心版本的字体，但是这并不是强制的。如果你不想这么做，那么你可以把这个例外在你的版本里删掉。

我在编写一个网站维护系统（有人称之为“内容管理系统”），或者是其他通过模板创建网页的应用。这些模板应该使用什么样的许可证呢？

模板太轻量级了，还不足以动用 copyleft 来保护。一般来说，对轻量级的作品使用 copyleft 并没有害处，但是模板有点例外，因为它们和用户数据结合在一起，而且一起发布。所以，我们建议对模板使用简单许可性条款。

有些模板会调用 JavaScript 函数。由于 Javascript 通常不是微不足道的功能，它值得使用 copyleft。因为模板会和用户数据结合在一起，所以模板+用户数据+JavaScript可以考虑做成一个作品并受版权保护。JavaScript（copyleft）和用户代码（通常使用和copyleft不兼容的条款）应该有明确的界限。

以下是针对此类 JavaScript 代码做的例外示范：

作为 GPL 的一个特定例外，任何 HTML 文件，如果仅仅是调用了该代码，并因此作为引用包含了该代码，那么该文件就应该按照版权法的考虑作为一个独立的作品。另外，此代码的版权持有者授权你可以将该代码和按照 GNU GPL 许可证发布的自由软件库组合在一起。你可以按照 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 不兼容库的情况一样。这就意味着：

1. 如果你写代码并以 GPL 发布，那么你可以给予明确的例外来允许连接到 GPL 不兼容的工具。
2. 如果你写了代码并将程序按照 GPL 发布，而且你的程序就是特地设计成要和这些工具一起工作，那么人们可以认为这里有隐含的例外允许他们连接到这些工具。但是如果这确实是你想要的，你最好明确陈述出来。
3. 你不能拿来别人的 GPL 代码并象上面那样使用，或者添加类似的例外条款。只有代码的版权持有者才能添加这个例外。

谁可以进行GPL执法？

由于 GPL 是一个版权许可证，所以软件的版权持有者有权维护该权益。如果你发现有人违反了 GPL，那么你应该通知该 GPL 软件的开发者。他们要不就是版权持有者，要不就是和版权持有者有关系。

此外，我们鼓励采取各种可行的法律手段维护 GNU GPL 的合规，帮助用户获得完整和相应的源代码，因为这是用户的权利。归根结底，我们开发 GNU GPL 本来就是要用户拥有所有软件自由。

在一个面向对象的语言，比如Java下，如果我不加修改地使用了一个GPL类，并做成了子类，那么GPL会对更大范围的程序有什么影响？

创建子类也是在创建衍生作品。因此，GPL 的条款会影响包含了被创建的 GPL 子类的父类的软件。

如果我把我的程序移植到GNU/Linux，那么这是否意味着我必须按照GPL或其他自由软件许可证发布我的软件？

一般来说，回答是否定的—这不是法律上的要求。具体来说，回答依赖于你要用的库以及这些库的许可证。大多数系统库不是使用 GNU LGPL，就是使用 GNU GPL 加上一个允许该库连接任何程序的例外条款。这些库可以用于非自由的程序；但是就 LGPL 许可证来说，它还是有一些你必须遵守的要求的。

有些库是只以 GNU GPL 发布的；你必须使用和 GPL 兼容的许可证才能使用这些库。但是这些通常是更加专用的库，并且在其他平台上你也很难找到类似的库，所以对于简单的程序移植你可能不太会涉及这些库。

当然，如果你的软件是非自由的，那么它并没有对我们的社区做贡献，而看重自由的人是不会用这种软件的。只有要放弃自由的人才会使用你的软件，这意味着该软件实际上是在诱使人们失去自由。

如果你希望将来回首往事的时候，你的软件曾经为建设美好和自由的社会做出了贡献，那么你需要让它成为自由软件。

我发现有个公司有一个GPL软件的拷贝，但是要花钱才能拿到该软件。这个公司是否因此违反了GPL?

不。GPL 并不要求人们使用互联网来发布程序。它也没有要求某个特定的人来再发布程序。而且（除了一个特定的场景），如果有人决定要再发布一个程序，GPL 也没有说他必须把程序发布给你或这任何特定的人。

GPL 要求的是如果他愿意，他有自由为你发布一份该程序的拷贝。一旦版权持有者发布了程序的拷贝给某个人，那么这个人就可以再发布拷贝给你或其他人，只要他觉得合适。

我是否可以发布一款软件，它的许可证是你可以按GPL发布此软件的修改版，但是你不能按GPL发布此软件的原始版？

不行。这样的许可证自相矛盾。让我们看看它对作为用户的我意味着什么吧。

假定我从原始版本（版本甲）开始，并添加了一些代码（比如 1000 行），而后按照 GPL 发布了该修改版（版本乙）。GPL 说任何人可以再修改版本乙并按照 GPL 发布。所以我（或其他人）可以删掉这 1000 行代码，制作版本丙。版本丙的代码其实和版本甲一样，但是版本丙是遵循 GPL 的。

如果你想拦住这条去路，在许可证中明确说我不能通过删除版本乙的代码制作和版本甲一样的程序，不过是遵循 GPL 许可证的，那么你的许可证实际上是在说我不能完全按照 GPL 许可证使用版本乙。换句话说，你的许可证实际上不允许用户按照 GPL 发布一个修改版，比如版本乙。

把软件拷贝移送到一个由多数人拥有并控制的机构是否构成发布？

把软件拷贝移送到或者从该机构拿出来是否构成 “发布” 是一件按照版权法在法庭里决定的事。GPL 不会也不能超越适用地的法律。美国法律对此也没有清晰的界定，但是倾向于认为这不是发布。

如果在某些国家，这个被认为是发布，那么该机构就必须获得再发布该软件的权利，实际上也是这样做的。如果该机构由一个母公司控制，那么有没有再权发布就由母公司说了算。

软件安装程序是否可以要求人们通过点击同意GPL？如果我得到一份GPL软件，那么我必须同意什么吗？

有些软件的安装系统有一个要求你点击同意 GPL 的地方，否则就意味着同意了 GPL 的条款。这不是要求，也不被禁止。点不点击同意，GPL 的条款并不会改变。

单是同意 GPL 并没有对你强加什么义务。你没有被要求同意任何事才能使用 GPL 软件。只有你修改或分发该软件时，你才有义务。如果你觉得点击同意 GPL 有问题，那么没有人可以阻止你改写该 GPL 软件并跳过点击同意。

我想把GPL软件和一些安装程序合在一起。这些安装程序也必须是GPL软件吗？

不。安装程序和被安装的文件是分别的作品。因此，GPL 条款不应用于该安装程序。