\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