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

Early GPL enforcement 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 \verb0gpl-violations.org0, a website and mailing

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

reports, Welte successfully pursued many enforcements 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 has 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 mistakes that can be,

for the most part, easily avoided.  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.

\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 appear initially

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 the ``copyleft''

requirements of the license.  Indeed, the license was designed primarily

to embody this licensing feature.  Most companies adding non-trivial

  discussion regarding copyleft and derivative works.  In practical

  reality, this issue is not relevant to the vast majority of companies

However, in our experience with GPL enforcement, few redistributors'

compliance challenges relate directly to the copyleft provisions; this is

doubly true for most embedders.  Instead, the distributions of GPL'd

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,

developed from scratch, which are designed to run on the Free Software operating

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

involve close questions about derivative works, require a highly

fact-dependent analysis and cannot be addressed in a general-purpose

document.

Most companies accused of violations, however, lack a basic understanding

of how to comply even in the straightforward scenario.  This document

provides that fundamental and generally applicable prerequisite knowledge.

For answers to rarer and more complicated legal questions, such as whether

your software is a derivative 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}.}

For this discussion, we will assume 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.  In

such a case, the GPL requires you to provide complete and corresponding

source 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 should have the freedom to innovate and import useful

software components to improve your product.  However, along with that

freedom should come rules and reporting procedures to make sure that you

are aware of what software is being tested or included with your product.

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

integrate Free Software without intervention. The 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 be involved in all decisions to bring Free Software into your

product.

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

free software integration.  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.  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

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 we will explain in further detail below, the most important component

to maintaining GPL compliance is inclusion of the complete and

corresponding source code in any distributions that you make of GPL'd

software.  Knowing at all times what sources generated a given binary

distribution is paramount.

In an unfortunately large number of our enforcement cases, the violating

company's engineering team had difficulty reconstructing the precise

sources for a given binary distributed by the company.  Ensure that your

developers are using revision control systems properly.  Have them mark or

tag the full source tree corresponding to builds distributed to customers.

Finally, 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.  Your developers will also

benefit from a system that tracks the precise version of source that

very important, because the Free Software community heavily supports

users' rights to ``fair use'' and ``unregulated use'' of copyrighted

material.  GPLv2 asserts through this clause that it supports users' rights

to fair and unregulated uses.

Fair use (called ``fair dealing'' in some jurisdictions) of copyrighted

material is an established legal doctrine that permits certain activities

regardless of whether copyright law would other restrict those activities.

Discussion of the various types of fair use activity are beyond the scope of

this tutorial.  However, one important example of fair use is the right to

quote portions of the text in larger work so as to criticize or suggest

changes.  This fair use rights is commonly used on mailing lists when

discussing potential improvements or changes to Free Software.

Fair use is a doctrine established by the courts or by statute.  By

contrast, unregulated uses are those that are not covered by the statue

nor determined by a court to be covered, but are common and enjoyed by

many users.  An example of unregulated use is reading a printout of the

program's source code like an instruction book for the purpose of learning

how to be a better programmer.  The right to read something that you have

access is and should remain unregulated and unrestricted.

\medskip

Thus, the GPLv2 protects users fair and unregulated use rights precisely by

not attempting to cover them.  Furthermore, the GPLv2 ensures the freedom

to run specifically by stating the following:

\begin{quote}

''The act of running the Program is not restricted.''

\end{quote}

Thus, users are explicitly given the freedom to run by GPLv2~\S0.

\medskip

The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used

throughout.  The only one worth discussing in detail is ``work based on

the Program''.  The reason this definition is particularly interesting is

not for the definition itself, which is rather straightforward, but

because it clears up a common misconception about the GPL\@.

The GPL is often mistakenly criticized because it fails to give a

definition of ``derivative work''.  In fact, it would be incorrect and

problematic if the GPL attempted to define this.  A copyright license, in

fact, has no control over what may or may not be a derivative work.  This

matter is left up to copyright law and the courts --- not the licenses that utilize it.

It is certainly true that copyright law as a whole does not propose clear

and straightforward guidelines for what is and is not a derivative

software work under copyright law.  However, no copyright license --- not

even the GNU GPL --- can be blamed for this.  Legislators and court

opinions must give us guidance to decide the border cases.

\section{GPLv2~\S1: Verbatim Copying}

\label{GPLv2s1}

GPLv2~\S1 covers the matter of redistributing the source code of a program

exactly as it was received. This section is quite straightforward.

However, there are a few details worth noting here.

The phrase ``in any medium'' is important.  This, for example, gives the

freedom to publish a book that is the printed copy of the program's source

code.  It also allows for changes in the medium of distribution.  Some

vendors may ship Free Software on a CD, but others may place it right on

the hard drive of a pre-installed computer.  Any such redistribution media

is allowed.

Preservation of copyright notice and license notifications are mentioned

specifically in GPLv2~\S1.  These are in some ways the most important part of

the redistribution, which is why they are mentioned by name.  GPL

always strives to make it abundantly clear to anyone who receives the

software what its license is.  The goal is to make sure users know their

rights and freedoms under GPL, and to leave no reason that users might be

surprised the software is GPL'd. Thus

throughout the GPL, there are specific references to the importance of

notifying others down the distribution chain that they have rights under

GPL.

Also mentioned by name is the warranty disclaimer. Most people today do

not believe that software comes with any warranty.  Notwithstanding the

\href{http://mlis.state.md.us/2000rs/billfile/hb0019.htm}{Maryland's} and \href{http://leg1.state.va.us/cgi-bin/legp504.exe?001+ful+SB372ER}{Virginia's} UCITA bills, there are few or no implied warranties with software.

However, just to be on the safe side, GPL clearly disclaims them, and the

GPL requires re distributors to keep the disclaimer very visible. (See

Sections~\ref{GPLv2s11} and~\ref{GPLv2s12} of this tutorial for more on GPL's

warranty disclaimers.)

Note finally that GPLv2~\S1 creates groundwork for the important defense of

commercial freedom.  GPLv2~\S1 clearly states that in the case of verbatim

copies, one may make money.  Re distributors are fully permitted to charge

for the redistribution of copies of Free Software. In addition, they may

provide the warranty protection that the GPL disclaims as an additional

service for a fee. (See Section~\ref{Business Models} for more discussion

on making a profit from Free Software redistribution.)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Derivative Works: Statute and Case Law}

We digress for this chapter from our discussion of GPL's exact text to

consider the matter of derivative works --- a concept that we must

understand fully before considering GPLv2~\S\S2--3\@. GPL, and Free

Software licensing in general, relies critically on the concept of

``derivative work'' since software that is ``independent,'' (i.e., not

``derivative'') of Free Software need not abide by the terms of the

applicable Free Software license. As much is required by \S~106 of the

Copyright Act, 17 U.S.C. \S~106 (2002), and admitted by Free Software

licenses, such as the GPL, which (as we have seen) states in GPLv2~\S0 that ``a

`work based on the Program' means either the Program or any derivative

work under copyright law.'' It is being a derivative work of Free Software

that triggers the necessity to comply with the terms of the Free Software

license under which the original work is distributed. Therefore, one is

left to ask, just what is a ``derivative work''? The answer to that

question differs depending on which court is being asked.

The analysis in this chapter sets forth the differing definitions of

derivative work by the circuit courts. The broadest and most

established definition of derivative work for software is the

abstraction, filtration, and comparison test (``the AFC test'') as

created and developed by the Second Circuit. Some circuits, including

the Ninth Circuit and the First Circuit, have either adopted narrower

versions of the AFC test or have expressly rejected the AFC test in

favor of a narrower standard. Further, several other circuits have yet

to adopt any definition of derivative work for software.

As an introductory matter, it is important to note that literal copying of

a significant portion of source code is not always sufficient to establish

that a second work is a derivative work of an original

program. Conversely, a second work can be a derivative work of an original

program even though absolutely no copying of the literal source code of

the original program has been made. This is the case because copyright

protection does not always extend to all portions of a program's code,

while, at the same time, it can extend beyond the literal code of a

program to its non-literal aspects, such as its architecture, structure,

sequence, organization, operational modules, and computer-user interface.

\section{The Copyright Act}

The copyright act is of little, if any, help in determining the definition

of a derivative work of software. However, the applicable provisions do

provide some, albeit quite cursory, guidance. Section 101 of the Copyright

Act sets forth the following definitions:

\begin{quotation}

A ``computer program'' is a set of statements or instructions to be used

directly or indirectly in a computer in order to bring about a certain

result.

A ``derivative work'' is a work based upon one or more preexisting works,

such as a translation, musical arrangement, dramatization,

fictionalization, motion picture version, sound recording, art

reproduction, abridgment, condensation, or any other form in which a work

may be recast, transformed, or adapted. A work consisting of editorial

revisions, annotations, elaborations, or other modifications which, as a

whole, represent an original work of authorship, is a ``derivative work.''

\end{quotation}

These are the only provisions in the Copyright Act relevant to the

determination of what constitutes a derivative work of a computer

program. Another provision of the Copyright Act that is also relevant to

the definition of derivative work is \S~102(b), which reads as follows:

\begin{quotation}

In no case does copyright protection for an original work of authorship

extend to any idea, procedure, process, system, method of operation,

concept, principle, or discovery, regardless of the form in which it is

described, explained, illustrated, or embodied in such work.

\end{quotation}

Therefore, before a court can ask whether one program is a derivative work

of another program, it must be careful not to extend copyright protection

to any ideas, procedures, processes, systems, methods of operation,

concepts, principles, or discoveries contained in the original program. It

is the implementation of this requirement to ``strip out'' unprotectable

elements that serves as the most frequent issue over which courts

disagree.

\section{Abstraction, Filtration, Comparison Test}

As mentioned above, the AFC test for determining whether a computer

program is a derivative work of an earlier program was created by the

Second Circuit and has since been adopted in the Fifth, Tenth, and

Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982

F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural

Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe,

Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates

Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993);

Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman

v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings,

Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).

Under the AFC test, a court first abstracts from the original program its

constituent structural parts. Then, the court filters from those

structural parts all unprotectable portions, including incorporated ideas,