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…
	
	Add table
		
		Reference in a new issue
	
	 Bradley M. Kuhn
						Bradley M. Kuhn