% compliance-guide.tex                            -*- LaTeX -*-

\part{A Practical Guide to GPL Compliance}

\label{gpl-compliance-guide}

{\parindent 0in

This part is: \\

\begin{tabbing}

Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn. \\

Copyright \> \copyright{} 2008 \> \hspace{.2in} Software Freedom Law Center. \\

\end{tabbing}

\vspace{1in}

\begin{center}

Authors of this part are: \\

Bradley M. Kuhn \\

Aaron Williamson \\

Karen M. Sandler \\

\vspace{3in}

The copyright holders of this part hereby grant the freedom to copy, modify,

convey, Adapt, and/or redistribute this work under the terms of the Creative

Commons Attribution Share Alike 4.0 International License.  A copy of that

license is available at

\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=. 

\end{center}

}

\bigskip

\chapter*{Executive Summary}

This is a guide to effective compliance with the GNU General Public

License (GPL) and related licenses.  Copyleft advocates

usually seek to assist the community with

GPL compliance cooperatively.   This guide focuses on complying from the

start, so that readers can learn to avoid enforcement actions entirely, or, at

least, minimize  the negative impact when enforcement actions occur.

This guide  introduces and explains basic legal concepts related to the GPL and its

enforcement by copyright holders. It also outlines business practices and

methods that lead to better GPL compliance.  Finally, it recommends proper

post-violation responses to the concerns of copyright holders.

\chapter{Background}

Early GPL enforcement efforts began soon after the GPL was written by

Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,

often in public Usenet discussions.\footnote{One example is the public

  outcry over NeXT's attempt to make the Objective-C front-end to GCC

  proprietary.  RMS, in fact, handled this enforcement action personally and

  the Objective-C front-end is still part of upstream GCC today.}  Over the next decade, the Free Software Foundation (FSF),

which holds copyrights in many GNU programs, was the only visible entity

actively enforcing its GPL'd copyrights on behalf of the software freedom

community.

FSF's enforcement

was generally a private process; the FSF contacted violators

confidentially and helped them to comply with the license.  Most

violations were pursued this way until the early 2000's.

By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in

embedded devices such as wireless routers.  During this period, public

ridicule of violators in the press and on Internet fora supplemented

ongoing private enforcement and increased pressure on businesses to

comply.  In 2003, the FSF formalized its efforts into the GPL Compliance

Lab, increased the volume of enforcement, and built community coalitions

to encourage copyright holders to together settle amicably with violators.

Beginning in 2004, Harald Welte took a more organized public enforcement

approach and launched \verb0gpl-violations.org0, a website and mailing

list for collecting reports of GPL violations.  On the basis of these

reports, Welte successfully pursued many enforcements in Europe, including

formal legal action.  Harald earns the permanent fame as the first copyright

holder to bring legal action in a Court regarding GPL compliance. 

In 2007, two copyright holders in BusyBox, in conjunction with the

Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit

based on a violation of the GPL\@ in the USA. While  lawsuits are of course

quite public, the vast majority of Conservancy's enforcement actions 

are resolved privately via

cooperative communications with violators.  As both FSF and Conservancy has worked to bring

individual companies into compliance, both organizations have encountered numerous

violations resulting from preventable problems such as inadequate

attention to licensing of upstream software, misconceptions about the

GPL's terms, and poor communication between software developers and their

management.  This document highlights these problems and describe

best practices to encourage corporate Free Software users to reevaluate their

approach to GPL'd software and avoid future violations.

Both FSF and Conservancy continue GPL enforcement and compliance efforts

for software under the GPL, the GNU Lesser

Public License (LGPL) and other copyleft licenses.  In doing so, both organizations have

found that most violations stem from a few common mistakes that can be,

for the most part, easily avoided.  All copyleft advocates  hope to educate the community of

commercial distributors, redistributors, and resellers on how to avoid

violations in the first place, and to respond adequately and appropriately

when a violation occurs.

\chapter{Best Practices to Avoid Common Violations}

\label{best-practices}

Unlike highly permissive licenses (such as the ISC license), which

typically only require preservation of copyright notices, licensees face many

important requirements from the GPL.  These requirements are

carefully designed to uphold certain values and standards of the software

freedom community.  While the GPL's requirements may appear initially

counter-intuitive to those more familiar with proprietary software

licenses, by comparison, its terms are in fact clear and quite favorable to

licensees.  Indeed, the GPL's terms actually simplify compliance when

violations occur.

GPL violations occur (or, are compounded) most often when companies lack sound

practices for the incorporation of GPL'd components into their

internal development environment.  This section introduces some best

practices for software tool selection, integration and distribution,

inspired by and congruent with software freedom methodologies.  Companies should

establish such practices before building a product based on GPL'd

software.\footnote{This document addresses compliance with GPLv2,

  GPLv3, LGPLv2, and LGPLv3.  Advice on avoiding the most common

  errors differs little for compliance with these four licenses.

  \S~\ref{lgpl} discusses the key differences between GPL and LGPL

  compliance.}

\section{Evaluate License Applicability}

\label{derivative-works}

Political discussion about the GPL often centers around the ``copyleft''

requirements of the license.  Indeed, the license was designed primarily

to embody this licensing feature.  Most companies adding non-trivial

features (beyond mere porting and bug-fixing) to GPL'd software (and

thereby invoking these requirements) are already well aware of their

more complex obligations under the license.\footnote{While, there has been much legal

  discussion regarding copyleft and derivative works.  In practical

  reality, this issue is not relevant to the vast majority of companies

  distributing GPL'd software.  Those interested in this issue should study

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

However, experienced  GPL enforcers find that few redistributors'

compliance challenges relate directly to the copyleft provisions; this is

particularly true for most embedders.  Instead, the distributions of GPL'd

systems most often encountered typically consist of a full operating system

including components under the GPL (e.g., Linux, BusyBox) and components

under the LGPL (e.g., the GNU C Library).  Sometimes, these programs have

been patched or slightly improved by direct modification of their sources,

resulting unequivocally in a derivative work.  Alongside these programs,

companies often distribute fully independent, proprietary programs,

developed from scratch, which are designed to run on the Free Software operating

system but do not combine with, link to, modify, derive from, or otherwise

create a combined work with

the GPL'd components.\footnote{However, these programs do often combine

  with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}

In the latter case, where the work is unquestionably a separate work of

creative expression, no copyleft provisions are invoked.

Admittedly, a tiny

minority of situations which lie outside these two categories, and thus

do involve close questions about derivative and combined works.  Those

situations admittedly do require a highly

fact-dependent analysis and cannot be addressed in a general-purpose

document, anyway.

\medskip

Most companies accused of violations lack a basic understanding

of how to comply even in the former straightforward scenario.  This document

provides those companies with the fundamental and generally applicable prerequisite knowledge.

For answers to rarer and more complicated legal questions, such as whether

your software is a derivative or combined work of some copylefted software, consult

with an attorney.\footnote{If you would like more information on the

  application of derivative works doctrine to software, a detailed legal

  discussion is presented in our colleague Dan Ravicher's article,

  \textit{Software Derivative Work: A Circuit Dependent Determination} and in

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

This discussion thus assumes that you have already identified the

``work'' covered by the license, and that any components not under the GPL

(e.g., applications written entirely by your developers that merely happen

to run on a Linux-based operating system) distributed in conjunction with

those works are separate works within the meaning of copyright law and the GPL\@.  In

such a case, the GPL requires you to provide complete corresponding

source (CCS)\footnote{For more on CCS,  see

\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of

    this tutorial}.}

for the GPL'd components and your modifications thereto, but not

for independent proprietary applications.  The procedures described in

this document address this typical scenario.

\section{Monitor Software Acquisition}

Software engineers deserve the freedom to innovate and import useful

software components to improve products.  However, along with that

freedom should come rules and reporting procedures to make sure that you

are aware of what software that you include with your product.

The most typical response to an initial enforcement action is: ``We

didn't know there was GPL'd stuff in there''.  This answer indicates

failure in the software acquisition and procurement process.  Integration

of third-party proprietary software typically requires a formal

arrangement and management/legal oversight before the developers

incorporate the software.  By contrast, developers often obtain and

integrate Free Software without intervention nor oversight. That ease of acquisition, however,

does not mean the oversight is any less necessary.  Just as your legal

and/or management team negotiates terms for inclusion of any proprietary

software, they should gently facilitate all decisions to bring Free Software into your

product.

Simple, engineering-oriented rules help provide a stable foundation for

Free Software integration.  For example, simply ask your software developers to send an email to a

standard place describing each new Free Software component they add to the system,

and have them include a brief description of how they will incorporate it

into the product.  Further, make sure developers use a revision control

system (such as Git or Mercurial), and have

store the upstream versions of all software in a ``vendor branch'' or

similar mechanism, whereby they can easily track and find the main version

of the software and, separately, any local changes.

Such procedures are best instituted at your project's launch.  Once 

chaotic and poorly-sourced development processes begin, cataloging the

presence of GPL'd components  becomes challenging.

Such a situation often requires use of a tool to ``catch up'' your knowledge

about what software your product includes.  Most commonly, companies choose

some software licensing scanning tool to inspect the codebase.  However,

there are few tools that are themselves Free Software.  Thus, GPL enforcers

usually recommend the GPL'd

\href{http://fossology.org/}{Fossology system}, which analyzes a

source code base and produces a list of Free Software licenses that may apply to

the code.  Fossology can help you build a catalog of the sources you have

already used to build your product.  You can then expand that into a more

structured inventory and process.

\section{Track Your Changes and Releases}

As explained in further detail below, the most important component of GPL

compliance is the one most often ignored: proper inclusion of CCS in all

distributions  of GPL'd

software.  To comply with GPL's CCS requirements, the distributor

\textit{must} always know precisely what sources generated a given binary

distribution.

In an unfortunately large number of our enforcement cases, the violating

company's engineering team had difficulty reconstructing the CCS

for binaries distributed by the company.  Here are three simple rules to

\begin{itemize}

\item Ensure that your

developers are using revision control systems properly.

\item Have developers mark or ``tag'' the full source tree corresponding to

  builds distributed to customers

\item Check that your developers store all parts of the software

development in the revision control system, including {\sc readme}s, build

scripts, engineers' notes, and documentation.

\end{itemize}

Your developers will benefit anyway from these rules.  Developers will be

happier in their jobs if their tools already track the precise version of

source that corresponds to any deployed binary.

\section{Avoid the ``Build Guru''}

Too many software projects rely on only one or a very few team members who

know how to build and assemble the final released product.  Such knowledge

centralization not only creates engineering redundancy issues, but also

thwarts GPL compliance.  Specifically, CCS does not just require source code,

but scripts and other material that explain how to control compilation and

installation of the executable and object code.

Thus, avoid relying on a ``build guru'', a single developer who is the only one

who knows how to produce your final product. Make sure the build process

is well defined.  Train every developer on the build process for the final

binary distribution, including (in the case of embedded software)

generating a final firmware image suitable for distribution to the

customer.  Require developers to use revision control for build processes.

Make a rule that adding new components to the system without adequate

build instructions (or better yet, scripts) is unacceptable engineering

practice.

\chapter{Details of Compliant Distribution}

This section explains the specific requirements placed upon

distributors of GPL'd software.  Note that this section refers heavily to

specific provisions and language in

\href{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section3}{GPLv2}

and \href{http://www.fsf.org/licensing/licenses/gpl.html#section6}{GPLv3}.

It may be helpful to have a copy of each license open while reading this

section.

\section{Binary Distribution Permission}

\label{binary-distribution-permission}

% be careful below, you cannot refill the \if section, so don't refill

% this paragraph without care.

The various versions of the GPL are copyright licenses that grant

permission to make certain uses of software that are otherwise restricted

by copyright law.  This permission is conditioned upon compliance with the

GPL's requirements.

This section walks through the requirements (of both GPLv2 and GPLv3) that

apply when you distribute GPL'd programs in binary (i.e., executable or

object code) form, which is typical for embedded applications.  Because a

binary application derives from a program's original sources, you need

permission from the copyright holder to distribute it.  \S~3 of GPLv2 and

\S~6 of GPLv3 contain the permissions and conditions related to binary

distributions of GPL'd programs.\footnote{These sections cannot be fully

  understood in isolation; read the entire license thoroughly before

  focusing on any particular provision.  However, once you have read and

  understood the entire license, look to these sections to guide

  compliance for binary distributions.}

GPL's binary distribution sections offer a choice of compliance methods,

each of which we consider in turn.  Each option refers to the

``Corresponding Source'' code for the binary distribution, which includes

the source code from which the binary was produced.  This abbreviated and

simplified definition is sufficient for the binary distribution discussion

in this section, but you may wish to refer back to this section after

reading the thorough discussion of ``Corresponding Source'' that appears

in \S~\ref{corresponding-source}.

\subsection{Option (a): Source Alongside Binary}

GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing

source code: including Corresponding Source with every binary

distribution.  While other options appear initially less onerous, this

option invariably minimizes potential compliance problems, because when

you distribute Corresponding Source with the binary, \emph{your GPL

  obligations are satisfied at the time of distribution}.  This is not

true of other options, and for this reason, we urge you to seriously

consider this option.  If you do not, you may extend the duration of your

obligations far beyond your last binary distribution.

Compliance under this option is straightforward.  If you ship a product

that includes binary copies of GPL'd software (e.g., in firmware, or on a

hard drive, CD, or other permanent storage medium), you can store the

Corresponding Source alongside the binaries.  Alternatively, you can

include the source on a CD or other removable storage medium in the box

containing the product.

GPLv2 refers to the various storage mechanisms as ``medi[a] customarily

used for software interchange''.  While the Internet has attained primacy

as a means of software distribution where super-fast Internet connections

are available, GPLv2 was written at a time when downloading software was

not practical (and was often impossible).  For much of the world, this

condition has not changed since GPLv2's publication, and the Internet

still cannot be considered ``a medium customary for software

interchange''.  GPLv3 clarifies this matter, requiring that source be

``fixed on a durable physical medium customarily used for software

interchange''.  This language affirms that option (a) requires binary

redistributors to provide source on a physical medium.

Please note that while selection of option (a) requires distribution on a

physical medium, voluntary distribution via the Internet is very useful.  This

is discussed in detail in \S~\ref{offer-with-internet}.

\subsection{Option (b): The Offer}

\label{offer-for-source}

Many distributors prefer to ship only an offer for source with the binary

distribution, rather than the complete source package.  This

option has value when the cost of source distribution is a true

per-unit cost.  For example, this option might be a good choice for

embedded products with permanent storage too small to fit the source, and

which are not otherwise shipped with a CD but \emph{are} shipped with a

manual or other printed material.

However, this option increases the duration of your obligations

dramatically.  An offer for source must be good for three full years from

your last binary distribution (under GPLv2), or your last binary or spare

part distribution (under GPLv3).  Your source code request and

provisioning system must be designed to last much longer than your product

life cycle.

In addition, if you are required to comply with the terms of GPLv2, you

{\bf cannot} use a network service to provide the source code.  For GPLv2,

the source code offer is fulfilled only with physical media.  This usually

means that you must continue to produce an up-to-date ``source code CD''

for years after the product's end-of-life.

\label{offer-with-internet}

Under GPLv2, it is acceptable and advisable for your offer for source code

to include an Internet link for downloadable source \emph{in addition} to

offering source on a physical medium.  This practice enables those with

fast network connections to get the source more quickly, and typically

decreases the number of physical media fulfillment requests.

(GPLv3~\S~6(b) permits provision of source with a public

network-accessible distribution only and no physical media.  We discuss

this in detail at the end of this section.)

The following is a suggested compliant offer for source under GPLv2 (and

is also acceptable for GPLv3) that you would include in your printed

materials accompanying each binary distribution:

\begin{quote}

The software included in this product contains copyrighted software that

is licensed under the GPL\@.  A copy of that license is included in this

document on page $X$\@.  You may obtain the complete Corresponding Source

code from us for a period of three years after our last shipment of this

product, which will be no earlier than 2011-08-01, by sending a money

order or check for \$5 to: \\

GPL Compliance Division \\

Our Company \\

Any Town, US 99999 \\

\\

Please write ``source for product $Y$'' in the memo line of your

payment.

You may also find a copy of the source at

\verb0http://www.example.com/sources/Y/0.

This offer is valid to anyone in receipt of this information.

\end{quote}

There are a few important details about this offer.  First, it requires a

copying fee.  GPLv2 permits ``a charge no more than your cost of

physically performing source distribution''.  This fee must be reasonable.

If your cost of copying and mailing a CD is more than around \$10, you

should perhaps find a cheaper CD stock and shipment method.  It is simply

not in your interest to try to overcharge the community.  Abuse of this

provision in order to make a for-profit enterprise of source code

provision will likely trigger enforcement action.

Second, note that the last line makes the offer valid to anyone who

requests the source.  This is because v2~\S~3(b) requires that offers be

``to give any third party'' a copy of the Corresponding Source.  GPLv3 has

a similar requirement, stating that an offer must be valid for ``anyone

who possesses the object code''.  These requirements indicated in

v2~\S~3(c) and v3~\S~6(c) are so that noncommercial redistributors may

pass these offers along with their distributions.  Therefore, the offers

must be valid not only to your customers, but also to anyone who received

a copy of the binaries from them.  Many distributors overlook this

requirement and assume that they are only required to fulfill a request

from their direct customers.

The option to provide an offer for source rather than direct source

distribution is a special benefit to companies equipped to handle a

fulfillment process.  GPLv2~\S~3(c) and GPLv3~\S~6(c) avoid burdening

noncommercial, occasional redistributors with fulfillment request

obligations by allowing them to pass along the offer for source as they

received it.

Note that commercial redistributors cannot avail themselves of the option

(c) exception, and so while your offer for source must be good to anyone

who receives the offer (under v2) or the object code (under v3), it

\emph{cannot} extinguish the obligations of anyone who commercially

redistributes your product.  The license terms apply to anyone who

distributes GPL'd software, regardless of whether they are the original

distributor.  Take the example of Vendor $V$, who develops a software

platform from GPL'd sources for use in embedded devices.  Manufacturer $M$

contracts with $V$ to install the software as firmware in $M$'s device.

$V$ provides the software to $M$, along with a compliant offer for source.

In this situation, $M$ cannot simply pass $V$'s offer for source along to

its customers.  $M$ also distributes the GPL'd software commercially, so

$M$ too must comply with the GPL and provide source (or $M$'s \emph{own}

offer for source) to $M$'s customers.

This situation illustrates that the offer for source is often a poor

choice for products that your customers will likely redistribute.  If you

include the source itself with the products, then your distribution to

your customers is compliant, and their (unmodified) distribution to their

customers is likewise compliant, because both include source.  If you

include only an offer for source, your distribution is compliant but your

customer's distribution does not ``inherit'' that compliance, because they

have not made their own offer to accompany their distribution.

The terms related to the offer for source are quite different if you

distribute under GPLv3.  Under v3, you may make source available only over

a network server, as long as it is available to the general public and

remains active for three years from the last distribution of your product

or related spare part.  Accordingly, you may satisfy your fulfillment

obligations via Internet-only distribution.  This makes the ``offer for

source'' option less troublesome for v3-only distributions, easing

compliance for commercial redistributors.  However, before you switch to a

purely Internet-based fulfillment process, you must first confirm that you

can actually distribute \emph{all} of the software under GPLv3.  Some

programs are indeed licensed under ``GPLv2, \emph{or any later version}''

(often abbreviated ``GPLv2-or-later'').  Such licensing gives you the

option to redistribute under GPLv3.  However, a few popular programs are

only licensed under GPLv2 and not ``or any later version''

(``GPLv2-only'').  You cannot provide only Internet-based source request

fulfillment for the latter programs.

If you determine that all GPL'd works in your whole product allow upgrade

to GPLv3 (or were already GPLv3'd to start), your offer for source may be

as simple as this:

\begin{quote}

The software included in this product contains copyrighted software that

is licensed under the GPLv3\@.  A copy of that license is included in this

document on page $X$\@.  You may obtain the complete Corresponding Source

code from us for a period of three years after our last shipment of this

product and/or spare parts therefor, which will be no earlier than

2011-08-01, on our website at

\verb0http://www.example.com/sources/productnum/0.

\end{quote}

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 among 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 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'd 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

so that \S\S~0--3 can do their jobs.

\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 loses 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 decide 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 transferred 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 the GPL, and nothing in

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

% FIXME-LATER: Write this

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

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

\label{GPLv2s6}

A point that was glossed over in Section~\ref{GPLv2s4}'s discussion of GPLv2~\S4

was the irrevocable nature of the GPL\@. The GPLv2 is indeed irrevocable,

and it is made so formally by GPLv2~\S6.

The first sentence in GPLv2~\S6 ensures that as software propagates down the

distribution chain, that each licensor can pass along the license to each

new licensee.  Under GPLv2~\S6, the act of distributing automatically grants a

license from the original licensor to the next recipient.  This creates a

chain of grants that ensure that everyone in the distribution has rights

under the GPLv2\@.  In a mathematical sense, this bounds the bottom ---

making sure that future licensees get no fewer rights than the licensee before.

The second sentence of GPLv2~\S6 does the opposite; it bounds from the top.  It

prohibits any licensor along the distribution chain from placing

additional restrictions on the user.  In other words, no additional

requirements may trump the rights and freedoms given by GPLv2\@.

The final sentence of GPLv2~\S6 makes it abundantly clear that no individual

entity in the distribution chain is responsible for the compliance of any

other.  This is particularly important for noncommercial users who have

passed along a source offer under GPLv2~\S3(c), as they cannot be assured that

the issuer of the offer will honor their GPLv2~\S3 obligations.

In short, GPLv2~\S6 says that your license for the software is your one and

only copyright license allowing you to copy, modify and distribute the

software.

\section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''}

\label{GPLv2s7}

In essence, GPLv2~\S7 is a verbosely worded way of saying for non-copyright

systems what GPLv2~\S6 says for copyright.  If there exists any reason that a

distributor knows of that would prohibit later licensees from exercising

their full rights under GPL, then distribution is prohibited.

Originally, this was designed as the title of this section suggests --- as

a last ditch effort to make sure that freedom was upheld.  However, in

modern times, it has come to give much more.  Now that the body of GPL'd

software is so large, patent holders who would want to be distributors of

GPL'd software have a tough choice.  They must choose between avoiding

distribution of GPL'd software that exercises the teachings of their

patents, or grant a royalty-free, irrevocable, non-exclusive license to

those patents.  Many companies have chosen the latter.

Thus, GPLv2~\S7 rarely gives software death by stopping its distribution.

Instead, it is inspiring patent holders to share their patents in the same

freedom-defending way that they share their copyrighted works.

\section{GPLv2~\S8: Excluding Problematic Jurisdictions}

\label{GPLv2s8}

GPLv2~\S8 is rarely used by copyright holders.  Its intention is that if a

particular country, say Unfreedonia, grants particular patents or allows

copyrighted interfaces (no country to our knowledge even permits those

yet), that the GPLv2'd software can continue in free and unabated

distribution in the countries where such controls do not exist.

As far as is currently known, GPLv2~\S8 has very rarely been formally used by

copyright holders.  Admittedly, some have used GPLv2~\S8 to explain various

odd special topics of distribution (usually related in some way to

GPLv2~\S7).  However, generally speaking, this section is not proven

particularly useful in the more than two decades of GPLv2 history.

Meanwhile, despite many calls by the FSF (and others) for those licensors who

explicitly use this section to come forward and explain their reasoning, no

one ever did.  Furthermore, research conducted during the GPLv3 drafting

process found exactly one licensor who had invoked this section to add an

explicit geographical distribution limitation, and the reasoning for that one

invocation was not fitting with FSF's intended spirit of GPLv2~\S8.  As such,

GPLv2~\S8 was not included at all in GPLv3.

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

\chapter{Odds, Ends, and Absolutely No Warranty}

GPLv2~\S\S0--7 constitute the freedom-defending terms of the GPLv2.  The remainder

liability.

\section{GPLv2~\S9: FSF as Stewards of GPL}

\label{GPLv2s9}

FSF reserves the exclusive right to publish future versions of the GPL\@;

GPLv2~\S9 expresses this.  While the stewardship of the copyrights on the body

of GPL'd software around the world is shared among thousands of

individuals and organizations, the license itself needs a single steward.

Forking of the code is often regrettable but basically innocuous.  Forking

of licensing is disastrous.

(Chapter~\ref{tale-of-two-copylefts} discusses more about the various

versions of GPL.)

\section{GPLv2~\S10: Relicensing Permitted}

\label{GPLv2s10}

GPLv2~\S10 reminds the licensee of what is already implied by the nature of

copyright law.  Namely, the copyright holder of a particular software

program has the prerogative to grant alternative agreements under separate

copyright licenses.

\section{GPLv2~\S11: No Warranty}

\label{GPLv2s11}

Most warranty disclaimer language shout at you.  The

\href{http://www.law.cornell.edu/ucc/2/2-316}{Uniform Commercial

  Code~\S2-316} requires that disclaimers of warranty be ``conspicuous''.

There is apparently general acceptance that \textsc{all caps} is the

preferred way to make something conspicuous, and that has over decades worked

its way into the voodoo tradition of warranty disclaimer writing.

That said, there is admittedly some authority under USA law suggesting that

effective warranty disclaimers that conspicuousness can be established by

capitalization and is absent when a disclaimer has the same typeface as the

terms surrounding it (see \textit{Stevenson v.~TRW, Inc.}, 987 F.2d 288, 296

(5th Cir.~1993)).  While GPLv3's drafters doubted that such authority would

apply to copyright licenses like the GPL, the FSF has nevertheless left

warranty and related disclaimers in \textsc{all caps} throughout all versions

of GPL\@\footnote{One of the authors of this tutorial, Bradley M.~Kuhn, has

  often suggested the aesthetically preferable compromise of a

  \textsc{specifically designed ``small caps'' font, such as this one, as an

    alternative to} WRITING IN ALL CAPS IN THE DEFAULT FONT (LIKE THIS),

  since the latter adds more ugliness than conspicuousness.  Kuhn once

  engaged in reversion war with a lawyer who disagreed, but that lawyer never

  answered Kuhn's requests for case law that argues THIS IS INHERENTLY MORE

  CONSPICUOUS \textsc{Than this is}.}.

Some have argued the GPL is unenforceable in some jurisdictions because

its disclaimer of warranties is impermissibly broad.  However, GPLv2~\S11

contains a jurisdictional savings provision, which states that it is to be

interpreted only as broadly as allowed by applicable law.  Such a

provision ensures that both it, and the entire GPL, is enforceable in any

jurisdiction, regardless of any particular law regarding the

permissibility of certain warranty disclaimers.

Finally, one important point to remember when reading GPLv2~\S11 is that GPLv2~\S1

permits the sale of warranty as an additional service, which GPLv2~\S11 affirms.

\section{GPLv2~\S12: Limitation of Liability}

\label{GPLv2s12}

There are many types of warranties, and in some jurisdictions some of them

cannot be disclaimed.  Therefore, usually agreements will have both a

warranty disclaimer and a limitation of liability, as we have in GPLv2~\S12.

GPLv2~\S11 thus gets rid of all implied warranties that can legally be

disavowed. GPLv2~\S12, in turn, limits the liability of the actor for any

warranties that cannot legally be disclaimed in a particular jurisdiction.

Again, some have argued the GPL is unenforceable in some jurisdictions

because its limitation of liability is impermissibly broad. However, \S

12, just like its sister, GPLv2~\S11, contains a jurisdictional savings

provision, which states that it is to be interpreted only as broadly as

allowed by applicable law.  As stated above, such a provision ensures that

both GPLv2~\S12, and the entire GPL, is enforceable in any jurisdiction,

regardless of any particular law regarding the permissibility of limiting

liability.

So end the terms and conditions of the GNU General Public License.

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

\chapter{GPL Version 3}

\label{GPLv3}

This chapter discusses the text of GPLv3.  Much of this material herein

includes text that was adapted (with permission) from text that FSF

originally published as part of the so-called ``rationale documents'' for the

various discussion drafts of GPLv3.

The FSF ran a somewhat public process to develop GPLv3, and it was the first

attempt of its kind to develop a Free Software license this way.  Ultimately,

RMS was the primary author of GPLv3, but he listened to feedback from all

sorts of individuals and even for-profit companies.  Nevertheless, in

attempting to understand GPLv3 after the fact, the materials available from

the GPLv3 process have a somewhat ``drinking from the firehose'' effect.

This chapter seeks to explain GPLv3 to newcomers, who perhaps are familiar

with GPLv2 and who did not participate in the GPLv3 process.

Those who wish to drink from the firehose and take a diachronic approach to

GPLv3 study by reading the step-by-step public drafting process of the GPLv3 (which

occurred from Monday 16 January 2006 through Monday 19 November 2007) should

visit \url{http://gplv3.fsf.org/}.

\section{Understanding GPLv3 As An Upgraded GPLv2}

Ultimately, GPLv2 and GPLv3 co-exist as active licenses in regular use.  As

discussed in Chapter~\ref{tale-of-two-copylefts}, GPLv1 was never regularly