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

have 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.2nd 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 

compatability'' (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),

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 overaggressiveness on the part of the plaintiff.  

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

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

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

modifies 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 in tact

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 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} to 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 an {\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 what the copyright law says is a derivative

work.  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 is

distributing or publishing a work that is deemed a derivative work under

copyright law --- 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