GNU通用公共许可证

历史

GPL由理察·斯托曼于1989年编写，提供给列入GNU项目的一些软件程序所使用。 原始的GPL基于GNU Emacs （1985）， GNU Debugger和GNU C编译器的早期版本中使用的类似许可证的统一。 这些许可证包含与现代GPL类似的规定，但具体针对每个程序，使其不兼容，尽管是相同的许可证。 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许可许可软件的原意。 这些问题包括Tivo化 （来自硬件的软件限制，意指将GPL许可软件安装在硬件上，又拒绝运行更动相关软件的修改版本），类似与Affero通用公共许可协议类似的兼容性问题，以及微软和自由开源软件，其中一些被认为试图将专利申请用作于对付自由软件社群的武器。
第3版旨在解决这些问题，并于2007年6月29日正式发布。

用语

根据知识共享官方网站，GNU General Public License 的台湾法律用语翻法为“GNU通用公共授權條款”，香港法律用语翻法亦为如此。

GPLv1

1989年2月25日发布的GNU GPL 版本1 阻止了软件经销商限制自由软件定义的两个主要方式。第一个问题是经销商可能仅发布二进制文件- 可执行，但不能由人类读取或修改。为了防止这种情况，GPLv1表示，任何分发二进制代码的供应商还必须按照相同的许可条款（许可证的第3a和3b节）提供可读的源代码。
第二个问题是经销商可能会增加许可证的限制，也可能会将软件与其他具有其他分发限制的软件相结合。两套限制的联合将适用于组合工作，从而增加不可接受的限制。 为了防止这种情况，GPLv1表示，修改后的版本作为一个整体，必须按照GPLv1（许可证第2b和4节）的条款分发。 因此，根据GPLv1条款分发的软件可以以更宽松的条款​​与软件相结合，因为这不会改变整体可以分发的条款。 然而，根据GPLv1分发的软件不能与在更严格的许可证下分发的软件相结合，因为这与根据GPLv1的条款可以分发的要求相冲突。

GPLv2

根据理查德·斯托曼的说法，GPLv2的主要变化是“自由或死亡”（Liberty or Death）条款。就如字面上所说，“被许可人只有在满足所有许可证的义务下”才可以分发包含GPL许可的软件，尽管他们可能拥有任何其他法律义务。换句话说，就算有相互矛盾的义务，许可证的义务也可能不被切断。 该条款旨在阻止任何一方使用专利侵权索赔或其他诉讼来损害用户在许可证下的自由。这章中的意思是，为了在一定程度上保障和尊重其它一些人的自由和权益，无论任何人要发布源于GPL的软件的时候，同时也须遵守强制的条款分享源代码，否则他将根本无权发布该软件。（因为在一些国家里，人们只能以二进制代码的形式发布软件，以保护开发软件者的著作权。）
到1990年，越来越明显的是，对于C库来说，本质上已经跟受专利保护的软件库的功能表现相当，有一个限制较少许可证对于自由软件发展的策略上来说更为实用；因此，当GPL的版本2（GPLv2）在1991年6月发布时，第二类别的许可证：库通用公共许可证（英语：Library General Public License），也同时被引入，并从第二版编号开始，表明两者是互补的。版本号在1999年发行，当时LGPL的版本2.1被发布，更名为GNU通用公共许可证，以反映其在哲学中的地位。
最常见的是“GPLv2并延伸到未来版本”的声明，让许可证的用户了解，得以允许升级到GPLv3。

条款和条件

GPL的条款和条件必须提供给任何接受GPL应用的作品的副本（“被许可人”）的人员。任何遵守条款和条件的被授证人员都有权修改作品，以及复制和重新分发作品或任何派生版本。被许可人被允许为此服务收取费用，或无偿。后一点将GPL与禁止商业再分发的软件许可区分开来。FSF认为，自由软件不应该限制商业用途，GPL明确规定GPL作品可能以任何价格出售。
GPL还规定，经销商不得对GPL授予的权利施加“进一步限制”。禁止根据不披露协议或合同分发软件等活动。
许可证版本2的第四部分和版本3的第七部分要求，作为预编译二进制文件分发的程序应附有源代码的副本，通过与前一版本相同的机制分发源代码的书面报价编译的二进制文件或书面报价，以获取用户在GPL下接收预编译二进制文件时获得的源代码。版本2的第二部分和版本3的第五部分还要求“所有收件人本程序附带的许可证副本”。 许可证的版本3允许以其他方式提供源代码来实现第七部分。这些包括从相邻网络服务器下载源代码或通过点对点传输，只要编译代码是可用的，并且在哪里可以找到源代码的“清晰方向”。
除非作者明确赋予FSF 著作权（除了作为GNU项目一部分的程序很少发生），否则FSF对GPL发布的作品不具有著作权。只有个人著作权持有人有权在发生许可证时才起诉。

使用许可软件

GPL下的软件可以用于所有目的，包括商业目的，甚至作为创建专有软件的工具，例如使用GPL许可的编译器时。分发GPL许可作品（如软件）的用户或公司可能会收取副本费用或无偿提供费用。 这将GPL与共享软件许可证区分开来，允许复制用于个人使用，但禁止商业发布，或著作权法禁止复制的专有许可。 FSF认为自由软件不应该限制商业使用和发布（包括再发布）。GPL明确规定，GPL工作可能以任何价格出售。
在纯私人（或内部）使用 - 没有销售和没有发行- 软件代码可能被修改和零件重复使用，而不需要发布源代码。 对于销售或分销，整个源代码需要提供给最终用户，包括任何代码更改和添加- 在这种情况下，应用copyleft来确保最终用户保留上面定义的自由。
然而，作为GPL许可操作系统（如Linux）下的应用程序运行的软件不需要根据GPL进行许可或者以源代码可用性分发- 许可只依赖于使用的库和软件组件，而不是依赖于底层平台。例如，如果一个程序仅由自己的原始定制软件组成（software component），或者与其他软件组件的源代码组合在一起，则自己的定制软件组件不需要根据GPL许可，不需要使其代码可用; 即使所使用的底层操作系统是根据GPL许可的，运行在其上的应用程序也不被视为派生作品。  只有在程序中使用了GPLed部件（程序已经分发）的情况下，程序的所有其他源代码才能在相同的许可条款下提供。GNU较宽松公共许可协议（LGPL）被创建为具有比GPL更弱的Copyleft，因为它不需要在相同的许可条款下提供自己定制的源代码（不同于LGPLed部分）。

Copyleft

GPL许可版本的修改后作品的发行权不是无条件的。 当有人分发GPL的作品又加上自己的修改时，分发整个作品的要求不能大于GPL中的要求。这个要求被称为Copyleft。 它通过软件程序使用著作权获得法律权力。 由于GPL的作品受著作权保护，被许可人无权重新分发，即使是以修改形式（除合理使用）外，除了许可条款外， 如果希望行使通常受著作权法限制的权利，例如重新分配，只需遵守GPL的条款。 相反，如果在不遵守GPL条款（例如保留源代码秘密）的情况下分发作品的副本，则原始作者可以根据著作权法提起诉讼。因此，“Copyleft使用著作权法来完成”与常见法律的设置目的相反，不是施加限制，而是“赋予其他人权利，以确保权利不能随之被剥夺的方式。”如果在Copyleft声明中找到任何法律缺陷，它也可以确保不给予无限的重新分发权限。
许多GPL程序的经销商将源代码与可执行文件捆绑在一起。 满足Copyleft的替代方法是提供书面报价，以便在物理介质（如CD）上提供源代码。 实际上，许多GPL的程序通过Internet进行分发，源代码通过FTP 或 HTTP提供。对于互联网分发，这匹配许可证。只有当一个人试图重新分发程序时，Copyleft才适用。 只要不将修改后的软件分发给任何人，开发人员可以制作私有修改版本，无需泄露修改。 请注意，Copyleft仅适用于软件，而不适用于其输出（除非该输出本身是程序的派生作品）。
例如，运行GPL内容管理系统（CMS）修改版的派生产品之公共门户网站不需将其更动分发给底层软件，因为其输出不是派生产品。
有人辩论，如果以代码混淆形式发布源代码是否违反GPL，例如在作者不太愿意提供源代码的情况下。普遍认为虽然这是不道德的，但无法认为是违法行为。 这问题已得到澄清：当许可证被更改为v2时，就需要提供源代码的“首选”版本。

许可证与合同的区别

GPL被设计为许可证 ，而不是合同。在一些普通法（Common Law）司法管辖区，许可证和合同之间的法律区别是重要的：合同可以通过合同法运行，而许可证是根据著作权法运行的。 然而，这种区别对于合同和执照之间没有区别的许多司法管辖区（如民法系统）并不有用。
GPL原理很简单：在著作权法下，你不遵守GPL的条款和条件你就没有相对应的权利。而作品在没有GPL的情况下，著作权法作为默认条款发生效力，而不是作品进入公有领域。 那些不接受GPL条款和条件的人根据著作权法没有许可复制或分发GPL许可软件或派生作品。 然而，如果他们不重新分发GPL的程序，他们仍然可以按自己的喜好使用组织内的软件，使用该程序构建的工程（包括程序）不需要被该许可证覆盖。
艾里逊·兰德尔认为，GPLv3作为许可证对于读者来说是不必要的混乱，可以在保留相同的条件和法律效力的情况下进行简化。

派生或扩展性

GPL的文案本身，受著作权保护，著作权由自由软件基金会持有。GPL的文案本身，却不在GPL之下。 经许可的著作权不允许修改许可证。 允许复制和分发许可证，因为GPL要求收件人获得“本许可证与本计划一起”的副本。 [62]根据GPL常见问题，任何人都可以使用GPL的修改版本，只要他或她使用不同的名称作为许可证，不提“GNU”，并删除前言，尽管如果使用自由软件基金会（FSF）获得许可，则序言可以在修改后的许可证中使用。
FSF允许人们根据GPL创建新的许可证，只要派生的许可证未经许可不使用GPL前缀。 然而，这是不鼓励的，因为这样的许可证可能与GPL不兼容，并导致感染的许可证扩散（license proliferation）。
由GNU项目创建的其他许可证包括GNU通用公共许可证，GNU自由文件许可证和Affero通用公共许可证。

争议：非GPL软件是否可以合法地链接或动态地链接到GPL库

据FSF称，“GPL不要求您发布修改版本，或其任何部分，您可以自由地进行修改和留作私人使用，而无需发布。”然而若是向公众发布GPL许可的实体，则有链接的问题：换言之，“使用GPL库的专利程序是否违反了GPL ？”
这个关键的争议的重点是“非GPL软件是否可以合法地链接或动态地链接到GPL库”。这个问题有不同的看法。GPL清楚地表明，GPL下的所有派生作品代码都必须属于GPL。关于使用GPL库和将GPL软件捆绑到更大的包中（可能通过静态链接混合成二进制文件），会出现歧义。这最终不是GPL 本身的问题，而是著作权法如何界定派生作品。有以下观点存在：

观点：动态和静态链接违反GPL

自由软件基金会（其拥有若干著名的GPL软件产品和许可文字本身的著作权）声称，使用动态链接库的可执行档确实是派生作品。然而，这不适用于彼此通信的单独程序。自由软件基金会还创建了LGPL，LGPL与GPL极为相似，但额外允许以“使用库”为目的的链接。理查德·斯托曼和自由软件基金会特别鼓励库作者根据GPL来进行许可，以便专有程序无法使用GPL库，透过为自由软件世界提供比专有世界更多的工具来保护自由软件世界。

观点：静态链接违反GPL，但动态链接则有待厘清

有些人认为，当静态链接产生派生作品时，不清楚动态链接到GPL代码的可执行档是否应被视为派生作品（请参阅Weak Copyleft）。Linux作者Linus Torvalds同意动态链接可以创建派生作品，但在这种情况下不一致。一位Novell律师写道，动态链接不算是派生作品的观点合理但是不够明确，专有的Linux内核驱动程序就是善意的动态链接的一大明证。在Galoob对任天堂案中，美国第九巡回上诉法院将派生作品定义为具有“形式”或“永久性”，并指出“侵权作品必须以某种形式包含一部分受著作权保护的作品”，但是没有明确的法院裁决来解决这一特定的冲突。

著作权所有人

GPL文本是著作权所有的，且著作权人是自由软件基金会。但是，自由软件基金会没有在GPL下发行作品的著作权（除非作者指定自由软件基金会是著作权人）。通常认为，只有著作权人才有权对许可证的违反进行起诉，但是那并不准确。法国的一个教育组织AFPA于2000年从Edu4购买课堂使用的计算机设备发现其使用GPL软件但并未附带源代码。 
自由软件基金会允许人们使用以GPL为基础的其他许可证，但不允许演绎的许可证未经许可地使用GPL的前言。不过像这样的许可证通常与GPL不兼容。
GNU计划创立的其他许可证包括：GNU宽通用公共许可证和GNU自由文档许可证。

兼容性

大多数自由软件许可证，比如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双许可证以规避这一问题。