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,

constant s, 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 

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

the

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

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

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

An interesting issue regarding this implied patent license of GPLv2'd

software is what would be considered ``uses of the [software] to which

the parties might reasonably contemplate the product will be put.'' A

clever advocate may argue that the implied license granted by GPLv2 is

larger in scope than the express license in other Free Software

licenses with express patent grants, in that the patent license

clause of many of those other Free  Software licenses are specifically 

limited to the patent claims covered by the code as licensed by the patentee.

In contrast, a GPLv2 licensee, under the doctrine of implied patent license, 

is free to practice any patent claims held by the licensor that cover 

``reasonably contemplated uses'' of the GPL'd code, which may very well 

include creation and distribution of derivative works since the GPL's terms, 

under which the patented code is distributed, expressly permits such activity.

Further supporting this result is the Federal Circuit's pronouncement that

the recipient of a patented article has, not only an implied license to

make, use, and sell the article, but also an implied patent license to

repair the article to enable it to function properly, Bottom Line Mgmt.,

Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the

Federal Circuit extended that rule to include any future recipients of the

patented article, not just the direct recipient from the distributor.

This theory comports well with the idea of Free Software, whereby software

is distributed amongst many entities within the community for the purpose

of constant evolution and improvement. In this way, the law of implied

patent license used by the GPLv2 ensures that the community mutually

benefits from the licensing of patents to any single community member.

Note that simply because GPLv2'd software has an implied patent license does

not mean that any patents held by a distributor of GPLv2'd code become

worthless. To the contrary, the patents are still valid and enforceable

against either:

\begin{enumerate}

 \renewcommand{\theenumi}{\alph{enumi}}

 \renewcommand{\labelenumi}{\textup{(\theenumi)}}

\item any software other than that licensed under the GPLv2 by the patent

  holder, and

\item any party that does not comply with the GPLv2

with respect to the licensed software.

\end{enumerate}

\newcommand{\compB}{$\mathcal{B}$}

\newcommand{\compA}{$\mathcal{A}$}

For example, if Company \compA{} has a patent on advanced Web browsing, but

also licenses a Web browsing software program under the GPLv2, then it

cannot assert the patent against any party based on that party's use of 

Company \compA{}'s GPL'ed Web browsing software program, or on that party's

creation and use of derivative works of that GPL'ed program.  However, if a

party uses that program without

complying with the GPLv2, then Company \compA{} can assert both copyright

infringement claims against the non-GPLv2-compliant party and

infringement of the patent, because the implied patent license only

extends to use of the software in accordance with the GPLv2. Further, if

Company \compB{} distributes a competitive advanced Web browsing program 

that is not a derivative work of Company \compA{}'s GPL'ed Web browsing software

program, Company \compA{} is free to assert its patent against any user or

distributor of that product. It is irrelevant whether Company \compB's

program is also distributed under the GPLv2, as Company \compB{} can not grant

implied licenses to Company \compA's patent.

This result also reassures companies that they need not fear losing their

proprietary value in patents to competitors through the GPLv2 implied patent

license, as only those competitors who adopt and comply with the GPLv2's

terms can benefit from the implied patent license. To continue the

example above, Company \compB{} does not receive a free ride on Company

\compA's patent, as Company \compB{} has not licensed-in and then

redistributed Company A's advanced Web browser under the GPLv2. If Company

\compB{} does do that, however, Company \compA{} still has not lost

competitive advantage against Company \compB{}, as Company \compB{} must then,

when it re-distributes Company \compA's program, grant an implied license

to any of its patents that cover the program. Further, if Company \compB{}

relicenses an improved version of Company A's program, it must do so under

the GPLv2, meaning that any patents it holds that cover the improved version

are impliedly licensed to any licensee. As such, the only way Company

\compB{} can benefit from Company \compA's implied patent license, is if it,

itself, distributes Company \compA's software program and grants an

implied patent license to any of its patents that cover that program.

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

\chapter{Defending Freedom on Many Fronts}

Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the

core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3.

GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are

not infringed, are enforceable, are kept to the confines of copyright law but

also  not trumped by other copyright agreements or components of other

entirely separate legal systems.  In short, while GPLv2~\S\S0--3 are the parts

of the license that defend the freedoms of users and programmers,

GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear

\section{GPLv2~\S4: Termination on Violation}

\label{GPLv2s4}

GPLv2~\S4 is GPLv2's termination clause.  Upon first examination, it seems

strange that a license with the goal of defending users' and programmers'

freedoms for perpetuity in an irrevocable way would have such a clause.

However, upon further examination, the difference between irrevocability

and this termination clause becomes clear.

The GPL is irrevocable in the sense that once a copyright holder grants

rights for someone to copy, modify and redistribute the software under terms

of the GPL, they cannot later revoke that grant.  Since the GPL has no

provision allowing the copyright holder to take such a prerogative, the

license is granted as long as the copyright remains in effect.\footnote{In

  the USA, due to unfortunate legislation, the length of copyright is nearly

  perpetual, even though the Constitution forbids perpetual copyright.} The

copyright holders have the right to relicense the same work under different

licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to

stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used),

but they may not revoke the rights under GPLv2 already granted.

In fact, when an entity looses their right to copy, modify and distribute

GPL'd software, it is because of their \emph{own actions}, not that of the

copyright holder.  The copyright holder does not decided when GPLv2~\S4

termination occurs (if ever); rather, the actions of the licensee determine

that.

Under copyright law, the GPL has granted various rights and freedoms to

the licensee to perform specific types of copying, modification, and

redistribution.  By default, all other types of copying, modification, and

redistribution are prohibited.  GPLv2~\S4 says that if you undertake any of

those other types (e.g., redistributing binary-only in violation of GPLv2~\S3),

then all rights under the license --- even those otherwise permitted for

those who have not violated --- terminate automatically.

GPLv2~\S4 makes GPLv2 enforceable.  If licensees fail to adhere to the

license, then they are stuck without any permission under to engage in

activities covered by copyright law.  They must completely cease and desist

from all copying, modification and distribution of the GPL'd software.

At that point, violating licensees must gain the forgiveness of the copyright

holders to have their rights restored.  Alternatively, the violators could

negotiate another agreement, separate from GPL, with the copyright

holder.  Both are common practice, although

\tutorialpartsplit{as discussed in \textit{A Practical Guide to GPL

    Compliance}, there are }{Chapter~\ref{compliance-understanding-whos-enforcing}

  explains further } key differences between these two very different uses of GPL.

\section{GPLv2~\S5: Acceptance, Copyright Style}

\label{GPLv2s5}

GPLv2~\S5 brings us to perhaps the most fundamental misconception and common

confusion about GPLv2\@. Because of the prevalence of proprietary software,

most users, programmers, and lawyers alike tend to be more familiar with

EULAs. EULAs are believed by their authors to be contracts, requiring

formal agreement between the licensee and the software distributor to be

valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap''

as mechanisms to perform acceptance ceremonies with EULAs.

The GPL does not need contract law to ``transfer rights.''  Usually, no rights

are transfered between parties.  By contrast, the GPL is primarily a permission

slip to undertake activities that would otherwise have been prohibited

by copyright law.  As such, GPL needs no acceptance ceremony; the

licensee is not even required to accept the license.

However, without the GPL, the activities of copying, modifying and

distributing the software would have otherwise been prohibited.  So, the

GPL says that you only accepted the license by undertaking activities that

you would have otherwise been prohibited without your license under GPL\@.

This is a certainly subtle point, and requires a mindset quite different

from the contractual approach taken by EULA authors.

An interesting side benefit to GPLv2~\S5 is that the bulk of users of Free

Software are not required to accept the license.  Undertaking fair and

unregulated use of the work, for example, does not bind you to the GPL,

since you are not engaging in activity that is otherwise controlled by

copyright law.  Only when you engage in those activities that might have an

impact on the freedom of others does license acceptance occur, and the

terms begin to bind you to fair and equitable sharing of the software.  In

other words, the GPL only kicks in when it needs to for the sake of

freedom.

While GPL is by default a copyright license, it is certainly still possible

to consider GPL as a contract as well.  For example, some distributors chose

to ``wrap'' their software in an acceptance ceremony to GPL, and nothing in

GPL prohibits that use.  Furthermore, the ruling in \textit{Jacobsen

  v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008)} indicates that \textbf{both}

copyright and contractual remedies may be sought by a copyright holder

seeking to enforce a license designed to uphold software freedom.

\section{Using GPL Both as a Contract and Copyright License}

\section{GPLv2~\S6: GPL, My One and Only}

\label{GPLv2s6}

\section{GPLv3~\S9: Acceptance}

% FIXME

\section{GPLv3~\S10: Explicit Downstream License}

% FIXME

\section{GPLv3~\S11: Explicit Patent Licensing}

\label{GPLv3s11}

% FIXME: just brought in words here, needs rewriting.

is rooted in the basic principles of the GPL.

Our license has always stated that distributors may not impose further

restrictions on users' exercise of GPL rights.  To make the suggested

distinction between contribution and distribution is to allow a

distributor to demand patent royalties from a direct or indirect

recipient, based on claims embodied in the distributed code. This

undeniably burdens users with an additional legal restriction on their

rights, in violation of the license.

%FIXME: possible useful text, but maybe not.

In the covenant provided in the revised section 11, the set of claims

that a party undertakes not to assert against downstream users are that

party's ``essential patent claims'' in the work conveyed by the party.

``Essential patent claims,'' a new term defined in section 0, are simply

all claims ``that would be infringed by making, using, or selling the

work.''  We have abandoned the phrase ``reasonably contemplated use.''

This change makes the obligations of distributing patent holders more

predictable.

% FIXME:  probably needs a lot of work, these provisions changed over time.

GPLv3 adds a new section on licensing of patents. GPLv2 relies on an implied

patent license. The doctrine of implied license is one that is recognized

under United States patent law but may not be recognized in other

jurisdictions. We have therefore decided to make the patent license grant

explicit in GPLv3. Under section 11, a redistributor of a GPL'd work

automatically grants a nonexclusive, royalty-free and worldwide license for

any patent claims held by the redistributor, if those claims would be

infringed by the work or a reasonably contemplated use of the work.

% FIXME:  probably needs a lot of work, these provisions changed over time.

The patent license is granted both to recipients of the redistributed work

and to any other users who have received any version of the work. Section 11

therefore ensures that downstream users of GPL'd code and works derived from

GPL'd code are protected from the threat of patent infringement allegations

made by upstream distributors, regardless of which country's laws are held to

apply to any particular aspect of the distribution or licensing of the GPL'd

code.

% FIXME:  probably needs a lot of work, these provisions changed over time.

A redistributor of GPL'd code may benefit from a patent license that has been

granted by a third party, where the third party otherwise could bring a

patent infringement lawsuit against the redistributor based on the

distribution or other use of the code. In such a case, downstream users of

the redistributed code generally remain vulnerable to the applicable patent

claims of the third party. This threatens to defeat the purposes of the GPL,

for the third party could prevent any downstream users from exercising the

freedoms that the license seeks to guarantee.

% FIXME:  probably needs a lot of work, these provisions changed over time.

The second paragraph of section 11 addresses this problem by requiring the

redistributor to act to shield downstream users from these patent claims. The

requirement applies only to those redistributors who distribute knowingly

relying on a patent license. Many companies enter into blanket patent

cross-licensing agreements. With respect to some such agreements, it would

not be reasonable to expect a company to know that a particular patent

license covered by the agreement, but not specifically mentioned in it,

protects the company's distribution of GPL'd code.

% FIXME: does this still fit with the final retaliation provision?

This narrowly-targeted patent retaliation provision is the only form of

patent retaliation that GPLv3 imposes by its own force. We believe that it

strikes a proper balance between preserving the freedom of a user to run and

modify a program, and protecting the rights of other users to run, modify,

copy, and distribute code free from threats by patent holders. It is

particularly intended to discourage a GPL licensee from securing a patent

directed to unreleased modifications of GPL'd code and then suing the

original developers or others for making their own equivalent modifications.

Several other free software licenses include significantly broader patent

retaliation provisions. In our view, too little is known about the

consequences of these forms of patent retaliation. As we explain below,

section 7 permits distribution of a GPL'd work that includes added parts

covered by terms other than those of the GPL. Such terms may include certain

kinds of patent retaliation provisions that are broader than those of section

2.

% FIXME:  probably mostly still right, needs some updates, though.

The wording in the first sentence of section 12 has been revised

slightly to clarify that an agreement, such as a litigation settlement

agreement or a patent license agreement, is one of the ways in which

conditions may be ``imposed'' on a GPL licensee that may contradict the

conditions of the GPL, but which do not excuse the licensee from

compliance with those conditions.  This change codifies what has been

our interpretation of GPLv2.  

% FIXME:  probably mostly still right, needs some updates, though.

We have removed the limited severability clause of GPLv2 section 7 as a

matter of tactical judgment, believing that this is the best way to ensure

that all provisions of the GPL will be upheld in court. We have also removed

the final sentence of GPLv2 section 7, which we consider to be unnecessary.

\section{GPLv3~\S13: The Great Affero Compromise}

% FIXME

\section{GPLv3~\S14: So, When's GPLv4?}

\label{GPlv2s14}

% FIXME Say more

No substantive change has been made in section 14. The wording of the section

has been revised slightly to make it clearer.

% FIXME; proxy

\section{GPLv3~\S15--17: Warranty Disclaimers and Liability Limitation}

No substantive changes have been made in sections 15 and 16.

% FIXME: more, plus 17

% FIXME: Section header needed here about choice of law.

% FIXME: reword into tutorial

Some have asked us to address the difficulties of internationalization

by including, or permitting the inclusion of, a choice of law

provision.  We maintain that this is the wrong approach.  Free

software licenses should not contain choice of law clauses, for both

legal and pragmatic reasons.  Choice of law clauses are creatures of

contract, but the substantive rights granted by the GPL are defined

under applicable local copyright law. Contractual free software

licenses can operate only to diminish these rights.  Choice of law

clauses also raise complex questions of interpretation when works of

software are created by combination and extension.  There is also the

real danger that a choice of law clause will specify a jurisdiction

that is hostile to free software principles.

% FIXME: reword into tutorial, \ref to section 7.

Our revised version of section 7 makes explicit our view that the

inclusion of a choice of law clause by a licensee is the imposition of

an additional requirement in violation of the GPL.  Moreover, if a

program author or copyright holder purports to supplement the GPL with

a choice of law clause, section 7 now permits any licensee to remove

that clause.

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

\chapter{The Lesser GPL}

As we have seen in our consideration of the GPL, its text is specifically

designed to cover all possible derivative works under copyright law. Our

goal in designing GPL was to make sure that any derivative work of GPL'd

software was itself released under GPL when distributed. Reaching as far

as copyright law will allow is the most direct way to reach that goal.

However, while the strategic goal is to bring as much Free Software

into the world as possible, particular tactical considerations

regarding software freedom dictate different means. Extending the

copyleft effect as far as copyright law allows is not always the most

prudent course in reaching the goal. In particular situations, even

those of us with the goal of building a world where all published

software is Free Software realize that full copyleft does not best

serve us. The GNU Lesser General Public License (``GNU LGPL'') was

designed as a solution for such situations.

\section{The First LGPL'd Program}

The first example that FSF encountered where such altered tactics were

needed was when work began on the GNU C Library. The GNU C Library would

become (and today, now is) a drop-in replacement for existing C libraries.

On a Unix-like operating system, C is the lingua franca and the C library

is an essential component for all programs. It is extremely difficult to

construct a program that will run with ease on a Unix-like operating

system without making use of services provided by the C library --- even

if the program is written in a language other than C\@. Effectively, all

user application programs that run on any modern Unix-like system must

make use of the C library.

If the answer is ``yes'' to both these questions, then you most likely

have a ``work based on the library.''  If the answer is ``no'' to the

first but ``yes'' to the second, you are in a gray area between ``work

based on the library'' and a ``work that uses the library.''

In our years of work with the LGPLv2.1, however, we have never seen a work

of software that was not clearly one or the other; the line is quite

bright. At times, though, we have seen cases where a derivative work

appeared in some ways to be a work that used the library and in other

ways a work based on the library. We overcame this problem by

dividing the work into smaller subunits. It was soon discovered that

what we actually had were three distinct components: the original

LGPL'd work, a specific set of works that used that library, and a

specific set of works that were based on the library. Once such

distinctions are established, the licensing for each component can be

considered independently and the LGPLv2.1 applied to each work as

prescribed.

\section{Subtleties in Defining the Application}

In our discussion of the definition of ``works that use the library,'' we

left out a few more complex details that relate to lower-level programming

details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities,

and it has been a source of great confusion. Part of the confusion comes

because a deep understanding of how compiler programs work is nearly

mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to

cover. It helps some to note that this is a border case that we cover in

the license only so that when such a border case is hit, the implications

of using LGPL continue in the expected way.

To understand this subtle point, we must recall the way that a compiler

operates. The compiler first generates object code, which are the binary

representations of various programming modules. Each of those modules is

usually not useful by itself; it becomes useful to a user of a full program

when those modules are {\em linked\/} into a full binary executable.

As we have discussed, the assembly of modules can happen at compile-time

or at runtime. Legally, there is no distinction between the two --- both

create a derivative work by copying and combining portions of one work and

mixing them with another. However, under LGPL, there is a case in the

compilation process where the legal implications are different.

Specifically, while we know that a ``work that uses the library'' is one

whose final binary is a derivative work, but whose source is not, there

are cases where the object code --- that intermediate step between source

and final binary --- is a derivative work created by copying verbatim code

from the LGPL'd software.

For efficiency, when a compiler turns source code into object code, it

sometimes places literal portions of the copyrighted library code into the

object code for an otherwise separate independent work. In the normal

scenario, the derivative would not be created until final assembly and

linking of the executable occurred. However, when the compiler does this

efficiency optimization, at the intermediate object code step, a

derivative work is created.

LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of

the license is clearly that simply compiling software to ``make use'' of

the library does not in itself cause the compiled work to be a ``work

based on the library.''  However, since the compiler copies verbatim,

copyrighted portions of the library into the object code for the otherwise

separate and independent work, it would actually cause that object file to be a

``work based on the library.''  It is not FSF's intent that a mere

compilation idiosyncrasy would change the requirements on the users of the

LGPLv2.1'd software. This paragraph removes that restriction, allowing the

implications of the license to be the same regardless of the specific

mechanisms the compiler uses underneath to create the ``work that uses the

library.''

As it turns out, we have only once had anyone worry about this specific

idiosyncrasy, because that particular vendor wanted to ship object code

(rather than final binaries) to their customers and was worried about

this edge condition. The intent of clarifying this edge condition is

primarily to quell the worries of software engineers who understand the

level of verbatim code copying that a compiler often does, and to help

them understand that the full implications of LGPLv2.1 are the same regardless

of the details of the compilation progress.

\section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}

\label{lgpl-section-6}

Now that we have established a good working definition of works that

``use'' and works that ``are based on'' the library, we will consider the

rules for distributing these two different works.

The rules for distributing ``works that use the library'' are covered in

LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release

of source when a binary version of the LGPL'd software is released. Of

course, it only requires that source code for the library itself be made

available. The work that ``uses'' the library need not be provided in

source form. However, there are also conditions in LGPLv2.1~\S6 to make sure

that a user who wishes to modify or update the library can do so.

LGPLv2.1~\S6 lists five choices with regard to supplying library source

and granting the freedom to modify that library source to users. We

most common way currently used for LGPLv2.1 compliance on a ``work that

uses the library.''

LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to

simply use a dynamically linked, shared library mechanism to link with the

library. This is by far the easiest and most straightforward option for

distribution. In this case, the executable of the work that uses the

library will contain only the ``stub code'' that is put in place by the

shared library mechanism, and at runtime the executable will combine with

the shared version of the library already resident on the user's computer.

If such a mechanism is used, it must allow the user to upgrade and

replace the library with interface-compatible versions and still be able

to use the ``work that uses the library.''  However, all modern shared

library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest

option, since it does not even require that the distributor of the ``work

2based on the library'' ship copies of the library itself.

LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library

mechanism cannot be used. It requires that the source for the library be

included, in the typical GPL fashion, but it also has a requirement beyond

that. The user must be able to exercise her freedom to modify the library

to its fullest extent, and that means recombining it with the ``work based

on the library.''  If the full binary is linked without a shared library

mechanism, the user must have available the object code for the ``work

based on the library,'' so that the user can relink the application and

build a new binary.

The remaining options in LGPLv2.1~\S6 are very similar to the other choices

provided by GPLv2~\S3. There are some additional options, but time does

not permit us in this course to go into those additional options. In

almost all cases of distribution under LGPL, either LGPLv2.1~\S6(a) or LGPLv2.1~\S6(b) are

exercised.

\section{Distribution of the Combined Works}

Essentially, ``works based on the library'' must be distributed under the

same conditions as works under full GPL\@. In fact, we note that 

LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.

There are again subtle differences and additions, which time does not

permit us to cover in this course.

\section{And the Rest}

The remaining variations between LGPL and GPL cover the following

conditions:

\begin{itemize}

\item Allowing a licensing ``upgrade'' from LGPL to GPL\@ (in LGPLv2.1~\S3)

\item Binary distribution of the library only, covered in LGPLv2.1~\S4,

  which is effectively equivalent to LGPLv2.1~\S3

\item Creating aggregates of libraries that are not derivative works of

  each other, and distributing them as a unit (in LGPLv2.1~\S7)

\end{itemize}

Due to time constraints, we cannot cover these additional terms in detail,

but they are mostly straightforward. The key to understanding LGPLv2.1 is

understanding the difference between a ``work based on the library'' and a

``work that uses the library.''  Once that distinction is clear, the

remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in

our more extensive GPL unit can be directly applied.

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

\chapter{Integrating the GPL into Business Practices}

Since GPL'd software is now extremely prevalent through the industry, it

is useful to have some basic knowledge about using GPL'd software in

business and how to build business models around GPL'd software.

\section{Using GPL'd Software In-House}

As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial,

the GPL only governs the activities of copying, modifying and

distributing software programs that are not governed by the license.

Thus, in FSF's view, simply installing the software on a machine and

using it is not controlled or limited in any way by GPL\@. Using Free

Software in general requires substantially fewer agreements and less

license compliance activity than any known proprietary software.

Even if a company engages heavily in copying the software throughout the

enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is

encouraged!  If the company simply deploys unmodified (or even modified)

Free Software throughout the organization for its employees to use, the

obligations under the license are very minimal. Using Free Software has a

substantially lower cost of ownership --- both in licensing fees and in

licensing checking and handling -- than the proprietary software

equivalents.

\section{Business Models}

\label{Business Models}

Using Free Software in house is certainly helpful, but a thriving