内部人员爆料 GPL v3 起草过程
GPL

> 
> 在 GPL v3 许可证颁发 11 周年之际，让我们了解一下它对自由和开源软件的持久贡献。
> 
> 
> 


![](/data/attachment/album/201807/20/171454hz21p1npqzbx4o88.jpg)


2017 年，我错过了为 [GPL v3（GNU 通用公共许可协议的第三版）](https://www.gnu.org/licenses/gpl-3.0.en.html)发布 10 周年撰写文章的机会。GPL v3 由<ruby> 自由软件基金会 <rp>  （ </rp> <rt>  Free Software Foundation </rt> <rp>  ） </rp></ruby>（FSF）于 2007 年 6 月 29 日正式发布，这一天在技术史上更为人熟知的事件是苹果公司推出了 iPhone 手机。一年之后的现在，我觉得应该对 GPL v3 做一些回顾。对于我来说，许多有关 GPL v3 的有趣内容可以追溯到 11 年之前，我作为积极参与者经历了当时的公共起草过程。


2005 年，经过近十年热衷于自由软件的自我沉浸，但却几乎没有任何开源法律经验可言的我被 Eben Moglen 聘用，加入<ruby> 软件自由法律中心 <rp>  （ </rp> <rt>  Software Freedom Law Center </rt> <rp>  ） </rp></ruby>（SFLC）担任法律顾问。SFLC 当时是 FSF 的外部法律顾问，我的角色被设定为关注 GPL v3 起草过程的初期公共阶段。这个机会把我从以前的并不令我满意的一次职业转变中解救出来。<ruby> 自由和开源软件 <rp>  （ </rp> <rt>  Free and Open Source Software </rt> <rp>  ） </rp></ruby>（FOSS）的法律问题成为我的新专长，我发现这一点很有吸引力，令人满意，并且在智力上有所回报。我在 SFLC 的工作，特别是我在 GPL v3 方面勇闯火线的工作，成为了我的在职培训。


GPL v3 必须被理解为早期 FOSS 时代的产物，其轮廓可能让今天的人难以想象。在 2006 年公共起草过程开始时，Linux 和开源已经不再是早年一些漫不经心的观察者所看到的几乎是同义词的情形了，但两者之间的联系仍然比现在更密切。


Linux 已经对技术行业产生深远影响的反映是，每个人都认为 GPL v2 是主要的开源许可模式。我们看到了开源（和伪开源）商业模式如寒武纪式爆发的最终震荡。一个泡沫化商业炒作包围的开源（对我来说最令人难忘的典型代表是<ruby> 开源商业会议 <rp>  （ </rp> <rt>  Open Source Business Conference </rt></ruby>）与软件工程专业人士目前对开源开发的接受程度几乎没有相似之处。微软凭借其不断扩大的专利组合以及对 Linux 的竞争性对抗，在 FOSS 社区中普遍被视为一种现实存在的威胁，而 [SCO 诉讼](https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes)已经在 Linux 和 GPL 之间笼罩上了法律风险的阴云，并且没有完全消散。


这种环境必然使得 GPL v3 的起草成为自由软件历史上前所未有的高风险事件。主要的技术公司和顶级律师事务所的律师争先恐后地对该许可协议施加影响，并确信 GPL v3 必将接管并彻底重塑开源业态及所有大量相关的商业投资。


技术社区内存在类似的心态；这在 Linux 内核开发人员于 2006 年 9 月对 GPL v3 的[强烈指责]( https://lwn.net/Articles/200422/)中所表达的恐惧里略见一斑。我们这些接近 FSF 的人知道的多一点，但我认为我们假定新的许可协议要么是压倒性的成功，要么是彻底的失败——“成功”意味着将现有的 GPL v2 项目生态系统升级为 GPL v3，尽管也许 Linux 内核会缺席（LCTT 译注：十年过去了，Linux 内核仍旧采用 GPL v2 许可证）。实际的结果是介于两者之间的东西。


我对测量开源许可协议采用程度的尝试没有信心，近年来这种做法通常用于证明<ruby> 左版 <rp>  （ </rp> <rt>  Copyleft </rt> <rp>  ） </rp></ruby>许可协议失去竞争优势。根据我自己的接近 Linux 和工作于<ruby> 红帽 <rp>  （ </rp> <rt>  Red Hat </rt> <rp>  ） </rp></ruby>公司的明显有倾向性的经验，表明 GPL v3 作为自 2007 年以来推出项目的可选许可协议，享有适度的受欢迎程度。尽管 2007 年之前存在的大多数 GPL v2 项目以及它们在 2007 年以后的分支，仍然遵循旧许可协议。（GPL v3 的兄弟许可协议 LGPL v3 和 AGPL v3 从未获得过相当程度的普及）大多数现有的 GPL v2 项目（有一些明显的例外，如 Linux 内核和 Busybox）被许可为“GPL v2 或任何更高的版本”。技术界早就决定“GPL v2 或更高版本”是一个政治中立的许可协议选项，它包含了 GPL v2 和 GPL v3。这可以解释为什么 GPL v3 的采用推进得缓慢和有限，特别是在 Linux 社区中。


在 GPL v3 起草过程中，一些人表达了对 Linux 生态系统“<ruby> 巴尔干化 <rp>  （ </rp> <rt>  balkanized </rt> <rp>  ） </rp></ruby>”的担忧，无论是因为用户必须了解两个不同的强大左版许可协议的开销，还是因为 GPL v2 / GPL v3 的不兼容。事实证明，这些担忧完全没有根据。在主流服务器和工作站 Linux 堆栈中，这两个许可协议已经和平共存了十年。这其中部分是因为这样的堆栈由强大的左版范畴的单独单元组成（参见我对[容器设置中相关问题](/article-9316-1.html)的讨论）。至于强左版范畴单元内部的不兼容性，在这里，“GPL v2 或更高版本”的普遍性被技术界视为干净利索地解决了理论问题。尽管名义上的“GPL v2 或更高版本”升级为 GPL v3 的情况几乎没有发生过。


我已经说过，我们中间的一些 FOSS 许可协议极客已经提到了假定的左版衰退的问题。早在公共起草过程的开始阶段，GPL v3 已经在批评者那里形成了滥用，并且可以推断，有些人已经在特殊情况下的 GPL v3 不受欢迎与一般意义上的 GPL 或左版失宠之间建立了联系。


我对它的看法有所不同：很大程度上是因为它的复杂性和<ruby> 巴洛克 <rp>  （ </rp> <rt>  baroque </rt> <rp>  ） </rp></ruby>风格，GPL v3 失去了创建强大的可以广泛地吸引现代个人软件作者和企业许可人的左版许可协议的机会。我相信今天的个人开发者往往更喜欢简短、易懂、简约的许可证，最明显的例子就是 [MIT 许可证](https://opensource.org/licenses/MIT)。


面临开源许可协议选项的一些公司决策者可能很自然地分享这种观点，而其他公司决策者可能认为 GPL v3 的某些部分风险太大（例如专利条款或反锁定要求）或与其商业模式不相容。具有讽刺意味的是，未能吸引这些群体的 GPL v3 的一部分特性是因为有意识地试图使许可协议吸引这些具备相同类型利益的群体。


GPL v3 是如何变得如此巴洛克式的？正如我所说，GPL v3 是较早时期的产物，彼时 FOSS 许可协议被视为项目治理的主要工具。（现在我们倾向于将治理与其他类型的法律或准法律工具联系起来，例如组织非营利组织，围绕项目决策制定规则，行为准则和贡献者协议。）


在其起草过程中，GPL v3 是对 FOSS 许可协议可以作为雄心勃勃的私人监管手段持乐观态度的最高点。对于 GPL v2 来说已经是这样了，但是 GPL v3 通过详细解决一些新的政策问题——软件专利、反规避法律、设备锁定等方式来解决问题。这必然会使 GPL v3 许可协议比 GPL v2 更长、更复杂，因为 FSF 和 SFLC 在第一份 GPL v3 [基本原理文件](http://gplv3.fsf.org/gpl-rationale-2006-01-16.html)中满怀抱歉地提到了这一点。


但是，起草 GPL v3 过程中的其他一些因素无意中导致许可协议的复杂性增长。代表供应商和商业用户利益的律师从法律和商业角度提供了有用的改进建议，但这些通常采取让措辞简单的条款变成更冗长的形式，在明晰性方面可以说没有明确的改善。对技术社区反馈（通常是识别许可条款的漏洞）的回应也有类似的效果。


GPL v3 起草人也因短期政治危机（2006 年有争议的[微软/ Novell 交易](https://en.wikipedia.org/wiki/Novell#Agreement_with_Microsoft)）纠缠在一起，导致许可协议的专利部分永久性地增加了新的和不寻常的条件，这在 2007 年之后是毫无用处的, 除了使有良心的专利持有商更难遵守许可证。当然，GPL v3 中的一些复杂性仅仅是为了使合规更容易（特别是对于社区项目开发人员）或者编写 FSF 的解释实践。最后，人们可以对 GPL v3 中使用的语言风格提出质疑，其中大部分语言都具有传统软件许可法律的顽皮模仿或嘲弄；在许多情况下，一种更简单、直接的措辞形式是一种改进。


GPL v3 的复杂性以及在许可协议起草中倾向于简练和简洁的趋势以及明智的许可政策目标，意味着 GPL v3 的实质性文本对后来的 FOSS 法律起草几乎没有直接影响。但是，正如我在 2012 年所惊奇和[高兴](https://opensource.com/law/12/1/the-new-mpl)地看到的那样，MPL 2.0 改编了 GPL v3 的两个部分：GPL v3 终止条款中的 30 天补救和 60 天休眠文本，并保证升级到更高版本许可协议的下游对上游许可人没有新的义务。


GPL v3 补救文本已经产生了重大影响，特别是在过去一年中。随着 FSF 的支持，<ruby> 软件自由保护组织 <rp>  （ </rp> <rt>  Software Freedom Conservancy </rt> <rp>  ） </rp></ruby>颁布了《<ruby> <a href="https://sfconservancy.org/copyleft-compliance/principles.html">  面向社区的 GPL 执行原则 </a> <rp>  （ </rp> <rt>  Principles of Community-Oriented GPL Enforcement </rt> <rp>  ） </rp></ruby>》，该原则要求将 GPL v3 补救机会扩展到 GPL v2 违规行为，Linux 基金会技术顾问委员会发布了一份[声明](https://www.kernel.org/doc/html/v4.16/process/kernel-enforcement-statement.html)，得到了一百多个 Linux 内核开发人员支持，其中包含了 GPL v3 的补救文本。接下来是以红帽公司为首的一系列[企业承诺](https://www.redhat.com/en/about/press-releases/technology-industry-leaders-join-forces-increase-predictability-open-source-licensing)，将 GPL v3 补救条款扩展到 GPL v2 和 LGPL v2.x 违规，这是一项建议个人开源开发者做出同样承诺的活动。红帽公司的一项声明宣布，从此以后其主导的 GPL v2 和 LGPL v2.x 项目将在项目存储库中直接使用承诺文本。我在最近的[博客文章](https://www.redhat.com/en/blog/gpl-cooperation-commitment-and-red-hat-projects?source=author&term=26851)中讨论了这些发展。


关注 GPL v3 的一个持久贡献是改变了对广泛使用的 FOSS 许可协议修订方式的期待。在没有社区评论的参与，也没有努力与主要利益相关者进行磋商的情况下，这些许可协议不能完全进行私下修改。MPL 2.0 以及最近的 EPL 2.0 的起草过程反映了这一新规范。




---


作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。


译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。


![](/data/attachment/album/201807/20/171157gqkgilhpbpgbp4hm.jpg)


OK
Last year, I missed the opportunity to write about the 10th anniversary of [GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html), the third version of the GNU General Public License. GPLv3 was officially released by the Free Software Foundation (FSF) on June 29, 2007—better known in technology history as the date Apple launched the iPhone. Now, one year later, I feel some retrospection on GPLv3 is due. For me, much of what is interesting about GPLv3 goes back somewhat further than 11 years, to the public drafting process in which I was an active participant.

In 2005, following nearly a decade of enthusiastic self-immersion in free software, yet having had little open source legal experience to speak of, I was hired by Eben Moglen to join the Software Freedom Law Center as counsel. SFLC was then outside counsel to the FSF, and my role was conceived as focusing on the incipient public phase of the GPLv3 drafting process. This opportunity rescued me from a previous career turn that I had found rather dissatisfying. Free and open source software (FOSS) legal matters would come to be my new specialty, one that I found fascinating, gratifying, and intellectually rewarding. My work at SFLC, and particularly the trial by fire that was my work on GPLv3, served as my on-the-job training.

GPLv3 must be understood as the product of an earlier era of FOSS, the contours of which may be difficult for some to imagine today. By the beginning of the public drafting process in 2006, Linux and open source were no longer practically synonymous, as they might have been for casual observers several years earlier, but the connection was much closer than it is now.

Reflecting the profound impact that Linux was already having on the technology industry, everyone assumed GPL version 2 was the dominant open source licensing model. We were seeing the final shakeout of a Cambrian explosion of open source (and pseudo-open source) business models. A frothy business-fueled hype surrounded open source (for me most memorably typified by the Open Source Business Conference) that bears little resemblance to the present-day embrace of open source development by the software engineering profession. Microsoft, with its expanding patent portfolio and its competitive opposition to Linux, was commonly seen in the FOSS community as an existential threat, and the [SCO litigation](https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes) had created a cloud of legal risk around Linux and the GPL that had not quite dissipated.

That environment necessarily made the drafting of GPLv3 a high-stakes affair, unprecedented in free software history. Lawyers at major technology companies and top law firms scrambled for influence over the license, convinced that GPLv3 was bound to take over and thoroughly reshape open source and all its massive associated business investment.

A similar mindset existed within the technical community; it can be detected in the fears expressed in the final paragraph of the Linux kernel developers' momentous September 2006 [denunciation](https://lwn.net/Articles/200422/) of GPLv3. Those of us close to the FSF knew a little better, but I think we assumed the new license would be either an overwhelming success or a resounding failure—where "success" meant something approximating an upgrade of the existing GPLv2 project ecosystem to GPLv3, though perhaps without the kernel. The actual outcome was something in the middle.

I have no confidence in attempts to measure open source license adoption, which have in recent years typically been used to demonstrate a loss of competitive advantage for copyleft licensing. My own experience, which is admittedly distorted by proximity to Linux and my work at Red Hat, suggests that GPLv3 has enjoyed moderate popularity as a license choice for projects launched since 2007, though most GPLv2 projects that existed before 2007, along with their post-2007 offshoots, remained on the old license. (GPLv3's sibling licenses LGPLv3 and AGPLv3 never gained comparable popularity.) Most of the existing GPLv2 projects (with a few notable exceptions like the kernel and Busybox) were licensed as "GPLv2 or any later version." The technical community decided early on that "GPLv2 or later" was a politically neutral license choice that embraced both GPLv2 and GPLv3; this goes some way to explain why adoption of GPLv3 was somewhat gradual and limited, especially within the Linux community.

During the GPLv3 drafting process, some expressed concerns about a "balkanized" Linux ecosystem, whether because of the overhead of users having to understand two different, strong copyleft licenses or because of GPLv2/GPLv3 incompatibility. These fears turned out to be entirely unfounded. Within mainstream server and workstation Linux stacks, the two licenses have peacefully coexisted for a decade now. This is partly because such stacks are made up of separate units of strong copyleft scope (see my discussion of [related issues in the container setting](https://opensource.com/article/18/1/containers-gpl-and-copyleft)). As for incompatibility inside units of strong copyleft scope, here, too, the prevalence of "GPLv2 or later" was seen by the technical community as neatly resolving the theoretical problem, despite the fact that nominal license upgrading of GPLv2-or-later to GPLv3 hardly ever occurred.

I have alluded to the handwringing that some of us FOSS license geeks have brought to the topic of supposed copyleft decline. GPLv3 has taken its share of abuse from critics as far back as the beginning of the public drafting process, and some, predictably, have drawn a link between GPLv3 in particular and GPL or copyleft disfavor in general.

I have viewed it somewhat differently: Largely because of its complexity and baroqueness, GPLv3 was a lost opportunity to create a strong copyleft license that would appeal very broadly to modern individual software authors and corporate licensors. I believe individual developers today tend to prefer short, simple, easy to understand, minimalist licenses, the most obvious example of which is the [MIT License](https://opensource.org/licenses/MIT).

Some corporate decisionmakers around open source license selection may naturally share that view, while others may associate some parts of GPLv3, such as the patent provisions or the anti-lockdown requirements, as too risky or incompatible with their business models. The great irony is that the characteristics of GPLv3 that fail to attract these groups are there in part because of conscious attempts to make the license appeal to these same sorts of interests.

How did GPLv3 come to be so baroque? As I have said, GPLv3 was the product of an earlier time, in which FOSS licenses were viewed as the primary instruments of project governance. (Today, we tend to associate governance with other kinds of legal or quasi-legal tools, such as structuring of nonprofit organizations, rules around project decision making, codes of conduct, and contributor agreements.)

GPLv3, in its drafting, was the high point of an optimistic view of FOSS licenses as ambitious means of private regulation. This was already true of GPLv2, but GPLv3 took things further by addressing in detail a number of new policy problems—software patents, anti-circumvention laws, device lockdown. That was bound to make the license longer and more complex than GPLv2, as the FSF and SFLC noted apologetically in the first GPLv3 [rationale document](http://gplv3.fsf.org/gpl-rationale-2006-01-16.html).

But a number of other factors at play in the drafting of GPLv3 unintentionally caused the complexity of the license to grow. Lawyers representing vendors' and commercial users' interests provided useful suggestions for improvements from a legal and commercial perspective, but these often took the form of making simply worded provisions more verbose, arguably without net increases in clarity. Responses to feedback from the technical community, typically identifying loopholes in license provisions, had a similar effect.

The GPLv3 drafters also famously got entangled in a short-term political crisis—the controversial [Microsoft/Novell deal](https://en.wikipedia.org/wiki/Novell#Agreement_with_Microsoft) of 2006—resulting in the permanent addition of new and unusual conditions in the patent section of the license, which arguably served little purpose after 2007 other than to make license compliance harder for conscientious patent-holding vendors. Of course, some of the complexity in GPLv3 was simply the product of well-intended attempts to make compliance easier, especially for community project developers, or to codify FSF interpretive practice. Finally, one can take issue with the style of language used in GPLv3, much of which had a quality of playful parody or mockery of conventional software license legalese; a simpler, straightforward form of phrasing would in many cases have been an improvement.

The complexity of GPLv3 and the movement towards preferring brevity and simplicity in license drafting and unambitious license policy objectives meant that the substantive text of GPLv3 would have little direct influence on later FOSS legal drafting. But, as I noted with surprise and [delight](https://opensource.com/law/12/1/the-new-mpl) back in 2012, MPL 2.0 adapted two parts of GPLv3: the 30-day cure and 60-day repose language from the GPLv3 termination provision, and the assurance that downstream upgrading to a later license version adds no new obligations on upstream licensors.

The GPLv3 cure language has come to have a major impact, particularly over the past year. Following the Software Freedom Conservancy's promulgation, with the FSF's support, of the [Principles of Community-Oriented GPL Enforcement](https://sfconservancy.org/copyleft-compliance/principles.html), which calls for extending GPLv3 cure opportunities to GPLv2 violations, the Linux Foundation Technical Advisory Board published a [statement](https://www.kernel.org/doc/html/v4.16/process/kernel-enforcement-statement.html), endorsed by over a hundred Linux kernel developers, which incorporates verbatim the cure language of GPLv3. This in turn was followed by a Red Hat-led series of [corporate commitments](https://www.redhat.com/en/about/press-releases/technology-industry-leaders-join-forces-increase-predictability-open-source-licensing) to extend the GPLv3 cure provisions to GPLv2 and LGPLv2.x noncompliance, a campaign to get individual open source developers to extend the same commitment, and an announcement by Red Hat that henceforth GPLv2 and LGPLv2.x projects it leads will use the commitment language directly in project repositories. I discussed these developments in a recent [blog post](https://www.redhat.com/en/blog/gpl-cooperation-commitment-and-red-hat-projects?source=author&term=26851).

One lasting contribution of GPLv3 concerns changed expectations for how revisions of widely-used FOSS licenses are done. It is no longer acceptable for such licenses to be revised entirely in private, without opportunity for comment from the community and without efforts to consult key stakeholders. The drafting of MPL 2.0 and, more recently, EPL 2.0 reflects this new norm.

## Comments are closed.