GNU通用公共许可证

Disambig gray.svg  「GPL」重新导向至此。关于一场电子竞技联赛，请见「GPL超级联赛」。
GNU通用公众授权条款
GPLv3 Logo.svg
GNU GPLv3 Logo
作者 自由软体基金会
版本 第3版
释出者 自由软体基金会
释出日期 1989年2月25日，​33年前
DFSG相容 是[1]
自由软体 是[2]
OSI认证 是[3]
Copyleft 是[2][4]
与其他协定代码连结 仅可与GNU AGPLv3代码相链结[5]
网站 www.gnu.org/licenses/gpl.html 编辑维基数据链结

GNU通用公众授权条款（英语：GNU General Public License，缩写GNU GPL 或 GPL），是被广泛使用的自由软体授权条款，给予了终端使用者运行、学习、共享和修改软体的自由。授权条款最初由自由软体基金会的理察·斯托曼为GNU项目所撰写，并授予计算机程式的使用者自由软体定义（The Free Software Definition）的权利。GPL是一个Copyleft授权条款，这意味着只要项目的某个部分（如动态连结库）以GPL发布，则整个专案以及衍生作品只能以相同的许可条款分发。这与宽松自由软体授权条款有所区别 ，如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」：

  • 基于任何目的，按你的意愿执行软体的自由（自由之零）。
  • 学习软体如何工作的自由，按你的意愿修改软体以符合你的计算的自由（自由之一）。可存取原始码是此项自由的先决条件。
  • 分发软体副本的自由，因此你可以帮助你的好友（自由之二）。
  • 将你修改过的软体版本再分发给其他人的自由（自由之三）。这样可以让整个社群有机会共享你对软体的改动。可存取原始码是此项自由的先决条件。[17]

相反地，随著作权所有软体的终端使用者授权条款几乎从不授予使用者任何权利（除了使用的权利），甚至可能限制一些法律允许的行为，比如还原工程。

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]。

GPLv1

1989年2月25日发布的GNU GPL 版本1阻止了软体经销商限制自由软体定义的两个主要方式。第一个问题是经销商可能仅发布二进制档案 - 可执行，但不能由人类读取或修改。为了防止这种情况，GPLv1表示，任何分发二进制代码的供应商还必须按照相同的许可条款（授权条款的第3a和3b节）提供可读的原始码。

第二个问题是经销商可能会增加授权条款的限制，也可能会将软体与其他具有其他分发限制的软体相结合。两套限制的联合将适用于组合工作，从而增加不可接受的限制。为了防止这种情况，GPLv1表示，修改后的版本作为一个整体，必须按照GPLv1（授权条款第2b和4节）的条款分发。因此，根据GPLv1条款分发的软体可以以更宽松的条款与软体相结合，因为这不会改变整体可以分发的条款。然而，根据GPLv1分发的软体不能与在更严格的授权条款下分发的软体相结合，因为这与根据GPLv1的条款可以分发的要求相冲突。

GPLv2

根据理察·斯托曼的说法，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。

GPLv3

GPLv3 logo
理察·斯托曼起草了第一份GNU 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段中说：

这旨在使未来像这样的交易无效。该授权条款还意味着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]。

授权条款文字的最终版本于2007年6月29日由自由软体基金会正式发布[28]。

条款和条件

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部分）。

Copyleft

主条目：Copyleft

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通用公众授权条款。

链结和衍生作品

争议：非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对任天堂案中，美国第九巡回上诉法院将衍生作品定义为具有「形式」或「永久性」，并指出「侵权作品必须以某种形式包含一部分受著作权保护的作品」，但是没有明确的法院裁决来解决这一特定的冲突。

观点：链结无关

根据Linux Journal的一篇文章， Lawrence Rosen （一次性开源计划总顾问）认为，链结的方法与一个软体是否是衍生作品的问题大不相干; 更重要的是关于软体是否旨在与客户端软体和/或库连接的问题。他指出：「新程式是否是衍生工作的主要指示是原始程式的原始码是否以[复制粘贴方式]使用，以任何方式进行修改，翻译或以其他方式更改新程式，如果没有，那么我会认为这不是衍生工作「，并列出了关于意图，捆绑和联动机制的许多其他观点。 他进一步在他公司的网站上论证，这种「以市场为基础」的因素比链结技术更重要。

还有一个具体问题是，一个外挂程式或模组（如NVidia或ATI 显示卡核心模组）是否也必须是GPL，如果它可以合理地被认为是自己的工作。这个观点表明，如果工作是GPLv2，则可以根据任意授权条款，为设计使用外挂程式的软体提供合理的单独外挂程式或外挂程式。特别感兴趣的是GPLv2段落：

GPLv3有一个不同的条款：

作为一个案例研究，一些据称为GPLv2 CMS软体（如Drupal和WordPress）的专有外挂程式和主题/外观已经受到打击，双方均被采纳[63][64]

FSF区分外挂程式如何被调用。如果通过动态链结调用外挂程式，并且它对GPL程式执行函式调用，那么它很有可能是衍生工作。[65]

与非GPL程式的通讯和绑妥

与其他程式通讯的行为本身并不要求所有软体都是GPL; 也不用GPL软体分发GPL软体。但是，必须遵循较小的条件，确保GPL软体的权利不受限制。 以下是gnu.org的 GPL FAQ，该常见问题解答介绍了允许软体与GPL程式进行通讯和绑妥的程度：

因此，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最终判决。此判决明显的印证了自由软体基金会的法律顾问伊本·莫格林的预言：

「被告侵犯了原告的著作权：提供了软体netfilter/iptables的广告及下载，但没有遵守GPL的条款。可以说，如果被告有授权条款许可，这些行为是完全合法的……原被告就GPL是否达成协定这是一个独立的问题。如果当事人没有同意，被告将没有复制、发行、公开'netfilter/iptables'的权利。」

此判决十分重要，因为它是全球首次法庭确认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双授权条款以规避这一问题。

注释

  1. ^ 在一些国家里，人们只能以二进制代码的形式发布软体，以保护开发软体者的著作权。
  2. ^ example: if only GNU Lesser General Public License- (LGPL-) libraries, LGPL-software-components and components with permissive free software licenses are used (thus not GPL itself), then only the source code of LGPL parts has to be made available—for the developer's own self-developed software components this is not required (even when the underlying operating system used is licensed under GPL, as is the case with Linux).
  3. ^ 一个反例是 GPL'ed GNU Bison: the parsers it outputs do contain parts of itself and are therefore derivatives, which would fall under the GPL if not for a special exception granted by GNU Bison: Conditions for Using Bison. [2008-12-11]. （原始内容存档于2020-08-22）. </ref>

参见

参考文献

  1. ^ Debian – License information. Software in the Public Interest, Inc. [2009-12-10]. （原始内容存档于2016-04-22）. 
  2. ^ 2.0 2.1 Licenses – Free Software Foundation. Free Software Foundation. [2009-12-10]. （原始内容存档于2008-12-16）. 
  3. ^ Licenses by Name. Open Source Initiative. [2009-12-10]. （原始内容存档于2016-06-06）. 
  4. ^ Copyleft: Pragmatic Idealism – Free Software Foundation. Free Software Foundation. [2009-12-10]. （原始内容存档于2009-07-01）. 
  5. ^ If a library is released under the GPL (not the LGPL). Free Software Foundation. [2017-05-03]. （原始内容存档于2016-12-29）. 
  6. ^ 6.0 6.1 Top 20 licenses. Black Duck Software. 2015-11-19 [2015-11-19]. （原始内容存档于2016-07-19）. 1. MIT license 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-clause, New or Revised) License 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public License 2%, 10. Eclipse Public License (EPL) 2% 
  7. ^ GPL FAQ: Does using the GPL for a program make it GNU Software? （页面存档备份，存于网际网路档案馆）
  8. ^ 开源的许可证GPL、LGPL、BSD、Apache 2.0的通俗解释. [2021-08-30]. （原始内容存档于2021-08-30）. 
  9. ^ Make Your Open Source Software GPL-Compatible. Or Else.. [2017-05-03]. （原始内容存档于2021-01-26）. 
  10. ^ Estimating Linux's Size. www.dwheeler.com. [2017-05-03]. （原始内容存档于2021-01-25）. 
  11. ^ 11.0 11.1 11.2 GPLv3 hits 50 percent adoption. [2017-05-03]. （原始内容存档于2020-08-22）. 
  12. ^ 存档副本. [2017-05-03]. （原始内容存档于2020-10-08）. License proliferation: a naive quantitative analysis] on lwn.net "Walter van Holst is a legal consultant at the Dutch IT consulting company mitopics. ... Walter instead chose to use data from a software index, namely Freecode ... Walter's 2009 data set consisted of 38,674 projects ... The final column in the table shows the number of projects licensed under "any version of the GPL". In addition, Walter presented pie charts that showed the proportion of projects under various common licenses. Notable in those data sets was that, whereas in 2009 the proportion of projects licensed GPLv2-only and GPLv3 was respectively 3% and 2%, by 2013, those numbers had risen to 7% and 5%." 
  13. ^ Top 20 licenses. Black Duck Software. 2013-08-23 [2013-08-23]. （原始内容存档于2016-07-19）. 1. GNU General Public License (GPL) 2.0 33%, 2. Apache License 13%, 3. GNU General Public License (GPL) 3.0 12% 
  14. ^ Why the GPL rocketed Linux to success. [2017-05-03]. （原始内容存档于2013-06-25）. So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. 
  15. ^ 15.0 15.1 Torvalds, Linus. COPYING. kernel.org. [2013-08-13]. （原始内容存档于2015-12-17）. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. 
  16. ^ Linus Torvalds. Linux-2.4.0-test8. lkml.iu.edu. 2000-09-08 [2015-11-21]. （原始内容存档于2020-05-15）. The only one of any note that I'd like to point out directly is the clarification in the COPYING file, making it clear that it's only _that_particular version of the GPL that is valid for the kernel. This should not come as any surprise, as that's the same license that has been there since 0.12 or so, but I thought I'd make that explicit 
  17. ^ 《自由软件，自由社会》：什幺是自由软件？. [2018-05-20]. （原始内容存档于2020-08-22）. 
  18. ^ Ball, Patrick. Holbrook, J. , 编. Free Software. Ethics, Science, Technology, and Engineering: A Global Resource (Farmington Hills, MI: Macmillan Reference USA). 2015, 2 (2): 291–295 [2016-11-26]. （原始内容存档于2019-10-16）. Thus free software may be used and shared by anyone who accepts the terms of the license. The most common free software license is the general public license (GPL). A GPL offers the following: 
  19. ^ GNU Emacs Copying Permission Notice (1985). [2015-11-08]. （原始内容存档于2020-08-22）. 
  20. ^ The History of the GPL. [2011-11-24]. （原始内容存档于2020-11-11）. 
  21. ^ 21.0 21.1 Stallman, Richard. Presentation at the second international GPLv3 conference, held in Porto Alegre. 2006-04-21 [2017-05-03]. （原始内容存档于2009-03-31）. 
  22. ^ Why Upgrade to GPL Version 3 --GPLv3. Fsf.org. [2011-03-17]. （原始内容存档于2021-01-03）. 
  23. ^ GNU 工程的哲学. [2019-04-16]. （原始内容存档于2021-01-12）. 
  24. ^ FSF releases the GNU General Public License, version 3 – Free Software Foundation – working together for free software. Fsf.org. [2011-01-15]. （原始内容存档于2013-06-25）. 
  25. ^ Creative Commons—GNU General Public License. [2010-07-20]. （原始内容存档于2010-09-25）. 
  26. ^ GNU通用公共授权条款. [2010-07-20]. （原始内容存档于2010-09-10）. 
  27. ^ 27.0 27.1 Stallman, Richard. Presentation in Brussels, Belgium—the first day of that year's FOSDEM conference.. 2006-02-25 [2006-04-27]. （原始内容存档于2017-08-25）. 
  28. ^ 28.0 28.1 GPL第三版 GNU General Public License. [2012-06-15]. （原始内容存档于2017-07-29）. 
  29. ^ Interview with Richard Stallman （页面存档备份，存于网际网路档案馆）, Free Software Magazine, 23 January 2008.
  30. ^ A Quick Guide to GPLv3 – GNU Project – Free Software Foundation (FSF). Free Software Foundation. [2017-05-03]. （原始内容存档于2016-12-29）. 
  31. ^ GPLv3: Drafting version 3 of the GNU General Public License. Free Software Foundation Europe. [2017-05-03]. （原始内容存档于2009-04-13）. 
  32. ^ gplv3.fsf.org comments for discussion draft 4. [2012-11-23]. （原始内容存档于2008-10-02）. 
  33. ^ gplv3.fsf.org comments for draft 1. [2012-11-23]. （原始内容存档于2008-06-26）. Showing comments in file 'gplv3-draft-1' ... found 962 
  34. ^ gplv3.fsf.org comments for draft 2. [2012-11-23]. （原始内容存档于2008-07-24）. Showing comments in file 'gplv3-draft-1' ... found 727 
  35. ^ gplv3.fsf.org comments for draft 3. [2012-11-23]. （原始内容存档于2008-07-03）. Showing comments in file 'gplv3-draft-3' ... found 649 
  36. ^ gplv3.fsf.org comments for draft 4. [2012-11-23]. （原始内容存档于2008-10-02）. Showing comments in file 'gplv3-draft-4' ... found 298 
  37. ^ Guide to the third draft of GPLv3. [2017-05-03]. （原始内容存档于2017-06-05）. 
  38. ^ Final Discussion Draft. [2007-06-04]. （原始内容存档于2018-03-05）. 
  39. ^ GPL version 3 FAQ. [2007-06-04]. （原始内容存档于2017-09-17）. 
  40. ^ Fourth Discussion Draft Rationale (PDF). [2007-06-04]. （原始内容 (PDF)存档于2017-03-01）. 
  41. ^ Tiemann, Michael. GNU Affero GPL version 3 and the "ASP loophole". OSI. 2007-06-07 [2013-08-19]. （原始内容存档于2020-08-14）. 
  42. ^ List of free-software licences on the FSF website （页面存档备份，存于网际网路档案馆）: 「We recommend that developers consider using the GNU AGPL for any software which will commonly be run over a network」.
  43. ^ Why did you decide to write the GNU Affero GPLv3 as a separate license? （页面存档备份，存于网际网路档案馆） on gnu.org
  44. ^ 44.0 44.1 James E.J. Bottomley; Mauro Carvalho Chehab; Thomas Gleixner; Christoph Hellwig; Dave Jones; Greg Kroah-Hartman; Tony Luck; Andrew Morton; Trond Myklebust; David Woodhouse. Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3. LWN.net. 2006-09-15 [2015-03-11]. （原始内容存档于2021-01-18）. The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve. However, a deeper reading reveals several other problems with the current FSF draft: 5.1 DRM Clauses ... 5.2 Additional Restrictions Clause ... 5.3 Patents Provisions ... since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely. 
  45. ^ Petreley, Nicholas. A fight against evil or a fight for attention?. linuxjournal.com. 2006-09-27 [2015-03-11]. （原始内容存档于2018-03-02）. Second, the war between Linus Torvalds and other Kernel developers and the Free Software Foundation over GPLv3 is continuing, with Torvalds saying he's fed up with the FSF. 
  46. ^ Linus Torvalds says GPL v3 violates everything that GPLv2 stood for （页面存档备份，存于网际网路档案馆） Debconf 2014, Portland, Oregon (accessed 11 March 2015)
  47. ^ Kerner, Sean Michael. Torvalds Still Keen On GPLv2. internetnews.com. 2008-01-08 [2015-02-12]. （原始内容存档于2015-02-12）. "In some ways, Linux was the project that really made the split clear between what the FSF is pushing which is very different from what open source and Linux has always been about, which is more of a technical superiority instead of a -- this religious belief in freedom," Torvalds told Zemlin. So, the GPL Version 3 reflects the FSF's goals and the GPL Version 2 pretty closely matches what I think a license should do and so right now, Version 2 is where the kernel is." 
  48. ^ GPL 3 Overview. Tech LawForum. 2007-06-29 [2013-09-02]. （原始内容存档于2016-01-09）. 
  49. ^ A Quick Guide to GPLv3 – GNU Project – Free Software Foundation (FSF). Free Software Foundation. [2017-05-03]. （原始内容存档于2016-12-29）. 
  50. ^ Landley, Rob. Embedded Linux Conference 2013 - Toybox: Writing a New Command Line. The Linux Foundation. [2016-06-24]. （原始内容 (video)存档于2020-08-16）. GPLv3 broke "the" GPL into incompatible forks that can't share code. ... FSF expected universal compliance, but hijacked lifeboat clause when boat wasn't sinking. ... 
  51. ^ Landley, Rob. CELF 2013 Toybox talk. landley.net. [2013-08-21]. （原始内容存档于2020-08-07）. GPLv3 broke "the" GPL into incompatible forks that can't share code. ... FSF expected universal compliance, but hijacked lifeboat clause when boat wasn't sinking. ... 
  52. ^ 存档副本. [2017-05-03]. （原始内容存档于2017-08-25）. 
  53. ^ 53.0 53.1 Selling Free Software. Free Software Foundation. [2017-05-03]. （原始内容存档于2018-02-07）. 
  54. ^ GPL FAQ: Use GPL Tools to develop non-free programs （页面存档备份，存于网际网路档案馆）
  55. ^ GPL FAQ: GPL require source posted to public （页面存档备份，存于网际网路档案馆）, Unreleased modifications （页面存档备份，存于网际网路档案馆）, Internal Distribution （页面存档备份，存于网际网路档案馆）
  56. ^ 56.0 56.1 GPL FAQ: Port program to GNU/Linux （页面存档备份，存于网际网路档案馆）
  57. ^ Reasoning behind the "preferred form" language in the GPL. LWN.net. 2011-03-07 [2017-05-03]. （原始内容存档于2013-12-02）. 
  58. ^ Essay by Stallman explaining why a license is more suitable than a contract. [2017-05-03]. （原始内容存档于2020-11-12）. 
  59. ^ Eben Moglen explaining why the GPL is a license and why it matters. [2017-05-03]. （原始内容存档于2008-11-20）. 
  60. ^ Guadamuz-Gonzalez, Andres. Viral contracts or unenforceable documents? Contractual validity of copyleft licenses. European Intellectual Property Review. 2004, 26 (8): 331–339. SSRN 569101 可免费查阅. 
  61. ^ Allison Randal. GPLv3, Clarity and Simplicity. 2007-05-14 [2017-05-03]. （原始内容存档于2008-10-15）. 
  62. ^ GPL FAQ: Can I modify the GPL and make a modified license?. [2017-05-03]. （原始内容存档于2010-02-03）. 
  63. ^ Why They’re Wrong: WordPress Plugins Shouldn’t Have to be GPL. Webmaster-source.com. 2009-01-29 [2011-01-15]. （原始内容存档于2020-09-15）. 
  64. ^ Licensing FAQ. Drupal.org. [2011-01-15]. （原始内容存档于2015-09-05）. 
  65. ^ Frequently Asked Questions about the GNU Licenses – GNU Project – Free Software Foundation (FSF). Gnu.org. [2011-01-15]. （原始内容存档于2016-12-29）. 
  66. ^ GNU GPL在法国胜诉. 2009-09-25 [2009-09-25]. （原始内容存档于2020-08-07） （中文（中国大陆））. 
  67. ^ paris-16.09 .2009.pdf 判决书（法文）. [永久失效连结]
  68. ^ gnu.org. www.fsf.org. [2006-04-27]. （原始内容存档于2008-09-08）. 
  69. ^ ENTRY GRANTING REASSERTED MOTION TO DISMISS (PDF). [2006-04-27]. （原始内容 (PDF)存档于2020-01-16）. 

外部连结



历史
GNU's not UNIX
授权条款
软体
公众发言人
其它议题
组织
核心
支援
技术
除错
启动过程
ABI
API
使用者空间
FS，守护行程
封装库
核心部分
系统呼叫介面
核心内
核心组件
变种
虚拟化
采用
使用范围
采用者
  • Linux采用者列表
  • GENIVI联盟
  • Linux专有软体
人物
  • 分类 分类
  • 共享资源页面 共享资源
  • 维基百科图书 教科书
  • 维基学院页面 学院
  • 主题 主题

#