GPLv3
经过一年半的公开讨论，GPLv3 协议最终于 2007 年发布，其中增加了一些适用于特定情况的附加合规义务，但也使主要合规义务更易于履行，从而大大降低了因非故意侵权而造成许可自动终止的风险。
GPLv3 协议的撰写原则是避免使用专用于美国或某系统的词汇，以免引入仅适用于某系统的法律假设。例如，GPLv2 协议中的“分发”和“衍生作品”术语就曾造成分析困惑，对于理解整个许可证几乎有害无益。自 1991 年以来，随着 GPL 软件在全球广泛使用，FSF 及其律师们决定避免使用专用于某系统的表述，以免产生许可证理解方面的困惑。
GPLv3 协议中慎重使用了两个非国际版权法律语言的术语。“传播”许可证所涉作品指需要根据本地法律体系从版权持有人处获得许可才可进行的任一活动。出于个人原因使用或修改作品被明确排除在“传播”范围之外（无论各国版权法如何规定），以防止各国版权法影响如前所述的第 0 至 2 项自由权利。另一项好处是，由于“传播”包含任何特定版权制度下所授予的全部专有权利，因此自然而然地合规要求有效许可才能获得专有权的所有制度。
任何使他人能够接收或复制作品的传播活动都称为“发布”。在一般情况下，发布会产生 Copyleft 义务。“通过计算机网络与用户交流，而不涉及副本传送”被明确排除在“发布”范围之外，此规定区分了 GPLv3 协议和 AGPLv3 协议，详情请参见下文。
使用这些术语使人们只根据本地法律知识或技术事实便可对 GPLv3 协议进行权威解读。对在本国国内版权法框架下的 GPLv3 合规性存有疑问的各方只需了解以下两个问题，一个法律问题，一个事实问题：
1.根据本地版权法，我是否需要获得许可证才可开展此活动？
2.我开展的活动是否让任何其他方能够制作或接收此程序副本？
如果本地版权法律师对第一个问题的回答是否定的，则您所开展的活动不属于传播活动，因此受到 GPLv3 协议许可，无需获得许可证。如果本地版权法律师对这两个问题的回答都是肯定的，则您所开展的活动属于“发布”活动，需要履行下文 §§4-6 所述的 Copyleft 义务。
GPLv3 协议要求作品发布者提供构建程序所需的所有源码，包括支持库和编译脚本等。GPLv3 §1 中的“对应源码”定义如下：
生成、安装、（对可执行作品而言）运行目标码以及修改作品所需的所有源码，包括用于控制这些活动的脚本。但并不包括作品的系统程序库，或者在未经修改的情况下用于开展这些活动、但并非该作品一部分的常用免费程序或通用工具。例如，对应源码包括与作品的源码文件相关联的接口定义文件，以及作品通过这些子程序和其他部分之间的密切数据通讯或控制流等方式明确要求的共享库和动态链接子程序源码.
GPL 的两个许可版本都免除提供完整对应“系统库”源码的要求，通常称为“系统库例外规定”。如上文引语所述，“系统库例外规定”使分发者免于交付不必要的源码，这些源码可能随操作系统一起提供，也可能属于公开代码，或是用于生成该程序的通用编程工具。
第 2 节：基本许可
此许可证明确表明您可以不受限制地运行该程序的未修改版本。在合规此许可证条款的情况下，即使不发布作品也可进行修改或传播。例如，如果您的许可遭到终止，则将无法制作新的修改版本来提供给他人。
第 2 节明确规定此许可证禁止分许可。“软件即服务”中的轻率合同条款或其他模糊不清的内容可能并已经与本条款冲突。
第 4 节：发布完整副本
根据 §4 的条款，任何人都可无限制地发布程序源码的完整副本。发布者的合规义务仅限于附加版权声明以及随源码提供许可证文本。如果缺少版权声明，则必须添加。按照下面 §7 的规定，所有权利归属声明和附加许可（或者新添加的权利归属声明和许可）以及所有上游保修免责声明都必须保留。自动化软件管理程序能够通过简单且低成本的方式履行 §4 中规定的所有义务。
第 5 节：发布经过修改的源码版本
§5 规定的声明义务与 §4 的规定相同，不过添加了一些附加要求：提供修改声明、修改日期和修改人身份信息（如上述 GPLv2 §2(a) 要求）。
§5 重申了 GPLv2 §2 中的集合规定，如下所示：
如果该许可证所涉作品与其他隔离且独立的作品编译于同一存储或分发介质上，但该独立作品并非此所涉作品的扩展，也不会与此所涉作品组合为一个更大的程序，且这一组合及由此产生的版权不用于限制用户的使用范围和法律权利不得超出单独作品的相关权限，则这种组合称为“集合”。在集合中引入所涉作品不会导致此协议适用于该集合中的其他部分。
第 6 节：发布非源码形式的副本
第 6 节规定了分发“非源码形式”程序时的合规义务。任何不利于开发者修改的代码形式都称为“非源码形式”。因此，除了二进制代码或可执行代码，非源码形式还包括经过混淆处理、最小化、压缩或其他不利于修改的呈现形式。目前在网络上分发 Javascript 时不合规 GPLv3 协议的情况越来越多，虽然还未导致任何纠纷，但如果一直这样发展下去，可以预见未来这一领域必定会产生纠纷。
§6 要求提供完整对应源码的条款与上述 GPLv2 §3 中的条款非常相似，但进行了一些更改以便更易于在现代技术条件下合规。在 GPLv2 协议下，源码可通过网络分发，不过与 GPLv2 §3 相比，“相同地点”要求在 GPLv3 中略微宽松：
如果要在网络服务器上复制目标代码，那么对应源码可位于另一台支持等效复制设备的服务器上（由您或第三方操作），但您需要在目标码旁清楚标明对应源码所在的位置。无论对应源码托管在哪个服务器上，您始终有义务确保用户在需要时可找到该源码。
此条款首次允许第三方在商业分发情况下提供完整对应源码。分发非源码形式副本的一方仍然有义务明确指明（在非源码下载内容“旁边”）提供源码所在的第三方服务器位置，并确保该第三方服务器在规定期间正常运作。
第 6 节还允许在二进制代码或其他非源码形式代码依据端到端网络协议（如 BitTorrent）分发的情况下，使用此类服务器提供源码。唯一相关要求与上文所述相同，即必须让每一端都知晓源码在服务器上的位置
第 6 节对书面要约的相关规则进行了少许修改。根据上述 GPLv2 §3(b) 条款，书面要约必须在三年内持续有效。而除了书面要约的有效期至少为三年外，GPLv3 §6 还要求只要该软件所嵌入的实体产品仍在提供其他备件和/或客户服务，则该书面要约就应持续有效。
§1 中有关对应源码“系统库”例外情况的定义与已讨论过的 GPLv2 协议中的相应定义有较大差异。新的定义如下：
可执行作品的“系统库”除了作为整体的作品外，还包括以下两种代码：(a) 打包主要部件时包含在代码包中，但并非主要部件的部分代码；(b) 仅用于让作品可与主要部件一起运行的代码，或者用于实施标准接口的代码，此类标准接口的实施源码本身已公开。在此规定中，“主要部件”指运行可执行程序的特定操作系统（如果有）中的某个主要且不可或缺的部件（例如内核、窗口系统等），或者用于生成本作品的编译器，或用于运行本作品的目标码解析器。
此定义阐明了该程序目标操作系统的分发过程中所包含的语言处理器（编译器和解析器）不属于对应源码。如 GPLv2 协议中所述，随附于操作系统主要部件的库或者其他启动或辅助代码也不属于对应源码。同样，以公共文档形式发布的“标准接口”（以源码形式向公众公开）也不属于对应源码。
GPLv3 协议中讨论最为广泛的新要求也包含在 §6 中，即要求在“用户产品”中提供 GPLv3 代码的“安装信息”。§6 的提供“安装信息”要求旨在保护用户权利，让用户可以修改其所购买和使用的产品中嵌入的 GPLv3 代码，并运行修改后的版本。如果没有此条款，则“锁定”设备以阻止法定持有人修改软件便会损害 GPL 许可证作者希望用户拥有的自由权利。如果所有嵌入式设备都执行此类锁定，则如美国最高法院曾经说过的一样，GPL 所保证的自由权就会变成“空头支票”(Edwards v. California, 314 U.S. 160, 186 (1941) (Jackson, J. concurring)
“用户产品”指：
(1)“消费品”，即通常用于个人、家庭或日常使用的有形个人财产；或 (2) 任何为了安装到住所而设计或销售的产品。
“用户产品”在通过永久转让所有权或控制权，或者基于固定期限出借或出租时，产品中 GPL 程序的非源码形式副本便已向用户发布。向用户提供对应源码时应随附足够的技术信息：
方法、过程、授权密匙，或安装和执行用户产品中的修改版 GPL 软件所需的其他信息。这些信息必须足以保证修改后的目标码不会仅因遭到修改而无法继续执行。
除非设备中采用了技术措施来阻止修改版本的安装和执行，否则此要求无关紧要。因此从 2007 年以来的经验可以看出，如果生产厂商想要锁定其产品，则应避免使用 GPLv3 软件。据我们所知，自 GPLv3 发布之日起，尚未出现任何针对违反此安装信息要求的维权行动。
第 7 节：附加条款
GPLv2 协议不允许添加任何附加限制条款，但 GPLv3 协议允许进行一些特定的有限变化，与严格的 GPLv2 协议下 Copyleft 相比，GPLv3 更好地兼容了其他许可证。第 7 节包含可用于补充此许可证条款的附加许可和非许可条款。任一版权持有人均可在其对许可作品的贡献版本中附加 §7 中条款外的额外许可条款。GPLv3 协议声明，所有附加许可条款都必须以书面形式提供，这一点在 GPLv2 中并未规定。条款起草者认为，GPLv2 协议允许附加条款以非正式或非书面形式提供的规定会造成不必要的疑惑。如果软件发布者希望在发布软件副本前删除之前由上游作者授权的书面附加许可条款，则可将其删除。
第 7(a) 节 — 保修免责声明。版权持有人有权免除保修责任，或以与 §§15 和 16条款规定不同的方式限制其应承担的责任。GPL 的全球适用要求起草者允许对这些条款进行必要更改，因为目前国际上尚未就保修和免责法律达成共识。
第 7(b) 节 — 保留适当的法律声明。第 7 节允许要求保留适当法律声明的附加条款，包括有关所涉作品执行结果的声明。
第 7(c) 节 — 此条款禁止歪曲原始材料，使 GPLv3 与要求以 “合理”方式标记修改版本（与 GPL 的精确标记要求不同）的宽松许可证相符。
第 7(d) 节 — 限制以宣传为目的使用许可方的姓名。添加此条款是为了与禁止在未修改版本上使用许可方姓名以及其他具有广告宣传禁令的许可证相符。GPL 与“BSD 广告条款”的冲突长期以来不时为用户带来困扰，此条款的制定解决了此问题。
第 7(e) 节 — 不授予商标法权利。此条款在“不许可商标权”这一点上与宽松的许可证条款具有类似效用。
第 7(f) 节 — 允许要求作者和许可方赔偿，从而解决了与 Apache 软件许可证 2.0 冲突的两个主要部分之一。
除了上述附加条款外的任何其他非许可条款均视为 §10 条款禁止附加的“进一步”限制。如果您添加了第 7 节中所述的附加条款，则必须确保添加的条款位于相关源文件中，或在显著位置标明附加条款的位置。§7 中的合规义务完全属于法律审查问题，不存在技术或编程方面的后果。
示例：GNU 编译器集 (GCC) 运行时间库特例 GCC 运行时间库特例（“特例”）属于 GPLv3 协议第 7 节所述的附加许可。此特例条款的制定目的在于允许编译非 GPL（包括私有）程序，此类程序可利用特例所涉的标头文件和运行时间库，并包含编译器在编译过程中内嵌在程序目标代码中的 Copyleft 工具链中的代码。GCC 运行时间库特例中的所涉文件指任何在许可证标头处包含例外情况声明的文件。其中包括 libgcc、libstdc++、ibfortran、libgomp、libdecnumber、libgcov 以及其他使用 GCC 分发的库。
第 8 节：终止许可
GPLv3 将 GPLv2 中的“如果违反条款将自动终止许可”规定改为“如果是首次违反条款，则可在一定时期内自我修正，并自动恢复许可证所授予的权利”，这一变动是新版本中对基本合规规则最重要的修改之一。
但是，如果您在发现违反许可证条款后停止了所有侵权行为，则您从某个特定版权持有人处获得的许可证能够通过以下方式恢复 (a) 暂时恢复许可证，直到版权持有人最终明确终止您的许可证；(b) 如果在您停止侵权行为后的 60 天内，版权持有人没有以某种合理方式向您提供侵权通知，则您可永久恢复许可证。
进一步来说，如果某个版权持有人以某种合理方式向您提供侵权通知，而这是您首次收到来自该版权持有人的此类通知（针对任何作品），并在收到该通知后的 30 天内修正了侵权行为，那么您从该版权持有人处获得的许可证将永久恢复。
与 GPLv2 相比，GPLv3 规定了对发现并修正问题的激励措施，这正是新版本的一大主要优势。自动终止的许可只有在获得版权持有人同意后才可恢复，这虽然能够避免失去分发权，但也在鼓励隐藏问题，而不是解决问题。“整体分发侵权”案例指未能在分发设备内嵌的整个操作系统时提供所有 Copyleft 程序的对应源码，这会导致一次性侵犯成百上千个版权作品的版权。这种情况对侵权者恢复许可造成了巨大障碍，而如果没有恢复许可证，他们就不能分发产品。在最近的一个案例中，我们受聘对一家在软件编程合规方面相对缺乏经验的中型企业进行审计。在审计过程中，我们发现该企业已发生“整体分发侵权”情况。该企业早期产品中的软件在分发时不合规并且已导致许可自动终止，只是该企业尚未发现。依据 GPLv2 协议，即使新产品完全合规，也需要联系 100 多个软件包的所有权利人，才能确保其拥有继续分发新产品的权利。
第 10 节：下游接收者的自动许可
此节列出了本文档其他部分所讨论的无附加限制和向下游接收者自动授予许可原则。向分发程序的接收对象主张专利权属于附加限制，是第 10 节中所明确禁止的。
兼并和并购 第 10 节还阐明，无论是通过收购资产还是转让控制权来收购企业，收购方都是被收购方的下游用户。这就产生上游版权持有人自动向下游授予的新许可、被收购企业所做所有修改的许可，以及向新的下游收购方提供源码的权利。
根据我们的经验，在大多数并购情况下，处理这些许可和权利的成本都极高，而且效率低下。其实，只要收购方在收购项目完成前声明豁免和免除被收购方的 GPL 合规责任，就可解决这个问题。如果收购方已有足够完善的软件管理系统，则在整个交易过程中获得的所有软件都可纳入已购买软件的标准管理流程，这样并购后的新实体就可以自动完成合规。
第 11 节：专利
GPLv3 提供以下两项专利承诺：
1.禁止向下游分发对象主张专利权：GPLv3 §10 明确规定不可施加附加条件来要求被许可方的直接分发对象接受专利许可或支付专利许可费。此条款制定了有关 GPL 软件专利权用尽的统一规则，不考虑任何特定法律体系或区域法律下的国内专利法。
2.贡献者版本中的专利许可：第 11 节指出，任何向 GPL 软件贡献代码的人都需要将其中涉及的专利许可授予用户。此规定旨在防止社区内的成员以激进方式向用户主张自己所修改的代码部分的专利权，即防止社区“内部人员叛变”。如果引入修改代码可导致修改后的软件构成侵犯贡献者专利权，贡献者会将原软件中的专利权许可授予所有后续用户、软件修改人或软件衍生作品的修改人，但不会授予代码修改部分中属于他人的专利权许可。此条款还规定，“贡献者版本”完成后获得的专利权也会在版本获得或完成时授予用户。如果某个拥有众多此类专利权的公司收购或聘用了程序修改者，则根据本条款，收购者已获得和后续获得的专利权也会自动传递。例如，微软公司收购诺基亚后，微软基于诺基亚曾修改的任何 GPLv3 程序的任何贡献者版本当前或以后获得的此类专利权都会自动向下游授予许可。微软收购诺基亚导致 GPLv3 程序的微软专利诉讼量整体下降这一现象至今未在行业内得到充分关注。
第 11 节还努力减少相关方共谋实施歧视性专利许可而破坏 GPL 代码共有权这一现象。如果 A 从 B 处获得了专利许可证，而该许可证只对 A 有利，却对 A 的客户或分发对象不利，则 A 就将来源于 B 的专利风险转移给了其他人。在很多情况下，这种结果是可接受的。但如果只有 A 可分发该程序、获得该程序的许可证并基于此许可证分发该程序，则 A 实际上是在帮助 B“将该程序私有化”。 第 11 节提出了一些 A 可执行的方案，包括放弃该许可证或将该许可证适用对象扩展至相关各方。但最合规且成本最低的方案是：只需确保该程序的源码可永久通过第三方获得，以便希望自担风险开发、商业部署或再分发代码的人可以获得源码。
除了此“下游保护”规定，条款 §11 还采取另外两项措施，来防止滥用歧视性专利许可策略：
如果在某项单独交易或协议下，您获得一份所涉作品的发布权来发布或传播该作品，并向收到该作品的某些组织授予了专利许可，以授权他们使用、传播、修改或发布该作品的特定副本，则您所授予的专利许可会自动延伸给接收该作品以及该作品的所有衍生作品的所有接收者。
例如，如果 B 公司提供来自 A 公司的大量折扣券，这些折扣券可使第三方拥有 A 分发的 GPL 程序，并且只在第三方通过 B 购买 A 公司产品或使用 B 发放的折扣券购买 A 公司产品时，才会将该程序的专利权授予第三方。第 11 节事实上剥夺了 B 在交易中的价值，因为专利许可是自动扩展至所有其他用户的。经验表明，B 将反过来声称折扣券不适用于所涉软件包中的任何 GPLv3 程序。但这样做行不通。
如果某一专利许可的范围不包括或禁止实施此许可证明确授予的一项或多项权利、或以不实施一项或多项此类权利为前提条件，那么该专利许可具有“歧视性”。如果您与从事软件销售业务的第三方通过协议约定您支付给第三方的费用基于您发布作品的范围，第三方向从您接收作品的任何用户提供歧视性专利许可，该许可 (a) 与您发布的所涉作品副本（或基于这些副本复制的副本）相关，或者 (b) 主要用于涵盖所涉作品的特定产品或软件集合，或者与该产品或软件集合相关，则您不得发布该所涉作品。如果您与第三方签署的这一协议或获得前述专利许可的日期早于 2007 年 3 月 28 日，则不受此条款的约束。
此条款的引入旨在防止在自由软件基金会组织公开讨论实施 GPLv3 期间出现更多的公司间特定协议。据我们所知，目前尚未出现有关此条款的合规问题。
专利主张和报复：如果分发者或贡献者针对自己分发或贡献的作品主张专利权，GPLv3 规定了具有限制的专利报复方案。§§8、10 和 11 节共同描述了防御性的专利许可暂停和终止条件。
第 8 节的终止条款明确表明，如果被许可方违反 GPL 条款规定，则除了版权许可外，贡献者还可终止其根据 §11 条款授予该许可方的任何专利许可。因此，如果下游被许可方提起违反 §10 的专利侵权诉讼，则贡献者可以终止其授予该下游被许可方的专利许可。
第 12 节：不得放弃他人的自由权
GPLv3 §12 与 GPLv2 §7 的功能相同。GPLv2 条款中所举的示例不仅没有将问题解释清楚，而且让人更加困惑，所以被删除了。从所有其他方面（包括合规结果）来看，两个版本中的这两个条款具有相同效果。有关详情，请参见上文。
第 13 节：与 GNU Affero 通用公共许可证一起使用
此节专门许可将 GPLv3 作品与 AGPLv3 作品相链接或相组合。下文将就 AGPLv3 讨论这一许可的合规结果。
组合后的作品整体适用 GPLv3 协议，但如果该作品是通过网络使用的，则应适用 AGPLv3 协议。
无论您多么喜欢 GPLv3，都不能依据 GPLv3 发布或修改 GNU AGPL 代码，反之亦然。但是，您可以将这两种许可证下的单独模块或源文件组合入同一个项目。
当 GPLv3 代码与 AGPL 代码通过链接形成组合作品后，每个许可证下的 Copyleft 义务不可扩展至另一方。也就是说，进行此类组合后，Affero 的许可义务只适用于引入组合作品的 Affero 代码部分。如果在收到此类组合作品后，不希望合规 Affero 的许可义务，则需要删除其中的 Affero 代码。