Posted by Matt Jacobs on November 12, 2018
Many contracts contain language saying that if the licensee breaches/violates the license, the licensee will have an opportunity to cure that breach. But the GPLv2 provides no right to cure.
Many contracts, either in their boilerplate form or as part of the negotiated give and take, contain some language that says that if the licensee breaches/violates the license, the licensee will be afforded some opportunity to cure that breach (depending, naturally, on the severity of the breach). Without a valid license from the copyright holder (the licensor), the licensee is using something without the right to do so and is engaging in copyright infringement. With copyright infringement comes the potential for statutory damages and other remedies, so that is a bad place for the licensee to be. Accordingly, reasonable cure provisions are key to giving a licensee comfort that in the case of an inadvertent breach, the licensee won’t find their license immediately revoked.
The GPLv2 has no cure provision, and it is not the kind of license that you can negotiate such provisions into. You take the GPLv2 license as is. If you breach, even by failing to do something easy to fix—such as including a written offer to make the corresponding source code available (if you don’t already provide the source code)—then you have violated the license, and you are in copyright infringement territory immediately.
The business community has struggled since the very beginning to warm up to GPLv2. This comes, in part, from the fact that to err is human and mistakes happen. The notion that the right to use code licensed under the GPLv2 is terminated owing to an inadvertent breach, with no opportunity to cure, is perceived by many as not being a “commercially reasonable” risk to assume.
However, tension arises because simply staying clear of the GPLv2 is really not possible for many tech enterprises. This is because Linux is, and forever will be, licensed exclusively under the GPLv2. Linux is relied on by many, many enterprises and is a major tech driver. The importance of Linux to so much of everything we do and touch can’t be understated.
Patrick McHardy, the now infamous copyright troll, was the final straw. A potentially frightening aspect of the GNU Linux operating system is that each contributor to it technically retains ownership of their contribution, no matter how small. Other open source projects operate under contributor agreements whereby those who want to contribute to a project essentially assign over their rights to the project and the project then controls the copyright. Not so with Linux, where each contributor (and there may be thousands) still owns their copyright and licenses their tiny piece of the pie under the GPLv2 consistent with how Linux is licensed. Hence, if some third party is infringing, arguably each one of those many contributors has at least a theoretical right (standing) to sue for breach.
In the case of McHardy, he claimed that no one else in the community was stepping up to stop breaches, so he took the lead. Most would agree he did this strictly for his own financial gain. And the GPL violations that he is going after are what some experts have called “foot fouls,” equating them to very minor infractions in sports. They’re easy to fix, but technical violations. Allowing an opportunity to fix these minor fouls will go a long way to putting a stake in the heart of this troll.
It is worth noting that the drafters of the GPLv3 did include a provision expressly including a mechanism for breaches to be addressed and potentially cured. Again, this doesn’t address the Linux problem since Linux is licensed only under GPLv2.
To curtail further McHardy-style actions, many companies have joined the GPL Cooperation Commitment. Committers to this program agree to apply the cure provision found in GPLv3 to GPLv2-licensed code. Applying a right to cure is an important step in offering users of Linux and other code licensed under the GPLv2 valuable certainty and comfort that will no doubt encourage further adoption and use of this code.
Get the latest Software Integrity news, thought leadership, and more.