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