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

\label{GPLv3s3}

As discussed in \S~\ref{software-and-non-copyright} of this tutorial,

\href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} and

relate sections\footnote{These sections of the USC are often referred to as

  the ``Digital Millennium Copyright Act'', or ``DMCA'', as that was the name

  of the bill that so-modified these sections of the USC\@.} prohibits users

from circumventing technological measures that implement DRM\@.  Since this

is part of copyright law and the GPL is primarily a copyright license, and

since what the DMCA calls ``circumvention'' is simply ``modifying the

software'' under the GPL, GPLv3 must disclaim such anti-circumvention

provisions are not applicable to the GPLv3'd software.  GPLv3\S3 shields

users from being subjected to liability under anti-circumvention law for

exercising their rights under the GPL, so far as the GPL can do so.

First, GPLv3\S3\P1 declares that no GPL'd program is part of an effective

technological protection measure, regardless of what the program does.  Early

drafts of GPLv3\S3\P1 referred directly to the DMCA, but the final version

instead includes instead an international legal reference to

anticircumvention laws enacted pursuant to the 1996 WIPO treaty and any

similar laws.  Lawyers outside the USA worried that a USA statutory reference

could be read as indicating a choice for application of USA law to the

license as a whole.  While the FSF did not necessarily agree with that view,

the FSF decided anyway to refer to the WIPO treaty rather than DMCA, since

several national anticircumvention laws were (or will likely be) structured

more similarly to the anticircumvention provisions of the DMCA in their

implementation of WIPO\@.  Furthermore, the addition of ``or similar laws''

provides an appropriate catch-all.

Furthermore, GPLv3\S3\P2 states precisely that a conveying party waives the

power to forbid circumvention of technological measures only to the extent

that such circumvention is accomplished through the exercise of GPL rights in

the conveyed work.  GPLv3\S3\P2 makes clear that the referenced ``legal

rights'' are specifically rights arising under anticircumvention law.  and

refers to both the conveying party's rights and to third party rights, as in

some cases the conveying party will also be the party legally empowered to

enforce or invoke rights arising under anticircumvention law.

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

stringently control access to other copyrighted works should effectively

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

users who escape technical restriction measures implemented by GPL'd

software.

\section{GPLv3~\S4: Verbatim Copying}

\label{GPLv3s4}

GPLv3~\S4 is a revision of GPLv2\~S1 (as discussed in \S~\ref{GPLv2s1} of

this tutorial).   There are almost no changes to this section from the

GPLv2\~S1, other than to use the new defined terms.

The only notable change of ``a fee'' to ``any price or no price'' in the

first sentence of GPLv3\S4\P2.  The GPLv2\S1\P1 means that the GPL permits

one to charge money for the distribution of software.  Despite efforts by

copyleft advocates to explain this in GPLv2 itself and in other documents,

there are evidently some people who still believe that GPLv2 allows charging

for services but not for selling copies of software and/or that the GPL

requires downloads to be gratis.  Perhaps this is because GPLv2 referred to

charging a ``fee''; the term ``fee'' is generally used in connection with

services.

GPLv2's wording also referred to ``the physical act of transferring.''  The

intention was to distinguish charging for transfers from attempts to impose

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

suggesting ``distribution in a physical medium only''.

To address these two issues, GPLv3 says ``price'' in place of ``fee,'' and

removes the term ``physical.''

GPLv3~\S4 has also been revised from its corresponding section in GPLv2 in

light of the GPLv3~\S7 (see \S~\ref{GPLv3s7} in this tutorial for more).

Specifically, a distributor of verbatim copies of the program's source code

must obey any existing additional terms that apply to parts of the program

pursuant to GPLv3~\S7.  In addition, the distributor is required to keep

intact all license notices, including notices of such additional terms.

Finally, there is no harm in explicitly pointing out what ought to be

obvious: that those who convey GPL-covered software may offer commercial

services for the support of that software.

\section{GPLv3~\S5: Modified Source}

\label{GPLv3s5}

GPLv3\S5 is the rewrite of GPLv2\S2, which was discussed in \S~\ref{GPLv2s2}

of this tutorial.  This section discusses the changes found in GPLv3\S5

compared to GPLv2\S2.

GPLv3\S5(a) still requires modified versions be marked with ``relevant

date'', but no longer says ``the date of any change''.  The best practice is

to include the date of the latest and/or most significant changes and who

made those.  Of course, compared to its GPLv2\S2(a), GPLv3\S5(a) slightly

relaxes the requirements regarding notice of changes to the program.  In

particular, the modified files themselves need no longer be marked.  This

reduces administrative burdens for developers of modified versions of GPL'd

software.

GPLv3\S5(b) is a new but simple provision. GPLv3\S5(b)  requires that the

license text itself must be unmodified (except as permitted by GPLv3\S7; see

\S~\ref{GPLv3s7} in this tutorial).  Furthermore, it  removes any perceived

conflict between the words ``keep intact all notices'' in GPLv3\S4, since

operating under GPLv3\S5 still includes all the requirements of GPLv3\S4 by

reference.

GPLv3\S5(c) is the primary source-code-related copyleft provision of GPL. (The

object-code-related copyleft provisions are in GPLv3\S6, discussed in

\S~\ref{GPLv3s6} of this tutorial).  Compared to GPLv2\S2(b), GPLv3\S5(c)

states that the GPL applies to the whole of the work.  Such was stated

already in GPLv2\S2(b), in ``in whole or in part'', but this simplified

wording makes it clear the entire covered work

Another change in GPLv3\S5(c) is the removal of the

words ``at no charge,'' which was often is misunderstood upon na\"{i}ve

reading of in GPLv2\S(b) (as discussed in \S~\ref{GPLv2s2-at-no-charge} of this

tutorial).

%  FIXME-LATER: Write up something on 5d, and related it to Appropriate Legal Notices.

Note that of GPLv2~\S2's penultimate and ante-penultimate paragraphs are now

handled adequately by the definitions in GPLv3\S0 and as such, have no direct

analogs in GPLv3.

GPLv2~\S2's final paragraph, however, is reworded and expanded into the final

paragraph of GPLv3\S5, which now also covers issues related to copyright

compilations (but not compilations into object code --- that's in the next

section!).  The intent and scope is the same as was intended in GPLv2.

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

\label{GPLv3s6}

GPLv3~\S6 clarifies and revises GPLv2~\S3.  It requires distributors of GPL'd

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

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

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

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

GPLv3~\S6(a--b) now apply specifically to distribution of object code in a

physical product.  Physical products include embedded systems, as well as

physical software distribution media such as CDs.  As in GPLv2~\S3 (discussed

in \S~\ref{GPLv2s3} of this tutorial), the distribution of object code may

either be accompanied by the machine-readable source code, or it may be

accompanied by a valid written offer to provide the machine-readable source

code.  However, unlike in GPLv2, that offer cannot be exercised by any third

party; rather, only those ``who possesses the object code'' it can exercised

the offer.  (Note that this is a substantial narrowing of requirements of

offer fulfillment, and is a wonderful counterexample to dispute claims that

the GPLv3 has more requirements than GPLv2.)

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

GPLv3~\S6(b) further revises the requirements for the written offer to

provide source code. As before, the offer must remain valid for at least

three years. In addition, even after three years, a distributor of a product

containing GPL'd object code must offer to provide source code for as long as

the distributor also continues to offer spare parts or customer support for

the product model.  This is a reasonable and appropriate requirement; a

distributor should be prepared to provide source code if he or she is

prepared to provide support for other aspects of a physical product.

GPLv3~\S6(a--b) clarifies that the medium for software interchange on which

the machine-readable source code is provided must be a durable physical

medium.  GPLv3~\S6(b)(2), however, permits a distributor to instead offer to

provide source code from a network server instead, which is yet another

example GPLv3 looser in its requirements than GPLv2 (see

\S~\ref{GPLv2s3-medium-customarily} for details).

% FIXME-LATER: more information about source provision, cost of physically

% performing, reasonable fees, medium customary clearly being said durable

% connecting back to previous text

GPLv3\S6(c) gives narrower permission than GPLv2\S3(c).  The ``pass along''

option for GPLv3\S6(c)(1) offers is now available only for individual

distribution of object code; moreover, such individual distribution can occur

only ``occasionally and noncommercially.''  A distributor cannot comply with

the GPL merely by making object code available on a publicly-accessible

network server accompanied by a copy of the written offer to provide source

code received from an upstream distributor.

%FIXME-LATER: tie back to the discussion of the occasional offer pass along

%             stuff in GPLv2 this tutorial.

GPLv3~\S6(d) revises and improves GPLv2~\S3's final paragraph.  When object

code is provided by offering access to copy the code from a designated place

(such as by enabling electronic access to a network server), the distributor

must merely offer equivalent access to copy the source code ``in the same way

through the same place''.  This wording also permits a distributor to offer a

third party access to both object code and source code on a single network

portal or web page, even though the access may include links to different

physical servers.  For example, a downstream distributor may provide a link

to an upstream distributor's server and arrange with the operator of that

server to keep the source code available for copying for as long as the

downstream distributor enables access to the object code.  This codifies

formally typical historical interpretation of GPLv2.

% FIXME-LATER: perhaps in enforcement section, but maybe here, note about

% ``slow down'' on source downloads being a compliance problem. 

Furthermore, under GPLv3~\S6(d), distributors may charge for the conveyed

object code; however, those who pay to obtain the object code must be given

equivalent and gratis access to obtain the CCS.  (If distributors convey the

object code gratis, distributors must likewise make CCS available without

charge.)  Those who do not obtain the object code from that distributors

(perhaps because they choose not to pay the fee for object code) are outside

the scope of the provision; distributors are under no specific obligation to

give CCS to someone who has not purchased an object code download under

GPLv3~\S6(d).  (Note: this does not change nor impact any obligations under

GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)

\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}

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

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

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

BitTorrent distribution is neither straightforward nor reasonable; such

distribution is multidirectional, cooperative and anonymous.  In peer-to-peer

distribution systems, participants act both as transmitters and recipients of

blocks of a particular file, but they perceive the experience merely as users

and receivers, and not as distributors in any conventional sense.  At any

given moment of time, most peers will not have the complete file.

Meanwhile, GPLv3~\S6(d) permits distribution of a work in object code form

over a network, provided that the distributor offers equivalent access to

copy the Corresponding Source Code ``in the same way through the same

place''.  This wording might be interpreted to permit peer-to-peer

distribution of binaries \textit{if} they are packaged together with the CCS,

but such packaging impractical, for at least three reasons.  First, even if

the CCS is packaged with the object code, it will only be available to a

non-seeding peer at the end of the distribution process, but the peer will

already have been providing parts of the binary to others in the network.

Second, in practice, peer-to-peer forms of transmission are poorly suited

means for distributing CCS.  In large distributions, packaging CCS with the

object code may result in a substantial increase in file size and

transmission time.  Third, in current practice, CCS packages themselves tend

\textit{not} to be transmitted through BitTorrent --- owing to reduced demand

-- thus, there generally will be too few participants downloading the same

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

GPLv3~\S6(e) addresses this issues.  If a licensee conveys such a work of

object code using peer-to-peer transmission, that licensee is in compliance

with GPLv3~\S6 if the licensee informs other peers where the object code and

its CCS are publicly available at no charge under subsection GPLv3~\S6(d).

The CCS therefore need not be provided through the peer-to-peer system that

was used for providing the binary.

Second, GPLv3\S9 also clarifies that ancillary propagation of a covered work

that occurs as part of the process of peer-to-peer file transmission does not

require acceptance, just as mere receipt and execution of the Program does

not require acceptance.  Such ancillary propagation is permitted without

limitation or further obligation.

% FIXME-LATER: Would be nice to explain much more about interactions between

% the various options of GPLv3~\S6(a-e), which might all be in play at once!

% 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

a defined class of ``User Products.''

In our discussions with companies and governments that use specialized

or enterprise-level computer facilities, we found that sometimes these

organizations actually 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 preference. It is not clear that we

need to interfere, and 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, and we expect that to remain true in

the near future. 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 if limited to User Products, as defined in Draft 3, the

provision still does the job that needs to be done. Therefore we have

decided to limit the technical restrictions provisions to User Products

in this draft.

The core of the User Product definition is a subdefinition of ``consumer

product'' taken verbatim from the Magnuson-Moss Warranty Act, a federal

consumer protection law in the United States: ``any tangible personal

property which is normally used for personal, family, or household

purposes.''\footnote{15 U.S.C.~\S\ 2301.}  The United States 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 United States and Canada, having been

adopted in several state and provincial consumer protection laws.}  We

mean for this body of interpretation to guide interpretation of the

consumer product subdefinition in section 6, which will provide a degree

of legal certainty advantageous to device manufacturers and downstream

licensees alike.  Our incorporation of such legal interpretation is in

no way intended to work a general choice of United States law for GPLv3

as a whole.  The paragraph in section 6 defining ``User Product'' and

``consumer product'' contains an explicit statement to this effect,

bracketed for discussion.  We will decide whether to retain this

statement in the license text after gathering comment on it.

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

C.F.R.~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54

U.C.C.~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 C.F.R. \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.}

We do not rely solely on the definition of consumer product, however,

because in the area of components of dwellings we consider 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, we define User Products as a

superset of consumer products that also includes ``anything designed or

sold for incorporation into a dwelling.''

Although the User Products rule of Draft 3 reflects a special concern

for individual purchasers of devices, we wrote the rule to cover a

category of products, rather than categorizing users.  Discrimination

against organizational users has no place in a free software license.

Moreover, a rule that applied to individual use, rather than to use of

products normally used by individuals, would have too narrow an

effect. Because of its incorporation of the liberal Magnuson-Moss

interpretation of ``consumer product,'' the User Products rule benefits

not only individual purchasers of User Products but also all

organizational purchasers of those same kinds of products, regardless of

their intended use of the products.

we have replaced the Magnuson-Moss

reference with three sentences that encapsulate the judicial and

administrative principles established over the past three decades in the

United States concerning the Magnuson-Moss consumer product definition.

First, we state that doubtful cases are resolved in favor of coverage

under the definition.  Second, we 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, we make clear 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, contrary

to what some critics of Draft 3 have suggested.

We have made one additional change to the User Products provisions of

section 6.  In Draft 3 we made clear that the requirement to provide

Installation Information implies no requirement to provide warranty or

support for a work that has been modified or installed on a User

Product.  The Final Draft adds that there is similarly no requirement to

provide warranty or support for the User Product itself.

% FIXME: this needs integration

In Draft 3 we instead use a definition of ``Installation Information'' in

section 6 that is as simple and clear as that goal.  Installation Information

is information that is ``required to install and execute modified versions of

a covered work \dots from a modified version of its Corresponding Source,''

in the same User Product for which the covered work is conveyed.  We provide

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

%FIXME: This probably needs work to be brought into clarity with tutorial,

%next three paragarphs.

Why do distributors only have to provide Installation Information for User

Products?

Some companies effectively outsource their entire IT department to another

company. Computers and applications are installed in the company's offices,

but managed remotely by some service provider. In some of these situations,

the hardware is locked down; only the service provider has the key, and the

customers consider that to be a desirable security feature.

We think it's unfortunate that people would be willing to give up their

freedom like this.  But they should be able to fend for themselves, and the

market provides plenty of alternatives to these services that would not lock

them down. As a result, we have introduced this compromise to the draft:

distributors are only required to provide Installation Information when

they're distributing the software on a User Product, where the customers'

buying power is likely to be less organized.

This is a compromise of strategy, and not our ideals. Given the environment

we live in today --- where Digital Restrictions Management is focused largely

in consumer devices, and everyone, including large companies, is becoming

increasingly worried about the effects of DRM thanks to recent developments

like the release of Microsoft's Windows Vista --- we think that the proposed

language will still provide us with enough leverage to effectively thwart

DRM. We still believe you have a fundamental right to modify the software on

all the hardware you own; the preamble explains, ``If such problems [as

  locked-down hardware] arise substantially in other domains, we stand ready

to extend this provision to those domains in future versions of the GPL, as

needed to protect the freedom of users.''

The definition of Installation Information states that the information

provided ``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.''  We did not consider it necessary to

define ``continued functioning'' further. However, we believed it would be

appropriate to 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.  We

make clear that GPLv3 implies no obligation ``to continue to provide support

service, warranty, or updates'' for such a work.

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.  We settled on a rule that 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.  We intend it to serve as a foundation

for development of reasonable enforcement policies that respect recipients'

right to modify while recognizing the legitimate interests of network

providers.

% FIXME: This needs merged in somewhere in here

The mere fact that use of the work implies that the user \textit{has} the key

may not be enough to ensure the user's freedom in using it.  The user must

also be able to read and copy the key; thus, its presence in a special

register inside the computer does not satisfy the requirement. In an

application in which the user's personal key is used to protect privacy or

limit distribution of personal data, the user clearly has the ability to read

and copy the key, which therefore is not included in the Corresponding

Source. On the other hand, if a key is generated based on the object code, or

is present in hardware, but the user cannot manipulate that key, then the key

must be provided as part of the Corresponding Source.