Chapter 14
Best Practices to Avoid Common Violations

Unlike highly permissive licenses (such as the ISC license), which typically only require preservation of copyright notices, licensees face many important requirements from the GPL. These requirements are carefully designed to uphold certain values and standards of the software freedom community. While the GPL’s requirements may initially appear counter-intuitive to those more familiar with proprietary software licenses, by comparison, its terms are in fact clear and quite favorable to licensees. Indeed, the GPL’s terms actually simplify compliance when violations occur.

GPL violations occur (or, are compounded) most often when companies lack sound practices for the incorporation of GPL’d components into their internal development environment. This section introduces some best practices for software tool selection, integration and distribution, inspired by and congruent with software freedom methodologies. Companies should establish such practices before building a product based on GPL’d software.1

14.1 Evaluate License Applicability

Political discussion about the GPL often centers around determining the “work” that must be licensed under GPL, or in other words, “what is the derivative and/or combined work that was created”. Nearly ever esoteric question asked by lawyers seek to consider that question 2 (perhaps because that question explores exciting legal issues while the majority of the GPL deals with much more mundane ones). Of course, GPL was designed primarily to embody the licensing feature of copyleft.

However, most companies who add complex features to and make combinations with GPL’d software are already well aware of their more complex obligations under the license that require complex legal analysis. And, there are few companies overall that engage in such activities. Thus, in practical reality, this issue is not relevant to the vast majority of companies distributing GPL’d software.

Thus, experienced GPL enforcers find that few redistributors’ compliance challenges relate directly to combined work issues in copyleft. Instead, the distributions of GPL’d systems most often encountered typically consist of a full operating system including components under the GPL (e.g., Linux, BusyBox) and components under the LGPL (e.g., the GNU C Library). Sometimes, these programs have been patched or slightly improved by direct modification of their sources, and thus the result is unequivocally a modified version. Alongside these programs, companies often distribute fully independent, proprietary programs, developed from scratch, which are designed to run on the Free Software operating system but do not combine with, link to, modify, derive from, or otherwise create a combined work with the GPL’d components.3 In the latter case, where the work is unquestionably a separate work of creative expression, no copyleft provisions are invoked. The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a combined, derivative, and/or modified version of the work, but rather, issues related to distribution and conveyance of binary works based on GPL’d source, but without Complete, Corresponding Source.

As such, issues of software delivery are the primary frustration for GPL enforcers. In particular, the following short list accounts for at least 95% of the GPL violations ever encountered:

This tutorial therefore focuses primarily on these issue. Admittedly, a tiny minority of compliance situations relate to question of derivative, combined, or modified versions of the work. Those situations are so rare, and the details from situation to situation differ greatly. Thus, such situations require a highly fact-dependent analysis and cannot be addressed in a general-purpose document such as this one.

Most companies accused of violations lack a basic understanding of how to comply even in the straightforward scenario. This document provides those companies with the fundamental and generally applicable prerequisite knowledge. For answers to rarer and more complicated legal questions, such as whether your software is a derivative or combined work of some copylefted software, consult with an attorney.4

This discussion thus assumes that you have already identified the “work” covered by the license, and that any components not under the GPL (e.g., applications written entirely by your developers that merely happen to run on a Linux-based operating system) distributed in conjunction with those works are separate works within the meaning of copyright law and the GPL. In such a case, the GPL requires you to provide complete corresponding source (CCS)5 for the GPL’d components and your modifications thereto, but not for independent proprietary applications. The procedures described in this document address this typical scenario.

14.2 Monitor Software Acquisition

Software engineers deserve the freedom to innovate and import useful software components to improve products. However, along with that freedom should come rules and reporting procedures to make sure that you are aware of what software that you include with your product.

The most typical response to an initial enforcement action is: “We didn’t know there was GPL’d stuff in there”. This answer indicates failure in the software acquisition and procurement process. Integration of third-party proprietary software typically requires a formal arrangement and management/legal oversight before the developers incorporate the software. By contrast, developers often obtain and integrate Free Software without intervention nor oversight. That ease of acquisition, however, does not mean the oversight is any less necessary. Just as your legal and/or management team negotiates terms for inclusion of any proprietary software, they should gently facilitate all decisions to bring Free Software into your product.

Simple, engineering-oriented rules help provide a stable foundation for Free Software integration. For example, simply ask your software developers to send an email to a standard place describing each new Free Software component they add to the system, and have them include a brief description of how they will incorporate it into the product. Further, make sure developers use a revision control system (such as Git or Mercurial), and store the upstream versions of all software in a “vendor branch” or similar mechanism, whereby they can easily track and find the main version of the software and, separately, any local changes.

Such procedures are best instituted at your project’s launch. Once chaotic and poorly-sourced development processes begin, cataloging the presence of GPL’d components becomes challenging.

Such a situation often requires use of a tool to “catch up” your knowledge about what software your product includes. Most commonly, companies choose some software licensing scanning tool to inspect the codebase. However, there are few tools that are themselves Free Software. Thus, GPL enforcers usually recommend the GPL’d FOSSology system, which analyzes a source code base and produces a list of Free Software licenses that may apply to the code. FOSSology can help you build a catalog of the sources you have already used to build your product. You can then expand that into a more structured inventory and process.

14.3 Track Your Changes and Releases

As explained in further detail below, the most important component of GPL compliance is the one most often ignored: proper inclusion of CCS in all distributions of GPL’d software. To comply with GPL’s CCS requirements, the distributor must always know precisely what sources generated a given binary distribution.

In an unfortunately large number of our enforcement cases, the violating company’s engineering team had difficulty reconstructing the CCS for binaries distributed by the company. Here are three simple rules to follow to decrease the likelihood of this occurrence:

Your developers will benefit anyway from these rules. Developers will be happier in their jobs if their tools already track the precise version of source that corresponds to any deployed binary.

14.4 Avoid the “Build Guru”

Too many software projects rely on only one or a very few team members who know how to build and assemble the final released product. Such knowledge centralization not only creates engineering redundancy issues, but also thwarts GPL compliance. Specifically, CCS does not just require source code, but scripts and other material that explain how to control compilation and installation of the executable and object code.

Thus, avoid relying on a “build guru”, a single developer who is the only one who knows how to produce your final product. Make sure the build process is well defined. Train every developer on the build process for the final binary distribution, including (in the case of embedded software) generating a final firmware image suitable for distribution to the customer. Require developers to use revision control for build processes. Make a rule that adding new components to the system without adequate build instructions (or better yet, scripts) is unacceptable engineering practice.

1This document addresses compliance with GPLv2, GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common errors differs little for compliance with these four licenses. § 18.1 discusses the key differences between GPL and LGPL compliance.

2This tutorial in fact also addresses the issue at length in § 14.1.

3However, these programs do often combine with LGPL’d libraries. This is discussed in detail in § 18.1.

4If you would like more information on the application of derivative works doctrine to software, a detailed legal discussion is presented in our colleague Dan Ravicher’s article, Software Derivative Work: A Circuit Dependent Determination and in § 14.1 of this tutorial.

5For more on CCS, see § 5.1 and § 9.3 of this tutorial.