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

% FIXME: this came from Section 1 but is now mostly in Section 6

In section 1, we have tried to limit as precisely as possible the situation

in which an encryption or signing key is part of the Corresponding Source

Code of a GPL'd work.  Where someone is provided a GPL'd work, he must

receive the whole of the power to use and modify the work that was available

to preceding licensors whose permissions he automatically receives.  If a key

would be necessary to install a fully functional version of the GPL'd work

from source code, the user who receives the binary must receive the key along

with the source.  The requirement of full functionality, which we have

illustrated with examples, is no more optional than it would be if GPL'd

software were redistributed with an additional license condition, rather than

a technical limitation, on the uses to which modified versions could be

put.\footnote{There is a clear distinction between this situation and the

  situation of authenticated modules or plug-ins distributed as part of a

  multi-component software system, so that instances of the software can

  verify for the user the integrity of the collection.  So long as the

  decision about whether to run a modified version is the user's decision,

  not controlled by a preceding licensor or a third party, the vendor's

  authentication key would also not qualify as part of the Corresponding

  Source under the language we have adopted for Draft 2.}

% FIXME: this needs the right place.

We do not object to the practice of conveying object code in a mode not

practically susceptible to modification by any party, such as code burned in

ROM or embedded in silicon.  What we find ethically objectionable is the

refusal to pass on to the downstream licensee the real right to modify,

coupled with the retention of that right in the device manufacturer or some

other party.  Our text has never prohibited distribution in ROM, but we have

decided to make the point explicitly, for clarity's sake. Accordingly, our

text states that the requirement to provide Installation Information ``does

not apply if neither you nor any third party retains the ability to install

modified object code on the User Product.''

%FIXME: publicly documented format.  This might work as a start on that:

Our primary objective here was to ensure that the

distributor use a generally-recognized mechanism for packaging source

code.