One of the goals of the Software Freedom Law Center (SFLC) is to become a center for education in free and open source software (FOSS) legal issues. As part of this effort, the SFLC has already published "A Legal Issues Primer for Open Source and Free Software Projects." Its latest effort in public education, released last week, is "A Practical Guide to GPL Compliance," a 15-page guide for FOSS projects on how to avoid violations of the GNU General Public License (GPL) and Lesser General Public License (LGPL). The guide is a practical summary of its subject, but its wording is unnecessarily legalistic, and its structure and omissions sometimes fall short of the goal of being a standalone reference.
The guide begins with a history of GPL enforcement, emphasizing the Free Software Foundation's compliance lab and Harald Welte's gpl-violations.org, as well as the SFLC's growing role over the last two years. Most violations, the guide stresses, are resolved "privately via cooperative communications with violators" -- an approach (although the guide does not say so) that is partly due to the organization's wish to avoid the expenses of litigation, but which also emphasizes that the point is compliance, not damages.
After this background, the guide plunges into best practices to avoid violations. The most common violations, it suggests, come from full operating systems with GPL or LGPL components in original or modified versions. To prevent such violations, the guide urges projects monitor the use of FOSS, and carefully monitor what source is used to build which binaries. It also suggests avoiding the rise of "build gurus" -- a dependency on one or two people who know all the details of the project, and who can cause chaos when they leave, taking their knowledge with them.
The next section describes different ways of meeting the licenses' obligation to provide source code. This section is marked by a firm distinction between what is acceptable in the second and third versions of the GPL, and spends some time on the pros and cons of opting for simply offering to provide source code. Along the way, it debunks some common incorrect assumptions, such as the idea that only customers can take advantage of the offer, or that peer-to-peer availablity satisfies the requirement for non-peer-to-peer software. Perhaps the greatest problem is that, often, groups make the offer but have no process for providing the source code until someone requests it. They then have to scramble to provide it.
The rest of the guide explains how to handle a violation. To avoid legal escalation, projects should reply promptly, if only to say that they will respond in more detail by a specific date. The guide also emphasizes that being in violation means that you are no longer authorized to distribute the software involved, and talks about how the right to do so can be reinstated, including the third version of the GPL's provision of automatic reinstatement, and typical conditions that copyright holders might require before reinstatement is permitted. The guide concludes with some special consideration of the LGPL, and by pointing out that even if a violation is made by a subcontractor, the project is still responsible for it.
One draft short of ready
The guide's selection of topics is so far-ranging that anyone interested in FOSS legal issues will find it interesting reading, even if they have no immediate concerns about possible violations. However, for others -- especially, perhaps, those who most need to read it -- the guide makes for unnecessarily hard reading.
For one thing, perhaps because those who wrote the guide are either lawyers or regularly deal with legal matters, the language of the guide is often turgid. Although some passages are models of clear writing, addressing the reader as "you" and using short, clear sentences, at least as many discourage reading. These passages are full of passive voice, and are sprinkled with stilted diction, such as "absent" for "without" and "avail" for "take advantage of."
Even more importantly, the guide assumes that the reader is already reasonably familiar with the subject. The very first sentence explains that the guide concerns the GPL and "related licenses" -- but fails to explain which licenses it refers to (in practice, only the LGPL is discussed, and not the GNU Affero General Public Licenses (AGPL) or any of the GPL variants with exceptions). "Copyleft" and "derivative works" are also unexplained, as well as the history of the GPL license, let alone the exact intent of free licenses.
Structually, too, the guide has problems, including starting with an executive summary in the worst academic style, and a failure to provide any hints for further reading on what is, after all, a complex subject.
But perhaps the worst structural problems are in section 4, which talks about distribution of source code and the various options under the second and third versions of the GPL. The section starts by suggesting that readers have copies of the licenses open to refer to while reading the section, but it fails to provide a link. However, so many sections are referenced that you can easily imagine those who need to read the guide giving up in disgust. Quoting relevant sections would not have made the guide much longer, and would have added greatly to its coherrence.
You also have to wonder about what was left out. Even granted that the writers wished to keep the guide short, many topics are raised in passing that would surely rate at least a short paragraph. For instance, the implication of the guide seems to be that most violations are accidental, but is that so? Is the guide relevant to the AGPL, or is the AGPL, which was released last November, too new to figure in the discussion? And while the guide is about common situations, what are some of the uncommon ones, just in case they arise?
"A Practical Guide to GPL Compliance" is a document that could be valuable in educating CTOs and managers, but in its present form, I suspect that few are likely to read it all the way through. I wish that the SFLC had written another draft or two before publication, ideally under the eye of a copy editor with some understanding of the topics. Then, it might have been the plain English reference that business and FOSS communities need. As things are, I suspect that those likely to read it through to the end are those who have the least need of it.