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

  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 \S~\ref{lgpl}, and specific details that are unique to

GPLv3's installation instructions are in \S~\ref{user-products}.

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

\section{Best Practices and Corresponding Source}

\S~\ref{best-practices} and \S~\ref{corresponding-source} 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!

\section{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~\ref{gpl-lgpl-part} shows various places where legal considerations are

necessary for considering compliance activity.

For example, specific compliance issues related to

\hyperref[GPLv2s7]{GPLv2\S7}, \hyperref[GPLv3s7]{GPLv3\S7}, and

\hyperref[GPLv3s7]{GPLv3\S11} 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.

\section{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 CEGEO's CCS

check in \S~\ref{pristine-example}, which you can emulate when examining

their own CCS\@.

Second, measure all copyleft compliance from the position of the

users\footnote{Realizing of course that user very well may not be your own

  customer.} 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 CEGEO'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.

\chapter{When The Letter Comes}

Unfortunately, many GPL violators ignore their obligations until they are

contacted by a copyright holder or the lawyer of a copyright holder.  You

should certainly contact your own lawyer if you have received a letter

alleging that you have infringed copyrights that were licensed to you

under the GPL\@.  This section outlines a typical enforcement case and

provides some guidelines for response.  These discussions are

generalizations and do not all apply to every alleged violation.  However,

CEGEO's in particular universally follow the processes described herein.

\section{Communication Is Key}

GPL violations are typically only escalated when a company ignores the

copyright holder's initial communication or fails to work toward timely

compliance.  Accused violators should respond very promptly to the

initial request.  As the process continues, violators should follow up weekly with the

copyright holders to make sure everyone agrees on targets and deadlines

for resolving the situation.

Ensure that any staff who might receive communications regarding alleged

GPL violations understands how to channel the communication appropriately

within your organization.  Often, initial contact is addressed for general

correspondence (e.g., by mail to corporate headquarters or by e-mail to

general informational or support-related addresses).  Train the staff that

processes such communications to escalate them to someone with authority

to take action.  An unknowledgable response to such an inquiry (e.g., from

a first-level technical support person) can cause negotiations to fail

prematurely.

Answer promptly by multiple means (paper letter, telephone call, and

email), even if your response merely notifies the sender that you are

investigating the situation and will respond by a certain date.  Do not

let the conversation lapse until the situation is fully resolved.

Proactively follow up with synchronous communication means to be sure

communications sent by non-reliable means (such as email) were received.

Remember that the software freedom community generally values open communication and

cooperation, and these values extend to GPL enforcement.  You will

generally find that software freedom developers and their lawyers are willing to

have a reasonable dialogue and will work with you to resolve a violation

once you open the channels of communication in a friendly way.

\section{Termination}

Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and

GPLv3~\S~8).  Under v2, violators forfeit their rights to redistribute and

modify the GPL'd software until those rights are explicitly reinstated by

the copyright holder.  In contrast, v3 allows violators to rapidly resolve

some violations without consequence.

If you have redistributed an application under GPLv2\footnote{This applies

  to all programs licensed to you under only GPLv2 (``GPLv2-only'').

  However, most so-called GPLv2 programs are actually distributed with

  permission to redistribute under GPLv2 \emph{or any later version of the

    GPL} (``GPLv2-or-later'').  In the latter cases, the redistributor can

  choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even

  GPLv3-or-later.  Where the redistributor has chosen v2 explicitly, the

  v2 termination provision will always apply.  If the redistributor has

  chosen v3, the v3 termination provision will always apply.  If the

  redistributor has chosen GPLv2-or-later, then the redistributor may want

  to narrow to GPLv3-only upon violation, to take advantage of the

  termination provisions in v3.}, but have violated the terms of GPLv2,

you must request a reinstatement of rights from the copyright holders

before making further distributions, or else cease distribution and

modification of the software forever.  Different copyright holders

condition reinstatement upon different requirements, and these

requirements can be (and often are) wholly independent of the GPL\@.  The

terms of your reinstatement will depend upon what you negotiate with the

copyright holder of the GPL'd program.

Since your rights under GPLv2 terminate automatically upon your initial

violation, \emph{all your subsequent distributions} are violations and

infringements of copyright.  Therefore, even if you resolve a violation on

your own, you must still seek a reinstatement of rights from the copyright

holders whose licenses you violated, lest you remain liable for

infringement for even compliant distributions made subsequent to the

initial violation.

GPLv3 is more lenient.  If you have distributed only v3-licensed programs,

you may be eligible under v3~\S~8 for automatic reinstatement of rights.

You are eligible for automatic reinstatement when:

\begin{itemize}

\item you correct the violation and are not contacted by a copyright

  holder about the violation within sixty days after the correction, or

\item you receive, from a copyright holder, your first-ever contact

  regarding a GPL violation, and you correct that violation within thirty

  days of receipt of copyright holder's notice.

\end{itemize}

In addition to these permanent reinstatements provided under v3, violators

who voluntarily correct their violation also receive provisional

permission to continue distributing until they receive contact from the

copyright holder.  If sixty days pass without contact, that reinstatement

becomes permanent.  Nonetheless, you should be prepared to cease

distribution during those initial sixty days should you receive a

termination notice from the copyright holder.

Given that much discussion of v3 has focused on its so-called more

complicated requirements, it should be noted that v3 is, in this regard,

more favorable to violators than v2.

However, note that most Linux-based systems typically include some software

licensed under GPLv2-only, and thus the copyright holders have withheld

permission to redistribute under terms of GPLv3.  In larger aggregate

distributions which include GPLv2-only works (such as the kernel named

Linux), redistributors must operate as if termination is immediate and

permanent, since the technological remove of GPLv2-only works from the larger

distribution requires much more engineering work than the negotiation

required to seek restoration of rights for distribution under GPLv2-only

after permanent termination.

\chapter{Standard Requests}

As we noted above, different copyright holders have different requirements

for reinstating a violator's distribution rights.  Upon violation, you no

longer have a license under the GPL\@.  Copyright holders can therefore

set their own requirements outside the license before reinstatement of

rights.  We have collected below a list of reinstatement demands that

copyright holders often require.

\begin{itemize}

\item {\bf Compliance on all Free Software copyrights}.  Copyright holders of Free Software

  often want a company to demonstrate compliance for all GPL'd software in

  a distribution, not just their own.  A copyright holder may refuse to

  reinstate your right to distribute one program unless and until you

  comply with the licenses of all Free Software in your distribution.

\item {\bf Notification to past recipients}.  Users to whom you previously

  distributed non-compliant software should receive a communication

  (email, letter, bill insert, etc.) indicating the violation, describing

  their rights under the GPL, and informing them how to obtain a gratis source

  distribution.  If a customer list does not exist (such as in reseller

  situations), an alternative form of notice may be required (such as a

  magazine advertisement).

\item {\bf Appointment of a GPL Compliance Officer.}  The software freedom community

  values personal accountability when things go wrong.  Copyright holders

  often require that you name someone within the violating company

  officially responsible for Free Software license compliance, and that this

  individual serve as the key public contact for the community when

  compliance concerns arise.

\item {\bf Periodic Compliance Reports.}  Many copyright holders wish to

  monitor future compliance for some period of time after the violation.

  For some period, your company may be required to send regular reports on

  how many distributions of binary and source have occurred.

\end{itemize}

These are just a few possible requirements for reinstatement.  In the

context of a GPL violation, and particularly under v2's termination

provision, the copyright holder may have a range of requests in exchange

for reinstatement of rights.  These software developers are talented

professionals from whose work your company has benefited.  Indeed, you are

unlikely to find a better value or more generous license terms for similar

software elsewhere.  Treat the copyright holders with the same respect you

treat your corporate partners and collaborators.

\chapter{Special Topics in Compliance}

There are several other issues that are less common, but also relevant in

a GPL compliance situation.  To those who face them, they tend to be of

particular interest.

% FIXME-URGENT: integrate

Non-compliance with GPLv3 in the

distribution of Javascript on the Web is becoming more frequent

%FIXME-URGENT: END

\section{LGPL Compliance}

\label{lgpl}

GPL compliance and LGPL compliance mostly involve the same issues.  As we

discussed in \S~\ref{derivative-works}, questions of modified versions of

software are highly fact-dependant and cannot be easily addressed in any

overview document.  The LGPL adds some additional complexity to the

analysis.  Namely, the various LGPL versions permit proprietary licensing

of certain types of modified versions.  These issues are well beyond the

scope of this document, but as a rule of thumb, once you have determined

(in accordance with LGPLv3) what part of the work is the ``Application''

and what portions of the source are ``Minimal Corresponding Source'', then

you can usually proceed to follow the GPL compliance rules that we

discussed, replacing our discussion of ``Corresponding Source'' with

``Minimal Corresponding Source''.

LGPL also requires that you provide a mechanism to combine the Application

with a modified version of the library, and outlines some options for

this.  Also, the license of the whole work must permit ``reverse

engineering for debugging such modifications'' to the library.  Therefore,

you should take care that the EULA used for the Application does not

contradict this permission.

%FIXME-URGENT: integrate

Under the terms of LGPL, they must also refrain from license terms on works

based on the licensed work that prohibit replacement of the licensed

components of the larger non-LGPL’d work, or prohibit decompilation or

reverse engineering in order to enhance or fix bugs in the LGPL’d components.

Section 2(a) states that if a licensed work is a software library (defined in

\S0 as ``a collection of software functions and/or data prepared so as to be

conveniently linked with application programs (which use some of those

functions and data) to form executables'') permission is given to distribute

modified versions only if those versions are themselves libraries. LGPLv2.1

code can therefore not be compliantly taken from its context in a library and

placed in a non-library modified version or work based on the work. Section 6

does not provide an exception for this rule: a combination may be made of a

modified version of an LGPL’d library with other code, but the LGPL’d code

must continue to be structured as a library, and to that library the terms of

the license continue to apply.

%FIXME-URGENT: END

\section{Upstream Providers}

\label{upstream}

With ever-increasing frequency, software development (particularly for

embedded devices) is outsourced to third parties.  If you rely on an

upstream provider for your software, note that you \emph{cannot ignore

  your GPL compliance requirements} simply because someone else packaged

the software that you distribute.  If you redistribute GPL'd software

(which you do, whenever you ship a device with your upstream's software in

it), you are bound by the terms of the GPL\@.  No distribution (including

redistribution) is permissible absent adherence to the license terms.

Therefore, you should introduce a due diligence process into your software

acquisition plans.  This is much like the software-oriented

recommendations we make in \S~\ref{best-practices}.  Implementing

practices to ensure that you are aware of what software is in your devices

can only improve your general business processes.  You should ask a clear

list of questions of all your upstream providers and make sure the answers

are complete and accurate.  The following are examples of questions you