Emacs and the GPL

The Free Software Foundation (FSF) prides itself on being the champion of free software and its licensing, so a recent misstep with Emacs source code has to be a little embarrassing. But it is just that, a misstep, and one that was quickly addressed in two separate ways. While it may be tempting to lambaste the FSF and the Emacs developers for the oversight (and many have done so), it really should be seen as a lesson for projects and companies to be ever more vigilant regarding the licensing of their code. That may cause some to question whether complying with free software licenses is harder than it needs to be, but that would be ignoring the huge benefits that the GPL and free software bring to the table.

The problem stems from the inclusion of CEDET (a Collection of Emacs Development Environment Tools) into Emacs 23.2. CEDET has parsers for various languages that are based on Bison grammar files that get translated into Elisp (an Emacs dialect of Lisp). The grammar files were not included with Emacs 23.2 and 23.3, but, in addition, the Lisp output from the Bovine and Wisent parser generator tools used to do the translation had been hand-edited. That meant that even having the grammar files was insufficient to reproduce the Lisp code that got shipped with those versions of Emacs.

Needless to say, shipping code without providing source in the "preferred form of the work for making modifications" is not at all GPL-compliant. That's not really a legal issue for the Emacs project because the FSF owns the copyright to the code and is thus not required to follow the GPL. It certainly sets a bad precedent, however, and one that Richard Stallman and others wanted fixed in short order. That fix took two paths.

To start with, Chong Yidong created new versions of the two affected Emacs releases. Those included the grammar files and a script to apply the changes made to the Lisp output. That means that anyone distributing 23.2a or 23.3a would be in compliance with the GPL.

But that left those who had already distributed the earlier versions in a bit of a bind, as they were in technical non-compliance with the GPL for doing so. Stallman solved that problem with a grant of permission that essentially absolves those distributors of any copyright violation and "extends to versions with unrelated modifications, provided those versions comply with GNU GPL version 3 in all other respects". He also notes that the GPLv3 makes the process a little easier:

The version numbers aren't quite right in his explanation above (though they are in the grant), but his point is an interesting one. The GPLv3 has explicit language that reinstates the distribution right for violators if they cease the violation (which the permission grant effectively does) and aren't contacted by the copyright holder in 60 days. The picture for GPLv2 would have been a bit murkier because it lacked the automatic reinstatement of the license. Though, obviously, the FSF could have explicitly forgiven the earlier violations had Emacs been released under GPLv2.

Clearly Stallman is a stickler for adhering to the letter of the GPL—as he should be—and the problem was resolved less than a week after it came to his attention. The fact that it took more than a year for the problem to be recognized is unfortunate, but it stemmed from a misunderstanding about the "preferred form". It seems that Chong believed that the Lisp source code, which was distributed, was a reasonable interpretation of providing the source—which it is. Where it falls down, of course, is that it isn't the form that a programmer would want to use if they were to make modifications to CEDET.

There was some unhappiness expressed in the thread on emacs-devel regarding the coverage of the issue, specifically that which appeared at LWN. While there may have been some intemperate comments in the thread, it's a little strange to hear that coverage of the issue should have been out-of-bounds. As Stephen J. Turnbull points out, it's important for word to get out about the problem:

Turnbull's footnote notes that it is extremely unlikely that it would go that far, but his point is well taken. Whether one likes the coverage (and comments) or not, it is important for the word to get out to downstream distributors so that they can decide if they want to update to 23.2a or 23.3a. It would be well-nigh impossible for the project to find and contact all of the different distributors who have shipped the non-compliant code. The Linux and free software media have a role to play, though the coverage here and elsewhere still won't reach every downstream of course.

Turnbull also makes a larger point:

There is a cost associated with using free software, and complying with the license is the biggest part of that cost. Proprietary licenses have their costs as well, of course, and those can be partially measured in dollars. Complying with a thick stack of legalese in order to license some bit of proprietary code may seem easier, at least partly because companies are used to those kinds of licenses, but probably isn't. In the end, free software is an enormous bargain, in general, because the amount of work required to comply is far outweighed by the usefulness of the code. It may take a bit of a different mindset, but the value gained is enormous.

Beyond that, the GPL also provides a level playing field for contributors, so that individuals and companies can contribute to a common code base and know that no one has the upper hand. No one can take the code proprietary or make changes and distribute them without sharing those changes back. Copyright assignment (or licensing) may muddy the water to some extent, but, for many projects, the GPL provides the needed cover for competitors to collaborate.

In the end analysis, this was a minor problem that was addressed fairly quickly. The grammar files were always available at the CEDET site, and the handmade changes were pretty trivial overall. That said, it is important that it was found and fixed, not least because the FSF is the poster child for GPL compliance. The silver lining is that other projects are likely to remember this mistake and keep an eye out for similar problems in their own code. If suffering a little public embarrassment results in fewer GPL mistakes (and violations) down the road, the FSF's goals will have been well-served in the process.