Changeset - d2c59d90e9d6
[Not reviewed]
0 1 0
Bradley Kuhn (bkuhn) - 10 years ago 2014-03-20 12:53:35
bkuhn@ebb.org
Intro paragraph to new section explaining GPLv3's lock-down issue.
1 file changed with 15 insertions and 8 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -1809,1544 +1809,1551 @@ write her own GPLv2~\S3(b)-compliant source offer.
 
This process is precisely the reason why a GPLv2~\S3(b) source offer must be
 
valid for all third parties.  At the time the offer is made, there is no
 
way of knowing who might end up noncommercially receiving a copy of the
 
software.  Companies who choose to comply via GPLv2~\S3(b) must thus be
 
prepared to honor all incoming source code requests.  For this and the
 
many other additional necessary complications under GPLv2~\S\S3(b--c), it is
 
only rarely a better option than complying via GPLv2~\S3(a).
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{GPL's Implied Patent Grant}
 
\label{gpl-implied-patent-grant}
 

	
 
We digress again briefly from our section-by-section consideration of GPLv2
 
to consider the interaction between the terms of GPL and patent law. The
 
GPLv2, despite being silent with respect to patents, actually confers on its
 
licensees more rights to a licensor's patents than those licenses that
 
purport to address the issue. This is the case because patent law, under
 
the doctrine of implied license, gives to each distributee of a patented
 
article a license from the distributor to practice any patent claims owned
 
or held by the distributor that cover the distributed article. The
 
implied license also extends to any patent claims owned or held by the
 
distributor that cover ``reasonably contemplated uses'' of the patented
 
article. To quote the Federal Circuit Court of Appeals, the highest court
 
for patent cases other than the Supreme Court:
 

	
 
\begin{quotation}
 
Generally, when a seller sells a product without restriction, it in
 
effect promises the purchaser that in exchange for the price paid, it will
 
not interfere with the purchaser's full enjoyment of the product
 
purchased. The buyer has an implied license under any patents of the
 
seller that dominate the product or any uses of the product to which the
 
parties might reasonably contemplate the product will be put.
 
\end{quotation}
 
Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d
 
1445, 1451 (Fed. Cir. 1997).
 

	
 
Of course, Free Software is licensed, not sold, and there are indeed
 
restrictions placed on the licensee, but those differences are not likely
 
to prevent the application of the implied license doctrine to Free
 
Software, because software licensed under the GPL grants the licensee the
 
right to make, use, and sell the software, each of which are exclusive
 
rights of a patent holder. Therefore, although the GPLv2 does not expressly
 
grant the licensee the right to do those things under any patents the
 
licensor may have that cover the software or its reasonably contemplated
 
uses, by licensing the software under the GPLv2, the distributor impliedly
 
licenses those patents to the GPLv2 licensee with respect to the GPLv2'd
 
software.
 

	
 
An interesting issue regarding this implied patent license of GPLv2'd
 
software is what would be considered ``uses of the [software] to which
 
the parties might reasonably contemplate the product will be put.'' A
 
clever advocate may argue that the implied license granted by GPLv2 is
 
larger in scope than the express license in other Free Software
 
licenses with express patent grants, in that the patent license
 
clause of many of those other Free  Software licenses are specifically 
 
limited to the patent claims covered by the code as licensed by the patentee.
 

	
 
In contrast, a GPLv2 licensee, under the doctrine of implied patent license, 
 
is free to practice any patent claims held by the licensor that cover 
 
``reasonably contemplated uses'' of the GPL'd code, which may very well 
 
include creation and distribution of derivative works since the GPL's terms, 
 
under which the patented code is distributed, expressly permits such activity.
 

	
 

	
 
Further supporting this result is the Federal Circuit's pronouncement that
 
the recipient of a patented article has, not only an implied license to
 
make, use, and sell the article, but also an implied patent license to
 
repair the article to enable it to function properly, Bottom Line Mgmt.,
 
Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the
 
Federal Circuit extended that rule to include any future recipients of the
 
patented article, not just the direct recipient from the distributor.
 
This theory comports well with the idea of Free Software, whereby software
 
is distributed amongst many entities within the community for the purpose
 
of constant evolution and improvement. In this way, the law of implied
 
patent license used by the GPLv2 ensures that the community mutually
 
benefits from the licensing of patents to any single community member.
 

	
 

	
 

	
 
Note that simply because GPLv2'd software has an implied patent license does
 
not mean that any patents held by a distributor of GPLv2'd code become
 
worthless. To the contrary, the patents are still valid and enforceable
 
against either:
 

	
 
\begin{enumerate}
 
 \renewcommand{\theenumi}{\alph{enumi}}
 
 \renewcommand{\labelenumi}{\textup{(\theenumi)}}
 

	
 
\item any software other than that licensed under the GPLv2 by the patent
 
  holder, and
 

	
 
\item any party that does not comply with the GPLv2
 
with respect to the licensed software.
 
\end{enumerate}
 

	
 
\newcommand{\compB}{$\mathcal{B}$}
 
\newcommand{\compA}{$\mathcal{A}$}
 

	
 
For example, if Company \compA{} has a patent on advanced Web browsing, but
 
also licenses a Web browsing software program under the GPLv2, then it
 
cannot assert the patent against any party based on that party's use of 
 
Company \compA{}'s GPL'ed Web browsing software program, or on that party's
 
creation and use of derivative works of that GPL'ed program.  However, if a
 
party uses that program without
 
complying with the GPLv2, then Company \compA{} can assert both copyright
 
infringement claims against the non-GPLv2-compliant party and
 
infringement of the patent, because the implied patent license only
 
extends to use of the software in accordance with the GPLv2. Further, if
 
Company \compB{} distributes a competitive advanced Web browsing program 
 
that is not a derivative work of Company \compA{}'s GPL'ed Web browsing software
 
program, Company \compA{} is free to assert its patent against any user or
 
distributor of that product. It is irrelevant whether Company \compB's
 
program is also distributed under the GPLv2, as Company \compB{} can not grant
 
implied licenses to Company \compA's patent.
 

	
 
This result also reassures companies that they need not fear losing their
 
proprietary value in patents to competitors through the GPLv2 implied patent
 
license, as only those competitors who adopt and comply with the GPLv2's
 
terms can benefit from the implied patent license. To continue the
 
example above, Company \compB{} does not receive a free ride on Company
 
\compA's patent, as Company \compB{} has not licensed-in and then
 
redistributed Company A's advanced Web browser under the GPLv2. If Company
 
\compB{} does do that, however, Company \compA{} still has not lost
 
competitive advantage against Company \compB{}, as Company \compB{} must then,
 
when it re-distributes Company \compA's program, grant an implied license
 
to any of its patents that cover the program. Further, if Company \compB{}
 
relicenses an improved version of Company A's program, it must do so under
 
the GPLv2, meaning that any patents it holds that cover the improved version
 
are impliedly licensed to any licensee. As such, the only way Company
 
\compB{} can benefit from Company \compA's implied patent license, is if it,
 
itself, distributes Company \compA's software program and grants an
 
implied patent license to any of its patents that cover that program.
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{Defending Freedom on Many Fronts}
 

	
 
Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the
 
core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3.
 
GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are
 
not infringed, are enforceable, are kept to the confines of copyright law but
 
also  not trumped by other copyright agreements or components of other
 
entirely separate legal systems.  In short, while GPLv2~\S\S0--3 are the parts
 
of the license that defend the freedoms of users and programmers,
 
GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear
 
so that \S\S~0--3 can do their jobs.
 

	
 
\section{GPLv2~\S4: Termination on Violation}
 
\label{GPLv2s4}
 

	
 
GPLv2~\S4 is GPLv2's termination clause.  Upon first examination, it seems
 
strange that a license with the goal of defending users' and programmers'
 
freedoms for perpetuity in an irrevocable way would have such a clause.
 
However, upon further examination, the difference between irrevocability
 
and this termination clause becomes clear.
 

	
 
The GPL is irrevocable in the sense that once a copyright holder grants
 
rights for someone to copy, modify and redistribute the software under terms
 
of the GPL, they cannot later revoke that grant.  Since the GPL has no
 
provision allowing the copyright holder to take such a prerogative, the
 
license is granted as long as the copyright remains in effect.\footnote{In
 
  the USA, due to unfortunate legislation, the length of copyright is nearly
 
  perpetual, even though the Constitution forbids perpetual copyright.} The
 
copyright holders have the right to relicense the same work under different
 
licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to
 
stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used),
 
but they may not revoke the rights under GPLv2 already granted.
 

	
 
In fact, when an entity looses their right to copy, modify and distribute
 
GPL'd software, it is because of their \emph{own actions}, not that of the
 
copyright holder.  The copyright holder does not decided when GPLv2~\S4
 
termination occurs (if ever); rather, the actions of the licensee determine
 
that.
 

	
 
Under copyright law, the GPL has granted various rights and freedoms to
 
the licensee to perform specific types of copying, modification, and
 
redistribution.  By default, all other types of copying, modification, and
 
redistribution are prohibited.  GPLv2~\S4 says that if you undertake any of
 
those other types (e.g., redistributing binary-only in violation of GPLv2~\S3),
 
then all rights under the license --- even those otherwise permitted for
 
those who have not violated --- terminate automatically.
 

	
 
GPLv2~\S4 makes GPLv2 enforceable.  If licensees fail to adhere to the
 
license, then they are stuck without any permission under to engage in
 
activities covered by copyright law.  They must completely cease and desist
 
from all copying, modification and distribution of the GPL'd software.
 

	
 
At that point, violating licensees must gain the forgiveness of the copyright
 
holders to have their rights restored.  Alternatively, the violators could
 
negotiate another agreement, separate from GPL, with the copyright
 
holder.  Both are common practice, although
 
\tutorialpartsplit{as discussed in \textit{A Practical Guide to GPL
 
    Compliance}, there are }{Chapter~\ref{compliance-understanding-whos-enforcing}
 
  explains further } key differences between these two very different uses of GPL.
 

	
 
\section{GPLv2~\S5: Acceptance, Copyright Style}
 
\label{GPLv2s5}
 

	
 
GPLv2~\S5 brings us to perhaps the most fundamental misconception and common
 
confusion about GPLv2\@. Because of the prevalence of proprietary software,
 
most users, programmers, and lawyers alike tend to be more familiar with
 
EULAs. EULAs are believed by their authors to be contracts, requiring
 
formal agreement between the licensee and the software distributor to be
 
valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap''
 
as mechanisms to perform acceptance ceremonies with EULAs.
 

	
 
The GPL does not need contract law to ``transfer rights.''  Usually, no rights
 
are transfered between parties.  By contrast, the GPL is primarily a permission
 
slip to undertake activities that would otherwise have been prohibited
 
by copyright law.  As such, GPL needs no acceptance ceremony; the
 
licensee is not even required to accept the license.
 

	
 
However, without the GPL, the activities of copying, modifying and
 
distributing the software would have otherwise been prohibited.  So, the
 
GPL says that you only accepted the license by undertaking activities that
 
you would have otherwise been prohibited without your license under GPL\@.
 
This is a certainly subtle point, and requires a mindset quite different
 
from the contractual approach taken by EULA authors.
 

	
 
An interesting side benefit to GPLv2~\S5 is that the bulk of users of Free
 
Software are not required to accept the license.  Undertaking fair and
 
unregulated use of the work, for example, does not bind you to the GPL,
 
since you are not engaging in activity that is otherwise controlled by
 
copyright law.  Only when you engage in those activities that might have an
 
impact on the freedom of others does license acceptance occur, and the
 
terms begin to bind you to fair and equitable sharing of the software.  In
 
other words, the GPL only kicks in when it needs to for the sake of
 
freedom.
 

	
 
While GPL is by default a copyright license, it is certainly still possible
 
to consider GPL as a contract as well.  For example, some distributors chose
 
to ``wrap'' their software in an acceptance ceremony to GPL, and nothing in
 
GPL prohibits that use.  Furthermore, the ruling in \textit{Jacobsen
 
  v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008)} indicates that \textbf{both}
 
copyright and contractual remedies may be sought by a copyright holder
 
seeking to enforce a license designed to uphold software freedom.
 

	
 
\section{Using GPL Both as a Contract and Copyright License}
 

	
 
\section{GPLv2~\S6: GPL, My One and Only}
 
\label{GPLv2s6}
 

	
 
A point that was glossed over in Section~\ref{GPLv2s4}'s discussion of GPLv2~\S4
 
was the irrevocable nature of the GPL\@. The GPLv2 is indeed irrevocable,
 
and it is made so formally by GPLv2~\S6.
 

	
 
The first sentence in GPLv2~\S6 ensures that as software propagates down the
 
distribution chain, that each licensor can pass along the license to each
 
new licensee.  Under GPLv2~\S6, the act of distributing automatically grants a
 
license from the original licensor to the next recipient.  This creates a
 
chain of grants that ensure that everyone in the distribution has rights
 
under the GPLv2\@.  In a mathematical sense, this bounds the bottom ---
 
making sure that future licensees get no fewer rights than the licensee before.
 

	
 
The second sentence of GPLv2~\S6 does the opposite; it bounds from the top.  It
 
prohibits any licensor along the distribution chain from placing
 
additional restrictions on the user.  In other words, no additional
 
requirements may trump the rights and freedoms given by GPLv2\@.
 

	
 
The final sentence of GPLv2~\S6 makes it abundantly clear that no individual
 
entity in the distribution chain is responsible for the compliance of any
 
other.  This is particularly important for noncommercial users who have
 
passed along a source offer under GPLv2~\S3(c), as they cannot be assured that
 
the issuer of the offer will honor their GPLv2~\S3 obligations.
 

	
 
In short, GPLv2~\S6 says that your license for the software is your one and
 
only copyright license allowing you to copy, modify and distribute the
 
software.
 

	
 
\section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''}
 
\label{GPLv2s7}
 

	
 
In essence, GPLv2~\S7 is a verbosely worded way of saying for non-copyright
 
systems what GPLv2~\S6 says for copyright.  If there exists any reason that a
 
distributor knows of that would prohibit later licensees from exercising
 
their full rights under GPL, then distribution is prohibited.
 

	
 
Originally, this was designed as the title of this section suggests --- as
 
a last ditch effort to make sure that freedom was upheld.  However, in
 
modern times, it has come to give much more.  Now that the body of GPL'd
 
software is so large, patent holders who would want to be distributors of
 
GPL'd software have a tough choice.  They must choose between avoiding
 
distribution of GPL'd software that exercises the teachings of their
 
patents, or grant a royalty-free, irrevocable, non-exclusive license to
 
those patents.  Many companies have chosen the latter.
 

	
 
Thus, GPLv2~\S7 rarely gives software death by stopping its distribution.
 
Instead, it is inspiring patent holders to share their patents in the same
 
freedom-defending way that they share their copyrighted works.
 

	
 
\section{GPLv2~\S8: Excluding Problematic Jurisdictions}
 
\label{GPLv2s8}
 

	
 
GPLv2~\S8 is rarely used by copyright holders.  Its intention is that if a
 
particular country, say Unfreedonia, grants particular patents or allows
 
copyrighted interfaces (no country to our knowledge even permits those
 
yet), that the GPLv2'd software can continue in free and unabated
 
distribution in the countries where such controls do not exist.
 

	
 
As far as is currently known, GPLv2~\S8 has very rarely been formally used by
 
copyright holders.  Admittedly, some have used GPLv2~\S8 to explain various
 
odd special topics of distribution (usually related in some way to
 
GPLv2~\S7).  However, generally speaking, this section is not proven
 
particularly useful in the more than two decades of GPLv2 history.
 

	
 
Meanwhile, despite many calls by the FSF (and others) for those licensors who
 
explicitly use this section to come forward and explain their reasoning, no
 
one ever did.  Furthermore, research conducted during the GPLv3 drafting
 
process found exactly one licensor who had invoked this section to add an
 
explicit geographical distribution limitation, and the reasoning for that one
 
invocation was not fitting with FSF's intended spirit of GPLv2~\S8.  As such,
 
GPLv2~\S8 was not included at all in GPLv3.
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{Odds, Ends, and Absolutely No Warranty}
 

	
 
GPLv2~\S\S0--7 constitute the freedom-defending terms of the GPLv2.  The remainder
 
of the GPLv2 handles administrivia and issues concerning warranties and
 
liability.
 

	
 
\section{GPLv2~\S9: FSF as Stewards of GPL}
 
\label{GPLv2s9}
 

	
 
FSF reserves the exclusive right to publish future versions of the GPL\@;
 
GPLv2~\S9 expresses this.  While the stewardship of the copyrights on the body
 
of GPL'd software around the world is shared among thousands of
 
individuals and organizations, the license itself needs a single steward.
 
Forking of the code is often regrettable but basically innocuous.  Forking
 
of licensing is disastrous.
 

	
 
(Chapter~\ref{tale-of-two-copylefts} discusses more about the various
 
versions of GPL.)
 

	
 
\section{GPLv2~\S10: Relicensing Permitted}
 
\label{GPLv2s10}
 

	
 
GPLv2~\S10 reminds the licensee of what is already implied by the nature of
 
copyright law.  Namely, the copyright holder of a particular software
 
program has the prerogative to grant alternative agreements under separate
 
copyright licenses.
 

	
 
\section{GPLv2~\S11: No Warranty}
 
\label{GPLv2s11}
 

	
 
Most warranty disclaimer language shout at you.  The
 
\href{http://www.law.cornell.edu/ucc/2/2-316}{Uniform Commercial
 
  Code~\S2-316} requires that disclaimers of warranty be ``conspicuous''.
 
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.
 

	
 
That said, there is admittedly some authority under USA law suggesting that
 
effective warranty disclaimers 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)).  While GPLv3's drafters doubted that such authority would
 
apply to copyright licenses like the GPL, the FSF has nevertheless left
 
warranty and related disclaimers in \textsc{all caps} throughout all versions
 
of GPL\@\footnote{One of the authors of this tutorial, Bradley M.~Kuhn, has
 
  often suggested the aesthetically preferable compromise of a
 
  \textsc{specifically designed ``small caps'' font, such as this one, as an
 
    alternative to} WRITING IN ALL CAPS IN THE DEFAULT FONT (LIKE THIS),
 
  since the latter adds more ugliness than conspicuousness.  Kuhn once
 
  engaged in reversion war with a lawyer who disagreed, but that lawyer never
 
  answered Kuhn's requests for case law that argues THIS IS INHERENTLY MORE
 
  CONSPICUOUS \textsc{Than this is}.}.
 

	
 
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
 
interpreted only as broadly as allowed by applicable law.  Such a
 
provision ensures that both it, and the entire GPL, is enforceable in any
 
jurisdiction, regardless of any particular law regarding the
 
permissibility of certain warranty disclaimers.
 

	
 
Finally, one important point to remember when reading GPLv2~\S11 is that GPLv2~\S1
 
permits the sale of warranty as an additional service, which GPLv2~\S11 affirms.
 

	
 
\section{GPLv2~\S12: Limitation of Liability}
 
\label{GPLv2s12}
 

	
 
There are many types of warranties, and in some jurisdictions some of them
 
cannot be disclaimed.  Therefore, usually agreements will have both a
 
warranty disclaimer and a limitation of liability, as we have in GPLv2~\S12.
 
GPLv2~\S11 thus gets rid of all implied warranties that can legally be
 
disavowed. GPLv2~\S12, in turn, limits the liability of the actor for any
 
warranties that cannot legally be disclaimed in a particular jurisdiction.
 

	
 
Again, some have argued the GPL is unenforceable in some jurisdictions
 
because its limitation of liability is impermissibly broad. However, \S
 
12, just like its sister, GPLv2~\S11, contains a jurisdictional savings
 
provision, which states that it is to be interpreted only as broadly as
 
allowed by applicable law.  As stated above, such a provision ensures that
 
both GPLv2~\S12, and the entire GPL, is enforceable in any jurisdiction,
 
regardless of any particular law regarding the permissibility of limiting
 
liability.
 

	
 
So end the terms and conditions of the GNU General Public License.
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{GPLv3}
 
\label{GPLv3}
 

	
 
This chapter discussed the text of GPLv3.  Much of this material herein
 
includes text that was adapted (with permission) from text that FSF
 
originally published as part of the so-called ``rationale documents'' for the
 
various discussion drafts of GPLv3.
 

	
 
The FSF ran a somewhat public process to develop GPLv3, and it was the first
 
attempt of its kind to develop a Free Software license this way.  Ultimately,
 
RMS was the primary author of GPLv3, but he listened to feedback from all
 
sorts of individuals and even for-profit companies.  Nevertheless, in
 
attempting to understand GPLv3 after the fact, the materials available from
 
the GPLv3 process have a somewhat ``drinking from the firehose'' effect.
 
This chapter seeks to explain GPLv3 to newcomers, who perhaps are familiar
 
with GPLv2 and who did not participate in the GPLv3 process.
 

	
 
Those who wish to drink from the firehose and take a diachronic approach to
 
GPLv3 study by reading the step-by-step public drafting process GPLv3 (which
 
occurred from Monday 16 January 2006 through Monday 19 November 2007) should
 
visit \url{http://gplv3.fsf.org/}.
 

	
 
\section{Understanding GPLv3 As An Upgraded GPLv2}
 

	
 
Ultimately, GPLv2 and GPLv3 co-exist as active licenses in regular use.  As
 
discussed in Chapter\~ref{tale-of-two-copylefts}, GPLv1 was never regularly
 
used alongside GPLv2.  However, given GPLv2's widespread popularity and
 
existing longevity by the time GPLv3 was published, it is not surprising that
 
some licensors still prefer GPLv2-only or GPLv2-or-later.  GPLv3 gained major
 
adoption by many projects, old and new, but many projects have not upgraded
 
due to (in some cases) mere laziness and (in other cases) policy preference
 
for some of GPLv2's terms and/or policy opposition to GPLv3's terms.
 

	
 
Given this ``two GPLs world'' is reality, it makes sense to consider GPLv3 in
 
terms of how it differs from GPLv2.  Also, most of the best GPL experts in
 
the world must deal regularly with both licenses, and admittedly have decades
 
of experience of GPLv2 while the most experience with GPLv3 that's possible
 
is by default less than a decade.  These two factors usually cause even new
 
students of GPL to start with GPLv2 and move on to GPLv3, and this tutorial
 
follows that pattern.
 

	
 
Overall, the changes made in GPLv3 admittedly \textit{increased} the
 
complexity of the license.  The FSF stated at the start of the GPLv3 process
 
that they would have liked to oblige those who have asked for a simpler and
 
shorter GPL\@.  Ultimately, the FSF gave priority to making GPLv3 a better
 
copyleft in the spirit of past GPL's.  Obsession for concision should never
 
trump software freedom.
 

	
 
The FSF had many different, important goals in seeking to upgrade to GPLv3.
 
However, one important goal that is often lost in the discussion of policy
 
minutia is a rather simple but important issue.  Namely, FSF sought to assure
 
that GPLv3 was more easily internationalized than GPLv2.  In particular, the
 
FSF sought to ease interpretation of GPL in other countries by replacement of
 
USA-centric\footnote{See Section~\ref{non-usa-copyright} of this tutorial for
 
  a brief discussion about non-USA copyright systems.}  copyright phrases and
 
wording with neutral terminology rooted in description of behavior rather
 
than specific statue.  As can be seen in the section-by-section discussion of
 
GPLv3 that follows, nearly every section had changes related to issues of
 
internationalization.
 
 
 
\section{GPLv3~\S0: Giving In On ``Defined Terms''}
 

	
 
One of lawyers' most common complaints about GPLv2 is that defined terms in
 
the document appear throughout.  Most licenses define terms up-front.
 
However, GPL was always designed both as a document that should be easily
 
understood both by lawyers and by software developers: it is a document
 
designed to give freedom to software developers and users, and therefore it
 
should be comprehensible to that constituency.
 

	
 
Interestingly enough, one coauthor of this tutorial who is both a lawyer and
 
a developer pointed out that in law school, she understood defined terms more
 
quickly than other law students precisely because of her programming
 
background.  For developers, having \verb0#define0 (in the C programming
 
language) or other types of constants and/or macros that automatically expand
 
in the place where they are used is second nature.  As such, adding a defined
 
terms section was not terribly problematic for developers, and thus GPLv3
 
adds one.  Most of these defined terms are somewhat straightforward and bring
 
forward better worded definitions from GPLv2.  Herein, this tutorial
 
discusses a few of the new ones.
 

	
 
GPLv3~\S0 includes definitions of five new terms not found in any form in
 
GPLv2: ``modify'' ``covered work'', ``propagate'', ``convey'', and
 
``Appropriate Legal Notices''. 
 

	
 
\subsection{Modify and the Work Based on the Program}
 

	
 
GPLv2 included a defined term, ``work based on the Program'', but also used
 
the term ``modify'' and ``based on'' throughout the license.  GPLv2's ``work
 
based on the Program'' definition made use of a legal term of art,
 
``derivative work'', which is peculiar to USA copyright law.  However,
 
ironically, the most criticism of USA-specific legal terminology in GPLv2's
 
``work based on the Program'' definition historically came not primarily from
 
readers outside the USA, but from those within it\footnote{The FSF noted in
 
  that it did not generally agree with these views, and expressed puzzlement
 
  by the energy with which they were expressed, given the existence of many
 
  other, more difficult legal issues implicated by the GPL.  Nevertheless,
 
  the FSF argued that it made sense to eliminate usage of local copyright
 
  terminology to good effect.}.  Admittedly, even though differently-labeled
 
concepts corresponding to the derivative work are recognized in all copyright
 
law systems, these counterpart concepts might differ to some degree in scope
 
and breadth from the USA derivative work.
 

	
 
The goal and intention of GPLv2 was always to cover all rights governed by
 
relevant copyright law, in the USA and elsewhere.  GPLv3 therefore takes the
 
task of internationalizing the license further by removing references to
 
derivative works and by providing a more globally useful definition.  The new
 
definition returns to the common elements of copyright law.  Copyright
 
holders of works of software have the exclusive right to form new works by
 
modification of the original --- a right that may be expressed in various
 
ways in different legal systems.  GPLv3 operates to grant this right to
 
successive generations of users (particularly through the copyleft conditions
 
set forth in GPLv3~\S5, as described later in this tutorial in its
 
\S~\ref{GPLv3s5}).  Here in GPLv3~\S0, ``modify'' refers to basic copyright
 
rights, and then this definition of ``modify'' is used to define ``modified
 
version of'' and ``work based on,'' as synonyms.
 

	
 
\section{The Covered Work}
 

	
 
GPLv3 uses a common license drafting technique of building upon simpler
 
definitions to make complex ones.  The Program is a defined term found
 
throughout GPLv2, and the word ``covered'' and the phrase ``covered by this
 
license'' are used in tandem with the Program in GPLv2, but not as part of a
 
definition.  GPLv3 offers a single term ``covered work'', which enables some
 
of the wording in GPLv3 to be simpler and clearer than its GPLv2
 
counterparts.
 

	
 
\section{Propagate}
 

	
 
The term ``propagate'' serves two purposes.  First, ``propagate'' provides a
 
simple and convenient means for distinguishing between the kinds of uses of a
 
work that GPL imposes conditions on and the kinds of uses that GPL does not
 
(for the most part) impose conditions on.
 

	
 
Second, ``propagate'' helps globalize GPL in its wording and effect.  When a
 
work is GPL'd, the copyright law of some particular country will govern
 
certain legal issues arising under the license.  A term like ``distribute''
 
(or its equivalent in languages other than English) is used in several
 
national copyright statutes.  Yet, practical experience with GPLv2 revealed
 
the awkwardness of using the term ``distribution'' in a license intended for
 
global use: the scope of ``distribution'' in the copyright context can differ
 
from country to country.  The GPL never necessarily intended the specific
 
meaning of ``distribution'' that exists under USA (or any other country's)
 
copyright law.
 

	
 
Indeed, even within a single country and language, the term distribution may
 
be ambiguous; as a legal term of art, distribution varies significantly in
 
meaning among those countries that recognize it.  For example, comments
 
during GPLv3's drafting process indicated that in at least one country,
 
distribution may not include network transfers of software but may include
 
interdepartmental transfers of physical copies within an organization.
 
Meanwhile, the copyright laws of many countries, as well as certain
 
international copyright treaties, recognize ``making available to the
 
public'' or ``communication to the public'' as one of the exclusive rights of
 
copyright holders.
 

	
 
Therefore, the GPL defines the term ``propagate'' by reference to activities
 
that require permission under ``applicable copyright law'', but excludes
 
execution and private modification from the definition.  GPLv3's definition
 
also gives examples of activities that may be included within ``propagation''
 
but it also makes clear that, under the copyright laws of a given country,
 
``propagation'' may include other activities as well.
 

	
 
Thus, propagation is defined by behavior, and not by categories drawn from
 
some particular national copyright statute.  This helps not only with
 
internationalization, but also factually-based terminology aids in
 
developers' and users' understanding of GPL\@.
 

	
 
\section{Convey}
 

	
 
Further to this point, a subset of propagate --- ``convey'' --- is defined.
 
Conveying includes activities that constitute propagation of copies to
 
others.  As with the definition of propagate, GPLv3 thus addresses transfers
 
of copies of software in behavioral rather than statutory terms.  
 

	
 
\section{Appropriate Legal Notices}
 

	
 
GPLv2 used the term ``appropriate copyright notice and disclaimer of
 
warranty'' in two places, which is a rather bulk term.  Also, experience with
 
GPLv2 and other licenses that grant software freedom showed throughout the
 
1990s that the scope of types of notices that need preservation upon
 
conveyance were more broad that merely the copyright notices.  The
 
Appropriate Legal Notice definition consolidates the material that GPLv2
 
traditionally required preserved into one definition.
 

	
 
\section{Other Defined Terms}
 

	
 
Note finally that not all defined terms in GPLv3 appear in GPLv3~\S0.
 
Specifically, those defined terms that are confined in use to a single
 
section are defined in the section in which they are used, and GPLv3~\S1
 
contains those definitions focused on source code.  In this tutorial, those
 
defined terms are discussed in the section where they are defined and/or
 
used.
 

	
 
\section{GPLv3~\S1: Understanding CCS}
 

	
 
Ensuring that users have the source code to the software they receive and the
 
freedom to modify remains the paramount right embodied in the Free Software
 
Definition (found in \S~\ref{Free Software Definition} of this tutorial).  As
 
such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it
 
contains all the defined terms related to this important software freedom.
 

	
 
\subsection{Source Code Definition}
 

	
 
First, GPLv3\~S1 retains GPLv2's definition of ``source code'' and adds an
 
explicit definition of ``object code'' as ``any non-source version of a
 
work''.  Object code is not restricted to a narrow technical meaning and is
 
understood broadly to include any form of the work other than the preferred
 
form for making modifications to it.  Object code therefore includes any kind
 
of transformed version of source code, such as bytecode or minified
 
Javascript.  The definition of object code also ensures that licensees cannot
 
escape their obligations under the GPL by resorting to shrouded source or
 
obfuscated programming.
 

	
 
\subsection{CCS Definition}
 

	
 
The definition of CCS\footnote{Note that the preferred term for those who
 
  work regularly with both GPLv2 and GPLv3 is ``Complete Corresponding
 
  Source'', abbreviated to ``CCS''.  Admittedly, the word ``complete'' no
 
  longer appears in GPLv3 (which uses the word ``all'' instead).  However,
 
  both GPLv2 and the early drafts of GPLv3 itself used the word ``complete'',
 
  and early GPLv3 drafts even called this defined term ``Complete
 
  Corresponding Source''.  Meanwhile, use of the acronym ``CCS'' (sometimes,
 
  ``C\&CS'') was so widespread among GPL enforcers that its use continues
 
  even though GPLv3-focused experts tend to say just the defined term of
 
  ``Corresponding Source''.}, or, as GPLv3 officially calls it,
 
``Corresponding Source'' in GPLv3~\S1\P4 is possibly the most complex
 
definition in the license.
 

	
 
The CCS definition is broad so as to protect users' exercise of their rights
 
under the GPL\@.  The definition includes with particular examples to remove
 
any doubt that they are to be considered CCS\@.  GPLv3 seeks to make it
 
completely clear that a licensee cannot avoid complying with the requirements
 
of the GPL by dynamically linking a subprogram component to the original
 
version of a program.  The example also clarifies that the shared libraries
 
and dynamically linked subprograms that are included in Corresponding Source
 
are those that the work is ``specifically'' designed to require, which
 
clarifies that they do not include libraries invoked by the work that can be
 
readily substituted by other existing implementations.  While copyleft
 
advocates never doubted this was required under GPLv2's definition of CCS,
 
making it abundantly clear with an extra example.
 

	
 
GPL, as always, seeks to ensure users are truly in a position to install and
 
run their modified versions of the program; the CCS definition is designed to
 
be expansive to ensure this software freedom.  However, although the
 
definition of CCS 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 be locked-down and restricted.  The
 
requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this
 
tutorial) handle that issue.  (Early drafts of GPLv3 included those
 
requirements in the definition of CCS; however, given that the lock-down
 
issue only comes up in distribution of object code, it is more logical to
 
place those requirements with the parts of GPLv3 dealing directly with object
 
code distribution).
 

	
 
The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does
 
not require source that can be automatically generated.  Many code
 
generators, preprocessors and take source code as input and sometimes even
 
have output that is still source code.  Source code should always be whatever
 
the original programmer preferred to modify.
 

	
 
GPLv3\S1's final paragraph removes any ambiguity about what should be done on
 
source-only distributions.  Specifically, the right to convey source code
 
that does not compile, does not work, or otherwise is experimental
 
in-progress work is fully permitted, \textit{provided that} no object code
 
form is conveyed as well.  Indeed, when combined with the permissions in
 
GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can
 
never be required to provide more than that.  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{The System Library Exception}
 

	
 
The previous section skipped over one part of the CCS definition, the
 
so-called system library exception.  The ``System Libraries'' definition (and
 
the ``Standard Interface'' and ``Major Component'' definitions, which it
 
includes) are designed as part
 

	
 
to permit certain distribution arrangements that are considered reasonable by
 
copyleft advocates.  The system library exception is designed to allow
 
copylefted software to link with these libraries when such linking would hurt
 
software freedom more than it would hurt proprietary software.
 

	
 
The system library exception has two parts.  Part (a) rewords the GPLv2
 
exception for clarity replaces GPLv2's words ``unless that component itself
 
accompanies the executable'' with ``which is not part of the Major
 
Component''.  The goal here is to not require disclosure of source code of
 
certain libraries, such as necessary Microsoft Windows DLLs (which aren't
 
part of Windows' kernel but accompany it) that are required for functioning
 
of copylefted programs compiled for Windows.
 

	
 
However, in isolation, (a) would be too permissive, as it would sometimes
 
allowing distributors to evade important GPL requirements.  Part (b) reigns
 
in (a).  Specifically, (b) specifies only a few functionalities that a the
 
system library may provide and still qualify for the exception.  The goal is
 
to ensure system libraries are truly adjunct to a major essential operating
 
system component, compiler, or interpreter.  The more low-level the
 
functionality provided by the library, the more likely it is to be qualified
 
for this exception.
 

	
 
Admittedly, the system library exception is a frequently discussed topic of
 
obsessed GPL theorists.  The amount that has been written on the system
 
library exception (both the GPLv2 and GPLv3 versions of it), if included
 
herein,  could easily increase this section of the tutorial to a length
 
greater than all the others.
 

	
 
Like any exception to the copyleft requirements of GPL, would-be GPL
 
violators frequently look to the system library exception as a potential
 
software freedom circumvention technique.  When considering whether or not a
 
library qualifies for the system library exception, here is a pragmatic
 
thesis to consider, based on the combined decades of experience in GPL
 
interpretation of this tutorial's authors: the harder and more strained the
 
reader must study and read the system library exception, the more likely it
 
is that the library in question does not qualify for it.
 

	
 
\section{GPLv3~\S2: Basic Permissions}
 

	
 
GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed
 
in \S~\ref{GPLv2sS0} of this tutorial).  However, the usual style of
 
improvements found in GPLv3 are found here as well.  For example, the first
 
sentence of GPLv3~\S2 furthers the goal internationalization.  Under the
 
copyright laws of some countries, it may be necessary for a copyright license
 
to include an explicit provision setting forth the duration of the rights
 
being granted. In other countries, including the USA, such a provision is
 
unnecessary but permissible.
 

	
 
GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of
 
copyright fair use, or the equivalent under applicable law.  These rights are
 
compatible with, and not in conflict with, the freedoms that the GPL seeks to
 
protect, and the GPL cannot and should not restrict them.
 

	
 
However, note that (sadly to some copyleft advocates) the unlimited freedom
 
to run is confined to the \textit{unmodified} Program.  This confinement is
 
unfortunately necessary since Programs that do not qualify as a User Product
 
in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain
 
unfortunate restrictions on the freedom to run\footnote{See
 
  \S~ref{freedom-to-run} of this tutorial for the details on ``the freedom to
 
  run''.}
 

	
 
GPLv3~\S2\P2 distinguishes between activities of a licensee that are
 
permitted without limitation and activities that trigger additional
 
requirements.  Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of
 
privately modifying and running the program.
 

	
 
Also, GPLv3~\S2\P2 gives an explicit permission for a client to provide a
 
copy of its modified software to a contractor exclusively for that contractor
 
to modify it further, or run it, on behalf of the client.  However, the
 
client can \textit{only} exercise this control over its own copyrighted
 
changes to the GPL-covered program.  The parts of the program it obtained
 
from other contributors must be provided to the contractor with the usual GPL
 
freedoms.  Thus, GPLv3 permits users to convey covered works to contractors
 
operating exclusively on the users' behalf, under the users' direction and
 
control, and to require the contractors to keep the users' copyrighted
 
changes confidential, but \textit{only if} the contractor is limited to acting
 
on the users' behalf (just as the users' employees would have to act).
 

	
 
The strict conditions in this ``contractors provision'' are needed so that it
 
cannot be twisted to fit other activities, such as making a program available
 
to downstream users or customers.  By making the limits on this provision
 
very narrow, GPLv3 ensures that, in all other cases, contractors gets the
 
full freedoms of the GPL that they deserve.
 

	
 
GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing.
 
This provision ensures that GPL enforcement is always by the copyright
 
holder.  Usually, sublicensing is regarded as a practical convenience or
 
necessity for the licensee, to avoid having to negotiate a license with each
 
licensor in a chain of distribution.  The GPL solves this problem in another
 
way --- through its automatic licensing provision found in GPLv3\~S10 (which
 
is discussed in more detail in \S\~ref{GPLv3s10} of this tutorial).
 

	
 
% 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.
 
\section{GPLv3's views on DRM and Device Lock-Down}
 

	
 
The issues of DRM, device lock-down and encryption key disclosure were the
 
most hotly debated during the GPLv3 process.  FSF's views on this were sadly
 
frequently misunderstood and, comparing the provisions related to these
 
issues in the earliest drafts of GPLv3 to  the final version of GPLv3 shows
 
the FSF's willingness to compromise on tactical issues to reach the larger
 
goal of software freedom.
 

	
 
Specifically, GPLv3 introduced 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
 
computing,'' which actually means selling people computers they cannot trust
 
--- are alike in one basic respect.  They all employ technical means to turn
 
the system of copyright law, where the powers of the copyright holder are
 
limited exceptions to general freedom, into a prison, where everything not
 
specifically permitted is utterly forbidden, and indeed, if the full extent
 
of their ambition is realized, would be technically impossible.  This system
 
of ``para-copyright'' has been created since the adoption of GPLv2, through
 
legislation in the United States, the European Union, and elsewhere that
 
makes it a serious civil or even criminal offense to escape from these
 
restrictions, even where the purpose in doing so is to restore the users'
 
legal rights that the technology wrongfully prevents them from exercising.
 

	
 
% FIXME: Remove FSF specific parts
 

	
 
As a digital rights organization, we would not be following our mission if we
 
did not oppose these injustices.  But the reason our license must respond to
 
these practices at all is the result of a remarkable irony. Those who wish to
 
impose DRM on the public would like to do so by using software covered by the
 
GPL, a license that is intended to preserve the very freedom that they seek
 
to crush.  They are not satisfied merely with publishing programs having
 
limited capability, which free software permits. They seek to go further, to
 
prevent the user from removing those limits, turning Freedom 1, the freedom
 
to modify, into a sham.
 

	
 
GPLv2 did not address the use of technical measures to take back the rights
 
that the GPL granted, because such measures did not exist in 1991, and would
 
have been irrelevant to the forms in which software was then delivered to
 
users.  But GPLv3 must address these issues: free software is ever more
 
widely embedded in devices that impose technical limitations on the user's
 
freedom to change it.
 

	
 
These unjust measures must not be confused with legitimate applications that
 
give users control, as by enabling them to choose higher levels of system or
 
data security within their networks, or by allowing them to protect the
 
security of their communications using keys they can generate or copy to
 
other devices for sending or receiving messages.  These technologies present
 
no obstacles to the freedom of free software. The user is presented with
 
choices, and figuratively as well as literally retains all the keys to the
 
digital home.
 

	
 
By contrast, technical restrictions that allow other parties to control the
 
user have no legitimate social purpose.  In existing applications where the
 
user is not afforded the same degree of real power to modify the free
 
software in his system that vendors or distributors have retained, or have
 
conveyed to third parties, the software has been delivered in a fashion that
 
violates the spirit of the GPL, regardless of whether it complies with the
 
letter of the license. The freedoms the GPL grants have actually been
 
withdrawn by technical means.  It may even be a crime for the user to modify
 
that free software to escape from those restrictions and regain control over
 
what is still, at least nominally, his own system.
 

	
 
% FIXME: reference \S6 and \S3 stuff.
 

	
 
We believe that these provisions, taken together, are a minimalist set of
 
terms sufficient to protect the free software community against the threat of
 
invasive para-copyright.
 

	
 
Large enterprise users of free software often contract with non-employee
 
developers, often working offsite, to make modifications intended for
 
the user's private or internal use, and often arrange with other
 
companies to operate their data centers.  Whether GPLv2 permits these
 
activities is not clear and may depend on variations in copyright law.
 
The practices seem basically harmless, so we have decided to make it
 
clear they are permitted.
 

	
 

	
 
\section{GPLv3~\S3: What Hath DMCA Wrought}
 
\label{GPLv3s3}
 

	
 
% FIXME: reference the section in DMCA about this, maybe already there in
 
%        GPLv2 section?
 

	
 
% 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
 
prohibited circumvention of such technological measures. If a covered work is
 
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
 
specifically stated the rule, previously implicit, that modes of
 
distribution that establish limitations on use or modification that
 
are inconsistent with the terms of the license are not permitted by
 
the license.  In addition, we have added disclaimers, based on advice
 
of counsel from nations that have enacted para-copyright provisions
 
akin to the Digital Millennium Copyright Act in the US or pursuant to
 
the European Union Copyright Directive.  We believe these disclaimers
 
by each licensor of any intention to use GPL'd software to stringently
 
control access to other copyrighted works should practically prevent
 
any private or public parties from invoking DMCA-like laws against
 
users who escape technical restriction measures implemented by GPL'd
 
software.
 

	
 
This section shields users from being subjected to liability under
 
anti-circumvention law for exercising their rights under the GPL, so far as
 
the GPL can do so.  Some readers seem to have assumed that this provision
 
contains a prohibition on DRM; it does not (no part of GPLv3 forbids DRM).
 

	
 
\section{GPLv3~\S4: Verbatim Copying}
 

	
 
% FIXME: there appear to be minor changes here in later drafts, fix that.
 

	
 
Section 4 has been revised from its corresponding section in GPLv2 in light
 
of the new section 7 on license compatibility. A distributor of verbatim
 
copies of the program's source code must obey any existing additional terms
 
that apply to parts of the program. In addition, the distributor is required
 
to keep intact all license notices, including notices of such additional
 
terms.
 

	
 
% FIXME: needs context, needs match up to current text, and removal of stuff
 
%        that's no longer there
 

	
 
The original wording of this clause was meant to
 
make clear that the GPL permits one to charge for the distribution of
 
software.  Despite our efforts to explain this in the license and in
 
other documents, there are evidently some who believe that the GPL
 
allows charging for services but not for selling software, or that the
 
GPL requires downloads to be gratis.  We referred to charging a ``fee'';
 
the term ``fee'' is generally used in connection with services.  Our
 
original wording also referred to ``the physical act of transferring.''
 
The intention was to distinguish charging for transfers from attempts to
 
impose licensing fees on all third parties.  ``Physical'' might be read,
 
however, as suggesting ``distribution in a physical medium only.''  In
 
our revised wording we use ``price'' in place of ``fee,'' and we remove
 
the term ``physical.''
 

	
 
% FIXME: say more and tie it to the text
 

	
 
There is no harm in explicitly pointing out what ought to be obvious: that
 
those who convey GPL-covered software may offer commercial services for the
 
support of that software.
 

	
 
\section{GPLv3~\S5: Modified Source}
 

	
 
% FIXME: 5(a) is slightly different in final version
 

	
 
Section 5 contains a number of changes relative to the corresponding section
 
in GPLv2. Subsection 5a slightly relaxes the requirements regarding notice of
 
changes to the program. In particular, the modified files themselves need no
 
longer be marked. This reduces administrative burdens for developers of
 
modified versions of GPL'd software.
 

	
 
Under subsection 5a, as in the corresponding provision of GPLv2, the notices
 
must state ``the date of any change,'' which we interpret to mean the date of
 
one or more of the licensee's changes.  The best practice would be to include
 
the date of the latest change.  However, in order to avoid requiring revision
 
of programs distributed under ``GPL version 2 or later,'' we have retained
 
the existing wording.
 

	
 
% FIXME:  It's now (b) and (c).  Also, ``validity'' of proprietary
 
%         relicensing?  Give me a break.  I'll fix that.
 

	
 
Subsection 5b is the central copyleft provision of the license.  It now
 
states that the GPL applies to the whole of the work.  The license must be
 
unmodified, except as permitted by section 7, which allows GPL'd code to be
 
combined with parts covered by certain other kinds of free software licensing
 
terms. Another change in subsection 5b is the removal of the words ``at no
 
charge,'' which was often misinterpreted by commentators.  The last sentence
 
of subsection 5b explicitly recognizes the validity of disjunctive
 
dual-licensing.
 

	
 
%  FIXME: 5d.  Related to Appropriatey Legal notices
 

	
 

	
 
% follows 5d now, call it the ``final paragraph''
 

	
 
The paragraph following subsection 5c has been revised for clarity, but the
 
underlying meaning is unchanged. When independent non-derivative sections are
 
distributed for use in a combination that is a covered work, the whole of the
 
combination must be licensed under the GPL, regardless of the form in which
 
such combination occurs, including combination by dynamic linking. The final
 
sentence of the paragraph adapts this requirement to the new compatibility
 
provisions of section 7.
 

	
 
We have added these words to the aggregation clause to eliminate any question
 
that GPLv3 alters the scope of the copyleft as understood and applied under
 
GPLv2. In GPLv3, as in GPLv2, addition of modules or other parts to a program
 
results in a new program based on the old program, with different functional
 
characteristics created by the merger of two expressions: the original
 
program and the added parts.  Such added parts are ``by their nature
 
extensions of'' the old program, and therefore the entire new program which
 
they and the old program form must be licensed under the GPL.  As subsection
 
5c states, packaging of a work has no bearing on the scope of copyleft.
 

	
 
\section{GPLv3~\S6: Non-Source and Corresponding Source}
 

	
 
Section 6 of GPLv3, which clarifies and revises GPLv2 section 3, requires
 
distributors of GPL'd object code to provide access to the corresponding
 
source code, in one of four specified ways. As noted above, ``object code''
 
in GPLv3 is defined broadly to mean any non-source version of a work.
 

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

	
 
Subsections 6a and 6b now apply specifically to distribution of object code
 
in a physical product. Physical products include embedded systems, as well as
 
physical software distribution media such as CDs. As in GPLv2, the
 
distribution of object code may either be accompanied by the machine-readable
 
source code, or it may be accompanied by a written offer to provide the
 
machine-readable source code to any third party. GPLv3 clarifies that the
 
medium for software interchange on which the machine-readable source code is
 
provided must be a durable physical medium. Subsection 6b does not prevent a
 
distributor from offering to provide source code to a third party by some
 
other means, such as transmission over a network, so long as the option of
 
obtaining source code on a physical medium is presented.
 

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

	
 
Subsection 6b revises the requirements for the written offer to provide
 
source code. As before, the offer must remain valid for at least three
 
years. In addition, even after three years, a distributor of a product
 
containing GPL'd object code must offer to provide source code for as long as
 
the distributor also continues to offer spare parts or customer support for
 
the product model. We believe that this is a reasonable and appropriate
 
requirement; a distributor should be prepared to provide source code if he or
 
she is prepared to provide support for other aspects of a physical product.
 

	
 
% FIXME: 10x language is gone.
 

	
 
Subsection 6b also increases the maximum permitted price for providing a copy
 
of the source code. GPLv2 stated that the price could be no more than the
 
cost of physically performing source distribution; GPLv3 allows the price to
 
be up to ten times the distributor's cost. It may not be practical to expect
 
some organizations to provide such copies at cost. Moreover, permitting such
 
organizations to charge ten times the cost is not particularly harmful, since
 
some recipient of the code can be expected to make the code freely available
 
on a public network server. We also recognize that there is nothing wrong
 
with profiting from providing copies of source code, provided that the price
 
of a copy is not so unreasonably high as to make it effectively unavailable.
 

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

	
 
Subsection 6c gives narrower permission than the corresponding subsection in
 
GPLv2.  The option of including a copy of an offer received in accordance
 
with subsection 6b is available only for private distribution of object code;
 
moreover, such private distribution is restricted to ``occasional
 
non-commercial distribution.''  This subsection makes clear that a
 
distributor cannot comply with the GPL merely by making object code available
 
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: 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. 
 

	
 
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??
 

	
 

	
 
% 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.
 

	
 
\label{user-product}
 
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.
 

	
 
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.
 

	
 
we have replaced the Magnuson-Moss
 
reference with three sentences that encapsulate the judicial and
 
administrative principles established over the past three decades in the
 
United States concerning the Magnuson-Moss consumer product definition.
 
First, we state that doubtful cases are resolved in favor of coverage
 
under the definition.  Second, we indicate that the words ``normally
 
used'' in the consumer product definition refer to a typical or common
 
use of a class of product, and not the status of a particular user or
 
expected or actual uses by a particular user.  Third, we make clear that
 
the existence of substantial non-consumer uses of a product does not
 
negate a determination that it is a consumer product, unless such
 
non-consumer uses represent the only significant mode of use of that
 
product.
 

	
 
It should be clear from these added sentences that it is the general
 
mode of use of a product that determines objectively whether or not it
 
is a consumer product.  One could not escape the effects of the User
 
Products provisions by labeling what is demonstrably a consumer product
 
in ways that suggest it is ``for professionals,'' for example, contrary
 
to what some critics of Draft 3 have suggested.
 

	
 
We have made one additional change to the User Products provisions of
 
section 6.  In Draft 3 we made clear that the requirement to provide
 
Installation Information implies no requirement to provide warranty or
 
support for a work that has been modified or installed on a User
 
Product.  The Final Draft adds that there is similarly no requirement to
 
provide warranty or support for the User Product itself.
 

	
 
% FIXME: this needs integration
 

	
 
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: 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.''
 

	
 
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
 
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}
 

	
 
% FIXME: more about license compatibility here.
 

	
 
A challenge that faced the Free Software community heavily through out the
 
early 2000s was the proliferation of incompatible Free Software licenses.  Of
 
course, we cannot make the GPL compatible with all such licenses. GPLv3
 
contains provisions that are designed to reduce license incompatibility by
 
making it easier for developers to combine code carrying non-GPL terms with
 
GPL'd code.
 

	
 
% FIXME: connecting text
 

	
 
\subsection{Additional Permissions}
 

	
 
% FIXME: rework and fix formatting.
 

	
 
The GPL is a statement of permissions, some of which have conditions.
 
Additional terms, terms that supplement those of the GPL, may come to be
 
placed on, or removed from, GPL-covered code in certain common ways.  We
 
consider those added terms ``additional permissions'' if they grant
 
exceptions from the conditions of the GPL, and ``additional requirements'' if
 
they add conditions to the basic permissions of the GPL. The treatment of
 
additional permissions and additional requirements under GPLv3 is necessarily
 
asymmetrical, because they do not raise the same ethical and interpretive
 
issues; in particular, additional requirements, if allowed without careful
 
limitation, could transform a GPL'd program into a non-free one.  With these
 
principles in the background, section 7 answers the following questions: (1)
 
How do the presence of additional terms on all or part of a GPL'd program
 
affect users' rights? (2) When and how may a licensee add terms to code being
 
distributed under the GPL? (3) When may a licensee remove additional terms?
 

	
 
% FIXME: FSF third person, etc.
 

	
 
Additional permissions present the easier case.  We have licensed some of our
 
own software under GPLv2 with permissive exceptions that allow combination
 
with non-free code, and that allow removal of those permissions by downstream
 
recipients; similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,
 
and it permits relicensing under the GPL.  We have generalized these
 
practices in section 7.  A licensee may remove any additional permission from
 
a covered work, whether it was placed by the original author or by an
 
upstream distributor.  A licensee may also add any kind of additional
 
permission to any part of a work for which the licensee has, or can give,
 
appropriate copyright permission. For example, if the licensee has written
 
that part, the licensee is the copyright holder for that part and can
 
therefore give additional permissions that are applicable to it.
 
Alternatively, the part may have been written by someone else and licensed,
 
with the additional permissions, to that licensee.  Any additional
 
permissions on that part are, in turn, removable by downstream recipients.
 
As subsection 7a explains, the effect of an additional permission depends on
 
whether the permission applies to the whole work or a part.
 

	
 
% FIXME: rework this a bit
 

	
 
We have drafted version 3 of the GNU LGPL, which we have released with Draft
 
2 of GPLv3, as a simple list of additional permissions supplementing the
 
terms of GPLv3.  Section 7 has thus provided the basis for recasting a
 
formally complex license as an elegant set of added terms, without changing
 
any of the fundamental features of the existing LGPL.  We offer this draft of
 
LGPLv3 as as a model for developers wishing to license their works under the
 
GPL with permissive exceptions.  The removability of additional permissions
 
under section 7 does not alter any existing behavior of the LGPL; the LGPL
 
has always allowed relicensing under the ordinary GPL.
 

	
 
\subsection{Additional Requirements and License Compatibility}
 

	
 
% FIXME: minor rewrites needed
 

	
 
We broadened the title of section 7 because license compatibility, as it is
 
conventionally understood, is only one of several facets of the placement of
 
additional terms on GPL'd code.  The license compatibility issue arises for
 
three reasons.  First, the GPL is a strong copyleft license, requiring
 
modified versions to be distributed under the GPL.  Second, the GPL states
 
that no further restrictions may be placed on the rights of recipients.
 
Third, all other free software licenses in common use contain certain
 
requirements, many of which are not conditions made by the GPL.  Thus, when
 
GPL'd code is modified by combination with code covered by another formal
 
license that specifies other requirements, and that modified code is then
 
distributed to others, the freedom of recipients may be burdened by
 
additional requirements in violation of the GPL.  It can be seen that
 
additional permissions in other licenses do not raise any problems of license
 
compatibility.
 

	
 
% FIXME: minor rewrites needed
 

	
 
Section 7 relaxes the prohibition on further restrictions slightly by
 
enumerating, in subsection 7b, a limited list of categories of additional
 
requirements that may be placed on code without violating GPLv3.  The list
 
includes the items that were listed in Draft 1, though rewritten for clarity.
 
It also includes a new catchall category for terms that might not obviously
 
fall within one of the other categories but which are precisely equivalent to
 
GPLv3 conditions, or which deny permission for activities clearly not
 
permitted by GPLv3.  We have carefully considered but rejected proposals to
 
expand this list further.  We have also rejected suggestions, made by some
 
discussion committee members, that the Affero clause requirement (7d in Draft
 
1 and 7b4 in Draft 2) be removed, though we have revised it in response to
 
certain comments.  We are unwavering in our view that the Affero requirement
 
is a legitimate one, and we are committed to achieving compatibility of the
 
Affero GPL with GPLv3.
 

	
 
% FIXME: minor rewrites needed
 

	
 
A GPL licensee may place an additional requirement on code for which the
 
licensee has or can give appropriate copyright permission, but only if that
 
requirement falls within the list given in subsection 7b.  Placement of any
 
other kind of additional requirement continues to be a violation of the
 
license.  Additional requirements that are in the 7b list may not be removed,
 
but if a user receives GPL'd code that purports to include an additional
 
requirement not in the 7b list, the user may remove that requirement.  Here
 
we were particularly concerned to address the problem of program authors who
 
purport to license their works in a misleading and possibly
 
self-contradictory fashion, using the GPL together with unacceptable added
 
restrictions that would make those works non-free software.
 

	
 
\section{GPLv3~\S7: Explicit Compatibility}
 

	
 

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

	
 
In GPLv3 we take a new approach to the issue of combining GPL'd code with
 
code governed by the terms of other free software licenses. Our view, though
 
it was not explicitly stated in GPLv2 itself, was that GPLv2 allowed such
 
combinations only if the non-GPL licensing terms permitted distribution under
 
the GPL and imposed no restrictions on the code that were not also imposed by
 
the GPL. In practice, we supplemented this policy with a structure of
 
exceptions for certain kinds of combinations.
 

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

	
 
Section 7 of GPLv3 implements a more explicit policy on license
 
compatibility. It formalizes the circumstances under which a licensee may
 
release a covered work that includes an added part carrying non-GPL terms. We
 
distinguish between terms that provide additional permissions, and terms that
 
place additional requirements on the code, relative to the permissions and
0 comments (0 inline, 0 general)