Changeset - 678e841079aa
[Not reviewed]
0 1 0
Free Software Foundation, Inc - 10 years ago 2014-03-19 20:01:54
info@fsf.org
Relevant text from FSF's "GPLv2 Discussion Draft 3 FAQ",
as published circa 2007-03-28, (around the time of GPLv3 Third Discussion
Draft)

I (Bradley M. Kuhn) carefully went through FSF's "GPLv2 Discussion Draft 3
FAQ", which appears to have been published on Thursday 28 March 2007, and
merged in any relevant text that might be of use in this tutorial.

The raw material used for this commit can be found here:
http://gplv3.fsf.org/dd3-faq

As I merged in this text, I added FIXME's where it seemed the text was
incomplete or referred to parts of GPLv3 draft text that disappeared in later
versions.

Finally, note that this material was originally copyrighted and licensed as
follows:

Copyright © 2007 Free Software Foundation, Inc.

Verbatim copying and distribution of this entire article are permitted
worldwide, without royalty, in any medium, provided this notice, and the
copyright notice, are preserved.

However, I am hereby relicensing this material to CC-By-SA-4.0, with the
verbal permission from John Sullivan, Executive Director of the FSF, which
was given to me during a conference call on Wednesday 12 February 2014. I
also confirmed that relicensing permission on IRC with johnsu01 today.
1 file changed with 29 insertions and 0 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -2794,24 +2794,53 @@ 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
 

	
 

	
 
Why do distributors only have to provide Installation Information for User Products?
 

	
 
Some companies effectively outsource their entire IT department to another
 
company. Computers and applications are installed in the company's offices,
 
but managed remotely by some service provider. In some of these situations,
 
the hardware is locked down; only the service provider has the key, and the
 
customers consider that to be a desirable security feature.
 

	
 
We think it's unfortunate that people would be willing to give up their
 
freedom like this.  But they should be able to fend for themselves, and the
 
market provides plenty of alternatives to these services that would not lock
 
them down. As a result, we have introduced this compromise to the draft:
 
distributors are only required to provide Installation Information when
 
they're distributing the software on a User Product, where the customers'
 
buying power is likely to be less organized.
 

	
 
This is a compromise of strategy, and not our ideals. Given the environment
 
we live in today --- where Digital Restrictions Management is focused largely
 
in consumer devices, and everyone, including large companies, is becoming
 
increasingly worried about the effects of DRM thanks to recent developments
 
like the release of Microsoft's Windows Vista --- we think that the proposed
 
language will still provide us with enough leverage to effectively thwart
 
DRM. We still believe you have a fundamental right to modify the software on
 
all the hardware you own; the preamble explains, ``If such problems [as
 
  locked-down hardware] arise substantially in other domains, we stand ready
 
to extend this provision to those domains in future versions of the GPL, as
 
needed to protect the freedom of users.''
 

	
 
% 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.
0 comments (0 inline, 0 general)