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