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 of GPLv2 while the most experience with GPLv3 that's possible

is by default 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 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 statue.  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''}

One of lawyers' most common complaints about GPLv2 is that defined terms in

the document appear throughout.  Most licenses define terms up-front.

However, 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}

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

ironically, the 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\footnote{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.}.  Admittedly, 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.

The goal and intention of GPLv2 was always to cover all rights governed by

relevant copyright law, in the USA and elsewhere.  GPLv3 therefore takes the

task of internationalizing the license further by removing references to

derivative works and by providing a more globally useful definition.  The new

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

\section{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.

\section{Propagate}

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

work is GPL'd, the copyright law of some particular country will govern

certain legal issues arising under the license.  A term like ``distribute''

(or its equivalent in languages other than English) is used in several

national copyright statutes.  Yet, 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 GPL 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 GPL\@.

\section{Convey}

Further to this point, a subset of propagate --- ``convey'' --- is defined.

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.  

\section{Appropriate Legal Notices}

GPLv2 used the term ``appropriate copyright notice and disclaimer of

warranty'' in two places, which is a rather bulk 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.

\section{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}

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}

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 with 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 example also clarifies 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,

making it abundantly clear with an extra example.

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}

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

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

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

includes) are designed as part

to permit certain distribution arrangements that are considered reasonable by

copyleft advocates.  The system library exception is designed to allow

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

software freedom more than it would hurt proprietary software.

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

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

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

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

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

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

of copylefted programs compiled for Windows.

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

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

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

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

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

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

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

for this exception.

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

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

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

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

greater than all the others.

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

violators frequently look to the system library exception as a potential

software freedom circumvention technique.  When considering whether or not a

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

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

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

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

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

\section{GPLv3~\S2: Basic Permissions}

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

full freedoms of the GPL that they deserve.

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

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

Furthermore, 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'' 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 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 clarifies and revises GPLv2~\S3.  It requires distributors of GPL'd

object code to provide access to the corresponding source code, in one of

four specified ways.  As noted in \S~\ref{GPLv3s0}, ``object code'' in GPLv3

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

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

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 possesses the object code'' it can exercised

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

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

Certain decentralized forms of peer-to-peer file sharing present a challenge

to the unidirectional view of distribution that is implicit in GPLv2 and

Draft 1 of GPLv3.  Identification of an upstream/downstream link in

BitTorrent distribution is neither straightforward nor reasonable; such

distribution is multidirectional, cooperative and 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 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 this 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 thwart

technical measures such as signature checks in hardware to prevent

modification of GPLed 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 are 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, 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 \texit{preference}.  It is not clear that 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 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 underinclusive.

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

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}

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.

With these principles in the background, GPLv3~\S7  answers the following

questions: 

\begin{enumerate}

\item How do 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 with permissive

exceptions 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\@.  

\sectin

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,