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,

the GPL {\em does} grants such permission, but requires the modified work must

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

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}

%FIXME-URGENT: integrate

But the GNU GPL licenses recognize what is outside their scope. Where a programmer’s work is

``separate and independent'' from any GPL’d program code with which it could be

combined, then the obligations of copyleft do not extend to the work

separately distributed. Far from attempting to extend copyleft beyond the

scope of copyright, the licenses explicitly recognize.

%FIXME-URGENT: end

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

% FIXME-URGENT: integrate

The GPL licenses, then, are explicit about limiting the scope of copyleft to

the scope of copyright.  They do not, however, as is sometimes suggested, do

so in a way that distinguishes ``dynamic'' from ``static'' linking of program

code in ``early-binding'' programming languages. It is occasionally suggested

that a subroutine ``dynamically'' linked to GPL’d code is, by virtue of the

linking alone, inherently outside the scope of copyleft on the main

work. This is a misunderstanding. When two software components are joined