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!

\subsection{User Products, Installation Information and Device Lock-Down}

As discussed in \S~\ref{GPLv3-drm} of this tutorial, GPLv3 seeks thwart

technical measures such as signature checks in hardware to prevent

modification of GPLed software on a device.

To address this issue, GPLv3~\S6 requires that parties distributing object

code provide recipients with the source code through certain means.  When

those distributors pass on the CCS, they are also required to pass on any

information or data necessary to install modified software on the particular

device that included it.  (This strategy is not unlike that used in LGPLv2.1

to enable users to link proprietary programs to modified libraries.)

% FIXME-LATER: LGPLv2.1 section should talk about this explicitly and this

%              should be a forward reference here

\label{user-product}

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