% compliance-guide.tex                            -*- LaTeX -*-

\part{A Practical Guide to GPL Compliance}

\label{gpl-compliance-guide}

{\parindent 0in

This part is: \\

\begin{tabbing}

Copyright \= \copyright{} 2008, 2014 \= \hspace{.2in} Bradley M. Kuhn. \\

Copyright \= \copyright{} 2014 \> \hspace{.2in} Free Software Foundation, Inc. \\

Copyright \> \copyright{} 2008, 2014 \> \hspace{.2in} Software Freedom Law Center. \\

\end{tabbing}

\vspace{.1in}

\begin{center}

The copyright holders of this part hereby grant the freedom to copy, modify,

convey, Adapt, and/or redistribute this work under the terms of the Creative

Commons Attribution Share Alike 4.0 International License.  A copy of that

license is available at

\url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.

\vfill

CC-By-SA-licensed published works: \\

\begin{itemize}

\item \hrefnofollow{http://www.softwarefreedom.org/resources/2008/compliance-guide.html}{\textit{The Practical Guide GPL Compliance}}, by Bradley M. Kuhn, Aaron

Williamson and Karen Sandler, first published on 2008-08-20. \\

\item \hrefnofollow{http://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html}{\textit{Software Freedom Law Center Guide to GPL Compliance, 2nd

  Edition}} by Eben Moglen and Mishi Choudhary, first published on 2014-10-31. \\

\end{itemize}

However, this work is primarily composed of the many contributions it

receives as a public, collaborative project.  Please

\href{https://gitorious.org/copyleft-org/tutorial/history/master:compliance-guide.tex}{review

  its Git logs} for full documentation of all contributions.

\end{center}

}

\pagebreak

\chapter*{Executive Summary}

This is a guide to effective compliance with the GNU General Public

License (GPL) and related licenses.  Copyleft advocates

usually seek to assist the community with

GPL compliance cooperatively.   This guide focuses on complying from the

start, so that readers can learn to avoid enforcement actions entirely, or, at

least, minimize  the negative impact when enforcement actions occur.

This guide  introduces and explains basic legal concepts related to the GPL and its

enforcement by copyright holders. It also outlines business practices and

methods that lead to better GPL compliance.  Finally, it recommends proper

post-violation responses to the concerns of copyright holders.

\chapter{Background}

Copyright law grants exclusive rights to authors.  Authors who chose copyleft

seek to protect the freedom of users and developers to copy, share, modify

and redistribute the software.  However, copyleft is ultimately implemented

through copyright, and the GPL is primarily and by default a copyright

license.  (See \S~\ref{explaining-copyright} for more about the interaction

between copyright and copyleft.)  Copyright law grants an unnatural exclusive

control to copyright holders regarding copyright-controlled permissions

related to the work.  Therefore, copyright holders (or their agents) are the

ultimately the sole authorities to enforce copyleft and protect the rights of

users.  Actions for copyright infringement are the ultimate legal mechanism

for enforcement.  Therefore, copyright holders, or collaborative groups of

copyright holders, have historically been the actors in GPL enforcement.

The earliest of these efforts began soon after the GPL was written by

Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,

often in public Usenet discussions.\footnote{One example is the public

  outcry over NeXT's attempt to make the Objective-C front-end to GCC

  proprietary.  RMS, in fact, handled this enforcement action personally and

  the Objective-C front-end is still part of upstream GCC today.}  Over the next decade, the Free Software Foundation (FSF),

which holds copyrights in many GNU programs, was the only visible entity

actively enforcing its GPL'd copyrights on behalf of the software freedom

community.

FSF's enforcement

was generally a private process; the FSF contacted violators

confidentially and helped them to comply with the license.  Most

violations were pursued this way until the early 2000's.

By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in

embedded devices such as wireless routers.  During this period, public

ridicule of violators in the press and on Internet fora supplemented

ongoing private enforcement and increased pressure on businesses to

comply.  In 2003, the FSF formalized its efforts into the GPL Compliance

Lab, increased the volume of enforcement, and built community coalitions

to encourage copyright holders to together settle amicably with violators.

Beginning in 2004, Harald Welte took a more organized public enforcement

approach and launched \href{http://gpl-violations.org/}{gpl-violations.org}, a website and mailing

list for collecting reports of GPL violations.  On the basis of these

reports, Welte successfully pursued many enforcement actions in Europe, including

formal legal action.  Harald earns the permanent fame as the first copyright

holder to bring legal action in a court regarding GPL compliance.

In 2007, two copyright holders in BusyBox, in conjunction with the

Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit

based on a violation of the GPL\@ in the USA. While  lawsuits are of course

quite public, the vast majority of Conservancy's enforcement actions 

are resolved privately via

cooperative communications with violators.  As both FSF and Conservancy have worked to bring

individual companies into compliance, both organizations have encountered numerous

violations resulting from preventable problems such as inadequate

attention to licensing of upstream software, misconceptions about the

GPL's terms, and poor communication between software developers and their

management.  This document highlights these problems and describe

best practices to encourage corporate Free Software users to reevaluate their

approach to GPL'd software and avoid future violations.

Both FSF and Conservancy continue GPL enforcement and compliance efforts

for software under the GPL, the GNU Lesser

Public License (LGPL) and other copyleft licenses.  In doing so, both organizations have

found that most violations stem from a few common, avoidable mistakes.  All copyleft advocates  hope to educate the community of

commercial distributors, redistributors, and resellers on how to avoid

violations in the first place, and to respond adequately and appropriately

when a violation occurs.

\section{Who Has Compliance Obligations?}

All distributors of modified or unmodified versions of copylefted works

unmodified versions of the works have compliance obligations.  Common methods

of modifying the works include innumerable common acts, such as:

\begin{itemize}

  \item embedding those works as executable copies

    into a device,

  \item transferring a digital copy of executable copies to someone else,

  \item posting a patch to the copylefted software to a public mailing list.

\end{itemize}

Such distributors have obligations to (at least) the users to whom they (or

intermediary parties) distribute those copies.  In some cases, distributors

have obligations to third parties not directly receiving their distribution

of the works (depending on the distributors chosen licensing options, as

described later in \S~\ref{binary-distribution-permission}).  In addition,

distributors have compliance obligations to upstream parties, such as

preservation of reasonable legal notices embedded in the code, and

appropriate labeling of modified versions.

Online service providers and distributors alike have other compliance

obligations.  In general, they must refrain from imposing any additional

restrictions on downstream parties. Most typically, such compliance problems

arise from ``umbrella licenses:'' EULAs, or sublicenses that restrict

downstream users' rights under copyleft. (See \S~\ref{GPLv2s6} and

\S~\ref{GPLv3s10}).

Patent holders having claims reading on GPL'd works they distribute must

refrain from enforcing those claims against parties to whom they distribute.

Furthermore, patent holders holding copyrights on GPLv3'd works must further

grant an explicit patent license for any patent claims reading on the version

they distributed, and therefore cannot enforce those specific patent claims

against anyone making, using or selling a work based on their distributed

version.  All parties must refrain from acting as a provider of services or

distributor of licensed works if they have accepted, or had imposed on them

by judicial action, any legal conditions that would prevent them from meeting

any obligation under GPL\@.  (See \S~\ref{GPLv2s7}, \S~\ref{GPLv3s11} and

\S~\ref{GPLv3s12}.

\section{What Are The Risks of Non-Compliance?}

Copyleft experts have for decades observed a significant mismatch between the

assumptions most businesses make about copyleft compliance and the realities.

Possibly due to excessive marketing of proprietary tools and services from

the for-profit compliance industry, businesses perennially focus on the wrong

concerns.  This tutorial seeks to educate those businesses about what

actually goes wrong, what causes disputes, and how to resolve those disputes.

Many businesses currently invest undue resources to avoid unlikely risks that

have low historical incidence of occurrence and low cost of remediation,

while leaving unmanaged the risks that have historically resulted in all the

litigation and other adverse outcomes.  For example, some ``compliance

industry''\footnote{``Compliance industry'' refers to third-party for-profit

  companies that market proprietary software tools and/or consulting services

  that purport to aid businesses with their Free Software license compliance

  obligations, such as those found in GPL and other copyleft licenses.  This

  tutorial leaves the term in quotes throughout, primarily to communicate the

  skepticism most of this tutorial's authors feel regarding the mere

  existence of this industry.  Not only do copyleft advocates object on

  principle to proprietary software tools in general, and to their ironic use

  specifically to comply with copyleft, but also to the ``compliance

  industry'' vendors' marketing messaging, which some copyleft advocates

  claim as a cause in the risk misassessments discussed herein.  Bradley

  M.~Kuhn, specifically, regularly uses the term ``compliance industrial

  complex''

  \href{http://en.wikipedia.org/wiki/Military-industrial_complex}{to

    analogize the types of problems in this industry to those warned against

    in the phrase of origin}.} vendors insist that great effort must be

expended to carefully list, in the menus or manuals of embedded electronics

products, copyright notices for every last copyright holder that contributed

to the Free Software included in the product.  While nearly all Free Software

licenses, including copylefts like GPL, require preservation and display of

copyright notices, failure to meet this specific requirement is trivially

remedied.  Therefore, businesses should spend just reasonable efforts to

properly display copyright notices, and note that failure to do so is simply

remedied: add the missing copyright notice!

\section{Understanding Who's Enforcing}

\label{compliance-understanding-whos-enforcing}

The mismatch between actual compliance risk and compliance risk management

typically results from a misunderstanding of licensor intentions.  For-profit

businesses often err by assuming other actors have kindred motivations.  The

primary enforcers of the GPL, however, have goals that for-profit businesses

will find strange and perhaps downright alien.

Specifically, community-oriented GPL enforcement organizations (called

``COGEOs'' throughout the remainder of this tutorial) are typically

non-profit charities (such as the FSF and Software Freedom Conservancy) who

declare, as part of their charitable mission, advancement of software freedom

for all users.  In the USA, these COGEOs are all classified as charitable

under the IRS's 501(c)(3) designation, which is reserved for organizations

that have a mission to enhance the public good.

As such, these COGEOs enforce GPL primarily to pursue the policy goals and

motivations discussed throughout this tutorial: to spread software freedom

further.  As such, COGEOs are unified in their primary goal to bring the

violator back into compliance as quickly as possible, and redress the damage

caused by the violation.  COGEOs are steadfast in their position in a

violation negotiation: comply with the license and respect freedom.

Certainly, other entities do not share the full ethos of software freedom as

institutionalized by COGEOs, and those entities pursue GPL violations

differently.  Oracle, a company that produces the GPL'd MySQL database, upon

discovering GPL violations typically negotiates a proprietary software

license separately for a fee.  While this practice is not one a COGEO would

undertaking nor endorsing, a copyleft license technically permits this

behavior.  To put a finer point on this practice already discussed

in~\S~\ref{Proprietary Relicensing}, copyleft advocates usually find copyleft

enforcement efforts focused on extract alternative proprietary licenses

distasteful at best, and a corrupt manipulation of copyleft at worst.  Much

to the advocates' chagrin, such for-profit enforcement efforts seem to

increase rather than decrease.

Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly

assume that all copyright holders seek royalties.  Businesses therefore focus

on the risk of so-called ``accidental'' (typically as the result of

unsupervised activity by individual programmers) infringe copyright by

incorporating ``snippets'' of copylefted code into their own proprietary

computer program.  ``Compliance industry'' flagship products, therefore,

focus on ``code scanning'' services that purport to detect accidental

inclusions.  Such effort focuses on proprietary software development and view

Free Software as a foreign interloper.  Such approach not only ignores

current reality that many companies build their products directly on major

copylefted projects (e.g., Android vendor's use of the kernel named Linux),

but also creates a culture of fear among developers, leading them into a

downward spiral of further hiding their necessary reliance on copylefted

software in the company's products.

Fortunately, COGEOs regard GPL compliance failures as an opportunity to

improve compliance.  Every compliance failure downstream represents a loss of

rights by their users. The COGEOs are the guardian of its users' and

developers' rights.  Their activity seeks to restore those rights, and

to protect the project's contributors' intentions in the making of their

software. 

\chapter{Best Practices to Avoid Common Violations}

\label{best-practices}

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.\footnote{This document addresses compliance with GPLv2,

  GPLv3, LGPLv2, and LGPLv3.  Advice on avoiding the most common

  errors differs little for compliance with these four licenses.

  \S~\ref{lgpl} discusses the key differences between GPL and LGPL

  compliance.}

\section{Evaluate License Applicability}

\label{derivative-works}

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

\footnote{\tutorialpartsplit{In fact, a companion work, \textit{Detailed Analysis of the GNU GPL and Related

      Licenses} contains an entire section discussing derivative works}{This tutorial in fact

  also addresses the issue at length in~\S~\ref{derivative-works}}.} (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.\footnote{However, these programs do often combine

  with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}

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:

\begin{itemize}

\item The violator fails to provide required information about the presence

  of copylefted programs and their applicable license terms in the product

  they have purchased.

\item The violator fails to reliably deliver \hyperref[CCS

  Definition]{complete, corresponding source} (CCS) for copylefted programs

  the violator knew were included (i.e., the CCS is either delivered but

  incomplete, or is not delivered at all).

\item Requestors are ignored when they communicate with violator's published

  addresses requesting fulfillment of businesses' obligations.

\end{itemize}

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.

\medskip

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.\footnote{If 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,

  \textit{Software Derivative Work: A Circuit Dependent Determination} and in

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

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)\footnote{For more on CCS,  see

\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of

    this tutorial}.}

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.

\section{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

\href{http://fossology.org/}{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.

\section{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

\textit{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:

\begin{itemize}

\item Ensure that your

developers are using revision control systems properly.

\item Have developers mark or ``tag'' the full source tree corresponding to

  builds distributed to customers.

\item Check that your developers store all parts of the software

development in the revision control system, including {\sc readme}s, build

scripts, engineers' notes, and documentation.

\end{itemize}

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.

\section{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.

\chapter{Details of Compliant Distribution}

Distribution of GPL'd works has requirements; copyleft will not function

without placing requirements on redistribution.  However, some requirements

are more likely to cause compliance difficult than others.  This

chapter\footnote{Note that this chapter refers heavily to specific provisions

  and language in

  \hyperref[GPLv2s3-full-text]{GPLv2\S3}

  and \hyperref[GPLv3s6-full-text]{GPLv3\S6}.

  It may be helpful  to review \S~\ref{GPLv2s3} and \S~\ref{GPLv3s6} first,

  and then have a copy of each license open while reading this

  section.}  explains some the specific requirements placed upon

distributors of GPL'd software that redistributors are most likely to

overlook, yielding compliance problems.

First, \hyperref[GPLv2s1]{GPLv2\S1} and \hyperref[GPLv2s4]{GPLv2\S4} 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\footnote{At least one COGEO recommends the

  \href{https://www.yoctoproject.org/}{Yocto Project}, since its engineers

  have designed such features into it build process.}

\section{Binary Distribution Permission}

\label{binary-distribution-permission}

% be careful below, you cannot refill the \if section, so don't refill

% this paragraph without care.

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.  \S~3 of GPLv2 and

\S~6 of GPLv3 contain the permissions and conditions related to binary

distributions of GPL'd programs.\footnote{These sections cannot be fully

  understood in isolation; read the entire license thoroughly before

  focusing on any particular provision.  However, once you have read and

  understood the entire license, look to these sections to guide

  compliance for binary distributions.}  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 \S~\ref{corresponding-source}.

\subsection{Option (a): Source Alongside Binary}

GPLv2~\S~3(a) and v3~\S~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, \emph{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 \S~\ref{offer-with-internet}.

\subsection{Option (b): The Offer}

\label{offer-for-source}

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 \emph{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

{\bf 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.

\label{offer-with-internet}

Under GPLv2, it is acceptable and advisable for your offer for source code

to include an Internet link for downloadable source \emph{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~\S~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:

\begin{quote}

The software included in this product contains copyrighted software that

is licensed under the GPL\@.  A copy of that license is included in this

document on page $X$\@.  You may obtain the complete Corresponding Source

code from us for a period of three years after our last shipment of this

product, which will be no earlier than 2011-08-01, by sending a money

order or check for \$5 to: \\

GPL Compliance Division \\

Our Company \\

Any Town, US 99999 \\

\\

Please write ``source for product $Y$'' in the memo line of your

payment.

You may also find a copy of the source at

\url{http://www.example.com/sources/Y/}.

This offer is valid to anyone in receipt of this information.

\end{quote}

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~\S~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~\S~3(c) and v3~\S~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~\S~3(c) and GPLv3~\S~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

\emph{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 \emph{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 \emph{all} of the software under GPLv3.  Some

programs are indeed licensed under ``GPLv2, \emph{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:

\begin{quote}

The software included in this product contains copyrighted software that

is licensed under the GPLv3\@.  A copy of that license is included in this

document on page $X$\@.  You may obtain the complete Corresponding Source

code from us for a period of three years after our last shipment of this

product and/or spare parts therefor, which will be no earlier than

2011-08-01, on our website at

\url{http://www.example.com/sources/productnum/}.

\end{quote}

\medskip

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 \emph{immediately} on that

offer when your customers request it, you should expect an enforcement

action.

\subsection{Option (c): Noncommercial Offers}

As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~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 \S~\ref{upstream}.

\subsection{Option 6(d) in GPLv3: Internet Distribution}

Under GPLv2, your formal provisioning options for Corresponding Source

ended with \S~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~\S~3:

\begin{quote}

If distribution of executable or object code is made by offering access to

copy from a designated place, then offering equivalent access to copy the

source code from the same place counts as distribution of the source code,

even though third parties are not compelled to copy the source along with

the object code.

\end{quote}

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~\S~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~\S~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.

\subsection{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~\S~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 \emph{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.

\section{Preparing Corresponding Source}

\label{corresponding-source}

Most enforcement cases involve companies that have unfortunately not

implemented procedures like our \S~\ref{best-practices} 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 \S~\ref{best-practices} 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.

\subsection{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.

\subsection{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:

\begin{quote}

  The ``Corresponding Source'' for a work in object code form means all

  the source code needed to generate, install, and (for an executable

  work) run the object code and to modify the work, including scripts to

  control those activities.

\end{quote}

and the definition from GPLv2:

\begin{quote}

The source code for a work means the preferred form of the work for making

modifications to it.  For an executable work, complete source code means

all the source code for all modules it contains, plus any associated

interface definition files, plus the scripts used to control compilation

and installation of the executable.

\end{quote}

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\footnote{``Linux'' refers only to the kernel, not the larger system

  as a whole.} 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