This post is Part 2 of a two part blog post, Part 1 of which was titled “The Dark Practice of Free & Open Source Software Law.”
In April, I attended Free Software Foundation Europe’s Legal and Licensing Workshop in Barcelona, the world’s largest and probably most important gathering of open source attorneys. One of the presentations at the conference was about the GPL Cooperation Commitment and was presented by a number of companies who had entered into the Commitment. More can be read about the Commitment here, but in summary, the Commitment is as follows: a number of companies promised that if they enforce compliance with the GPL 2, they will give the non-compliant entity a 30 day cure period to come into compliance before terminating the license. In other words, they’re promising to treat GPL 2 enforcement just like the GPL 3, which has an explicit 30 day cure provision that the GPL 2 lacks.
On the face of it, this is a good step forward because it allows people to use the GPL 2 without fear of instantly and possibly irrevocably losing their license. This, the theory goes, encourages more companies to use the GPL 2, and perhaps to participate in and contribute to the open source ecosystem. It also underscores the view that enforcement should be about obtaining compliance, rather than using enforcement as a way to attack competitors or eke out monetary damages.
At first glance, I was on board with this seemingly benign and frankly, somewhat boring, “innovation.” I say that because 30 days is really not enough time for anyone to get GPL compliant given the product release cycle (a point the presenters openly conceded) and many of the companies signing on to the commitment either don’t produce much GPL’ed code (I’m looking at you, Etsy) or have no incentive to enforce the GPL. So, to the extent the Commitment has any impact at all, that impact is fairly marginal. But, then the presenters started to discuss future projects where they hoped to “document existing norms and establish new ones.” An audience member suggested that maybe there should also be a “commitment” around the idea that source code doesn’t actually have to be delivered with the GPL’ed software; it would be acceptable to simply post a link to it and point requesters to the same. Other suggestions came rolling in for other “commitments” that would essentially update or upgrade the GPL 2 to more closely match industry practice and modern technologies.
But the problem with the GPL Cooperation Commitment and other suggested “commitments” is that it makes the practice of open source law even more opaque than it already is. As I wrote in Part 1 of this blog series, understanding how an open source license should be applied in any particular situation requires a multilayer analysis that goes well beyond the text of the license itself.
With respect to the GPL in particular, one would have to understand the open source movement, one would have to understand the tome which we call the GPL 2, one would have to know what parts of software package were GPL 2 (and which parts are “GPL 2 only” v. “GPL 2 or later”) and if any exceptions applied, one would have to know what programming languages were involved and what the software architecture looked like, one would have to know whether they’re dealing in user space or kernel space and/or what connection there was between the two, one would have to read the GPL FAQ, one would have to know who the relevant copyright holder(s) are and what their intentions might be, and a number of other disparate sources on the GPL and its application, depending on the exact scenario they’re trying to analyze. In some cases, companies even post additional terms on their websites intended to convey their own, idiosyncratic interpretation of the GPL. Many GPL-related analyses that are widely accepted across the open source community, are based on nothing more formal or authoritative than an email from Linus Torvalds.
With the GPL Cooperation Agreement, one must not only know all of the above to do a complete analysis of GPL compliance, but now they also have to look at a list of Commitment participants on a random Github page to understand the applicable termination provision for the package they’re analyzing. A list that, by the way, isn’t acknowledged anywhere in the package itself. You just have to know it’s out there.
And it gets worse, because a project can have multiple copyright owners capable of enforcing the GPL, some of whom have signed onto the Commitment and some of whom haven’t. So now, if the Commitment actually matters to you and might be a consideration in your decision-making (the goal of the Commitment, right?) you actually need to know all the contributors to a particular project before you really know what the applicable termination provision to the project is. This is notoriously hard since contributors don’t necessarily mark their code with their copyright notices, not all projects track their contributors, and even when they do, it may not be clear if the contribution was really by the individual listed or their employer or whether the copyright in that contribution has been assigned to someone else (e.g. one company bought another) since the contribution was memorialized. Now imagine there are multiple “commitments” like this and companies who signed onto one of them may or may not sign onto the others.
This yields a dream scenario for open source compliance attorneys who will now bill more hours completing their work and open source compliance software vendors, but a nightmare for companies just trying to do their best to comply with their open source license obligations. It also makes it that much harder for new attorneys to master this field of law. It’s a move that cements incumbent advantage for existing open source attorneys and existing tech companies, profitable and sophisticated enough to deal with an additional layer of compliance complexity that can only really be dealt with by investing money and time into automated compliance systems. It reeks to me of an anticompetitive move under the guise of open source altruism.
As a community, we should be trying to make open source compliance easier, not harder. Our goal should be to make open source licenses easily understandable to the people using them. We should be writing new licenses that fix the errors of old licenses, clarify ambiguities, and clearly spell out all the “hidden” understandings that experts divulge for a fee. In particular, the fact that it was necessary to invent the “Commitment” hack is a sign that it’s time to write new licenses that can easily be upgraded over time. After all, the Commitment was necessary because Linux is under “GPL 2,” not “GPL 2 or later,” meaning that it’s impossible to move Linux to GPL 3 without getting permission from every Linux contributor to do so since presumably they made their contributions under GPL 2 as well. It’s also a sign that we should think a lot harder about the terms under which projects accept contributions (like Developer Certificates of Origin or Contributor License Agreements) and perhaps accept that promising contributors that the license of a project will never change might be detrimental to the long-term success of open source in general if it means that fundamental technologies like Linux remain under stone age licenses and force many Linux-adjacent technologies to also live under outdated licenses in order to maintain license compatibility.
These are undoubtedly large issues to tackle, but necessary ones as the open source movement matures and we need a wider perspective that encompasses a license’s entire lifecycle and the inevitable changes the future will necessitate because of new laws, new legal interpretations, and new technologies. The open source legal community should set its sights on these larger issues rather than putting their fingers in the dike. It’s not sustainable to keep using the same old licenses and letting a self-selected group of companies declare they mean something that they don’t at their whim. That’s a path for turning the GPL 2 into a religious text instead of a legal document.
