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

\part{A Practical Guide to GPL Compliance}

\label{gpl-compliance-guide}

{\parindent 0in

This part is: \\

\begin{tabbing}

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

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

\end{tabbing}

\vspace{1in}

\begin{center}

Authors of this part are: \\

Bradley M. Kuhn \\

Aaron Williamson \\

Karen M. Sandler \\

\vspace{3in}

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

\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=. 

\end{center}

}

\bigskip

\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

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 it also

endangers GPL compliance, which requires you to provide build scripts.

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}

In this section, we explain the specific requirements placed upon

distributors of GPL'd software.  Note that this section refers heavily to

specific provisions and language in

\href{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section3}{GPLv2}

and \href{http://www.fsf.org/licensing/licenses/gpl.html#section6}{GPLv3}.

It may be helpful to have a copy of each license open while reading this

section.

\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.\footnote{For a full discussion of this concept, please see

\ifpdf

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-40002}{the

  chapter entitled ``Common Copyright Questions''} in SFLC's publication,

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.pdf}{\textit{A

    Legal Issues Primer for Open Source and Free Software Projects}}.

\else

\ifx \generateHTML \isGeneratingHTML

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-40002}{the

  chapter entitled ``Common Copyright Questions''} in SFLC's publication

\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html}{\textit{A

    Legal Issues Primer for Open Source and Free Software Projects}}.

\else

the chapter entitled ``Common Copyright Questions'' in SFLC's publication,

\textit{A Legal Issues Primer for Open Source and Free Software

  Projects}.

\fi

\fi

}

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

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.

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

  \S~\ref{GPLv2s3} in this tutorial).

\end{itemize}

The next chapter discusses GPLv2 in full detail, and readers who wish to dive

into the section-by-section discussion of the GPL should jump ahead now to

that chapter.  However, the most interesting fact to note here is how GPLv2

was published with little fanfare and limited commentary.  This contrasts

greatly with the creation of GPLv3.

\section{The GNU General Public License, Version 3}

RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups

during that era about new text of that license.  However, rampant violations

of the GPL required more immediate attention of FSF's licensing staff, and as

such, much of the early 2000's was spent doing GPL enforcement

work\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a

    companion tutorial, \textit{A Practical Guide to GPL

      Compliance}}{Part~\ref{gpl-compliance-guide} of this tutorial}.}.  In

2006, FSF began in earnest drafting work for GPLv3.

The GPLv3 process began in earnest in January 2006.  It became clear that

many provisions of the GPL could benefit from modification to fit new

circumstances and to reflect what the entire community learned from

experience with version 2.  Given the scale of revision it seems proper to

approach the work through public discussion in a transparent and accessible

manner.

The GPLv3 process continued through June 2007, culminating in publication of

GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC

Runtime Library Exception on 27 January 2009.

All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3

and two discussion drafts of AGPLv3 were published and discussed.

Ultimately, FSF remained the final arbiter and publisher of the licenses, and

RMS himself their primary author, but input was sought from many parties, and

these licenses do admittedly look and read more like legislation as a result.

Nevertheless, all of the ``v3'' group are substantially better and improved

licenses.

GPLv3 and its terms are discussed in detail in Chapter\~ref{GPLv3}.

\section{The Innovation of Optional ``Or Any Later'' Version}

An interesting fact of all GPL licenses is that the are ultimate multiple

choices for use of the license.  The FSF is the primary steward of GPL (as

discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv3s14}).  However, those

who wish to license works under GPL are not required to automatically accept

changes made by the FSF for their own copyrighted works.

Each licensor may chose three different methods of licensing, as follows:

\begin{itemize}

\item explicitly name a single version of GPL for their work (usually

  indicated in shorthand by saying the license is ``GPLv$X$-only''), or

\item name no version of the GPL, thus they allow their downstream recipients

  to select any version of the GPL they chose (usually indicated in shorthand

  by saying the license is simply ``GPL''), or

\item name a specific version of GPL and give downstream recipients the

  option to chose that version ``or any later version as published by the

  FSF'' (usually indicated by saying the license is

  ``GPLv$X$-or-later'')\footnote{The shorthand of ``GPL$X+$'' is also popular

    for this situation.  The authors of this tutorial prefer ``-or-later''

    syntax, because it (a) mirrors the words ``or'' and ``later from the

    licensing statement, (b) the $X+$ doesn't make it abundantly clear that

    $X$ is clearly included as a license option and (c) the $+$ symbol has

    other uses in computing (such as with regular expressions) that mean

    something different.}

\end{itemize}

\label{license-compatibility-first-mentioned}

Oddly, this flexibility has received (in the opinion of the authors, undue)

criticism, primarily because of the complex and oft-debated notion of

``license compatibility'' (which is explained in detail in

\S~\ref{license-compatibility}).  Copyleft licenses are generally

incompatible with each other, because the details of how they implement

copyleft differs.  Specifically, copyleft works only because of its

requirement that downstream licensors use the \textit{same} license for

combined and modified works.  As such, software licensed under the terms of

``GPLv2-only'' cannot be combined with works licensed ``GPLv3-or-later''.

This is admittedly a frustrating outcome.

Other copyleft licenses that appeared after GPL, such

as the Creative Commons ``Share Alike'' licenses, the Eclipse Public License

and the Mozilla Public License \textbf{require} all copyright holders choosing

to use any version of those licenses to automatically accept and relicense

their copyrighted works under new versions.  Of course ,Creative Commons, the

Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally

served as excellent stewards of their licenses.  Copyright holders using

those licenses seems to find it acceptable that to fully delegate all future

licensing decisions for their copyrights to these organizations without a

second thought.

However, note that FSF gives herein the control of copyright holders to

decide whether or not to implicitly trust the FSF in its work of drafting

future GPL versions.  The FSF, for its part, does encourage copyright holders

to chose by default ``GPLv$X$-or-later'' (where $X$ is the most recent

version of the GPL published by the FSF).  However, the FSF \textbf{does not

  mandate} that a choice to use any GPL requires a copyright holder ceding

its authority for future licensing decisions to the FSF.  In fact, the FSF

considered this possibility for GPLv3 and chose not to do so, instead opting

for the third-party steward designation clause discussed in

Section~\ref{GPLv3s14}.

\section{Complexities of Two Simultaneously Popular Copylefts}

Obviously most GPL advocates would prefer widespread migration to GPLv3, and

many newly formed projects who seek a copyleft license tend to choose a

GPLv3-based license.  However, many existing copylefted projects continue

with GPLv2-only or GPLv2-or-later as their default license.

While GPLv3 introduces many improvements --- many of which were designed to

increase adoption by for-profit companies --- GPLv2 remains a widely used and

extremely popular license.  The GPLv2 is, no doubt, a good and useful

license.

However, unlike GPLv1, which (as pointed out in \S~\ref{GPLv1}), which is

completely out of use by the mid-1990s.  However, unlike GPLv1 before it,

GPLv2 remains a integral part of the copyleft licensing infrastructure for

some time to come.  As such, those who seek to have expertise in current

topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of

licenses.

Furthermore, GPLv3 can is more easily understood by first studying GPLv2.

This is not only because of their chronological order, but also because much

of the discussion material available for GPLv3 tends to talk about GPLv3 in

contrast to GPLv2.  As such, a strong understanding of GPLv2 helps in

understanding most of the third-party material found regarding GPLv3.  Thus,

the following chapter begins a deep discussion of GPLv2.

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

\chapter{Running Software and Verbatim Copying}

\label{run-and-verbatim}

This chapter begins the deep discussion of the details of the terms of

GPLv2\@. In this chapter, we consider the first two sections: GPLv2 \S\S

0--2. These are the straightforward sections of the GPL that define the

simplest rights that the user receives.

\section{GPLv2~\S0: Freedom to Run}

\label{GPLv2s0}

GPLv2~\S0, the opening section of GPLv2, sets forth that the copyright law governs

the work.  It specifically points out that it is the ``copyright

holder'' who decides if a work is licensed under its terms and explains

how the copyright holder might indicate this fact.

A bit more subtly, GPLv2~\S0 makes an inference that copyright law is the only

system that can restrict the software.  Specifically, it states:

\begin{quote}

Activities other than copying, distribution and modification are not

covered by this License; they are outside its scope.

\end{quote}

In essence, the license governs \emph{only} those activities, and all other

activities are unrestricted, provided that no other agreements trump GPLv2

(which they cannot; see Sections~\ref{GPLv2s6} and~\ref{GPLv2s7}).  This is

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,

expression that is necessarily incidental to those ideas, and elements

that are taken from the public domain. Finally, the court compares any and

all remaining kernels of creative expression to the structure of the

second program to determine whether the software programs at issue are

substantially similar so as to warrant a finding that one is the

derivative work of the other.

Often, the courts that apply the AFC test will perform a quick initial

comparison between the entirety of the two programs at issue in order to

help determine whether one is a derivative work of the other. Such a

holistic comparison, although not a substitute for the full application of

the AFC test, sometimes reveals a pattern of copying that is not otherwise

obvious from the application of the AFC test when, as discussed below,

only certain components of the original program are compared to the second

program. If such a pattern is revealed by the quick initial comparison,

the court is more likely to conclude that the second work is indeed a

derivative of the original.

\subsection{Abstraction}

The first step courts perform under the AFC test is separation of the

work's ideas from its expression. In a process akin to reverse

engineering, the courts dissect the original program to isolate each level

of abstraction contained within it. Courts have stated that the

abstractions step is particularly well suited for computer programs

because it breaks down software in a way that mirrors the way it is

typically created. However, the courts have also indicated that this step

of the AFC test requires substantial guidance from experts, because it is

extremely fact and situation specific.

By way of example, one set of abstraction levels is, in descending order

of generality, as follows: the main purpose, system architecture, abstract

data types, algorithms and data structures, source code, and object

code. As this set of abstraction levels shows, during the abstraction step

of the AFC test, the literal elements of the computer program, namely the

source and object code, are defined as particular levels of

abstraction. Further, the source and object code elements of a program are

not the only elements capable of forming the basis for a finding that a

second work is a derivative of the program. In some cases, in order to

avoid a lengthy factual inquiry by the court, the owner of the copyright in

the original work will submit its own list of what it believes to be the

protected elements of the original program. In those situations, the court

will forgo performing its own abstraction, and proceed to the second step of

the AFC test.

\subsection{Filtration}

The most difficult and controversial part of the AFC test is the second

step, which entails the filtration of protectable expression contained in

the original program from any unprotectable elements nestled therein. In

determining which elements of a program are unprotectable, courts employ a

myriad of rules and procedures to sift from a program all the portions

that are not eligible for copyright protection.

First, as set forth in \S~102(b) of the Copyright Act, any and all ideas

embodied in the program are to be denied copyright protection. However,

implementing this rule is not as easy as it first appears. The courts

readily recognize the intrinsic difficulty in distinguishing between ideas

and expression and that, given the varying nature of computer programs,

doing so will be done on an ad hoc basis. The first step of the AFC test,

the abstraction, exists precisely to assist in this endeavor by helping

the court separate out all the individual elements of the program so that

they can be independently analyzed for their expressive nature.

A second rule applied by the courts in performing the filtration step of

the AFC test is the doctrine of merger, which denies copyright protection

to expression necessarily incidental to the idea being expressed. The

reasoning behind this doctrine is that when there is only one way to

express an idea, the idea and the expression merge, meaning that the

expression cannot receive copyright protection due to the bar on copyright

protection extending to ideas. In applying this doctrine, a court will ask

whether the program's use of particular code or structure is necessary for

the efficient implementation of a certain function or process. If so, then

that particular code or structure is not protected by copyright and, as a

result, it is filtered away from the remaining protectable expression.

A third rule applied by the courts in performing the filtration step of

the AFC test is the doctrine of scenes a faire, which denies copyright

protection to elements of a computer program that are dictated by external

factors. Such external factors can include:

\begin{itemize}

  \item The mechanical

specifications of the computer on which a particular program is intended

to operate

  \item Compatibility requirements of other programs with which a

program is designed to operate in conjunction

  \item Computer manufacturers'

design standards

  \item Demands of the industry being serviced, and

widely accepted programming practices within the computer industry

\end{itemize}

Any code or structure of a program that was shaped predominantly in

response to these factors is filtered out and not protected by

copyright. Lastly, elements of a computer program are also to be filtered

out if they were taken from the public domain or fail to have sufficient

originality to merit copyright protection.

Portions of the source or object code of a computer program are rarely

filtered out as unprotectable elements. However, some distinct parts of

source and object code have been found unprotectable. For example,

constant s, the invariable integers comprising part of formulas used to

perform calculations in a program, are unprotectable. Further, although

common errors found in two programs can provide strong evidence of

copying, they are not afforded any copyright protection over and above the

protection given to the expression containing them.

\subsection{Comparison}

The third and final step of the AFC test entails a comparison of the

original program's remaining protectable expression to a second

program. The issue will be whether any of the protected expression is

copied in the second program and, if so, what relative importance the

copied portion has with respect to the original program overall. The