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 re-distribution 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}

\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

understand fully before considering GPLv2~\S\S2--3\@. The 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,

constants, 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

ultimate inquiry is whether there is ``substantial'' similarity between

the protected elements of the original program and the potentially

derivative work. The courts admit that this process is primarily

qualitative rather than quantitative and is performed on a case-by-case

basis. In essence, the comparison is an ad hoc determination of whether

the protectable elements of the original program that are contained in the

second work are significant or important parts of the original program. If

so, then the second work is a derivative work of the first. If, however,

the amount of protectable elements copied in the second work are so small

as to be de minimis, then the second work is not a derivative work of the

original.

\section{Analytic Dissection Test}

The Ninth Circuit has adopted the analytic dissection test to determine

whether one program is a derivative work of another. Apple Computer,

Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic

dissection test first considers whether there are substantial similarities

in both the ideas and expressions of the two works at issue. Once the

similar features are identified, analytic dissection is used to determine

whether any of those similar features are protected by copyright. This

step is the same as the filtration step in the AFC test. After identifying

the copyrightable similar features of the works, the court then decides

whether those features are entitled to ``broad'' or ``thin''

protection. ``Thin'' protection is given to non-copyrightable facts or

ideas that are combined in a way that affords copyright protection only

from their alignment and presentation, while ``broad'' protection is given

to copyrightable expression itself. Depending on the degree of protection

afforded, the court then sets the appropriate standard for a subjective

comparison of the works to determine whether, as a whole, they are

sufficiently similar to support a finding that one is a derivative work of

the other. ``Thin'' protection requires the second work be virtually

identical in order to be held a derivative work of an original, while

``broad'' protection requires only a ``substantial similarity.''

\section{No Protection for ``Methods of Operation''}

The First Circuit has taken the position that the AFC test is inapplicable 

when the works in question relate to unprotectable elements set forth in 

\S~102(b).  Their approach results in a much narrower definition

of derivative work for software in comparison to other circuits. Specifically, 

the

First Circuit holds that ``method of operation,'' as used in \S~102(b) of

the Copyright Act, refers to the means by which users operate

computers. Lotus Development Corp. v. Borland Int'l., Inc., 49 F.3d 807

(1st Cir. 1995).  In Lotus, the court held that a menu command

hierarchy for a computer program was uncopyrightable because it did not

merely explain and present the program's functional capabilities to the

user, but also served as a method by which the program was operated and

controlled. As a result, under the First Circuit's test, literal copying

of a menu command hierarchy, or any other ``method of operation,'' cannot

form the basis for a determination that one work is a derivative of

another.  As a result, courts in the First Circuit that apply the AFC test

do so only after applying a broad interpretation of \S~102(b) to filter out

unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc., 

683 F. Supp.2d 147, 154 (D. Mass. 2010).

\section{No Test Yet Adopted}

Several circuits, most notably the Fourth and Seventh, have yet to

declare their definition of derivative work and whether or not the

AFC, Analytic Dissection, or some other test best fits their

interpretation of copyright law. Therefore, uncertainty exists with

respect to determining the extent to which a software program is a

derivative work of another in those circuits. However, one may presume

that they would give deference to the AFC test since it is by far the

majority rule among those circuits that have a standard for defining

a software derivative work.

\section{Cases Applying Software Derivative Work Analysis}

In the preeminent case regarding the definition of a derivative work for

software, Computer Associates v. Altai, the plaintiff alleged that its

program, Adapter, which was used to handle the differences in operating

system calls and services, was infringed by the defendant's competitive

program, Oscar. About 30\% of Oscar was literally the same code as

that in Adapter. After the suit began, the defendant rewrote those

portions of Oscar that contained Adapter code in order to produce a new

version of Oscar that was functionally competitive with Adapter, without

having any literal copies of its code. Feeling slighted still, the

plaintiff alleged that even the second version of Oscar, despite having no

literally copied code, also infringed its copyrights. In addressing that

question, the Second Circuit promulgated the AFC test.

In abstracting the various levels of the program, the court noted a

similarity between the two programs' parameter lists and macros. However,

following the filtration step of the AFC test, only a handful of the lists

and macros were protectable under copyright law because they were either

in the public domain or required by functional demands on the

program. With respect to the handful of parameter lists and macros that

did qualify for copyright protection, after performing the comparison step

of the AFC test, it was reasonable for the district court to conclude that

they did not warrant a finding of infringement given their relatively minor

contribution to the program as a whole. Likewise, the similarity between

the organizational charts of the two programs was not substantial enough

to support a finding of infringement because they were too simple and

obvious to contain any original expression.

In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012),

the Northern District of California District Court examined the question of 

whether the application program interfaces (APIs) associated with the Java

programming language are entitled to copyright protection.  While the 

court expressly declined to rule whether all APIs are free to use without 

license (872 F. Supp.2d 974 at 1002), the court held that the command 

structure and taxonomy of the APIs were not protectable under copyright law.

Specifically, the court characterized the command structure and taxonomy as

both a ``method of operation'' (using an approach not dissimilar to the 

First Circuit's analysis in Lotus) and a ``functional requirement for 

compatibility'' (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and

Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies),

and thus unprotectable subject matter under \S~102(b). 

Perhaps not surprisingly, there have been few other cases involving a highly

detailed software derivative work analysis. Most often, cases involve

clearer basis for decision, including frequent bad faith on the part of

the defendant or over-aggressiveness on the part of the plaintiff.  

\section{How Much Do Derivative Works Matter?}

It is certainly true that GPL intends for any work that is determined a

``derivative work'' under copyright law must be licensed as a whole under

GPL\@, as will be discussed in the following chapter.  However, as we finish

up our discussion derivative works, we must note that preparation of a

derivative work is by far not the only way to create a new work covered by

GPL\@.

In fact, while derivative work preparation is perhaps the most exciting area

of legal issues to consider, the more mundane ways to create a new work

covered by GPL are much more common.  For example, copyright statutes

generally require permission from the copyright holder to grant explicit

permission to modify a work in any manner.  As discussed in the next chapter,

also be licensed under the terms of the GPL (and only GPL:

see\S~\label{GPLv2s6} in this tutorial).  Determining whether software was

modified is a substantially easier analysis than the derivative work

discussions and considerations in this chapter.

The question of derivative works, when and how they are made, is undoubtedly

an essential discussion in the interpretation and consideration of copyleft.

That is why this chapter was included in this tutorial.  However, as we

return from this digression and resume discussion of the detailed text of the

GPLv2, we must gain a sense of perspective: most GPL questions center around

questions of modification and distribution, not preparation of derivative

works.  Derivative work preparation is ultimately a small subset of the types

of modified versions of the software a developer might create, thus, while an

excessive focus on derivative works indulges us in the more exciting areas of

copyleft, we must keep a sense of perspective regarding their relative

importance.

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

\chapter{Modified Source and Binary Distribution}

\label{source-and-binary}

In this chapter, we discuss the two core sections that define the rights

and obligations for those who modify, improve, and/or redistribute GPL'd

software. These sections, GPLv2~\S\S2--3, define the central core rights and

requirements of GPLv2\@.

\section{GPLv2~\S2: Share and Share Alike}

\label{GPLv2s2}

For many, this is where the ``magic'' happens that defends software

freedom upon redistribution.  GPLv2~\S2 is the only place in GPLv2

that governs the modification controls of copyright law.  If users

distribute modified versions a GPLv2'd program, they must follow the terms of GPLv2~\S2 in making

those changes.  Thus, this sections ensures that the body of GPL'd software, as it

continues and develops, remains Free as in freedom.

To achieve that goal, GPLv2~\S2 first sets forth that the rights of

redistribution of modified versions are the same as those for verbatim

copying, as presented in GPLv2~\S1.  Therefore, the details of charging money,

keeping copyright notices intact, and other GPLv2~\S1 provisions are intact

here as well.  However, there are three additional requirements.

The first (GPLv2~\S2(a)) requires that modified files carry ``prominent

notices'' explaining what changes were made and the date of such

changes. This section does not prescribe some specific way of

marking changes nor does it control the process of how changes are made.

Primarily, GPLv2~\S2(a) seeks to ensure that those receiving modified

versions know the history of changes to the software.  For some users,

it is important to know that they are using the standard version of

program, because while there are many advantages to using a fork,

there are a few disadvantages.  Users should be informed about the

historical context of the software version they use, so that they can

make proper support choices.  Finally, GPLv2~\S2(a) serves an academic

purpose --- ensuring that future developers can use a diachronic

approach to understand the software.

\medskip

The second requirement (GPLv2~\S2(b)) contains the four short lines that embody

the legal details of ``share and share alike''.  These 46 words are

considered by some to be the most worthy of careful scrutiny because

GPLv2~\S2(b), and they

can be a source of great confusion when not properly understood.

In considering GPLv2~\S2(b), first note the qualifier: it \textit{only} applies to

derivative, combined and/or modified works that ``you distribute or publish''.  Despite years of

education efforts on this matter, many still believe that modifiers

of GPL'd software \textit{must} publish or otherwise

share their changes.  On the contrary, GPLv2~\S2(b) {\bf does not apply if} the

changes are never distributed.  Indeed, the freedom to make private,

personal, unshared changes to software for personal use only should be

protected and defended.\footnote{Most Free Software enthusiasts believe there is a {\bf

    moral} obligation to redistribute changes that are generally useful,

  and they often encourage companies and individuals to do so.  However, there

  is a clear distinction between what one {\bf ought} to do and what one

  {\bf must} do.}

Next, we again encounter the same matter that appears in GPLv2~\S0, in the

following text:

\begin{quote}

``...that in whole or part contains or is derived from the Program or any part thereof.''

\end{quote}

Again, the GPL relies here on copyright law.

If, under copyright law, the modified version ``contains or is

derived from'' the GPL'd software, then the requirements of GPLv2~\S2(b)

apply.  The GPL invokes its control as a copyright license over the

modification of the work in combination with its control over distribution

of the work.

The final clause of GPLv2~\S2(b) describes what the licensee must do if she

distributes or publishes a modified version of the work --- namely, the following:

\begin{quote}

[The work must] be licensed as a whole at no charge to all third parties

under the terms of this License.

\end{quote}

That is probably the most tightly-packed phrase in all of the GPL\@.

Consider each subpart carefully.

The work ``as a whole'' is what is to be licensed. This is an important

point that GPLv2~\S2 spends an entire paragraph explaining; thus this phrase is

worthy of a lengthy discussion here.  As a programmer modifies a software

program, she generates new copyrighted material --- fixing expressions of

ideas into the tangible medium of electronic file storage.  That

programmer is indeed the copyright holder of those new changes.  However,

those changes are part and parcel to the original work distributed to

the programmer under GPL\@. Thus, the license of the original work

affects the license of the new whole combined and/or derivative work.

% {\cal I}

\newcommand{\gplusi}{$\mathcal{G\!\!+\!\!I}$}

\newcommand{\worki}{$\mathcal{I}$}

\newcommand{\workg}{$\mathcal{G}$}

\label{separate-and-independent}

It is certainly possible to take an existing independent work (called

\worki{}) and combine it with a GPL'd program (called \workg{}).  The

license of \worki{}, when it is distributed as a separate and independent

work, remains the prerogative of the copyright holder of \worki{}.

However, when \worki{} is combined with \workg{}, it produces a new work

that is the combination of the two (called \gplusi{}). The copyright of

this combined work, \gplusi{}, is held by the original copyright

holder of each of the two works.

In this case, GPLv2~\S2 lays out the terms by which \gplusi{} may be

distributed and copied.  By default, under copyright law, the copyright

holder of \worki{} would not have been permitted to distribute \gplusi{};

copyright law forbids it without the expressed permission of the copyright

holder of \workg{}. (Imagine, for a moment, if \workg{} were a proprietary

product --- would its copyright holders  give you permission to create and distribute

\gplusi{} without paying them a hefty sum?)  The license of \workg{}, the

GPL, states the  options for the copyright holder of \worki{}

who may want to create and distribute \gplusi{}. The  GPL's pre-granted

permission to create and distribute combined and/or derivative works, provided the terms

of the GPL are upheld, goes far above and beyond the permissions that one

would get with a typical work not covered by a copyleft license.  (Thus, to

say that this condition is any way unreasonable is simply ludicrous.)

\medskip

\label{GPLv2s2-at-no-charge}

The next phrase of note in GPLv2~\S2(b) is ``licensed \ldots at no charge.''

This phrase  confuses many.  The sloppy reader points out this as ``a

contradiction in GPL'' because (in their confused view) that clause of GPLv2~\S2 says that re-distributors cannot

charge for modified versions of GPL'd software, but GPLv2~\S1 says that

they can.  Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit re-distributors from

charging when performing the acts governed by copyright

law,\footnote{Recall that you could by default charge for any acts not

governed by copyright law, because the license controls are confined

by copyright.} but rather that they cannot charge a fee for the

\emph{license itself}.  In other words, redistributors of (modified

and unmodified) GPL'd works may charge any amount they choose for

performing the modifications on contract or the act of transferring

the copy to the customer, but they may not charge a separate licensing

fee for the software.

GPLv2~\S2(b) further states that the software must ``be licensed \ldots to all

third parties.''  This too yields some confusion, and feeds the

misconception mentioned earlier --- that all modified versions must be made

available to the public at large.  However, the text here does not say

that.  Instead, it says that the licensing under terms of the GPL must

extend to anyone who might, through the distribution chain, receive a copy

of the software.  Distribution to all third parties is not mandated here,

but GPLv2~\S2(b) does require re-distributors to license the whole work in

a way that extends to all third parties who may ultimately receive a

copy of the software.

In summary, GPLv2\ 2(b) says what terms under which the third parties must

receive this no-charge license.  Namely, they receive it ``under the terms

of this License'', the GPLv2.  When an entity \emph{chooses} to redistribute

a work based on GPL'd software, the license of that whole 

work must be GPL and only GPL\@.  In this manner, GPLv2~\S2(b) dovetails nicely

with GPLv2~\S6 (as discussed in Section~\ref{GPLv2s6} of this tutorial).

\medskip

The final paragraph of GPLv2~\S2 is worth special mention.  It is possible and

quite common to aggregate various software programs together on one

distribution medium.  Computer manufacturers do this when they ship a

pre-installed hard drive, and GNU/Linux distribution vendors do this to

give a one-stop CD or URL for a complete operating system with necessary

applications.  The GPL very clearly permits such ``mere aggregation'' with

programs under any license.  Despite what you hear from its critics, the

GPL is nothing like a virus, not only because the GPL is good for you and

a virus is bad for you, but also because simple contact with a GPL'd

code-base does not impact the license of other programs.  A programmer must

expend actual effort  to cause a work to fall under the terms

of the GPL.  Redistributors are always welcome to simply ship GPL'd

software alongside proprietary software or other unrelated Free Software,

as long as the terms of GPL are adhered to for those packages that are

truly GPL'd.

\subsection{Right to Private Modification} 

\label{gplv2-private-modification}

The issue of private modifications of GPLv2'd works deserves special

attention.  While these rights are clearly explicit in GPLv3~\S2\P2 (see

\S~\ref{GPLv3S2} of this tutorial for details), the permission to create

private modifications is mostly implicit in GPLv2.  Most notably, the

requirements of GPLv2~\S2 (and GPLv2~\S3, which will be discussed next) are

centered around two different copyright controls: both modification

\emph{and} distribution.  As such, GPLv2~\S2's requirements need only be met

when a modified version is distributed; one need not follow them for modified

versions that are not distributed\footnote{As a matter of best practice, it's

  useful to assume that all software may eventually be distributed later,

  even if there no plans for distribution at this time.  Too often, GPL

  violations occur because of a late distribution decision of software that

  was otherwise never intended for distribution.}.

However, the careful reader of GPLv2 will notice that, unlike GPLv3, no other

clauses of the license actually give explicit permission to make private

modifications.  Since modification of software is a control governed by

copyright, a modifier needs permission from the copyright holder to engage in

that activity.

In practice, however, traditional GPLv2 interpretation has always assumed

that blanket permission to create non-distributed modified versions was

available, and the

\href{http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic}{FSF

  has long opined that distribution of modified versions is never mandatory}.

This issue is one of many where GPLv3 clarifies in explicit text the implicit

policy and intent that was solidified via long-standing interpretation of

GPLv2.

\section{GPLv2~\S3: Producing Binaries}

\label{GPLv2s3}

Software is a strange beast when compared to other copyrightable works.

It is currently impossible to make a film or a book that can be truly

obscured.  Ultimately, the full text of a novel, even one written by

William Faulkner, must be presented to the reader as words in some

human-readable language so that they can enjoy the work.  A film, even one

directed by David Lynch, must be perceptible by human eyes and ears to

have any value.

Software is not so.  While the source code --- the human-readable

representation of software --- is of keen interest to programmers, users and

programmers alike cannot make the proper use of software in that

human-readable form.  Binary code --- the ones and zeros that the computer

can understand --- must be predicable and attainable for the software to

be fully useful.  Without the binaries, be they in object or executable

form, the software serves only the didactic purposes of computer science.

Under copyright law, binary representations of the software are simply

modified versions (and/or derivative works) of the source code.  Applying a systematic process (i.e.,

``compilation''\footnote{``Compilation'' in this context refers to the

  automated computing process of converting source code into binaries.  It

  has absolutely nothing to do with the term ``compilation'' in copyright statues.}) to a work of source code yields binary code. The binary

code is now a new work of expression fixed in the tangible medium of

electronic file storage.

Therefore, for GPL'd software to be useful, the GPL, since it governs the

rules for creation of modified works, must grant permission for the

generation of binaries.  Furthermore, notwithstanding the relative

popularity of source-based GNU/Linux distributions like Gentoo, users find

it extremely convenient to receive distribution of binary software.  Such

distribution is the redistribution of modified works of the software's

source code.  GPLv2~\S3 addresses the matter of creation and distribution of

binary versions.

Under GPLv2~\S3, binary versions may be created and distributed under the

terms of GPLv2~\S1--2, so all the material previously discussed applies

here.  However, GPLv2~\S3 must go a bit further.  Access to the software's

source code is an incontestable prerequisite for the exercise of the

fundamental freedoms to modify and improve the software.  Making even

the most trivial changes to a software program at the binary level is

effectively impossible.  GPLv2~\S3 must ensure that the binaries are never

distributed without the source code, so that these freedoms are passed

through the distribution chain.

GPLv2~\S3 permits distribution of binaries, and then offers three options for

distribution of source code along with binaries. The most common and the

least complicated is the option given under GPLv2~\S3(a).

GPLv2~\S3(a) offers the option to directly accompany the source code alongside

the distribution of the binaries.  This is by far the most convenient

option for most distributors, because it means that the source-code

provision obligations are fully completed at the time of binary

distribution (more on that later).

Under GPLv2~\S3(a), the source code provided must be the ``corresponding source

code.''  Here ``corresponding'' primarily means that the source code

provided must be that code used to produce the binaries being distributed.

That source code must also be ``complete''.   GPLv2~\S3's penultimate paragraph

explains in detail what is meant by ``complete''.  In essence, it is all

the material that a programmer of average skill would need to actually use

the source code to produce the binaries she has received.  Complete source

is required so that, if the licensee chooses, she should be able to

exercise her freedoms to modify and redistribute changes.  Without the

complete source, it would not be possible to make changes that were

actually directly derived from the version received.

Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been

seen in GPL enforcement.  Under GPL, if you pay a high price for

a copy of GPL'd binaries (which comes with corresponding source, of

course), you have the freedom to redistribute that work at any fee you

choose, or not at all.  Sometimes, companies attempt a GPL-violating

cozenage whereby they produce very specialized binaries (perhaps for

an obscure architecture).  They then give source code that does

correspond, but withhold the ``incantations'' and build plans they

used to make that source compile into the specialized binaries.

Therefore, GPLv2~\S3 requires that the source code include ``meta-material'' like

scripts, interface definitions, and other material that is used to

``control compilation and installation'' of the binaries.  In this

manner, those further down the distribution chain are assured that

they have the unabated freedom to build their own modified works

from the sources provided.

Software distribution comes in many

forms.  Embedded manufacturers, for example, have the freedom to put

GPL'd software into mobile devices with very tight memory and space

constraints.  In such cases, putting the source right alongside the

binaries on the machine itself might not be an option.  While it is

recommended that this be the default way that people comply with GPL, the

GPL does provide options when such distribution is unfeasible.

\label{GPLv2s3-medium-customarily}

GPLv2~\S3, therefore, allows source code to be provided on any physical

``medium customarily used for software interchange.''  By design, this

phrase covers a broad spectrum --- the phrase seeks to pre-adapt to

changes in  technology.  When GPLv2 was first published in June

1991, distribution on magnetic tape was still common, and CD was

relatively new.  By 2002, CD was the default.  By 2007, DVD's were the

default.  Now, it's common to give software on USB drives and SD cards.  This

language in the license must adapt with changing technology.

Meanwhile, the binding created by the word ``customarily'' is key.  Many

incorrectly believe that distributing binary on CD and source on the

Internet is acceptable.  In the corporate world in industrialized countries, it is indeed customary to

simply download a CDs' worth of data quickly.  However, even today in the USA, many computer users are not connected to the Internet, and most people connected

to the Internet still have limited download speeds.  Downloading

CDs full of data is not customary for them in the least.  In some cities

in Africa, computers are becoming more common, but Internet connectivity

is still available only at a few centralized locations.  Thus, the

``customs'' here are normalized for a worldwide userbase.  Simply

providing source on the Internet --- while it is a kind, friendly and

useful thing to do --- is not usually sufficient.

Note, however, a major exception to this rule, given by the last paragraph

of GPLv2~\S3. \emph{If} distribution of the binary files is made only on the

Internet (i.e., ``from a designated place''), \emph{then} simply providing

the source code right alongside the binaries in the same place is

sufficient to comply with GPLv2~\S3.

\medskip

As is shown above, under GPLv2~\S3(a), embedded manufacturers can put the

binaries on the device and ship the source code along on a CD\@.  However,

sometimes this turns out to be too costly.  Including a CD with every

device could prove too costly, and may practically (although not legally)

prohibit using GPL'd software. For this situation and others like it, GPLv2\S~3(b) is available.

GPLv2~\S3(b) allows a distributor of binaries to instead provide a written

offer for source code alongside those binaries.  This is useful in two

specific ways.  First, it may turn out that most users do not request the

source, and thus the cost of producing the CDs is saved --- a financial

and environmental windfall.  In addition, along with a GPLv2~\S3(b) compliant

offer for source, a binary distributor might choose to \emph{also} give a

URL for source code.  Many who would otherwise need a CD with source might

turn out to have those coveted high bandwidth connections, and are able to

download the source instead --- again yielding environmental and financial

windfalls.

However, note that regardless of how many users prefer to get the

source online, GPLv2~\S3(b) does place lasting long-term obligations on the

binary distributor.  The binary distributor must be prepared to honor

that offer for source for three years and ship it out (just as they

would have had to do under GPLv2~\S3(a)) at a moment's notice when they

receive such a request.  There is real organizational cost here:

support engineers must be trained how to route source requests, and

source CD images for every release version for the last three years

must be kept on hand to burn such CDs quickly. The requests might not

even come from actual customers; the offer for source must be valid

for ``any third party''.

That phrase is another place where some get confused --- thinking again

that full public distribution of source is required.  The offer for source

must be valid for ``any third party'' because of the freedoms of

redistribution granted by GPLv2~\S\S1--2.  A company may ship a binary image

and an offer for source to only one customer.  However, under GPL, that

customer has the right to redistribute that software to the world if she

likes.  When she does, that customer has an obligation to make sure that

those who receive the software from her can exercise their freedoms under