disavowed. GPLv2~\S12, in turn, limits the liability of the actor for any

warranties that cannot legally be disclaimed in a particular jurisdiction.

Again, some have argued the GPL is unenforceable in some jurisdictions

because its limitation of liability is impermissibly broad. However, \S

12, just like its sister, GPLv2~\S11, contains a jurisdictional savings

provision, which states that it is to be interpreted only as broadly as

allowed by applicable law.  As stated above, such a provision ensures that

both GPLv2~\S12, and the entire GPL, is enforceable in any jurisdiction,

regardless of any particular law regarding the permissibility of limiting

liability.

So end the terms and conditions of the GNU General Public License.

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

\chapter{GPLv3}

\label{GPLv3}

This chapter discussed the text of GPLv3.  Much of this material herein

includes text that was adapted (with permission) from text that FSF

originally published as part of the so-called ``rationale documents'' for the

various discussion drafts of GPLv3.

The FSF ran a somewhat public process to develop GPLv3, and it was the first

attempt of its kind to develop a Free Software license this way.  Ultimately,

RMS was the primary author of GPLv3, but he listened to feedback from all

sorts of individuals and even for-profit companies.  Nevertheless, in

attempting to understand GPLv3 after the fact, the materials available from

the GPLv3 process have a somewhat ``drinking from the firehose'' effect.

This chapter seeks to explain GPLv3 to newcomers, who perhaps are familiar

with GPLv2 and who did not participate in the GPLv3 process.

Those who wish to drink from the firehose and take a diachronic approach to

GPLv3 study by reading the step-by-step public drafting process GPLv3 (which

occurred from Monday 16 January 2006 through Monday 19 November 2007) should

visit \url{http://gplv3.fsf.org/}.

\section{Understanding GPLv3 As An Upgraded GPLv2}

Ultimately, GPLv2 and GPLv3 co-exist as active licenses in regular use.  As

discussed in Chapter\~ref{tale-of-two-copylefts}, GPLv1 was never regularly

used alongside GPLv2.  However, given GPLv2's widespread popularity and

existing longevity by the time GPLv3 was published, it is not surprising that

some licensors still prefer GPLv2-only or GPLv2-or-later.  GPLv3 gained major

adoption by many projects, old and new, but many projects have not upgraded

due to (in some cases) mere laziness and (in other cases) policy preference

for some of GPLv2's terms and/or policy opposition to GPLv3's terms.

Given this ``two GPLs world'' is reality, it makes sense to consider GPLv3 in

terms of how it differs from GPLv2.  Also, most of the best GPL experts in

the world must deal regularly with both licenses, and admittedly have decades

of experience of GPLv2 while the most experience with GPLv3 that's possible

is by default less than a decade.  These two factors usually cause even new

students of GPL to start with GPLv2 and move on to GPLv3, and this tutorial

follows that pattern.

Overall, the changes made in GPLv3 admittedly \textit{increased} the

complexity of the license.  The FSF stated at the start of the GPLv3 process

that they would have liked to oblige those who have asked for a simpler and

shorter GPL\@.  Ultimately, the FSF gave priority to making GPLv3 a better

copyleft in the spirit of past GPL's.  Obsession for concision should never

trump software freedom.

The FSF had many different, important goals in seeking to upgrade to GPLv3.

However, one important goal that is often lost in the discussion of policy

minutia is a rather simple but important issue.  Namely, FSF sought to assure

that GPLv3 was more easily internationalized than GPLv2.  In particular, the

FSF sought to ease interpretation of GPL in other countries by replacement of

USA-centric\footnote{See Section~\ref{non-usa-copyright} of this tutorial for

  a brief discussion about non-USA copyright systems.}  copyright phrases and

wording with neutral terminology rooted in description of behavior rather

than specific statue.  As can be seen in the section-by-section discussion of

GPLv3 that follows, nearly every section had changes related to issues of

internationalization.

\section{GPLv3~\S0: Giving In On ``Defined Terms''}

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

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

However, GPL was always designed both as a document that should be easily

understood both by lawyers and by software developers: it is a document

designed to give freedom to software developers and users, and therefore it

should be comprehensible to that constituency.

Interestingly enough, one coauthor of this tutorial who is both a lawyer and

a developer pointed out that in law school, she understood defined terms more

quickly than other law students precisely because of her programming

background.  For developers, having \verb0#define0 (in the C programming

language) or other types of constants and/or macros that automatically expand

in the place where they are used is second nature.  As such, adding a defined

terms section was not terribly problematic for developers, and thus GPLv3

adds one.  Most of these defined terms are somewhat straightforward and bring

forward better worded definitions from GPLv2.  Herein, this tutorial

discusses a few of the new ones.

GPLv3~\S0 includes definitions of five new terms not found in any form in

GPLv2: ``modify'' ``covered work'', ``propagate'', ``convey'', and

``Appropriate Legal Notices''. 

\subsection{Modify and the Work Based on the Program}

GPLv2 included a defined term, ``work based on the Program'', but also used

the term ``modify'' and ``based on'' throughout the license.  GPLv2's ``work

based on the Program'' definition made use of a legal term of art,

``derivative work'', which is peculiar to USA copyright law.  However,

ironically, the most criticism of USA-specific legal terminology in GPLv2's

``work based on the Program'' definition historically came not primarily from

readers outside the USA, but from those within it\footnote{The FSF noted in

  that it did not generally agree with these views, and expressed puzzlement

  by the energy with which they were expressed, given the existence of many

  other, more difficult legal issues implicated by the GPL.  Nevertheless,

  the FSF argued that it made sense to eliminate usage of local copyright

  terminology to good effect.}.  Admittedly, even though differently-labeled

concepts corresponding to the derivative work are recognized in all copyright

law systems, these counterpart concepts might differ to some degree in scope

and breadth from the USA derivative work.

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

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

task of internationalizing the license further by removing references to

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

definition returns to the common elements of copyright law.  Copyright

holders of works of software have the exclusive right to form new works by

modification of the original --- a right that may be expressed in various

ways in different legal systems.  GPLv3 operates to grant this right to

successive generations of users (particularly through the copyleft conditions

set forth in GPLv3~\S5, as described later in this tutorial in its

\S~\ref{GPLv3s5}).  Here in GPLv3~\S0, ``modify'' refers to basic copyright

rights, and then this definition of ``modify'' is used to define ``modified

version of'' and ``work based on,'' as synonyms.

\section{The Covered Work}

GPLv3 uses a common license drafting technique of building upon simpler

definitions to make complex ones.  The Program is a defined term found

throughout GPLv2, and the word ``covered'' and the phrase ``covered by this

license'' are used in tandem with the Program in GPLv2, but not as part of a

definition.  GPLv3 offers a single term ``covered work'', which enables some

of the wording in GPLv3 to be simpler and clearer than its GPLv2

counterparts.

\section{Propagate}

The term ``propagate'' serves two purposes.  First, ``propagate'' provides a

simple and convenient means for distinguishing between the kinds of uses of a

work that GPL imposes conditions on and the kinds of uses that GPL does not

(for the most part) impose conditions on.

Second, ``propagate'' helps globalize GPL in its wording and effect.  When a

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

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

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

national copyright statutes.  Yet, practical experience with GPLv2 revealed

the awkwardness of using the term ``distribution'' in a license intended for

global use: the scope of ``distribution'' in the copyright context can differ

from country to country.  The GPL never necessarily intended the specific

meaning of ``distribution'' that exists under USA (or any other country's)

copyright law.

Indeed, even within a single country and language, the term distribution may

be ambiguous; as a legal term of art, distribution varies significantly in

meaning among those countries that recognize it.  For example, comments

during GPLv3's drafting process indicated that in at least one country,

distribution may not include network transfers of software but may include

interdepartmental transfers of physical copies within an organization.

Meanwhile, the copyright laws of many countries, as well as certain

international copyright treaties, recognize ``making available to the

public'' or ``communication to the public'' as one of the exclusive rights of

copyright holders.

Therefore, the GPL defines the term ``propagate'' by reference to activities

that require permission under ``applicable copyright law'', but excludes

execution and private modification from the definition.  GPLv3's definition

also gives examples of activities that may be included within ``propagation''

but it also makes clear that, under the copyright laws of a given country,

``propagation'' may include other activities as well.

Thus, propagation is defined by behavior, and not by categories drawn from

some particular national copyright statute.  This helps not only with

internationalization, but also factually-based terminology aids in

developers' and users' understanding of GPL\@.

\section{Convey}

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

Conveying includes activities that constitute propagation of copies to

others.  As with the definition of propagate, GPLv3 thus addresses transfers

of copies of software in behavioral rather than statutory terms.  

\section{Appropriate Legal Notices}

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

warranty'' in two places, which is a rather bulk term.  Also, experience with

GPLv2 and other licenses that grant software freedom showed throughout the

1990s that the scope of types of notices that need preservation upon

conveyance were more broad that merely the copyright notices.  The

Appropriate Legal Notice definition consolidates the material that GPLv2

traditionally required preserved into one definition.

\section{Other Defined Terms}

Note finally that not all defined terms in GPLv3 appear in GPLv3~\S0.

Specifically, those defined terms that are confined in use to a single

section are defined in the section in which they are used, and GPLv3~\S1

contains those definitions focused on source code.  In this tutorial, those

defined terms are discussed in the section where they are defined and/or

used.

\section{GPLv3~\S1: Understanding CCS}

Ensuring that users have the source code to the software they receive and the

freedom to modify remains the paramount right embodied in the Free Software

Definition (found in \S~\ref{Free Software Definition} of this tutorial).  As

such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it

contains all the defined terms related to this important software freedom.

\subsection{Source Code Definition}

First, GPLv3\~S1 retains GPLv2's definition of ``source code'' and adds an

explicit definition of ``object code'' as ``any non-source version of a

work''.  Object code is not restricted to a narrow technical meaning and is

understood broadly to include any form of the work other than the preferred

form for making modifications to it.  Object code therefore includes any kind

of transformed version of source code, such as bytecode or minified

Javascript.  The definition of object code also ensures that licensees cannot

escape their obligations under the GPL by resorting to shrouded source or

obfuscated programming.

\subsection{CCS Definition}

The definition of CCS\footnote{Note that the preferred term for those who

  work regularly with both GPLv2 and GPLv3 is ``Complete Corresponding

  Source'', abbreviated to ``CCS''.  Admittedly, the word ``complete'' no

  longer appears in GPLv3 (which uses the word ``all'' instead).  However,

  both GPLv2 and the early drafts of GPLv3 itself used the word ``complete'',

  and early GPLv3 drafts even called this defined term ``Complete

  Corresponding Source''.  Meanwhile, use of the acronym ``CCS'' (sometimes,

  ``C\&CS'') was so widespread among GPL enforcers that its use continues

  even though GPLv3-focused experts tend to say just the defined term of

  ``Corresponding Source''.}, or, as GPLv3 officially calls it,

``Corresponding Source'' in GPLv3~\S1\P4 is possibly the most complex

definition in the license.

The CCS definition is broad so as to protect users' exercise of their rights

under the GPL\@.  The definition includes with particular examples to remove

any doubt that they are to be considered CCS\@.  GPLv3 seeks to make it

completely clear that a licensee cannot avoid complying with the requirements

of the GPL by dynamically linking a subprogram component to the original

version of a program.  The example also clarifies that the shared libraries

and dynamically linked subprograms that are included in Corresponding Source

are those that the work is ``specifically'' designed to require, which

clarifies that they do not include libraries invoked by the work that can be

readily substituted by other existing implementations.  While copyleft

advocates never doubted this was required under GPLv2's definition of CCS,

making it abundantly clear with an extra example.

GPL, as always, seeks to ensure users are truly in a position to install and

run their modified versions of the program; the CCS definition is designed to

be expansive to ensure this software freedom.  However, although the

definition of CCS is expansive, it is not sufficient to protect users'

freedoms in many circumstances.  For example, a GPL'd program, or a modified

version of such a program, might be locked-down and restricted.  The

requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this

tutorial) handle that issue.  (Early drafts of GPLv3 included those

requirements in the definition of CCS; however, given that the lock-down

issue only comes up in distribution of object code, it is more logical to

place those requirements with the parts of GPLv3 dealing directly with object

code distribution).

The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does

not require source that can be automatically generated.  Many code

generators, preprocessors and take source code as input and sometimes even

have output that is still source code.  Source code should always be whatever

the original programmer preferred to modify.

GPLv3\S1's final paragraph removes any ambiguity about what should be done on

source-only distributions.  Specifically, the right to convey source code

that does not compile, does not work, or otherwise is experimental

in-progress work is fully permitted, \textit{provided that} no object code

form is conveyed as well.  Indeed, when combined with the permissions in

GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can

never be required to provide more than that.  One always has the right to

modify a source code work by deleting any part of it, and there can be no

requirement that free software source code be a whole functioning program.

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

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

in \S~\ref{GPLv2sS0} of this tutorial).  However, the usual style of

improvements found in GPLv3 are found here as well.  For example, the first

sentence of GPLv3~\S2 furthers the goal internationalization.  Under the

copyright laws of some countries, it may be necessary for a copyright license

to include an explicit provision setting forth the duration of the rights

being granted. In other countries, including the USA, such a provision is

unnecessary but permissible.

GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of

copyright fair use, or the equivalent under applicable law.  These rights are

compatible with, and not in conflict with, the freedoms that the GPL seeks to

protect, and the GPL cannot and should not restrict them.

However, note that (sadly to some copyleft advocates) the unlimited freedom

to run is confined to the \textit{unmodified} Program.  This confinement is

unfortunately necessary since Programs that do not qualify as a User Product

in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain

unfortunate restrictions on the freedom to run\footnote{See

  \S~ref{freedom-to-run} of this tutorial for the details on ``the freedom to

  run''.}

GPLv3~\S2\P2 distinguishes between activities of a licensee that are

permitted without limitation and activities that trigger additional

requirements.  Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of

privately modifying and running the program.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

full freedoms of the GPL that they deserve.

GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing.

This provision ensures that GPL enforcement is always by the copyright

holder.  Usually, sublicensing is regarded as a practical convenience or

necessity for the licensee, to avoid having to negotiate a license with each

licensor in a chain of distribution.  The GPL solves this problem in another

way --- through its automatic licensing provision found in GPLv3\~S10 (which

is discussed in more detail in \S\~ref{GPLv3s10} of this tutorial).

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.

\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

anti-circumvention law for exercising their rights under the GPL, so far as

the GPL can do so.  Some readers seem to have assumed that this provision

contains a prohibition on DRM; it does not (no part of GPLv3 forbids DRM).

\section{GPLv3~\S4: Verbatim Copying}

% FIXME: there appear to be minor changes here in later drafts, fix that.

Section 4 has been revised from its corresponding section in GPLv2 in light

of the new section 7 on license compatibility. A distributor of verbatim

copies of the program's source code must obey any existing additional terms

that apply to parts of the program. In addition, the distributor is required

to keep intact all license notices, including notices of such additional

terms.

% FIXME: needs context, needs match up to current text, and removal of stuff

%        that's no longer there

The original wording of this clause was meant to

make clear that the GPL permits one to charge for the distribution of

software.  Despite our efforts to explain this in the license and in

other documents, there are evidently some who believe that the GPL

allows charging for services but not for selling software, or that the

GPL requires downloads to be gratis.  We referred to charging a ``fee'';

the term ``fee'' is generally used in connection with services.  Our

original wording also referred to ``the physical act of transferring.''

The intention was to distinguish charging for transfers from attempts to

impose licensing fees on all third parties.  ``Physical'' might be read,

however, as suggesting ``distribution in a physical medium only.''  In

our revised wording we use ``price'' in place of ``fee,'' and we remove

the term ``physical.''

% FIXME: say more and tie it to the text

There is no harm in explicitly pointing out what ought to be obvious: that

those who convey GPL-covered software may offer commercial services for the

support of that software.

\section{GPLv3~\S5: Modified Source}

% FIXME: 5(a) is slightly different in final version

Section 5 contains a number of changes relative to the corresponding section

in GPLv2. Subsection 5a slightly relaxes the requirements regarding notice of

changes to the program. In particular, the modified files themselves need no

longer be marked. This reduces administrative burdens for developers of

modified versions of GPL'd software.

Under subsection 5a, as in the corresponding provision of GPLv2, the notices

must state ``the date of any change,'' which we interpret to mean the date of

one or more of the licensee's changes.  The best practice would be to include

the date of the latest change.  However, in order to avoid requiring revision

of programs distributed under ``GPL version 2 or later,'' we have retained

the existing wording.

% FIXME:  It's now (b) and (c).  Also, ``validity'' of proprietary

%         relicensing?  Give me a break.  I'll fix that.

Subsection 5b is the central copyleft provision of the license.  It now

states that the GPL applies to the whole of the work.  The license must be

unmodified, except as permitted by section 7, which allows GPL'd code to be

combined with parts covered by certain other kinds of free software licensing

terms. Another change in subsection 5b is the removal of the words ``at no

charge,'' which was often misinterpreted by commentators.  The last sentence

of subsection 5b explicitly recognizes the validity of disjunctive

dual-licensing.

%  FIXME: 5d.  Related to Appropriatey Legal notices

% follows 5d now, call it the ``final paragraph''

The paragraph following subsection 5c has been revised for clarity, but the

underlying meaning is unchanged. When independent non-derivative sections are

distributed for use in a combination that is a covered work, the whole of the

combination must be licensed under the GPL, regardless of the form in which

such combination occurs, including combination by dynamic linking. The final

sentence of the paragraph adapts this requirement to the new compatibility

provisions of section 7.

We have added these words to the aggregation clause to eliminate any question

that GPLv3 alters the scope of the copyleft as understood and applied under

GPLv2. In GPLv3, as in GPLv2, addition of modules or other parts to a program

results in a new program based on the old program, with different functional

characteristics created by the merger of two expressions: the original

program and the added parts.  Such added parts are ``by their nature

extensions of'' the old program, and therefore the entire new program which

they and the old program form must be licensed under the GPL.  As subsection

5c states, packaging of a work has no bearing on the scope of copyleft.

\section{GPLv3~\S6: Non-Source and Corresponding Source}

Section 6 of GPLv3, which clarifies and revises GPLv2 section 3, requires

distributors of GPL'd object code to provide access to the corresponding

source code, in one of four specified ways. As noted above, ``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.

Subsections 6a and 6b 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, the

distribution of object code may either be accompanied by the machine-readable

source code, or it may be accompanied by a written offer to provide the

machine-readable source code to any third party. GPLv3 clarifies that the

medium for software interchange on which the machine-readable source code is

provided must be a durable physical medium. Subsection 6b does not prevent a

distributor from offering to provide source code to a third party by some

other means, such as transmission over a network, so long as the option of

obtaining source code on a physical medium is presented.

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

Subsection 6b 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. We believe that 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.

% FIXME: 10x language is gone.

Subsection 6b also increases the maximum permitted price for providing a copy

of the source code. GPLv2 stated that the price could be no more than the

cost of physically performing source distribution; GPLv3 allows the price to

be up to ten times the distributor's cost. It may not be practical to expect

some organizations to provide such copies at cost. Moreover, permitting such

organizations to charge ten times the cost is not particularly harmful, since

some recipient of the code can be expected to make the code freely available

on a public network server. We also recognize that there is nothing wrong

with profiting from providing copies of source code, provided that the price

of a copy is not so unreasonably high as to make it effectively unavailable.

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

Subsection 6c gives narrower permission than the corresponding subsection in

GPLv2.  The option of including a copy of an offer received in accordance

with subsection 6b is available only for private distribution of object code;

moreover, such private distribution is restricted to ``occasional

non-commercial distribution.''  This subsection makes clear that 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:  probably mostly still right, needs some updates, though.

New subsection 6d, which revises the final paragraph of GPLv2 section 3,

addresses distribution of object code by offering access to copy the code

from a designated place, such as by enabling electronic access to a network

server.  Subsection 6d clarifies that the distributor must offer equivalent

access to copy the source code ``in the same way through the same place.''

This wording 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 what has been our

interpretation of GPLv2.

% FIXME: where should this go?

We improved the wording of this sentence to provide a clearer expression of

the intended policy.  Under the 6d option, you may charge for the conveyed

object code. Those who pay to obtain the object code must be given equivalent

and gratis access to obtain the Corresponding Source.  (If you convey the

object code to them gratis, you must likewise make the Corresponding Source

available to them without charge.) Those who do not obtain the object code

from you, perhaps because they choose not to pay the fee you charge, are

outside the scope of the provision; you need not give them any kind of access

to the Corresponding Source.

%FIXME: 6e, peer-to-peer

Informing the peers is clearly enough; what seemed to be an additional

knowledge requirement was superfluous wording.

%  FIXME: Not final paragraph anymore. 

The final paragraph of section 6 takes account of the fact that the Complete

Corresponding Source Code may include added parts that carry non-GPL terms,

as permitted by section 7.

% FIXME: update lock-down section to work with more recent drafts

Though the definition of Complete Corresponding Source Code in the second

paragraph of section 1 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 need to be signed with a key or authorized

with a code in order for it to run on a particular machine and function

properly. Similarly, a program that produces digitally-restricted files might

require a decryption code in order to read the output.

The third paragraph of section 1 addresses this problem by making clear that

Complete Corresponding Source Code includes any such encryption,

authorization, and decryption codes. By requiring the inclusion of this

information whenever the GPL requires distribution of Complete Corresponding

Source Code, we thwart efforts to obstruct the goals of the GPL, and we

ensure that users will remain in control over their own machines. We

recognize an exception where use of the program normally implies that the

user already has the codes. For example, in secure systems a computer owner

might possess any keys needed to run a program, while the distributor of the

program might not have the keys.

% FIXME: installation information??

% FIXME: perhaps this additional information isn't needed, next 3 paras, but

%        there might be something good here

Another major goal for GPLv3 has been to thwart technical measures such as

signature checks in hardware to prevent modification of GPLed software on a

device.  Previous drafts attempted to accomplish this by defining

"Corresponding Source" to include any encryption or authorization keys

necessary to install new versions of the software.  A number of members of

the community questioned the impact and utility of such a definition.

The third discussion draft uses a different strategy to accomplish the same

task.  Section 6 requires that parties distributing object code provide

recipients with the source code through certain means.  Now, when those

distributors pass on the source, they are also required to pass on any

information or data necessary to install modified software on the

particular device that included it.  We believe that this will more

precisely accomplish our goals, and avoid potential problems with expanding

the definition of source code.  The new strategy should be familiar to free

software developers: the GNU LGPL has long had similar requirements that

enable users to link proprietary programs to modified libraries.

\label{user-product}

In addition, the scope of these requirements has been narrowed.  This draft

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.  After some discussion with committees, we discovered

that the proposals in the second discussion draft would interfere with a

number of existing business models that don't seem to be dangerous.  We

believe that this compromise will achieve the greatest success in

preventing tivoization.

In brief, we condition 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.

%FIXME: this really big section on user product stuff may be too much for the

%       tutorial

In our earlier drafts, the requirement to provide encryption keys

applied to all acts of conveying object code, as this requirement was

part of the general definition of Corresponding Source. Section 6 of

Draft 3 now limits the applicability of the technical restrictions

provisions to object code conveyed in, with, or specifically for use in