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: 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

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