to select any version of the GPL they chose (usually indicated in shorthand

  by saying the license is simply ``GPL''), or

\item name a specific version of GPL and give downstream recipients the

  option to chose that version ``or any later version as published by the

  FSF'' (usually indicated by saying the license is

  ``GPLv$X$-or-later'')\footnote{The shorthand of ``GPL$X+$'' is also popular

    for this situation.  The authors of this tutorial prefer ``-or-later''

    syntax, because it (a) mirrors the words ``or'' and ``later from the

    licensing statement, (b) the $X+$ doesn't make it abundantly clear that

    $X$ is clearly included as a license option and (c) the $+$ symbol has

    other uses in computing (such as with regular expressions) that mean

    something different.}

\end{itemize}

\label{license-compatibility-first-mentioned}

Oddly, this flexibility has received (in the opinion of the authors, undue)

criticism, primarily because of the complex and oft-debated notion of

``license compatibility'' (which is explained in detail in

\S~\ref{license-compatibility}).  Copyleft licenses are generally

incompatible with each other, because the details of how they implement

copyleft differs.  Specifically, copyleft works only because of its

requirement that downstream licensors use the \textit{same} license for

combined and modified works.  As such, software licensed under the terms of

``GPLv2-only'' cannot be combined with works licensed ``GPLv3-or-later''.

This is admittedly a frustrating outcome.

Other copyleft licenses that appeared after GPL, such

as the Creative Commons ``Share Alike'' licenses, the Eclipse Public License

and the Mozilla Public License \textbf{require} all copyright holders chosing

to use any version of those licenses to automatically accept and relicense

their copyrighted works under new versions.  Of course ,Creative Commons, the

Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally

served as excellent stewards of their licenses.  Copyright holders using

those licenses seems to find it acceptable that to fully delegate all future

licensing decisions for their copyrights to these organizations without a

second thought.

However, note that FSF gives herein the control of copyright holders to

decide whether or not to implicitly trust the FSF in its work of drafting

future GPL versions.  The FSF, for its part, does encourage copyright holders

to chose by default ``GPLv$X$-or-later'' (where $X$ is the most recent

version of the GPL published by the FSF).  However, the FSF \textbf{does not

  mandate} that a choice to use any GPL requires a copyright holder ceding

its authority for future licensing decisions to the FSF.  In fact, the FSF

considered this possibility for GPLv3 and chose not to do so, instead opting

for the third-party steward designation clause discussed in

\section{Complexities of Two Simultaneously Popular Copylefts}

Obviously most GPL advocates would prefer widespread migration to GPLv3, and

many newly formed projects who seek a copyleft license tend to choose a

GPLv3-based license.  However, many existing copylefted projects continue

with GPLv2-only or GPLv2-or-later as their default license.

While GPLv3 introduces many improvements --- many of which were designed to

increase adoption by for-profit companies --- GPLv2 remains a widely used and

extremely popular license.  The GPLv2 is, no doubt, a good and useful

license.

However, unlike GPLv1, which (as pointed out in \S~\ref{GPLv1}), which is

completely out of use by the mid-1990s.  However, unlike GPLv1 before it,

GPLv2 remains a integral part of the copyleft licensing infrastructure for

some time to come.  As such, those who seek to have expertise in current

topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of

licenses.

Furthermore, GPLv3 can is more easily understood by first studying GPLv2.

This is not only because of their chronological order, but also because much

of the discussion material available for GPLv3 tends to talk about GPLv3 in

contrast to GPLv2.  As such, a strong understanding of GPLv2 helps in

understanding most of the third-party material found regarding GPLv3.  Thus,

the following chapter begins a deep discussion of GPLv2.

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

\chapter{GPLv2: Running Software and Verbatim Copying}

\label{run-and-verbatim}

This chapter begins the deep discussion of the details of the terms of

GPLv2\@. In this chapter, we consider the first two sections: GPLv2 \S\S

0--2. These are the straightforward sections of the GPL that define the

simplest rights that the user receives.

\section{GPLv2~\S0: Freedom to Run}

\label{GPLv2s0}

GPLv2~\S0, the opening section of GPLv2, sets forth that the copyright law governs

the work.  It specifically points out that it is the ``copyright

holder'' who decides if a work is licensed under its terms and explains

how the copyright holder might indicate this fact.

A bit more subtly, GPLv2~\S0 makes an inference that copyright law is the only

system that can restrict the software.  Specifically, it states:

\begin{quote}

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

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

they can.  Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit redistributors 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 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 redistributors to license the derivative works 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 derivative work of 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

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

\section{GPLv2~\S3: Producing Binaries}

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

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

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

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 GPLv22 was first published in June

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

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

default.  Now, it's common to give software on USB drives and SD card.  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)

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

GPL --- including the freedom to modify, rebuild, and redistribute the

source code.

GPLv2~\S3(c) is created to save her some trouble, because by itself GPLv2~\S3(b)

would unfairly favor large companies.  GPLv2~\S3(b) allows the

separation of the binary software from the key tool that people can use

to exercise their freedom. The GPL permits this separation because it is

good for redistributors, and those users who turn out not to need the

source.  However, to ensure equal rights for all software users, anyone

along the distribution chain must have the right to get the source and

exercise those freedoms that require it.

Meanwhile, GPLv2~\S3(b)'s compromise primarily benefits companies who

distribute binary software commercially.  Without GPLv2~\S3(c), that benefit

would be at the detriment of the companies' customers; the burden of

source code provision would be unfairly shifted to the companies'

\subsection{The System Library Exception}

The previous section skipped over one part of the CCS definition, the

so-called system library exception.  The ``System Libraries'' definition (and

the ``Standard Interface'' and ``Major Component'' definitions, which it

includes) are designed as part

to permit certain distribution arrangements that are considered reasonable by

copyleft advocates.  The system library exception is designed to allow

copylefted software to link with these libraries when such linking would hurt

software freedom more than it would hurt proprietary software.

The system library exception has two parts.  Part (a) rewords the GPLv2

exception for clarity replaces GPLv2's words ``unless that component itself

accompanies the executable'' with ``which is not part of the Major

Component''.  The goal here is to not require disclosure of source code of

certain libraries, such as necessary Microsoft Windows DLLs (which aren't

part of Windows' kernel but accompany it) that are required for functioning

of copylefted programs compiled for Windows.

However, in isolation, (a) would be too permissive, as it would sometimes

allowing distributors to evade important GPL requirements.  Part (b) reigns

in (a).  Specifically, (b) specifies only a few functionalities that a the

system library may provide and still qualify for the exception.  The goal is

to ensure system libraries are truly adjunct to a major essential operating

system component, compiler, or interpreter.  The more low-level the

functionality provided by the library, the more likely it is to be qualified

for this exception.

Admittedly, the system library exception is a frequently discussed topic of

obsessed GPL theorists.  The amount that has been written on the system

library exception (both the GPLv2 and GPLv3 versions of it), if included

herein,  could easily increase this section of the tutorial to a length

greater than all the others.

Like any exception to the copyleft requirements of GPL, would-be GPL

violators frequently look to the system library exception as a potential

software freedom circumvention technique.  When considering whether or not a

library qualifies for the system library exception, here is a pragmatic

thesis to consider, based on the combined decades of experience in GPL

interpretation of this tutorial's authors: the harder and more strained the

reader must study and read the system library exception, the more likely it

is that the library in question does not qualify for it.

\section{GPLv3~\S2: Basic Permissions}

GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed

improvements found in GPLv3 are found here as well.  For example, the first

sentence of GPLv3~\S2 furthers the goal internationalization.  Under the

copyright laws of some countries, it may be necessary for a copyright license

to include an explicit provision setting forth the duration of the rights

being granted. In other countries, including the USA, such a provision is

unnecessary but permissible.

GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of

copyright fair use, or the equivalent under applicable law.  These rights are

compatible with, and not in conflict with, the freedoms that the GPL seeks to

protect, and the GPL cannot and should not restrict them.

However, note that (sadly to some copyleft advocates) the unlimited freedom

to run is confined to the \textit{unmodified} Program.  This confinement is

unfortunately necessary since Programs that do not qualify as a User Product

in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain

unfortunate restrictions on the freedom to run\footnote{See

  \S~ref{freedom-to-run} of this tutorial for the details on ``the freedom to

  run''.}

GPLv3~\S2\P2 distinguishes between activities of a licensee that are

permitted without limitation and activities that trigger additional

requirements.  Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of

privately modifying and running the program.

Also, GPLv3~\S2\P2 gives an explicit permission for a client to provide a

copy of its modified software to a contractor exclusively for that contractor

to modify it further, or run it, on behalf of the client.  However, the

client can \textit{only} exercise this control over its own copyrighted

changes to the GPL-covered program.  The parts of the program it obtained

from other contributors must be provided to the contractor with the usual GPL

freedoms.  Thus, GPLv3 permits users to convey covered works to contractors

operating exclusively on the users' behalf, under the users' direction and

control, and to require the contractors to keep the users' copyrighted

changes confidential, but \textit{only if} the contractor is limited to acting

on the users' behalf (just as the users' employees would have to act).

The strict conditions in this ``contractors provision'' are needed so that it

cannot be twisted to fit other activities, such as making a program available

to downstream users or customers.  By making the limits on this provision

very narrow, GPLv3 ensures that, in all other cases, contractors gets the

full freedoms of the GPL that they deserve.

GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing.

This provision ensures that GPL enforcement is always by the copyright

holder.  Usually, sublicensing is regarded as a practical convenience or

necessity for the licensee, to avoid having to negotiate a license with each

licensor in a chain of distribution.  The GPL solves this problem in another

that such circumvention is accomplished through the exercise of GPL rights in

the conveyed work.  GPLv3\S3\P2 makes clear that the referenced ``legal

rights'' are specifically rights arising under anticircumvention law.  and

refers to both the conveying party's rights and to third party rights, as in

some cases the conveying party will also be the party legally empowered to

enforce or invoke rights arising under anticircumvention law.

These disclaimers by each licensor of any intention to use GPL'd software to

stringently control access to other copyrighted works should effectively

prevent any private or public parties from invoking DMCA-like laws against

users who escape technical restriction measures implemented by GPL'd

software.

\section{GPLv3~\S4: Verbatim Copying}

% FIXME: there appear to be minor changes here in later drafts, fix that.

Section 4 has been revised from its corresponding section in GPLv2 in light

of the new section 7 on license compatibility. A distributor of verbatim

copies of the program's source code must obey any existing additional terms

that apply to parts of the program. In addition, the distributor is required

to keep intact all license notices, including notices of such additional

terms.

% FIXME: needs context, needs match up to current text, and removal of stuff

%        that's no longer there

The original wording of this clause was meant to

make clear that the GPL permits one to charge for the distribution of

software.  Despite our efforts to explain this in the license and in

other documents, there are evidently some who believe that the GPL

allows charging for services but not for selling software, or that the

GPL requires downloads to be gratis.  We referred to charging a ``fee'';

the term ``fee'' is generally used in connection with services.  Our

original wording also referred to ``the physical act of transferring.''

The intention was to distinguish charging for transfers from attempts to

impose licensing fees on all third parties.  ``Physical'' might be read,

however, as suggesting ``distribution in a physical medium only.''  In

our revised wording we use ``price'' in place of ``fee,'' and we remove

the term ``physical.''

% FIXME: say more and tie it to the text

There is no harm in explicitly pointing out what ought to be obvious: that

those who convey GPL-covered software may offer commercial services for the

support of that software.

\section{GPLv3~\S5: Modified Source}

% FIXME: 5(a) is slightly different in final version

Section 5 contains a number of changes relative to the corresponding section

in GPLv2. Subsection 5a slightly relaxes the requirements regarding notice of

changes to the program. In particular, the modified files themselves need no

longer be marked. This reduces administrative burdens for developers of

modified versions of GPL'd software.

Under subsection 5a, as in the corresponding provision of GPLv2, the notices

must state ``the date of any change,'' which we interpret to mean the date of

one or more of the licensee's changes.  The best practice would be to include

the date of the latest change.  However, in order to avoid requiring revision

of programs distributed under ``GPL version 2 or later,'' we have retained

the existing wording.

% FIXME:  It's now (b) and (c).  Also, ``validity'' of proprietary

%         relicensing?  Give me a break.  I'll fix that.

Subsection 5b is the central copyleft provision of the license.  It now

states that the GPL applies to the whole of the work.  The license must be

unmodified, except as permitted by section 7, which allows GPL'd code to be

combined with parts covered by certain other kinds of free software licensing

terms. Another change in subsection 5b is the removal of the words ``at no

charge,'' which was often misinterpreted by commentators.  The last sentence

of subsection 5b explicitly recognizes the validity of disjunctive

dual-licensing.

%  FIXME: 5d.  Related to Appropriatey Legal notices

% follows 5d now, call it the ``final paragraph''

The paragraph following subsection 5c has been revised for clarity, but the

underlying meaning is unchanged. When independent non-derivative sections are

distributed for use in a combination that is a covered work, the whole of the

combination must be licensed under the GPL, regardless of the form in which

such combination occurs, including combination by dynamic linking. The final

sentence of the paragraph adapts this requirement to the new compatibility

provisions of section 7.

We have added these words to the aggregation clause to eliminate any question

that GPLv3 alters the scope of the copyleft as understood and applied under

GPLv2. In GPLv3, as in GPLv2, addition of modules or other parts to a program

results in a new program based on the old program, with different functional

characteristics created by the merger of two expressions: the original

program and the added parts.  Such added parts are ``by their nature

extensions of'' the old program, and therefore the entire new program which

they and the old program form must be licensed under the GPL.  As subsection

5c states, packaging of a work has no bearing on the scope of copyleft.

\section{GPLv3~\S6: Non-Source and Corresponding Source}

Section 6 of GPLv3, which clarifies and revises GPLv2 section 3, requires

distributors of GPL'd object code to provide access to the corresponding

source code, in one of four specified ways. As noted above, ``object code''

in GPLv3 is defined broadly to mean any non-source version of a work.

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

Subsections 6a and 6b now apply specifically to distribution of object code

in a physical product. Physical products include embedded systems, as well as

physical software distribution media such as CDs. As in GPLv2, the

distribution of object code may either be accompanied by the machine-readable

source code, or it may be accompanied by a written offer to provide the

machine-readable source code to any third party. GPLv3 clarifies that the

medium for software interchange on which the machine-readable source code is

provided must be a durable physical medium. Subsection 6b does not prevent a

distributor from offering to provide source code to a third party by some

other means, such as transmission over a network, so long as the option of

obtaining source code on a physical medium is presented.

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

Subsection 6b revises the requirements for the written offer to provide

source code. As before, the offer must remain valid for at least three

years. In addition, even after three years, a distributor of a product

containing GPL'd object code must offer to provide source code for as long as

the distributor also continues to offer spare parts or customer support for

the product model. We believe that this is a reasonable and appropriate

requirement; a distributor should be prepared to provide source code if he or

she is prepared to provide support for other aspects of a physical product.

% FIXME: 10x language is gone.

Subsection 6b also increases the maximum permitted price for providing a copy

of the source code. GPLv2 stated that the price could be no more than the

cost of physically performing source distribution; GPLv3 allows the price to

be up to ten times the distributor's cost. It may not be practical to expect

some organizations to provide such copies at cost. Moreover, permitting such

organizations to charge ten times the cost is not particularly harmful, since

some recipient of the code can be expected to make the code freely available

on a public network server. We also recognize that there is nothing wrong

with profiting from providing copies of source code, provided that the price

of a copy is not so unreasonably high as to make it effectively unavailable.

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

Subsection 6c gives narrower permission than the corresponding subsection in

GPLv2.  The option of including a copy of an offer received in accordance

goals of the Affero GPL, have objected to the form of the additional

requirement in that license.  These developers were generally

disappointed with our decision to allow Affero-like terms through

section 7, rather than adopt a condition for GPLv3.  Echoing their

concerns about the Affero GPL itself, they found fault with the wording

of the section 7 clause in both of the earlier drafts.  We drafted 7b4

at a higher level than its Draft 1 counterpart based in part on comments

from these developers. They considered the Draft 1 clause too closely

tied to the Affero mechanism of preserving functioning facilities for

downloading source, which they found too restrictive of the right of

modification.  The 7b4 rewording did not satisfy them, however. They

objected to its limitation to terms requiring compliance by network

transmission of source, and to the technically imprecise or inaccurate

use of the phrase ``same network session.''

We have concluded that any redrafting of the 7b4 clause would fail to

satisfy the concerns of both sets of its critics.  The first group

maintains that GPLv3 should do nothing about the problem of public

use. The second group would prefer for GPLv3 itself to have an

Affero-like condition, but that seems to us too drastic. By permitting

GPLv3-covered code to be linked with code covered by version 2 of the

Affero GPL, the new section 13 honors our original commitment to

achieving GPL compatibility for the Affero license.

Version 2 of the Affero GPL is not yet published.  We will work with

Affero, Inc., and with all other interested members of our community, to

complete the drafting of this license following the release of Draft 3,

with a goal of having a final version available by the time of our

adoption of the final version of GPLv3.  We hope the new Affero license

will satisfy those developers who are concerned about the issue of

public use of unconveyed versions but who have concerns about the

narrowness of the condition in the existing Affero license.

As the second sentence in section 13 indicates, when a combined work is

made by linking GPLv3-covered code with Affero-covered code, the

copyleft on one part will not extend to the other part.\footnote{The

plan is that the additional requirement of the new Affero license will

state a reciprocal limitation.} That is to say, in such combinations,

the Affero requirement will apply only to the part that was brought into

the combination under the Affero license.  Those who receive such a

combination and do not wish to use code under the Affero requirement may

remove the Affero-covered portion of the combination.

Those who criticize the permission to link with code under the Affero

GPL should recognize that most other free software licenses also permit

such linking. 

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

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

% FIXME: does this need to be a section, describing how it was out then in

% then out then in? :)

We have removed from this draft the appended section on ``How to Apply These

Terms to Your New Programs.'' For brevity, the license document can instead

refer to a web page containing these instructions as a separate document.

In short, FSF designed LGPL for those edge cases where the freedom of the

public can better be served by a more lax licensing system. FSF doesn't

encourage use of LGPL automatically for any software that happens to be a

library; rather, FSF suggests that it only be used in specific cases, such

as the following:

\begin{itemize}

\item To encourage the widest possible use of a Free Software library, so

  it becomes a de-facto standard over similar, although not

  interface-identical, proprietary alternatives

\item To encourage use of a Free Software library that already has

  interface-identical proprietary competitors that are more developed

\item To allow a greater number of users to get freedom, by encouraging

  proprietary companies to pick a Free alternative for its otherwise

  proprietary products

\end{itemize}

LGPL's preamble sets forth the limits to which the license seeks to go in

chasing these goals. LGPL is designed to ensure that users who happen to

acquire software linked with such libraries have full freedoms with

respect to that library. They should have the ability to upgrade to a newer

or modified Free version or to make their own modifications, even if they

cannot modify the primary software program that links to that library.

Finally, the preamble introduces two terms used throughout the license to

clarify between the different types of derivative works: ``works that use

the library,'' and ``works based on the library.''  Unlike GPL, LGPL must

draw some lines regarding derivative works. We do this here in this

license because we specifically seek to liberalize the rights afforded to

those who make derivative works. In GPL, we reach as far as copyright law

allows. In LGPL, we want to draw a line that allows some derivative works

copyright law would otherwise prohibit if the copyright holder exercised

his full permitted controls over the work.

\section{An Application: A Work that Uses the Library}

In the effort to allow certain proprietary derivative works and prohibit

others, LGPL distinguishes between two classes of derivative works:

``works based on the library,'' and ``works that use the library.''  The

distinction is drawn on the bright line of binary (or runtime) derivative

works and source code derivatives. We will first consider the definition

of a ``work that uses the library,'' which is set forth in LGPLv2.1~\S5.

We noted in our discussion of GPLv2~\S3 (discussed in

compiled and linked with GPL'd software are derivative works of that GPL'd

software. This includes both linking that happens at compile-time (when

the binary is created) or at runtime (when the binary -- including library

and main program both -- is loaded into memory by the user). In GPL,

binary derivative works are controlled by the terms of the license (in GPLv2~\S3),

and distributors of such binary derivatives must release full

corresponding source\@.

In the case of LGPL, these are precisely the types of derivative works

we wish to permit. This scenario, defined in LGPL as ``a work that uses

the library,'' works as follows:

\newcommand{\workl}{$\mathcal{L}$}

\newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$}

\begin{itemize}

\item A new copyright holder creates a separate and independent work,

  \worki{}, that makes interface calls (e.g., function calls) to the

  LGPL'd work, called \workl{}, whose copyright is held by some other

  party. Note that since \worki{} and \workl{} are separate and

  independent works, there is no copyright obligation on this new copyright

  holder with regard to the licensing of \worki{}, at least with regard to

  the source code.

\item The new copyright holder, for her software to be useful, realizes

  that it cannot run without combining \worki{} and \workl{}.

  Specifically, when she creates a running binary program, that running

  binary must be a derivative work, called \lplusi{}, that the user can

  run.

\item Since \lplusi{} is a derivative work of both \worki{} and \workl{},

  the license of \workl{} (the LGPL) can put restrictions on the license

  of \lplusi{}. In fact, this is what LGPL does.

\end{itemize}

We will talk about the specific restrictions LGPLv2.1 places on ``works

that use the library'' in detail in Section~\ref{lgpl-section-6}. For

now, focus on the logic related to how the LGPLv2.1 places requirements on

the license of \lplusi{}. Note, first of all, the similarity between

this explanation and that in Section~\ref{separate-and-independent},

which discussed the combination of otherwise separate and independent

works with GPL'd code. Effectively, what LGPLv2.1 does is say that when a

new work is otherwise separate and independent, but has interface

calls out to an LGPL'd library, then it is considered a ``work that

uses the library.''