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

\subsection{The Simpler Parts of GPLv2~\S2}

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.

GPLv2~\S2(c), a relatively simple section, requires that any program which

(before modification) ``normally reads commands interactively when run'' and

displays or prints legal information also display all copyright notices,

warranty disclaimer, modification indications and a pointer to the license,

even in modified versions.  The requirement is relatively simple, and relates

to an important policy goal of copyleft: downstream users should be informed

of their rights.  Its implications and details are straightforward and

simple.

\subsection{GPLv2~\S2(b)}

Meanwhile, GPLv2~\S2(b) requires careful and extensive study.  Its four short lines embody

the some of the essential legal details of ``share and share alike''.  These 46 words are

considered by some to be the most worthy of careful scrutiny because 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}

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.

The GPL  recognizes what is outside its scope.  When 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.  Thus, Far from attempting to extend copyleft beyond the

scope of copyright, the licenses explicitly recognize.

Thus, GPL recognizes what is outside its scope.  When a programmer's work is

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

be combined, then copyleft obligations do not extend to the independent work

separately distributed.  Thus, far from attempting to extend copyleft beyond

the scope of copyright, GPL explicitly limits the scope of copyleft to the

scope of copyright.

GPL does not, however (as is sometimes suggested) distinguish ``dynamic''

from ``static'' linking of program code.  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 together to make

one work (whether a main and some library subroutines, two objects with their

respective methods, or a program and a ``plugin'') the combination infringes

the copyright on the components if the combination required copyright

permission from the component copyright holders, as such permission was

either not available or was available on terms that were not observed.

In other words, when combining other software with GPL'd components, the only

available permission is GPL\@.  The combiner must observe and respect the GPL

observed on the combination as a whole.  It matters not if that combination

is made with a linker before distribution of the executable, is made by the

operating system in order to share libraries for execution efficiency at

runtime, or results from runtime references in the language at runtime (as in

Java programs).

\medskip

\label{GPLv2s2-at-no-charge}

The next phrase of note in GPLv2~\S2(b) is ``licensed \ldots at no charge.''

This phrase  confuses many.  The sloppy reader points out this as ``a

contradiction in GPL'' because (in their confused view) that clause of GPLv2~\S2 says that re-distributors cannot

charge for modified versions of GPL'd software, but GPLv2~\S1 says that

they can.  Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit re-distributors 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 be 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 re-distributors to license the whole work 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 work based on 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

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

%FIXME: need discussion of GPLv2's system library exception somewhere in here.

\subsection{Right to Private Modification} 

\label{gplv2-private-modification}

The issue of private modifications of GPLv2'd works deserves special

attention.  While these rights are clearly explicit in GPLv3~\S2\P2 (see

\S~\ref{GPLv3S2} of this tutorial for details), the permission to create

private modifications is mostly implicit in GPLv2.  Most notably, the

requirements of GPLv2~\S2 (and GPLv2~\S3, which will be discussed next) are

centered around two different copyright controls: both modification

\emph{and} distribution.  As such, GPLv2~\S2's requirements need only be met

when a modified version is distributed; one need not follow them for modified

versions that are not distributed.\footnote{As a matter of best practice, it's

  useful to assume that all software may eventually be distributed later,

  even if there no plans for distribution at this time.  Too often, GPL

  violations occur because of a late distribution decision of software that

  was otherwise never intended for distribution.}

However, the careful reader of GPLv2 will notice that, unlike GPLv3, no other

clauses of the license actually give explicit permission to make private

modifications.  Since modification of software is a control governed by

copyright, a modifier needs permission from the copyright holder to engage in

that activity.

In practice, however, traditional GPLv2 interpretation has always assumed

that blanket permission to create non-distributed modified versions was

available, and the

\href{http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic}{FSF

  has long opined that distribution of modified versions is never mandatory}.

This issue is one of many where GPLv3 clarifies in explicit text the implicit

policy and intent that was solidified via long-standing interpretation of

GPLv2.

\section{GPLv2~\S3: Producing Binaries}

\label{GPLv2s3}

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

modified versions (and/or 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 modified 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 modified 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).

\label{GPLv2s3a}

GPLv2~\S3(a) offers the option to directly accompany the source code alongside

the distribution of the binaries.  This is by far the most convenient

option for most distributors, because it means that the source-code

provision obligations are fully completed at the time of binary

distribution (more on that later).

Under GPLv2~\S3(a), the source code provided must be the ``corresponding source

code.''  Here ``corresponding'' primarily means that the source code

provided must be that code used to produce the binaries being distributed.

That source code must also be ``complete''.   GPLv2~\S3's penultimate paragraph

explains in detail what is meant by ``complete''.  In essence, it is all

the material that a programmer of average skill would need to actually use

the source code to produce the binaries she has received.  Complete source

is required so that, if the licensee chooses, she should be able to

exercise her freedoms to modify and redistribute changes.  Without the

complete source, it would not be possible to make changes that were

actually directly derived from the version received.

\label{GPLv2s3-build-scripts}

Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been

seen in GPL enforcement.  Under GPL, if you pay a high price for

a copy of GPL'd binaries (which comes with corresponding source, of

course), you have the freedom to redistribute that work at any fee you

choose, or not at all.  Sometimes, companies attempt a GPL-violating

cozenage whereby they produce very specialized binaries (perhaps for

an obscure architecture).  They then give source code that does

correspond, but withhold the ``incantations'' and build plans they

used to make that source compile into the specialized binaries.

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

\label{GPLv2s3-medium-customarily}

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

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

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

default.  Now, it's common to give software on USB drives and SD cards.  This

language in the license must adapt with changing technology.