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 choose (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 choose 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 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 before it,

GPLv2 remains an integral part of the copyleft licensing infrastructure.  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 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 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 otherwise 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 a larger work so as to criticize or suggest

changes.  This fair use right 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 to 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

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

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}

\label{derivative-works}

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

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