% FIXME:  probably mostly still right, needs some updates, though.

New subsection 6d, which revises the final paragraph of GPLv2 section 3,

addresses distribution of object code by offering access to copy the code

from a designated place, such as by enabling electronic access to a network

server.  Subsection 6d clarifies that the distributor must offer equivalent

access to copy the source code ``in the same way through the same place.''

This wording 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 what has been our

interpretation of GPLv2.

%FIXME: 6e, peer-to-peer

%  FIXME: Not final paragraph anymore. 

The final paragraph of section 6 takes account of the fact that the Complete

Corresponding Source Code may include added parts that carry non-GPL terms,

as permitted by section 7.

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

\section{Understanding License Compatibility}

\label{license-compatibility}

% FIXME: more about license compatibility here.

A challenge that faced the Free Software community heavily through out the

early 2000s was the proliferation of incompatible Free Software licenses.  Of