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,

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.

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

This 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 software freedom respecting 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.

GPLv3  took a new approach to the issue of combining GPL'd code with

code governed by the terms of other software freedom licenses.  Traditional

GPLv2 license compatibility theory (which was not explicitly stated in GPLv2

itself, but treated as a license interpretation matter by the FSF) held 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, the FSF historically supplemented that policy with a structure of

exceptions for certain kinds of combinations.

GPLv3~\S7  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. 

GPLv3~\S7 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.

As discussed in the previous section of this tutorial, GPLv3~\S7 first and foremost explicitly allows added parts covered by terms with

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

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.

In its treatment of terms that impose additional requirements, GPLv3\S7

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 GPLv3\S7. There

are, of course,  limits on the acceptable additional requirements, which to

ensures that enhanced license compatibility does not

defeat the broader software-freedom-defending terms of 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 only in the

pathological case\footnote{Theoretically, a user could collect copyright

  assignment from all known contributors and then do this, but this would

  indeed be the pathological case.}  would a user have the right to do so.

% FIXME-LATER: It would be good to have detailed info on each of 7a-f.

%              Here's some commented-out text that might be useful for 7a-b

%% 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-LATER:  Say removing additional restrictions

% FIXME-LATER: This text may be useful later:

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

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 technically needs to obtain forgiveness

from all copyright holders, and even contacting them all might be impossible.

GPLv3~\S8 replaces now grants opportunities for provisional and permanent

reinstatement of rights. The termination procedure provides a limited

opportunity to cure license violations.  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''.

Finally, if a licensee violates the GPL, a contributor may terminate any

patent licenses that it granted under GPLv3~\S11, in addition to any

copyright permissions the contributor granted to the licensee.

% FIXME-LATER: write more here, perhaps linking up to enforcement

\section{GPLv3~\S9: Acceptance}

GPLv3~\S9 means what it says: mere receipt or execution of code neither

requires nor signifies contractual acceptance under the GPL.  Speaking more

broadly, GPLv3 is intentionally structured our license as a unilateral grant

of copyright permissions, the basic operation of which exists outside of any

law of contract.  Whether and when a contractual relationship is formed

between licensor and licensee under local law do not necessarily matter to

the working of the license.

\section{GPLv3~\S10: Explicit Downstream License}

% FIXME-LATER: link up this paragraph to above sections.

Careful readers of the GPL have suggested that its explicit prohibition

against imposition of further restrictions\footnote{GPLv2, section 6; Draft

  3, section 10, third paragraph.} has, or ought to have, implications for

those who assert patents against other licensees.  Draft 2 took some steps to

clarify this point in a manner not specific to patents, by describing the

imposition of ``a license fee, royalty, or other charge'' for exercising GPL

rights as one example of an impermissible further restriction.  In Draft 3 we

have clarified further that the requirement of non-imposition of further

restrictions has specific consequences for litigation accusing GPL-covered

programs of infringement.  Section 10 now states that ``you may not initiate

litigation (including a cross-claim or counterclaim in a lawsuit) alleging

that any patent claim is infringed by making, using, selling, offering for

sale, or importing the Program (or the contribution of any contributor).''

That is to say, a patent holder's licensed permissions to use a work under

GPLv3 may be terminated under section 8 if the patent holder files a lawsuit

alleging that use of the work, or of any upstream GPLv3-licensed work on

which the work is based, infringes a patent.

\section{GPLv3~\S11: Explicit Patent Licensing}

\label{GPLv3s11}

% FIXME: These don't belong here, but it's closer to where it ought to be now.

It is important to note that section 11, paragraph 3 refers to a work that is

conveyed, and section 10, paragraph 2 refers to a kind of automatic

counterpart to conveying achieved as the result of a transaction. 

The patent licensing practices that section 7 of GPLv2 (corresponding to

section 12 of GPLv3) was designed to prevent are one of several ways in which

software patents threaten to make free programs non-free and to prevent users

from exercising their rights under the GPL. GPLv3 takes a more comprehensive

approach to combatting the danger of patents.

Software patenting is a harmful and unjust policy, and should be abolished;

recent experience makes this all the more evident. Since many countries grant

patents that can apply to and prohibit software packages, in various guises

and to varying degrees, we seek to protect the users of GPL-covered programs

from those patents, while at the same time making it feasible for patent

holders to contribute to and distribute GPL-covered programs as long as they

do not attack the users of those programs.

It is generally understood that GPLv2 implies some limits on a licensee's

power to assert patent claims against the use of GPL-covered works.

Therefore, we have designed GPLv3 to reduce the patent risks that distort and

threaten the activities of users who make, run, modify and share free

software.  At the same time, we have given due consideration to practical

goals such as certainty and administrability for patent holders that

participate in distribution and development of GPL-covered software.  Our

policy requires each such patent holder to provide appropriate levels of

patent assurance to users, according to the nature of the patent holder's

relationship to the program.

Draft 3 features several significant changes concerning patents.  We have

made improvements to earlier wording, clarified when patent assertion becomes

a prohibited restriction on GPL rights, and replaced a distribution-triggered

non-assertion covenant with a contribution-based patent license grant. We

have also added provisions to block collusion by patent holders with software

distributors that would extend patent licenses in a discriminatory way.

Draft 3 introduces the terms ``contributor'' and ``contribution,'' which are

used in the third paragraph of section 10 and the first paragraph of section

11, discussed successively in the following two subsections.  Section 0

defines a contributor as ``a party who licenses under this License a work on

which the Program is based.'' That work is the ``contribution'' of that

contributor.  In other words, each received GPLv3-covered work is associated

with one or more contributors, making up the finite set of upstream GPLv3

licensors for that work. Viewed from the perspective of a recipient of the

Program, contributors include all the copyright holders for the Program,

other than copyright holders of material originally licensed under non-GPL

terms and later incorporated into a GPL-covered work.  The contributors are

therefore the initial GPLv3 licensors of the Program and all subsequent

upstream licensors who convey, under the terms of section 5, modified works

on which the Program is based.

For a contributor whose contribution is a modified work conveyed under

section 5, the contribution is ``the entire work, as a whole'' which the

contributor is required to license under GPLv3.  The contribution therefore

includes not just the material added or altered by the contributor, but also

the pre-existing material the contributor copied from the upstream version

and retained in the modified version. Our usage of ``contributor'' and

``contribution'' should not be confused with the various other ways in which

those terms are used in certain other free software licenses.\footnote{Cf.,

  e.g., Apache License, version 2.0, section 1; Eclipse Public License,

  version 1.0, section 1; Mozilla Public License, version 1.1, section 1.1.}

The term ``patent license,'' as used in the third through fifth

paragraphs of section 11, is not meant to be confined to agreements

formally identified or classified as patent licenses.  The new second

paragraph of section 11 makes this clear by defining ``patent license,''

for purposes of the subsequent three paragraphs, as ``a patent license,

a covenant not to bring suit for patent infringement, or any other

express agreement or commitment, however denominated, not to enforce a

patent.''  The definition does not include patent licenses that arise by

implication or operation of law, because the third through fifth

paragraphs of section 11 are specifically concerned with explicit

promises that purport to be legally enforceable.

Our previous drafts featured a patent license grant triggered by all

acts of distribution of GPLv3-covered works.\footnote{In Draft 2 we

rewrote the patent license as a covenant not to assert patent claims. We

explain why we reverted to the form of a patent license grant in \S\

\ref{cov}.} Many patent-holding companies objected to this policy. They

have made two objections: (1) the far-reaching impact of the patent

license grant on the patent holder is disproportionate to the act of

merely distributing code without modification or transformation, and (2)

it is unreasonable to expect an owner of vast patent assets to exercise

requisite diligence in reviewing all the GPL-covered software that it

provides to others.  Some expressed particular concern about the

consequences of ``inadvertent'' distribution.

The argument that the impact of the patent license grant would be

``disproportionate,'' that is to say unfair, is not valid. Since

software patents are weapons that no one should have, and using them for

aggression against free software developers is an egregious act,

preventing that act cannot be unfair. 

However, the second argument seems valid in a practical sense.  A

typical GNU/Linux distribution includes thousands of programs. It would

be quite difficult for a redistributor with a large patent portfolio to

review all those programs against that portfolio every time it receives

and passes on a new version of the distribution. Moreover, this question

raises a strategic issue. If the GPLv3 patent license requirements

convince patent-holding companies to remain outside the distribution

path of all GPL-covered software, then these requirements, no matter how

strong, will cover few patents. 

We concluded it would be more effective to make a partial concession

which would lead these companies to feel secure in doing the

distribution themselves, so that the conditions of section 10 would

apply to assertion of their patents.  We therefore made the stricter

section 11 patent license apply only to those distributors that have

modified the program.  The other changes we have made in sections 10 and

11 provide strengthened defenses against patent assertion and compensate

partly for this concession. 

Therefore, in Draft 3, the first paragraph of section 11 states that a

contributor's patent license covers all the essential patent claims

implemented by the whole program as that contributor distributes it.

Contributors of modified works grant a patent license to claims that

read on ``the entire work, as a whole.'' This is the work that the

copyleft clause in section 5 requires the contributor to license under

GPLv3; it includes the material the contributor has copied from the

upstream version that the contributor has modified.  The first paragraph

of section 11 does not apply to those that redistribute the program

without change.\footnote{An implied patent license from the distributor,

however, may arise by operation of law. See the final paragraph of

section 11.  Moreover, distributors are subject to the limits on patent

assertion contained in the third paragraph of section 10.} 

We hope that this decision will result in fairly frequent licensing of

patent claims by contributors.  A contributor is charged with awareness

of the fact that it has modified a work and provided it to others; no

act of contribution should be treated as inadvertent.  Our rule also

requires no more work, for a contributor, than the weaker rule proposed

by the patent holders.  Under their rule, the contributor must always

compare the entire work against its patent portfolio to determine

whether the combination of the modifications with the remainder of the

work cause it to read on any of the contributor's patent claims.

We have made three changes to the definition of ``essential patent

claims'' in section 0.  This definition now serves exclusively to

identify the set of patent claims licensed by a contributor under the

first paragraph of section 11.

First, we have clarified when essential patent claims include

sublicensable claims that have been licensed to the contributor by a

third party.\footnote{This issue is typically handled in other free

software licenses having patent licensing provisions by use of the

unhelpful term ``licensable,'' which is either left undefined or is

given an ambiguous definition.}  Most commercial patent license

agreements that permit sublicensing do so under restrictive terms that

are inconsistent with the requirements of the GPL.  For example, some

patent licenses allow the patent licensee to sublicense but require

collection of royalties from any sublicensees.  The patent licensee

could not distribute a GPL-covered program and grant the recipient a

patent sublicense for the program without violating section 12 of

GPLv3.\footnote{Draft 3 provides a new example in section 12 that makes

this point clear.}  In rare cases, however, a conveying party can freely

grant patent sublicenses to downstream recipients without violating the

GPL.

Draft 3 now defines essential patent claims, for a given party, as a

subset of the claims ``owned or controlled'' by the party.  The

definition states that ``control includes the right to grant sublicenses

in a manner consistent with the requirements of this License.''

Therefore, in the case of a patent license that requires collection of

royalties from sublicensees, essential patent claims would not include

any claims sublicensable under that patent license, because sublicenses

to those claims could not be granted consistent with section 12.

Second, we now state that essential patent claims are those ``that would

be infringed by some manner, permitted by this License, of making,

using, or selling the work.'' This modified wording is intended to make

clear that a patent claim is ``essential'' if some mode of usage would

infringe that claim, even if there are other modes of usage that would

not infringe.

Third, we have clarified that essential patent claims ``do not include

claims that would be infringed only as a consequence of further

modification of the work.''  That is to say, the set of essential patent

claims licensed under the first paragraph of section 11 is fixed by the

the particular version of the work that was contributed.  The claim set

cannot expand as a work is further modified downstream.  (If it could,

then any software patent claim would be included, since any software

patent claim can be infringed by some further modification of the

work.)\footnote{However, ``the work'' should not be understood to be

restricted to a particular mechanical affixation of, or medium for

distributing, a program, where the same program might be provided in

other forms or in other ways that may be captured by other patent claims

held by the contributor.}

The downstream shielding provision of section 11 responds particularly

to the problem of exclusive deals between patent holders and

distributors, which threaten to distort the free software distribution

system in a manner adverse to developers and users. Draft 2 added a

source code availability option to this provision, as a specific

alternative to the general requirement to shield downstream users from

patent claims licensed to the distributor. A distributor conveying a

covered work knowingly relying on a patent license may comply with the

provision by ensuring that the Corresponding Source of the work is

publicly available, free of charge.  We retained the shielding option in

Draft 2 because we did not wish to impose a general requirement to make

source code available to all, which has never been a GPL condition.

The addition of the source code availability option was supported by the

free software vendors most likely to be affected by the downstream

shielding provision.  Enterprises that primarily use and occasionally

distribute free software, however, raised concerns regarding the

continued inclusion of a broadly-worded requirement to ``shield,'' which

appears to have been mistakenly read by those parties as creating an

obligation to indemnify.  To satisfy these concerns, in Draft 3 we have

replaced the option to shield with two specific alternatives to the

source code availability option. The distributor may comply by

disclaiming the patent license it has been granted for the conveyed

work, or by arranging to extend the patent license to downstream

recipients.\footnote{The latter option, if chosen, must be done ``in a

manner consistent with the requirements of this License''; for example,

it is unavailable if extension of the patent license would result in a

violation of section 12. Cf.~the discussion of sublicensable patent

claims in \S\ \ref{epc}.}  The GPL is intended to permit private

distribution as well as public distribution, and the addition of these

options ensures that this remains the case, even though we expect that

distributors in this situation will usually choose the source code

availability option.

Without altering its underlying logic, we have modified the phrasing of

the requirement to make clear that it is activated only if the

Corresponding Source is not already otherwise publicly available.  (Most

often it will, in fact, already be available on some network server

operated by a third party.)  Even if it is not already available, the

option to ``cause the Corresponding Source to be so available'' can then

be satisfied by verifying that a third party has acted to make it

available.  That is to say, the affected distributor need not itself

host the Corresponding Source to take advantage of the source code

availability option.  This subtlety may help the distributor avoid

certain peculiar assumptions of liability.

We have made two other changes to the downstream shielding provision.

The phrase ``knowingly rely'' was left undefined in our earlier drafts;

in Draft 3 we have provided a detailed definition.  We have also deleted

the condition precedent, added in Draft 2, that the relied-upon patent

license be one that is non-sublicensable and ``not generally available

to all''; this was imprecise in Draft 2 and is unnecessary in Draft

3. In nearly all cases in which the ``knowingly relying'' test is met,

the patent license will indeed not be sublicensable or generally

available to all on free terms.  If, on the other hand, the patent

license is generally available under terms consistent with the

requirements of the GPL, the distributor is automatically in compliance,

because the patent license has already been extended to all downstream

recipients.  If the patent license is sublicensable on GPL-consistent

terms, the distributor may choose to grant sublicenses to downstream

recipients instead of causing source code to be publicly available.  In

such a case, if the distributor is also a contributor, it will already

have granted a patent sublicense by operation of the first paragraph of

section 11,\footnote{See \S\ \ref{epc}.} and so it need not do anything

further to comply with the third paragraph.

% FIXME: This probably needs editing

One major goal for GPLv3 is to provide developers with additional protection

from being sued for patent infringement.  After much feedback and cooperation

from the committees, we are now proposing a patent license which closely

resembles those found in other free software licenses.  This will be more

comfortable for everyone in the free software community to use, without

creating undue burdens for distributors.

We have also added new terms to stop distributors from colluding with third

parties to offer selective patent protection, as Microsoft and Novell have

recently done.  The GPL is designed to ensure that all users receive the

same rights; arrangements that circumvent this make a mockery of free

software, and we must do everything in our power to stop them.

Our strategy has two parts.  First, any license that protects some

recipients of GPLed software must be extended to all recipients of the

software.  Second, we prohibit anyone who made such an agreement from

distributing software released under GPLv3.  We are still considering

whether or not this ban should apply when a deal was made before these

terms were written, and we look forward to community input on this issue.

The patent license grant of the first paragraph of section 11 no longer

applies to those who merely distribute works without modification. (We

explain why we made this change in the next subsection.) Such parties are

nonetheless subject to the conditions stated in section 10.  Unlike the

patent license, which establishes a defense for downstream users lasting for

as long as they remain in compliance with the GPL, the commitment not to sue

that arises under section 10 is one that the distributor can end, so long as

the distributor also ceases to distribute.  This is because a party who

initiates patent litigation in violation of section 10 risks termination of

its licensed permissions by the copyright holders of the work.

% FIXME: just brought in words here, needs rewriting.

is rooted in the basic principles of the GPL.

Our license has always stated that distributors may not impose further

restrictions on users' exercise of GPL rights.  To make the suggested

distinction between contribution and distribution is to allow a

distributor to demand patent royalties from a direct or indirect

recipient, based on claims embodied in the distributed code. This

undeniably burdens users with an additional legal restriction on their

rights, in violation of the license.

%FIXME: possible useful text, but maybe not.

In the covenant provided in the revised section 11, the set of claims

that a party undertakes not to assert against downstream users are that

party's ``essential patent claims'' in the work conveyed by the party.

``Essential patent claims,'' a new term defined in section 0, are simply

all claims ``that would be infringed by making, using, or selling the

work.''  We have abandoned the phrase ``reasonably contemplated use.''

This change makes the obligations of distributing patent holders more

predictable.