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

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

% FIXME: phrase ``unmodified Program'' appears due to User Products exception

We have included the first sentence of section 2 to further internationalize

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

United States, such a provision is unnecessary but permissible.

The first paragraph of section 2 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.

% FIXME: propagate and convey

Section 2 distinguishes between activities of a licensee that are permitted

without limitation and activities that trigger additional requirements. The

second paragraph of section 2 guarantees the basic freedoms of privately

modifying and running the program. However, the right to privately modify and

run the program is terminated if the licensee brings a patent infringement

lawsuit against anyone for activities relating to a work based on the

program.

% FIXME:  transition, and some word smith

The explicit prohibition of sublicensing ensures that enforcement of the GPL

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.

% FIXME: new section here, just to talk DRM before the other section.

GPLv3 introduces 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 --- often described by such

Orwellian phrases 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

--- 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 prison, where everything not

specifically permitted is utterly forbidden, and indeed, if the full extent

of their ambition is realized, would be technically impossible.  This system

of ``para-copyright'' has been created since the adoption of GPLv2, through

legislation in the United States, the European Union, and elsewhere that

makes it a serious civil or even criminal offense to escape from these

restrictions, even where the purpose in doing so is to restore the users'

legal rights that the technology wrongfully prevents them from exercising.

% FIXME: Remove FSF specific parts

As a digital rights organization, we would not be following our mission if we

did not oppose these injustices.  But the reason our license must respond to

these practices at all is the result of a remarkable irony. Those who wish to

impose DRM on the public would like to do so by using software covered by the

GPL, a license that is intended to preserve the very freedom that they seek

to crush.  They are not satisfied merely with publishing programs having

limited capability, which free software permits. They seek to go further, to

prevent the user from removing those limits, turning Freedom 1, the freedom

to modify, into a sham.

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.  But GPLv3 must address these issues: free software is ever more

widely embedded in devices that impose technical limitations on the user's

freedom to change it.

These unjust measures must not be confused 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.  These technologies present

no obstacles to the freedom of free software. The user is presented with

choices, and figuratively as well as literally retains all the keys to the

digital home.

By contrast, technical restrictions that allow other parties to control the

user have no legitimate social purpose.  In existing applications where the

user is not afforded the same degree of real power to modify the free

software in his system that vendors or distributors have retained, or have

conveyed to third parties, the software has been delivered in a fashion that

violates the spirit of the GPL, regardless of whether it complies with the

letter of the license. The freedoms the GPL grants have actually been

withdrawn by technical means.  It may even be a crime for the user to modify

that free software to escape from those restrictions and regain control over

what is still, at least nominally, his own system.

% FIXME: reference \S6 and \S3 stuff.

We believe that these provisions, taken together, are a minimalist set of

terms sufficient to protect the free software community against the threat of

invasive para-copyright.

Large enterprise users of free software often contract with non-employee

developers, often 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.

The practices seem basically harmless, so we have decided to make it

clear they are permitted.

GPLv3 now 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 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.

This permission is stated in section 2.  It permits a user to convey

covered works to contractors operating exclusively on the user's behalf,

under the user's direction and control, and to require the contractors

to keep the user's copyrighted changes confidential, but only if the

contractor is limited to acting on the user's behalf, just as the user's

employees would have to act.

The strict conditions in this provision are needed so that it cannot be

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

users or customers.  By making the limits on this provision very narrow,

we ensure that in all other cases the contractor gets the full freedoms

of the GPL.

\section{GPLv3~\S3: What Hath DMCA Wrought}

\label{GPLv3s3}

% FIXME: reference the section in DMCA about this, maybe already there in

%        GPLv2 section?

% FIXME: Wrong paragraph now.

What was the second paragraph of section 3 in Draft 2, concerning so-called

anticircumvention law, has been broken up into two paragraphs.  In the first

paragraph we have replaced the reference to the Digital Millennium Copyright

Act, a United States statute, with a corresponding international legal

reference to anticircumvention laws enacted pursuant to the 1996 WIPO treaty

and any similar laws.  Lawyers outside the United States have worried that a

United States statutory reference could be read as indicating a choice for

application of United States law to the license as a whole, which of course

was not our intention.  Further research has caused us to doubt the view that

only one or the other paragraph of section 3 will typically be effective in a

country that has enacted an anticircumvention law.  Moreover, we believe that

several national anticircumvention laws have been or will be structured more

similarly to the anticircumvention provisions of the Digital Millennium

Copyright Act than to the counterpart provisions of the European Union

Copyright Directive.

The second paragraph of section 3 declares that no GPL'd program is part of

an effective technological protection measure, regardless of what the program

does. Ill-advised legislation in the United States and other countries has

prohibited circumvention of such technological measures. If a covered work is

distributed as part of a system for generating or accessing certain data, the

effect of this paragraph is to prevent someone from claiming that some other

GPL'd program that accesses the same data is an illegal circumvention.

we now state more 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. We have made two changes in the disclaimer of intention

regarding limitations on the design and use of the work. First, we make clear

that the referenced ``legal rights'' are specifically rights arising under

anticircumvention law.  Second, we now refer to the conveying party's rights

in addition 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.

% FIXME: this needs rewritten 

In section 3, which has been retitled as well as redrafted, we have

specifically stated the rule, previously implicit, that modes of

distribution that establish limitations on use or modification that

are inconsistent with the terms of the license are not permitted by

the license.  In addition, we have added disclaimers, based on advice

of counsel from nations that have enacted para-copyright provisions

akin to the Digital Millennium Copyright Act in the US or pursuant to

the European Union Copyright Directive.  We believe these disclaimers

by each licensor of any intention to use GPL'd software to stringently

control access to other copyrighted works should practically prevent

any private or public parties from invoking DMCA-like laws against

users who escape technical restriction measures implemented by GPL'd

software.

This section shields users from being subjected to liability under

% 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

\section{GPLv3~\S7(e): Peer-to-Peer Sharing Networks}

% FIXME: rewrite a bit, maybe drop reference to bitorrent?

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.  It is neither straightforward nor reasonable to identify

an upstream/downstream link in BitTorrent distribution; such distribution is

multidirectional, cooperative and anonymous.  In systems like BitTorrent,

participants act both as transmitters and recipients of blocks of a

particular file, but they see themselves 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.

% FIXME: rewrite a bit.

The GPL 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 BitTorrent distribution of binaries if

they are packaged together with the source code, but this impractical, for at

least two reasons. First, even if the source code is packaged with the

binary, 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, functioning rather like a router or a

cache proxy.  Second, in practice BitTorrent and similar peer-to-peer forms

of transmission have been less suitable means for distributing source code.

In large distributions, packaging source code with the binary may result in a

substantial increase in file size and transmission time.  Source code

packages themselves tend not to be transmitted through BitTorrent owing to

reduced demand. There generally will be too few participants downloading the

same source package at the same time to enable effective seeding and

distribution.

% FIXME: rewrite a bit.

We have made two changes that recognize and facilitate distribution of

covered works in object code form using BitTorrent or similar peer-to-peer

methods.  First, under new subsection 6e, if a licensee conveys such a work

using peer-to-peer transmission, that licensee is in compliance with section

6 so long as the licensee knows, and informs other peers where, the object

code and its Corresponding Source are publicly available at no charge under

subsection 6d.  The Corresponding Source therefore need not be provided

through the peer-to-peer system that was used for providing the binary.

Second, we have revised section 9 to make clear 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:  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

addition of the cure opportunity achieves a better balance than our earlier

section 8 drafts between facilitating enforcement of the license and

protecting inadvertent violators against unfair results.

We have restructured the form of section 8 by replacing non-automatic

termination with automatic termination coupled with opportunities for

provisional and permanent reinstatement of rights.  The revised wording does

not alter the underlying policy or details of procedure established in the

previous drafts, including the 60-day period of repose and 30-day cure

opportunity for first-time violators.  The restoration of automatic

termination was motivated in part to facilitate enforcement in European

countries.  We also believe the revised wording will be easier to understand

and apply in all jurisdictions.

\section{GPLv3~\S9: Acceptance}

% FIXME: needs some work here

Section 9 means what it says: mere receipt or execution of code neither

requires nor signifies contractual acceptance under the GPL.  Speaking more

broadly, we have 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: needs filled out and more here.

Draft1 removed the words ``at no charge'' from what is now subsection 5b, the

core copyleft provision, for reasons related to our current changes to the

second paragraph of section 4: it had contributed to a misconception that the

GPL did not permit charging for distribution of copies.  The purpose of the

``at no charge'' wording was to prevent attempts to collect royalties from

third parties.  The removal of these words created the danger that the

imposition of licensing fees would no longer be seen as a license

violation.

We therefore have added a new explicit prohibition on imposition of licensing

fees or royalties in section 10.  This section is an appropriate place for

such a clause, since it is a specific consequence of the general requirement

that no further restrictions be imposed on downstream recipients of

GPL-covered code.

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}

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