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.

\section{Understanding License Compatibility}

\label{license-compatibility}

% FIXME: more about license compatibility here.

A challenge that faced the Free Software community heavily through out the

early 2000s was the proliferation of incompatible Free Software licenses.  Of

course, we cannot make the GPL compatible with all such licenses. GPLv3

contains provisions that are designed to reduce license incompatibility by

making it easier for developers to combine code carrying non-GPL terms with

GPL'd code.

% FIXME: connecting text

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}

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.

whether the permission applies to the whole work or a part.

formally complex license as an elegant set of added terms, without changing

GPL with permissive exceptions.  The removability of additional permissions

\subsection{Additional Requirements and License Compatibility}

We broadened the title of section 7 because license compatibility, as it is

conventionally understood, is only one of several facets of the placement of

additional terms on GPL'd code.  The license compatibility issue arises for

three reasons.  First, the GPL is a strong copyleft license, requiring

modified versions to be distributed under the GPL.  Second, the GPL states

that no further restrictions may be placed on the rights of recipients.

Third, all other free software licenses in common use contain certain

requirements, many of which are not conditions made by the GPL.  Thus, when

GPL'd code is modified by combination with code covered by another formal

license that specifies other requirements, and that modified code is then

distributed to others, the freedom of recipients may be burdened by

additional requirements in violation of the GPL.  It can be seen that

additional permissions in other licenses do not raise any problems of license

compatibility.

% FIXME: minor rewrites needed

Section 7 relaxes the prohibition on further restrictions slightly by

enumerating, in subsection 7b, a limited list of categories of additional

requirements that may be placed on code without violating GPLv3.  The list

includes the items that were listed in Draft 1, though rewritten for clarity.

It also includes a new catchall category for terms that might not obviously

fall within one of the other categories but which are precisely equivalent to

GPLv3 conditions, or which deny permission for activities clearly not

permitted by GPLv3.  We have carefully considered but rejected proposals to

expand this list further.  We have also rejected suggestions, made by some

discussion committee members, that the Affero clause requirement (7d in Draft

1 and 7b4 in Draft 2) be removed, though we have revised it in response to

certain comments.  We are unwavering in our view that the Affero requirement

is a legitimate one, and we are committed to achieving compatibility of the

Affero GPL with GPLv3.

% FIXME: minor rewrites needed

A GPL licensee may place an additional requirement on code for which the

licensee has or can give appropriate copyright permission, but only if that

requirement falls within the list given in subsection 7b.  Placement of any

other kind of additional requirement continues to be a violation of the

license.  Additional requirements that are in the 7b list may not be removed,

but if a user receives GPL'd code that purports to include an additional

requirement not in the 7b list, the user may remove that requirement.  Here

we were particularly concerned to address the problem of program authors who

purport to license their works in a misleading and possibly

self-contradictory fashion, using the GPL together with unacceptable added

restrictions that would make those works non-free software.

\section{GPLv3~\S7: Explicit Compatibility}

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

In GPLv3 we take a new approach to the issue of combining GPL'd code with

code governed by the terms of other free software licenses. Our view, though

it was not explicitly stated in GPLv2 itself, was that GPLv2 allowed such

combinations only if the non-GPL licensing terms permitted distribution under

the GPL and imposed no restrictions on the code that were not also imposed by

the GPL. In practice, we supplemented this policy with a structure of

exceptions for certain kinds of combinations.

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

Section 7 of GPLv3 implements a more explicit policy on license

compatibility. It formalizes the circumstances under which a licensee may

release a covered work that includes an added part carrying non-GPL terms. We

distinguish between terms that provide additional permissions, and terms that

place additional requirements on the code, relative to the permissions and

requirements established by applying the GPL to the code.

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

Section 7 first explicitly allows added parts covered by terms with

additional permissions to be combined with GPL'd code. This codifies our

existing practice of regarding such licensing terms as compatible with the

GPL. A downstream user of a combined GPL'd work who modifies such an added

part may remove the additional permissions, in which case the broader

permissions no longer apply to the modified version, and only the terms of

the GPL apply to it.

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

In its treatment of terms that impose additional requirements, section 7

extends the range of licensing terms with which the GPL is compatible. An

added part carrying additional requirements may be combined with GPL'd code,

but only if those requirements belong to an set enumerated in section 7. We

must, of course, place some limit on the kinds of additional requirements

that we will accept, to ensure that enhanced license compatibility does not

defeat the broader freedoms advanced by the GPL. Unlike terms that grant

additional permissions, terms that impose additional requirements cannot be

removed by a downstream user of the combined GPL'd work, because no such user

would have the right to do so.

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

Under subsections 7a and 7b, the requirements may include preservation of

copyright notices, information about the origins of the code or alterations

of the code, and different warranty disclaimers. Under subsection 7c, the

requirements may include limitations on the use of names of contributors and

on the use of trademarks for publicity purposes. In general, we permit these

requirements in added terms because many free software licenses include them

and we consider them to be unobjectionable. Because we support trademark fair

use, the limitations on the use of trademarks may seek to enforce only what

is required by trademark law, and may not prohibit what would constitute fair

use.

% FIXME: 7d-f

% FIXME:  removing additional restrictions

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

Section 7 requires a downstream user of a covered work to preserve the

non-GPL terms covering the added parts just as they must preserve the GPL, as

long as any substantial portion of those parts is present in the user's

version.

% FIXME: minor rewrites needed

Section 7 points out that GPLv3 itself makes no assertion that an additional

requirement is enforceable by the copyright holder.  However, section 7 makes

clear that enforcement of such requirements is expected to be by the

termination procedure given in section 8 of GPLv3.

% FIXME: better context, etc.

Some have questioned whether section 7 is needed, and some have suggested

that it creates complexity that did not previously exist.  We point out to

those readers that there is already GPLv2-licensed code that carries

additional terms.  One of the objectives of section 7 is to rationalize

existing practices of program authors and modifiers by setting clear

guidelines regarding the removal and addition of such terms.  With its

carefully limited list of allowed additional requirements, section 7

accomplishes additional objectives, permitting the expansion of the base of

code available for GPL developers, while also encouraging useful

experimentation with requirements we do not include in the GPL itself.

\section{GPLv3~\S8: A Lighter Termination}

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

GPLv2 provided for automatic termination of the rights of a person who

copied, modified, sublicensed, or distributed a work in violation of the

license.  Automatic termination can be too harsh for those who have committed

an inadvertent violation, particularly in cases involving distribution of

large collections of software having numerous copyright holders.  A violator

who resumes compliance with GPLv2 would need to obtain forgiveness from all

copyright holders, but even to contact them all might be impossible.

% FIXME: needs to be updated to describe more complex termination

Section 8 of GPLv3 replaces automatic termination with a non-automatic

termination process.  Any copyright holder for the licensed work may opt to

terminate the rights of a violator of the license, provided that the

copyright holder has first given notice of the violation within 60 days of

its most recent occurrence. A violator who has been given notice may make

efforts to enter into compliance and may request that the copyright holder

agree not exercise the right of termination; the copyright holder may choose

to grant or refuse this request.

% FIXME: needs to be updated to describe more complex termination

If a licensee who is in violation of GPLv3 acts to correct the violation and

enter into compliance, and the licensee receives no notice of the past

violation within 60 days, then the licensee need not worry about termination

of rights under the license.

In Draft 3 the termination provision of section 8 has been revised to

indicate that, if a licensee violates the GPL, a contributor may terminate

any patent licenses that it granted under the first paragraph of section 11

to that licensee, in addition to any copyright permissions the contributor

granted to the licensee.  Therefore, a contributor may terminate the patent

licenses it granted to a downstream licensee who brings patent infringement

litigation in violation of section 10.

We have made two substantive changes to section 8.  First, we have clarified

that patent rights granted under the GPL are among the rights that a

copyright holder may terminate under section 8.  Therefore, a contributor who

grants a patent license under the first paragraph of section 11 may terminate

that patent license, just as that contributor may terminate copyright rights,

to a downstream recipient who has violated the license.  We think that this

is a reasonable result, and was already implicit in the wording of the

termination provision in our earlier drafts.  Moreover, this clarification

should encourage patent holders to make contributions to GPL-covered

programs.

Second, we have modified the termination procedure by providing a limited

opportunity to cure license violations, an improvement that was requested by

many different members of our community.  If a licensee has committed a

first-time violation of the GPL with respect to a given copyright holder, but

the licensee cures the violation within 30 days following receipt of notice

of the violation, then any of the licensee's GPL rights that have been

terminated by the copyright holder are ``automatically reinstated.''  The