去年，我错过了撰写关于 GNU 通用公共许可证第三版 GPLv3 发布十周年的文章的机会。GPLv3 由自由软件基金会 (FSF) 于 2007 年 6 月 29 日正式发布，在技术历史上更广为人知的是苹果发布 iPhone 的日子。一年后的今天，我觉得有必要对 GPLv3 进行一些回顾。对我来说，GPLv3 中许多有趣的地方都可以追溯到 11 年前，追溯到我积极参与的公开起草过程。
2005 年，在对自由软件充满热情地投入了近十年，但几乎没有开源法律经验的情况下，我受 Eben Moglen 聘请，加入软件自由法律中心担任律师。当时 SFLC 是 FSF 的外部律师，我的角色是专注于 GPLv3 起草过程的初期公开阶段。这个机会把我从之前一个让我颇为不满的职业转型中拯救了出来。自由和开源软件 (FOSS) 法律事务将成为我的新专长，我发现它非常有趣、令人满意并且在智力上有所回报。我在 SFLC 的工作，尤其是我在 GPLv3 方面的工作，就像一场烈火般的考验，成为了我的在职培训。
必须将 GPLv3 理解为 FOSS 早期的产物，其轮廓对于今天的一些人来说可能难以想象。到 2006 年公开起草过程开始时，Linux 和开源已不再像几年前的普通观察员那样，实际上是同义词，但这种联系比现在紧密得多。
反映了 Linux 已经对技术行业产生的深刻影响，每个人都认为 GPL 第 2 版是主要的开源许可模式。我们正在看到开源（和伪开源）商业模式寒武纪爆发的最终结局。一种由商业推动的泡沫般的炒作围绕着开源（对我来说，最令人难忘的是开源商业会议），这与当今软件工程行业对开源开发的拥抱几乎没有任何相似之处。微软及其不断扩大的专利组合以及对 Linux 的竞争性反对，在 FOSS 社区中普遍被视为一种生存威胁，并且围绕 Linux 和 GPL 的 SCO 诉讼 造成了法律风险的阴影，这种阴影尚未完全消散。
这种环境必然使 GPLv3 的起草成为一场高风险的事件，这在自由软件历史上是前所未有的。主要技术公司的律师和顶级律师事务所争夺对该许可证的影响力，他们确信 GPLv3 势必会接管并彻底重塑开源及其所有相关的巨额商业投资。
技术社区中也存在类似的想法；可以从 Linux 内核开发者 2006 年 9 月 谴责 GPLv3 的重大声明的最后一段中看出。我们这些接近 FSF 的人了解得更多一些，但我认为我们假设新许可证要么会取得压倒性的成功，要么会彻底失败——其中“成功”意味着现有 GPLv2 项目生态系统向 GPLv3 的近似升级，尽管可能不包括内核。实际结果介于两者之间。
我对尝试衡量开源许可证采用情况没有信心，近年来，这种尝试通常被用来证明 copyleft 许可的竞争优势丧失。我自己的经验，无可否认地因接近 Linux 和我在 Red Hat 的工作而扭曲，表明 GPLv3 作为 2007 年以来启动的项目的许可证选择，已经获得了适度的欢迎，尽管 2007 年之前存在的大多数 GPLv2 项目以及它们在 2007 年之后的衍生产品，仍然使用旧的许可证。（GPLv3 的兄弟许可证 LGPLv3 和 AGPLv3 从未获得类似的普及程度。）大多数现有的 GPLv2 项目（除了像内核和 Busybox 这样的一些著名例外）都被许可为“GPLv2 或任何更高版本”。技术社区很早就决定，“GPLv2 或更高版本”是一种政治中立的许可证选择，它同时包含了 GPLv2 和 GPLv3；这在一定程度上解释了为什么 GPLv3 的采用在某种程度上是渐进的和有限的，尤其是在 Linux 社区内。
在 GPLv3 的起草过程中，一些人表达了对“巴尔干化” Linux 生态系统的担忧，无论是由于用户必须理解两种不同的强 copyleft 许可证的开销，还是由于 GPLv2/GPLv3 不兼容。这些担忧最终被证明是完全没有根据的。在主流服务器和工作站 Linux 堆栈中，这两种许可证已经和平共存了十年。这部分是因为这些堆栈是由单独的强 copyleft 范围单元组成的（请参阅我在容器设置中相关问题的讨论）。至于强 copyleft 范围单元内部的不兼容性，在这里，技术社区也认为“GPLv2 或更高版本”巧妙地解决了理论问题，尽管实际上几乎从未发生过将 GPLv2-or-later 名义升级到 GPLv3 的情况。
我已经提到了一些我们 FOSS 许可证极客对所谓的 copyleft 衰落所带来的焦虑。早在公开起草过程开始时，GPLv3 就受到了批评家的抨击，并且一些人，可以预见的是，将 GPLv3 特别与 GPL 或 copyleft 的不受欢迎联系起来。
我对此的看法略有不同：很大程度上由于其复杂性和巴洛克风格，GPLv3 错失了一个机会，无法创建一个强大的 copyleft 许可证，该许可证将广泛地吸引现代个人软件作者和公司许可方。我认为，当今的个人开发者倾向于选择简短、简单、易于理解的、最小化的许可证，其中最明显的例子是 MIT 许可证。
围绕开源许可证选择的一些公司决策者可能自然地持有这种观点，而另一些人可能认为 GPLv3 的某些部分，例如专利条款或反锁定要求，风险太大或与他们的商业模式不兼容。最大的讽刺是，GPLv3 未能吸引这些群体的特性在某种程度上是由于有意识地尝试使该许可证吸引这些相同的利益。
GPLv3 是如何变得如此巴洛克的？正如我所说，GPLv3 是早期时代的产物，在那个时代，FOSS 许可证被视为项目治理的主要工具。（今天，我们倾向于将治理与其他类型的法律或准法律工具联系起来，例如非营利组织的结构、项目决策的规则、行为准则和贡献者协议。）
GPLv3 在起草过程中，是 FOSS 许可证作为私有监管的雄心勃勃手段的乐观观点的最高点。GPLv2 已经如此，但 GPLv3 通过详细解决许多新的政策问题（软件专利、反规避法律、设备锁定）进一步推进了这一点。正如 FSF 和 SFLC 在第一个 GPLv3 基本原理文件中道歉的那样，这注定会使该许可证比 GPLv2 更长、更复杂。
但是在 GPLv3 的起草过程中，许多其他因素无意中导致了许可证的复杂性增加。代表供应商和商业用户利益的律师从法律和商业的角度提出了有用的改进建议，但是这些建议通常以使简单措辞的条款更加冗长为形式，这可以说并没有明显提高清晰度。对来自技术社区的反馈的响应，通常会识别许可证条款中的漏洞，也产生了类似的效果。
GPLv3 的起草者还因 2006 年有争议的 微软/Novell 协议而卷入了一场短期政治危机，导致在许可证的专利部分永久添加了新的和不寻常的条件，除了使有良知的专利持有供应商更难遵守许可证之外，这在 2007 年之后可以说几乎没有任何作用。当然，GPLv3 中的某些复杂性仅仅是出于良好意图的尝试，以使合规更容易，特别是对于社区项目开发者，或者对 FSF 的解释实践进行编纂。最后，人们可以对 GPLv3 中使用的语言风格提出异议，其中大部分具有对传统软件许可证法律术语的俏皮模仿或嘲弄的性质；在许多情况下，更简单、更直接的措辞形式将会是一种改进。
GPLv3 的复杂性以及在许可证起草和非雄心勃勃的许可证政策目标方面倾向于简洁和简单的趋势，意味着 GPLv3 的实质性文本对后来的 FOSS 法律起草几乎没有直接影响。但是，正如我在 2012 年惊讶和 高兴地指出的那样，MPL 2.0 采用了 GPLv3 的两个部分：来自 GPLv3 终止条款的 30 天补救期和 60 天冷静期语言，以及下游升级到更高许可证版本不会给上游许可方增加任何新义务的保证。
GPLv3的补救条款已经产生了重大影响，尤其是在过去一年。在软件自由保护协会（Software Freedom Conservancy）在FSF的支持下发布了《面向社区的GPL执行原则》之后，该原则呼吁将GPLv3的补救机会扩展到GPLv2的违规行为。随后，Linux基金会技术咨询委员会发布了一份声明，该声明得到了数百名Linux内核开发人员的认可，并逐字纳入了GPLv3的补救条款。紧随其后的是红帽主导的一系列公司承诺，将GPLv3的补救条款扩展到GPLv2和LGPLv2.x的违规行为，并开展了一项活动，以争取个人开源开发者做出同样的承诺，以及红帽宣布，今后其主导的GPLv2和LGPLv2.x项目将在项目仓库中直接使用该承诺语言。我在最近的博客文章中讨论了这些进展。
GPLv3的一个持久贡献是改变了人们对广泛使用的FOSS许可证修订方式的期望。在没有社区评论的机会，也没有努力咨询主要利益相关者的情况下，完全私下修订此类许可证的做法已不再被接受。MPL 2.0以及最近的EPL 2.0的起草反映了这一新规范。
评论已关闭。