开源许可协议与知识共享许可协议

互联网中充满了具有创造性和实用价值的资源，比如照片、文章、音乐、视频和代码。相对于自己创造轮子，寻找现有的资源和已存在的实现方法则更快捷，廉价和实用。无论是否免费，这些资源通常以某种许可协议发布以确保公正的使用。

版权知识

版权和许可协议

当我们创造一些东西时 – 比如说图像 – 我们拥有它的版权，这是我们作为此作品的作者而独享的权利。我们同时控制谁可以使用我们的作品，以何种方式使用。比如我允许别人打印我的图像，或者用在某个艺术品身上。此时，我不是通过口头形式建立协议，而是以设定了特定使用规则的许可协议发布我的作品。有版权的东西有时候又被称之为“智慧财产”。

许可协议由权威授予，用来允许某些特定的用途；举个例子，如版权所有者，我来设定资源的发布和使用方式。我可能决定免费提供我的作品，或者要求付费；或者我可以使用某种许可协议来限制使用，并维护自己的版权。一些用户即使为我的作品付钱了也并不意味着他们对所购买的产品有全面的控制或者权利。许可协议可以规定指明金额或者用途，使用限制，甚至许可协议有效期。

还有，在雇佣模式下，老板拥有版权，而不是作者或者创造者；在许多情况下，通常是公司（比如说创造机构）或者它的客户（通过合同）拥有版权。在这些情况下，创造者拥有他们产品的“精神权利”，包括了归属权。这也就是在发布的文章中通常提到原作者，尽管“精神权利”可以包括匿名。

版权的法律可能非常复杂，但是这个可以是好的开始。

“合理使用”的含义

“合理使用”是版权所有者的特有权利的一个例外。它存在比如说美国，英国这样的国家。在这个特定的情况下，使用未经授权的资源是可能的。如果某个人的使用被定义为合理的使用，他们就不需要遵循某个协议。实质上讲，使用具有版权的东西是一个合法的权利。下面是几个合理使用的例子：

• 教育性的目的，比如说教授和学生研究
• 作为新闻报道或者发布文章的评论和观点。

这里有一个误解，即非商业和非盈利的使用都是可以被接受的并不成立。合理使用是一个法定词，是通过具体的例子来评判的。如果你认为你使用具有版权的资源是合法的，最好要深入彻底的研究下。

公共领域的含义

落入“公共领域”的资源通常没有版权拥有者，你随心所欲可以使用、修改、重新发布。一个作者因为某些原因丧失他们作品的版权，然后，他的作品资源就放到公共领域中。版权的拥有权在作者死后就过期了（在大部分国家是死后的50到70年）。

合法权利

每个国家对于版权法律都有自己的理解和解释，但是国家之间通常有许多的协定。许可协议是在版权法律之下的，不同于合同法律。然而，不同的司法局对法律的阐释又不太一样，所以版权法律和合同法律有时候看起来会没啥区别。

Berne Convention （为了保护文学和艺术品）于1886年建立，是一个管理版权的国际协定。它阐述到：每个成员国必须承认其他国家作品的版权，并且将给予本国公民的权利同等给予其他国家的公民。它同时为了版权所有者构建了最小标准化的保护。至今，已经有164个国家签署此协议。

许可协议会限制于某些司法局。所以，有时候一件东西可能在一个国家是自由的，而在另外一个国家版权所有者则会拥有所有权利。

如果你正在读这个，我猜，你正在或者将会从不同国家的版权所有者购买许可协议。这些许可协议可能会被这些国家的法律限制，而你必须要尊重他们。

现在，我们会深入政治和司法区域。记住：如果有疑问，寻求法律意见。

许可协议术语

一个许可协议可以从头开始写起，但是大部分人都选择比较知名的。接下来，我们将介绍一些关于我们网站设计和开发的常用许可证协议，特别是那些允许免费使用 – 是免费使用，而不是自由使用。通常来说，管理付费资源的许可证协议都被单独撰写，但是所有的许可证协议都有共同点。

在源代码和摄影作品这两个种类上通常会有明显的本质区别。所以不难理解，有各种范围的许可证协议存在着。每个都根据用途不同定做。在我们深入研究之前，先认识一些专业术语：

• Copy：源作品的一份拷贝。
• Modify：在使用具有版权的作品之前，以某种方式来修改。
• Derivative work：修改有版权的作品来创造一个新的作品。
• Distribute：将自己的作品以某种许可证协议发布的行为。
• Redistribute：在原许可证协议下获取作品之后，再次发布作品和许可证协议的行为。
• Share alike：以相同或者类似许可证协议发布作品的行为.
• Credit 或者 attribution： 表明原版权所有者的行为
• Copyright notice：一个强调短语或者用(©)符号来表明版权所有者(根据法律规定不一定存在)。
• All rights reserved：一个常见的版权所有的声明：保留所有权利（可以不声明）。
• Warranty “”包含许可证协议的保证(通常可以不写).

知识共享许可协议（CC协议）

Lawrence Lessig 在2001年建立 Creative Commons (CC)来为在线工作创建一系列的易于理解版权许可证，通常包含了一些“some rights reserved.”

知识共享协议有六种核心协议，其包含了各种特定使用情况下的协议，如当初具有许可协议的作品是否可以商用，可以被修改，是否可以使用相同（或者兼容）的协议再发布。

最基本的CC许可协议是 CC Attribution。它允许所有的，如复制，修改，重新发布（甚至是商业的），它假设原作者的被著名（而原作者没有表示/暗示任何的认同，或支持）。在 CC Attribution 下东西是完全的自由。

CC Attribution 扩展出来就是 CC Attribution-ShareAlike.基本上与 Attribution 一样，不同的是所有衍生出来的工作必须以相同的许可协议发布。这样的不同确保了所有的东西仍然保持自由。Wikipedia 就是采用此许可协议。

下面是其他四个CC许可协议：

• CC Attribution-NoDerivs 重新发布是允许的，前提是标注了原归属权，并且没有修改。
• CC Attribution-NonCommercial 只要包含了原归属权，所有事情都是允许的，但是不允许用于商业目的。
• CC Attribution-NonCommercial-ShareAlike 和上边的一样，但是重新发布的作品必须以同样的许可协议发布。
• CC Attribution-NonCommercial-NoDerivs 重新发布的作品允许非商业应用，没有任何修改。

如你所见，CC许可协议有6个不同的版本，所有的版本都要求注明原作者。

你可以这样标注，作品的标题，版权信息，原作者的名字，许可协议的名字，例如：

This work includes the photo “Photo’s Title,” available under a Creative Commons Attribution license, © Author’s Name.

如果原有作品包含了版权信息，必须原文完整的包含。还有，你可以用其他合适方法来注明。还有，最好给原作品和其版权信息的链接。通知原作者很礼貌的，但并不必须。

CC0

CC0使版权所有者放弃他们所有的权利。它是一种方式，即将作品放在公共区域并且“不保留任何权利”。这个概念存在着，是因为许多司法署对把作品放在公共区域的过程并不清楚，许多法律系统实际上也禁止诸如版权拥有权之类的法律权利。

CC许可协议清晰明了。如上所述，Wikipedia 使用的是 Attribution-ShareAlike。Flickr 让用户为自己巨大的图像资源选择使用哪种 CC 许可协议。

在设计页面、编写文章或制作 PPT 的过程中，有时需要用到外部的图片，网上寻找的图片一不小心可能就会让你变成被告。基于 CCO 版权协议的免费图库则可以为你避免此类问题。

CCO 版权协议的图片网站：

• https://www.pexels.com/
• https://pixabay.com/
• https://unsplash.com/
• http://www.publicdomainpictures.net/
• https://www.splitshire.com/
• http://www.1millionfreepictures.com/
• https://gratisography.com/
• http://littlevisuals.co/
• http://pdpics.com/
• https://nos.twnsnd.co/
• http://publicdomainarchive.com/
• http://librestock.com/
• http://finda.photo/
• https://everypixel.com/
• https://www.goodfreephotos.com/
• https://www.lifeofpix.com/
• https://stocksnap.io/
• https://picjumbo.com/
• https://visualhunt.com/
• https://libreshot.com/
• http://www.iconfont.cn/plus
• https://morguefile.com/quest/1
• http://pickupimage.com/cn/
• https://www.flickr.com/creativecommons/

CC0音乐：

• https://soundcloud.com/
• http://freemusicarchive.org/
• http://www.freesound.org/
• http://dig.ccmixter.org/
• http://www.kompoz.com/
• http://www.beatpick.com/
• http://musopen.org/
• http://vimeo.com/musicstore?license=cc
• http://ibeat.org/
• http://www.cctrax.com/
• http://www.jewelbeat.com/free/free-background-music.htm
• http://audionautix.com/
• http://www.purple-planet.com/
• http://incompetech.com/music/royalty-free/
• http://www.bumpfoot.net/
• https://opengameart.org/content/cc0-music
• https://starfrosch.com/hot-100/royalty-free-music/cc0
• https://www.bensound.com/
• https://www.zapsplat.com/
• https://www.unminus.com/

软件许可协议

软件许可协议包含了代码的使用。如果你使用了第三方的库或者开源项目中的元素，你的使用必须遵守相关的协议。

开发许可协议通常包含了以下几点：

• 作品以及所做的修改发布的方式
• 所有修改过的作品是否要开源
• 重发布时的版权问题以及其他事项

软件许可协议可以被定义为：“宽容的”或者“copyleft”，而后者移除了在重新发布的作品之上再加限制的权利。

下面是一些常见的软件许可协议和他们的方式。

世界上的开源许可证（Open Source License）大概有上百种，今天我们来介绍下几种我们常见的开源协议。大致有GPL、BSD、MIT、Mozilla、Apache和LGPL等。

MIT许可协议

MIT许可协议（英语：The MIT License）是许多软件许可条款中，被广泛使用的其中一种。与其他常见的软件许可协议（如GPL、LGPL、BSD）相比，MIT是相对宽松的软件许可协议。

MIT许可协议之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称”X许可协议”（X License）或”X11许可协议”（X11 License）

MIT内容与三条款BSD许可协议（3-clause BSD license）内容颇为近似，但是赋予软件被许可人更大的权利与更少的限制。

有许多团体均采用MIT许可证。例如著名的SSH连线软件PuTTY与X窗口系统。Expat、Mono开发平台库、Ruby on Rails、Lua、微软的Visual Studio Code源代码等等也都采用MIT许可协议。

被许可人权利

特此授予任何人免费获得本软件和相关文档文件（”软件”）副本的许可，不受限制地处理本软件，包括但不限于使用、复制、修改、合并、发布、分发、再许可的权利，被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和/或贩售软件及软件的副本，及授予被供应人同等权利，惟服从以下义务。

被许可人义务

在软件和软件的所有副本中都必须包含以上著作权声明和本许可声明。

其他重要特性

• 此许可协议并非属copyleft的自由软件许可协议条款，允许在自由及开放源代码软件或非自由软件（proprietary software）所使用。
• MIT的内容可依照程序著作权者的需求更改内容。此亦为MIT与BSD（The BSD license, 3-clause BSD license）本质上不同处。
• MIT许可协议可与其他许可协议并存。另外，MIT条款也是自由软件基金会（FSF）所认可的自由软件许可协议条款，与GPL兼容。

MIT是和BSD一样宽松的许可协议,作者只想保留版权,而无任何其他了限制.也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的。

• 你可以使用，复制和修改软件
• 你可以免费使用软件或出售
• 唯一的限制是，它是必须附有MIT授权协议

BSD许可协议

BSD许可协议（英语：Berkeley Software Distribution license）是自由软件中使用最广泛的许可协议之一。BSD就是遵照这个许可证来发布，也因此而得名BSD许可协议。

BSD包最初所有者是加州大学的董事会，这是由于BSD源自加州大学伯克利分校。BSD开始后，BSD许可协议得以修正，使得以后许多BSD变种，都采用类似风格的条款。

跟其他条款相比，从GNU通用公共许可证（GPL）到限制重重的著作权（Copyright），BSD许可证比较宽松，甚至跟公有领域更为接近。事实上，BSD许可证被认为是copycenter（中间著作权），介乎标准的copyright与GPL的copyleft之间。”Take it down to the copy center and make as many copies as you want”[1]。可以说，GPL强迫后续版本必须一样是自由软件，BSD的后续版本可以选择要继续是BSD或其他自由软件条款或封闭软件等等。

BSD开源协议：是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

• 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
• 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
• 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

BSD在最初散播的时候，其许可证内含有一项额外的条款，要求所有从以BSD许可证授权的软件派生著作，都必须要包含一段文字以交代源代码的来源。该条文列于原BSD许可证的第三条。

GNU工程将这个称为”令人感到不舒服的BSD交代条款”（obnoxious BSD advertising clause）。GNU工程认为存在两个问题：第一，修改源码的人都希望将其大名加到鸣谢中，如果一个项目参加的人非常多，或者软件包中包含许多个单独项目，鸣谢阵容将会变得非常庞大；第二，这跟GNU通用公共许可协议相抵触，GPL不允许增加额外的限制，所以软件只能在GNU跟BSD之间选择。GNU工程建议人们提到非copyleft许可证的例子时，不要使用”BSD风格”的字眼，以免原本的BSD许可证不慎被使用。

应理查德·斯托曼的请求，1999年7月22日，William Hoskins，也就是伯克利技术许可办公室的主管（director of the office of technology licensing for Berkeley），删除了BSD许可证的第三条。[3]原来的许可证有时被称为”BSD-old”（老BSD）或”4-clause BSD”（四句版BSD），当前的BSD许可证有的被称为”BSD-new”（新BSD）、”revised BSD”（修订的BSD）或”3-clause BSD”（三句版BSD）。

Apache许可协议

Apache许可证（英语：Apache License），是一个由Apache软件基金会发布的自由软件许可证，最初为Apache http服务器而撰写。Apache许可证要求被授权者保留著作权和放弃权利的声明，但它不是一个反著作权的许可证。

此许可证最新版本为”版本2″，于2004年1月发布。

Apache许可证在Apache社区内外被广泛使用。Apache基金会下属所有项目都使用Apache许可证，许多非Apache基金会项目也使用了Apache许可证。

Apache许可证是宽容的，因为它不会强制派生和修改产物使用相同的许可证进行发布（与一些著作权许可证不同，参见比较）。但它仍然要求对所有未修改的部分应用相同的许可证，并且在每个许可文件中，必须保留再分发代码中的任何原始著作权，专利，商标和归属通知（不需要包括任何部分的派生作品）；并且在每个更改的许可文件中，都必须添加一条通知，说明对该文件进行了更改。

如果声明文本文件作为原始作品发布的一部分包含在内，则派生作品必须在包含该通知文本文件的可读副本，可以是文档或显示在软件中。

声明文件的内容不会修改许可证，因为它们仅用于提供信息，并且可以在许可证文本中添加更多属性声明，前提是这些声明不能被理解为修改许可证。修改可能有适当的著作权声明，并可能为修改提供不同的许可条款。

除非另有明确规定，否则许可证持有者向授权者提交的任何文稿将根据许可证的条款进行，没有任何条款和条件，但这并不排除与授权者有关的这些贡献有单独的协议。

Apache Licence需要遵循以下条件：

• 需要给代码的用户一份Apache Licence。
• 如果修改了代码，需要再被修改的文件中说明。
• 在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
• 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以再Notice中增加自己的许可，但是不可以表现为对Apache Licence构成更改。
• Apache Licence也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。

使用这个协议的好处是:

• 永久权利一旦被授权，永久拥有。
• 全球范围的权利在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。

授权免费无版税，前期、后期均无任何费用。

• 授权无排他性任何人都可以获得授权
• 授权不可撤消一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码

Apache 许可协议 v2 可以说是 GPL 兼容的，意味着一个 Apache v2 发布的代码工程同样以 GPLv3 许可协议发布。

GPL 许可协议

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

历史上，GPL 许可证系列一直是自由和开源软件领域最受欢迎的软件许可之一。根据 GPL 许可的优异自由软件程序的例子有 Linux 内核和 GNU 编译器集合（GCC）。大卫·A·惠勒认为，GPL 提供的 Copyleft 对于基于 Linux 的系统的成功至关重要，给予向内核贡献的程序员保证他们的工作将有益于整个世界并保持自由，而不至于被不提供反馈给社群的无良软件公司所剥削。

2007 年，发布了第三版许可证（GNU GPLv3），以解决在长期使用期间发现的第二版（GNU GPLv2）所发生的一些困扰。为了使许可证保持最新状态，GPL 许可证包含一个可选的“并延伸到未来版本”条款，允许用户在 FSF 更新的原始条款或新版本之间进行选择。有些开发人员在软件许可使用时，选择省略它; 例如，Linux 内核已经在 GPLv2 下获得许可，就不需包括“并延伸到未来版本”的声明。[15][16]

GPL 授予程序接受人以下权利，或称“自由”，或称“copyleft”：

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

相反地，随著作权所有软件的最终用户许可证几乎从不授予用户任何权利（除了使用的权利），甚至可能限制一些法律允许的行为，比如逆向工程。

GPL 与其他一些更“许可的”自由软件许可证（比如 BSD 许可证）相比，主要区别就在于 GPL 寻求确保上述自由能在复制软件及派生作品中得到保障。它通过一种由斯托曼发明的叫 Copyleft 的法律机制实现，即要求 GPL 程序的派生作品也要在 GPL 之下。相反，BSD 式的许可证并不禁止演绎作品变成专有软件。

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 宽松通用公共许可证（英语：Lesser General Public License），以反映其在哲学中的地位。

最常见的是“GPLv2 并延伸到未来版本”的声明，让许可证的用户了解，得以允许升级到 GPLv3。

GPLv3

理查德·斯托曼起草了第一份 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 日自由及开源软件开发者欧洲会议的演讲时谈到最重要的四件事：

• 解决软件专利问题；
• 自由软件许可证与其它商用许可的兼容性问题；
• 源代码分割与组成的定义；
• 解决数字版权管理的问题，意即反软件修改的硬件限制。

还有一些其他的更改涉及国际化，如何处理许可证违规，以及著作权所有者如何授予额外权限。它还增加了一项规定，“剥离”（strips）其法定价值的数字版权管理（Digital Rights Management，缩写 DRM），所以人们可以合理的当在法院被视为侵犯 DRM 时，去破解运行 GPL 软件的任何东西，而不会违反 DMCA 等法律。

公共咨询过程由自由软件基金会在软件自由法律中心、欧洲自由软件基金会和其他自由软件组织的协助下进行协调。通过 FSF（页面存档备份，存于互联网档案馆）网站从公众收集评论。该门户网站运行名为 stet 的专用软件。在公众咨询过程中，提交了第一稿的 962 条意见。最后，共提交了 2636 条意见。

第三稿于 2007 年 3 月 28 日发布。该草案包括旨在防止与专利相关协议（如有争议的 Microsoft-Novell 专利协议）的语言，并将反倾销条款限于“用户”或“消费品”。它还明确删除了“地理限制”一节，确认公开咨询开始时就提到可能会删除的这一部分。

最后的第四个讨论草案于 2007 年 5 月 31 日发布。它引入了 Apache 许可证版本 2.0 兼容性（以前的版本不兼容），澄清了外部承包商的作用，并提出了一个例外，以避免充满争议的 Microsoft-Novell 专利协议再度发生，在第 11 节第 6 段中说：“您不得发送具 GNU 许可证保护的软件作品，如果您是与营销软件业务（后称第三方）进行安排的缔约方，根据该协议按照你发送作品活动的程度，您付款项给第三方，又根据该协议，对于可能收到与您所涉涵盖的工作的其它方，第三方获得歧视性专利。”

这旨在使未来像这样的交易无效。该许可证还意味着 Microsoft 将其授予 Novell 客户的专利许可证扩展到使用 GPLv3 软件的所有用户，使用 GPLv3 软件;除非当 Microsoft 合法地是 GPLv3 软件的“发送者”时，才有可能。

此外，GPLv3 的早期草案让许可方添加了一个 Affero 类的需求，将会填补 GPL 中的 ASP 漏洞[41][42]。由于担忧该附加要求的代码检查所需要的额外行政费用，决定将 GPL 和 Affero 许可证分开。

值得留意的是 Linux 内核的一些高调的开发人员，例如林纳斯·托瓦兹、葛雷格·克罗哈曼和安德鲁·莫顿，向大众媒体发表了评论，并就讨论草案 1 和 2 的部分内容作了公开声明。内核开发人员提及关于 DRM/Tivoization、专利和“附加限制”的 GPLv3 草案条款，并警告会产生“开源宇宙”（Open Source Universe）的巴尔干半岛式分裂。林纳斯·托瓦兹决定不采用 GPLv3 作为 Linux 内核，仍然使用 GPLv2 许可，甚至在几年后重申了他的批评。此事曾引起理查德·斯托曼的不满。

GPLv3 提高了与许多开放源代码软件许可证（如 Apache 许可证版本 2.0）和 GNU Affero 通用公共许可证（GPLv2 无法组合）的兼容性[48]。但是，如果所使用的 GPLv2 许可证具有可选的“或更高版本”子句，并且软件升级到 GPLv3，GPLv3 软件只能与 GPLv2 软件组合并共享代码。虽然 FSF 认为“GPLv2 并延伸到未来版本”条款是许可 GPLv2 软件的最常见形式[49]，诸如 Toybox 开发商 Rob Landley 将其描述为“救生艇条款”（lifeboat clause）。使用可选“或更高版本”条款许可的软件项目包括 GNU 项目，而没有该子句的最明显的案例是 Linux 内核。

许可证文本的最终版本于 2007 年 6 月 29 日由自由软件基金会正式发布。

LGPL

GNU 宽通用公共许可证（英语：GNU Lesser General Public License，简称：LGPL）是由自由软件基金会公布的自由软件授权条款。它允许企业与软件开发者使用，或将 LGPL 授权的软件整合至他们自己的软件内（即使该软件是私有软件也被允许），同时不会受到 Copyleft 特性的许可证强制对软件开源的限制。该许可证常被用于一些（但不是全部）GNU 程序库。

这个许可证以前被称为 GNU 程式库通用公共许可证（GNU Library General Public License）。此许可证最新版本为“第 3 版”，2007 年 6 月 29 日发布，较早的版本有 2.0 和 2.1 版。此种授权之出现，是为了在 GPL 与许可式授权（如 MIT 许可证及柏克莱大学的 BSD 许可证）间取得折衷。

采用 LGPL 之计画本身虽然仍有“Copyleft”之限制条件，但这些限制不感染仅仅只链接到本计画的软体。不过此等软体仍会受到其他限制。

LGPL 主要使用之标的为软体函式库（Software Libraries），但是其亦可使用于独立存在的应用程式。比较有名的例子为 Mozilla 跟 OpenOffice.Org。

Mozilla 公共许可证

Mozilla 公共许可证（英语：Mozilla Public License，简称 MPL）是个自由、开源、详细的软件许可证，由 Mozilla 基金会开发并维护。该协议融合了 BSD 许可证和 GNU 通用公共许可协议的特性，追求平衡专有软件和开源软件开发者之间的顾虑。

此协议已有两个版本，最新发布的 2.0 版以更简洁和更好的兼容其他协议为目标。

MPL 既是得到自由软件基金会承认的自由软件许可证，也是得到开放源代码促进会承认的开源软件许可证。MPL 允许在其授权下的源代码与其他授权的文件进行混合，包括私有许可证。但在 MPL 授权下的代码文件必须保持 MPL 授权，并且保持开源。这样的条款让 MPL 既不像 MIT 和 BSD 那样允许派生作品完全转化为私有，也不像 GPL 那样要求所有的派生作品，包括新的组件在内，全部必须保持 GPL。通过允许在派生项目中存在私有模块，同时保证核心文件的开源，MPL 同时激励了商业及开源社区来参与帮助开发核心软件。

使用 MPL 许可的软件并不受专利的限制，其可以自由使用，出售，并可自由的重新发布。带有专利代码的版本仍然可以使用，转让，甚至出售，但未经许可则不能修改代码。此外，MPL 并不授予用户对于开发者商标的使用权。

为了满足 MPL 的条款限制，用户必须负担一些“责任”，主要是关于散发使用 MPL 许可的软件。用户必须确保重新散发的软件所有源代码均以 MPL 许可，即使是以可执行文件的方式提供或是与其他使用专有软件许可的源代码结合也一样。但若跟以 GNU 通用公共许可协议、GNU 宽通用公共许可证、Affero 通用公共许可证许可的源代码结合则是例外。此时开发者则可选用以上三种更加严格的条款来许可。

不像那些较严格的 Copyleft 许可证，使用 MPL 许可的源代码可以在一个复杂的软件中与任何其他的许可协议相结合，只要仍满足 MPL 许可协议中 3.3 节的规定即可[5]。这意味着在一份给定的源文件里面，必须全部的源代码都以 MPL 许可，否则就所有源代码均以其他方式许可。

MPL 第二版与 Apache 许可证以及 GPL 第二版或更新、LGPL 2.1 版或更新，及 AGPL 第三版或更新兼容。而 1.1 版因为有“一些复杂的限制”造成与 GPL 的不兼容（从而阻止升级到 MPL 2.0）。MPL 1.1 版虽然也包含了一个可以让开发者在第二个许可（包含 GPL 及与 GPL 兼容的许可证）下撰写代码的条款，但 MPL 1.1 与 GPL 却无法“合法的链接”，导致自由软件基金会不鼓励开发者使用 MPL 1.1 进行许可[21]。因为这个理由，早期的 Firefox 采用了三重许可：MPL 1.1、GPL 2.0、LGPL 2.1。Mozilla Application Suite 仍采用三重许可。