Toggle navigation

WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.

Chapter 15
Details of Compliant Distribution

First, GPLv2§1 and GPLv2§4 require that the full license text must accompany every distribution (either in source or binary form) of each licensed work. Strangely, this requirement is responsible for a surprisingly significant fraction of compliance errors; too often, physical products lack required information about the presence of GPL’d programs and the applicable license terms. Automated build processes can and should carry a copy of the license from the the source distribution into the final binary firmware package for embedded products. Such automation usually achieves compliance regarding license inclusion requirements²

15.1 Binary Distribution Permission

The various versions of the GPL are copyright licenses that grant permission to make certain uses of software that are otherwise restricted by copyright law. This permission is conditioned upon compliance with the GPL’s requirements.

This section walks through the requirements (of both GPLv2 and GPLv3) that apply when you distribute GPL’d programs in binary (i.e., executable or object code) form, which is typical for embedded applications. Because a binary application derives from a program’s original sources, you need permission from the copyright holder to distribute it. § 3 of GPLv2 and § 6 of GPLv3 contain the permissions and conditions related to binary distributions of GPL’d programs.³ Failure to provide or offer CCS is the single largest failure mode leading to compliance disputes.

GPL’s binary distribution sections offer a choice of compliance methods, each of which we consider in turn. Each option refers to the “Corresponding Source” code for the binary distribution, which includes the source code from which the binary was produced. This abbreviated and simplified definition is sufficient for the binary distribution discussion in this section, but you may wish to refer back to this section after reading the thorough discussion of “Corresponding Source” that appears in § 15.2.

15.1.1 Option (a): Source Alongside Binary

GPLv2 § 3(a) and v3 § 6(a) embody the easiest option for providing source code: including Corresponding Source with every binary distribution. While other options appear initially less onerous, this option invariably minimizes potential compliance problems, because when you distribute Corresponding Source with the binary, your GPL obligations are satisfied at the time of distribution. This is not true of other options, and for this reason, we urge you to seriously consider this option. If you do not, you may extend the duration of your obligations far beyond your last binary distribution.

Compliance under this option is straightforward. If you ship a product that includes binary copies of GPL’d software (e.g., in firmware, or on a hard drive, CD, or other permanent storage medium), you can store the Corresponding Source alongside the binaries. Alternatively, you can include the source on a CD or other removable storage medium in the box containing the product.

GPLv2 refers to the various storage mechanisms as “medi[a] customarily used for software interchange”. While the Internet has attained primacy as a means of software distribution where super-fast Internet connections are available, GPLv2 was written at a time when downloading software was not practical (and was often impossible). For much of the world, this condition has not changed since GPLv2’s publication, and the Internet still cannot be considered “a medium customary for software interchange”. GPLv3 clarifies this matter, requiring that source be “fixed on a durable physical medium customarily used for software interchange”. This language affirms that option (a) requires binary redistributors to provide source on a physical medium.

Please note that while selection of option (a) requires distribution on a physical medium, voluntary distribution via the Internet is very useful. This is discussed in detail in § 15.1.2.

15.1.2 Option (b): The Offer

Many distributors prefer to ship only an offer for source with the binary distribution, rather than the complete source package. This option has value when the cost of source distribution is a true per-unit cost. For example, this option might be a good choice for embedded products with permanent storage too small to fit the source, and which are not otherwise shipped with a CD but are shipped with a manual or other printed material.

However, this option increases the duration of your obligations dramatically. An offer for source must be good for three full years from your last binary distribution (under GPLv2), or your last binary or spare part distribution (under GPLv3). Your source code request and provisioning system must be designed to last much longer than your product life cycle. Thus, it also increases your compliance costs in the long run.

In addition, if you are required to comply with the terms of GPLv2, you cannot use a network service to provide the source code. For GPLv2, the source code offer is fulfilled only with physical media. This usually means that you must continue to produce an up-to-date “source code CD” for years after the product’s end-of-life.

Under GPLv2, it is acceptable and advisable for your offer for source code to include an Internet link for downloadable source in addition to offering source on a physical medium. This practice enables those with fast network connections to get the source more quickly, and typically decreases the number of physical media fulfillment requests. (GPLv3 § 6(b) permits provision of source with a public network-accessible distribution only and no physical media. We discuss this in detail at the end of this section.)

The following is a suggested compliant offer for source under GPLv2 (and is also acceptable for GPLv3) that you would include in your printed materials accompanying each binary distribution:

There are a few important details about this offer. First, it requires a copying fee. GPLv2 permits “a charge no more than your cost of physically performing source distribution”. This fee must be reasonable. If your cost of copying and mailing a CD is more than around $10, you should perhaps find a cheaper CD stock and shipment method. It is simply not in your interest to try to overcharge the community. Abuse of this provision in order to make a for-profit enterprise of source code provision will likely trigger enforcement action.

Second, note that the last line makes the offer valid to anyone who requests the source. This is because v2 § 3(b) requires that offers be “to give any third party” a copy of the Corresponding Source. GPLv3 has a similar requirement, stating that an offer must be valid for “anyone who possesses the object code”. These requirements indicated in v2 § 3(c) and v3 § 6(c) are so that noncommercial redistributors may pass these offers along with their distributions. Therefore, the offers must be valid not only to your customers, but also to anyone who received a copy of the binaries from them. Many distributors overlook this requirement and assume that they are only required to fulfill a request from their direct customers.

The option to provide an offer for source rather than direct source distribution is a special benefit to companies equipped to handle a fulfillment process. GPLv2 § 3(c) and GPLv3 § 6(c) avoid burdening noncommercial, occasional redistributors with fulfillment request obligations by allowing them to pass along the offer for source as they received it.

Note that commercial redistributors cannot avail themselves of the option (c) exception, and so while your offer for source must be good to anyone who receives the offer (under v2) or the object code (under v3), it cannot extinguish the obligations of anyone who commercially redistributes your product. The license terms apply to anyone who distributes GPL’d software, regardless of whether they are the original distributor. Take the example of Vendor V , who develops a software platform from GPL’d sources for use in embedded devices. Manufacturer M contracts with V to install the software as firmware in M’s device. V provides the software to M, along with a compliant offer for source. In this situation, M cannot simply pass V ’s offer for source along to its customers. M also distributes the GPL’d software commercially, so M too must comply with the GPL and provide source (or M’s own offer for source) to M’s customers.

This situation illustrates that the offer for source is often a poor choice for products that your customers will likely redistribute. If you include the source itself with the products, then your distribution to your customers is compliant, and their (unmodified) distribution to their customers is likewise compliant, because both include source. If you include only an offer for source, your distribution is compliant but your customer’s distribution does not “inherit” that compliance, because they have not made their own offer to accompany their distribution.

The terms related to the offer for source are quite different if you distribute under GPLv3. Under v3, you may make source available only over a network server, as long as it is available to the general public and remains active for three years from the last distribution of your product or related spare part. Accordingly, you may satisfy your fulfillment obligations via Internet-only distribution. This makes the “offer for source” option less troublesome for v3-only distributions, easing compliance for commercial redistributors. However, before you switch to a purely Internet-based fulfillment process, you must first confirm that you can actually distribute all of the software under GPLv3. Some programs are indeed licensed under “GPLv2, or any later version” (often abbreviated “GPLv2-or-later”). Such licensing gives you the option to redistribute under GPLv3. However, a few popular programs are only licensed under GPLv2 and not “or any later version” (“GPLv2-only”). You cannot provide only Internet-based source request fulfillment for the latter programs.

If you determine that all GPL’d works in your whole product allow upgrade to GPLv3 (or were already GPLv3’d to start), your offer for source may be as simple as this:

Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of the license itself, either electronically or in print, with every distribution.

Finally, it is unacceptable to use option (b) merely because you do not have Corresponding Source ready. We find that some companies choose this option because writing an offer is easy, but producing a source distribution as an afterthought to a hasty development process is difficult. The offer for source does not exist as a stop-gap solution for companies rushing to market with an out-of-compliance product. If you ship an offer for source with your product but cannot actually deliver immediately on that offer when your customers request it, you should expect an enforcement action.

15.1.3 Option (c): Noncommercial Offers

As discussed in the last section, GPLv2 § 3(c) and GPLv3 § 6(c) apply only to noncommercial use. These options are not available to businesses distributing GPL’d software. Consequently, companies that redistribute software packaged for them by an upstream vendor cannot merely pass along the offer they received from the vendor; they must provide their own offer or corresponding source to their distributees. We talk in detail about upstream software providers in § 18.2.

15.1.4 Option 6(d) in GPLv3: Internet Distribution

Under GPLv2, your formal provisioning options for Corresponding Source ended with § 3(c). But even under GPLv2, pure Internet source distribution was a common practice and generally considered to be compliant. GPLv2 mentions Internet-only distribution almost as aside in the language, in text at the end of the section after the three provisioning options are listed. To quote that part of GPLv2 § 3:

When that was written in 1991, Internet distribution of software was the exception, not the rule. Some FTP sites existed, but generally software was sent on magnetic tape or CDs. GPLv2 therefore mostly assumed that binary distribution happened on some physical media. By contrast, GPLv3 § 6(d) explicitly gives an option for this practice that the community has historically considered GPLv2-compliant.

Thus, you may fulfill your source-provision obligations by providing the source code in the same way and from the same location. When exercising this option, you are not obligated to ensure that users download the source when they download the binary, and you may use separate servers as needed to fulfill the requests as long as you make the source as accessible as the binary. However, you must ensure that users can easily find the source code at the time they download the binary. GPLv3 § 6(d) thus clarifies a point that has caused confusion about source provision in v2. Indeed, many such important clarifications are included in v3 which together provide a compelling reason for authors and redistributors alike to adopt GPLv3.

15.1.5 Option 6(e) in GPLv3: Software Torrents

Peer-to-peer file sharing arose well after GPLv2 was written, and does not easily fit any of the v2 source provision options. GPLv3 § 6(e) addresses this issue, explicitly allowing for distribution of source and binary together on a peer-to-peer file sharing network. If you distribute solely via peer-to-peer networks, you can exercise this option. However, peer-to-peer source distribution cannot fulfill your source provision obligations for non-peer-to-peer binary distributions. Finally, you should ensure that binaries and source are equally seeded upon initial peer-to-peer distribution.

15.2 Preparing Corresponding Source

Most enforcement cases involve companies that have unfortunately not implemented procedures like our § 14 recommendations and have no source distribution arranged at all. These companies must work backwards from a binary distribution to come into compliance. Our recommendations in § 14 are designed to make it easy to construct a complete and Corresponding Source release from the outset. If you have followed those principles in your development, you can meet the following requirements with ease. If you have not, you may have substantial reconstruction work to do.

15.2.1 Assemble the Sources

For every binary that you produce, you should collect and maintain a copy of the sources from which it was built. A large system, such as an embedded firmware, will probably contain many GPL’d and LGPL’d components for which you will have to provide source. The binary distribution may also contain proprietary components which are separate and independent works that are covered by neither the GPL nor LGPL.

The best way to separate out your sources is to have a subdirectory for each component in your system. You can then easily mark some of them as required for your Corresponding Source releases. Collecting subdirectories of GPL’d and LGPL’d components is the first step toward preparing your release.

15.2.2 Building the Sources

Few distributors, particularly of embedded systems, take care to read the actual definition of Corresponding Source in the GPL. Consider carefully the definition, from GPLv3:

and the definition from GPLv2:

Note that you must include “scripts used to control compilation and installation of the executable” and/or anything “needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities”. These phrases are written to cover different types of build environments and systems. Therefore, the details of what you need to provide with regard to scripts and installation instructions vary depending on the software details. You must provide all information necessary such that someone generally skilled with computer systems could produce a binary similar to the one provided.

Take as an example an embedded wireless device. Usually, a company distributes a firmware, which includes a binary copy of Linux⁴ and a filesystem. That filesystem contains various binary programs, including some GPL’d binaries, alongside some proprietary binaries that are separate works (i.e., not derived from, nor based on freely-licensed sources). Consider what, in this case, constitutes adequate “scripts to control compilation and installation” or items “needed to generate, install and run” the GPL’d programs.

Most importantly, you must provide some sort of roadmap that allows technically sophisticated users to build your software. This can be complicated in an embedded environment. If your developers use scripts to control the entire compilation and installation procedure, then you can simply provide those scripts to users along with the sources they act upon. Sometimes, however, scripts were never written (e.g., the information on how to build the binaries is locked up in the mind of your “build guru”). In that case, we recommend that you write out build instructions in a natural language as a detailed, step-by-step readme.

No matter what you offer, you need to give those who receive source a clear path from your sources to binaries similar to the ones you ship. If you ship a firmware (kernel plus filesystem), and the filesystem contains binaries of GPL’d programs, then you should provide whatever is necessary to enable a reasonably skilled user to build any given GPL’d source program (and modified versions thereof), and replace the given binary in your filesystem. If the kernel is Linux, then the users must have the instructions to do the same with the kernel. The best way to achieve this is to make available to your users whatever scripts or process your engineers would use to do the same.

These are the general details for how installation instructions work. Details about what differs when the work is licensed under LGPL is discussed in § 18.1, and specific details that are unique to GPLv3’s installation instructions are in § 18.4.

15.2.3 What About the Compiler?

The GPL contains no provision that requires distribution of the compiler used to build the software. While companies are encouraged to make it as easy as possible for their users to build the sources, inclusion of the compiler itself is not normally considered mandatory. The Corresponding Source definition – both in GPLv2 and GPLv3 – has not been typically read to include the compiler itself, but rather things like makefiles, build scripts, and packaging scripts.

Nonetheless, in the interest of goodwill and the spirit of the GPL, most companies do provide the compiler itself when they are able, particularly when the compiler is based on GCC or another copylefted compiler. If you have a GCC-based system, it is your prerogative to redistribute that GCC version (binaries plus sources) to your customers. We in the software freedom community encourage you to do this, since it often makes it easier for users to exercise their software freedom. However, if you chose to take this recommendation, ensure that your GCC distribution is itself compliant.

If you have used a proprietary, third-party compiler to build the software, then you probably cannot ship it to your customers. We consider the name of the compiler, its exact version number, and where it can be acquired as information that must be provided as part of the Corresponding Source. This information is essential to anyone who wishes to produce a binary. It is not the intent of the GPL to require you to distribute third-party software tools to your customer (provided the tools themselves are not based on the GPL’d software shipped), but we do believe it requires that you give the user all the essential non-proprietary facts that you had at your disposal to build the software. Therefore, if you choose not to distribute the compiler, you should include a readme about where you got it, what version it was, and who to contact to acquire it, regardless of whether your compiler is Free Software, proprietary, or internally developed.

15.3 Best Practices and Corresponding Source

§ 14 and § 15.2 above are closely related. If you follow the best practices outlined above, you will find that preparing your Corresponding Source release is an easier task, perhaps even a trivial one.

Indeed, the enforcement process itself has historically been useful to software development teams. Development on a deadline can lead organizations to cut corners in a way that negatively impacts its development processes. We have frequently been told by violators that they experience difficulty when determining the exact source for a binary in production (in some cases because their “build guru” quit during the release cycle). When management rushes a development team to ship a release, they are less likely to keep release sources tagged and build systems well documented.

We suggest that, if contacted about a violation, product builders use GPL enforcement as an opportunity to improve their development practices. No developer would argue that their system is better for having a mysterious build system and no source tracking. Address these issues by installing a revision system, telling your developers to use it, and requiring your build guru to document his or her work!

15.4 Non-Technical Compliance Issues

Certainly, the overwhelming majority of compliance issues are, in fact, either procedural or technical. Thus, the primary material in this chapter so far has covered those issues. However, a few compliance issues do require more direct consideration of a legal situation. This portion guide does not consider those in detail, as a careful reading of the earlier chapters of Part I shows various places where legal considerations are necessary for considering compliance activity.

For example, specific compliance issues related to GPLv2§7, GPLv3§7, and GPLv3§11 demand a more traditional approach to legal license compliance. Of course, such analysis and consideration can be complicated, and some are considered in the enforcement case studies that follow in the next part. However, compliance issues related to such sections are not rare, and, as is typical, no specific training is available for dealing with extremely rare occurrences.

15.5 Self-Assessment of Compliance

Most companies that adopt copylefted software believe they have complied. Humans usually have difficult admitting their own mistakes, particularly systematic ones. Therefore, perhaps the most important necessary step to stay in compliance is a company’s regular evaluation of their own compliance.

First, exercise a request CCS for all copylefted works from all your upstream providers of software and of components embedding software. Then, perform your own CCS check on this material first, and verify that it meets the requirements. This tutorial presents later a case study of a COGEO’s CCS check in § 21, which you can emulate when examining their own CCS.

Second, measure all copyleft compliance from the position of the users⁵ downstream from you exercising their rights under GPL. Have those users received notice of the copylefted software included in your product? Is CCS available to the users easily (preferably by automated means)? Ask yourself these questions frequently. If you cannot answer these questions with certainty in the positive, dig deeper and modify your process.

Avoid “compliance industry” marketing distractions and concentrate on the copylefted software you already know is in your product. Historically, the risk from a copylefted code snippet that some programmer dropped in your proprietary product careless of the consequences is a problem far more infrequent and less difficult to resolve. Efficient management of the risks of higher concern lies in making sure you can provide, for example, precisely CCS for a copy of Coreboot, the kernel named Linux, BusyBox, or GNU tar that you included in a product your company shipped two years ago than in the risk of 10 lines of GPL’d Java code an engineer accidentally pasted into the source of your ERP system.

Thus, reject the “compliance industry” suggestions that code scanners find and help solve fundamental compliance problems. Consider how COGEO’s tend to use code scanners. FOSSology is indeed an important part of a violation investigation, but such is the last step and catches only some (usually minor) licensing notice problems. Thus, code scanners can help solve minor compliance problems once you have resolved the major ones. Code scanners do not manage risk.