Copyleft/guide Changeset - 224e1913909c

% gpl-lgpl.tex                                                  -*- LaTeX -*-

%      Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course

% License: CC-By-SA-4.0

% The copyright holders 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.

% This text is distributed in the hope that it will be useful, but

% WITHOUT ANY WARRANTY; without even the implied warranty of

% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% You should have received a copy of the license with this document in

% a file called 'CC-By-SA-4.0.txt'.  If not, please visit

% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive

% the license text.

% FIXME-LATER: I should make a macro like the Texinfo @xref stuff for places

%      where I'm saying ``see section X in this tutorial'', so that the extra

%      verbiage isn't there in the HTML versions that I'll eventually do.

%      Maybe something like that already exists?  In the worst case, I could

%      adapt @xref from texinfo.texi for it.

\newcommand{\defn}[1]{\emph{#1}}

\part{Detailed Analysis of the GNU GPL and Related Licenses}

\label{gpl-lgpl-part}

\tutorialpartsplit{This tutorial}{This part of the tutorial} gives a

comprehensive explanation of the most popular Free Software copyright

license, the GNU General Public License (``GNU GPL'', or sometimes just

``GPL'') -- both version 2 (``GPLv2'') and version 3 (``GPLv3'') -- and

teaches lawyers, software developers, managers and businesspeople how to use

the GPL (and GPL'd software) successfully both as a community-building

``Constitution'' for a software project, and to incorporate copylefted

software into a new Free Software business and in existing, successful

enterprises.

To benefit from this part of the tutorial, readers should

have a general familiarity with software development processes.  A basic

understanding of how copyright law applies to software is also helpful.  The

tutorial is of most interest to lawyers, software developers and managers who

run or advise software businesses that modify and/or redistribute software

under the terms of the GNU GPL (or who wish to do so in the future), and those

who wish to make use of existing GPL'd software in their enterprise.

Upon completion of this part of the tutorial, readers can expect

to have learned the following:

\begin{itemize}

  \item The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3.

  \item The differences between GPLv2 and GPLv3.

  \item The redistribution options under the GPLv2 and GPLv3.

  \item The obligations when modifying GPLv2'd or GPLv3'd software.

  \item How to build a plan for proper and successful compliance with the GPL.

  \item The business advantages that the GPL provides.

  \item The most common business models used in conjunction with the GPL.

  \item How existing GPL'd software can be used in existing enterprises.

  \item The basics of LGPLv2.1 and LGPLv3, and how they

    differ from the GPLv2 and GPLv3, respectively.

  \item The basics to begin understanding the complexities regarding

    derivative and combined works of software.

\end{itemize}

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

% END OF ABSTRACTS SECTION

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

% START OF DAY ONE COURSE

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

\chapter{What Is Software Freedom?}

Study of the GNU General Public License (herein, abbreviated as \defn{GNU

  GPL} or just \defn{GPL}) must begin by first considering the broader world

of software freedom. The GPL was not created in a vacuum. Rather, it was

created to embody and defend a set of principles that were set forth at the

founding of the GNU Project and the Free Software Foundation (FSF) -- the

preeminent organization that upholds, defends and promotes the philosophy of software

freedom. A prerequisite for understanding both of the popular versions

of the GPL

(GPLv2 and GPLv3) and their terms and conditions is a basic understanding of

the principles behind them.  The GPL family of licenses are unlike nearly all

other software licenses in that they are designed to defend and uphold these

principles.

\section{The Free Software Definition}

\label{Free Software Definition}

The Free Software Definition is set forth in full on FSF's website at

\verb0http://fsf.org/0 \verb0philosophy/free-sw.html0. This section presents

an abbreviated version that will focus on the parts that are most pertinent

to the GPL\@.

A particular user has software freedom with respect to a particular program if that

user has the following freedoms:

\begin{itemize}

\item The freedom to run the program, for any purpose.

\item The freedom to study how the program works, and modify it

\item The freedom to redistribute copies.

\item The freedom to distribute copies of  modified versions to others.

\end{itemize}

The focus on ``a particular user'' is particularly pertinent here.  It is not

uncommon for a subset of a specific program's user base to have these freedoms, while other

users of the same version the program have none or only some of these freedoms.

Section~\ref{Proprietary Relicensing} talks in detail about how

this can unfortunately happen even if a program is released under the GPL\@.

Many people refer to software with these freedoms as ``Open Source.''

Besides having a different political focus from those who call such software

by the name ``Free

Software'',\footnote{The political differences between the Free Software

  Movement and the Open Source Movement are documented on FSF's Web site at

  \url{http://www.fsf.org/licensing/essays/free-software-for-freedom.html}.},

 those who call the software ``Open Source'' are often focused on a side

issue.  Specifically, user access to the source code of a program is a

prerequisite to make use of the freedom to modify.  However, the important

issue is what freedoms are granted in the license that applies to that source code.

Software freedom is only complete when no restrictions are imposed on how

these freedoms are exercised.  Specifically, users and programmers can

exercise these freedoms noncommercially or commercially.  Licenses that grant

these freedoms for noncommercial activities but prohibit them for commercial

activities are considered non-free.  The Open Source Initiative

(\defn{OSI}) (the arbiter of what is considered ``Open Source'') also regards

such licenses as inconsistent with its ``Open Source Definition''.

In general, software for which any of these freedoms are restricted in any

way is called ``nonfree'' software.  Some use the term ``proprietary

software'' more or less interchangeably with ``nonfree software''.  The FSF

published a useful

\href{http://www.gnu.org/philosophy/categories.html}{explanation of various

  types of software and how they relate to one another}.

Keep in mind that none of the terms ``software freedom'', ``open source''

and ``free software'' are known to be trademarked or otherwise legally

restricted by any organization in

any jurisdiction.  As such, it's quite common that these terms are abused and

misused by parties who wish to bank on the popularity of software freedom.

When one considers using, modifying or redistributing a software package that

purports to be Open Source or Free Software, one \textbf{must} verify that

the license grants software freedom.

Furthermore, throughout this text, we generally prefer the term ``software

freedom'', as this is the least ambiguous term available to describe software

that meets the Free Software Definition.  For example, it is well known and

often discussed that the adjective ``free'' has two unrelated meanings in

English: ``free as in freedom'' and ``free as in price''.  Meanwhile, the

term ``open source'' is even more confusing, because it appears to refer only to the

``freedom to study'', which is merely a subset of one of the four freedoms.

The remainder of this section considers each of each component of software

freedom in detail.

\subsection{The Freedom to Run}

\label{freedom-to-run}

The first tenet of software freedom is the user's fully unfettered right to

run the program.  The software's license must permit any conceivable use of

the software.  Perhaps, for example, the user has discovered an innovative

use for a particular program, one that the programmer never could have

predicted.  Such a use must not be restricted.

It was once rare that this freedom was restricted by even proprietary

software; but such is quite common today. Most End User License Agreements

(EULAs) that cover most proprietary software typically restrict some types of

uses.  Such restrictions of any kind are an unacceptable restriction on

software freedom.

\subsection{The Freedom to Change and Modify}

Perhaps the most useful right of software freedom is the users' right to

change, modify and adapt the software to suit their needs.  Access to the

source code and related build and installation scripts are an essential part

of this freedom.  Without the source code, and the ability to build and

install the binary applications from that source, users cannot effectively

exercise this freedom.

Programmers directly benefit from this freedom.  However, this freedom

remains important to users who are not programmers.  While it may seem

counterintuitive at first, non-programmer users often exercise this freedom

indirectly in both commercial and noncommercial settings.  For example, users

often seek noncommercial help with the software on email lists and in user

groups.  To make use of such help they must either have the freedom to

recruit programmers who might altruistically assist them to modify their

software, or to at least follow rote instructions to make basic modifications

themselves.

More commonly, users also exercise this freedom commercially.  Each user, or

group of users, may hire anyone they wish in a competitive free market to

modify and change the software.  This means that companies have a right to

hire anyone they wish to modify their Free Software.  Additionally, such

companies may contract with other companies to commission software

modifications.

\subsection{The Freedom to Copy and Share}

Users share Free Software in a variety of ways. Software freedom advocates

work to eliminate a fundamental ethical dilemma of the software age: choosing

between obeying a software license and friendship (by giving away a copy of a

program to your friend who likes the software you are using). Licenses that

respect software freedom, therefore, permit altruistic sharing of software

among friends.

The commercial environment also benefits from this freedom.  Commercial sharing

includes selling copies of Free Software: that is, Free Software can

be distributed for any monetary

price to anyone.  Those who redistribute Free Software commercially also have

the freedom to selectively distribute (i.e., you can pick your customers) and

to set prices at any level that redistributor sees fit.

Of course, most people get copies of Free Software very cheaply (and

sometimes without charge).  The competitive free market of Free Software

tends to keep prices low and reasonable.  However, if someone is willing to

pay billions of dollars for one copy of the GNU Compiler Collection, such a

sale is completely permitted.

Another common instance of commercial sharing is service-oriented

distribution.  For example, some distribution vendors provide immediate

security and upgrade distribution via a special network service.  Such

distribution is not necessarily contradictory with software freedom.

(Section~\ref{Business Models} of this tutorial talks in detail about some

common Free Software business models that take advantage of the freedom to

share commercially.)

\subsection{The Freedom to Share Improvements}

The freedom to modify and improve is somewhat empty without the freedom to

share those improvements.  The software freedom community is built on the

pillar of altruistic sharing of improved Free Software. Historically

it was typical for a

Free Software project to sprout a mailing list where improvements

would be shared

freely among members of the development community.\footnote{This is still

commonly the case, though today there are additional ways of

sharing Free Software.}  Such noncommercial

sharing is the primary reason that Free Software thrives.

Commercial sharing of modified Free Software is equally important.

For commercial support to exist in a competitive free market, all

developers -- from single-person contractors to large software

companies -- must have the freedom to market their services as

augmenters of Free Software.  All forms of such service marketing must

be equally available to all.

For example, selling support services for Free Software is fully

permitted. Companies and individuals can offer themselves as ``the place

to call'' when software fails or does not function properly.  For such a

service to be meaningful, the entity offering that service needs the

right to modify and improve the software for the customer to correct any

problems that are beyond mere user error.

Software freedom licenses also permit any entity to distribute modified

versions of Free Software.  Most Free Software programs have a ``standard

version'' that is made available from the primary developers of the software.

However, all who have the software have the ``freedom to fork'' -- that is,

make available nontrivial modified versions of the software on a permanent or

semi-permanent basis.  Such freedom is central to vibrant developer and user

interaction.

Companies and individuals have the right to make true value-added versions

of Free Software.  They may use freedom to share improvements to

distribute distinct versions of Free Software with different functionality

and features.  Furthermore, this freedom can be exercised to serve a

disenfranchised subset of the user community.  If the developers of the

standard version refuse to serve the needs of some of the software's

users, other entities have the right to create a long- or short-lived fork

to serve that sub-community.

\section{How Does Software Become Free?}

The previous section set forth key freedoms and rights that are referred to

as ``software freedom''.  This section discusses the licensing mechanisms

used to enable software freedom.  These licensing mechanisms were ultimately

created as a community-oriented ``answer'' to the existing proprietary

software licensing mechanisms.  Thus, first, consider carefully why

proprietary software exists in the first place.

\label{explaining-copyright}

The primary legal regime that applies to software is copyright law.

Proprietary software exists at all only because copyright law governs

software.\footnote{This statement is admittedly an oversimplification. Patents and

  trade secrets can cover software and make it effectively non-Free, and one

  can contract away their rights and freedoms regarding software, or source

  code can be practically obscured in binary-only distribution without

  reliance on any legal system.  However, the primary control mechanism for

  software is copyright, and therefore this section focuses on how copyright

  restrictions make software proprietary.} Copyright law, with respect to

software, typically governs copying, modifying, and redistributing that

software (For details of this in the USA, see

\href{http://www.copyright.gov/title17/92chap1.html#106}{\S~106} and

\href{http://www.copyright.gov/title17/92chap1.html#117}{\S~117} of

\href{http://www.law.cornell.edu/uscode/text/17}{Title 17} of the

\textit{United States Code}).\footnote{Copyright law in general also governs

  ``public performance'' of copyrighted works. There is no generally agreed

  definition for public performance of software and both GPLv2 and GPLv3 do

  not restrict public performance.} By law (in the USA and in most other

jurisdictions), the copyright holder (most typically, the author) of the work controls

how others may copy, modify and/or distribute the work. For proprietary

software, these controls are used to prohibit these activities. In addition,

proprietary software distributors further impede modification in a practical

sense by distributing only binary code and keeping the source code of the

software secret.

Copyright is not a natural state, it is a legal construction. In the USA, the

Constitution permits, but does not require, the creation of copyright law as

federal legislation.  Software, since it is an ``original work of authorship

fixed in any tangible medium of expression ...  from which they can be

perceived, reproduced, or otherwise communicated, either directly or with the

aid of a machine or device'' (as stated in

\href{http://www.law.cornell.edu/uscode/text/17/102}{17 USC \S~102}), is thus

covered by the statute, and is copyrighted by default.

However, software, in its natural state without copyright, is Free

Software. In an imaginary world with no copyright, the rules would be

different. In this world, when you received a copy of a program's source

code, there would be no default legal system to restrict you from sharing it

with others, making modifications, or redistributing those modified

versions.\footnote{Note that this is again an oversimplification; the

  complexities with this argument are discussed in

  Section~\ref{software-and-non-copyright}.}

Software in the real world is copyrighted by default and is automatically

covered by that legal system.  However, it is possible to move software out

of the domain of the copyright system.  A copyright holder can often

\defn{disclaim} their copyright. (For example, under USA copyright law

it is possible for a copyright holder to engage in conduct resulting

in abandonment of copyright.)  If copyright is disclaimed, the software is

effectively no longer restricted by copyright law.   Software not restricted by copyright is in the

``public domain.''

\subsection{Public Domain Software}

In the USA and other countries that

are parties to the Berne Convention on Copyright, software is copyrighted

automatically by the author when she fixes the software in a tangible

medium.  In the software world, this usually means typing the source code

of the software into a file.

Imagine if authors could truly disclaim those default controls of copyright

law.  If so, the software is in the public domain --- no longer covered by

copyright.  Since copyright law is the construction allowing for most

restrictions on software (i.e., prohibition of copying, modification, and

redistribution), removing the software from the copyright system usually

yields software freedom for its users.

Carefully note that software truly in the public domain is \emph{not} licensed

in any way.  It is confusing to say software is ``licensed for the

public domain,'' or any phrase that implies the copyright holder gave

express permission to take actions governed by copyright law.

Copyright holders who state that they are releasing their code into

the public domain are effectively renouncing copyright controls on

the work.  The law gave the copyright holders exclusive controls over the

work, and they chose to waive those controls.  Software that is, in

this sense, in the public domain

is conceptualized by the developer as having no copyright and thus no license. The software freedoms discussed in

Section~\ref{Free Software Definition} are all granted because there is no

legal system in play to take them away.

Admittedly, a discussion of public domain software is an oversimplified

example.

Because copyright controls are usually automatically granted and because, in

some jurisdictions, some copyright controls cannot be waived (see

Section~\ref{non-usa-copyright} for further discussion), many copyright

holders sometimes incorrectly believe a work has been placed in the public

domain.  Second, due to aggressive lobbying by the entertainment industry,

the ``exclusive Right'' of copyright, that was supposed to only exist for

``Limited Times'' according to the USA Constitution, appears to be infinite:

simply purchased on the installment plan rather than in whole.  Thus, we must

assume no works of software will fall into the public domain merely due to

the passage of time.

Nevertheless, under USA law it is likely that the typical

disclaimers of copyright or public domain dedications we see in the

Free Software world would be interpreted by courts as copyright

abandonment, leading to a situation in which the user effectively receives a

maximum grant of copyright freedoms, similar to a maximally-permissive

Free Software license.

The best example of software known to truly be in the public domain is software

that is published by the USA government.  Under

\href{http://www.law.cornell.edu/uscode/text/17/105}{17 USC 101 \S~105}, all

works published by the USA Government are not copyrightable in the USA.

\subsection{Why Copyright Free Software?}

If simply disclaiming copyright on software yields Free Software, then it

stands to reason that putting software into the public domain is the

easiest and most straightforward way to produce Free Software. Indeed,

some major Free Software projects have chosen this method for making their

software Free. However, most of the Free Software in existence \emph{is}

copyrighted. In most cases (particularly in those of FSF and the GNU

Project), this was done due to very careful planning.

copyrighted.

For some, this is because while it's reasonable to assume that US courts

will recognize abandonment of copyright given a clear enough notice from the

author, that's not necessarily true in all jurisdictions and even if it was,

we don't know what form exactly a dedication should take to convince courts

and prevent confusion or attempted revocations.

For others, it's because authors feel that enforcing through copyright one or

more license condtions, reasonably chosen to correspond to their wishes, is

another way to create Free Software that everyone benefits from.

In the case of FSF and the GNU Project, copyrighting and licensing software

was done due to very careful planning.

Software released into the public domain does grant freedom to those users

who receive the standard versions on which the original author disclaimed

copyright. However, since the work is not copyrighted, any nontrivial

modification made to the work is copyrightable.

% FIXME: can't this be written better?

% The core intention of copyleft is to keep software from being reused in

% proprietary software. [It's the last - not discussed in the guide? - paragraph

% in GPLv2 and v3; though not part of the legal text, I'd argue it pervades it.]

% This means a lot of things, but it doesn't automatically mean that the public

% domain would disappear otherwise, in the simple sense that what is in the public

% domain remains there. If the argument is that there aren't adequate incentives

% for enlarging it, that's different than saying someone can shrink it.

% If there are serious reasons for thinking one can shrink it, then those

% reasons seem worth discussing separately from the incentives issue.

Free Software released into the public domain initially is Free, and

perhaps some who modify the software choose to place their work into the

public domain as well. However, over time, some entities will choose to

proprietarize their modified versions. The public domain body of software

feeds the proprietary software. The public commons disappears, because

fewer and fewer entities have an incentive to contribute back to the

commons. They know that any of their competitors can proprietarize their

enhancements. Over time, almost no interesting work is left in the public

domain, because nearly all new work is done by proprietarization.

A legal mechanism is needed to redress this problem. FSF was in fact

originally created primarily as a legal entity to defend software freedom,

and that work of defending software freedom is a substantial part of

its work today. Specifically because of this ``embrace, proprietarize and

extend'' cycle, FSF made a conscious choice to copyright its Free Software,

and then license it under ``copyleft'' terms. Many, including the

developers of the kernel named Linux, have chosen to follow this paradigm.

\label{copyleft-definition}

Copyleft is a strategy of utilizing copyright law to pursue the policy goal

of fostering and encouraging the equal and inalienable right to copy, share,

modify and improve creative works of authorship.  Copyleft (as a general

term) describes any method that utilizes the copyright system to achieve the

aforementioned goal.  Copyleft as a concept is usually implemented in the

details of a specific copyright license, such as the

\hyperref[GPLv3-full-text]{GNU General Public License (GPL)} and the Creative

Commons Attribution Share Alike License (the latter of which is the license

of this work itself).  Copyright holders of creative work can unilaterally

implement these licenses for their own works to build communities that

collaboratively share and improve those copylefted creative works.

Copyleft uses functional parts of the copyright system to achieve an unusual

result (legal protection for free sharing). Copyleft modifies, or ``hacks''

copyright law, which is usually employed to strengthen the rights of authors

or publishers, to strengthen instead the rights of users.  Thus, Copyleft is

a legal strategy and mechanism to defend, uphold and propagate software

freedom. The basic technique of copyleft is as follows: copyright the

software, license it under terms that give all the software freedoms, but use

the copyright law controls to ensure that all who receive a copy of the

software have equal rights and freedom. In essence, copyleft grants freedom,

but forbids others to forbid that freedom to anyone else along the

distribution and modification chains.

Copyleft's ``reciprocity'' or ``share and share alike'' rule protects both

developers, who avoid facing a ``prioritized'' competitor of their project,

and users, who can be sure that they will have all four software freedoms ---

not only in the present version of the program they use, but in all its

future improved versions.

Copyleft is a general concept. Much like ideas for what a computer might

do must be \emph{implemented} by a program that actually does the job, so

too must copyleft be implemented in some concrete legal structure.

``Share and share alike'' is a phrase that is used often enough to explain the

concept behind copyleft, but to actually make it work in the real world, a

true implementation in legal text must exist, written as a ``copyright

license''.  The GPL implements the concept of copyleft for software-oriented

and other functional works of a technical nature.  The ``CC BY SA'' license

implements copyleft for works of textual, musical and visual authorship, such

as this tutorial.

Copyleft advocates often distinguish between the concept of a ``strong

copyleft'' or a ``weak copyleft''.  However, ``strong vs. weak'' copyleft is

not a dichotomy, it's a spectrum.  The strongest copylefts strive to the

exclusive rights that copyright  grants to authors as extensively as possible

to maximize software freedom.  As a copyleft gets ``weaker'', the copyleft

license typically makes ``trade offs'' that might impede software freedom,

but reach other tactic goals for the community of users and developers of the

work.

In other words, strong copyleft licenses place the more requirements on how

``the work'' is licensed.  The unit of copyright law is ``the work''.  In

that sense, the ``work'' referenced by the licenses is anything that can be

copyrighted or will be subject to the terms of copyright law.  Strong

copyleft licenses exercise their scope fully.  Anything which is ``a work''

or a ``work based on a work'' licensed under a strong copyleft is subject to

its requirements, including the requirement of complete, corresponding source

code\footnote{Copyleft communities' use of the term ``strong copyleft'' is

  undoubtedly imprecise.  For example, most will call the GNU GPL a ``strong

  copyleft'' license, even though the GPL itself has various exceptions, such

  as the \hyperref[GPLv3-system-library-exception]{GPLv3's system library

    exception} written into the text of the license itself.  Furthermore, the

  copyleft community continues to debate where the a license cross the line

  from ``strong copyleft'' to ``license that fails to respect software

  freedom'', although ultimately these debates are actually regarding whether

  the license fits \hyperref[Free Software Definition]{Free Software

    definition} at all.}.  Thus, copyleft licenses, particularly strong ones,

seek to ensure the same license covers every version of ``work based on the

work'', as recognized by local copyright law, and thereby achieve the

specific strategic policy aim of ensuring software freedom for all users,

developers, authors, and readers who encounter the copylefted work.

\subsection{Software and Non-Copyright Legal Regimes}

\label{software-and-non-copyright}

The use, modification and distribution of software, like many endeavors,

simultaneously interacts with multiple different legal regimes.  As was noted

early via footnotes, copyright is merely the \textit{most common way} to

restrict users' rights to copy, share, modify and/or redistribute software.

However, proprietary software licenses typically use every mechanism

available to subjugate users.  For example:

\begin{itemize}

\item Unfortunately, despite much effort by many in the software freedom

  community to end patents that read on software (i.e., patents on

  computational ideas), they still exist.  As such, a software

  program might otherwise seem to be unrestricted, but a patent might read on

  the software and ruin everything for its users.\footnote{See

  \S\S~\ref{gpl-implied-patent-grant},~\ref{GPLv2s7},~\ref{GPLv3s11} for more

  discussion on how the patent system interacts with copyleft, and read

  Richard M.~Stallman's essay,

  \href{http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/}{\textit{Let's

      Limit the Effect of Software Patents, Since We Can't Eliminate Them}}

  for more information on the problems these patents present to society.}

\item Digital Restrictions Management (usually called \defn{DRM}) is often

  used to impose technological restrictions on users' ability to exercise

  software freedom that they might otherwise be granted.\footnote{See

    \S~\ref{GPLv3-drm} for more information on how GPL deals with this issue.}

  The simplest (and perhaps oldest) form of DRM, of course, is separating

  software source code (read by humans), from their compiled binaries (read

  only by computers).  Furthermore,

  \href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} often

  prohibits users legally from circumventing some of these DRM systems.

\item Most EULAs also include a contractual agreement that bind users further

  by forcing them to agree to a contractual, prohibitive software license

  before ever even using the software.

\end{itemize}

Thus, most proprietary software restricts users via multiple interlocking

legal and technological means.  Any license that truly respect the software

freedom of all users must not only grant appropriate copyright permissions,

but also \textit{prevent} restrictions from other legal and technological

means like those listed above.

\subsection{Non-USA Copyright Regimes}

\label{non-usa-copyright}

Generally speaking, copyright law operates similarly enough in countries that

have signed the Berne Convention on Copyright, and software freedom licenses

have generally taken advantage of this international standardization of

copyright law.  However, copyright law does differ from country to country,

and commonly, software freedom licenses like the GPL must be considered under the

copyright law in the jurisdiction where any licensing dispute occurs.

Those who are most familiar with the USA's system of copyright often are

surprised to learn that there are certain copyright controls that cannot be

waived nor disclaimed.  Specifically, many copyright regimes outside the USA

recognize a concept of moral rights of authors.  Typically, moral rights are

fully compatible with respecting software freedom, as they are usually

centered around controls that software freedom licenses generally respect,

such as the right of an authors to require proper attribution for their work.

\section{A Community of Equality}

The previous section described the principles of software freedom, a brief

introduction to mechanisms that typically block these freedoms, and the

simplest ways that copyright holders might grant those freedoms to their

users for their copyrighted works of software.  The previous section also

introduced the idea of \textit{copyleft}: a licensing mechanism to use

copyright to not only grant software freedom to users, but also to uphold

those rights against those who might seek to curtail them.

Copyleft, as defined in \S~\ref{copyleft-definition}, is a general term for this

mechanism.  The remainder of this text will discuss details of various

real-world implementations of copyleft -- most notably, the GPL\@.

This discussion begins first with some general explanation of what the GPL is

able to do in software development communities.  After that brief discussion

in this section, deeper discussion of how GPL accomplishes this in practice

follows in the next chapter.

Simply put, though, the GPL ultimately creates a community of equality for

both business and noncommercial users.

\subsection{The Noncommercial Community}

A GPL'd code base becomes a center of a vibrant development and user

community.  Traditionally, volunteers, operating noncommercially out of

keen interest or ``scratch an itch'' motivations, produce initial versions

of a GPL'd system.  Because of the efficient distribution channels of the

Internet, any useful GPL'd system is adopted quickly by noncommercial

users.

Fundamentally, the early release and quick distribution of the software

gives birth to a thriving noncommercial community.  Users and developers

begin sharing bug reports and bug fixes across a shared intellectual

commons.  Users can trust the developers, because they know that if the

developers fail to address their needs or abandon the project, the GPL

ensures that someone else has the right to pick up development.

Developers know that the users cannot redistribute their software without

passing along the rights granted by the GPL, so they are assured that every

one of their users is treated equally.

Because of the symmetry and fairness inherent in GPL'd distribution,

nearly every GPL'd package in existence has a vibrant noncommercial user

and developer base.

\subsection{The Commercial Community}

By the same token, nearly all established GPL'd software systems have a

vibrant commercial community.  Nearly every GPL'd system that has gained

wide adoption from noncommercial users and developers eventually begins

to fuel a commercial system around that software.

For example, consider the Samba file server system that allows Unix-like

systems (including GNU/Linux) to serve files to Microsoft Windows systems.

Two graduate students originally developed Samba in their spare time and

it was deployed noncommercially in academic environments.\footnote{See

  \href{http://turtle.ee.ncku.edu.tw/docs/samba/history}{Andrew Tridgell's

    ``A bit of history and a bit of fun''}}  However, very

soon for-profit companies discovered that the software could work for them

as well, and their system administrators began to use it in place of

Microsoft Windows NT file-servers.  This served to lower the cost of

running such servers by orders of magnitude. There was suddenly room in

Windows file-server budgets to hire contractors to improve Samba.  Some of

the first people hired to do such work were those same two graduate

students who originally developed the software.

The noncommercial users, however, were not concerned when these two

fellows began collecting paychecks off of their GPL'd work.  They knew

that because of the nature of the GPL that improvements that were

distributed in the commercial environment could easily be folded back into

the standard version.  Companies are not permitted to proprietarize

Samba, so the noncommercial users, and even other commercial users are

safe in the knowledge that the software freedom ensured by the GPL will remain

protected.

Commercial developers also work in concert with noncommercial

developers.  Those two now-long-since graduated students continue to

contribute to Samba altruistically, but also get paid work doing it.

Priorities change when a client is in the mix, but all the code is

contributed back to the standard version.  Meanwhile, many other

individuals have gotten involved noncommercially as developers,

because they want to ``cut their teeth on Free Software,'' or because

the problems interest them.  When they get good at it, perhaps they

will move on to another project, or perhaps they will become

commercial developers of the software themselves.

No party is a threat to another in the GPL software scenario because

everyone is on equal ground.  The GPL protects rights of the commercial

and noncommercial contributors and users equally. The GPL creates trust,

because it is a level playing field for all.

\subsection{Law Analogy}

In his introduction to Stallman's \emph{Free Software, Free Society},

Lawrence Lessig draws an interesting analogy between the law and Free

Software. He argues that the laws of a free society must be protected

much like the GPL protects software.  So that I might do true justice to

Lessig's argument, I quote it verbatim:

\begin{quotation}

A ``free society'' is regulated by law. But there are limits that any free

society places on this regulation through law: No society that kept its

laws secret could ever be called free.  No government that hid its

regulations from the regulated could ever stand in our tradition. Law

controls.  But it does so justly only when visibly.  And law is visible

only when its terms are knowable and controllable by those it regulates,

or by the agents of those it regulates (lawyers, legislatures).

This condition on law extends beyond the work of a legislature.  Think

about the practice of law in American courts.  Lawyers are hired by their

clients to advance their clients' interests.  Sometimes that interest is

advanced through litigation. In the course of this litigation, lawyers

write briefs. These briefs in turn affect opinions written by judges.

These opinions decide who wins a particular case, or whether a certain law

can stand consistently with a constitution.

All the material in this process is free in the sense that Stallman means.

Legal briefs are open and free for others to use.  The arguments are

transparent (which is different from saying they are good), and the

reasoning can be taken without the permission of the original lawyers.

The opinions they produce can be quoted in later briefs.  They can be

copied and integrated into another brief or opinion.  The ``source code''

for American law is by design, and by principle, open and free for anyone

to take. And take lawyers do---for it is a measure of a great brief that

it achieves its creativity through the reuse of what happened before.  The

source is free; creativity and an economy is built upon it.

This economy of free code (and here I mean free legal code) doesn't starve

lawyers.  Law firms have enough incentive to produce great briefs even

though the stuff they build can be taken and copied by anyone else.  The

lawyer is a craftsman; his or her product is public.  Yet the crafting is

not charity. Lawyers get paid; the public doesn't demand such work

without price.  Instead this economy flourishes, with later work added to

the earlier.

We could imagine a legal practice that was different --- briefs and

arguments that were kept secret; rulings that announced a result but not

the reasoning. Laws that were kept by the police but published to no one

else. Regulation that operated without explaining its rule.

We could imagine this society, but we could not imagine calling it

``free.''  Whether or not the incentives in such a society would be better

or more efficiently allocated, such a society could not be known as free.

The ideals of freedom, of life within a free society, demand more than

efficient application.  Instead, openness and transparency are the

constraints within which a legal system gets built, not options to be

added if convenient to the leaders.  Life governed by software code should

be no less.

Code writing is not litigation.  It is better, richer, more

productive.  But the law is an obvious instance of how creativity and

incentives do not depend upon perfect control over the products

created.  Like jazz, or novels, or architecture, the law gets built

upon the work that went before. This adding and changing is what

creativity always is.  And a free society is one that assures that its

most important resources remain free in just this sense.\footnote{This

quotation is Copyright \copyright{} 2002, Lawrence Lessig. It is

licensed under the terms of

\href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution

License'' version 1.0} or any later version as published by Creative

Commons.}

\end{quotation}

In essence, lawyers are paid to service the shared commons of legal

infrastructure.  Few citizens defend themselves in court or write their

own briefs (even though they are legally permitted to do so) because

everyone would prefer to have an expert do that job.

The Free Software economy is a market ripe for experts.  It

functions similarly to other well established professional fields like the

law. The GPL, in turn, serves as the legal scaffolding that permits the

creation of this vibrant commercial and noncommercial Free Software

economy.

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

\chapter{A Tale of Two Copyleft Licenses}

\label{tale-of-two-copylefts}

While determining the proper methodology and criteria to yield an accurate

count remains difficult, the GPL is generally considered one of the most

widely used Free Software licenses.  For most of its history --- for 16 years

from June 1991 to June 2007 --- there was really only one version of the GPL,

version 2.

However, the GPL had both earlier versions before version 2, and, more well

known, a revision to version 3.

\section{Historical Motivations for the General Public License}

The earliest license to grant software freedom was likely the Berkeley

Software Distribution (``BSD'') license.  This license is typical of what are

often called lax, highly permissive licenses.  Not unlike software in the

public domain, these non-copyleft licenses (usually) grant software freedom

to users, but they do not go to any effort to uphold that software freedom

for users.  The so-called ``downstream'' (those who receive the software and

then build new things based on that software) can restrict the software and

distribute further.

The GNU's Not Unix (``GNU'') project, which Richard M.~Stallman (``RMS'')

founded in 1984 to make a complete Unix-compatible operating system

implementation that assured software freedom for all.  However, RMS saw that

using a license that gave but did not assure software freedom would be

counter to the goals of the GNU Project.  RMS invented ``copyleft'' as an

answer to that problem, and began using various copyleft licenses for the

early GNU Project programs.\footnote{RMS writes more fully about this topic in

  his essay entitled simply

  \href{http://www.gnu.org/gnu/thegnuproject.html}{\textit{The GNU Project}}.

    For those who want to hear the story in his own voice,

    \href{http://audio-video.gnu.org/audio/}{speech recordings} of his talk,

    \textit{The Free Software Movement and the GNU/Linux Operating System}

    are also widely available}

\section{Proto-GPLs And Their Impact}

%FIXME-LATER: bad line break:

%\href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs

%  General Public License}

The earliest copyleft licenses were specific to various GNU programs.  For

example,  The Emacs

General Public License was likely the first copyleft license ever

published.  Interesting to note that even this earliest copyleft license

contains a version of the well-known GPL copyleft clause:

\begin{quotation}

You may modify your copy or copies of GNU Emacs \ldots provided that you also

\ldots cause the whole of any work that you distribute or publish, that in

whole or in part contains or is a derivative of GNU Emacs or any part

thereof, to be licensed at no charge to all third parties on terms identical

to those contained in this License Agreement.

\end{quotation}

This simply stated clause is the fundamental innovation of copyleft.

Specifically, copyleft \textit{uses} the copyright holders' controls on

permission to modify the work to add a conditional requirement.  Namely,

downstream users may only have permission to modify  the work if they pass

along the same permissions on the modified version that came originally to

them.

These original program-specific proto-GPLs give an interesting window into

the central ideas and development of copyleft.  In particular, reviewing them

shows how the text of the GPL we know has evolved to address more of the

issues discussed earlier in \S~\ref{software-and-non-copyright}.

\section{The GNU General Public License, Version 1}

\label{GPLv1}

In January 1989, the FSF announced that the GPL had been converted into a

``subroutine'' that could be reused not just for all FSF-copyrighted

programs, but also by anyone else.  As the FSF claimed in its announcement of

the GPLv1:\footnote{The announcement of GPLv1 was published in the

  \href{http://www.gnu.org/bulletins/bull6.html\#SEC8}{GNU's Bulletin, vol 1,

    number 6 dated January 1989}.  (Thanks very much to Andy Tai for his

  \href{http://www.free-soft.org/gpl_history/}{consolidation of research on

    the history of the pre-v1 GPL's}.)}

\begin{quotation}

To make it easier to copyleft programs, we have been improving on the

legalbol architecture of the General Public License to produce a new version

that serves as a general-purpose subroutine: it can apply to any program

without modification, no matter who is publishing it.

\end{quotation}

This, like many inventive ideas, seems somewhat obvious in retrospect.  But,

the FSF had some bright people and access to good lawyers when it started.

It took almost five years from the first copyleft licenses to get to a

generalized, reusable GPLv1.  In the context and mindset of the 1980s, this

is not surprising.  The idea of reusable licensing infrastructure was not

only uncommon, it was virtually nonexistent!  Even the early BSD licenses

were simply copied and rewritten slightly for each new use.\footnote{It

  remains an interesting accident of history that the early BSD problematic

  ``advertising clause'' (discussion of which is somewhat beyond the scope of

  this tutorial) lives on into current day, simply because while the

  University of California at Berkeley gave unilateral permission to remove

  the clause from \textit{its} copyrighted works, others who adapted the BSD

  license with their own names in place of UC-Berkeley's never have.}  The

GPLv1's innovation of reusable licensing infrastructure, an obvious fact

today, was indeed a novel invention for its day.\footnote{We're all just

  grateful that the FSF also opposes business method patents, since the FSF's

  patent on a ``method for reusable licensing infrastructure'' would have

  not expired until 2006!}

\section{The GNU General Public License, Version 2}

The GPLv2 was released two and a half years after GPLv1, and over the

following sixteen years, it became the standard for copyleft licensing until

the release of GPLv3 in 2007 (discussed in more detail in the next section).

While this tutorial does not discuss the terms of GPLv1 in detail, it is

worth noting below the three key changes that GPLv2 brought:

\begin{itemize}

\item Software patents and their danger are explicitly mentioned, inspiring

  (in part) the addition of GPLv2~\S\S5--7.  (These sections are discussed in

  detail in \S~\ref{GPLv2s5}, \S~\ref{GPLv2s6} and \S~\ref{GPLv2s7} of this

  tutorial.)

\item GPLv2~\S2's copyleft terms are expanded to more explicitly discuss the

  issue of combined works.  (GPLv2~\S2 is discussed in detail in

  \S~\ref{GPLv2s2} in this tutorial).

\item GPLv2~\S3 includes more detailed requirements, including the phrase

 ``the scripts used to control compilation and installation of the

  executable'', which is a central component of current GPLv2 enforcement.

  (GPLv2~\S3 is discussed in detail in

  \S~\ref{GPLv2s3} in this tutorial).

\end{itemize}

The next chapter discusses GPLv2 in full detail, and readers who wish to dive

into the section-by-section discussion of the GPL should jump ahead now to

that chapter.  However, the most interesting fact to note here is how GPLv2

was published with little fanfare and limited commentary.  This contrasts

greatly with the creation of GPLv3.

\section{The GNU General Public License, Version 3}

RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups

during that era about new text of that license.  However, rampant violations

of the GPL required more immediate attention of FSF's licensing staff, and as

such, much of the early 2000's was spent doing GPL enforcement

work.\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a

    companion tutorial, \textit{A Practical Guide to GPL

      Compliance}}{Part~\ref{gpl-compliance-guide} of this tutorial}.}  In

2006, FSF began in earnest drafting work for GPLv3.

The GPLv3 process began in earnest in January 2006.  It became clear that

many provisions of the GPL could benefit from modification to fit new

circumstances and to reflect what the entire community learned from

experience with version 2.  Given the scale of revision it seems proper to

approach the work through public discussion in a transparent and accessible

manner.

The GPLv3 process continued through June 2007, culminating in publication of

GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC

Runtime Library Exception on 27 January 2009.

All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3

and two discussion drafts of AGPLv3 were published and discussed.

Ultimately, FSF remained the final arbiter and publisher of the licenses, and

RMS himself their primary author, but input was sought from many parties, and

these licenses do admittedly look and read more like legislation as a result.

Nevertheless, all of the ``v3'' group are substantially better and improved

licenses.

GPLv3 and its terms are discussed in detail in Chapter~\ref{GPLv3}.

\section{The Innovation of Optional ``Or Any Later'' Version}

An interesting fact of all GPL licenses is that there are ultimately multiple

choices for use of the license.  The FSF is the primary steward of GPL (as

discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv3s14}).  However, those

who wish to license works under GPL are not required to automatically accept

changes made by the FSF for their own copyrighted works.

Each licensor may chose three different methods of licensing, as follows:

\begin{itemize}

\item explicitly name a single version of GPL for their work (usually

  indicated in shorthand by saying the license is ``GPLv$X$-only''), or

\item name no version of the GPL, thus they allow their downstream recipients

  to select any version of the GPL they choose (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 choose 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

``Attribution-Share Alike'' licenses, the Eclipse Public License and the

Mozilla Public License \textbf{require} all copyright holders choosing

to use any version of those licenses to automatically allow use of their

copyrighted works under new versions.\footnote{CC-BY-SA-2.0 and greater only

permit licensing of adaptations under future versions; 1.0 did not have

any accomodation for future version compatibility.}  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 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~\ref{GPLv3s14}.

\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 before it,

GPLv2 remains an integral part of the copyleft licensing infrastructure.  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 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{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 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}

Activities other than copying, distribution and modification are not

covered by this License; they are outside its scope.

\end{quote}

In essence, the license governs \emph{only} those activities, and all other

activities are unrestricted, provided that no other agreements trump GPLv2

(which they cannot; see Sections~\ref{GPLv2s6} and~\ref{GPLv2s7}).  This is

very important, because the Free Software community heavily supports

users' rights to ``fair use'' and ``unregulated use'' of copyrighted

material.  GPLv2 asserts through this clause that it supports users' rights

to fair and unregulated uses.

Fair use (called ``fair dealing'' in some jurisdictions) of copyrighted

material is an established legal doctrine that permits certain activities

regardless of whether copyright law would otherwise restrict those activities.

Discussion of the various types of fair use activity are beyond the scope of

this tutorial.  However, one important example of fair use is the right to

quote portions of the text in a larger work so as to criticize or suggest

changes.  This fair use right is commonly used on mailing lists when

discussing potential improvements or changes to Free Software.

Fair use is a doctrine established by the courts or by statute.  By

contrast, unregulated uses are those that are not covered by the statue

nor determined by a court to be covered, but are common and enjoyed by

many users.  An example of unregulated use is reading a printout of the

program's source code like an instruction book for the purpose of learning

how to be a better programmer.  The right to read something that you have

access to is and should remain unregulated and unrestricted.

\medskip

Thus, the GPLv2 protects users' fair and unregulated use rights precisely by

not attempting to cover them.  Furthermore, the GPLv2 ensures the freedom

to run specifically by stating the following:

\begin{quote}

''The act of running the Program is not restricted.''

\end{quote}

Thus, users are explicitly given the freedom to run by GPLv2~\S0.

\medskip

The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used

throughout.  The only one worth discussing in detail is ``work based on

the Program''.  The reason this definition is particularly interesting is

not for the definition itself, which is rather straightforward, but

because it clears up a common misconception about the GPL\@.

The GPL is often mistakenly criticized because it fails to give a

definition of ``derivative work'' or ``combined work''.  In fact, it would be incorrect and

problematic if the GPL attempted to define these terms.  A copyright license, in

fact, has no control over the rules of copyright themselves.  Such rules are

the domain of copyright law and the courts --- not the licenses that utilize

those systems.

Copyright law as a whole does not propose clear and straightforward guidelines

for identifying the derivative and/or combined works of software.  However,

no copyright license --- not even the GNU GPL --- can be blamed for this.

Legislators and court opinions must give us guidance in borderline cases.

Meanwhile, lawyers will likely based their conclusions on the application of rules

made in the context of literary or artistic copyright to the different

context of computer programming and by analyzing the (somewhat limited) case

law and guidance available from various sources.

(Chapter~\ref{derivative-works} discusses this issue in depth.)

\section{GPLv2~\S1: Verbatim Copying}

\label{GPLv2s1}

GPLv2~\S1 covers the matter of redistributing the source code of a program

exactly as it was received. This section is quite straightforward.

However, there are a few details worth noting here.

The phrase ``in any medium'' is important.  This, for example, gives the

freedom to publish a book that is the printed copy of the program's source

code.  It also allows for changes in the medium of distribution.  Some

vendors may ship Free Software on a CD, but others may place it right on

the hard drive of a pre-installed computer.  Any such redistribution media

is allowed.

Preservation of copyright notice and license notifications are mentioned

specifically in GPLv2~\S1.  These are in some ways the most important part of

the redistribution, which is why they are mentioned by name.  GPL

always strives to make it abundantly clear to anyone who receives the

software what its license is.  The goal is to make sure users know their

rights and freedoms under GPL, and to leave no reason that users might be

surprised the software is GPL'd. Thus

throughout the GPL, there are specific references to the importance of

notifying others down the distribution chain that they have rights under

GPL.

GPL disclaims all warranties that legally can be disclaimed (which is

discussed later in sections~\ref{GPLv2s11} and~\ref{GPLv2s12}).  Users

generally rarely expect their software comes with any warranties, since

typically all EULAs and other Free Software licenses disclaim warranties too.

However, since many local laws require ``consipicous'' warranty disclaimers,

GPLv2~\S1 explicitly mentions the importance of keeping warranty disclaimers

in tact upon redistribution.

Note finally that GPLv2~\S1 creates groundwork for the important defense of

commercial freedom.  GPLv2~\S1 clearly states that in the case of verbatim

copies, one may make money.  Re-distributors are fully permitted to charge

for the re-distribution of copies of Free Software. In addition, they may

provide the warranty protection that the GPL disclaims as an additional

service for a fee. (See Section~\ref{Business Models} for more discussion

on making a profit from Free Software redistribution.)

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

\chapter{Derivative Works: Statute and Case Law}

\label{derivative-works}

As described in the \hyperref[copyleft-definition]{earlier general discussion

  of copyleft}, strong copyleft licenses such as the GPL seek to uphold

software freedom via the copyright system.  This principle often causes

theoretical or speculative dispute among lawyers, because ``the work'' ---

the primary unit of consideration under most copyright rules -- is not a unit

of computer programming. In order to determine whether a ``routine'' an

``object'', a ``function'', a ``library'' or any other unit of software is

part of one ``work'' when combined with other GPL'd code, we must ask a

question that copyright law will not directly answer in the same technical

terms.

Therefore, this chapter digresses from  discussion of GPL's exact text to

consider the matter of combined and/or derivative works --- a concept that we must

understand fully before considering GPLv2~\S\S2--3\@.  At least under USA

copyright law, The GPL, and Free

Software licensing in general, relies critically on the concept of

``derivative work'' since software that is ``independent,'' (i.e., not

``derivative'') of Free Software need not abide by the terms of the

applicable Free Software license. As much is required by \S~106 of the

Copyright Act, 17 U.S.C. \S~106 (2002), and admitted by Free Software

licenses, such as the GPL, which (as we have seen) states in GPLv2~\S0 that ``a

`work based on the Program' means either the Program or any derivative

work under copyright law.'' It is being a derivative work of Free Software

that triggers the necessity to comply with the terms of the Free Software

license under which the original work is distributed. Therefore, one is

left to ask, just what is a ``derivative work''? The answer to that

question differs depending on which court is being asked.

The analysis in this chapter sets forth the differing definitions of

derivative work by the circuit courts. The broadest and most

established definition of derivative work for software is the

abstraction, filtration, and comparison test (``the AFC test'') as

created and developed by the Second Circuit. Some circuits, including

the Ninth Circuit and the First Circuit, have either adopted narrower

versions of the AFC test or have expressly rejected the AFC test in

favor of a narrower standard. Further, several other circuits have yet

to adopt any definition of derivative work for software.

As an introductory matter, it is important to note that literal copying of

a significant portion of source code is not always sufficient to establish

that a second work is a derivative work of an original

program. Conversely, a second work can be a derivative work of an original

program even though absolutely no copying of the literal source code of

the original program has been made. This is the case because copyright

protection does not always extend to all portions of a program's code,

while, at the same time, it can extend beyond the literal code of a

program to its non-literal aspects, such as its architecture, structure,

sequence, organization, operational modules, and computer-user interface.

\section{The Copyright Act}

The copyright act is of little, if any, help in determining the definition

of a derivative work of software. However, the applicable provisions do

provide some, albeit quite cursory, guidance. Section 101 of the Copyright

Act sets forth the following definitions:

\begin{quotation}

A ``computer program'' is a set of statements or instructions to be used

directly or indirectly in a computer in order to bring about a certain

result.

A ``derivative work'' is a work based upon one or more preexisting works,

such as a translation, musical arrangement, dramatization,

fictionalization, motion picture version, sound recording, art

reproduction, abridgment, condensation, or any other form in which a work

may be recast, transformed, or adapted. A work consisting of editorial

revisions, annotations, elaborations, or other modifications which, as a

whole, represent an original work of authorship, is a ``derivative work.''

\end{quotation}

These are the only provisions in the Copyright Act relevant to the

determination of what constitutes a derivative work of a computer

program. Another provision of the Copyright Act that is also relevant to

the definition of derivative work is \S~102(b), which reads as follows:

\begin{quotation}

In no case does copyright protection for an original work of authorship

extend to any idea, procedure, process, system, method of operation,

concept, principle, or discovery, regardless of the form in which it is

described, explained, illustrated, or embodied in such work.

\end{quotation}

Therefore, before a court can ask whether one program is a derivative work

of another program, it must be careful not to extend copyright protection

to any ideas, procedures, processes, systems, methods of operation,

concepts, principles, or discoveries contained in the original program. It

is the implementation of this requirement to ``strip out'' unprotectable

elements that serves as the most frequent issue over which courts

disagree.

\section{Abstraction, Filtration, Comparison Test}

As mentioned above, the AFC test for determining whether a computer

program is a derivative work of an earlier program was created by the

Second Circuit and has since been adopted in the Fifth, Tenth, and

Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982

F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural

Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe,

Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates

Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993);

Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman

v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings,

Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).

Under the AFC test, a court first abstracts from the original program its

constituent structural parts. Then, the court filters from those

structural parts all unprotectable portions, including incorporated ideas,

expression that is necessarily incidental to those ideas, and elements

that are taken from the public domain. Finally, the court compares any and

all remaining kernels of creative expression to the structure of the

second program to determine whether the software programs at issue are

substantially similar so as to warrant a finding that one is the

derivative work of the other.

Often, the courts that apply the AFC test will perform a quick initial

comparison between the entirety of the two programs at issue in order to

help determine whether one is a derivative work of the other. Such a

holistic comparison, although not a substitute for the full application of

the AFC test, sometimes reveals a pattern of copying that is not otherwise

obvious from the application of the AFC test when, as discussed below,

only certain components of the original program are compared to the second

program. If such a pattern is revealed by the quick initial comparison,

the court is more likely to conclude that the second work is indeed a

derivative of the original.

\subsection{Abstraction}

The first step courts perform under the AFC test is separation of the

work's ideas from its expression. In a process akin to reverse

engineering, the courts dissect the original program to isolate each level

of abstraction contained within it. Courts have stated that the

abstractions step is particularly well suited for computer programs

because it breaks down software in a way that mirrors the way it is

typically created. However, the courts have also indicated that this step

of the AFC test requires substantial guidance from experts, because it is

extremely fact and situation specific.

By way of example, one set of abstraction levels is, in descending order

of generality, as follows: the main purpose, system architecture, abstract

data types, algorithms and data structures, source code, and object

code. As this set of abstraction levels shows, during the abstraction step

of the AFC test, the literal elements of the computer program, namely the

source and object code, are defined as particular levels of

abstraction. Further, the source and object code elements of a program are

not the only elements capable of forming the basis for a finding that a

second work is a derivative of the program. In some cases, in order to

avoid a lengthy factual inquiry by the court, the owner of the copyright in

the original work will submit its own list of what it believes to be the

protected elements of the original program. In those situations, the court

will forgo performing its own abstraction, and proceed to the second step of

the AFC test.

\subsection{Filtration}

The most difficult and controversial part of the AFC test is the second

step, which entails the filtration of protectable expression contained in

the original program from any unprotectable elements nestled therein. In

determining which elements of a program are unprotectable, courts employ a

myriad of rules and procedures to sift from a program all the portions

that are not eligible for copyright protection.

First, as set forth in \S~102(b) of the Copyright Act, any and all ideas

embodied in the program are to be denied copyright protection. However,

implementing this rule is not as easy as it first appears. The courts

readily recognize the intrinsic difficulty in distinguishing between ideas

and expression and that, given the varying nature of computer programs,

doing so will be done on an ad hoc basis. The first step of the AFC test,

the abstraction, exists precisely to assist in this endeavor by helping

the court separate out all the individual elements of the program so that

they can be independently analyzed for their expressive nature.

A second rule applied by the courts in performing the filtration step of

the AFC test is the doctrine of merger, which denies copyright protection

to expression necessarily incidental to the idea being expressed. The

reasoning behind this doctrine is that when there is only one way to

express an idea, the idea and the expression merge, meaning that the

expression cannot receive copyright protection due to the bar on copyright

protection extending to ideas. In applying this doctrine, a court will ask

whether the program's use of particular code or structure is necessary for

the efficient implementation of a certain function or process. If so, then

that particular code or structure is not protected by copyright and, as a

result, it is filtered away from the remaining protectable expression.

A third rule applied by the courts in performing the filtration step of

the AFC test is the doctrine of scenes a faire, which denies copyright

protection to elements of a computer program that are dictated by external

factors. Such external factors can include:

\begin{itemize}

  \item The mechanical

specifications of the computer on which a particular program is intended

to operate

  \item Compatibility requirements of other programs with which a

program is designed to operate in conjunction

  \item Computer manufacturers'

design standards

  \item Demands of the industry being serviced, and widely accepted programming practices within the computer industry

\end{itemize}

Any code or structure of a program that was shaped predominantly in

response to these factors is filtered out and not protected by

copyright. Lastly, elements of a computer program are also to be filtered

out if they were taken from the public domain or fail to have sufficient

originality to merit copyright protection.

Portions of the source or object code of a computer program are rarely

filtered out as unprotectable elements. However, some distinct parts of

source and object code have been found unprotectable. For example,

constants, the invariable integers comprising part of formulas used to

perform calculations in a program, are unprotectable. Further, although

common errors found in two programs can provide strong evidence of

copying, they are not afforded any copyright protection over and above the

protection given to the expression containing them.

\subsection{Comparison}

The third and final step of the AFC test entails a comparison of the

original program's remaining protectable expression to a second

program. The issue will be whether any of the protected expression is

copied in the second program and, if so, what relative importance the

copied portion has with respect to the original program overall. The

ultimate inquiry is whether there is ``substantial'' similarity between

the protected elements of the original program and the potentially

derivative work. The courts admit that this process is primarily

qualitative rather than quantitative and is performed on a case-by-case

basis. In essence, the comparison is an ad hoc determination of whether

the protectable elements of the original program that are contained in the

second work are significant or important parts of the original program. If

so, then the second work is a derivative work of the first. If, however,

the amount of protectable elements copied in the second work are so small

as to be de minimis, then the second work is not a derivative work of the

original.

\section{Analytic Dissection Test}

The Ninth Circuit has adopted the analytic dissection test to determine

whether one program is a derivative work of another. Apple Computer,

Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic

dissection test first considers whether there are substantial similarities

in both the ideas and expressions of the two works at issue. Once the

similar features are identified, analytic dissection is used to determine

whether any of those similar features are protected by copyright. This

step is the same as the filtration step in the AFC test. After identifying

the copyrightable similar features of the works, the court then decides

whether those features are entitled to ``broad'' or ``thin''

protection. ``Thin'' protection is given to non-copyrightable facts or

ideas that are combined in a way that affords copyright protection only

from their alignment and presentation, while ``broad'' protection is given

to copyrightable expression itself. Depending on the degree of protection

afforded, the court then sets the appropriate standard for a subjective

comparison of the works to determine whether, as a whole, they are

sufficiently similar to support a finding that one is a derivative work of

the other. ``Thin'' protection requires the second work be virtually

identical in order to be held a derivative work of an original, while

``broad'' protection requires only a ``substantial similarity.''

\section{No Protection for ``Methods of Operation''}

The First Circuit has taken the position that the AFC test is inapplicable

when the works in question relate to unprotectable elements set forth in

\S~102(b).  Their approach results in a much narrower definition

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

the

First Circuit holds that ``method of operation,'' as used in \S~102(b) of

the Copyright Act, refers to the means by which users operate

computers. Lotus Development Corp. v. Borland Int'l., Inc., 49 F.3d 807

(1st Cir. 1995).  In Lotus, the court held that a menu command

hierarchy for a computer program was uncopyrightable because it did not

merely explain and present the program's functional capabilities to the

user, but also served as a method by which the program was operated and

controlled. As a result, under the First Circuit's test, literal copying

of a menu command hierarchy, or any other ``method of operation,'' cannot

form the basis for a determination that one work is a derivative of

another.  As a result, courts in the First Circuit that apply the AFC test

do so only after applying a broad interpretation of \S~102(b) to filter out

unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc.,

683 F. Supp.2d 147, 154 (D. Mass. 2010).

\section{No Test Yet Adopted}

Several circuits, most notably the Fourth and Seventh, have yet to

declare their definition of derivative work and whether or not the

AFC, Analytic Dissection, or some other test best fits their

interpretation of copyright law. Therefore, uncertainty exists with

respect to determining the extent to which a software program is a

derivative work of another in those circuits. However, one may presume

that they would give deference to the AFC test since it is by far the

majority rule among those circuits that have a standard for defining

a software derivative work.

\section{Cases Applying Software Derivative Work Analysis}

In the preeminent case regarding the definition of a derivative work for

software, Computer Associates v. Altai, the plaintiff alleged that its

program, Adapter, which was used to handle the differences in operating

system calls and services, was infringed by the defendant's competitive

program, Oscar. About 30\% of Oscar was literally the same code as

that in Adapter. After the suit began, the defendant rewrote those

portions of Oscar that contained Adapter code in order to produce a new

version of Oscar that was functionally competitive with Adapter, without

having any literal copies of its code. Feeling slighted still, the

plaintiff alleged that even the second version of Oscar, despite having no

literally copied code, also infringed its copyrights. In addressing that

question, the Second Circuit promulgated the AFC test.

In abstracting the various levels of the program, the court noted a

similarity between the two programs' parameter lists and macros. However,

following the filtration step of the AFC test, only a handful of the lists

and macros were protectable under copyright law because they were either

in the public domain or required by functional demands on the

program. With respect to the handful of parameter lists and macros that

did qualify for copyright protection, after performing the comparison step

of the AFC test, it was reasonable for the district court to conclude that

they did not warrant a finding of infringement given their relatively minor

contribution to the program as a whole. Likewise, the similarity between

the organizational charts of the two programs was not substantial enough

to support a finding of infringement because they were too simple and

obvious to contain any original expression.

In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012),

the Northern District of California District Court examined the question of

whether the application program interfaces (APIs) associated with the Java

programming language are entitled to copyright protection.  While the

court expressly declined to rule whether all APIs are free to use without

license (872 F. Supp.2d 974 at 1002), the court held that the command

structure and taxonomy of the APIs were not protectable under copyright law.

Specifically, the court characterized the command structure and taxonomy as

both a ``method of operation'' (using an approach not dissimilar to the

First Circuit's analysis in Lotus) and a ``functional requirement for

compatibility'' (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and

Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies),

and thus unprotectable subject matter under \S~102(b).

Perhaps not surprisingly, there have been few other cases involving a highly

detailed software derivative work analysis. Most often, cases involve

clearer basis for decision, including frequent bad faith on the part of

the defendant or over-aggressiveness on the part of the plaintiff.

\section{How Much Do Derivative Works Matter?}

It is certainly true that GPL intends for any work that is determined a

``derivative work'' under copyright law must be licensed as a whole under

GPL\@, as will be discussed in the following chapter.  However, as we finish

up our discussion derivative works, we must note that preparation of a

derivative work in edge cases like the above is by far not the only way to

create a new work covered by GPL\@.

In fact, while questions on the limits of derivative work preparation are

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 discussions and considerations

in this chapter on other derivative works.

The question of any 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}

% FIXME: GPLv2~\S2(a) isn't discussed heavily here and more should be

% discussed about it.  There have been developer questions.  One idea I had

% was to write up:

%        http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

% as a compliance case study specific to GPLv2 Section 2(a)

% Another point to discuss here -- or maybe it goes better in the compliance

% case study ? -- is to explain that git logs ARE adequate but possibly

% overkill.

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

% FIXME-SOON:

%   A commonly asked question is whether or not separated distribution (i.e.,

%   dynamic loading of a module that is expected to be present on the

%   downstream sytem) triggers the copyleft requirement.  The text above

%   hints at that issue, with reference to Java runtime.  However, here would

%   likely be the natural place to discuss that issue in more depth.  I have

%   never actually studied this specific question in a GPLv2 vs. GPLv3

%   analysis, and as such I'd want to do that first.  Furthermore, the FSF

%   has not publicly opined on this question to my knowledge, so I'd want to

%   see possible update to

%   http://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic to mention

%   this issue before opining about it in the Guide.

%   I'm not aware, BTW, of any dissenting opinions or disagreements among

%   copyleft advocates on this point.  I think it's just a question that is

%   rarely opined on but often asked, so it's fitting for this Guide to cover

%   it, and for addition on this point in the FAQ.

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

\subsection{Complete, Corresponding Source (CCS)}

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.

Based on the appearance of those two words, GPL theorists will often refer to

the source code required under the previsions of this section as ``Complete,

Corresponding Source'', sometimes abbreviated as CCS\@.  CCS is not a formal,

defined term in GPLv2, but rather, GPL theorists coined the acronym CCS to

embody not just the concepts of ``complete'' and ``corresponding'' as found

in GPLv2, but the entirety of GPLv2's requirements for source code

provisioning.  In other words, GPL theorists might say: ``the company

provided some source, but it wasn't CCS'', which would mean the source code

failed in some ways to meet some term of GPLv2.

\label{GPLv2s3-build-scripts}

Indeed, CCS needs completely include not just that source which is directly

translated by the compiler into object code, but other materials necessary to

convert the source into equivalent binaries.  Specifically, 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.

This requirement is not merely of theoretical value.  If you pay a high price

for a copy of GPL'd binaries (which comes with CCS, 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.  Such distributions violate GPL, since the downstream users cannot

effectively ``control compilation and installation'' of the binaries.

\subsection{Additional Source Provision Options}

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.

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)

prohibit using GPL'd software. For this situation and others like it, GPLv2\S~3(b) is available.

\label{GPLv2s3b}

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 re-distributors, 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 that

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'

customers.  A customer, who had received binaries with a GPLv2~\S3(b)-compliant

offer, would be required under GPLv2 (sans GPLv2~\S3(c)) to acquire the source,

merely to give a copy of the software to a friend who needed it.  GPLv2~\S3(c)

reshifts this burden to entity who benefits from GPLv2~\S3(b).

GPLv2~\S3(c) allows those who undertake \emph{noncommercial} distribution to

simply pass along a GPLv2~\S3(b)-compliant source code offer.  The customer who

wishes to give a copy to her friend can now do so without provisioning the

source, as long as she gives that offer to her friend.  By contrast, if

she wanted to go into business for herself selling CDs of that software,

she would have to acquire the source and either comply via GPLv2~\S3(a), or

write her own GPLv2~\S3(b)-compliant source offer.

This process is precisely the reason why a GPLv2~\S3(b) source offer must be

valid for all third parties.  At the time the offer is made, there is no

way of knowing who might end up noncommercially receiving a copy of the

software.  Companies who choose to comply via GPLv2~\S3(b) must thus be

prepared to honor all incoming source code requests.  For this and the

many other additional necessary complications under GPLv2~\S\S3(b--c), it is

only rarely a better option than complying via GPLv2~\S3(a).

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

\chapter{GPL's Implied Patent Grant}

\label{gpl-implied-patent-grant}

We digress again briefly from our section-by-section consideration of GPLv2

to consider the interaction between the terms of GPL and patent law. The

GPLv2, despite being silent with respect to patents, actually confers on its

licensees more rights to a licensor's patents than those licenses that

purport to address the issue. This is the case because patent law, under

the doctrine of implied license, gives to each distributee of a patented

article a license from the distributor to practice any patent claims owned

or held by the distributor that cover the distributed article. The

implied license also extends to any patent claims owned or held by the

distributor that cover ``reasonably contemplated uses'' of the patented

article. To quote the Federal Circuit Court of Appeals, the highest court

for patent cases other than the Supreme Court:

\begin{quotation}

Generally, when a seller sells a product without restriction, it in

effect promises the purchaser that in exchange for the price paid, it will

not interfere with the purchaser's full enjoyment of the product

purchased. The buyer has an implied license under any patents of the

seller that dominate the product or any uses of the product to which the

parties might reasonably contemplate the product will be put.

\end{quotation}

Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d

1445, 1451 (Fed. Cir. 1997).

Free Software offers the user all rights to enjoy the software in the

privacy of their home, and while it places conditions on acts covered by

copyright, that is typically triggered by distributing and it's not

likely to prevent the application of the implied license doctrine to Free

Software. Software licensed under the GPL grants the licensee the right to

make, use, and sell the software, each of which are exclusive rights of a

patent holder. Therefore, although the GPLv2 does not expressly grant the

licensee the right to do those things under any patents the licensor may

have that cover the software or its reasonably contemplated uses, by

licensing the software under the GPLv2, the distributor impliedly licenses

those patents to the GPLv2 licensee with respect to the GPLv2'd software.

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

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

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

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

larger in scope than the express license in other Free Software

licenses with express patent grants, in that the patent license

clause of many of those other Free  Software licenses are specifically

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

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

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

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

include creation and distribution of modified 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'd Web browsing software program, or on that party's

creation and use of modified versions of that GPL'd 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 modified version 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 (if and because they're prohibited by copyright).

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.

GPLv2~\S6 is GPLv2's ``automatic downstream licensing''

provision\footnote{This section was substantially expanded for clarity and

  detail in \hyperref[GPLv3s10]{GPLv3~\S10}.}.  Each time you

redistribute a GPL'd program, the recipient automatically receives a license

from each original licensor to copy, distribute or modify the program subject

to the conditions of the license.  The redistributor need not take any

to ensure the downstream recipient's acceptance of the license terms.

This places every copyright holder in the chain of descent of the code

in legal privity, or direct relationship, with every downstream

redistributor.  Two legal effects follow.  First, downstream parties

who remain in compliance have valid permissions for all actions

(including modification and redistribution) even if their immediate upstream

supplier of the software has been terminated for license

violation\footnote{\label{German-reinstatement-footnote} While this is legally true, as a practical matter, a

  failure of ``complete, corresponding source'' (CCS) provisioning by an

  upstream could make it effectively impossible for a downstream party to

  engage in a commercial redistribution pursuant to

  \hyperref[GPLv2s3]{GPLv2~\S3(a--b)}.  (\S~\ref{upstream} in the Compliance

  Guide portion of this tutorial discussed related details.)}\footnote{In the larger

  Free Software community, it is generally understood that the copyright permissions

  of downstream parties are valid regardless whether someone on their distribution

  chain may have lost their license, because their permissions come from the copyright

  holder, and the license text grants those permissions (as long as one complies with

  its conditions). From this perspective, the GPL's ``automatic downstream licensing''

  provision is a restatement or reinforcement of that obvious rule, not a new or

  specific clause. This intuition is valuable and one can argue it is not unwarranted,

  because, among others, there is a fundamental distinction in US copyright law between

  material object (the copy) and the intellectual content (the work): the physical ``source''

  from where the downstream licensee got the copy doesn't preclude that they get a license

  to the content from the copyright holder(s), i.e. the permissions under certain conditions

  as spelled out in the text.}.

Downstream's

licensed rights are not dependent on compliance of their upstream, because

their licenses issue directly from the copyright holder.  Second, automatic

termination cannot be cured by obtaining additional copies from an alternate

supplier: the license permissions emanate only from the original licensors,

and if they have automatically terminated permission, no act by any

intermediate license holder can restore those terminated

rights\footnote{While nearly all attorneys and copyleft theorists are in

  agreement on this point, German copyleft legal expert

  \href{http://www.jbb.de/en/attorneys/till-jaeger/}{Till Jaeger}

  vehemently disagrees.  Jaeger's position is as follows: under German

  copyright law, a new copy of GPL'd software is a ``fresh'' license under

  GPL, and if compliance continues from that point further, the violator's

  permissions under copyright law are automatically restored, notwithstanding

  the strict termination provision in \hyperref[GPLv2s4]{GPLv2~\S4}.

  However, in

  practice, this issue is only salient with regard to \hyperref[Proprietary

    Relicensing]{proprietary relicensing} business models, since other copyright

  holders typically formally restore distributions rights once the only

  remaining compliance issue is ``you lost copyright permission due to

  GPLv2~\S4''.  Therefore, the heated debates, which have raged between

  Jaeger and almost everyone else in the copyleft community for nearly a

  decade, regard an almost moot and wholly esoteric legal detail.}.

\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

of the GPLv2 handles administrivia and issues concerning warranties and

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 shouts at you.  The

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

  Code~\S2-316}, which most of the USA's states and commonwealths have adopted as their local

law, allows disclaimers of warranty, provided that the disclaimer is ``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

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

% FIXME: Should UCITA be mentioned anywhere in here?  It was previously

% mentioned elsewhere in the tutorial but it was out of context and not

% useful.  If it should be mentioned anywhere, here is probably the spot, but

% it's not clear we should mention it at all, since it's specific just to two

% state/commonwealths in the USA: MD and VA.

Critics have occasionally questioned GPL's enforceability in some jurisdictions because its

disclaimer of warranties is impermissibly broad.  However,

critics

have generally failed to articulate specific precedents in their

jurisdictions that would directly indicate a problem with GPL's warranty

disclaimer.  Meanwhile,

\href{http://www.cisg.law.pace.edu/cisg/text/treaty.html#35}{Article 35 of

  the United Nations Convention on Contracts for the International Sale of

  Goods} (often abbreviated ``CISG'', which

\href{https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&id=228&chapter=10&lang=en}{many

  countries have adopted}) permits the disclaimer of warranties, so

jurisdictions adopting this treaty allow some form of warranty

disclaimer\footnote{Scholars continue to debate to what extent CISG applies to software

  licenses.  For example, Diedrich concluded that ``CISG is prima facie

  applicable to international transactions involving the transfer of computer

  software for a price'', but Sono disagrees with this ``prevailing view'',

  presenting an ``analysis [that] restricts the applicability of the CISG to

  software transactions by excluding `license contracts'''.  (See

  \href{http://www.cisg.law.pace.edu/cisg/biblio/diedrich1.html}{Frank

    Diedrich, \textit{The CISG and Computer Software Revisited}}, 6 Vindobona

  Journal of International Commercial Law and Arbitration, Supplement 55--75

  (2002), and

\href{http://www.cisg.law.pace.edu/cisg/biblio/sono6.html}{Hiroo Sono,

  \textit{The Applicability and Non-Applicability of the CISG to Software

    Transactions}}, Camilla B. Andersen \& Ulrich G. Schroeter eds., Sharing

International Commercial Law across National Boundaries: Festschrift for

Albert H. Kritzer on the Occasion of his Eightieth Birthday, Wildy, Simmonds

\& Hill Publishing (2008) 512--526.)}.

Nevertheless, to account for possible jurisdictional variances regarding this

or any other issue, 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

used alongside GPLv2.  However, given GPLv2's widespread popularity and

existing longevity by the time GPLv3 was published, it is not surprising that

some licensors still prefer GPLv2-only or GPLv2-or-later.  GPLv3 gained major

adoption by many projects, old and new, but many projects have not upgraded

due to (in some cases) mere laziness and (in other cases) policy preference

for some of GPLv2's terms and/or policy opposition to GPLv3's terms.

Given this ``two GPLs world'' is reality, it makes sense to consider GPLv3 in

terms of how it differs from GPLv2.  Also, most of the best GPL experts in

the world must deal regularly with both licenses, and admittedly have decades

of experience with GPLv2 while the most experience with GPLv3 that's possible

is by definition less than a decade.  These two factors usually cause even new

students of GPL to start with GPLv2 and move on to GPLv3, and this tutorial

follows that pattern.

Overall, the changes made in GPLv3 admittedly \textit{increased} the

complexity of the license.  The FSF stated at the start of the GPLv3 process

that they would have liked to oblige those who have asked for a simpler and

shorter GPL\@.  Ultimately, the FSF gave priority to making GPLv3 a better

copyleft license in the spirit of past GPL's.  Obsession for concision should

never trump software freedom.

The FSF had many different, important goals in seeking to upgrade to GPLv3.

However, one important goal that is often lost in the discussion of policy

minutia is a rather simple but important issue.  Namely, FSF sought to assure

that GPLv3 was more easily internationalized than GPLv2.  In particular, the

FSF sought to ease interpretation of GPL in other countries by replacement of

USA-centric\footnote{See Section~\ref{non-usa-copyright} of this tutorial for

  a brief discussion about non-USA copyright systems.}  copyright phrases and

wording with neutral terminology rooted in description of behavior rather

than specific statute.  As can be seen in the section-by-section discussion of

GPLv3 that follows, nearly every section had changes related to issues of

internationalization.

\section{GPLv3~\S0: Giving In On ``Defined Terms''}

\label{GPLv3s0}

One of lawyers' most common complaints about GPLv2 is that defined terms in

the document appear throughout.  Most licenses define terms up-front.

However, the GPL was always designed both as a document that should be easily

understood both by lawyers and by software developers: it is a document

designed to give freedom to software developers and users, and therefore it

should be comprehensible to that constituency.

Interestingly enough, one coauthor of this tutorial who is both a lawyer and

a developer pointed out that in law school, she understood defined terms more

quickly than other law students precisely because of her programming

background.  For developers, having \verb0#define0 (in the C programming

language) or other types of constants and/or macros that automatically expand

in the place where they are used is second nature.  As such, adding a defined

terms section was not terribly problematic for developers, and thus GPLv3

adds one.  Most of these defined terms are somewhat straightforward and bring

forward better worded definitions from GPLv2.  Herein, this tutorial

discusses a few of the new ones.

GPLv3~\S0 includes definitions of five new terms not found in any form in

GPLv2: ``modify'' ``covered work'', ``propagate'', ``convey'', and

``Appropriate Legal Notices''.

\subsection{Modify and the Work Based on the Program}

%  FIXME: I think we actually need to research the claim below that

%  ``derivative work'' as a term is unique to USA copyright law.  I have

%  heard German lawyers, for example, use the term extensively.  Is it also a

%  term perhaps under German law?  -- bkuhn

GPLv2 included a defined term, ``work based on the Program'', but also used

the term ``modify'' and ``based on'' throughout the license.  GPLv2's ``work

based on the Program'' definition made use of a legal term of art,

``derivative work'', which is peculiar to USA copyright

law.\footnote{Ironically, most criticism of USA-specific legal

terminology in GPLv2's ``work based on the Program'' definition historically

came not primarily from readers outside the USA, but from those within

it.  The FSF noted in that it did not generally agree with these

  views, and expressed puzzlement by the energy with which they were

  expressed, given the existence of many other, more difficult legal issues

  implicated by the GPL.  Nevertheless, the FSF argued that it made sense to

  eliminate usage of local copyright terminology to good effect.}  GPLv2

always sought to cover all rights governed by relevant copyright law, in the

USA and elsewhere.

Even though differently-labeled concepts corresponding to the

derivative work are recognized in all copyright law systems, these

counterpart concepts might differ to some degree in scope and breadth from

the USA derivative work.  GPLv3 therefore internationalizes

on this issue by removing GPLv2's references to derivative

works and by providing a more globally useful definition.

GPLv3 drops all reference to USA ``derivative works'' and returns

to the base concept only: GPL covers the licensed work and all works where

copyright permission from the licensed work's copyright holder.

The new definitions returns to the common elements of copyright law.  Copyright

holders of works of software have the exclusive right to form new works by

modification of the original --- a right that may be expressed in various

ways in different legal systems.  GPLv3 operates to grant this right to

successive generations of users (particularly through the copyleft conditions

set forth in GPLv3~\S5, as described later in this tutorial in its

\S~\ref{GPLv3s5}).  Here in GPLv3~\S0, ``modify'' refers to basic copyright

rights, and then this definition of ``modify'' is used to define ``modified

version of'' and ``work based on'' as synonyms.

\subsection{The Covered Work}

GPLv3 uses a common license drafting technique of building upon simpler

definitions to make complex ones.  The Program is a defined term found

throughout GPLv2, and the word ``covered'' and the phrase ``covered by this

license'' are used in tandem with the Program in GPLv2, but not as part of a

definition.  GPLv3 offers a single term ``covered work'', which enables some

of the wording in GPLv3 to be simpler and clearer than its GPLv2

counterparts.

Next, to avoid locking GPLv3 into specific copyright statues, the GPLv3

defines two terms that are otherwise exotic to the language of international

copyright.

\subsection{Propagate}

To ``propagate'' a work covered by the license means any activity in a locale

that requires permission of copyright holders in that locale's legal system.

However, personal use or modification for personal use are activities explicitly

excluded from ``propagation'' \textit{regardless} of domestic copyright law.

The term ``propagate'' serves two purposes.  First, ``propagate'' provides a

simple and convenient means for distinguishing between the kinds of uses of a

work that GPL imposes conditions on and the kinds of uses that GPL does not

(for the most part) impose conditions on.

Second, ``propagate'' helps globalize GPL in its wording and effect:

``derivative work'' was in fact not the only term commonly used by local

copyright statutes.  A term like ``distribute'' (or its equivalent in

languages other than English) is also used in several national copyright

statutes.  Practical experience with GPLv2 revealed the awkwardness of using

the term ``distribution'' in a license intended for global use: the scope of

``distribution'' in the copyright context can differ from country to country.

The GPL never necessarily intended the specific meaning of ``distribution''

that exists under USA (or any other country's) copyright law.

Indeed, even within a single country and language, the term distribution may

be ambiguous; as a legal term of art, distribution varies significantly in

meaning among those countries that recognize it.  For example, comments

during GPLv3's drafting process indicated that in at least one country,

distribution may not include network transfers of software but may include

interdepartmental transfers of physical copies within an organization.

Meanwhile, the copyright laws of many countries, as well as certain

international copyright treaties, recognize ``making available to the

public'' or ``communication to the public'' as one of the exclusive rights of

copyright holders.

Therefore, the GPLv3 defines the term ``propagate'' by reference to activities

that require permission under ``applicable copyright law'', but excludes

execution and private modification from the definition.  GPLv3's definition

also gives examples of activities that may be included within ``propagation''

but it also makes clear that, under the copyright laws of a given country,

``propagation'' may include other activities as well.

Thus, propagation is defined by behavior, and not by categories drawn from

some particular national copyright statute.  This helps not only with

internationalization, but also factually-based terminology aids in

developers' and users' understanding of the GPL\@.

As a further benefit, because ``propagation'' includes all

exclusive rights granted under any particular copyright regime, the term

automatically  accounts for all exclusive rights under that regime.

\subsection{Convey}

Next, GPLv3 defines a subset of propagate --- ``convey''.

Conveying includes activities that constitute propagation of copies to

others.  As with the definition of propagate, GPLv3 thus addresses transfers

of copies of software in behavioral rather than statutory terms.

Any propagation that enables other parties to receive or make copies of the

work, is called ``conveying''.  Usually, conveying is the activity that

triggers most of the other obligations of GPLv3.

\subsection{Appropriate Legal Notices}

GPLv2 used the term ``appropriate copyright notice and disclaimer of

warranty'' in two places, which is a rather bulky term.  Also, experience with

GPLv2 and other licenses that grant software freedom showed throughout the

1990s that the scope of types of notices that need preservation upon

conveyance were more broad that merely the copyright notices.  The

Appropriate Legal Notice definition consolidates the material that GPLv2

traditionally required preserved into one definition.

\subsection{Other Defined Terms}

Note finally that not all defined terms in GPLv3 appear in GPLv3~\S0.

Specifically, those defined terms that are confined in use to a single

section are defined in the section in which they are used, and GPLv3~\S1

contains those definitions focused on source code.  In this tutorial, those

defined terms are discussed in the section where they are defined and/or

used.

\section{GPLv3~\S1: Understanding CCS}

\label{GPLv3s1}

Ensuring that users have the source code to the software they receive and the

freedom to modify remains the paramount right embodied in the Free Software

Definition (found in \S~\ref{Free Software Definition} of this tutorial).  As

such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it

contains all the defined terms related to this important software freedom.

\subsection{Source Code Definition}

First, GPLv3~\S1 retains GPLv2's definition of ``source code'' and adds an

explicit definition of ``object code'' as ``any non-source version of a

work''.  Object code is not restricted to a narrow technical meaning and is

understood broadly to include any form of the work other than the preferred

form for making modifications to it.  Object code therefore includes any kind

of transformed version of source code, such as bytecode or minified

Javascript.  The definition of object code also ensures that licensees cannot

escape their obligations under the GPL by resorting to shrouded source or

obfuscated programming.

\subsection{CCS Definition}

\label{CCS Definition}

The definition of CCS,\footnote{Note that the preferred term for those who

  work regularly with both GPLv2 and GPLv3 is ``Complete Corresponding

  Source'', abbreviated to ``CCS''.  Admittedly, the word ``complete'' no

  longer appears in GPLv3 (which uses the word ``all'' instead).  However,

  both GPLv2 and the early drafts of GPLv3 itself used the word ``complete'',

  and early GPLv3 drafts even called this defined term ``Complete

  Corresponding Source''.  Meanwhile, use of the acronym ``CCS'' (sometimes,

  ``C\&CS'') was so widespread among GPL enforcers that its use continues

  even though GPLv3-focused experts tend to say just the defined term of

  ``Corresponding Source''.} or, as GPLv3 officially calls it,

``Corresponding Source'' in GPLv3~\S1\P4 is possibly the most complex

definition in the license.

The CCS definition is broad so as to protect users' exercise of their rights

under the GPL\@.  The definition includes particular examples to remove

any doubt that they are to be considered CCS\@.  GPLv3 seeks to make it

completely clear that a licensee cannot avoid complying with the requirements

of the GPL by dynamically linking a subprogram component to the original

version of a program.  The examples also clarify that the shared libraries

and dynamically linked subprograms that are included in Corresponding Source

are those that the work is ``specifically'' designed to require, which

clarifies that they do not include libraries invoked by the work that can be

readily substituted by other existing implementations.  While copyleft

advocates never doubted this was required under GPLv2's definition of CCS,

GPLv3 makes it abundantly clear with an extra example.

The GPL, as always, seeks to ensure users are truly in a position to install and

run their modified versions of the program; the CCS definition is designed to

be expansive to ensure this software freedom.  However, although the

definition of CCS is expansive, it is not sufficient to protect users'

freedoms in many circumstances.  For example, a GPL'd program, or a modified

version of such a program, might be locked-down and restricted.  The

requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this

tutorial) handle that issue.  (Early drafts of GPLv3 included those

requirements in the definition of CCS; however, given that the lock-down

issue only comes up in distribution of object code, it is more logical to

place those requirements with the parts of GPLv3 dealing directly with object

code distribution).

The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does

not require source that can be automatically generated.  Many code

generators, preprocessors and take source code as input and sometimes even

have output that is still source code.  Source code should always be whatever

the original programmer preferred to modify.

GPLv3\S1's final paragraph removes any ambiguity about what should be done on

source-only distributions.  Specifically, the right to convey source code

that does not compile, does not work, or otherwise is experimental

in-progress work is fully permitted, \textit{provided that} no object code

form is conveyed as well.  Indeed, when combined with the permissions in

GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can

never be required to provide more than that.  One always has the right to

modify a source code work by deleting any part of it, and there can be no

requirement that free software source code be a whole functioning program.

\subsection{The System Library Exception}

\label{GPLv3-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

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 prohibition of that 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 replacing 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

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

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

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}

\label{GPLv3S2}

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

in \S~\ref{GPLv2s0} of this tutorial).  However, the usual style of

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.  While these basic freedoms were

generally considered a standard part of users' rights under GPLv2 as well,

the GPLv3 states them herein more explicitly.  In other words, there is no

direct analog to the first sentence of GPLv3~\S2\P2 in GPLv2

(See \S~\ref{gplv2-private-modification} of this tutorial for more on this issue.)

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, contractor gets the

full freedoms of the GPL that they deserve.

The FSF was specifically asked to add this ``contractors provisions'' by

large enterprise users of Free Software, who often contract with non-employee

developers, working offsite, to make modifications intended for the user's

private or internal use, and often arrange with other companies to operate

their data centers.  Whether GPLv2 permits these activities is not clear and

may depend on variations in copyright law in different jurisdictions.  The

practices seem basically harmless, so FSF decided to make it clear they are

permitted.

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

way --- through its automatic licensing provision found in GPLv3~\S10 (which

is discussed in more detail in \S~\ref{GPLv3s10} of this tutorial).

\section{GPLv3's views on DRM and Device Lock-Down}

\label{GPLv3-drm}

The issues of DRM, device lock-down and encryption key disclosure were the

most hotly debated during the GPLv3 process.  FSF's views on this were sadly

frequently misunderstood and, comparing the provisions related to these

issues in the earliest drafts of GPLv3 to  the final version of GPLv3 shows

the FSF's willingness to compromise on tactical issues to reach the larger

goal of software freedom.

Specifically, GPLv3 introduced provisions that respond to the growing

practice of distributing GPL-covered programs in devices that employ

technical means to restrict users from installing and running modified

versions.  This practice thwarts the expectations of developers and users

alike, because the right to modify is one of the core freedoms the GPL is

designed to secure.

Technological measures to defeat users' rights.  These measures are often

described by such Orwellian phrases, such as ``digital rights management,''

which actually means limitation or outright destruction of users' legal

rights, or ``trusted computing,'' which actually means selling people

computers they cannot trust.  However, these measures are alike in one basic

respect.  They all employ technical means to turn the system of copyright law

(where the powers of the copyright holder are limited exceptions to general

freedom) into a virtual prison, where everything not specifically permitted

is utterly forbidden.  This system of ``para-copyright'' was created well

after GPLv2 was written --- initially through legislation in the USA and the

EU, and later in other jurisdictions as well.  This legislation creates

serious civil or even criminal penalties to escape from these restrictions

(commonly and aptly called ``jail-breaking a device''), even where the

purpose in doing so is to restore the users' legal rights that the technology

wrongfully prevents them from exercising.

GPLv2 did not address the use of technical measures to take back the rights

that the GPL granted, because such measures did not exist in 1991, and would

have been irrelevant to the forms in which software was then delivered to

users.  GPLv3 addresses these issues, particularly because copylefted

software is ever more widely embedded in devices that impose technical

limitations on the user's freedom to change it.

However, FSF always made a clear distinction to avoid conflating these

``lock-down'' measures with legitimate applications that give users control,

as by enabling them to choose higher levels of system or data security within

their networks, or by allowing them to protect the security of their

communications using keys they can generate or copy to other devices for

sending or receiving messages.  Such technologies present no obstacles to

software freedom and the goals of copyleft.

The public GPLv3 drafting process sought to balance these positions of

copyleft advocates with various disparate views of the larger

Free-Software-using community.  Ultimately, FSF compromised to the GPLv3\S3

and GPLv3\S6 provisions that, taken together, are a minimalist set of terms

sufficient to protect the software freedom against the threat of invasive

para-copyright.

The compromises made were ultimately quite reasonable.  The primary one is

embodied in GPLv3\S6's ``User Product'' definition (see \S~\ref{user-product}

in this tutorial for details).  Additionally, some readers of early GPLv3

drafts seem to have assumed GPLv3 contained a blanket prohibition on DRM; but

it does not.  In fact, no part of GPLv3 forbids DRM regarding non-GPL'd

works; rather, GPLv3 forbids the use of DRM specifically to lock-down

restrictions on users' ability to install modified versions of the GPL'd

software itself, but again, \textit{only} with regard to User Products.

\section{GPLv3~\S3: What Hath DMCA Wrought}

\label{GPLv3s3}

As discussed in \S~\ref{software-and-non-copyright} of this tutorial,

\href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} and

related sections\footnote{These sections of the USC are often referred to as

  the ``Digital Millennium Copyright Act'', or ``DMCA'', as that was the name

  of the bill that so-modified these sections of the USC\@.} prohibits users

from circumventing technological measures that implement DRM\@.  Since this

is part of copyright law and the GPL is primarily a copyright license, and

since what the DMCA calls ``circumvention'' is simply ``modifying the

software'' under the GPL, GPLv3 must disclaim that such anti-circumvention

provisions are not applicable to the GPLv3'd software.  GPLv3\S3 shields

users from being subjected to liability under anti-circumvention law for

exercising their rights under the GPL, so far as the GPL can do so.

First, GPLv3\S3\P1 declares that no GPL'd program is part of an effective

technological protection measure, regardless of what the program does.  Early

drafts of GPLv3\S3\P1 referred directly to the DMCA, but the final version

instead includes instead an international legal reference to

anticircumvention laws enacted pursuant to the 1996 WIPO treaty and any

similar laws.  Lawyers outside the USA worried that a USA statutory reference

could be read as indicating a choice for application of USA law to the

license as a whole.  While the FSF did not necessarily agree with that view,

the FSF decided anyway to refer to the WIPO treaty rather than DMCA, since

several national anticircumvention laws were (or will likely be) structured

more similarly to the anticircumvention provisions of the DMCA in their

implementation of WIPO\@.  Furthermore, the addition of ``or similar laws''

provides an appropriate catch-all.

GPLv3\S3\P2 states precisely that a conveying party waives the

power to forbid circumvention of technological measures only to the extent

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}

\label{GPLv3s4}

GPLv3~\S4 is a revision of GPLv2~\S1 (as discussed in \S~\ref{GPLv2s1} of

this tutorial).   There are almost no changes to this section from the

GPLv2~\S1, other than to use the new defined terms.

The only notable change, of ``a fee'' to ``any price or no price'', is in the

first sentence of GPLv3\S4\P2.  The GPLv2\S1\P1 means that the GPL permits

one to charge money for the distribution of software.  Despite efforts by

copyleft advocates to explain this in GPLv2 itself and in other documents,

there are evidently some people who still believe that GPLv2 allows charging

for services but not for selling copies of software and/or that the GPL

requires downloads to be gratis.  Perhaps this is because GPLv2 referred to

charging a ``fee''; the term ``fee'' is generally used in connection with

services.

GPLv2's 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''.

To address these two issues, GPLv3 says ``price'' in place of ``fee,'' and

removes the term ``physical.''

GPLv3~\S4 has also been revised from its corresponding section in GPLv2 in

light of the GPLv3~\S7 (see \S~\ref{GPLv3s7} in this tutorial for more).

Specifically, a distributor of verbatim copies of the program's source code

must obey any existing additional terms that apply to parts of the program

pursuant to GPLv3~\S7.  In addition, the distributor is required to keep

intact all license notices, including notices of such additional terms.

Finally, 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}

\label{GPLv3s5}

GPLv3\S5 is the rewrite of GPLv2\S2, which was discussed in \S~\ref{GPLv2s2}

of this tutorial.  This section discusses the changes found in GPLv3\S5

compared to GPLv2\S2.

GPLv3\S5(a) still requires modified versions be marked with ``relevant

date'', but no longer says ``the date of any change''.  The best practice is

to include the date of the latest and/or most significant changes and who

made those.  Of course, compared to its GPLv2\S2(a), GPLv3\S5(a) 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.

GPLv3\S5(b) is a new but simple provision. GPLv3\S5(b)  requires that the

license text itself must be unmodified (except as permitted by GPLv3\S7; see

\S~\ref{GPLv3s7} in this tutorial).  Furthermore, it  removes any perceived

conflict between the words ``keep intact all notices'' in GPLv3\S4, since

operating under GPLv3\S5 still includes all the requirements of GPLv3\S4 by

reference.

GPLv3\S5(c) is the primary source-code-related copyleft provision of GPL. (The

object-code-related copyleft provisions are in GPLv3\S6, discussed in

\S~\ref{GPLv3s6} of this tutorial).  Compared to GPLv2\S2(b), GPLv3\S5(c)

states that the GPL applies to the whole of the work.  Such was stated

already in GPLv2\S2(b), in ``in whole or in part'', but this simplified

wording makes it clear it applies to the entire covered work.

Another change in GPLv3\S5(c) is the removal of the

words ``at no charge,'' which was often is misunderstood upon na\"{i}ve

reading of in GPLv2\S(b) (as discussed in \S~\ref{GPLv2s2-at-no-charge} of this

tutorial).

%  FIXME-LATER: Write up something on 5d, and related it to Appropriate Legal Notices.

Note that of GPLv2~\S2's penultimate and ante-penultimate paragraphs are now

handled adequately by the definitions in GPLv3\S0 and as such, have no direct

analogs in GPLv3.

GPLv2~\S2's final paragraph, however, is reworded and expanded into the final

paragraph of GPLv3\S5, which now also covers issues related to copyright

compilations (but not compilations into object code --- that's in the next

section!).  The intent and scope is the same as was intended in GPLv2.

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

\label{GPLv3s6}

GPLv3~\S6 states the compliance obligations for distributing ``non-source

forms'' of a program (which means any form other than CCS).  As noted in \S~\ref{GPLv3s0}, ``object code'' in GPLv3

is defined broadly to mean any non-source version of a work, and thus

includes not only binaries or executables, but also obfuscated, minimized, compressed or otherwise

non-preferred forms for modification.  Thus, GPLv3~\S6 clarifies and revises GPLv2~\S3.

Indeed, GPLv3~\S6's CCS requirement under

closely parallels the provisions of \hyperref[GPLv2s3]{GPLv2~\S3}, with changes

designed to make compliant provisioning easier under contemporary

technological conditions.  Distributors of GPLv3'd

object code must provide access to the corresponding source code, in one of

four specified ways.

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

GPLv3~\S6(a--b) 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~\S3 (discussed

in \S~\ref{GPLv2s3} of this tutorial), the distribution of object code may

either be accompanied by the machine-readable source code, or it may be

accompanied by a valid written offer to provide the machine-readable source

code.  However, unlike in GPLv2, that offer cannot be exercised by any third

party; rather, only those ``who possess the object code'' can exercise

the offer.  (Note that this is a substantial narrowing of requirements of

offer fulfillment, and is a wonderful counterexample to dispute claims that

the GPLv3 has more requirements than GPLv2.)

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

GPLv3~\S6(b) further 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.  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.

GPLv3~\S6(a--b) clarifies that the medium for software interchange on which

the machine-readable source code is provided must be a durable physical

medium.  GPLv3~\S6(b)(2), however, permits a distributor to instead offer to

provide source code from a network server instead, which is yet another

example GPLv3 looser in its requirements than GPLv2 (see

\S~\ref{GPLv2s3-medium-customarily} for details).

% FIXME-LATER: more information about source provision, cost of physically

% performing, reasonable fees, medium customary clearly being said durable

% connecting back to previous text

GPLv3\S6(c) gives narrower permission than GPLv2\S3(c).  The ``pass along''

option for GPLv3\S6(c)(1) offers is now available only for individual

distribution of object code; moreover, such individual distribution can occur

only ``occasionally and noncommercially.''  A distributor cannot comply with

the GPL merely by making object code available on a publicly-accessible

network server accompanied by a copy of the written offer to provide source

code received from an upstream distributor.

%FIXME-LATER: tie back to the discussion of the occasional offer pass along

%             stuff in GPLv2 this tutorial.

GPLv3~\S6(d) revises and improves GPLv2~\S3's final paragraph.  When object

code is provided by offering access to copy the code from a designated place

(such as by enabling electronic access to a network server), the distributor

must merely offer equivalent access to copy the source code ``in the same way

through the same place''.  This wording also permits a distributor to offer a

third party access to both object code and source code on a single network

portal or web page, even though the access may include links to different

physical servers.  For example, a downstream distributor may provide a link

to an upstream distributor's server and arrange with the operator of that

server to keep the source code available for copying for as long as the

downstream distributor enables access to the object code.  Thus,

the obligation remains on the party distributing object code to point

prominently (``next to'' the object code download) to the third-party source

code provisioning server, and to ensure that this third-party server remains

in operation for required period.  This codifies formally the typical

historical interpretation of GPLv2.

% FIXME-LATER: perhaps in enforcement section, but maybe here, note about

% ``slow down'' on source downloads being a compliance problem.

Furthermore, under GPLv3~\S6(d), distributors may charge for the conveyed

object code; however, those who pay to obtain the object code must be given

equivalent and gratis access to obtain the CCS.  (If distributors convey the

object code gratis, distributors must likewise make CCS available without

charge.)  Those who do not obtain the object code from that distributors

(perhaps because they choose not to pay the fee for object code) are outside

the scope of the provision; distributors are under no specific obligation to

give CCS to someone who has not purchased an object code download under

GPLv3~\S6(d).  (Note: this does not change nor impact any obligations under

GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)

\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}

GPLv3~\S6(e) allows provision of CCS via another server when the binary or

other non-source form is distributed by peer-to-peer protocols such as

BitTorrent.  Here the requirement is only that each peer be effectively

informed of the location of the source code on a server as above.

GPLv3 really did require this addition, even though it adds  complexity to

a key section of GPL\@.  In particular,

Decentralized peer-to-peer file sharing present a challenge

to the unidirectional view of distribution that is implicit in GPLv2 and

initial drafts of GPLv3.  Identification of an upstream/downstream link in

BitTorrent distribution is neither straightforward nor reasonable; such

distribution is multidirectional, cooperative and (somewhat) anonymous.  In peer-to-peer

distribution systems, participants act both as transmitters and recipients of

blocks of a particular file, but they perceive the experience merely as users

and receivers, and not as distributors in any conventional sense.  At any

given moment of time, most peers will not have the complete file.

Meanwhile, GPLv3~\S6(d) permits distribution of a work in object code form

over a network, provided that the distributor offers equivalent access to

copy the Corresponding Source Code ``in the same way through the same

place''.  This wording might be interpreted to permit peer-to-peer

distribution of binaries \textit{if} they are packaged together with the CCS,

but such packaging is impractical, for at least three reasons.  First, even if

the CCS is packaged with the object code, it will only be available to a

non-seeding peer at the end of the distribution process, but the peer will

already have been providing parts of the binary to others in the network.

Second, in practice, peer-to-peer forms of transmission are poorly suited

means for distributing CCS.  In large distributions, packaging CCS with the

object code may result in a substantial increase in file size and

transmission time.  Third, in current practice, CCS packages themselves tend

\textit{not} to be transmitted through BitTorrent --- owing to reduced demand

-- thus, there generally will be too few participants downloading the same

source package at the same time to enable effective seeding and distribution.

GPLv3~\S6(e) addresses these issues.  If a licensee conveys such a work of

object code using peer-to-peer transmission, that licensee is in compliance

with GPLv3~\S6 if the licensee informs other peers where the object code and

its CCS are publicly available at no charge under subsection GPLv3~\S6(d).

The CCS therefore need not be provided through the peer-to-peer system that

was used for providing the binary.

Second, GPLv3\S9 also clarifies that ancillary propagation of a covered work

that occurs as part of the process of peer-to-peer file transmission does not

require acceptance, just as mere receipt and execution of the Program does

not require acceptance.  Such ancillary propagation is permitted without

limitation or further obligation.

% FIXME-LATER: Would be nice to explain much more about interactions between

% the various options of GPLv3~\S6(a-e), which might all be in play at once!

\subsection{User Products, Installation Information and Device Lock-Down}

As discussed in \S~\ref{GPLv3-drm} of this tutorial, GPLv3 seeks to thwart

technical measures such as signature checks in hardware to prevent

modification of GPL'd software on a device.

To address this issue, GPLv3~\S6 requires that parties distributing object

code provide recipients with the source code through certain means.  When

those distributors pass on the CCS, they are also required to pass on any

information or data necessary to install modified software on the particular

device that included it.  (This strategy is not unlike that used in LGPLv2.1

to enable users to link proprietary programs to modified libraries.)

% FIXME-LATER: LGPLv2.1 section should talk about this explicitly and this

%              should be a forward reference here

\subsubsection{User Products}

\label{user-product}

The scope of these requirements is narrow.  GPLv3~\S6 introduces the concept

of a ``User Product'', which includes devices that are sold for personal,

family, or household use.  Distributors are only required to provide

Installation Information when they convey object code in a User Product.

In brief, the right to convey object code in a defined class of ``User

Products,'' under certain circumstances, depends on providing whatever information

is required to enable a recipient to replace the object code with a functioning

modified version.

This was a compromise that was difficult for the FSF to agree to during the

GPLv3 drafting process.  However, companies and governments that use

specialized or enterprise-level computer facilities reported that they

actually \textit{want} their systems not to be under their own control.

Rather than agreeing to this as a concession, or bowing to pressure, they ask

for this as a \textit{preference}.  It is not clear that the GPL should interfere

here, since the main problem lies elsewhere.

While imposing technical barriers to modification is wrong regardless of

circumstances, the areas where restricted devices are of the greatest

practical concern today fall within the User Product definition.  Most, if

not all, technically-restricted devices running GPL-covered programs are

consumer electronics devices.  Moreover, the disparity in clout between the

manufacturers and these users makes it difficult for the users to reject

technical restrictions through their weak and unorganized market power.  Even

limited to User Products, this provision addresses the fundamental problem.

% FIXME-LATER: link \href to USC 2301

The core of the User Product definition is a subdefinition of ``consumer

product'' adapted from the Magnuson-Moss Warranty Act, a federal

consumer protection law in the USA found in 15~USC~\S2301: ``any tangible

personal property which is normally used for personal, family, or household

purposes.''  The USA has had three decades of experience of liberal

judicial and administrative interpretation of this definition in a manner

favorable to consumer rights.\footnote{The Magnuson-Moss consumer product

  definition itself has been influential in the USA and Canada, having been

  adopted in several state and provincial consumer protection laws.}

Ideally, this body of interpretation\footnote{The FSF, however, was very

  clear that incorporation of such legal interpretation was in no way

  intended to work as a general choice of USA law for GPLv3.} will guide

interpretation of the consumer product subdefinition in GPLv3~\S6, and this

will hopefully provide a degree of legal certainty advantageous to device

manufacturers and downstream licensees alike.

One well-established interpretive principle under Magnuson-Moss is that

ambiguities are resolved in favor of coverage.  That is, in cases where

it is not clear whether a product falls under the definition of consumer

product, the product will be treated as a consumer product.\footnote{16

CFR~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54

UCC~Rep.~Serv.2d 934 (D.~Ore.~2004).}  Moreover, for a given product,

``normally used'' is understood to refer to the typical use of that type

of product, rather than a particular use by a particular buyer.

Products that are commonly used for personal as well as commercial

purposes are consumer products, even if the person invoking rights is a

commercial entity intending to use the product for commercial

purposes.\footnote{16 CFR \S \ 700.1(a).  Numerous court decisions

interpreting Magnuson-Moss are in accord; see, e.g., \textit{Stroebner

Motors, Inc.~v.~Automobili Lamborghini S.p.A.}, 459 F.~Supp.2d 1028,

1033 (D.~Hawaii 2006).}  Even a small amount of ``normal'' personal use

is enough to cause an entire product line to be treated as a consumer

product under Magnuson-Moss.\footnote{\textit{Tandy Corp.~v.~Marymac

Industries, Inc.}, 213 U.S.P.Q.~702 (S.D.~Tex.~1981). In this case, the

court concluded that TRS-80 microcomputers were consumer products, where

such computers were designed and advertised for a variety of users,

including small businesses and schools, and had only recently been

promoted for use in the home.}

However, Magnuson-Moss is not a perfect fit because in the area of components

of dwellings, the settled interpretation under Magnuson-Moss is under-inclusive.

Depending on how such components are manufactured or sold, they may or may

not be considered Magnuson-Moss consumer products.\footnote{Building

  materials that are purchased directly by a consumer from a retailer, for

  improving or modifying an existing dwelling, are consumer products under

  Magnuson-Moss, but building materials that are integral component parts of

  the structure of a dwelling at the time that the consumer buys the dwelling

  are not consumer products. 16 C.F.R.~\S\S~700.1(c)--(f); Federal Trade

  Commission, Final Action Concerning Review of Interpretations of

  Magnuson-Moss Warranty Act, 64 Fed.~Reg.~19,700 (April 22, 1999); see also,

  e.g., \textit{McFadden}, 54 U.C.C.~Rep.~Serv.2d at 934.}  Therefore, GPLv3

defines User Products as a superset of consumer products that also includes

``anything designed or sold for incorporation into a dwelling.''

Thus, the three sentences in the center of GPLv3's User Product definition

encapsulate the judicial and administrative principles established over the

past three decades in the USA concerning the Magnuson-Moss consumer product

definition.  First, it states that doubtful cases are resolved in favor of

coverage under the definition.  Second, it indicates that the words ``normally

used'' in the consumer product definition refer to a typical or common use of

a class of product, and not the status of a particular user or expected or

actual uses by a particular user.  Third, it clearly states that the

existence of substantial non-consumer uses of a product does not negate a

determination that it is a consumer product, unless such non-consumer uses

represent the only significant mode of use of that product.

It should be clear from these added sentences that it is the general mode of

use of a product that determines objectively whether or not it is a consumer

product.  One could not escape the effects of the User Products provisions by

labeling what is demonstrably a consumer product in ways that suggest it is

``for professionals'', for example.

\subsubsection{Installation Information}

\label{GPLv3-installation-information}

With the User Products definition complete, the ``Installation Information''

definition uses that to define what those receiving object code inside a User

Product must receive.

Installation Information is information that is ``required to install and

execute modified versions of a covered work \dots from a modified version of

its'' CCS, in the same User Product for which the covered work is conveyed.

GPLv3 provides guidance concerning how much information must be provided: it

``must suffice to ensure that the continued functioning of the modified

object code is in no case prevented or interfered with solely because

modification has been made.''  For example, the information provided would be

insufficient if it enabled a modified version to run only in a disabled

fashion, solely because of the fact of modification (regardless of the actual

nature of the modification).  The information need not consist of

cryptographic keys; Installation Information may be ``any methods,

procedures, authorization keys, or other information''.

Note that GPLv3 does not define ``continued functioning'' further.  However,

GPLv3 does provide some additional guidance concerning the scope of

GPLv3-compliant action or inaction that distributors of

technically-restricted User Products can take with respect to a downstream

recipient who replaces the conveyed object code with a modified version.

First of all, GPLv3 makes clear that GPLv3 implies no obligation ``to

continue to provide support service, warranty, or updates'' for such a work.

Second, most technically-restricted User Products are designed to communicate

across networks.  It is important for both users and network providers to

know when denial of network access to devices running modified versions

becomes a GPL violation.  GPLv3 permits denial of access in two cases: ``when

the modification itself materially and adversely affects the operation of the

network,'' and when the modification itself ``violates the rules and

protocols for communication across the network''.  The second case is

deliberately drawn in general terms, and it serves as a foundation for

reasonable enforcement policies that respect recipients' right to modify

while recognizing the legitimate interests of network providers.

Note that GPLv3 permits the practice of conveying object code in a mode not

practically susceptible to modification by any party, such as code burned in

ROM or embedded in silicon.  The goal of the Installation Information

requirement is to ensure the downstream licensee receives the real right to

modify when the device manufacturer or some other party retains that right.

Accordingly, GPLv3\S6's ante-penultimate paragraph states that the

requirement to provide Installation Information ``does not apply if neither

you nor any third party retains the ability to install modified object code

on the User Product''.

Finally, GPLv3\S6 makes it clear that there is also no requirement to

provide warranty or support for the User Product itself.

\subsection{GPLv3~\S7: Additional Permissions}

\label{GPLv3s7}

The GPL is a statement of permissions, some of which have conditions.

Additional terms --- terms that supplement those of the GPL --- may come to be

placed on, or removed from, GPL-covered code in certain common ways.

Copyleft licensing theorists have generally called

 those added terms ``additional permissions'' if they grant

exceptions from the conditions of the GPL, and ``additional requirements'' if

they add conditions to the basic permissions of the GPL\@. The treatment of

additional permissions and additional requirements under GPLv3 is necessarily

asymmetrical, because they do not raise the same interpretive

issues; in particular, additional requirements, if allowed without careful

limitation, could transform a GPL'd program into a non-free one.

Due to the latter fear, historically,  GPLv2 did not permit any additional

requirements.  However, over time,

many copyright holders generally tolerated certain types of benign additional requirements

merely through a ``failure to enforce'' estoppel-esque scenario.  Therefore, GPLv3 allows

for some specific limited requirement variations that GPLv2 technically prohibits.

With these principles in the background, GPLv3~\S7  answers the following

questions:

\begin{enumerate}

\item How does the presence of additional terms on all or part of a GPL'd program

affect users' rights?

\item When and how may a licensee add terms to code being

distributed under the GPL?

\item When may a licensee remove additional terms?

\end{enumerate}

Additional permissions present the easier case.  Since the mid-1990s,

permissive exceptions often appeared alongside GPLv2 to allow combination

with certain non-free code.  Typically, downstream

stream recipients could remove those exceptions and operate under pure GPLv2.

Similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,

and it permits relicensing under the GPL\@.

These practices are now generalized via GPLv3~\S7.

A licensee may remove any additional permission from

a covered work, whether it was placed by the original author or by an

upstream distributor.  A licensee may also add any kind of additional

permission to any part of a work for which the licensee has, or can give,

appropriate copyright permission. For example, if the licensee has written

that part, the licensee is the copyright holder for that part and can

therefore give additional permissions that are applicable to it.

Alternatively, the part may have been written by someone else and licensed,

with the additional permissions, to that licensee.  Any additional

permissions on that part are, in turn, removable by downstream recipients.

As GPLv3~\S7\P1 explains, the effect of an additional permission depends on

whether the permission applies to the whole work or a part.

% FIXME-LATER: LGPLv3 will have its own section

Indeed, LGPLv3 is itself simply  a list of additional permissions supplementing the

terms of GPLv3.  GPLv3\S7 has thus provided the basis for recasting a

formally complex license as an elegant set of added terms, without changing

any of the fundamental features of the existing LGPL\@.  LGPLv3 is thus  a model for developers wishing to license their works under the

GPL with permissive exceptions.  The removability of additional permissions

under GPLv3\S7 does not alter any existing behavior of the LGPL since the LGPL

has always allowed relicensing under the ordinary GPL\@.

\section{GPLv3~\S7: Understanding License Compatibility}

\label{license-compatibility}

A challenge that faced the Free Software community heavily through out the

early 2000s was the proliferation of incompatible Free Software licenses.  Of

course, the GPL cannot possibly be compatible with all such licenses.