“GPL”代表“通用公共许可证”。其中最广泛使用的许可证是GNU通用公共许可证，简写为GNU GPL。它可以进一步简写为“GPL”，前提是大家明白这是指向GNU GPL。
使用GNU GPL要求所有发布的改进版本都必须是自由软件。这意味着你可以避免和一个你自己的作品的专有修改版竞争。不过，在某些特殊的情况下，使用更宽泛的许可证会更好。
大多数GNU软件包使用GNU GPL，但是也有一些GNU程序（或部分程序）使用更宽泛的许可证，比如LGPL。我们这样做是战略性的。
任何人都可以按照GNU GPL发布软件，但是这并不会使发布的软件变成GNU软件包。
把一个软件变成GNU软件包意味着明确地把它贡献给GNU工程。这在软件的开发者和GNU工程达成共识才行。如果你想为GNU工程贡献软件，请写信给<maintainers@gnu.org>。
你应该报告这个情况。首先，尽量查看事实情况。然后，告知出版者或版权持有者具体的GPL软件。如果他们是自由软件基金会，请写信给<license-violation@gnu.org>。如果不是，软件的维护者可能就是版权持有者、或者她能够告诉你谁是版权持有者，所以请报告给软件维护者。
自由软件的一个关键特点是用户有自由合作。允许愿意互相帮助的用户分享问题修复和软件改进是绝对必要的。
有些人建议不同于GPL的方法，就是要求改进版由原始作者通过。只要原始作者跟得上维护的需求，这个建议可能在实践上很不错，但是如果原作者（或多或少）停下来去干别的事或者没能顾及所有用户的需求，这个建议就没办法了。除了实际操作的问题，该建议也没有允许用户互相帮助。
有时，为了防止各种用户修改版的混淆，人们还建议对修改版进行控制。就我们的经验来说，混淆不是大问题。Emacs在GNU工程之外有很多版本，但是用户还是可以区分。GPL要求版本制作者署名，这样就可以区分版本并保护版本维护者的声誉。
GPL不要求你发布你的修改版或者任何一部分修改版。你有自由修改并自用，而不必发布。这个规则也适用于机构（包括公司）；机构可以做出修改版并在内部使用而不向其他外部组织发布。
但是如果你以某种方式把修改版向公众发布，GPL就要求你向用户提供修改版的源代码。
因此，GPL允许程序按某些方式发布，而不允许用其他的方式发布；但是，是不是发布由你来决定。
可以。
不。GPL允许一个人制作和发行软件的拷贝，只是当这个人选择这样做的时候。这个人也有权利选择不发行该软件。
如果你书面承诺提供源代码，那么提出源代码需求的人应该有资格得到源代码。
如果你商业发布二进制却不带源代码，那么GPL说你必须提供书面的在晚些时候发布源代码的承诺。当用户非商业性的再发布你的二进制时，他们必须附带这个书面承诺的拷贝。这意味着没有从你处获得二进制的用户仍然可以从你处获得源代码的拷贝，只要提供了此书面承诺。
我们要求此书面承诺对第三方有效的理由在于，间接获得二进制的用户也能够从你处获得源代码。
第2节说你发布的修改版必须对所有第三方使用GPL授权。“所有第三方”是指任何人—但是这并不要求你亲自为他们做事。这只是说他们对你的版本拥有来自你的许可证，是GPL。
我们并不要求你对你的修改声明版权。不过，在大多数国家，版权是默认就有的，所以如果你不想你的修改被版权限制，那么你需要明确地把它置于公开领域。
无论你是否对你的修改声明版权，你都必须作为整体按照GPL发布你的修改（如果你要发布你的修改版的话）。
按照版权法，作品的翻译也是一种修改。因此，GPL对修改版的规定也适用于翻译版。翻译版处在原版的版权范围之内。
如果原来的程序是自由许可证，那么这个许可证许可了程序的翻译。你如何使用翻译版和如何为翻译版选择许可证由原来的许可证决定。如果原来的程序使用了某个GNU GPL版本，那么翻译版也必须包含在这个GNU GPL许可证版本之下。
如果你能够区别哪些是公有领域部分和哪些不是，那么你可以这样做。如果该代码是被其开发者放到公有领域的，那么无论它在哪里，它都是公有领域的。
是的，GPL允许任何人这样做。销售拷贝的权利是包含在自由软件的定义中。除了一个特殊的情况，你的收费没有限制。（这个例外就是对于仅有二进制发布的软件，你必须提供书面的源代码可获取承诺。）
是。你可以对你发行的拷贝按你所需报价。按照 GPLv2，如果你提供的是二进制发布，那么你还必须提供“对等的”源代码下载—。因此，下载源代码的费用不能高过下载二进制的费用。如果二进制是按照 GPLv3 来发布的，那么你必须按照同样的方式在同样的地方提供对等的源代码下载，而且不能收取额外的费用。
不。事实上，这种要求会让程序变成非自由的。如果人们不得不付费才能得到一份程序拷贝，或者他们必须通知某个具体的人，那么这个程序是非自由的。参看自由软件的定义。
GPL是一份自由软件许可证，因此它允许人们使用乃至再发布软件而不要求必须付费才能这样做。
你可以向人们收费来给出你的软件拷贝。但是当人们从其他人那里获得拷贝时，你不能要求人们向你付费。
不。但是如果有人付费获得拷贝，GPL给予她向公众发布的自由，收不收费都可以。例如，有人付费给你，然后将拷贝发布到一个公开的网站上。
不。GPL说的是，从你处获得软件拷贝的任何人都有权再发布该拷贝，无论是否修改。你不得再限制该作品的发布。
如果你在获取FSF有版权的GPL软件时，有人要求你签署NDA，那么请立刻写信到license-violation@fsf.org通知我们。
如果违反事件涉及到其他的GPL代码持有人，请通知该版权持有者，就和你对付其他形式的GPL违反案例一样。
不。GPL说的是，修改版必须使用GPL所述的全部自由。因此，从你处获得修改版的人有权重新发布该软件（无论是否修改）。你不能使用带有更多限制的条款发布该软件的任何版本。
是的。例如，你可以签署一个开发修改版的合同，并同意只有在客户同意时才能发布你的修改。我们允许这样做是因为此时GPL的代码并没有按照NDA发布。
你也可以将你的修改按照GPL发布给你的客户，但是只有在客户同意时才能把它们发布给其他人。此时，GPL代码也没有按照NDA发布，或者说也没有按照任何附加条款发布。
GPL会赋予该客户再发布此版本的权利。此时，该客户可能会选择不执行该权利，但是她拥有该权利。
你当然可以从你的工作中获得荣誉。按照GPL发布程序的一个要求就是在版权声明处写上你的名字（假设你是版权拥有者）。GPL要求所有的拷贝都带有适当的版权声明。
不，GPL不允许这样做。虽然我们承认合理的引用是学术发表的一个重要部分，但是引用不能作为GPL的附加要求。根据GPLv3的第7(b)节，要求使用GPL软件的研究论文说明引用了GPL软件不在GPL的范围之内，因此这被认为是对GPL的额外限制。并且版权法也不允许添加这种对软件输出的要求，无论该软件是GPL授权，还是其他许可证授权。
在每个拷贝里都包含许可证是关键性的，这样每个获得拷贝的人都知道他们的权利是什么。
包含一个指向许可证的URL而非许可证本身也许看起来很不错。但是你无法保证该URL五年或十年之后的有效性。20年后，今天我们所用的URL可能不再存在了。
无论网络发生什么变化，唯一能够确保拥有拷贝的人们还能看到许可证的方法就是在程序中包含许可证的拷贝。
只是在软件库里放一份带有GNU GPL许可证拷贝的文件并不算明确声明在该软件库里的所有代码都可以按照GNU GPL来使用。而缺少明确的声明，意味着并不能完全清楚地界定GPL许可证是否真的适用于各个具体的源代码文件。一份明确的声明会使这一切清清楚楚。
一个只包含许可证的文件，其中没有明确说明具体其他文件遵循该许可证，就像是一个带有一个子程序的文件，而该子程序从来不被其他程序调用。这个比喻也不完美：律师和法庭可能会根据常识判定因为你想让代码使用该许可证才把GNU GPL的拷贝放在代码库里。他们也有可能不这样判断。但是，你为什么留下这样的问题呢？
你应该在每个源文件里包含这样的声明。在程序的README文件里明确说明也是充分有效的，只要该声明和源代码是在一起发布的，但是它们很容易被分别处置。为什么要冒让你的代码的许可证不能确定的风险呢？
这个问题并不是专门针对GNU GPL许可证的。任何自由许可证都有这个问题。
你的每个源代码文件都应该以一个声明开始，明确陈述该文件的许可证以避免你的代码和许可证分离。如果只是你的代码库的README文件说明了源代码遵循GNU GPL许可证，那么有人只把源代码文件复制到其他程序时你该怎么办？其他内容可能并不能说明该源代码文件的许可证究竟是什么。它可能会有了其他的许可证，也许什么许可证也没有（此时它可能会变成非自由代码）。
在每个代码文件的起始部分添加版权声明和许可证声明会让事情变得容易和清楚，以上的不确定性就很难立足。
这个问题并不是专门针对GNU GPL许可证的。任何自由许可证都有这个问题。
如果整个软件包仅包含很少的代码—我们使用的标准是少于300行代码—那么你可以使用一个宽泛授权的许可证，而无需使用GNU GPL这样的Copyleft许可证。（除非，该代码非常重要。）此时，我们建议使用Apache许可证2.0。
前言和指导是构成完整GNU GPL许可证的组成部分，它们不应该被省略。事实上，GPL受版权保护，它只允许全文逐字复制。（你可以使用其法律术语制作另一个许可证，但是那就不是GNU GPL了。）
前言和指导加起来不过1000多字，不到GPL全文的1/5。除非软件包本身特别小，这点篇幅不会造成软件大小的显著变化。如果软件包本身很小，那么你可以使用一个简单全权许可证而不用GNU GPL。
为了把两个程序（或者其主要部分）合成一个较大的程序，你需要某种许可才能做得到。如果这两个程序的许可证允许这么做，那么它们就是兼容的。如果无论如何都不能同时满足两个许可证，那么它们就是不兼容的。
对有些许可证来说，程序合成的方式也会影响许可证是否兼容—例如，它们可能允许把两个模块连接在一起，但是不允许把两个代码合成一个模块。
如果你只是想把两个程序安装到同一个系统中，那么它们的许可证没有必要是兼容的，因为安装并不是把它们合成一个大的程序。
这就是说该许可证和GNU GPL兼容；你可以把按照该许可证发布的代码和按照GNU GPL发布的代码合成一个大的程序。
GNU GPL的所有版本本身都允许这么做；这些版本还允许这些组合的发布，前提是该组合是按照同版本的GNU GPL发布的。如果一个许可证也允许这么做，那么它就是和GPL兼容的。
GPLv3比GPLv2兼容更多的许可证：GPLv3允许你组合某些代码，这些代码可以带有GPLv3本身没有的额外条款。第7节中有关于此情况的更多信息，包括被允许的额外条款的清单。
如果你这样做，那么你的程序将不能在自由的环境下全功能运行。如果你的程序依靠非自由库来完成某些工作，那么它就不能在自由的环境下做这些工作。如果它依靠非自由库才能工作，那么它就不能作为像GNU这样的自由操作系统的一部分；它超出了自由世界的极限。
所以，请你再考虑一下：你是否可以不使用非自由库来完成同样的工作？你是否可以写一个自由的库来代替那个非自由库？
如果你的软件已经使用了非自由库，那么改变这个可能有点晚了。你还是可以按照程序的现状来发布它，这比不发布要好一些。但是，请在README中说明该程序的一个不足是使用了非自由库，并把避免使用非自由库而完成同样的事情作为一个任务推荐给大家。请建议那些想继续为该程序工作的伙伴首先要做的就是摆脱那个非自由的库。
请注意，把某些非自由库和GPL自由软件合并起来可能还有法律问题。请参看关于GPL软件和GPL不兼容库的问题来了解更多信息。
两版GPL都有关于copyleft的例外，通常成为系统库例外。如果你用的GPL不兼容库满足了系统库的条件，那么你就不用对这些库做任何处理而直接使用；整个程序的源代码发布要求也不包含这些系统库，即使你发布的是连接了这些库之后的可执行文件也是一样。
关于“系统库”的标准，各版GPL有所不同。GPLv3在第1节明确定义了“系统库”，以将之和“相关源代码”区别开来。GPLv2的处理略微不同，放在在第3节。
这两个许可证都明确允许互相连接。你总是可以把 GPLv3 模块和 AGPLv3 模块连接在一起，反之亦然，不论连接的模块是不是库都一样。
如果你的程序要用到不属于系统库例外的库，那么你需要获得授权。下面是你可以使用的两个许可证声明的例子；一个是GPLv3用的，另一个是GPLv2用的。在两个例子中，你都应当在每一个需要授权的文件里添加这个声明。
只有程序的版权持有者能够合法地依据此条款发布他们的软件。如果你是自己编写了整个程序，那么假定你的雇主或学校没有对此声称版权，你是版权持有者—那么你有权批准这个例外。但是如果你的程序要使用其他作者的GPL程序部分，那么你没有权利批准和其他作者有关的例外。你必须获得其他程序的版权持有者的授权。
当其他人修改此程序时，他们不必对自己的代码做同样的例外声明—他们有权选择。
如果你要连接的库是非自由库，请同时参看使用非自由库撰写自由软件的部分。
如果你使用的是GPLv3，那么你可以按照第7节的描述做出额外授权来达到这个目的。以下的许可证声明就是一个例子。你必须把括号里的内容换成适合你的程序的内容。如果不是所有的人都能发布你想要连接的库的源代码，那么你应当删去括号内的文字；否则，你只需去掉括号就行。
Copyright (C) [年份] [版权持有者的名字]
本软件是自由软件；你可以按照由自由软件基金会发布的GNU通用公共许可证来再发布该软件或者修改该软件；你可以使用该许可证的第3版，或者（作为可选项）使用该许可证的任何更新版本。
本程序的发布是希望它能发挥作用，但是并无担保；甚至也不担保其可销售性或适用于某个特殊的目的。请参看GNU通用公共许可证来了解详情。
该程序应该同时附有一份GNU通用公共许可证的拷贝；如果没有，请参看<https://www.gnu.org/licenses>。
GNU GPL版本3第7节的额外授权
如果你通过连接或合并[库名称]（或者是该库的修改版）修改该程序或者其任何部分，而受到该库许可证[库的许可证名称]条款的制约，本程序的许可证授权你输送修改结果的额外权利。{修改结果的非源代码形式的相关源代码应当包含所用[库名称]的源代码部分和本软件的源代码部分。}
如果你使用的是GPLv2，那么你可以提供你自己的许可证例外。以下的许可证声明就是一个例子。同样地，你必须把括号里的内容换成适合你的程序的内容。如果不是所有的人都能发布你想要连接的库的源代码，那么你应当删去括号内的文字；否则，你只需去掉括号就行。
Copyright (C) [年份] [版权持有者的名字]
本软件是自由软件；你可以按照由自由软件基金会发布的GNU通用公共许可证来再发布该软件或者修改该软件；你可以使用该许可证的第2版，或者（作为可选项）使用该许可证的任何更新版本。
本程序的发布是希望它能发挥作用，但是并无担保；甚至也不担保其可销售性或适用于某个特殊的目的。请参看GNU通用公共许可证来了解详情。
该程序应该同时附有一份GNU通用公共许可证的拷贝；如果没有，请参看<https://www.gnu.org/licenses>。
静态或动态把[你的程序名称]和其他模块连接在一起就是在[你的程序名称]的基础上做工作。因此，GNU通用公共许可证的条款会覆盖到整个合并的工作。
另外，作为一个特例，[你程序的名称]的版权持有者赋予你把[你程序的名称]和自由软件或按照GNU LGPL发布的库合并的权利，其中[库的名称]标准发布代码使用[库的许可证]（或者该代码的修改版，许可证不变）。你可以复制和发布该系统，其许可证条款是[你程序的名称]使用的GNU GPL许可证和其他代码{, 假定你按照GNU GPL的发布要求包含了其他程序的源代码}使用的相关许可证。
请注意，修改[你程序的名称]的人没有义务为他们的修改版赋予该特例；这是他们的选择。GNU通用公共许可证允许无特例发布修改版；该特例也使发布的修改版继续带有此特例成为可能。
按照伯尔尼公约，任何写出来的东西在其形式固定时就自动获得版权。所以，你对自己写的东西不必做任何事就“获得”其版权—只要没有其他人声称拥有你的作品。
不过，注册版权在美国是一个好主意。这对你处理在美国的侵权更有利。
其他人可能声称对你的作品拥有版权的情况是你是一个雇员或学生；此时，雇主或学校可能会主张你是为他们工作的，所以他们拥有版权。他们的主张是否有效取决于当地的法律、雇佣合同和工作性质等。如果有疑问，最好是咨询律师。
如果你觉得雇主或学校可能会有所主张，那么你可以通过让公司或学校的授权人签署版权免除声明来解决此问题。（你的上司或教授通常没有权利签署这样的免除声明。）
当下，许多大学会通过限制使用它们开发的知识和信息来获取资金，这种行为和商业公司没什么分别。（请同时参看“被收买的大学”，Atlantic月刊，2000年3月号，来了解关于此问题及其影响的一般性讨论。）
如果你看出你的学校可能会拒绝你把你的程序发布为自由软件，那么你越早提出这个问题越好。程序越接近正常工作的水平，学校管理方越倾向于剥夺你的程序并自己完成该程序。越在早期，你越有发言权。
所以，我们建议你在程序早期时就和校方讨论这个问题，比如，“如果你让我将程序按自由软件发布，那么我就完成它。”不要认为这是一种虚张声势。要想站到上风，你必须有勇气说出，“我的程序要么拥有自由，要么就不存在。”
参看GPL指南页面。
GNU GPL没有赋予用户为程序附加其他许可证的权利。但是，程序的版权持有者可以同时按照多个许可证发布自己的程序。其中一个可以是GNU GPL。
假设程序的版权持有者添加了许可证并且你从合法途径获得该程序的拷贝，那么你得到的程序拷贝带有的许可证就是你的拷贝适用的许可证。
虽然把程序发布为非自由软件总是一个道德污点，但是法律并没有阻碍你这么做。如果你是自己代码的版权持有者，那么你可以在不同时间按照不同的非排他许可证发布。
严格来说，GPL是由开发者对其他人发布的的许可证，用于这些人使用、发布和改变该程序。开发者本人并不受到许可证的限制，所以无论开发者做什么，这都不是“违反”GPL。
不过，如果开发者做了某些若是用户做的话就会违反GPL的事，那么该开发者就必然会在社区就会失去道德上的立足之地。
不行，因为公众已经有了按照GPL使用该程序的权利，并且该权利不可撤回。
是的，因为编辑器和工具的版权并不包括你编写的代码。从法律上说，使用这些工具并不对你代码的许可证带来任何限制。
有些程序由于技术的原因会在输出时复制它自身的一部分—比如，Bison会输出一个标准的解析程序拷贝。在这种情况下，输出的文本拷贝拥有和其源代码一样的许可证。同时，从程序的输入导致的输出部分继承程序输入的版权。
实际使用时，Bison也可以用来开发非自由软件。这是由于我们明确决定允许不受限制地使用Bison输出的标准解析程序。因为有其他一些和Bison类似的工具已经允许用来开发非自由软件，所以我们也决定这样做。
是的，你有。“合理使用”就是无需任何特别许可的使用。因为你不需要开发者的许可来合理使用，所以你可以无视开发者对合理使用的说辞—无论是在许可证里还是在其他地方，无论是GNU GPL还是其他自由软件许可证。
不过，请注意，合理使用并没有一个放之四海而皆准的原则；什么是“合理”，在每个国家都有所不同。
如果程序是美国联邦雇员在雇佣期间写的，那么它是公有领域软件，就是说它没有版权。由于GNU GPL是基于版权的许可证，所以该程序不能使用GNU GPL发布。（不过，它仍可以是自由软件；公有领域的软件是自由的。）
但是，当美国政府机构使用合同商来开发软件时，情况就不同了。合同里可以要求合同商按照GNU GPL发布软件。（GNU Ada就是这样开发的。）或者合同把版权赋予政府机构，那么政府机构就可以按照GNU GPL来发布该软件。
是的。如果这些改进是政府雇员在其雇佣期间做出的，那么这些改进是公有领域的。不过，改进的软件，作为整体仍然是GNU GPL软件。这个没有问题。
如果美国政府使用合同商做出的改进，那么这些改进本身也可以使用GPL许可证。
不。把GPL作品和其他模块静态或动态连接在一起就是在基于GPL作品合成一个作品。因此，GNU通用公共许可证的条款和条件涵盖整个合成的作品。请同时参看GPL软件使用非GPL兼容库会有什么法律问题？
关于遵守LGPL（任何现存版：v2、v2.1或v3）的目的：
(1)如果你是静态连接一个LGPL库，那么你也必须提供你的应用的目标（不必是源代码）格式，这样用户就有机会修改该库并重新连接成应用。
(2) 如果你是动态连接一个已在用户电脑上的LGPL库，那么你不必输送该库的源代码。另一方面，如果你自己和你的应用一起输送了该LGPL库的可执行形式，无论是静态还是动态连接，那么你也必须输送该库的源文件，按照LGPL要求的一种方式。
一般来说，这在法律上是做不到的；版权法没有赋予你任何权利来对别人用他们自己的数据和你的程序做出来的输出做出限制。如果用户使用你的程序输入或转化自己的数据，输出的版权属于用户，而不是你。从更广泛的意义上说，当一个程序把其输入转化成其他的形式，那么输出继承的版权是输入的版权。
因此，只有输出大量复制（或多或少）来自你的程序的文本，你才对输出有发言权。例如，Bison（参看上面的问答）的输出就属于GNU GPL的范畴，如果我们没有对此做出例外的话。
你可以人工地制造复制文本的输出，即使这没什么技术必要。但是如果复制的文本没有实际用处，用户可以简单删除它们而只用剩下的部分。这样，她就没有必要非得遵守和这些复制文本相关的发布条件了。
程序的输出一般来说不在程序的版权范围内。所以，程序代码的许可证不会用于程序的输出，无论输出是文件、截图、录屏或视频。
例外的情况是，程序全屏显示来自程序自身的文本/艺术。此时，这些文本/艺术版权的版权涵盖程序的输出。输出的声音，比如视频游戏的输出，也适用于这个例外。
如果这些艺术/音乐是GPL的，那么无论你如何复制，GPL都适用。不过，合理使用可能仍然适用。
请记住，有些程序，特别是视频游戏，其艺术/音乐的许可证可能和游戏本身使用的GPL许可证不同。在这种情况下，艺术/音乐的许可证就会主导有音视频的游戏场景。请同时参看：GPL可以不用于软件吗？
GPL表述的是整个合成的程序必须按照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解释器是按照什么许可证发布的。
你可以把你的程序连接到这些库，并将编译好的程序发布给其他人。当你这样做时，按照GPLv3的定义，这些运行库就是“系统库”。这表示你不必担心在你的程序中要包含这些库的源代码。GPLv2在第3节也提供了类似的例外。
你不能把这些库按照DLL的形式和你的程序一起发布。为了防止有人利用系统库例外而不择手段地发布程序，GPL指出只有库不和程序一起发布才能作为系统库。如果你的库是和程序一起发布的DLL，那么它们不再适用于该例外；此时，你只有提供这些库的源代码才能遵守GPL，但这是你实际上无法提供的。
你可以写一个只在Windows下运行的自由软件，但这并不是一个好主意。这些程序可能会“落入”Windows的圈套，因而对自由世界毫无贡献。
因为它强加了一个GPL没有的条款；就是，要求对程序做广告的条款。GPLv2第6节的陈述是：
你不能对被授权者获得的权利强加任何额外的限制。
GPLv3在第10节也有类似的表述。广告条款正是这种额外的限制，因此它和GPL不兼容。
修正的BSD许可证没有这个广告条款，它就没有这个问题。
这依赖于主程序如何调用插件。如果主程序使用fork和exec调用插件，那么它们之间通过共享或交换复杂数据结构而建立了密切的通信，这样它们就是一个单一的结合在一起的程序。如果主程序使用的是简单的fork和exec调用插件，并没有建立密切的通信，那么插件就是一个单独的程序。
如果主程序动态连接了插件，而且它们之间互相调用函数并共享数据结构，那么我们认为它们构成了一个单一的组合程序，主程序和插件必须被当作一个扩展来对待。如果主程序动态连接了插件，但是它们之间的通信限于调用插件的‘主’函数及其参数并等待其返回，那么这就是个可以算单一组合程序也可以算两个独立程序的临界情况。
使用共享内存来交换复杂数据结构的情况和动态连接基本类似。
请参考这个问题来确定什么时候插件和主程序是一个单一的组合程序以及什么时候他们是独立的两个程序。
如果主程序和插件是一个单一的组合程序，那么就意味着插件必须按照GPL或GPL兼容的自由软件许可证发布，包括其源代码。如果主程序和插件是独立的两个程序，那么主程序的许可证对插件没有要求。
请参考这个问题来确定什么时候插件和主程序是一个单一的组合程序以及什么时候他们是独立的两个程序。
如果它们构成了一个单一的组合程序，那么组合GPL的插件和非自由主程序是违反GPL的。不过，你可以通过给插件的许可证添加一个例外来解决这个法律问题，例外就是允许把它和非自由的主程序连接在一起。
请同时参考这个问题我在使用一个非自由的库来编写自由软件。
请参考这个问题来确定什么时候插件和主程序是一个单一的组合程序以及什么时候他们是独立的两个程序。
如果它们构成一个一个单一的组合程序，那么主程序就必须按照GPL或GPL兼容的自由软件许可证发布，这时发布的主程序如果要使用这些插件，那么GPL的条款必须被遵循。
不过，如果它们是独立的作品，那么插件的许可证对主程序没有要求。
请同时参考这个问题我在使用一个非自由的库来编写自由软件。
不准确。这意味着你必须按照和GPL兼容的许可证发布你的程序（更准确地说，是和一个或多个被程序的其他部分代码所接受的GPL版本的GPL兼容）。然后，该组合程序就要遵守这些GPL的版本。
你可以这样问，但是大多数作者都会坚定地回答不。GPL的思想就是如果你想在程序中包含我们的代码，那么你的程序也必须是自由软件。它就是要让你的程序成为社区的一部分。
你当然总是可以合法地不用我们的代码。
Linux（GNU/Linux操作系统的内核）是按照GNU GPLv2发布的。发布一个要和Linux连接的非自由驱动是不是违反GPL？
是的，这是一个违反GPL的场景，因为这实际上是在制作一个较大的组合作品。期待用户把不同的东西组合在一起并不改变这个场景。
每个拥有一定量代码的Linux贡献者都可以要求对此执行GPL，而我们也鼓励他们对发布非自由Linux驱动的行为采取行动。
请把以下文字添加到你发布的每个文件的许可证声明里，文字的最后说此文件以GNU GPL发布：
把其他模块静态或动态地和ABC连接都构成基于ABC的组合作品。因此，整个组合都遵循GNU通用公共许可证的条款。
作为一个特例，ABC的版权持有者允许你将ABC和自由软件或以GNU LGPL发布的库组合，而且这些库只通过ABCDEF接口和ABC通信。你可以对ABC按照GNU GPL发布、对其他相关代码按照其相关许可证发布，前提是你按照GNU GPL的发布要求提供了相关的源代码并且你没有更改ABCDEF接口。
请注意，修改了ABC的人并没有被要求获得对修改版的例外；他们有权选择是否这样做。GNU通用公共许可证允许没有例外地发布修改版；该例外也使按照例外来发布后续的修改版成为可能。如果你修改了ABCDEF接口，那么该例外就不适用于你修改过的ABC，而你则必须在发布修改版时将此例从许可证声明中移除。
此例外是GNU通用公共许可证第3版第7节的附加许可。（“GPLv3”）
此例外允许使用特定接口（“ABCDEF”）连接带有不同许可证的模块，同时确保用户仍然像使用GPL一样收到源代码。
只有程序的版权持有者才能在法律上有效地授权该例外。如果你自己写了整个程序，并假定你的雇主或学校没有声称对此拥有版权，那么你就是版权持有者—因此你就可以做出此例外的授权。但是如果你想在你的程序中使用其他人的GPL程序，那么你不能代表其他人做出此例外的授权。你必须获得其他版权持有者的批准。
要回答这个问题，我们需要看看程序使用的部件的列表、这些部件的许可证以及你的程序如何使用这些部件的简述（几句话就行）。两个例子如下：
- 要正常使用我的软件，必须把它和FOO库连接在一起，该库使用LGPL许可证。
- 我们的程序需要通过系统调用（使用我的命令行）来运行BAR程序，该程序使用的许可证是“GPL，并带有允许连接QUUX的例外”。
“聚合版”包含有多个独立的程序，并在同一个CD-ROM或其他媒体上发行。GPL允许你制作并发布一个聚合版，即使其他软件的许可证不是自由许可证或不是GPL兼容的许可证也可以。唯一的条件是你的聚合版的许可证不能禁止用户行使每个独立程序的许可证允许的权利。
究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）。
如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。
反过来，pipes、sockets和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。
不，容器的引入并不改变他们是单一作品还是聚合版本的分析。
我们的律师告诉我们，如果要在法庭上面对违反者处于最有利于GPL的执法位置，我们就应当是程序的版权状态越简单越好。我们的方式是，请每位贡献者或者把版权赋予FSF，或者对版权做出免责声明。
我们还请个人贡献者从其雇主（如果有的话）获得版权免责声明，这样我们就可以确保雇主们不再对此主张版权。
当然，如果所有的贡献者都把代码放到公有领域，那么就没有必要对无版权的代码进行GPL执法了。所以，我们鼓励人们对大型代码贡献主张版权，而把小型的代码置于公共领域。
如果你想对你的程序进行GPL执法，那么你最好也使用类似的政策。请联系<licensing@gnu.org>来了解更多信息。
你可以做一个修改版的GPL，但是这实际上会有一些后果。
你可以合法地在另一个许可证里使用GPL的术语（可能是改过的术语），假定你的许可证叫另一个名字并且不带有GPL的前言，而且你修改过的操作指导也和GPL有足够明显的区别，你也没有提及GNU（虽然实际的操作流程和GPL是类似的）。
如果你想在修改版的许可证中使用我们的前言，请写信到<licensing@gnu.org>获得许可。为此，我们会希望检查实际的许可证要求来决定是否批准。
虽然我们对这样的修改版不会提起法律上的反对，但是我们还是希望你再考虑一下，最好不要这样做。这种修改版的许可证几乎可以肯定和GNU GPL不兼容，而这种不兼容会阻止软件模块的合理组合。不同自由软件许可证的数目增加本身只是一种负担。
请不要修改GPL，请使用GPLv3提供的例外机制。
我们允许你商业化销售修改版的软件，但是只有在遵循 GNU GPL 条款的情况下。因此，举个例子，你必须按照 GPL 的要求使用户可以拿到源代码，并且用户也必须能够再发布和修改该程序。
这些要求是在你的程序里包含 GPL 代码所必须的。
你可以将 GPL 用于任何作品，只要能说清楚什么是该作品的“源代码”就行。GPL 将源代码定义为修改作品的首选形式。
然而，对于手册和教材，或者任何用于教育的一般性作品，我们推荐使用 GFDL 而不是 GPL。
请参看此文了解详情。LGPL 可以按照既定的、期望的和预想的方式运作。
是的。由于 Y 是基于 X 的 V1 版本做出的，所以 Y 要按照 GNU GPL 发布。Y 不必就其代码同意使用任何其他的许可证。所以，X 要想按照其他协议发布 V2，必须要获得 Y 的许可。
你不能把 GPL 软件结合到专有系统中去。GPL 的目标是赋予所有人复制、发布、理解和修改程序的自由。如果你把 GPL 软件结合进一个非自由的系统，那么它的效果就和把 GPL 软件变成非自由软件一样。
一个结合了 GPL 程序的程序就是该 GPL 软件的扩展版。GPL 指出任何扩展版如果要发布都必须按照 GPL 来发布。这有两个理由：确保得到软件的用户得到他们应得的自由，鼓励人们回馈他们做出的改进。
不过，在许多情况下，你可以和 GPL 软件一起发布你的专有软件。你的所作要合法，你要确保自由和非自由的软件之间的隔离，它们之间的通信不应该看起来是一个组合在一起的程序的行为。
这样做和“结合” GPL 软件的不同有内容的因素也有形式的因素。内容的因素在于：如果两个程序组合在一起实际上变成了一个程序的两个部分，那么你就不能再把它们当成两个程序来看待。因此 GPL 必须涵盖到整个系统。
如果两个程序隔离地很好，正如编译器和内核，也如编辑器和 shell，那么你可以把他们当成两个独立的程序—但是你的做法必须合理。这个问题就是简单的形式：你如何描述你在做什么？为什么我们要关心这个？因为我们要确保用户清晰地理解整个集合中 GPL 软件的自由状态。
如果要发布 GPL 软件的人称之为专有系统的“一部分 ”，那么用户也许不确定他们对其中 GPL 软件的权利。但是如果用户知道他们得到一个自由的程序加上另一个程序，那么他们的权利就是清晰的。
对不起。我们不会对此提供例外。这样的例外是错误的。
使用户数量最大化并不是我们的目标。更准确地说，我们是要给予尽可能多的用户关键的自由。一般来说，专有软件会妨碍而不是助力自由。
我们偶尔也会允许许可证例外，并以此来帮助使用不同于 GPL 许可证的自由软件项目。然而，我们这样做时必须要看它对推进自由的充分理由。
我们有时也会更改软件包发行的条款，只要它是一条清晰的为自由软件服务的正确道路；但是，我们对此也分外小心，因此你的理由必须令人信服。
不行。X11 许可证和 GPL 是兼容的，因此你可以在 GPL 软件中添加一个遵循 X11 许可证的模块。但是，如果你想把这两个都合进一个更大的程序，包括这个 GPL 软件，那么整个程序就必须遵循 GNU GPL 许可证。
专有模块 A 和 GPL 许可证模块 C 通过 X11 许可证模块 B 通讯这件事在法律上并不相关；重要的是模块 C 被包含在整个软件中。
GCC运行库例外涵盖了 libgcc、libstdc++、libfortran、libgomp、libdecnumber 以及其他和 GCC 一起发布的库。该例外意在允许人们在发布使用GCC编译的程序时能够使用自己选择的条款，即使该程序经过编译形成的可执行文件包含了这些库的成分。如需更多信息，请参阅 关于 GCC 运行库例外的常见问答。
有两个原因。第一，常规的原因。如果我们允许甲公司制作一个专有文件，而乙公司发布一款连接着此文件的GPL软件，那么这个漏洞就会使整个GPL许可证陷入泥潭。这将成为人们拒不发布对GPL软件的修改和扩展的护身符。
让所有用户都有权获得源代码是我们的主要目标之一，因此我们绝对要避免上述情况的出现。
更具体地来说，和 Money Guzzler 的库连接在一起的程序不是我们所定义的真正意义上的自由软件——它们没有全部的源代码，因而用户也无法修改和再编译整个程序。
一个程序 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 v3 允许这样做；请参考选项 6(b) 来了解详情。在GPL v2 中，你当然可以通过 FTP 提供源代码，而且大多数用户正是这样获得源代码的。不过，如果有人希望获得邮寄的源代码介质，那么你也需要提供。
如果你通过 FTP 发布二进制，那么你也应该通过 FTP 发布源代码。
是的，你可以这样做。此承诺对所有拥有与之一起发布的二进制软件的用户都是有效的。这正是 GPL 指明你的朋友在提供二进制软件时必须提供该承诺的理由——这样你就可以利用该承诺获得源代码了。
可以。第 6(d) 允许这样做。然而，你必须提供人们获取源代码的清晰指南，而且你也必须保证只要目标代码还在，源代码就在。
不行，你必须提供和二进制代码对应的源代码。用户必须能够使用源代码构造出同样的二进制。
自由软件的意义包含用户可以获得他们使用的程序的源代码。使用你发布版本软件的用户应该获得该版本的源代码。
GPL 的一个主要目的就是构建一个自由社会，其中就包含确保修改后的软件也是自由的。如果你要发布一个 GPL 软件的改进版本，那么你就必须按照 GPL 来发布。
这是一个善意的请求，但是用这种方法提供源代码是行不通的。
如果一个用户想要获取一年前的源代码，那么他很有可能无法从那个网站取得合适的版本。标准发布可能有了较新的版本，但是同样的差异文件可能已经没法用了。
因此，在发布二进制时，你必须提供相应的完整源代码，而不是差异文件。
如果你在网络上发布了目标代码，那么你也必须提供相应的源代码。最简单的办法就是在同一个服务器上发布源代码，但是如果你喜欢，你也可以提供从其他服务器获取源代码的指南，或者提供一个版本控制系统。无论如何，获取源代码应该和获取目标代码一样简单。这些都写在 GPLv3 的第 6(d) 节。
源代码一定要和二进制对应。具体来说，它们对应该程序的同一个版本—既不是老一点的版本，也不是新一点的版本。
这个你不必担心。只要你提供了源代码和二进制，而用户可以看到并取得他们想要的，你就已经做了该做的事。下不下载源代码是用户自己的事。
我们的发布要求是确保用户可以获得源代码，并不是强迫不需要源代码的用户也去下载源代码。
完整的相关源代码的意思就是你用来制作二进制的源代码，但是这并不是说你的工具必须能够制作出和你发布的二进制一样的哈希值。有时，新制作的二进制和你发布的二进制很难有相同的哈希值——比如考虑这样一个例子：系统将在二进制中加入时间戳；或者编译工具的版本发生了变化。
GPL 允许任何人做一个修改版自己用而不发布。你所说的公司的做法就是一个这样的特例。因此，该公司不必发布其修改版。当该修改版使用的许可证是GNU Affero GPL时，情况有所不同。
把这个情况和网站包含或链接到独立的 GPL 程序做个比较，这些 GPL 程序在用户访问网站时分发给了用户（经常是JavaScript程序，但是也可以使用其他语言）。此时，这些发布给用户的程序的源代码必须按照 GPL 的条款来发布。
GNU Affero GPL 要求该修改版软件为其用户提供一个通过计算机网络获取源代码的方法。你所说的公司正处在这样一个状态下，所以它必须发布修改版软件的源代码。
不是，在公司内部使用只是公司为自己制作拷贝。因此，公司或组织可以开发自己的修改版并在内部部署，其员工也无权对外发布。
然而，当公司把拷贝发送给其他组织或个人时，就是发布。具体来说，为合同商提供拷贝来离岸使用就是发布。
如果该版本已经发布了，那么窃贼或许有权制作拷贝并按照 GPL 再发布，但是如果窃贼因为盗窃 CD 入狱了，那么可能只好等他出来再发布了。
如果被盗的版本没有公开，并且有公司认为它是商业机密，那么发布该版本可能在此情况下就是违反了商业机密法。GPL 并不改变这一点。如果该公司要发布该版本并且仍然把它看作是商业机密，那么该公司就违反了 GPL；但是如果该公司没有发布该版本，那么它就没有违反 GPL。
该公司违反了 GPL 并且必须停止发布。请注意这和上面的盗窃问题不同；软件拷贝遭到盗窃时，公司并未有意发布该软件，因此公司没有违反 GPL。
如果此发布程序中不包含其他人的 GPL 作品，那么该公司没有违反 GPL（更多信息，请参看 “GPL程序的开发者和GPL绑定了吗？”）。但是它在你如何使用该程序的问题上作出了自相矛盾的陈述：你既可以再发布之，又不可以再发布之。在你接受程序拷贝之前，你最好是要求它就如何使用该程序作出明确解释。
对具体的库采用宽 GPL 许可证实际上自由软件的倒退。这意味着我们部分放弃了对用户自由的保护，也部分放弃了一些 GPL 软件应有的要求。就事论事，这些放弃都是坏事。
有时，局部的倒退是一个不错的策略。在适当的情况下，对库采用 LGPL 会让这些库被更广泛地使用，因此就更多地改善了这些库、更多地支持了自由软件等等。如果范围很大，那么这就是对自由软件有益的事。但是它究竟会怎么发展呢？我们拭目以待。
如果能够对每个库都试行一段时间的 LGPL 来看看效果如何，若是没有什么帮助再改回 GPL 是最好的。但是这个做不到。一旦我们对一个具体的库使用了 LGPL，那么我们就很难再改回来。
因此，我们对哪个库使用什么许可证采用的是具体情况具体分析的原则。请参看我们关于如何判断的详细解释。
不定期的，每隔几年，我们会修改一下 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 版本。
我们不这么做是有原因的。这会导致将来某一天用户以前有的一些许可被自动收回了。
假设某个程序在2000年按照 “最新的 GPL 版本” 发布。当时，用户可以在 GPLv2 下使用该程序。我们在2007年发布了 GPLv3，所有人突然就必须在 GPLv3 下使用了。
有些用户可能根本就不知道 GPL 版本 3——但是他们还是被要求按照版本 3 来使用软件。这些用户可能无意中已经违反了许可证条款，只是因为他们不知道有新的许可证版本。这对他们不公正。
除非是因为有违反许可证的情况，我们认为收回已经授予的许可是错误的。如果自由可以撤销，那么它就不是真正的自由。因此，如果你在某个许可证版本下得到了软件，那么你就应该 一直 拥有在该许可证版本下被授予的权利。按照 “GPL 版本 N 或者任何以后的版本” 发布维持了这个原则。
GPL 可以用于手册，但是 GNU 自由文档许可证（GFDL）更适合手册。
GPL 本来就是为程序设计的；它的很多复杂条款对程序来说是关键的，但是它们对手册或书籍来说就太累赘而没有必要了。例如，任何出版纸质书的人如果没有随书提供该书的机器可读“源代码”，就必须提供随后会寄送该“源代码”的书面承诺。
同时，GFDL 的条款有助于自由手册的出版商通过销售拷贝赚钱——比如，使用封面文字。GFDL 的背书部分特有的条款使之有可能成为一个正式的标准。它允许修改版，但是修改版不能带有“标准”字样的标签。
使用 GFDL，我们允许修改手册中有关技术的内容。修改技术部分非常重要，因为修改软件的人应该有权修改相应的文档。这个自由是一个道德底线。
我们的手册还有一个阐述我们对自由软件的政治立场的章节。我们将此标记为“不变章节”，因此它们不能够被改变，也不能被删除。GFDL 为这些“不变部分”准备了条款。
字体的许可证是一个需要认真考虑的复杂问题。以下许可证例外是实验性的，但是已经获准常规性的使用。我们欢迎对此问题的建议——请参看此文的解释并写信给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 兼容库问答提供了更多的信息以及如何处理。
把 GPL 翻译成英语以外的语言很有用处。甚至有人把翻译稿发给我们。但是我们并没有批准这些翻译稿而使之成为正式有效的文件。其中的风险太高，我们还不太敢接受。
一份法律文件和程序有些类似。对法律文件的翻译就像是把一个程序从一种语言翻译到另一种语言和操作系统。只有擅长两种语言的律师可以做到——即使这样，其中还可能引入问题或缺陷。
如果我们要批准一份正式的 GPL 翻译文件，那么我们就是在授权每个人可以做翻译文件里允许她们做的事。如果翻译完全准确，那么还好。但是如果翻译有误，那么后果会是灾难性的，而且无法弥补。
如果程序有一个缺陷，我们可以发布一个新版本，而后老的版本就会慢慢减少乃至最终消失。但是一旦我们允许任何人按照一份特定的翻译文件去做事，那么我们就没法收回我们的许可，即使我们后来发现这里有一个翻译错误。
热心人有时要为我们提供翻译服务。如果问题只是找人翻译，那么它容易解决。但是真正的问题是出错的风险，提供翻译并不能避免这个风险。我们不可能批准一份不是由律师翻译的文件。
因此，目前为止，我们不会批准 GPL 的全球有效和有约束力的翻译。反过来，我们在做两件事：
人们可以参考非正式的翻译文档。这就是说我们允许人们翻译 GPL，但是我们不把它们批准为法律上有效和有约束力的文件。
未被批准的翻译没有法律效力，而且它必须明确陈述这一点。它可以这样说：
本 GPL 翻译文档是非正式的，而且也没有被自由软件基金会正式批准为有效文件。要完全确定授权内容，请参考 GPL （英文）原稿。
但是未被批准的翻译文档可以当作是理解英文版 GPL 的参考。对很多用户来说，这就足够了。
不过，在商业活动中使用 GNU 软件的企业以及对公众进行 ftp 发布的人，应该查看真正的英文 GPL 原稿以确保了解该许可证。
仅对单个国家发布有效翻译。
我们正在考虑为单个国家发布正式有效翻译文件的想法。这样的话，如果翻译有错误，那么也只是在该发布的国家之内，其破坏性还不是太大。
这仍然需要一个认同而有能力的律师花费相当多的精力和专业知识来完成一个翻译，所以我们还不能承诺这个翻译会很快出来。
当该解释器只是解释语言，回答是肯定的。此时，被解释的程序只是解释器的数据；而 GPL 并不限制处理程序的工具。
不过，如果解释器扩展到提供“绑定的”工具（经常，但不限于，库），那么被解释的程序实际上是和这些绑定工具连接在一起的。JNI 或 Java Native Interface 就是这类工具；此时 Java 程序和它调用的库是动态连接在一起的。
因此，如果这些工具是按照和 GPL 不兼容的许可证发布的，那么这就和其他连接 GPL 不兼容库的情况一样。这就意味着：
- 如果你写代码并以 GPL 发布，那么你可以给予明确的例外来允许连接到 GPL 不兼容的工具。
- 如果你写了代码并将程序按照 GPL 发布，而且你的程序就是特地设计成要和这些工具一起工作，那么人们可以认为这里有隐含的例外允许他们连接到这些工具。但是如果这确实是你想要的，你最好明确陈述出来。
- 你不能拿来别人的 GPL 代码并象上面那样使用，或者添加类似的例外条款。只有代码的版权持有者才能添加这个例外。
由于 GPL 是一个版权许可证，所以软件的版权持有者有权维护该权益。如果你发现有人违反了 GPL，那么你应该通知该 GPL 软件的开发者。他们要不就是版权持有者，要不就是和版权持有者有关系。
此外，我们鼓励采取各种可行的法律手段维护 GNU GPL 的合规，帮助用户获得完整和相应的源代码，因为这是用户的权利。归根结底，我们开发 GNU GPL 本来就是要用户拥有所有软件自由。
创建子类也是在创建衍生作品。因此，GPL 的条款会影响包含了被创建的 GPL 子类的父类的软件。
一般来说，回答是否定的—这不是法律上的要求。具体来说，回答依赖于你要用的库以及这些库的许可证。大多数系统库不是使用 GNU LGPL，就是使用 GNU GPL 加上一个允许该库连接任何程序的例外条款。这些库可以用于非自由的程序；但是就 LGPL 许可证来说，它还是有一些你必须遵守的要求的。
有些库是只以 GNU GPL 发布的；你必须使用和 GPL 兼容的许可证才能使用这些库。但是这些通常是更加专用的库，并且在其他平台上你也很难找到类似的库，所以对于简单的程序移植你可能不太会涉及这些库。
当然，如果你的软件是非自由的，那么它并没有对我们的社区做贡献，而看重自由的人是不会用这种软件的。只有要放弃自由的人才会使用你的软件，这意味着该软件实际上是在诱使人们失去自由。
如果你希望将来回首往事的时候，你的软件曾经为建设美好和自由的社会做出了贡献，那么你需要让它成为自由软件。
不。GPL 并不要求人们使用互联网来发布程序。它也没有要求某个特定的人来再发布程序。而且（除了一个特定的场景），如果有人决定要再发布一个程序，GPL 也没有说他必须把程序发布给你或这任何特定的人。
GPL 要求的是如果他愿意，他有自由为你发布一份该程序的拷贝。一旦版权持有者发布了程序的拷贝给某个人，那么这个人就可以再发布拷贝给你或其他人，只要他觉得合适。
不行。这样的许可证自相矛盾。让我们看看它对作为用户的我意味着什么吧。
假定我从原始版本（版本甲）开始，并添加了一些代码（比如 1000 行），而后按照 GPL 发布了该修改版（版本乙）。GPL 说任何人可以再修改版本乙并按照 GPL 发布。所以我（或其他人）可以删掉这 1000 行代码，制作版本丙。版本丙的代码其实和版本甲一样，但是版本丙是遵循 GPL 的。
如果你想拦住这条去路，在许可证中明确说我不能通过删除版本乙的代码制作和版本甲一样的程序，不过是遵循 GPL 许可证的，那么你的许可证实际上是在说我不能完全按照 GPL 许可证使用版本乙。换句话说，你的许可证实际上不允许用户按照 GPL 发布一个修改版，比如版本乙。
把软件拷贝移送到或者从该机构拿出来是否构成 “发布” 是一件按照版权法在法庭里决定的事。GPL 不会也不能超越适用地的法律。美国法律对此也没有清晰的界定，但是倾向于认为这不是发布。
如果在某些国家，这个被认为是发布，那么该机构就必须获得再发布该软件的权利，实际上也是这样做的。如果该机构由一个母公司控制，那么有没有再权发布就由母公司说了算。
有些软件的安装系统有一个要求你点击同意 GPL 的地方，否则就意味着同意了 GPL 的条款。这不是要求，也不被禁止。点不点击同意，GPL 的条款并不会改变。
单是同意 GPL 并没有对你强加什么义务。你没有被要求同意任何事才能使用 GPL 软件。只有你修改或分发该软件时，你才有义务。如果你觉得点击同意 GPL 有问题，那么没有人可以阻止你改写该 GPL 软件并跳过点击同意。
不。安装程序和被安装的文件是分别的作品。因此，GPL 条款不应用于该安装程序。
这并不是违反 GPL。这些分发商（几乎所有此类分发商都从事着销售自由软件和相关服务的商业活动）是在降低他们自己的法律风险，而不是在控制你的行为。美国的出口管制法可能会使承担责任，如果他们明知故犯地把软件出口到某些国家或者把软件交给可能会这样做的第三方。通过获取他们客户或伙伴的此类声明，他们就能够在以后被监管机构盘查分发软件的去向之时保护自己。他们并不是在限制你对软件的做法，他们只想避免因你的所作所为而受到牵连。因为他们没有对软件添加额外的限制，所以他们没有违反 GPLv3 的第 10 节或 GPLv2 的第 6 节。
FSF 抵制把美国出口管制法律应用于自由软件。这些法律不但和自由软件的总目标不兼容，而且这些法律也没有实现任何有意义的政府目标。因为自由软件现在已经被几乎所有国家所用而且将来也应该这样，包括那些没有出口管制法的国家和没有参加美国主导的贸易禁运活动的国家。因此，实际上没有政府被美国的出口管制法剥夺了自由软件，反之，对我们而言，任何国家的公民都不应该被剥夺自由软件，无论他们的政府政策是什么样的。不管你住在哪里，也不管你要干什么，你都可以从我们这里获得由 FSF 发布的所有 GPL 软件的拷贝。与此同时，FSF 理解美国的商业分销商遵守美国法律的诉求。他们有权选择他们分发具体自由软件的对象；使用该权利并不违反 GPL，除非他们添加了 GPL 许可之外契约式限制。
不行。在这种场景下，要求付费就是限制用户用户运行该程序。这是在 GPL 之上的额外要求，而 GPL 恰恰禁止这样做。
首先，请在你的软件包里加入新版的 GPL 许可证。如果你计划使用 LGPLv3，那么确保你加入了 GPLv3 和 LGPLv3 这两个许可证的拷贝，因为 LGPLv3 现在是作为 GPLv3 的额外许可撰写的。
其次，把你现有的 v2 许可证声明（通常在文件头部）全部用位于 GNU 许可证须知 的新推荐文字替换。新的推荐文字更能适应将来的变化，因为它不再带有 FSF 的邮寄地址。
当然，其他讲述软件许可证的描述性文字（比如 README）也应该做适当的更新。
由于 GPLv2 是在点对点软件发布成为通用模式之前写成的，所以用这种方式分享代码时很难满足它的要求。在 BitTorrent 发布符合 GPLv2 的目标代码的最佳方式是在同一个 torrent 上包含所有的相关源代码，这个就贵的离谱了。
GPLv3 有两个方法解决此问题。第一，下载此 torrent 并在此过程中将数据发送给第三方的人不会被要求做任何事。这是因为第 9 节说 “只是因为点对点传输而接收软件拷贝等辅助的软件传播活动不必接受 [本许可证]。”
第二，GPLv3 的第 6(e) 节为——torrent 的原始种子发起者——设计了一个清晰而直接的方法来提供源代码，这就是告诉接受方源代码在公共网络服务器的哪个地方可以得到。这就让所有想得到源代码的人可以得到，而对分发者几乎没有麻烦。
有些设备使用可以升级的自由软件，但是它们采用了一种不允许用户修改软件的设计。有很多方法可以做的这一点；比如，有时硬件会检查已安装软件的校验和，并在匹配错误时关机。这些制造商遵循 GPLv2 给了你源代码，但是你还是没有修改这个软件的自由。我们称之为 tivoization。
当人们分发包含遵循 GPLv3 软件的最终用户产品时，GPLv3 的第 6 节要求他们提供修改此软件的信息。最终用户产品是该许可证定义的一个专门术语；最终用户产品包括便携式音乐播放器、数字式录像机以及家用安全系统等。
不；你可以使用按照 GPLv3 发布的软件来开发 DRM 技术。不过，如果你这么做，那么按照第 3 节所述，你的系统不再被当作是一个有效的技术 “保护” 手段，这意味着如果有人破解了 DRM，那么她也有权利分发她的软件，而不受 DMCA 和其他类似法律的妨碍。
和往常一样，GNU GPL 并不限制人们用软件做事，它只是阻止人们限制其他人。
任何有版权的素材都能够使用 GPL 来授权。GPLv3 还能够为涉及其他版权法律的素材授权，比如半导体光掩模。因此，你可以按照 GPL 条款来发布一款物品的构图或线路板。
很多时候，版权并不覆盖到从构图制作物理硬件。此时，你关于构图的许可证就是不能发挥对制造或销售物理硬件的控制，无论你使用什么许可证。当版权覆盖到硬件制造时，比如集成电路光掩模，GPL 就能够发挥作用。
不。只有一种情况你需要发布签名密钥，这就是如果你把 GPL 软件传输到一个用户最终产品，而该产品的硬件在正常工作之前会验证签名密钥。这是一个特殊的情况，你需要为每个拥有此设备的人按需提供签名密钥来验证和安装修改版软件，这样该设备才能运行修改版软件。如果每个设备使用不同的密钥，那么你只需为每个设备购买者提供一个密钥。
不。发布包含着 GPLv3 软件的设备的公司最多是被要求向拥有目标代码的人提供源代码和安装信息。投票人并不拥有投票机（就像其他售卖机），连临时拥有都不算，所以投票人没有机器上二进制软件的所有权。
不过，请注意，投票是一个非常特殊的例子。仅仅是因为计算机运行着自由软件并不意味着你就应该相信此投票计算机。我们认为不能相信投票机。投票应该使用纸质系统。
实际上是有的。其第 10 节禁止传输软件的人发起针对其他许可证的专利诉讼。如果有人这么做了，那么第 8 节解释了他们这样做会失去许可证以及任何相关专利的许可证。
如果所用的代码片段很小，那么你可以按照公平使用或相似的法律来使用。否则，你不能使用。
这是说你输送源代码的所有授权和条件同样适用于输送目标代码：你可以收费，你不能改变版权声明，等等。
不。当你传输 GPL 软件时，你必须遵循该许可证特定版本的条款。此时，该许可证版本定义了你的义务。如果用户选择使用以后的 GPL 许可证版本，那么只是他们有了额外的授权——这并不要求你遵循后来的 GPL 版本的条款。
请不要以此作为向社区做出专利胁迫的手段。在很多国家，按照 GPLv2 发布软件就已经隐含着对接收者的专利授权，这样他们就能够在 GPL 下实践自己的权利。即使不是这样，强制实行专利法的人也会成为社区的敌人，而我们会奋起反击这样的行为。
“贡献者版本”只是你的库版本。
不。从 GPLv2 到 GPLv3，很多要求都变了，就是说 GPLv2 里的一些确切需求在 GPLv3 没有，反过来也一样。比如，GPLv3 的终止条款比 GPLv2 要更为宽松，因此它们和 GPLv2 的终止条款不同。
由于这些变化，这两个许可证不兼容：如果你试图组合按照 GPLv2 发布的代码和按照 GPLv3 发布的代码，那么你就违反了 GPLv2 的第 6 节。
不过，如果代码是按照 GPL “版本 2 或以后版本”发布的，那么它就和 GPLv3 兼容，因为 GPLv3 就是一个以后版本。
GPLv3 明确要求再发布要包含完整的 “安装信息”。GPLv2 没有使用这个条款，但是它也要求再发布包含与
控制编译和安装可执行文件的脚本
有关的完整源代码。这个没有 GPLv3 的 “安装信息” 全面。因此，GPLv3
关于安装信息的要求更严格。
修正违反意味着你通过调整遵循了许可证的要求。
可以。第 7 节具体地赋予你添加自己的免责声明的权利。
你需要保证用户在你的界面上可以访问到 GPLv3 所要求的适当法律声明。例如，如果你写的是有声界面，那么你可以设计一个朗读声明的命令。
只要你们俩不是私下使用该软件，而只是在公司使用该软件，那么回答是否定的。因为软件拷贝是公司的，不是你们自己的。拷贝只是传播，而非输送，原因是公司并没有为第三方提供拷贝。
是的，你可以这么说。正如如果用户修改了设备里的软件，用户就失去售后保障一样，你没有义务承担其他人对 GPLv3 软件的所作所为带来的质保问题。
GPLv3 的早期草拟版本中允许许可证的授权方在第 7 节中加入一个类似 Affero 的要求来发布源代码。不过，有些开发和依赖于自由软件的公司认为这个要求难以承担。他们想避免带有此条款的代码，并且表达了对于审核此类代码的管理成本的担忧。通过把 GNU Affero GPLv3 作为一个单独的许可证发布，添加相应的条款，加上允许 GPLv3 让使用这些许可证的代码互相连接，我们就实现了初期定下的全部目标，同时也让决定哪部分代码应该公开发布变得更加容易了。
GPLv2 的术语 “发布” 是从美国版权法借用的。经年累月，我们了解到一些法律体系在其版权法中也使用同样的术语，但是意义并不相同。为了让我们要表达的意思无论在什么地方都尽可能的清晰，我们发明了这些新的术语。这些术语在任何国家的版权法里都没有使用，而我们直接在许可证中定义了它们。
不行，因为你的两个目标互相矛盾。GNU GPL 专门设计成禁止添加额外的限制。GPLv3 在第 7 节允许非常小的例外，但是用户可以去除任何其他后添加的限制。
更普遍地说，一个限制用户范围，或者限制用户使用目的的许可证，不是自由软件许可证。
是的，差不多是一回事。在我们针对 GPLv2 的执法过程中，我们了解到一些法律体系在其版权法中使用 “发布” 一词，但是涵义和我们的不同。我们创造了新的术语，用来避免这些不同造成的混淆和问题。
“使之公开可得” 的一个例子就是把软件放在公共的网站或 FTP 服务器上。这样做了之后，人们可能还要花一段时间才能获得该软件——但是也有可能有人马上就下载了软件，你也满足了 GPL 对马上的义务。因此，输送包含了使之公开可得这一活动。
为你自己制作软件拷贝就是传播的主要形式，但是它不是输送。你这样做可能是在多个电脑上安装该软件，也可能是在做备份。
不算。预连接是编译过程的一部分；它并没有牵扯到超出编译之外或之上的许可证要求。如果你被允许把程序和库连接起来，那么预连接也就没有问题。如果你要发布预连接的目标代码，那么你就需要遵守第 6 节的条款。
没有。就我们所调查的此类问题所处的法律体系来讲，这种出借不算是输送。出借电脑的所有者不承担 GPL 的任何义务。
是的。如果两方企图互相合作来规避 GPL 的要求，那么他们两个都会受到侵权的追讨。由于输送的定义清楚地包含了构成次要侵权的活动，这种互相串通的案例就是尤其明显的侵权。
只要获取源代码的过程不是极其繁重以致难以操作，那么这个方法也是可以接受的。通过使用公开可得的自由软件客户端，能够下载目标代码的人也能够通过你的版本控制系统获取源代码。你应该为用户提供清晰和方便的指南，以便他们能够获取和目标代码对应的源代码——毕竟他们也许并不想要最新的开发版。
不行。当软件通过用户产品来输送源代码时，你必须提供安装信息，其定义明确说：“安装信息必须足以保证修改后的代码不能是单单因为被修改而导致设备禁止或干扰其运行。”如果设备采取了某种远程验证，那么安装信息就必须提供使修改后的软件上报其合法性的方法。
这个是指你通过网络发送数据时遵守的交通规则。例如，服务器是否有每日接受发送请求的总数限制、或者上传文件的大小是否受限等，如果你不遵守这些规则，那么你的访问可能会被拒绝。
这些规则和发送的数据没有直接的关系。例如，如果网络服务器向你的设备发送消息，那么它不能因为你修改了软件——比如不显示这些消息——就拒绝你的网络访问。
这包括许多设备制造商提供的产品安装、使用和故障排除服务。如果你的设备依赖网络服务等设施来正常工作，那么根据第 6 节的条款，无论是否使用网络，修改版的设备通常仍然享有这些服务。
很简单，这就是说这些许可证条款超越任何与之冲突的条款。例如，如果没有此条款，有些人可能会说你不能把 GPLv3 代码和 AGPLv3 代码组合在一起，因为根据 GPLv3 的第 7 节，AGPL 的额外要求应该被界定为是 “额外的限制”。这段文字就澄清了我们的解释，而你可以把以上两种许可证的代码组合在一起。
这段文字仅用来解决许可证的矛盾之处。当两个条款没有矛盾之时，两个条款必须同时满足。该文字没有授予你忽略许可证其他部分的权利——反之，它只是隔离出了很有限的例外情况。
许可证的第 1 节定义了“相关的源代码”，你应该按照所列的要求提供源代码。因此，如果你的修改版的依赖库使用了其他的许可证，比如 Expat 或 GPLv3，那么相关的源代码应当包含这些依赖库（除非它们是系统库）。如果你修改了这些库，那么你必须提供修改后的源代码。
第 13 节第一段的最后一句话只是用来强调大多数人本来就接受的假定：即使组合 GPLv3 代码是由第 13 节的特殊例外来处理的，组合程序也仍然要按照要求包含相关源代码。这句话不是说你 只 需提供 GPLv3 代码；反之，它是说 GPLv3 代码 没有 被排除在相关代码的定义之外。
如果程序的设计明显是通过网络接受用户请求和发送回复，那么该程序就符合远程交互的判定条件。符合此类条件的常见程序包括网络服务器和邮件服务器、交互式网络应用程序以及在线游戏的服务器。
如果程序的设计不是明显地通过网络来和用户交互，但是该程序碰巧运行在一个需要网络交互的环境下，那么它不算是远程交互程序。例如，用户使用 SSH 或远程 X 会话运行了某个应用。
它们实际上是等效的。Apache 许可证 2.0 版的“法律主体”的定义在各种法律协议中是非常标准的——如果有法庭做出了不同的解释，那就非常地意外了。我们完全相信法庭看到 GPLv3 和判断谁是许可证被授权者时会做出一致的解释。
“程序” 是指使用 GPLv3 许可证授权的具体作品，该作品由授权方或发布方发布给具体的许可证接收方。接收时，程序就是一个按照具体 GPLv3 许可证发布的具体软件。
“程序”不是指“所有按照 GPLv3 发布的作品”;这种解读没有道理。为了更好地理解这个道理，我们发布了 关于 “程序” 这一术语的分析。
什么也没有。GPL 对此没有任何约束。
AGPLv3 要求软件向 “所有与其通过网络进行远程交互的用户” 提供源代码。该程序被叫做 “客户端” 还是 “服务器” 并不重要，你需要问的问题是你是否期待人们通过网络远程和该程序交互。
对于代理服务器上的软件，你可以通过向代理服务器用户正常发送消息的方法为他们提供源代码。例如，网络代理可以使用起始页面。当用户开始使用代理时，你可以把他们引导到提供源代码等信息的页面。
AGPL 规定你必须为 “所有用户” 提供源代码。如果你知道某些用户已经获得了目前版本的源代码，那么你就无需为这些用户再重复此事。
各种 GNU 许可证互相之间友好兼容。你唯一可能碰到的无法组合源代码的情况是一个程序 只 使用了老的许可证而另一个程序使用了新的许可证。
下面是各种 GNU 许可证组合的兼容性的详细列表，它可以作为一个具体案例的快速参考。假定有一个软件使用了其中一个许可证，而你想把它的代码组合到你要发布的项目中（无论是你自己的原创，还是你对其他软件的修改版）。在表格的第一行找到你的项目要用的许可证，然后在左边第一列找到你要组合的软件的许可证。这一行一列的交叉表格就是你是否可以组合两个软件的答案。
当我们说 “复制代码,” 时，我们是指：你从一个软件取了一部分代码，改或不改都行，然后把它添加到你的程序中构成一个作品。“使用库” 是指：你没有直接复制源代码，而是在编译或运行时通过连接、导入或其他典型的机制把软件绑定在一起。
表格中有 GPLv3 的地方, 其兼容性的陈述对 AGPLv3 也适用。