Copyleft/guide
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Relevant text from FSF's "GPLv3 Third Discussion Draft Rationale",

Browse source 
as released on 2007-03-28.

I (Bradley M. Kuhn) went through FSF's "Third Discussion Draft Rationale",
and pasted in any sections that seemed useful to this tutorial.  There is a
lot of interesting material in that particular rationale document, although
much of it is probably too verbose for inclusion.  I expect much of this will
need to be cut out.

The raw material used for this commit can be found here:
     http://gplv3.fsf.org/gpl3-dd3-guide
Specifically, a copy of the LaTeX sources are here:
     http://gplv3.fsf.org/gpl3-dd3-rationale.tex

As I pasted in this text, I added FIXME's sometimes where it seemed the text
might need work.  However, I was much more extensive in just pasting here, so
there's a big editing job now.  The whole GPLv3 chapter is now completely
disjoint with all this pasting.

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 is
  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.
This commit is contained in:
Free Software Foundation 2007-03-28 11:20:11 -04:00 committed by Bradley M. Kuhn
parent ebe7610b2b
commit f4b4b9f85e
1 changed files with 834 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

835
gpl-lgpl.tex
View file

@ -2109,6 +2109,9 @@ geographical distribution limitation since GPLv2 was released in 1991. We
have concluded that this provision is not needed and is not expected to be
needed in the future, and that it therefore should be removed.
Although a principal reason for removing the provision is the fact that it
has rarely been used, we have also encountered one current example of its use
that we find troubling.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Odds, Ends, and Absolutely No Warranty}
@ -2148,6 +2151,15 @@ There is apparently general acceptance that \textsc{all caps} is the
preferred way to make something conspicuous, and that has over decades worked
its way into the voodoo tradition of warranty disclaimer writing.
% FIXME: Admittedly, goes here ?
There is authority under United States law suggesting that effective warranty
disclaimers must be ``conspicuous,'' and that conspicuousness can be
established by capitalization and is absent when a disclaimer has the same
typeface as the terms surrounding it (see \textit{Stevenson v.~TRW, Inc.},
987 F.2d 288, 296 (5th Cir.~1993)). We have reason to doubt that such
authority would apply to copyright licenses like the GPL.
Some have argued the GPL is unenforceable in some jurisdictions because
its disclaimer of warranties is impermissibly broad. However, GPLv2~\S11
contains a jurisdictional savings provision, which states that it is to be
@ -2254,6 +2266,13 @@ GPLv3~\S0 includes definitions of four new terms not found in any form in
GPLv2: ``covered work'', ``propagate'', ``convey'', and ``Appropriate Legal
Notices''.
% FIXME: modify needs more discussion
We have made further improvements to the important definitions of ``modify''
and ``based on,'' providing a complete definition of ``modify'' that refers
to basic copyright rights, and using this definition of ``modify'' to define
``modified version of'' and ``work based on,'' now presented as synonyms.
% FIXME: Transition, GPLv2 ref needed.
Although the definition of ``work based on the Program'' made use of a legal
@ -2470,6 +2489,29 @@ other existing implementations.
s long as users are truly in a position to install and run
their modified versions of the program
In our earlier drafts we devoted much care to devising a detailed technical
definition of the cryptographic information that would enable GPL licensees
to install functioning modified versions, without affecting legitimate uses
of encryption. The result was a provision that some found too complex and
difficult to understand, while others continued to raise concerns about
overinclusion. In fact, the complexity and its resultant problems were never
necessary, since our underlying goal was quite simple.
In Draft 3 we instead use a definition of ``Installation Information'' in
section 6 that is as simple and clear as that goal. Installation Information
is information that is ``required to install and execute modified versions of
a covered work \dots from a modified version of its Corresponding Source,''
in the same User Product for which the covered work is conveyed. We provide
guidance concerning how much information must be provided: it ``must suffice
to ensure that the continued functioning of the modified object code is in no
case prevented or interfered with solely because modification has been
made.'' For example, the information provided would be insufficient if it
enabled a modified version to run only in a disabled fashion, solely because
of the fact of modification (regardless of the actual nature of the
modification). The information need not consist of cryptographic keys;
Installation Information may be ``any methods, procedures, authorization
keys, or other information.''
% FIXME: Standard Interface
% FIXME: System Libraries: it's in a different place and changed in later drafts
@ -2495,6 +2537,20 @@ the requirement to distribute source code. The more low-level the
functionality provided by the library, the more likely it is to be
qualified for this exception.
Because GPLv3 now has requirements referring to Corresponding Source outside
of the object code conveying requirements of section 6 (see section 10,
second paragraph, and section 11, third paragraph), it has become necessary
to define what ``Corresponding Source'' means for a work in source code form.
Our definition states that it is nothing more than that work itself. It is
important to note that section 11, paragraph 3 refers to a work that is
conveyed, and section 10, paragraph 2 refers to a kind of automatic
counterpart to conveying achieved as the result of a transaction. The
permissions of section 5 imply that if one distributes source code, one can
never be required to provide more than what is distributed. One always has
the right to modify a source code work by deleting any part of it, and there
can be no requirement that free software source code be a whole functioning
program.
\section{GPLv3~\S2: Basic Permissions}
% FIXME: phrase ``unmodified Program'' appears due to User Products exception
@ -2531,6 +2587,13 @@ provision.
% FIXME: new section here, just to talk DRM before the other section.
GPLv3 introduces provisions that respond to the growing practice of
distributing GPL-covered programs in devices that employ technical means
to restrict users from installing and running modified versions. This
practice thwarts the expectations of developers and users alike, because
the right to modify is one of the core freedoms the GPL is designed to
secure.
Technological measures to defeat users' rights --- often described by such
Orwellian phrases as ``digital rights management,'' which actually means
limitation or outright destruction of users' legal rights, or ``trusted
@ -2599,6 +2662,22 @@ invasive para-copyright.
% FIXME: Wrong paragraph now.
What was the second paragraph of section 3 in Draft 2, concerning so-called
anticircumvention law, has been broken up into two paragraphs. In the first
paragraph we have replaced the reference to the Digital Millennium Copyright
Act, a United States statute, with a corresponding international legal
reference to anticircumvention laws enacted pursuant to the 1996 WIPO treaty
and any similar laws. Lawyers outside the United States have worried that a
United States statutory reference could be read as indicating a choice for
application of United States law to the license as a whole, which of course
was not our intention. Further research has caused us to doubt the view that
only one or the other paragraph of section 3 will typically be effective in a
country that has enacted an anticircumvention law. Moreover, we believe that
several national anticircumvention laws have been or will be structured more
similarly to the anticircumvention provisions of the Digital Millennium
Copyright Act than to the counterpart provisions of the European Union
Copyright Directive.
The second paragraph of section 3 declares that no GPL'd program is part of
an effective technological protection measure, regardless of what the program
does. Ill-advised legislation in the United States and other countries has
@ -2607,6 +2686,17 @@ distributed as part of a system for generating or accessing certain data, the
effect of this paragraph is to prevent someone from claiming that some other
GPL'd program that accesses the same data is an illegal circumvention.
we now state more precisely that a conveying party waives the power to forbid
circumvention of technological measures only to the extent that such
circumvention is accomplished through the exercise of GPL rights in the
conveyed work. We have made two changes in the disclaimer of intention
regarding limitations on the design and use of the work. First, we make clear
that the referenced ``legal rights'' are specifically rights arising under
anticircumvention law. Second, we now refer to the conveying party's rights
in addition to third party rights, as in some cases the conveying party will
also be the party legally empowered to enforce or invoke rights arising under
anticircumvention law.
% FIXME: this needs rewritten
In section 3, which has been retitled as well as redrafted, we have
@ -2771,8 +2861,22 @@ 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: where should this go?
We improved the wording of this sentence to provide a clearer expression of
the intended policy. Under the 6d option, you may charge for the conveyed
object code. Those who pay to obtain the object code must be given equivalent
and gratis access to obtain the Corresponding Source. (If you convey the
object code to them gratis, you must likewise make the Corresponding Source
available to them without charge.) Those who do not obtain the object code
from you, perhaps because they choose not to pay the fee you charge, are
outside the scope of the provision; you need not give them any kind of access
to the Corresponding Source.
%FIXME: 6e, peer-to-peer
Informing the peers is clearly enough; what seemed to be an additional
knowledge requirement was superfluous wording.
% FIXME: Not final paragraph anymore.
@ -2835,6 +2939,112 @@ 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.
In brief, we condition the right to convey object code in a defined class of
``User Products,'' under certain circumstances, on providing whatever
information is required to enable a recipient to replace the object code with
a functioning modified version.
%FIXME: this really big section on user product stuff may be too much for the
% tutorial
In our earlier drafts, the requirement to provide encryption keys
applied to all acts of conveying object code, as this requirement was
part of the general definition of Corresponding Source. Section 6 of
Draft 3 now limits the applicability of the technical restrictions
provisions to object code conveyed in, with, or specifically for use in
a defined class of ``User Products.''
In our discussions with companies and governments that use specialized
or enterprise-level computer facilities, we found that sometimes these
organizations actually want their systems not to be under their own
control. Rather than agreeing to this as a concession, or bowing to
pressure, they ask for this as a preference. It is not clear that we
need to interfere, and the main problem lies elsewhere.
While imposing technical barriers to modification is wrong regardless of
circumstances, the areas where restricted devices are of the greatest
practical concern today fall within the User Product definition. Most,
if not all, technically-restricted devices running GPL-covered programs
are consumer electronics devices, and we expect that to remain true in
the near future. Moreover, the disparity in clout between the
manufacturers and these users makes it difficult for the users to reject
technical restrictions through their weak and unorganized market
power. Even if limited to User Products, as defined in Draft 3, the
provision still does the job that needs to be done. Therefore we have
decided to limit the technical restrictions provisions to User Products
in this draft.
The core of the User Product definition is a subdefinition of ``consumer
product'' taken verbatim from the Magnuson-Moss Warranty Act, a federal
consumer protection law in the United States: ``any tangible personal
property which is normally used for personal, family, or household
purposes.''\footnote{15 U.S.C.~\S\ 2301.} The United States has had
three decades of experience of liberal judicial and administrative
interpretation of this definition in a manner favorable to consumer
rights.\footnote{The Magnuson-Moss consumer product definition itself
has been influential in the United States and Canada, having been
adopted in several state and provincial consumer protection laws.} We
mean for this body of interpretation to guide interpretation of the
consumer product subdefinition in section 6, which will provide a degree
of legal certainty advantageous to device manufacturers and downstream
licensees alike. Our incorporation of such legal interpretation is in
no way intended to work a general choice of United States law for GPLv3
as a whole. The paragraph in section 6 defining ``User Product'' and
``consumer product'' contains an explicit statement to this effect,
bracketed for discussion. We will decide whether to retain this
statement in the license text after gathering comment on it.
One well-established interpretive principle under Magnuson-Moss is that
ambiguities are resolved in favor of coverage. That is, in cases where
it is not clear whether a product falls under the definition of consumer
product, the product will be treated as a consumer product.\footnote{16
C.F.R.~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54
U.C.C.~Rep.~Serv.2d 934 (D.~Ore.~2004).} Moreover, for a given product,
``normally used'' is understood to refer to the typical use of that type
of product, rather than a particular use by a particular buyer.
Products that are commonly used for personal as well as commercial
purposes are consumer products, even if the person invoking rights is a
commercial entity intending to use the product for commercial
purposes.\footnote{16 C.F.R. \S \ 700.1(a). Numerous court decisions
interpreting Magnuson-Moss are in accord; see, e.g., \textit{Stroebner
Motors, Inc.~v.~Automobili Lamborghini S.p.A.}, 459 F.~Supp.2d 1028,
1033 (D.~Hawaii 2006).} Even a small amount of ``normal'' personal use
is enough to cause an entire product line to be treated as a consumer
product under Magnuson-Moss.\footnote{\textit{Tandy Corp.~v.~Marymac
Industries, Inc.}, 213 U.S.P.Q.~702 (S.D.~Tex.~1981). In this case, the
court concluded that TRS-80 microcomputers were consumer products, where
such computers were designed and advertised for a variety of users,
including small businesses and schools, and had only recently been
promoted for use in the home.}
We do not rely solely on the definition of consumer product, however,
because in the area of components of dwellings we consider the settled
interpretation under Magnuson-Moss underinclusive. Depending on how
such components are manufactured or sold, they may or may not be
considered Magnuson-Moss consumer products.\footnote{Building materials
that are purchased directly by a consumer from a retailer, for improving
or modifying an existing dwelling, are consumer products under
Magnuson-Moss, but building materials that are integral component parts
of the structure of a dwelling at the time that the consumer buys the
dwelling are not consumer products. 16 C.F.R.~\S\S~700.1(c)--(f);
Federal Trade Commission, Final Action Concerning Review of
Interpretations of Magnuson-Moss Warranty Act, 64 Fed.~Reg.~19,700
(April 22, 1999); see also, e.g., \textit{McFadden}, 54
U.C.C.~Rep.~Serv.2d at 934.} Therefore, we define User Products as a
superset of consumer products that also includes ``anything designed or
sold for incorporation into a dwelling.''
Although the User Products rule of Draft 3 reflects a special concern
for individual purchasers of devices, we wrote the rule to cover a
category of products, rather than categorizing users. Discrimination
against organizational users has no place in a free software license.
Moreover, a rule that applied to individual use, rather than to use of
products normally used by individuals, would have too narrow an
effect. Because of its incorporation of the liberal Magnuson-Moss
interpretation of ``consumer product,'' the User Products rule benefits
not only individual purchasers of User Products but also all
organizational purchasers of those same kinds of products, regardless of
their intended use of the products.
%FIXME: This probably needs work to be brought into clarity with tutorial,
%next three paragarphs.
@ -2868,6 +3078,30 @@ all the hardware you own; the preamble explains, ``If such problems [as
to extend this provision to those domains in future versions of the GPL, as
needed to protect the freedom of users.''
The definition of Installation Information states that the information
provided ``must suffice to ensure that the continued functioning of the
modified object code is in no case prevented or interfered with solely
because modification has been made.'' We did not consider it necessary to
define ``continued functioning'' further. However, we believed it would be
appropriate to provide some additional guidance concerning the scope of
GPLv3-compliant action or inaction that distributors of
technically-restricted User Products can take with respect to a downstream
recipient who replaces the conveyed object code with a modified version. We
make clear that GPLv3 implies no obligation ``to continue to provide support
service, warranty, or updates'' for such a work.
Most technically-restricted User Products are designed to communicate across
networks. It is important for both users and network providers to know when
denial of network access to devices running modified versions becomes a GPL
violation. We settled on a rule that permits denial of access in two cases:
``when the modification itself materially and adversely affects the operation
of the network,'' and when the modification itself ``violates the rules and
protocols for communication across the network.'' The second case is
deliberately drawn in general terms. We intend it to serve as a foundation
for development of reasonable enforcement policies that respect recipients'
right to modify while recognizing the legitimate interests of network
providers.
% FIXME: This needs merged in somewhere in here
The mere fact that use of the work implies that the user \textit{has} the key
@ -2903,6 +3137,19 @@ put.\footnote{There is a clear distinction between this situation and the
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
@ -3193,6 +3440,36 @@ 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.
In Draft 3 the termination provision of section 8 has been revised to
indicate that, if a licensee violates the GPL, a contributor may terminate
any patent licenses that it granted under the first paragraph of section 11
to that licensee, in addition to any copyright permissions the contributor
granted to the licensee. Therefore, a contributor may terminate the patent
licenses it granted to a downstream licensee who brings patent infringement
litigation in violation of section 10.
We have made two substantive changes to section 8. First, we have clarified
that patent rights granted under the GPL are among the rights that a
copyright holder may terminate under section 8. Therefore, a contributor who
grants a patent license under the first paragraph of section 11 may terminate
that patent license, just as that contributor may terminate copyright rights,
to a downstream recipient who has violated the license. We think that this
is a reasonable result, and was already implicit in the wording of the
termination provision in our earlier drafts. Moreover, this clarification
should encourage patent holders to make contributions to GPL-covered
programs.
Second, we have modified the termination procedure by providing a limited
opportunity to cure license violations, an improvement that was requested by
many different members of our community. If a licensee has committed a
first-time violation of the GPL with respect to a given copyright holder, but
the licensee cures the violation within 30 days following receipt of notice
of the violation, then any of the licensee's GPL rights that have been
terminated by the copyright holder are ``automatically reinstated.'' The
addition of the cure opportunity achieves a better balance than our earlier
section 8 drafts between facilitating enforcement of the license and
protecting inadvertent violators against unfair results.
\section{GPLv3~\S9: Acceptance}
% FIXME: needs some work here
@ -3224,6 +3501,24 @@ 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.
Careful readers of the GPL have suggested that its explicit prohibition
against imposition of further restrictions\footnote{GPLv2, section 6; Draft
3, section 10, third paragraph.} has, or ought to have, implications for
those who assert patents against other licensees. Draft 2 took some steps to
clarify this point in a manner not specific to patents, by describing the
imposition of ``a license fee, royalty, or other charge'' for exercising GPL
rights as one example of an impermissible further restriction. In Draft 3 we
have clarified further that the requirement of non-imposition of further
restrictions has specific consequences for litigation accusing GPL-covered
programs of infringement. Section 10 now states that ``you may not initiate
litigation (including a cross-claim or counterclaim in a lawsuit) alleging
that any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program (or the contribution of any contributor).''
That is to say, a patent holder's licensed permissions to use a work under
GPLv3 may be terminated under section 8 if the patent holder files a lawsuit
alleging that use of the work, or of any upstream GPLv3-licensed work on
which the work is based, infringes a patent.
\section{GPLv3~\S11: Explicit Patent Licensing}
\label{GPLv3s11}
@ -3233,6 +3528,255 @@ 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.
Software patenting is a harmful and unjust policy, and should be abolished;
recent experience makes this all the more evident. Since many countries grant
patents that can apply to and prohibit software packages, in various guises
and to varying degrees, we seek to protect the users of GPL-covered programs
from those patents, while at the same time making it feasible for patent
holders to contribute to and distribute GPL-covered programs as long as they
do not attack the users of those programs.
It is generally understood that GPLv2 implies some limits on a licensee's
power to assert patent claims against the use of GPL-covered works.
Therefore, we have designed GPLv3 to reduce the patent risks that distort and
threaten the activities of users who make, run, modify and share free
software. At the same time, we have given due consideration to practical
goals such as certainty and administrability for patent holders that
participate in distribution and development of GPL-covered software. Our
policy requires each such patent holder to provide appropriate levels of
patent assurance to users, according to the nature of the patent holder's
relationship to the program.
Draft 3 features several significant changes concerning patents. We have
made improvements to earlier wording, clarified when patent assertion becomes
a prohibited restriction on GPL rights, and replaced a distribution-triggered
non-assertion covenant with a contribution-based patent license grant. We
have also added provisions to block collusion by patent holders with software
distributors that would extend patent licenses in a discriminatory way.
Draft 3 introduces the terms ``contributor'' and ``contribution,'' which are
used in the third paragraph of section 10 and the first paragraph of section
11, discussed successively in the following two subsections. Section 0
defines a contributor as ``a party who licenses under this License a work on
which the Program is based.'' That work is the ``contribution'' of that
contributor. In other words, each received GPLv3-covered work is associated
with one or more contributors, making up the finite set of upstream GPLv3
licensors for that work. Viewed from the perspective of a recipient of the
Program, contributors include all the copyright holders for the Program,
other than copyright holders of material originally licensed under non-GPL
terms and later incorporated into a GPL-covered work. The contributors are
therefore the initial GPLv3 licensors of the Program and all subsequent
upstream licensors who convey, under the terms of section 5, modified works
on which the Program is based.
For a contributor whose contribution is a modified work conveyed under
section 5, the contribution is ``the entire work, as a whole'' which the
contributor is required to license under GPLv3. The contribution therefore
includes not just the material added or altered by the contributor, but also
the pre-existing material the contributor copied from the upstream version
and retained in the modified version. Our usage of ``contributor'' and
``contribution'' should not be confused with the various other ways in which
those terms are used in certain other free software licenses.\footnote{Cf.,
e.g., Apache License, version 2.0, section 1; Eclipse Public License,
version 1.0, section 1; Mozilla Public License, version 1.1, section 1.1.}
The term ``patent license,'' as used in the third through fifth
paragraphs of section 11, is not meant to be confined to agreements
formally identified or classified as patent licenses. The new second
paragraph of section 11 makes this clear by defining ``patent license,''
for purposes of the subsequent three paragraphs, as ``a patent license,
a covenant not to bring suit for patent infringement, or any other
express agreement or commitment, however denominated, not to enforce a
patent.'' The definition does not include patent licenses that arise by
implication or operation of law, because the third through fifth
paragraphs of section 11 are specifically concerned with explicit
promises that purport to be legally enforceable.
Our previous drafts featured a patent license grant triggered by all
acts of distribution of GPLv3-covered works.\footnote{In Draft 2 we
rewrote the patent license as a covenant not to assert patent claims. We
explain why we reverted to the form of a patent license grant in \S\
\ref{cov}.} Many patent-holding companies objected to this policy. They
have made two objections: (1) the far-reaching impact of the patent
license grant on the patent holder is disproportionate to the act of
merely distributing code without modification or transformation, and (2)
it is unreasonable to expect an owner of vast patent assets to exercise
requisite diligence in reviewing all the GPL-covered software that it
provides to others. Some expressed particular concern about the
consequences of ``inadvertent'' distribution.
The argument that the impact of the patent license grant would be
``disproportionate,'' that is to say unfair, is not valid. Since
software patents are weapons that no one should have, and using them for
aggression against free software developers is an egregious act,
preventing that act cannot be unfair.
However, the second argument seems valid in a practical sense. A
typical GNU/Linux distribution includes thousands of programs. It would
be quite difficult for a redistributor with a large patent portfolio to
review all those programs against that portfolio every time it receives
and passes on a new version of the distribution. Moreover, this question
raises a strategic issue. If the GPLv3 patent license requirements
convince patent-holding companies to remain outside the distribution
path of all GPL-covered software, then these requirements, no matter how
strong, will cover few patents.
We concluded it would be more effective to make a partial concession
which would lead these companies to feel secure in doing the
distribution themselves, so that the conditions of section 10 would
apply to assertion of their patents. We therefore made the stricter
section 11 patent license apply only to those distributors that have
modified the program. The other changes we have made in sections 10 and
11 provide strengthened defenses against patent assertion and compensate
partly for this concession.
Therefore, in Draft 3, the first paragraph of section 11 states that a
contributor's patent license covers all the essential patent claims
implemented by the whole program as that contributor distributes it.
Contributors of modified works grant a patent license to claims that
read on ``the entire work, as a whole.'' This is the work that the
copyleft clause in section 5 requires the contributor to license under
GPLv3; it includes the material the contributor has copied from the
upstream version that the contributor has modified. The first paragraph
of section 11 does not apply to those that redistribute the program
without change.\footnote{An implied patent license from the distributor,
however, may arise by operation of law. See the final paragraph of
section 11. Moreover, distributors are subject to the limits on patent
assertion contained in the third paragraph of section 10.}
We hope that this decision will result in fairly frequent licensing of
patent claims by contributors. A contributor is charged with awareness
of the fact that it has modified a work and provided it to others; no
act of contribution should be treated as inadvertent. Our rule also
requires no more work, for a contributor, than the weaker rule proposed
by the patent holders. Under their rule, the contributor must always
compare the entire work against its patent portfolio to determine
whether the combination of the modifications with the remainder of the
work cause it to read on any of the contributor's patent claims.
We have made three changes to the definition of ``essential patent
claims'' in section 0. This definition now serves exclusively to
identify the set of patent claims licensed by a contributor under the
first paragraph of section 11.
First, we have clarified when essential patent claims include
sublicensable claims that have been licensed to the contributor by a
third party.\footnote{This issue is typically handled in other free
software licenses having patent licensing provisions by use of the
unhelpful term ``licensable,'' which is either left undefined or is
given an ambiguous definition.} Most commercial patent license
agreements that permit sublicensing do so under restrictive terms that
are inconsistent with the requirements of the GPL. For example, some
patent licenses allow the patent licensee to sublicense but require
collection of royalties from any sublicensees. The patent licensee
could not distribute a GPL-covered program and grant the recipient a
patent sublicense for the program without violating section 12 of
GPLv3.\footnote{Draft 3 provides a new example in section 12 that makes
this point clear.} In rare cases, however, a conveying party can freely
grant patent sublicenses to downstream recipients without violating the
GPL.
Draft 3 now defines essential patent claims, for a given party, as a
subset of the claims ``owned or controlled'' by the party. The
definition states that ``control includes the right to grant sublicenses
in a manner consistent with the requirements of this License.''
Therefore, in the case of a patent license that requires collection of
royalties from sublicensees, essential patent claims would not include
any claims sublicensable under that patent license, because sublicenses
to those claims could not be granted consistent with section 12.
Second, we now state that essential patent claims are those ``that would
be infringed by some manner, permitted by this License, of making,
using, or selling the work.'' This modified wording is intended to make
clear that a patent claim is ``essential'' if some mode of usage would
infringe that claim, even if there are other modes of usage that would
not infringe.
Third, we have clarified that essential patent claims ``do not include
claims that would be infringed only as a consequence of further
modification of the work.'' That is to say, the set of essential patent
claims licensed under the first paragraph of section 11 is fixed by the
the particular version of the work that was contributed. The claim set
cannot expand as a work is further modified downstream. (If it could,
then any software patent claim would be included, since any software
patent claim can be infringed by some further modification of the
work.)\footnote{However, ``the work'' should not be understood to be
restricted to a particular mechanical affixation of, or medium for
distributing, a program, where the same program might be provided in
other forms or in other ways that may be captured by other patent claims
held by the contributor.}
The downstream shielding provision of section 11 responds particularly
to the problem of exclusive deals between patent holders and
distributors, which threaten to distort the free software distribution
system in a manner adverse to developers and users. Draft 2 added a
source code availability option to this provision, as a specific
alternative to the general requirement to shield downstream users from
patent claims licensed to the distributor. A distributor conveying a
covered work knowingly relying on a patent license may comply with the
provision by ensuring that the Corresponding Source of the work is
publicly available, free of charge. We retained the shielding option in
Draft 2 because we did not wish to impose a general requirement to make
source code available to all, which has never been a GPL condition.
The addition of the source code availability option was supported by the
free software vendors most likely to be affected by the downstream
shielding provision. Enterprises that primarily use and occasionally
distribute free software, however, raised concerns regarding the
continued inclusion of a broadly-worded requirement to ``shield,'' which
appears to have been mistakenly read by those parties as creating an
obligation to indemnify. To satisfy these concerns, in Draft 3 we have
replaced the option to shield with two specific alternatives to the
source code availability option. The distributor may comply by
disclaiming the patent license it has been granted for the conveyed
work, or by arranging to extend the patent license to downstream
recipients.\footnote{The latter option, if chosen, must be done ``in a
manner consistent with the requirements of this License''; for example,
it is unavailable if extension of the patent license would result in a
violation of section 12. Cf.~the discussion of sublicensable patent
claims in \S\ \ref{epc}.} The GPL is intended to permit private
distribution as well as public distribution, and the addition of these
options ensures that this remains the case, even though we expect that
distributors in this situation will usually choose the source code
availability option.
Without altering its underlying logic, we have modified the phrasing of
the requirement to make clear that it is activated only if the
Corresponding Source is not already otherwise publicly available. (Most
often it will, in fact, already be available on some network server
operated by a third party.) Even if it is not already available, the
option to ``cause the Corresponding Source to be so available'' can then
be satisfied by verifying that a third party has acted to make it
available. That is to say, the affected distributor need not itself
host the Corresponding Source to take advantage of the source code
availability option. This subtlety may help the distributor avoid
certain peculiar assumptions of liability.
We have made two other changes to the downstream shielding provision.
The phrase ``knowingly rely'' was left undefined in our earlier drafts;
in Draft 3 we have provided a detailed definition. We have also deleted
the condition precedent, added in Draft 2, that the relied-upon patent
license be one that is non-sublicensable and ``not generally available
to all''; this was imprecise in Draft 2 and is unnecessary in Draft
3. In nearly all cases in which the ``knowingly relying'' test is met,
the patent license will indeed not be sublicensable or generally
available to all on free terms. If, on the other hand, the patent
license is generally available under terms consistent with the
requirements of the GPL, the distributor is automatically in compliance,
because the patent license has already been extended to all downstream
recipients. If the patent license is sublicensable on GPL-consistent
terms, the distributor may choose to grant sublicenses to downstream
recipients instead of causing source code to be publicly available. In
such a case, if the distributor is also a contributor, it will already
have granted a patent sublicense by operation of the first paragraph of
section 11,\footnote{See \S\ \ref{epc}.} and so it need not do anything
further to comply with the third paragraph.
% FIXME: This probably needs editing
One major goal for GPLv3 is to provide developers with additional protection
@ -3255,6 +3799,16 @@ 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.
The patent license grant of the first paragraph of section 11 no longer
applies to those who merely distribute works without modification. (We
explain why we made this change in the next subsection.) Such parties are
nonetheless subject to the conditions stated in section 10. Unlike the
patent license, which establishes a defense for downstream users lasting for
as long as they remain in compliance with the GPL, the commitment not to sue
that arises under section 10 is one that the distributor can end, so long as
the distributor also ceases to distribute. This is because a party who
initiates patent litigation in violation of section 10 risks termination of
its licensed permissions by the copyright holders of the work.
% FIXME: just brought in words here, needs rewriting.
@ -3342,6 +3896,20 @@ kinds of patent retaliation provisions that are broader than those of section
% FIXME: should we mention Microsoft-Novell at all?
Section 7 of GPLv2 (now section 12 of GPLv3) has seen some success in
deterring conduct that would otherwise result in denial of full downstream
enjoyment of GPL rights. Experience has shown us that more is necessary,
however, to ensure adequate community safety where companies act in concert
to heighten the anticompetitive use of patents that they hold or license.
Previous drafts of GPLv3 included a ``downstream shielding'' provision in
section 11, which we have further refined in Draft 3; it is now found in the
third paragraph of section 11. In addition, Draft 3 introduces two new
provisions in section 11, located in the fourth and fifth paragraphs, that
address the problem of collusive extension of patent forbearance promises
that discriminate against particular classes of users and against the
exercise of particular freedoms. This problem has been made more acute by the
recent Microsoft/Novell deal.
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
@ -3355,6 +3923,183 @@ 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.
A software patent forbids the use of a technique or algorithm, and its
existence is a threat to all software developers and users. A patent
holder can use a patent to suppress any program which implements the
patented technique, even if thousands of other techniques are
implemented together with it. Both free software and proprietary
software are threatened with death in this way.
However, patents threaten free software with a fate worse than death: a
patent holder might also try to use the patent to impose restrictions on
use or distribution of a free program, such as to make users feel they
must pay for permission to use it. This would effectively make it
proprietary software, exactly what the GPL is intended to prevent.
Novell and Microsoft have recently attempted a new way of using patents
against our community, which involves a narrow and discriminatory
promise by a patent holder not to sue customers of one particular
distributor of a GPL-covered program. Such deals threaten our community
in several ways, each of which may be regarded as de facto
proprietization of the software. If users are frightened into paying
that one distributor just to be safe from lawsuits, in effect they are
paying for permission to use the program. They effectively deny even
these customers the full and safe exercise of some of the freedoms
granted by the GPL. And they make disfavored free software developers
and distributors more vulnerable to attacks of patent aggression, by
dividing them from another part of our community, the commercial users
that might otherwise come to their defense.
We have added the fourth and fifth paragraphs of section 11 to combat
this threat. This subsection briefly describes the operation of the new
provisions. We follow it with a more detailed separate note on the
Microsoft/Novell patent deal, in which we provide an extensive rationale
for these measures.
As noted, one effect of the discriminatory patent promise is to divide
and isolate those who make free software from the commercial users to
whom the promise is extended. This deprives the noncommercial
developers of the communal defensive measures against patents made
possible by the support of those commercial users. The fourth paragraph
of section 11 operates to restore effective defenses to the targets of
patent aggression.
A patent holder becomes subject to the fourth paragraph of section 11
when it enters into a transaction or arrangement that involves two acts:
(1) conveying a GPLv3-covered work, and (2) offering to some, but not
all, of the work's eventual users a patent license for particular
activities using specific copies of the covered work. This paragraph
only operates when the two triggering acts are part of a single
arrangement, because the patent license is part of the arrangement for
conveying, which requires copyright permission. Under those conditions,
the discriminatory patent license is ``automatically extended to all
recipients of the covered work and works based on it.''
This provision establishes a defense to infringement allegations brought
by the patent holder against any users of the program who are not
covered by the discriminatory patent license. That is to say, it gives
all recipients the benefit of the patent promise that the patent holder
extended only to some. The effect is to make contributing discriminatory
promises of patent safety to a GPL distribution essentially like
contributing code. In both cases, the operation of the GPL extends
license permission to everyone that receives a copy of the program.
The fourth paragraph of section 11 gives users a defense against patent
aggression brought by the party who made the discriminatory patent
promise that excluded them. By contrast, the fifth paragraph stops free
software vendors from contracting with patent holders to make
discriminatory patent promises. In effect, the fifth paragraph extends
the principle of section 12 to situations involving collusion between a
patent holder and a distributor.
Under this provision, a distributor conveying a GPL-covered program may
not make an arrangement to get a discriminatory patent promise from a
third party for its customers, covering copies of the program (or
products that contain the program), if the arrangement requires the
distributor to make payment to the third party based on the extent of
its activity in conveying the program, and if the third party is itself
in the business of distributing software. Unlike the fourth paragraph,
which creates a legal defense for targets of patent aggression, the
consequence for violation of the fifth paragraph is termination of GPL
permissions for the distributor.
The business, technical, and patent cooperation agreement between
Microsoft and Novell announced in November 2006 has significantly
affected the development of Draft 3. The fourth and fifth paragraphs of
section 11 embody our response to the sort of threat represented by the
Microsoft/Novell deal, and are designed to protect users from such
deals, and prevent or deter the making of such deals.
The details of the agreements entered into between Microsoft and Novell,
though subject to eventual public disclosure through the securities
regulation system, have not been fully disclosed to this
point.\footnote{Lawyers employed by the Software Freedom Law Center,
which is counsel to the Free Software Foundation and other relevant free
software clients, were accorded limited access to the terms of the deal
under a non-disclosure agreement between SFLC and Novell. The reasons
for delay in the application of securities regulations requiring
publication of the relevant contracts are unrelated to the deal between
Microsoft and Novell.} It is a matter of public knowledge, however,
that the arrangement calls for Novell to pay a portion of the future
gross revenue of one of its divisions to Microsoft, and that (as one
other feature of a complex arrangement) Microsoft has promised Novell's
customers not to bring patent infringement actions against certain
specific copies of Novell's SUSE ``Linux''\footnote{This is a GNU/Linux
distribution, and is properly called SUSE GNU/Linux Enterprise Server.}
Enterprise Server product for which Novell receives revenue from the
user, so long as the user does not make or distribute additional copies
of SLES.
The basic harm that such an agreement can do is to make the free
software subject to it effectively proprietary. This result occurs to
the extent that users feel compelled, by the threat of the patent, to
get their copies in this way. So far, the Microsoft/Novell deal does
not seem to have had this result, or at least not very much: users do
not seem to be choosing Novell for this reason. But we cannot take for
granted that such threats will always fail to harm the community. We
take the threat seriously, and we have decided to act to block such
threats, and to reduce their potential to do harm. Such deals also
offer patent holders a crack through which to split the community.
Offering commercial users the chance to buy limited promises of patent
safety in effect invites each of them to make a separate peace with
patent aggressors, and abandon the rest of our community to its fate.
Microsoft has been restrained from patent aggression in the past by the
vocal opposition of its own enterprise customers, who now also use free
software systems to run critical applications. Public statements by
Microsoft concerning supposed imminent patent infringement actions have
spurred resistance from users Microsoft cannot afford to alienate. But
if Microsoft can gain royalties from commercial customers by assuring
them that \textit{their} copies of free software have patent licenses
through a deal between Microsoft and specific GNU/Linux vendors,
Microsoft would then be able to pressure each user individually, and
each distributor individually, to treat the software as proprietary. If
enough users succumb, it might eventually gain a position to terrify
noncommercial developers into abandoning the software entirely.
Preventing these harms is the goal of the new provisions of section 11.
The fourth paragraph deals with the most acute danger posed by
discrimination among customers, by ensuring that any party who
distributes others' GPL-covered programs, and makes promises of patent
safety limited to some but not all recipients of copies of those
specific programs, automatically extends its promises of patent safety
to cover all recipients of all copies of the covered works. This will
negate part of the harm of the Microsoft/Novell deal, for GPLv3-covered
software.
In addition to the present deal, however, GPLv3 must act to deter
similar future arrangements, and it cannot be assumed that all future
arrangements by Microsoft or other potential patent aggressors will
involve procuring the conveyance of the program by the party that grants
the discriminatory promises of patent safety. Therefore, we need the
fifth paragraph as well, which is aimed at parties that play the Novell
role in a different range of possible deals.
Drafting this paragraph was difficult because it is necessary to
distinguish between pernicious agreements and other kinds of agreements
which do not have an acutely harmful effect, such as patent
contributions, insurances, customary cross-license promises to
customers, promises incident to ordinary asset transfers, and standard
settlement practices. We believe that we have achieved this, but it is
hard to be sure, so we are considering making this paragraph apply only
to agreements signed in the future. If we do that, companies would only
need to structure future agreements in accord with the fifth paragraph,
and would not face problems from past agreements that cannot be changed
now. We are not yet convinced that this is necessary, and we plan to
ask for more comment on the question. This is why the date-based cutoff
is included in brackets.
One drawback of this cutoff date is that it would ``let Novell off''
from part of the response to its deal with Microsoft. However, this may
not be a great drawback, because the fourth paragraph will apply to that
deal. We believe it is sufficient to ensure either the deal's voluntary
modification by Microsoft or its reduction to comparative harmlessness.
Novell expected to gain commercial advantage from its patent deal with
Microsoft; the effects of the fourth paragraph in undoing the harm of
that deal will necessarily be visited upon Novell.
\section{GPLv3~\S12: Familiar as GPLv2 \S~7}
% FIXME: probably mostly still right, needs some updates, though.
@ -3376,7 +4121,95 @@ the final sentence of GPLv2 section 7, which we consider to be unnecessary.
\section{GPLv3~\S13: The Great Affero Compromise}
% FIXME
The main purpose of clause 7b4 was to attain GPLv3 compatibility for the
additional condition of version 1 of the Affero GPL, with a view to
achieving compatibility for a future version, since version 1 was
incompatible with GPLv3.\footnote{Version 1 of the Affero GPL contains
its own copyleft clause, worded identically to that in GPLv2, which
conflicts with the copyleft clause in GPLv3. The Affero GPL permits
relicensing under versions of the GPL later than version 2, but only if
the later version ``includes terms and conditions substantially
equivalent to those of this license'' (Affero GPL, version 1, section
9). The Affero license was written with the expectation that its
additional requirement would be incorporated into the terms of GPLv3
itself, rather than being placeable on parts added to a covered work
through the mechanism of section 7 of GPLv3.} However, we wrote the
clause broadly enough to cover a range of other possible terms that
would differ from the Affero condition in their details. Draft 3 no
longer pursues the more ambitious goal of allowing compatibility for a
whole category of Affero-like terms. In place of 7b4, we have added a
new section 13 that simply permits GPLv3-covered code to be linked with
code covered by the forthcoming version 2 of the Affero GPL.
We have made this decision in the face of irreconcilable views from
different parts of our community. While we had known that many
commercial users of free software were opposed to the inclusion of a
mandatory Affero-like requirement in the body of GPLv3 itself, we were
surprised at their opposition to its availability through section 7.
Free software vendors allied to these users joined in their objections,
as did a number of free software developers arguing on ethical as well
as practical grounds.
Some of this hostility seemed to be based on a misapprehension that
Affero-like terms placed on part of a covered work would somehow extend
to the whole of the work.\footnote{It is possible that the presence of
the GPLv2-derived copyleft clause in the existing Affero GPL contributed
to this misunderstanding.} Our explanations to the contrary did little
to satisfy these critics; their objections to 7b4 instead evolved into a
broader indictment of the additional requirements scheme of section 7.
It was clear, however, that much of the concern about 7b4 stemmed from
its general formulation. Many were alarmed at the prospect of GPLv3
compatibility for numerous Affero-like licensing conditions,
unpredictable in their details but potentially having significant
commercial consequences.
On the other hand, many developers, otherwise sympathetic to the policy
goals of the Affero GPL, have objected to the form of the additional
requirement in that license. These developers were generally
disappointed with our decision to allow Affero-like terms through
section 7, rather than adopt a condition for GPLv3. Echoing their
concerns about the Affero GPL itself, they found fault with the wording
of the section 7 clause in both of the earlier drafts. We drafted 7b4
at a higher level than its Draft 1 counterpart based in part on comments
from these developers. They considered the Draft 1 clause too closely
tied to the Affero mechanism of preserving functioning facilities for
downloading source, which they found too restrictive of the right of
modification. The 7b4 rewording did not satisfy them, however. They
objected to its limitation to terms requiring compliance by network
transmission of source, and to the technically imprecise or inaccurate
use of the phrase ``same network session.''
We have concluded that any redrafting of the 7b4 clause would fail to
satisfy the concerns of both sets of its critics. The first group
maintains that GPLv3 should do nothing about the problem of public
use. The second group would prefer for GPLv3 itself to have an
Affero-like condition, but that seems to us too drastic. By permitting
GPLv3-covered code to be linked with code covered by version 2 of the
Affero GPL, the new section 13 honors our original commitment to
achieving GPL compatibility for the Affero license.
Version 2 of the Affero GPL is not yet published. We will work with
Affero, Inc., and with all other interested members of our community, to
complete the drafting of this license following the release of Draft 3,
with a goal of having a final version available by the time of our
adoption of the final version of GPLv3. We hope the new Affero license
will satisfy those developers who are concerned about the issue of
public use of unconveyed versions but who have concerns about the
narrowness of the condition in the existing Affero license.
As the second sentence in section 13 indicates, when a combined work is
made by linking GPLv3-covered code with Affero-covered code, the
copyleft on one part will not extend to the other part.\footnote{The
plan is that the additional requirement of the new Affero license will
state a reciprocal limitation.} That is to say, in such combinations,
the Affero requirement will apply only to the part that was brought into
the combination under the Affero license. Those who receive such a
combination and do not wish to use code under the Affero requirement may
remove the Affero-covered portion of the combination.
Those who criticize the permission to link with code under the Affero
GPL should recognize that most other free software licenses also permit
such linking.
\section{GPLv3~\S14: So, When's GPLv4?}
\label{GPlv2s14}