GNU通用公共许可证
一套自由軟件許可證 来自维基百科，自由的百科全书
一套自由軟件許可證 来自维基百科，自由的百科全书
GNU通用公共授权条款（英语：GNU General Public License，缩写GNU GPL 或 GPL），是被广泛使用的自由软件授权条款，给予了终端用户运行、学习、共享和修改软件的自由。[6]授权条款最初由自由软件基金会的理查德·斯托曼为GNU专案所撰写，并授予电脑程序的用户自由软件定义（The Free Software Definition）的权利。[7]GPL是一个Copyleft授权条款，这意味著只要专案的某个部分（如动态链接库）以GPL发布，则整个项目以及衍生作品只能以相同的许可条款分发[8]。这与宽松自由软件许可证有所区别 ，如BSD授权条款和MIT授权条款就是其中被广泛使用的例子。GPL是第一个普遍使用的Copyleft授权条款。
 |
历史上，GPL授权条款系列一直是自由和开源软件领域最受欢迎的软件许可之一。[6][9][10][11][11][11][12][13]根据GPL许可的优异自由软件程序的例子有Linux核心和GNU编译器集合（GCC）。大卫·A·惠勒认为，GPL提供的Copyleft对于基于Linux的系统的成功至关重要，给予向核心贡献的程式设计师保证他们的工作将有益于整个世界并保持自由，而不至于被不提供回馈给社群的无良软件公司所剥削。[14]
2007年，发布了第三版授权条款（GNU GPLv3），以解决在长期使用期间发现的第二版（GNU GPLv2）所发生的一些困扰。为了使授权条款保持最新状态，GPL授权条款包含一个可选的“并延伸到未来版本”条款，允许用户在FSF更新的原始条款或新版本之间进行选择。有些开发人员在软件授权使用时，选择省略它；例如，Linux核心已经在GPLv2下获得许可，就不需包括“并延伸到未来版本”的声明。[15][16]
GPL授予程序接受人以下权利，或称“自由”，或称“copyleft”：
相反地，随版权所有软体的终端使用者授权合约几乎从不授予用户任何权利（除了使用的权利），甚至可能限制一些法律允许的行为，比如逆向工程。
GPL与其他一些更“许可的”自由软体授权条款（比如BSD授权条款）相比，主要区别就在于GPL寻求确保上述自由能在复制软体及衍生作品中得到保障。它透过一种由斯托曼发明的叫Copyleft的法律机制实现，即要求GPL程序的衍生作品也要在GPL之下。相反，BSD式的授权条款并不禁止衍生作品变成专有软体。
GPL是自由软件和开源软件的最流行授权条款[18]。到2004年4月，GPL已占Freshmeat上所列的自由软件的约75%，SourceForge的约68%。类似的，2001年一项关于Red Hat Linux 7.1的调查显示一般的代码都以GPL发布。著名的GPL自由软件包括EMACS，Linux核心（并非所有Linux发行版的核心都是开源的）和GCC。
GPL由理查德·斯托曼于1989年编写，提供给列入GNU专案的一些软体程式所使用。原始的GPL基于GNU Emacs（1985），[19]GNU Debugger和GNU C编译器的早期版本中使用的类似授权条款的统一。[20]这些授权条款包含与现代GPL类似的规定，但具体针对每个程序，使其不兼容，尽管是相同的授权条款。[21]Stallman的目标是提供一个可用于任何专案的授权证，从而使许多专案得以共享代码。GPL版本1就这样，在1989年1月诞生。
到1990年时，某些因素使得共享庫（Library），应该要有比GPL更宽松的授权许可的需求。所以当GPL版本2在1991年6月发布，另一授权条款——程式库通用授权条款（Library General Public License，简称 LGPL）也随之诞生，并记作“版本2”以示对GPL的补充。版本号在LGPL版本2.1发布时不再相同，而LGPL也被重命名为GNU宽通用公共许可证以体现GNU的哲学观。
授权条款的第二个版本，版本2，在1991年发布。在接下来的15年中，自由软件社群的成员很关心GPLv2授权条款中的问题，可能会让某些人钻漏洞而违反授权条款，而违背了原先GPL许可授权软体的原意。[22]这些问题包括Tivo化[23]（来自硬体的软体限制，意指将GPL授权软体安装在硬体上，又拒绝运行更动相关软体的修改版本），类似与Affero通用公众授权条款类似的兼容性问题，以及微软和自由开源软件，其中一些被认为试图将专利申请用作于对付自由软件社群的武器。
第3版旨在解决这些问题，并于2007年6月29日正式发布。[24]
根据创用CC官方网站，GNU General Public License 的台湾法律用语翻法为“GNU通用公共授權條款”[25]，香港法律用语翻法亦为如此[26]。
1989年2月25日发布的GNU GPL 版本1阻止了软件经销商限制自由软件定义的两个主要方式。第一个问题是经销商可能仅发布二进位文件 - 可执行，但不能由人类读取或修改。为了防止这种情况，GPLv1表示，任何分发二进位代码的供应商还必须按照相同的许可条款（授权条款的第3a和3b节）提供可读的原始码。
第二个问题是经销商可能会增加授权条款的限制，也可能会将软件与其他具有其他分发限制的软件相结合。两套限制的联合将适用于组合工作，从而增加不可接受的限制。为了防止这种情况，GPLv1表示，修改后的版本作为一个整体，必须按照GPLv1（授权条款第2b和4节）的条款分发。因此，根据GPLv1条款分发的软件可以以更宽松的条款与软件相结合，因为这不会改变整体可以分发的条款。然而，根据GPLv1分发的软件不能与在更严格的授权条款下分发的软件相结合，因为这与根据GPLv1的条款可以分发的要求相冲突。
根据理查德·斯托曼的说法，GPLv2的主要变化是“自由或死亡”（Liberty or Death）条款[21]。就如字面上所说，“被许可人只有在满足所有授权条款的义务下”才可以分发包含GPL授权的软体，尽管他们可能拥有任何其他法律义务。换句话说，就算有相互矛盾的义务，授权条款的义务也可能不被切断。该条款旨在阻止任何一方使用专利侵权索赔或其他诉讼来损害用户在授权条款下的自由。这章中的意思是，为了在一定程度上保障和尊重其它一些人的自由和权益，无论任何人要发布源于GPL的软体的时候，同时也须遵守强制的条款分享原始码，否则他将根本无权发布该软体。[注 1]
到1990年，越来越明显的是，对于C函式库来说，本质上已经跟受专利保护的软件函式库的功能表现相当，有一个限制较少授权条款对于自由软体发展的策略上来说更为实用；因此，当GPL的版本2（GPLv2）在1991年6月发布时，第二类别的授权条款：函式库通用公共授权条款（英语：Library General Public License），也同时被引入，并从第二版编号开始，表明两者是互补的。版本号在1999年发行，当时LGPL的版本2.1被发布，更名为GNU宽松通用公共授权条款（英语：Lesser General Public License），以反映其在哲学中的地位。
最常见的是“GPLv2并延伸到未来版本”的声明，让授权条款的用户了解，得以允许升级到GPLv3。
到2005年，GPL版本3开始由斯托曼起草，由伊本·莫格林和软件自由法律中心（Software Freedom Law Center）提供法律咨询[27]。2005年底，自由软件基金会 （FSF）宣布了GPL（GPLv3）第3版的工作。2006年1月16日，公布了GPLv3的第一个“讨论稿”，公众谘询开始。公众谘询原计划为九至十五个月，但最终延长至十八个月，其中出版四份草案。2007年6月29日，官方正式版GPLv3于由FSF发布。[28]
之后，理查德·斯托曼在2006年2月25日自由及开源软体开发者欧洲会议的演讲时谈到最重要的四件事：
还有一些其他的更改涉及国际化，如何处理授权条款违规，以及版权所有者如何授予额外权限。[27][29]它还增加了一项规定，“剥离”（strips）其法定价值的数位版权管理（Digital Rights Management，缩写DRM），所以人们可以合理的当在法院被视为侵犯DRM时，去破解运行GPL软件的任何东西，而不会违反DMCA等法律。[30]
公共谘询过程由自由软件基金会在软件自由法律中心、欧洲自由软件基金会[31]和其他自由软件组织的协助下进行协调。透过FSF [1] （页面存档备份，存于互联网档案馆）网站从公众收集评论[32]。该门户网站运行名为 stet的专用软体。在公众谘询过程中，提交了第一稿的962条意见[33]。最后，共提交了2636条意见[34][35][36]。
第三稿于2007年3月28日发布[37]。该草案包括旨在防止与专利相关协议（如有争议的Microsoft-Novell专利协议）的语言 ，并将反倾销条款限于“用户”或“消费品”。它还明确删除了“地理限制”一节，确认公开谘询开始时就提到可能会删除的这一部分。
最后的第四个讨论草案[38]于2007年5月31日发布。它引入了Apache授权条款版本2.0兼容性（以前的版本不兼容），澄清了外部承包商的作用，并提出了一个例外，以避免充满争议的Microsoft-Novell专利协议再度发生，在第11节第6段中说：
| “ | 您不得传送具GNU授权条款保护的软体作品，如果您是与营销软体业务（后称第三方）进行安排的缔约方，根据该协议按照你传送作品活动的程度，您付款项给第三方，又根据该协议，对于可能收到与您所涉涵盖的工作的其它方，第三方获得歧视性专利。 | ” |
这旨在使未来像这样的交易无效。该授权条款还意味著Microsoft将其授予Novell客户的专利授权条款扩展到使用GPLv3软件的所有用户，使用GPLv3软件；除非当Microsoft合法地是GPLv3软件的“传送者”时，才有可能[39][40]。
此外，GPLv3的早期草案让许可方添加了一个Affero类的需求，将会填补GPL中的ASP漏洞[41][42]。由于担忧该附加要求的代码检查所需要的额外行政费用，决定将GPL和Affero授权条款分开[43]。
值得留意的是Linux核心的一些高调的开发人员 ，例如林纳斯·托瓦兹、葛雷格·克罗哈曼和安德鲁·莫顿，向大众媒体发表了评论，并就讨论草案1和2的部分内容作了公开声明[44]。核心开发人员提及关于DRM/Tivoization、专利和“附加限制”的GPLv3草案条款，并警告会产生“开源宇宙”（Open Source Universe）的巴尔干半岛式分裂[44][45]。林纳斯·托瓦兹决定不采用GPLv3作为Linux核心，仍然使用GPLv2授权[15]，甚至在几年后重申了他的批评[46][47]。此事曾引起理查德·斯托曼的不满。
GPLv3提高了与许多开放原始码软件授权条款（如Apache授权条款版本2.0）和GNU Affero通用公共授权条款（GPLv2无法组合）的兼容性[48]。但是，如果所使用的GPLv2授权条款具有可选的“或更高版本”子句，并且软件升级到GPLv3，GPLv3软件只能与GPLv2软件组合并共享代码。虽然FSF认为“GPLv2并延伸到未来版本”条款是许可GPLv2软件的最常见形式[49]，诸如Toybox开发商Rob Landley将其描述为“救生艇条款”（lifeboat clause）[50][51]。使用可选“或更高版本”条款许可的软件专案包括GNU专案，而没有该子句的最明显的案例是Linux核心[52]。
GPL的条款和条件必须提供给任何接受GPL应用的作品的副本（“被许可人”）的人员。任何遵守条款和条件的被授证人员都有权修改作品，以及复制和重新分发作品或任何衍生版本。被许可人被允许为此服务收取费用，或无偿。后一点将GPL与禁止商业再分发的软件许可区分开来。FSF认为，自由软件不应该限制商业用途，[53]GPL明确规定GPL作品可能以任何价格出售。
GPL还规定，经销商不得对GPL授予的权利施加“进一步限制”。禁止根据不披露协议或合同分发软件等活动。
授权条款版本2的第四部分和版本3的第七部分要求，作为预编译二进位文件分发的程序应附有原始码的副本，透过与前一版本相同的机制分发原始码的书面报价编译的二进位文件或书面报价，以获取用户在GPL下接收预编译二进位文件时获得的原始码。版本2的第二部分和版本3的第五部分还要求“所有收件人本程序附带的授权条款副本”。授权条款的版本3允许以其他方式提供原始码来实现第七部分。这些包括从相邻网络服务器下载原始码或透过对等传输，只要编译代码是可用的，并且在哪里可以找到原始码的“清晰方向”。
除非作者明确赋予 FSF 版权（除了作为GNU专案一部分的程序很少发生），否则FSF对GPL发布的作品不具有版权。只有个人版权持有人有权在发生授权条款时才起诉。
GPL下的软件可以用于所有目的，包括商业目的，甚至作为创建专有软件的工具，例如使用GPL授权的编译器时[54]。分发GPL许可作品（如软件）的用户或公司可能会收取副本费用或无偿提供费用。这将GPL与共享软件授权条款区分开来，允许复制用于个人使用，但禁止商业发布，或版权法禁止复制的专有许可。FSF认为自由软件不应该限制商业使用和发布（包括再发布）[53]。GPL明确规定，GPL工作可能以任何价格出售。
在纯私人（或内部）使用 - 没有销售和没有发行 - 软件代码可能被修改和零件重复使用，而不需要发布原始码。对于销售或分销，整个原始码需要提供给终端使用者，包括任何代码更改和添加 - 在这种情况下，应用copyleft来确保终端使用者保留上面定义的自由。[55]
然而，作为GPL许可操作系统（如Linux）下的应用程式运行的软件不需要根据GPL进行许可或者以原始码可用性分发 - 许可只依赖于使用的库和软件组件，而不是依赖于底层平台[56]。例如，如果一个程序仅由自己的原始定制软件组成（software component），或者与其他软件组件的原始码组合在一起[注 2]，则自己的定制软件组件不需要根据GPL授权，不需要使其代码可用；即使所使用的底层操作系统是根据GPL授权的，运行在其上的应用程式也不被视为衍生作品。[56]只有在程序中使用了GPLed部件（程序已经分发）的情况下，程序的所有其他原始码才能在相同的许可条款下提供。GNU较宽松公共授权条款（LGPL）被创建为具有比GPL更弱的Copyleft，因为它不需要在相同的许可条款下提供自己定制的原始码（不同于LGPLed部分）。
GPL授权版本的修改后作品的发行权不是无条件的。当有人分发GPL的作品又加上自己的修改时，分发整个作品的要求不能大于GPL中的要求。这个要求被称为Copyleft。它透过软件程序使用版权获得法律权力。由于GPL的作品受版权保护，被许可人无权重新分发，即使是以修改形式（除合理使用 ）外，除了许可条款外， 如果希望行使通常受版权法限制的权利，例如重新分配，只需遵守GPL的条款。相反，如果在不遵守GPL条款（例如保留原始码秘密）的情况下分发作品的副本，则原始作者可以根据版权法提起诉讼。因此，“Copyleft使用版权法来完成”与常见法律的设定目的相反，不是施加限制，而是“赋予其他人权利，以确保权利不能随之被剥夺的方式。”如果在Copyleft声明中找到任何法律缺陷，它也可以确保不给予无限的重新分发权限。[来源请求]
许多GPL程序的经销商将原始码与执行档捆绑在一起。满足Copyleft的替代方法是提供书面报价，以便在物理介质（如CD）上提供原始码。实际上，许多GPL的程序透过Internet进行分发，原始码透过FTP 或 HTTP提供。对于互联网分发，这符合授权条款。只有当一个人试图重新分发程序时，Copyleft才适用。只要不将修改后的软件分发给任何人，开发人员可以制作私有修改版本，无需泄露修改。请注意，Copyleft仅适用于软件，而不适用于其输出（除非该输出本身是程序的衍生作品[注 3]）。
例如，运行GPL内容管理系统（CMS）修改版的衍生产品之公共门户网站不需将其更动分发给底层软件，因为其输出不是衍生产品。
有人辩论，如果以程式码混淆形式发布原始码是否违反GPL，例如在作者不太愿意提供原始码的情况下。普遍认为虽然这是不道德的，但无法认为是违法行为。这问题已得到澄清：当授权条款被更改为v2时，就需要提供原始码的“首选”版本。[57]
GPL被设计为授权条款 ，而不是契约[58][59]。在一些普通法（Common Law）司法管辖区，授权条款和契约之间的法律区别是重要的：契约可以透过契约法执行，而授权条款是根据著作权法执行的。然而，这种区别对于契约和授权条款之间没有区别的许多司法管辖区（如民法系统）并不适用[60]。
GPL原理很简单：在著作权法下，你不遵守GPL的条款和条件你就没有相对应的权利。而作品在没有GPL的情况下，著作权法作为默认条款发生效力，而不是作品进入公有领域。那些不接受GPL条款和条件的人根据版权法没有许可复制或分发GPL许可软件或衍生作品。然而，如果他们不重新分发GPL的程序，他们仍然可以按自己的喜好使用组织内的软件，使用该程序构建的工程（包括程序）不需要被该授权条款覆盖。
艾里逊·兰德尔认为，GPLv3作为授权条款对于读者来说是不必要的混乱，可以在保留相同的条件和法律效力的情况下进行简化。[61]
GPL的文案本身，受版权保护 ，版权由自由软件基金会持有。GPL的文案本身，却不在GPL之下。 经许可的版权不允许修改授权条款。 允许复制和分发授权条款，因为GPL要求收件人获得“本授权条款与本计划一起”的副本。 [62]根据GPL常见问题，任何人都可以使用GPL的修改版本，只要他或她使用不同的名称作为授权条款，不提“GNU”，并删除前言，尽管如果使用自由软件基金会（FSF）获得许可，则序言可以在修改后的授权条款中使用。
FSF允许人们根据GPL创建新的授权条款，只要衍生的授权条款未经许可不使用GPL前缀。 然而，这是不鼓励的，因为这样的授权条款可能与GPL不兼容[62]，并导致感染的授权条款扩散（license proliferation）。
由GNU专案创建的其他授权条款包括GNU通用公共授权条款，GNU自由文件授权条款和Affero通用公共授权条款。
据FSF称，“GPL不要求您发布修改版本，或其任何部分，您可以自由地进行修改和留作私人使用，而无需发布。”然而若是向公众发布GPL许可的实体，则有连结的问题：换言之，“使用GPL函式库的专利程序是否违反了GPL ？”
这个关键的争议的重点是“非GPL软件是否可以合法地连结或动态地连结到GPL函式库”。这个问题有不同的看法。GPL清楚地表明，GPL下的所有衍生作品代码都必须属于GPL。关于使用GPL函式库和将GPL软体捆绑到更大的包中（可能透过静态连结混合成二进位文件），会出现歧义。这最终不是GPL 本身的问题，而是版权法如何界定衍生作品。有以下观点存在：
自由软体基金会（其拥有若干著名的GPL软体产品和授权文字本身的版权）声称，使用动态连结函式库的可执行档确实是衍生作品。然而，这不适用于彼此通信的单独程序。自由软体基金会还创建了LGPL，LGPL与GPL极为相似，但额外允许以“使用函式库”为目的的连结。理查德·斯托曼和自由软体基金会特别鼓励函式库作者根据GPL来进行授权，以便专有程序无法使用GPL函式库，透过为自由软体世界提供比专有世界更多的工具来保护自由软体世界。
有些人认为，当静态连结产生衍生作品时，不清楚动态连结到GPL代码的可执行档是否应被视为衍生作品（请参阅Weak Copyleft）。Linux作者Linus Torvalds同意动态连结可以创建衍生作品，但在这种情况下不一致。一位Novell律师写道，动态连结不算是衍生作品的观点合理但是不够明确，专有的Linux核心驱动程式就是善意的动态连结的一大明证。在Galoob对任天堂案中，美国第九巡回上诉法院将衍生作品定义为具有“形式”或“永久性”，并指出“侵权作品必须以某种形式包含一部分受版权保护的作品”，但是没有明确的法院裁决来解决这一特定的冲突。
根据Linux Journal的一篇文章， Lawrence Rosen （一次性开源计划总顾问）认为，连结的方法与一个软件是否是衍生作品的问题大不相干；更重要的是关于软件是否旨在与客户端软件和/或库连接的问题。他指出：“新程序是否是衍生工作的主要指示是原始程序的原始码是否以[复制贴上方式]使用，以任何方式进行修改，翻译或以其他方式更改新程序，如果没有，那么我会认为这不是衍生工作“，并列出了关于意图，捆绑和联动机制的许多其他观点。 他进一步在他公司的网站上论证，这种“以市场为基础”的因素比连结技术更重要。
还有一个具体问题是，一个插件或模组（如NVidia或ATI 显示卡核心模组）是否也必须是GPL，如果它可以合理地被认为是自己的工作。这个观点表明，如果工作是GPLv2，则可以根据任意授权条款，为设计使用插件的软件提供合理的单独插件或插件。特别感兴趣的是GPLv2段落：
| “ | 您可以修改本程序或其任何部分的副本或副本，从而根据本程序形成工作，并根据上述第1节的条款复制和分发此类修改或工作，前提是您也符合所有这些条件：……
b）您必须将您分发或发布的任何作品全部或部分包含或衍生自本计划或其任何部分，根据本授权条款的条款无偿授予所有第三方。 ...这些要求适用于整体修改后的工作。 如果该作品的可识别部分不是源自该程序，并且可以被合理地视为独立和独立的作品，则本授权条款及其条款在将其作为单独作品分发时不适用于这些部分。 但是，当您分发相同的部分作为基于程序的工作的整体的一部分时，整体的分布必须符合本授权条款的条款，其授权条款持有人的权限将扩展到整个，和每个部分，无论谁写的。 |
” |
GPLv3有一个不同的条款：
| “ | 您可以根据第4节的条款，以原始码的形式传达基于本程序的工作，或从程序生成的工作，只要您也符合以下所有条件：……
c）您必需根据本许可将整个作品整体授权给任何拥有副本的人。 因此，本授权条款连同任何适用的第7条附加条款适用于整个工作及其所有部分，无论其包装方式如何。 本授权条款不允许以任何其他方式许可该作品，但如果您已单独收到，则不会使该许可无效。……与其他单独和独立的作品的汇编，而不是其涵盖的作品的性质延伸，而不是与其组合，以形成更大的程序，在一个或多个如果汇编及其产生的版权不被用于限制编辑用户的存取权限或合法权限超出个人作品允许的范围，则称为“汇总”。 合并中的被覆盖的工作不会导致本授权条款适用于合并的其他部分。 |
” |
作为一个案例研究，一些据称为GPLv2 CMS软件（如Drupal和WordPress）的专有插件和主题/外观已经受到打击，双方均被采纳[63][64]
与其他程序通讯的行为本身并不要求所有软件都是GPL；也不用GPL软件分发GPL软件。但是，必须遵循较小的条件，确保GPL软件的权利不受限制。 以下是gnu.org的 GPL FAQ，该常见问题解答介绍了允许软件与GPL程序进行通讯和绑妥的程度：
| “ | Q：“合辑”（Aggregate）与其他类型的“修改版本”有什么区别？
A：“合辑”由多个单独的程序组成，分布在同一个CD-ROM或其他媒体上。 GPL允许您创建和分发合辑，即使其他软件的授权条款是非自由的或GPL不兼容的。 唯一的条件是，您不能根据禁止用户行使每个计划的个人授权条款授予他们的权利的授权条款发布合并。 Q：两个单独的程序之间的区别在哪里，一个程序有两个部分？ A：这是一个法律问题，最终法官会决定。 我们认为适当的标准取决于通信机制（exec，pipes，rpc，共享地址空间中的函数呼叫等）和通信的语义（哪些信息被互换）。如果模组包含在相同的执行档中，则它们在一个程序中被明确地组合。 如果模组设计为在共享地址空间中连接在一起运行，那么几乎肯定意味著将它们组合成一个程序。相比之下，管道（pipe）、接口（socket）和命令行参数是通常在两个独立程序之间使用的通讯机制。 所以当它们用于通信时，模组通常是单独的程序。 但是，如果通信的语义足够亲密，交换复杂的内部数据结构，那么也可以将这两个部分合并成一个更大的程序。 |
” |
因此，FSF想在“函式库”和“其他程序”之间透过以下两种方式划清界线： 1）信息交换的“复杂性（complexity）”和“亲密程度（intamacy）”；2）信息交换的“机构（mechanics）“，而不是“语义（semantic）”。但让问题不明确，而又复杂的情况下，交由判例法来决定。
GPL文本是版权所有的，且著作权人是自由软件基金会。但是，自由软件基金会没有在GPL下发行作品的著作权（除非作者指定自由软件基金会是著作权人）。通常认为，只有著作权人才有权对授权条款的违反进行起诉，但是那并不准确。法国的一个教育组织AFPA于2000年从Edu4购买课堂使用的电脑装置发现其使用GPL软件但并未附带原始码。 [66][67]
自由软件基金会允许人们使用以GPL为基础的其他授权条款，但不允许演绎的授权条款未经授权地使用GPL的前言。不过像这样的授权条款通常与GPL不兼容。[68]
GNU计划创立的其他授权条款包括：GNU宽通用公共许可证和GNU自由文件授权条款。
一个关于GPL重要的争议是，非GPL软件是否可以动态连结到GPL库。 GPL对GPL作品的演绎作品在GPL下发布规定很明确。但是对于动态连结到GPL库的作品是否是演绎作品就规定得不清楚了。自由和开放原始码社群为此分成两派，自由软件基金会认为这种作品就是演绎作品，但其他专家并不同意。这个问题根本的并不关乎GPL本身，而是一个版权法如何定义演绎作品。美国联邦上诉法院第九巡回审判庭在Galoob v. Nintendo案对演绎作品尝试定义，但最终没有明确的结果。
不幸的是，许多开发人员觉得这是个技术问题。但实际上这完全是法律问题。不过由于迄今为止没有案例表明有人以动态连结的方式来绕过GPL的条款并因此被起诉，动态连结的限制已经是事实上地（de facto）有效，不论它是否是法律上地（de jure）有效。
2002年，MySQL AB公司起诉Progress NuSphere侵犯版权和商标。 NuSphere被指以连结代码的形式侵犯了著作权。最终此案以调解结束。在听证期间，法官“认为没有什么原因”（不管是否是动态连结）会使得GPL失去法律效力。
2003年8月，SCO Group称他们认为GPL没有法律效力，且准备就在Linux核心中使用的SCO Unix代码进行诉讼。参见SCO诉IBM。
2004年4月，在SiteCom拒绝停止发行Netfilter专案的GPL软件后，慕尼黑地区法庭据对GPL条款的侵犯判定对SiteCom进行临时性禁令（诉前停止侵犯专利权行为的措施）。同年7月，法庭确认此勒令为对SiteCom最终判决。此判决明显的印证了自由软件基金会的法律顾问伊本·莫格林的预言：
此判决十分重要，因为它是全球首次法庭确认GPL是有法律效力的。
2005年5月，Daniel Wallace于美国联邦印第安纳南区地方法院起诉自由软件基金会，因为二者对GPL是否非法意见不一。后诉讼于3月结束，因为Wallace没有有效的反托拉斯陈述。法庭注意到“GPL鼓励，而不是反对电脑操作系统的自由竞争和发行，这直接使消费者受益。”[69]Wallace被拒绝改变诉由，并被要求支付诉讼费用。
大多数自由软件授权条款，比如MIT/X授权条款、BSD授权条款、LGPL，都是“ GPL兼容的”，即它们的代码与GPL代码混用无冲突（但新代码则是GPL下的）。但是有某些开源软件授权条款不是GPL兼容的。通常意见是开发人员仅只使用GPL兼容的授权条款，以免法律问题。
参见软体授权条款列表以查证兼容性。
2001年微软的首席执行官史蒂夫·巴尔默称Linux为“癌症”，因为GPL的影响。微软批评者指出，微软憎恶GPL的真正原因是因为GPL对微软的“包围、扩展、消灭”策略起了反作用。注意微软已以GPL为授权条款发行了SFU（Microsoft Windows Services for UNIX）中所包含的部分组件，例如GCC。
GPL的批评者常常认为GPL是有“传染性”的“病毒”，因为GPL条款规定演绎作品也必须是GPL的。由于“演绎作品”通常被解释为包含GPL代码或动态连结到GPL库（如上）的软件，“病毒说”来源于GPL对于授权条款的强制继承的要求。这正是GPL与BSD式授权条款的哲学思想上的差异。 GPL的支持者确信自由软件世界应具有自我保护能力和可持续发展性——确保自由软件的演绎作品同样“自由”，但其他人认为自由软件应给予“所有人”最大的自由。
不同版本之间的GPL并不相容。例如，当原始的作品以GPLv2发布，而补丁以GPLv3发布时，因为这样的原因，其编译之后产生的二进位版本不可以再行传播。因此，FSF通常会推荐以“GPLv2 or later”这样的形式来标示授权授权条款，或GPLv2 + GPLv3双授权条款以规避这一问题。
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
