Richard Stallman 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.}  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 community of

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 had become very common, particularly in

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

cooperative communications with violators.  As we have worked to bring

individual companies into compliance, we 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.  In this document, we highlight these problems and describe

approach to GPL'd software and avoid future violations.

SFLC continues to conduct GPL enforcement and compliance efforts for many

of its clients who release their software under the GPL, the GNU Lesser

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

found that most violations stem from a few common mistakes that can be,

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

when a violation occurs.

\chapter{Best Practices to Avoid Common Violations}

\label{best-practices}

typically only require preservation of copyright notices, the GPL places a

number of important requirements upon licensees.  These requirements are

carefully designed to uphold certain values and standards of the software

freedom community.  While the GPL's requirements may appear initially

counter-intuitive to those more familiar with proprietary software

licenses, by comparison its terms are in fact clear and favorable to

violations occur.

GPL violations are often caused or compounded by a failure to adopt sound

practices for the incorporation of GPL'd components into a company's

internal development environment.  In this section, we introduce some best

practices for software tool selection, integration and distribution,

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.}

systems that we encounter 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,

resulting unequivocally in a derivative work.  Alongside these programs,

companies often distribute fully independent, proprietary programs,

system but do not combine with, link to, modify, or otherwise derive from

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 derivative work has been created.  The tiny

minority of situations which lie outside these two categories, and thus

The companies we contact about GPL violations often respond with: ``We

didn't know there was GPL'd stuff in there''.  This answer indicates a

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, your developers often obtain and

does not mean the oversight is any less necessary.  Just as your legal

and/or management team negotiates terms for inclusion of any proprietary

product.

Simple, engineering-oriented rules help provide a stable foundation for

and have them include a brief description of how they will incorporate it

into the product.  Make sure they use a revision control system, and have

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 local changes made.

Such procedures are best instituted at your project's launch.  Once a

chaotic and poorly-sourced development process has begun, the challenges

of determining and cataloging the presence of GPL'd components is

difficult.  If you are in that situation, we recommend the

\href{http://fossology.org/}{Fossology system}, which analyzes a

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}

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

``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

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

a GCC-based system, it is your prerogative to redistribute that GCC

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

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

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

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.

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

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 GPL's termination provision (GPLv2~\S~4 and

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}

  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

\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 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).

  values personal accountability when things go wrong.  Copyright holders

  often require that you name someone within the violating company

  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

upstream.  In our experience, agreements regarding GPL compliance issues

and procedures are rarely negotiated up front.  However, when they are,

violations are resolved much more smoothly (at least from the point of

view of the redistributor).

Consider the cost of potential violations in your acquisition process.

wary of vendors who have done so without regard for the licenses.  If your

vendor's costs seem ``too good to be true,'' you may ultimately bear the

burden of the vendor's inattention to GPL compliance.  Ask the right

questions, demand an account of your vendors' compliance procedures, and

seek indemnity from them.

industry practice.  While it is impossible to provide a device that is

completely unmodifiable\footnote{Consider that the iPhone, a device

  designed primarily to restrict users' freedom to modify it, was unlocked

  and modified within 48 hours of its release.}, users are generally on

notice that they risk voiding their warranties and losing their update and

support services when they make modifications.\footnote{A popular t-shirt

  well-known for modifying products with full knowledge of the

  consequences.  GPLv3's ``Installation Instructions'' section merely

  confirms that reality, and makes sure GPL rights can be fully exercised,

  even if users exercise those rights at their own peril.}

GPLv3 is in many ways better for distributors who seek some degree of

rather than any unexpected application of the GPL's source code disclosure

requirements.

Compliance is straightforward when the entirety of your enterprise is

well-informed and well-coordinated.  The receptionists should know how to

route a GPL source request or accusation of infringement.  The lawyers

disclosure requirements, and should explain those details to the software

developers.  The software developers should use a version control system

that allows them to associate versions of source with distributed

binaries, have a well-documented build process that anyone skilled in the

art can understand, and inform the lawyers when they bring in new

software.  Managers should build systems and procedures that keep everyone

on target.  With these practices in place, any organization can comply

with the GPL without serious effort, and receive the substantial benefits

ready-made for their products.

\vfill

% LocalWords:  redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox

% LocalWords:  someone's downloadable subdirectory subdirectories filesystem