The GPL cooperation commitment and Red Hat projects

As of today, all new Red Hat-initiated open source projects that opt to use GPLv2 or LGPLv2.1 will be expected to supplement the license with the cure commitment language of GPLv3. The cure language will live in a file in the project source tree and will function as an additional permission extended to users from the start.

This is the latest development in an ongoing initiative within the open source community to promote predictability and stability in enforcement of GPL-family licenses. The “automatic termination” provision in GPLv2 and LGPLv2.x is often interpreted as terminating the license upon noncompliance without a grace period or other opportunity to correct the error in compliance. When the Free Software Foundation released GPLv2 in 1991, it held nearly all GPL-licensed copyrights, in part a consequence of the copyright assignment policy then in place for GNU project contributions. Long after the Linux kernel and many other non-GNU projects began to adopt the GPL and LGPL, the FSF was still the only copyright holder regularly engaged in license enforcement. Under those conditions, the automatic termination feature of GPLv2 section 4 may have seemed an appropriate means of encouraging license compliance.

By the mid-2000s the FSF had come to see the potential unfairness of automatic termination. Distribution of Linux-based products containing large numbers of GPL and LGPL-licensed components, under highly diverse copyright ownership, had become commonplace, and indeed was the cornerstone of Red Hat’s own business. Automatic license termination, as commonly understood in the community, meant that a single act of inadvertent non-compliance could, in theory, give rise to a large number of infringement claims, with no obligation on the part of copyright holders to notify the alleged violators prior to seeking legal recourse. With the publication of GPLv3 in 2007, the FSF introduced a modified termination policy that included mechanisms for license reinstatement where compliance errors were promptly fixed. But the large and ever-growing corpora of GPLv2 and LGPLv2.x-licensed code remained under the earlier approach. For some time, the FSF’s position was that developers and users concerned about this situation should upgrade to GPLv3 -- but that was not always possible or desirable.

In 2016 the FSF, along with the Software Freedom Conservancy, announced the Principles of Community-Oriented GPL Enforcement -- partly in response to tactics being employed by one litigant in the German courts. Among other things, the Principles call for extending GPLv3-style termination to GPLv2 works. By the end of 2017, over a hundred individual Linux kernel developers had signed on to a commitment advanced by the TAB to extend the GPLv3 cure provisions to all users of the kernel. Then, in a series of announcements, 10 major technology companies led by Red Hat (see November 2017 and March 2018 announcements) committed to extending the GPLv3 cure provisions to all their GPLv2, LGPLv2.1 and LGPLv2.0 code. Our new effort to promote adoption of the cure provisions directly by new Red Hat community projects takes this one step further.

We’ve also been working with existing Red Hat-led GPLv2/LGPLv2.1 projects to help them adopt the cure commitment. WildFly, GlusterFS and Pulp—providing core components of our JBoss Middleware, Red Hat Gluster Storage and Red Hat Satellite products—have done so. Some other projects we’ve been engaged with include Anaconda, Candlepin, Cockpit and Koji. If you maintain a GPLv2 or LGPLv2.x-licensed project, you may wish to adopt the cure commitment too. For now, you can do so by copying the text WildFly and GlusterFS are using; we anticipate that the standard commitment text for project use will be maintained in the GPL Cooperation Commitment repository hosted on GitHub.

You might wonder why Red Hat would bother to encourage adoption of the cure commitment on a project basis, given that we’ve already made our corporate commitment, or why we don’t just prohibit use of the v2 licenses in favor of their v3 successors or some non-copyleft alternative. This requires some understanding of Red Hat corporate culture.

License selection is a form of legal decision making, but for as long as I’ve been at Red Hat, engineers have been given significant discretion to choose licenses for the projects they maintain, within certain boundaries (for example, expectations to pick from a small set of widely-used, de facto standard licenses). This reflects not only our corporate traditions of developer empowerment, but also our view that engineers typically have the greatest competence to determine the appropriate license strategy for growing user and contributor communities around their projects. Earlier in Red Hat’s history, there was actually an expectation that our projects would be licensed under GPLv2, or LGPLv2.1 for libraries. While many Red Hat engineers continue to prefer these licenses, over the past several years growing numbers of Red Hat projects have been selecting GPLv3, the Apache License 2.0 and the MIT license. A prohibition on GPL-family licenses altogether might, unfortunately, be unworthy of comment in some other companies, but for Red Hat it would be unthinkable.

Because many Red Hat engineers continue to select GPLv2 or LGPLv2.1 for their projects, those projects over time are likely to incorporate contributions under those licenses from copyright holders other than Red Hat. That is largely because our projects use an “inbound=outbound” approach to contributions (increasingly along with the DCO). Were we to use asymmetrical contributor license agreements for our projects, as many other technology companies do, termination and enforcement of licenses by other copyright holders would be a non-issue for code specifically contributed to the project (though it would still be relevant for other third-party code copied into the project). But we have determined that the disadvantages of CLAs generally outweigh whatever benefits they are thought to have. For GPLv2 and LGPLv2.1 projects, then, adoption of the cure commitment at the outset will mean that all the GPL/LGPL license grants flowing into the project from contributions will be subject to the additional permission grant which the commitment represents.

We are extending the GPLv3 termination policy to users of our GPLv2/LGPLv2.1 code because we consider it the right thing to do. The cure permissions offer additional comfort that users of our code have reasonable assurances of quiet use of that code, even if there is a temporary license noncompliance by a third party redistributing our code, due to misunderstanding or otherwise. We also believe that community adoption of these rights will reduce the opportunity for illegitimate forms of license enforcement. We hope that others will also join in this endeavor to reassure the open source community that good faith efforts to fix noncompliance will be embraced