Finish up Installation Information section.
This commit is contained in:
parent
b00ddaa698
commit
678c1d8099
1 changed files with 10 additions and 54 deletions
64
gpl-lgpl.tex
64
gpl-lgpl.tex
|
@ -3069,63 +3069,19 @@ deliberately drawn in general terms, and it serves as a foundation for
|
|||
reasonable enforcement policies that respect recipients' right to modify
|
||||
while recognizing the legitimate interests of network providers.
|
||||
|
||||
Note that GPLv3 permits 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. The goal of the Installation Information
|
||||
requirement is to ensure the downstream licensee receives the real right to
|
||||
modify when the device manufacturer or some other party retains that right.
|
||||
Accordingly, GPLv3\S6's ante-penultimate paragraph 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''.
|
||||
|
||||
Finally, GPLv3\S6 makes it clear that there is also no requirement to
|
||||
provide warranty or support for the User Product itself.
|
||||
|
||||
% 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.
|
||||
|
||||
\section{Understanding License Compatibility}
|
||||
\label{license-compatibility}
|
||||
|
||||
|
|
Loading…
Reference in a new issue