Subsections 6a and 6b now apply specifically to distribution of object code

in a physical product. Physical products include embedded systems, as well as

physical software distribution media such as CDs. As in GPLv2, the

distribution of object code may either be accompanied by the machine-readable

source code, or it may be accompanied by a written offer to provide the

machine-readable source code to any third party. GPLv3 clarifies that the

medium for software interchange on which the machine-readable source code is

provided must be a durable physical medium. Subsection 6b does not prevent a

distributor from offering to provide source code to a third party by some

other means, such as transmission over a network, so long as the option of

obtaining source code on a physical medium is presented.

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

Subsection 6b revises the requirements for the written offer to provide

source code. As before, the offer must remain valid for at least three

years. In addition, even after three years, a distributor of a product

containing GPL'd object code must offer to provide source code for as long as

the distributor also continues to offer spare parts or customer support for

the product model. We believe that this is a reasonable and appropriate

requirement; a distributor should be prepared to provide source code if he or

she is prepared to provide support for other aspects of a physical product.

% FIXME: 10x language is gone.

Subsection 6b also increases the maximum permitted price for providing a copy

of the source code. GPLv2 stated that the price could be no more than the

cost of physically performing source distribution; GPLv3 allows the price to

be up to ten times the distributor's cost. It may not be practical to expect

some organizations to provide such copies at cost. Moreover, permitting such

organizations to charge ten times the cost is not particularly harmful, since

some recipient of the code can be expected to make the code freely available

on a public network server. We also recognize that there is nothing wrong

with profiting from providing copies of source code, provided that the price

of a copy is not so unreasonably high as to make it effectively unavailable.

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

Subsection 6c gives narrower permission than the corresponding subsection in

GPLv2.  The option of including a copy of an offer received in accordance

with subsection 6b is available only for private distribution of object code;

moreover, such private distribution is restricted to ``occasional

non-commercial distribution.''  This subsection makes clear that 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:  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

course, we cannot make the GPL compatible with all such licenses. GPLv3

contains provisions that are designed to reduce license incompatibility by

making it easier for developers to combine code carrying non-GPL terms with

GPL'd code.

% FIXME: connecting text

\subsection{Additional Permissions}

% FIXME: rework and fix formatting.

The GPL is a statement of permissions, some of which have conditions.

Additional terms, terms that supplement those of the GPL, may come to be

placed on, or removed from, GPL-covered code in certain common ways.  We

consider those added terms ``additional permissions'' if they grant

exceptions from the conditions of the GPL, and ``additional requirements'' if

they add conditions to the basic permissions of the GPL. The treatment of

additional permissions and additional requirements under GPLv3 is necessarily

asymmetrical, because they do not raise the same ethical and interpretive

issues; in particular, additional requirements, if allowed without careful

limitation, could transform a GPL'd program into a non-free one.  With these

principles in the background, section 7 answers the following questions: (1)

How do the presence of additional terms on all or part of a GPL'd program

affect users' rights? (2) When and how may a licensee add terms to code being

distributed under the GPL? (3) When may a licensee remove additional terms?

% FIXME: FSF third person, etc.

Additional permissions present the easier case.  We have licensed some of our

own software under GPLv2 with permissive exceptions that allow combination

with non-free code, and that allow removal of those permissions by downstream

recipients; similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,

and it permits relicensing under the GPL.  We have generalized these

practices in section 7.  A licensee may remove any additional permission from

a covered work, whether it was placed by the original author or by an

upstream distributor.  A licensee may also add any kind of additional

permission to any part of a work for which the licensee has, or can give,

appropriate copyright permission. For example, if the licensee has written

that part, the licensee is the copyright holder for that part and can

therefore give additional permissions that are applicable to it.

Alternatively, the part may have been written by someone else and licensed,

with the additional permissions, to that licensee.  Any additional

permissions on that part are, in turn, removable by downstream recipients.

As subsection 7a explains, the effect of an additional permission depends on

whether the permission applies to the whole work or a part.

% FIXME: rework this a bit