Changeset - ebe7610b2b3e
[Not reviewed]
0 1 0
Free Software Foundation, Inc - 10 years ago 2014-03-19 20:08:50
info@fsf.org
Relevant text from FSF press summary circa 2007-03-28

I (Bradley M. Kuhn) carefully went through some internal FSF files, and found
these in notes that were sent to journalists at the time of the release of
GPLv3 Discussion Draft 3.

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 78 insertions and 4 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -2756,100 +2756,136 @@ 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
 

	
 

	
 
Why do distributors only have to provide Installation Information for User Products?
 
% FIXME: installation information??
 

	
 

	
 
% FIXME: perhaps this additional information isn't needed, next 3 paras, but
 
%        there might be something good here
 

	
 
Another major goal for GPLv3 has been to thwart technical measures such as
 
signature checks in hardware to prevent modification of GPLed software on a
 
device.  Previous drafts attempted to accomplish this by defining
 
"Corresponding Source" to include any encryption or authorization keys
 
necessary to install new versions of the software.  A number of members of
 
the community questioned the impact and utility of such a definition.
 

	
 
The third discussion draft uses a different strategy to accomplish the same
 
task.  Section 6 requires that parties distributing object code provide
 
recipients with the source code through certain means.  Now, when those
 
distributors pass on the source, they are also required to pass on any
 
information or data necessary to install modified software on the
 
particular device that included it.  We believe that this will more
 
precisely accomplish our goals, and avoid potential problems with expanding
 
the definition of source code.  The new strategy should be familiar to free
 
software developers: the GNU LGPL has long had similar requirements that
 
enable users to link proprietary programs to modified libraries.
 

	
 
In addition, the scope of these requirements has been narrowed.  This draft
 
introduces the concept of a "User Product," which includes devices that are
 
sold for personal, family, or household use.  Distributors are only
 
required to provide installation information when they convey object code
 
in a User Product.  After some discussion with committees, we discovered
 
that the proposals in the second discussion draft would interfere with a
 
number of existing business models that don't seem to be dangerous.  We
 
believe that this compromise will achieve the greatest success in
 
preventing tivoization.
 

	
 

	
 
%FIXME: This probably needs work to be brought into clarity with tutorial,
 
%next three paragarphs.
 

	
 
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.
 

	
 
% 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
...
 
@@ -3152,180 +3188,218 @@ to grant or refuse this request.
 

	
 
% FIXME: needs to be updated to describe more complex termination
 

	
 
If a licensee who is in violation of GPLv3 acts to correct the violation and
 
enter into compliance, and the licensee receives no notice of the past
 
violation within 60 days, then the licensee need not worry about termination
 
of rights under the license.
 

	
 
\section{GPLv3~\S9: Acceptance}
 

	
 
% FIXME: needs some work here
 

	
 
Section 9 means what it says: mere receipt or execution of code neither
 
requires nor signifies contractual acceptance under the GPL.  Speaking more
 
broadly, we have intentionally structured our license as a unilateral grant
 
of copyright permissions, the basic operation of which exists outside of any
 
law of contract.  Whether and when a contractual relationship is formed
 
between licensor and licensee under local law do not necessarily matter to
 
the working of the license.
 

	
 
\section{GPLv3~\S10: Explicit Downstream License}
 

	
 
% FIXME: needs filled out and more here.
 

	
 
Draft1 removed the words ``at no charge'' from what is now subsection 5b, the
 
core copyleft provision, for reasons related to our current changes to the
 
second paragraph of section 4: it had contributed to a misconception that the
 
GPL did not permit charging for distribution of copies.  The purpose of the
 
``at no charge'' wording was to prevent attempts to collect royalties from
 
third parties.  The removal of these words created the danger that the
 
imposition of licensing fees would no longer be seen as a license
 
violation.
 

	
 
We therefore have added a new explicit prohibition on imposition of licensing
 
fees or royalties in section 10.  This section is an appropriate place for
 
such a clause, since it is a specific consequence of the general requirement
 
that no further restrictions be imposed on downstream recipients of
 
GPL-covered code.
 

	
 
\section{GPLv3~\S11: Explicit Patent Licensing}
 
\label{GPLv3s11}
 

	
 
The patent licensing practices that section 7 of GPLv2 (corresponding to
 
section 12 of GPLv3) was designed to prevent are one of several ways in which
 
software patents threaten to make free programs non-free and to prevent users
 
from exercising their rights under the GPL. GPLv3 takes a more comprehensive
 
approach to combatting the danger of patents.
 

	
 
% FIXME: This probably needs editing
 

	
 
One major goal for GPLv3 is to provide developers with additional protection
 
from being sued for patent infringement.  After much feedback and cooperation
 
from the committees, we are now proposing a patent license which closely
 
resembles those found in other free software licenses.  This will be more
 
comfortable for everyone in the free software community to use, without
 
creating undue burdens for distributors.
 

	
 
We have also added new terms to stop distributors from colluding with third
 
parties to offer selective patent protection, as Microsoft and Novell have
 
recently done.  The GPL is designed to ensure that all users receive the
 
same rights; arrangements that circumvent this make a mockery of free
 
software, and we must do everything in our power to stop them.
 

	
 
Our strategy has two parts.  First, any license that protects some
 
recipients of GPLed software must be extended to all recipients of the
 
software.  Second, we prohibit anyone who made such an agreement from
 
distributing software released under GPLv3.  We are still considering
 
whether or not this ban should apply when a deal was made before these
 
terms were written, and we look forward to community input on this issue.
 

	
 

	
 
% FIXME: just brought in words here, needs rewriting.
 

	
 
is rooted in the basic principles of the GPL.
 
Our license has always stated that distributors may not impose further
 
restrictions on users' exercise of GPL rights.  To make the suggested
 
distinction between contribution and distribution is to allow a
 
distributor to demand patent royalties from a direct or indirect
 
recipient, based on claims embodied in the distributed code. This
 
undeniably burdens users with an additional legal restriction on their
 
rights, in violation of the license.
 

	
 
%FIXME: possible useful text, but maybe not.
 

	
 
In the covenant provided in the revised section 11, the set of claims
 
that a party undertakes not to assert against downstream users are that
 
party's ``essential patent claims'' in the work conveyed by the party.
 
``Essential patent claims,'' a new term defined in section 0, are simply
 
all claims ``that would be infringed by making, using, or selling the
 
work.''  We have abandoned the phrase ``reasonably contemplated use.''
 
This change makes the obligations of distributing patent holders more
 
predictable.
 

	
 
% FIXME:  probably needs a lot of work, these provisions changed over time.
 

	
 
GPLv3 adds a new section on licensing of patents. GPLv2 relies on an implied
 
patent license. The doctrine of implied license is one that is recognized
 
under United States patent law but may not be recognized in other
 
jurisdictions. We have therefore decided to make the patent license grant
 
explicit in GPLv3. Under section 11, a redistributor of a GPL'd work
 
automatically grants a nonexclusive, royalty-free and worldwide license for
 
any patent claims held by the redistributor, if those claims would be
 
infringed by the work or a reasonably contemplated use of the work.
 

	
 
% FIXME:  probably needs a lot of work, these provisions changed over time.
 

	
 
The patent license is granted both to recipients of the redistributed work
 
and to any other users who have received any version of the work. Section 11
 
therefore ensures that downstream users of GPL'd code and works derived from
 
GPL'd code are protected from the threat of patent infringement allegations
 
made by upstream distributors, regardless of which country's laws are held to
 
apply to any particular aspect of the distribution or licensing of the GPL'd
 
code.
 

	
 
% FIXME:  probably needs a lot of work, these provisions changed over time.
 

	
 
A redistributor of GPL'd code may benefit from a patent license that has been
 
granted by a third party, where the third party otherwise could bring a
 
patent infringement lawsuit against the redistributor based on the
 
distribution or other use of the code. In such a case, downstream users of
 
the redistributed code generally remain vulnerable to the applicable patent
 
claims of the third party. This threatens to defeat the purposes of the GPL,
 
for the third party could prevent any downstream users from exercising the
 
freedoms that the license seeks to guarantee.
 

	
 
% FIXME:  probably needs a lot of work, these provisions changed over time.
 

	
 
The second paragraph of section 11 addresses this problem by requiring the
 
redistributor to act to shield downstream users from these patent claims. The
 
requirement applies only to those redistributors who distribute knowingly
 
relying on a patent license. Many companies enter into blanket patent
 
cross-licensing agreements. With respect to some such agreements, it would
 
not be reasonable to expect a company to know that a particular patent
 
license covered by the agreement, but not specifically mentioned in it,
 
protects the company's distribution of GPL'd code.
 

	
 
% FIXME: does this still fit with the final retaliation provision?
 

	
 
This narrowly-targeted patent retaliation provision is the only form of
 
patent retaliation that GPLv3 imposes by its own force. We believe that it
 
strikes a proper balance between preserving the freedom of a user to run and
 
modify a program, and protecting the rights of other users to run, modify,
 
copy, and distribute code free from threats by patent holders. It is
 
particularly intended to discourage a GPL licensee from securing a patent
 
directed to unreleased modifications of GPL'd code and then suing the
 
original developers or others for making their own equivalent modifications.
 

	
 
Several other free software licenses include significantly broader patent
 
retaliation provisions. In our view, too little is known about the
 
consequences of these forms of patent retaliation. As we explain below,
 
section 7 permits distribution of a GPL'd work that includes added parts
 
covered by terms other than those of the GPL. Such terms may include certain
 
kinds of patent retaliation provisions that are broader than those of section
 
2.
 

	
 
% FIXME: should we mention Microsoft-Novell at all?
 

	
 
We attack the Microsoft-Novell deal from two angles. First, in the sixth
 
paragraph of section 11, the draft says that if you arrange to provide patent
 
protection to some of the people who get the software from you, that
 
protection is automatically extended to everyone who receives the software,
 
no matter how they get it. This means that the patent protection Microsoft
 
has extended to Novell's customers would be extended to everyone who uses any
 
software Novell distributes under GPLv3.
 

	
 
Second, in the seventh paragraph, the draft says that you are prohibited from
 
distributing software under GPLv3 if you make an agreement like the
 
Microsoft-Novell deal in the future. This will prevent other distributors
 
from trying to make other deals like it.
 

	
 
\section{GPLv3~\S12: Familiar as GPLv2 \S~7}
 

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

	
 
The wording in the first sentence of section 12 has been revised
 
slightly to clarify that an agreement, such as a litigation settlement
 
agreement or a patent license agreement, is one of the ways in which
 
conditions may be ``imposed'' on a GPL licensee that may contradict the
 
conditions of the GPL, but which do not excuse the licensee from
 
compliance with those conditions.  This change codifies what has been
 
our interpretation of GPLv2.  
 

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

	
 
We have removed the limited severability clause of GPLv2 section 7 as a
 
matter of tactical judgment, believing that this is the best way to ensure
 
that all provisions of the GPL will be upheld in court. We have also removed
 
the final sentence of GPLv2 section 7, which we consider to be unnecessary.
 

	
 
\section{GPLv3~\S13: The Great Affero Compromise}
 

	
 
% FIXME
 

	
 
\section{GPLv3~\S14: So, When's GPLv4?}
 
\label{GPlv2s14}
 

	
 
% FIXME Say more
 

	
 
No substantive change has been made in section 14. The wording of the section
 
has been revised slightly to make it clearer.
 

	
 
% FIXME; proxy
 

	
 
\section{GPLv3~\S15--17: Warranty Disclaimers and Liability Limitation}
 

	
 
No substantive changes have been made in sections 15 and 16.
 

	
 
% FIXME: more, plus 17
 

	
 
% FIXME: Section header needed here about choice of law.
 

	
 
% FIXME: reword into tutorial
 

	
 
Some have asked us to address the difficulties of internationalization
 
by including, or permitting the inclusion of, a choice of law
 
provision.  We maintain that this is the wrong approach.  Free
 
software licenses should not contain choice of law clauses, for both
 
legal and pragmatic reasons.  Choice of law clauses are creatures of
0 comments (0 inline, 0 general)