维基百科

GNU通用公共许可证

一套自由軟件許可證
“GPL”重定向至此。关于一场电子竞技联赛，请见“GPL超级联赛”。

GNU通用公共许可协议（英语：GNU General Public License，缩写GNU GPL 或 GPL），是被广泛使用的自由软件许可协议，给予了终端用户运行、学习、共享和修改软件的自由。[6]许可协议最初由自由软件基金会的理查德·斯托曼为GNU项目所撰写，并授予电脑程序的用户自由软件定义（The Free Software Definition）的权利。[7]GPL是一个Copyleft许可协议，这意味着只要项目的某个部分（如动态链接库）以GPL发布，则整个项目以及派生作品只能以相同的许可条款分发[8]。这与宽松自由软件许可证有所区别 ，如BSD许可协议和MIT许可协议就是其中被广泛使用的例子。GPL是第一个普遍使用的Copyleft许可协议。

GNU通用公共许可证
GNU GPLv3 Logo
作者自由软件基金会
版本第3版
发布者自由软件基金会
发布日期1989年2月25日，​35年前​（1989-02-25）
DFSG兼容是[1]
自由软件是[2]
OSI认证是[3]
Copyleft是[2][4]
与不同许可证代码链接仅可与GNU AGPLv3代码相链接[5]
网站www.gnu.org/licenses/gpl.html 编辑维基数据链接

历史上，GPL许可协议系列一直是自由和开源软件领域最受欢迎的软件许可之一。[6][9][10][11][11][11][12][13]根据GPL许可的优异自由软件程序的例子有Linux核心和GNU编译器集合（GCC）。大卫·A·惠勒（英语：David A. Wheeler）认为，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（英语：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化（英语：Tivoization）[23]（来自硬件的软件限制，意指将GPL许可软件安装在硬件上，又拒绝运行更动相关软件的修改版本），类似与Affero通用公共许可协议类似的兼容性问题，以及微软和自由开源软件，其中一些被认为试图将专利申请用作于对付自由软件社群的武器。

第3版旨在解决这些问题，并于2007年6月29日正式发布。[24]

用语

编辑

根据知识共享官方网站，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许可的软件，尽管他们可能拥有任何其他法律义务。换句话说，就算有相互矛盾的义务，许可协议的义务也可能不被切断。该条款旨在阻止任何一方使用专利侵权（英语：Patent infringement）索赔或其他诉讼来损害用户在许可协议下的自由。这章中的意思是，为了在一定程度上保障和尊重其它一些人的自由和权益，无论任何人要发布源于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]

公共咨询过程由自由软件基金会在软件自由法律中心、欧洲自由软件基金会（英语：Free Software Foundation Europe）[31]和其他自由软件组织的协助下进行协调。透过FSF [1] （页面存档备份，存于互联网档案馆）网站从公众收集评论[32]。该门户网站运行名为 stet（英语：stet (software)）的专用软件。在公众咨询过程中，提交了第一稿的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（英语：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（英语：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的程序，他们仍然可以按自己的喜好使用组织内的软件，使用该程序构建的工程（包括程序）不需要被该许可协议覆盖。

艾里逊·兰德尔（英语：Allison Randal）认为，GPLv3作为许可协议对于读者来说是不必要的混乱，可以在保留相同的条件和法律效力的情况下进行简化。[61]

派生或扩展性

编辑

GPL的文案本身，受著作权保护 ，著作权由自由软件基金会持有。GPL的文案本身，却不在GPL之下。 经许可的著作权不允许修改许可协议。 允许复制和分发许可协议，因为GPL要求收件人获得“本许可协议与本计划一起”的副本。 [62]根据GPL常见问题，任何人都可以使用GPL的修改版本，只要他或她使用不同的名称作为许可协议，不提“GNU”，并删除前言，尽管如果使用自由软件基金会（FSF）获得许可，则序言可以在修改后的许可协议中使用。

FSF允许人们根据GPL创建新的许可协议，只要派生的许可协议未经许可不使用GPL前缀。 然而，这是不鼓励的，因为这样的许可协议可能与GPL不兼容[62]，并导致感染的许可协议扩散（英语：License proliferation）（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）. 

外部链接

编辑



）

检索自“https://zh.wikipedia.org/w/index.php?title=GNU通用公共许可证&oldid=85183633”