Changeset - e52a3d32dc52
[Not reviewed]
0 1 0
Mike Linksvayer (mlinksva) - 10 years ago 2014-11-16 15:37:45
ml@gondwanaland.com
relate sections -> related sections
1 file changed with 1 insertions and 1 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -1904,2049 +1904,2049 @@ forms.  Embedded manufacturers, for example, have the freedom to put
 
GPL'd software into mobile devices with very tight memory and space
 
constraints.  In such cases, putting the source right alongside the
 
binaries on the machine itself might not be an option.  While it is
 
recommended that this be the default way that people comply with GPL, the
 
GPL does provide options when such distribution is unfeasible.
 

	
 
\label{GPLv2s3-medium-customarily}
 
GPLv2~\S3, therefore, allows source code to be provided on any physical
 
``medium customarily used for software interchange.''  By design, this
 
phrase covers a broad spectrum --- the phrase seeks to pre-adapt to
 
changes in  technology.  When GPLv2 was first published in June
 
1991, distribution on magnetic tape was still common, and CD was
 
relatively new.  By 2002, CD was the default.  By 2007, DVD's were the
 
default.  Now, it's common to give software on USB drives and SD cards.  This
 
language in the license must adapt with changing technology.
 

	
 
Meanwhile, the binding created by the word ``customarily'' is key.  Many
 
incorrectly believe that distributing binary on CD and source on the
 
Internet is acceptable.  In the corporate world in industrialized countries, it is indeed customary to
 
simply download a CDs' worth of data quickly.  However, even today in the USA, many computer users are not connected to the Internet, and most people connected
 
to the Internet still have limited download speeds.  Downloading
 
CDs full of data is not customary for them in the least.  In some cities
 
in Africa, computers are becoming more common, but Internet connectivity
 
is still available only at a few centralized locations.  Thus, the
 
``customs'' here are normalized for a worldwide userbase.  Simply
 
providing source on the Internet --- while it is a kind, friendly and
 
useful thing to do --- is not usually sufficient.
 

	
 
Note, however, a major exception to this rule, given by the last paragraph
 
of GPLv2~\S3. \emph{If} distribution of the binary files is made only on the
 
Internet (i.e., ``from a designated place''), \emph{then} simply providing
 
the source code right alongside the binaries in the same place is
 
sufficient to comply with GPLv2~\S3.
 

	
 
\medskip
 

	
 
As is shown above, under GPLv2~\S3(a), embedded manufacturers can put the
 
binaries on the device and ship the source code along on a CD\@.  However,
 
sometimes this turns out to be too costly.  Including a CD with every
 
device could prove too costly, and may practically (although not legally)
 
prohibit using GPL'd software. For this situation and others like it, GPLv2\S~3(b) is available.
 

	
 
\label{GPLv2s3b}
 
GPLv2~\S3(b) allows a distributor of binaries to instead provide a written
 
offer for source code alongside those binaries.  This is useful in two
 
specific ways.  First, it may turn out that most users do not request the
 
source, and thus the cost of producing the CDs is saved --- a financial
 
and environmental windfall.  In addition, along with a GPLv2~\S3(b) compliant
 
offer for source, a binary distributor might choose to \emph{also} give a
 
URL for source code.  Many who would otherwise need a CD with source might
 
turn out to have those coveted high bandwidth connections, and are able to
 
download the source instead --- again yielding environmental and financial
 
windfalls.
 

	
 
However, note that regardless of how many users prefer to get the
 
source online, GPLv2~\S3(b) does place lasting long-term obligations on the
 
binary distributor.  The binary distributor must be prepared to honor
 
that offer for source for three years and ship it out (just as they
 
would have had to do under GPLv2~\S3(a)) at a moment's notice when they
 
receive such a request.  There is real organizational cost here:
 
support engineers must be trained how to route source requests, and
 
source CD images for every release version for the last three years
 
must be kept on hand to burn such CDs quickly. The requests might not
 
even come from actual customers; the offer for source must be valid
 
for ``any third party''.
 

	
 
That phrase is another place where some get confused --- thinking again
 
that full public distribution of source is required.  The offer for source
 
must be valid for ``any third party'' because of the freedoms of
 
redistribution granted by GPLv2~\S\S1--2.  A company may ship a binary image
 
and an offer for source to only one customer.  However, under GPL, that
 
customer has the right to redistribute that software to the world if she
 
likes.  When she does, that customer has an obligation to make sure that
 
those who receive the software from her can exercise their freedoms under
 
GPL --- including the freedom to modify, rebuild, and redistribute the
 
source code.
 

	
 
GPLv2~\S3(c) is created to save her some trouble, because by itself GPLv2~\S3(b)
 
would unfairly favor large companies.  GPLv2~\S3(b) allows the
 
separation of the binary software from the key tool that people can use
 
to exercise their freedom. The GPL permits this separation because it is
 
good for re-distributors, and those users who turn out not to need the
 
source.  However, to ensure equal rights for all software users, anyone
 
along the distribution chain must have the right to get the source and
 
exercise those freedoms that require it.
 

	
 
Meanwhile, GPLv2~\S3(b)'s compromise primarily benefits companies that
 
distribute binary software commercially.  Without GPLv2~\S3(c), that benefit
 
would be at the detriment of the companies' customers; the burden of
 
source code provision would be unfairly shifted to the companies'
 
customers.  A customer, who had received binaries with a GPLv2~\S3(b)-compliant
 
offer, would be required under GPLv2 (sans GPLv2~\S3(c)) to acquire the source,
 
merely to give a copy of the software to a friend who needed it.  GPLv2~\S3(c)
 
reshifts this burden to entity who benefits from GPLv2~\S3(b).
 

	
 
GPLv2~\S3(c) allows those who undertake \emph{noncommercial} distribution to
 
simply pass along a GPLv2~\S3(b)-compliant source code offer.  The customer who
 
wishes to give a copy to her friend can now do so without provisioning the
 
source, as long as she gives that offer to her friend.  By contrast, if
 
she wanted to go into business for herself selling CDs of that software,
 
she would have to acquire the source and either comply via GPLv2~\S3(a), or
 
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 modified 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 among 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 program under the GPLv2, then it
 
cannot assert the patent against any party based on that party's use of 
 
Company \compA{}'s GPL'd Web browsing software program, or on that party's
 
creation and use of modified versions of that GPL'd 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 modified version of Company \compA{}'s GPL'd 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 loses 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 decide 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 transferred 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 the GPL, and nothing in
 
the 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.
 

	
 
% FIXME-LATER: Write this
 

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

	
 
GPLv2~\S6 is GPLv2's ``automatic downstream licensing''
 
provision\footnote{This section was substantially expanded for clarity and
 
  detail in \hyperref[GPLv3s10]{GPLv3~\S10}.}.  Each time you
 
redistribute a GPL'd program, the recipient automatically receives a license
 
from each original licensor to copy, distribute or modify the program subject
 
to the conditions of the license.  The redistributor need not take any
 
to ensure the downstream recipient's acceptance of the license terms.
 
This places every copyright holder in the chain of descent of the code
 
in legal privity, or direct relationship, with every downstream
 
redistributor.  Two legal effects follow.  First, downstream parties
 
who remain in compliance have valid permissions for all actions
 
(including modification and redistribution) even if their immediate upstream
 
supplier of the software has been terminated for license
 
violation\footnote{\label{German-reinstatement-footnote} While this is legally true, as a practical matter, a
 
  failure of ``complete, corresponding source'' (CCS) provisioning by an
 
  upstream could make it effectively impossible for a downstream party to
 
  engage in a commercial redistribution pursuant to
 
  \hyperref[GPLv2s3]{GPLv2~\S3(a--b)}.  (\S~\ref{upstream} in the Compliance
 
  Guide portion of this tutorial discussed related details.)}.
 
Downstream's
 
licensed rights are not dependent on compliance of their upstream, because
 
their licenses issue directly from the copyright holder.  Second, automatic
 
termination cannot be cured by obtaining additional copies from an alternate
 
supplier: the license permissions emanate only from the original licensors,
 
and if they have automatically terminated permission, no act by any
 
intermediate license holder can restore those terminated
 
rights\footnote{While nearly all attorneys and copyleft theorists are in
 
  agreement on this point, German copyleft legal expert
 
  \href{http://www.jbb.de/en/attorneys/till-jaeger/}{Till Jaeger}
 
  vehemently disagrees.  Jaeger's position is as follows: under German
 
  copyright law, a new copy of GPL'd software is a ``fresh'' license under
 
  GPL, and if compliance continues from that point further, the violator's
 
  permissions under copyright law are automatically restored, notwithstanding
 
  the strict termination provision in \hyperref[GPLv2s4]{GPLv2~\S4}.
 
  However, in
 
  practice, this issue is only salient with regard to \hyperref[Proprietary
 
    Relicensing]{proprietary relicensing} business models, since other copyright
 
  holders typically formally restore distributions rights once the only
 
  remaining compliance issue is ``you lost copyright permission due to
 
  GPLv2~\S4''.  Therefore, the heated debates, which have raged between
 
  Jaeger and almost everyone else in the copyleft community for nearly a
 
  decade, regard an almost moot and wholly esoteric legal detail.}.
 

	
 
\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 shouts 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
 
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{GPL Version 3}
 
\label{GPLv3}
 

	
 
This chapter discusses 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 of the 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 with 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 license 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 statute.  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''}
 
\label{GPLv3s0}
 

	
 
One of lawyers' most common complaints about GPLv2 is that defined terms in
 
the document appear throughout.  Most licenses define terms up-front.
 
However, the 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}
 

	
 
%  FIXME: I think we actually need to research the claim below that
 
%  ``derivative work'' as a term is unique to USA copyright law.  I have
 
%  heard German lawyers, for example, use the term extensively.  Is it also a
 
%  term perhaps under German law?  -- bkuhn
 

	
 
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.\footnote{(Ironically, 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.  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.}  GPLv2
 
always sought to cover all rights governed by relevant copyright law, in the
 
USA and elsewhere.
 
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.  GPLv3 therefore takes the task of
 
internationalizing the license further by removing references to derivative
 
works and by providing a more globally useful definition.
 
GPLv3 drops all reference to USA ``derivative works'' and returns
 
to the base concept only: GPL covers the licensed work and all works where
 
copyright permission from the licensed work's copyright holder.
 

	
 
The new definitions 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.
 

	
 
\subsection{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.
 

	
 
Next, to avoid locking GPLv3 into specific copyright statues, the GPLv3
 
defines two terms that are otherwise exotic to the language of international
 
copyright.
 

	
 
\subsection{Propagate}
 

	
 
To ``propagate'' a work covered by the license means any activity in a locale
 
that requires permission of copyright holders in that locale's legal system.
 
However, personal use or modification for personal use are activities explicitly
 
excluded from ``propagation'' \textit{regardless} of domestic copyright law.
 

	
 
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:
 
``derivative work'' was in fact not the only term commonly used by local
 
copyright statutes.  A term like ``distribute'' (or its equivalent in
 
languages other than English) is also used in several national copyright
 
statutes.  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 GPLv3 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 the GPL\@.
 

	
 
As a further benefit, because ``propagation'' includes all
 
exclusive rights granted under any particular copyright regime, the term
 
automatically  accounts for all exclusive rights under that regime.
 

	
 
\subsection{Convey}
 

	
 
Next, GPLv3 defines a subset of propagate --- ``convey''.
 
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.  
 
Any propagation that enables other parties to receive or make copies of the
 
work, is called ``conveying''.  Usually, conveying is the activity that
 
triggers most of the other obligations of GPLv3.
 

	
 
\subsection{Appropriate Legal Notices}
 

	
 
GPLv2 used the term ``appropriate copyright notice and disclaimer of
 
warranty'' in two places, which is a rather bulky 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.
 

	
 
\subsection{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}
 
\label{GPLv3s1}
 

	
 
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}
 
\label{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 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 examples also clarify 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,
 
GPLv3 makes it abundantly clear with an extra example.
 

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

	
 
\subsection{The System Library Exception}
 
\label{GPLv3-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
 
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 prohibition of that 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 replacing 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
 
allow distributors to evade important GPL requirements.  Part (b) reigns
 
in (a).  Specifically, (b) specifies only a few functionalities that a
 
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}
 
\label{GPLv3S2}
 

	
 
GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed
 
in \S~\ref{GPLv2s0} 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.  While these basic freedoms were
 
generally considered a standard part of users' rights under GPLv2 as well,
 
the GPLv3 states them herein more explicitly.  In other words, there is no
 
direct analog to the first sentence of GPLv3~\S2\P2 in GPLv2
 
(See \S~\ref{gplv2-private-modification} of this tutorial for more on this issue.)
 

	
 
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, contractor gets the
 
full freedoms of the GPL that they deserve.
 

	
 
The FSF was specifically asked to add this ``contractors provisions'' by
 
large enterprise users of Free Software, who often contract with non-employee
 
developers, 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 in different jurisdictions.  The
 
practices seem basically harmless, so FSF decided to make it clear they are
 
permitted.
 

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

	
 
\section{GPLv3's views on DRM and Device Lock-Down}
 
\label{GPLv3-drm}
 

	
 
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.  These measures are often
 
described by such Orwellian phrases, such 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.  However, these measures 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 virtual prison, where everything not specifically permitted
 
is utterly forbidden.  This system of ``para-copyright'' was created well
 
after GPLv2 was written --- initially through legislation in the USA and the
 
EU, and later in other jurisdictions as well.  This legislation creates
 
serious civil or even criminal penalties to escape from these restrictions
 
(commonly and aptly called ``jail-breaking a device''), even where the
 
purpose in doing so is to restore the users' legal rights that the technology
 
wrongfully prevents them from exercising.
 

	
 
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.  GPLv3 addresses these issues, particularly because copylefted
 
software is ever more widely embedded in devices that impose technical
 
limitations on the user's freedom to change it.
 

	
 
However, FSF always made a clear distinction to avoid conflating these
 
``lock-down'' measures 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.  Such technologies present no obstacles to
 
software freedom and the goals of copyleft.
 

	
 
The public GPLv3 drafting process sought to balance these positions of
 
copyleft advocates with various disparate views of the larger
 
Free-Software-using community.  Ultimately, FSF compromised to the GPLv3\S3
 
and GPLv3\S6 provisions that, taken together, are a minimalist set of terms
 
sufficient to protect the software freedom against the threat of invasive
 
para-copyright.
 

	
 
The compromises made were ultimately quite reasonable.  The primary one is
 
embodied in GPLv3\S6's ``User Product'' definition (see \S~\ref{user-product}
 
in this tutorial for details).  Additionally, some readers of early GPLv3
 
drafts seem to have assumed GPLv3 contained a blanket prohibition on DRM; but
 
it does not.  In fact, no part of GPLv3 forbids DRM regarding non-GPL'd
 
works; rather, GPLv3 forbids the use of DRM specifically to lock-down
 
restrictions on users' ability to install modified versions of the GPL'd
 
software itself, but again, \textit{only} with regard to User Products.
 

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

	
 
As discussed in \S~\ref{software-and-non-copyright} of this tutorial,
 
\href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} and
 
relate sections\footnote{These sections of the USC are often referred to as
 
related sections\footnote{These sections of the USC are often referred to as
 
  the ``Digital Millennium Copyright Act'', or ``DMCA'', as that was the name
 
  of the bill that so-modified these sections of the USC\@.} prohibits users
 
from circumventing technological measures that implement DRM\@.  Since this
 
is part of copyright law and the GPL is primarily a copyright license, and
 
since what the DMCA calls ``circumvention'' is simply ``modifying the
 
software'' under the GPL, GPLv3 must disclaim that such anti-circumvention
 
provisions are not applicable to the GPLv3'd software.  GPLv3\S3 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.
 

	
 
First, GPLv3\S3\P1 declares that no GPL'd program is part of an effective
 
technological protection measure, regardless of what the program does.  Early
 
drafts of GPLv3\S3\P1 referred directly to the DMCA, but the final version
 
instead includes instead an international legal reference to
 
anticircumvention laws enacted pursuant to the 1996 WIPO treaty and any
 
similar laws.  Lawyers outside the USA worried that a USA statutory reference
 
could be read as indicating a choice for application of USA law to the
 
license as a whole.  While the FSF did not necessarily agree with that view,
 
the FSF decided anyway to refer to the WIPO treaty rather than DMCA, since
 
several national anticircumvention laws were (or will likely be) structured
 
more similarly to the anticircumvention provisions of the DMCA in their
 
implementation of WIPO\@.  Furthermore, the addition of ``or similar laws''
 
provides an appropriate catch-all.
 

	
 
Furthermore, GPLv3\S3\P2 states 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.  GPLv3\S3\P2 makes clear that the referenced ``legal
 
rights'' are specifically rights arising under anticircumvention law.  and
 
refers to both the conveying party's rights and 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.
 

	
 
These disclaimers by each licensor of any intention to use GPL'd software to
 
stringently control access to other copyrighted works should effectively
 
prevent any private or public parties from invoking DMCA-like laws against
 
users who escape technical restriction measures implemented by GPL'd
 
software.
 

	
 
\section{GPLv3~\S4: Verbatim Copying}
 
\label{GPLv3s4}
 

	
 
GPLv3~\S4 is a revision of GPLv2~\S1 (as discussed in \S~\ref{GPLv2s1} of
 
this tutorial).   There are almost no changes to this section from the
 
GPLv2~\S1, other than to use the new defined terms.
 

	
 
The only notable change of ``a fee'' to ``any price or no price'' in the
 
first sentence of GPLv3\S4\P2.  The GPLv2\S1\P1 means that the GPL permits
 
one to charge money for the distribution of software.  Despite efforts by
 
copyleft advocates to explain this in GPLv2 itself and in other documents,
 
there are evidently some people who still believe that GPLv2 allows charging
 
for services but not for selling copies of software and/or that the GPL
 
requires downloads to be gratis.  Perhaps this is because GPLv2 referred to
 
charging a ``fee''; the term ``fee'' is generally used in connection with
 
services.
 

	
 
GPLv2's 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''.
 

	
 
To address these two issues, GPLv3 says ``price'' in place of ``fee,'' and
 
removes the term ``physical.''
 

	
 
GPLv3~\S4 has also been revised from its corresponding section in GPLv2 in
 
light of the GPLv3~\S7 (see \S~\ref{GPLv3s7} in this tutorial for more).
 
Specifically, a distributor of verbatim copies of the program's source code
 
must obey any existing additional terms that apply to parts of the program
 
pursuant to GPLv3~\S7.  In addition, the distributor is required to keep
 
intact all license notices, including notices of such additional terms.
 

	
 
Finally, 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}
 
\label{GPLv3s5}
 

	
 
GPLv3\S5 is the rewrite of GPLv2\S2, which was discussed in \S~\ref{GPLv2s2}
 
of this tutorial.  This section discusses the changes found in GPLv3\S5
 
compared to GPLv2\S2.
 

	
 
GPLv3\S5(a) still requires modified versions be marked with ``relevant
 
date'', but no longer says ``the date of any change''.  The best practice is
 
to include the date of the latest and/or most significant changes and who
 
made those.  Of course, compared to its GPLv2\S2(a), GPLv3\S5(a) 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.
 

	
 
GPLv3\S5(b) is a new but simple provision. GPLv3\S5(b)  requires that the
 
license text itself must be unmodified (except as permitted by GPLv3\S7; see
 
\S~\ref{GPLv3s7} in this tutorial).  Furthermore, it  removes any perceived
 
conflict between the words ``keep intact all notices'' in GPLv3\S4, since
 
operating under GPLv3\S5 still includes all the requirements of GPLv3\S4 by
 
reference.
 

	
 
GPLv3\S5(c) is the primary source-code-related copyleft provision of GPL. (The
 
object-code-related copyleft provisions are in GPLv3\S6, discussed in
 
\S~\ref{GPLv3s6} of this tutorial).  Compared to GPLv2\S2(b), GPLv3\S5(c)
 
states that the GPL applies to the whole of the work.  Such was stated
 
already in GPLv2\S2(b), in ``in whole or in part'', but this simplified
 
wording makes it clear it applies to the entire covered work.
 

	
 
Another change in GPLv3\S5(c) is the removal of the
 
words ``at no charge,'' which was often is misunderstood upon na\"{i}ve
 
reading of in GPLv2\S(b) (as discussed in \S~\ref{GPLv2s2-at-no-charge} of this
 
tutorial).
 

	
 
%  FIXME-LATER: Write up something on 5d, and related it to Appropriate Legal Notices.
 

	
 

	
 
Note that of GPLv2~\S2's penultimate and ante-penultimate paragraphs are now
 
handled adequately by the definitions in GPLv3\S0 and as such, have no direct
 
analogs in GPLv3.
 

	
 
GPLv2~\S2's final paragraph, however, is reworded and expanded into the final
 
paragraph of GPLv3\S5, which now also covers issues related to copyright
 
compilations (but not compilations into object code --- that's in the next
 
section!).  The intent and scope is the same as was intended in GPLv2.
 

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

	
 
GPLv3~\S6 states the compliance obligations for distributing ``non-source
 
forms'' of a program (which means any form other than CCS).  As noted in \S~\ref{GPLv3s0}, ``object code'' in GPLv3
 
is defined broadly to mean any non-source version of a work, and thus
 
includes not only binaries or executables, but also obfuscated, minimized, compressed or otherwise
 
non-preferred forms for modification.  Thus, GPLv3~\S6 clarifies and revises GPLv2~\S3.
 
Indeed, GPLv3~\S6's CCS requirement under
 
closely parallels the provisions of \hyperref[GPLv2s3]{GPLv2~\S3}, with changes
 
designed to make compliant provisioning easier under contemporary
 
technological conditions.  Distributors of GPLv3'd
 
object code must provide access to the corresponding source code, in one of
 
four specified ways.
 

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

	
 
GPLv3~\S6(a--b) 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~\S3 (discussed
 
in \S~\ref{GPLv2s3} of this tutorial), the distribution of object code may
 
either be accompanied by the machine-readable source code, or it may be
 
accompanied by a valid written offer to provide the machine-readable source
 
code.  However, unlike in GPLv2, that offer cannot be exercised by any third
 
party; rather, only those ``who possess the object code'' can exercise
 
the offer.  (Note that this is a substantial narrowing of requirements of
 
offer fulfillment, and is a wonderful counterexample to dispute claims that
 
the GPLv3 has more requirements than GPLv2.)
 

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

	
 
GPLv3~\S6(b) further 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.  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.
 

	
 
GPLv3~\S6(a--b) clarifies that the medium for software interchange on which
 
the machine-readable source code is provided must be a durable physical
 
medium.  GPLv3~\S6(b)(2), however, permits a distributor to instead offer to
 
provide source code from a network server instead, which is yet another
 
example GPLv3 looser in its requirements than GPLv2 (see
 
\S~\ref{GPLv2s3-medium-customarily} for details).
 

	
 
% FIXME-LATER: more information about source provision, cost of physically
 
% performing, reasonable fees, medium customary clearly being said durable
 
% connecting back to previous text
 

	
 
GPLv3\S6(c) gives narrower permission than GPLv2\S3(c).  The ``pass along''
 
option for GPLv3\S6(c)(1) offers is now available only for individual
 
distribution of object code; moreover, such individual distribution can occur
 
only ``occasionally and noncommercially.''  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-LATER: tie back to the discussion of the occasional offer pass along
 
%             stuff in GPLv2 this tutorial.
 

	
 
GPLv3~\S6(d) revises and improves GPLv2~\S3's final paragraph.  When object
 
code is provided by offering access to copy the code from a designated place
 
(such as by enabling electronic access to a network server), the distributor
 
must merely offer equivalent access to copy the source code ``in the same way
 
through the same place''.  This wording also 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.  Thus,
 
the obligation remains on the party distributing object code to point
 
prominently (``next to'' the object code download) to the third-party source
 
code provisioning server, and to ensure that this third-party server remains
 
in operation for required period.  This codifies formally the typical
 
historical interpretation of GPLv2.
 

	
 
% FIXME-LATER: perhaps in enforcement section, but maybe here, note about
 
% ``slow down'' on source downloads being a compliance problem. 
 

	
 
Furthermore, under GPLv3~\S6(d), distributors may charge for the conveyed
 
object code; however, those who pay to obtain the object code must be given
 
equivalent and gratis access to obtain the CCS.  (If distributors convey the
 
object code gratis, distributors must likewise make CCS available without
 
charge.)  Those who do not obtain the object code from that distributors
 
(perhaps because they choose not to pay the fee for object code) are outside
 
the scope of the provision; distributors are under no specific obligation to
 
give CCS to someone who has not purchased an object code download under
 
GPLv3~\S6(d).  (Note: this does not change nor impact any obligations under
 
GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)
 

	
 
\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}
 

	
 
GPLv3~\S6(e) allows provision of CCS via another server when the binary or
 
other non-source form is distributed by peer-to-peer protocols such as
 
BitTorrent.  Here the requirement is only that each peer be effectively
 
informed of the location of the source code on a server as above.
 

	
 
GPLv3 really did require this addition, even though it adds  complexity to
 
a key section of GPL\@.  In particular,
 
Decentralized peer-to-peer file sharing present a challenge
 
to the unidirectional view of distribution that is implicit in GPLv2 and
 
initial drafts of GPLv3.  Identification of an upstream/downstream link in
 
BitTorrent distribution is neither straightforward nor reasonable; such
 
distribution is multidirectional, cooperative and (somewhat) anonymous.  In peer-to-peer
 
distribution systems, participants act both as transmitters and recipients of
 
blocks of a particular file, but they perceive the experience merely as users
 
and receivers, and not as distributors in any conventional sense.  At any
 
given moment of time, most peers will not have the complete file.
 

	
 
Meanwhile, GPLv3~\S6(d) permits distribution of a work in object code form
 
over a network, provided that the distributor offers equivalent access to
 
copy the Corresponding Source Code ``in the same way through the same
 
place''.  This wording might be interpreted to permit peer-to-peer
 
distribution of binaries \textit{if} they are packaged together with the CCS,
 
but such packaging is impractical, for at least three reasons.  First, even if
 
the CCS is packaged with the object code, it will only be available to a
 
non-seeding peer at the end of the distribution process, but the peer will
 
already have been providing parts of the binary to others in the network.
 
Second, in practice, peer-to-peer forms of transmission are poorly suited
 
means for distributing CCS.  In large distributions, packaging CCS with the
 
object code may result in a substantial increase in file size and
 
transmission time.  Third, in current practice, CCS packages themselves tend
 
\textit{not} to be transmitted through BitTorrent --- owing to reduced demand
 
-- thus, there generally will be too few participants downloading the same
 
source package at the same time to enable effective seeding and distribution.
 

	
 
GPLv3~\S6(e) addresses these issues.  If a licensee conveys such a work of
 
object code using peer-to-peer transmission, that licensee is in compliance
 
with GPLv3~\S6 if the licensee informs other peers where the object code and
 
its CCS are publicly available at no charge under subsection GPLv3~\S6(d).
 
The CCS therefore need not be provided through the peer-to-peer system that
 
was used for providing the binary.
 

	
 
Second, GPLv3\S9 also clarifies that ancillary propagation of a covered work
 
that occurs as part of the process of peer-to-peer file transmission does not
 
require acceptance, just as mere receipt and execution of the Program does
 
not require acceptance.  Such ancillary propagation is permitted without
 
limitation or further obligation.
 

	
 
% FIXME-LATER: Would be nice to explain much more about interactions between
 
% the various options of GPLv3~\S6(a-e), which might all be in play at once!
 

	
 
\subsection{User Products, Installation Information and Device Lock-Down}
 

	
 
As discussed in \S~\ref{GPLv3-drm} of this tutorial, GPLv3 seeks to thwart
 
technical measures such as signature checks in hardware to prevent
 
modification of GPL'd software on a device.
 

	
 
To address this issue, GPLv3~\S6 requires that parties distributing object
 
code provide recipients with the source code through certain means.  When
 
those distributors pass on the CCS, they are also required to pass on any
 
information or data necessary to install modified software on the particular
 
device that included it.  (This strategy is not unlike that used in LGPLv2.1
 
to enable users to link proprietary programs to modified libraries.)
 

	
 
% FIXME-LATER: LGPLv2.1 section should talk about this explicitly and this
 
%              should be a forward reference here
 

	
 
\subsubsection{User Products}
 

	
 
\label{user-product}
 

	
 
The scope of these requirements is narrow.  GPLv3~\S6 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.
 

	
 
In brief, the right to convey object code in a defined class of ``User
 
Products,'' under certain circumstances, depends on providing whatever information
 
is required to enable a recipient to replace the object code with a functioning
 
modified version.
 

	
 
This was a compromise that was difficult for the FSF to agree to during the
 
GPLv3 drafting process.  However, companies and governments that use
 
specialized or enterprise-level computer facilities reported that they
 
actually \textit{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 \textit{preference}.  It is not clear that the GPL should interfere
 
here, since 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.  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
 
limited to User Products, this provision addresses the fundamental problem.
 

	
 
% FIXME-LATER: link \href to USC 2301
 

	
 
The core of the User Product definition is a subdefinition of ``consumer
 
product'' adapted from the Magnuson-Moss Warranty Act, a federal
 
consumer protection law in the USA found in 15~USC~\S2301: ``any tangible
 
personal property which is normally used for personal, family, or household
 
purposes.''  The USA 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 USA and Canada, having been
 
  adopted in several state and provincial consumer protection laws.}
 
Ideally, this body of interpretation\footnote{The FSF, however, was very
 
  clear that incorporation of such legal interpretation was in no way
 
  intended to work as a general choice of USA law for GPLv3.} will guide
 
interpretation of the consumer product subdefinition in GPLv3~\S6, and this
 
will hopefully provide a degree of legal certainty advantageous to device
 
manufacturers and downstream licensees alike.
 

	
 
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
 
CFR~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54
 
UCC~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 CFR \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.}
 

	
 
However, Magnuson-Moss is not a perfect fit because in the area of components
 
of dwellings, the settled interpretation under Magnuson-Moss is under-inclusive.
 
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, GPLv3
 
defines User Products as a superset of consumer products that also includes
 
``anything designed or sold for incorporation into a dwelling.''
 

	
 
Thus, the three sentences in the center of GPLv3's User Product definition
 
encapsulate the judicial and administrative principles established over the
 
past three decades in the USA concerning the Magnuson-Moss consumer product
 
definition.  First, it states that doubtful cases are resolved in favor of
 
coverage under the definition.  Second, it 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, it clearly states 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.
 

	
 

	
 
\subsubsection{Installation Information}
 

	
 
\label{GPLv3-installation-information}
 

	
 
With the User Products definition complete,  The ``Installation Information''
 
definition uses that to define what those receiving object code inside a User
 
Product must receive.
 

	
 
Installation Information is information that is ``required to install and
 
execute modified versions of a covered work \dots from a modified version of
 
its'' CCS, in the same User Product for which the covered work is conveyed.
 
GPLv3 provides 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''.
 

	
 
Note that GPLv3 does not define ``continued functioning'' further.  However,
 
GPLv3 does 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.
 
First of all, GPLv3 makes clear that GPLv3 implies no obligation ``to
 
continue to provide support service, warranty, or updates'' for such a work.
 

	
 
Second, 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.  GPLv3 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, and it serves as a foundation for
 
reasonable enforcement policies that respect recipients' right to modify
 
while recognizing the legitimate interests of network providers.
 

	
 
Note that GPLv3 permits the practice of conveying object code in a mode not
 
practically susceptible to modification by any party, such as code burned in
 
ROM or embedded in silicon.  The goal of the Installation Information
 
requirement is to ensure the downstream licensee receives the real right to
 
modify when the device manufacturer or some other party retains that right.
 
Accordingly, GPLv3\S6's ante-penultimate paragraph states that the
 
requirement to provide Installation Information ``does not apply if neither
 
you nor any third party retains the ability to install modified object code
 
on the User Product''.
 

	
 
Finally, GPLv3\S6 makes it clear that there is also no requirement to
 
provide warranty or support for the User Product itself.
 

	
 
\subsection{GPLv3~\S7: Additional Permissions}
 
\label{GPLv3s7}
 

	
 
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.
 
Copyleft licensing theorists have generally called
 
 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 interpretive
 
issues; in particular, additional requirements, if allowed without careful
 
limitation, could transform a GPL'd program into a non-free one.
 

	
 
Due to the latter fear, historically,  GPLv2 did not permit any additional
 
requirements.  However, over time,
 
many copyright holders generally tolerated certain types of benign additional requirements
 
merely through a ``failure to enforce'' estoppel-esque scenario.  Therefore, GPLv3 allows
 
for some specific limited requirement variations that GPLv2 technically prohibits.
 

	
 
With these principles in the background, GPLv3~\S7  answers the following
 
questions: 
 
\begin{enumerate}
 
\item How does the presence of additional terms on all or part of a GPL'd program
 
affect users' rights?
 

	
 
\item When and how may a licensee add terms to code being
 
distributed under the GPL? 
 

	
 
\item When may a licensee remove additional terms?
 
\end{enumerate}
 

	
 
Additional permissions present the easier case.  Since the mid-1990s,
 
permissive exceptions often appeared alongside GPLv2 to allow combination
 
with certain non-free code.  Typically, downstream
 
stream recipients could remove those exceptions and operate under pure GPLv2.
 
Similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,
 
and it permits relicensing under the GPL\@.  
 

	
 
These practices are now generalized via GPLv3~\S7.
 
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 GPLv3~\S7\P1 explains, the effect of an additional permission depends on
 
whether the permission applies to the whole work or a part.
 

	
 
% FIXME-LATER: LGPLv3 will have its own section
 

	
 
Indeed, LGPLv3 is itself simply  a list of additional permissions supplementing the
 
terms of GPLv3.  GPLv3\S7 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\@.  LGPLv3 is thus  a model for developers wishing to license their works under the
 
GPL with permissive exceptions.  The removability of additional permissions
 
under GPLv3\S7 does not alter any existing behavior of the LGPL since the LGPL
 
has always allowed relicensing under the ordinary GPL\@.
 

	
 
\section{GPLv3~\S7: Understanding License Compatibility}
 
\label{license-compatibility}
 

	
 
A challenge that faced the Free Software community heavily through out the
 
early 2000s was the proliferation of incompatible Free Software licenses.  Of
 
course, the GPL cannot possibly be compatible with all such licenses.
 
However, 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.
 

	
 
This 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 software freedom respecting 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.
 

	
 
GPLv3  took a new approach to the issue of combining GPL'd code with
 
code governed by the terms of other software freedom licenses.  Traditional
 
GPLv2 license compatibility theory (which was not explicitly stated in GPLv2
 
itself, but treated as a license interpretation matter by the FSF) held 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, the FSF historically supplemented that policy with a structure of
 
exceptions for certain kinds of combinations.
 

	
 
GPLv3~\S7  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. 
 
GPLv3~\S7 distinguish between terms that provide additional permissions, and terms that
 
place additional requirements on the code, relative to the permissions and
 
requirements established by applying the GPL to the code.
 

	
 
As discussed in the previous section of this tutorial, GPLv3~\S7 first and foremost explicitly allows added parts covered by terms with
 
additional permissions to be combined with GPL'd code. This codifies the
 
existing practice of regarding such licensing terms as compatible with the
 
GPL\@. A downstream user of a combined GPL'd work who modifies such an added
 
part may remove the additional permissions, in which case the broader
 
permissions no longer apply to the modified version, and only the terms of
 
the GPL apply to it.
 

	
 
In its treatment of terms that impose additional requirements, GPLv3\S7
 
extends the range of licensing terms with which the GPL is compatible.  An
 
added part carrying additional requirements may be combined with GPL'd code,
 
but only if those requirements belong to an set enumerated in GPLv3\S7. There
 
are, of course,  limits on the acceptable additional requirements, which 
 
ensures that enhanced license compatibility does not
 
defeat the broader software-freedom-defending terms of the GPL\@. Unlike terms that grant
 
additional permissions, terms that impose additional requirements cannot be
 
removed by a downstream user of the combined GPL'd work, because only in the
 
pathological case\footnote{Theoretically, a user could collect copyright
 
  assignment from all known contributors and then do this, but this would
 
  indeed be the pathological case.}  would a user have the right to do so.
 

	
 
In general, the types of additional requirements were those terms in regular
 
use by other non-copyleft Free Software licenses that the FSF found
 
unobjectionable.  The specific details GPLv3's permitted additional
 
requirements hat GPLv3 are as follows:
 

	
 
\begin{enumerate}[label=7(\alph*):,ref=GPLv3s7\alph*]
 

	
 
\item This provision allows alternative ``disclaimer of warranty''
 
  forms. Copyright holders can disclaim warranty or limit liability
 
  differently from the terms as provided under GPLv3\S~\S15--16.  Drafters
 
  included this permission to advance the internationalization goals of
 
  GPLv3; international treaties lack adequate harmonization for laws
 
  regarding warranty and disclaimer.
 

	
 
\item This provision allows alternative requirements for preservation of
 
  appropriate legal notices.  GPLv3 permits additional requirements regarding
 
  preservation of legal notices, including on output from execution of
 
  covered works.  Preserved information can include information about the
 
  origins of the code or alterations of the code.
 

	
 
\item This provision allows prohibition of misrepresentation of original
 
  material.  The provision yields compatibility with non-copyleft Free
 
  Software licenses that require marking of modified versions in
 
  ``reasonable''ways which differ from GPL's own precise marking
 
  requirements.
 

	
 
\item This provision allows limitations on the use of names of licensor for
 
  publicity purposes.  This provision also yields additional compatibility
 
  with non-copyleft Free Software licenses that prohibit the use of the
 
  licensor's name on unmodified versions (or other prohibitions on
 
  advertising rights).  The third clause of the
 
  \href{http://opensource.org/licenses/BSD-3-Clause}{3-Clause BSD
 
  License}, for example, long considered de-facto compatible with GPLv2
 
    anyway, is via this clause unequivocally compatible with GPLv3.  However,
 
    \href{https://www.gnu.org/licenses/license-list.html#OriginalBSD}{this
 
      clause \textit{does not} make GPL compatible with the old BSD
 
      advertising clause} that the FSF
 
    \href{https://www.gnu.org/philosophy/bsd.html}{long ago identified as
 
      problematic}.
 
 
 
\item This provision clarifies that refusal to grant trademark rights for a
 
  GPLv3'd covered work remains compatible with GPLv3.  Again, some
 
  non-copyleft permissive licenses include such clauses.
 

	
 
\item This provision allows indemnification requirements of authors and
 
  licensors.  The FSF specifically designed this clause to achieve GPLv3
 
  compatibility for the
 
  \href{http://www.apache.org/licenses/LICENSE-2.0.html}{Apache Software
 
    License, Version 2.0}.
 

	
 
\end{enumerate}
 

	
 
During the GPLv3 drafting process, some questioned the necessity of GPLv3~\S7;
 
those critics suggested that it creates complexity that did not previously
 
exist.  However, by the time of GPLv3's drafting, many existing GPLv2'd
 
software packages already combined with various non-copylefted Free Software
 
licensed code that carried such additional terms.  Therefore, GPLv3~\S7 is
 
rationalized existing practices of those package authors and modifiers, since
 
it sets clear guidelines regarding the removal and addition of these
 
additional terms.  With its carefully limited list of allowed additional
 
requirements, GPLv3\S7 accomplishes additional objectives as well, since it
 
permits the expansion of the base of code available for GPL developers, while
 
also encouraging useful experimentation with requirements the GPLv3 does not
 
include by default.
 

	
 
However, any other non-permissive additional terms apart from those stated
 
above are considered ``further'' restrictions which
 
\hyperref[GPLv3s10]{GPLv3~\S10} prohibits.  Furthermore, as a compliance
 
matter, if you add additional terms in accordance with GPLv3~\S7, you must
 
ensure that the terms are placed in the relevant source files or provide a
 
conspicuous notice about where to find the additional terms.
 

	
 
\section{GPLv3~\S8: A Lighter Termination}
 

	
 
GPLv2 provided for automatic termination of the rights of a person who
 
copied, modified, sublicensed, or distributed a work in violation of the
 
license.  Automatic termination can be too harsh for those who have committed
 
an inadvertent violation, particularly in cases involving distribution of
 
large collections of software having numerous copyright holders.  A violator
 
who resumes compliance with GPLv2 technically needs to obtain forgiveness
 
from all copyright holders, and even contacting them all might be impossible.
 

	
 
GPLv3~\S8 now grants opportunities for provisional and permanent
 
reinstatement of rights. The termination procedure provides a limited
 
opportunity to cure license violations.  If a licensee has committed a
 
first-time violation of the GPL with respect to a given copyright holder, but
 
the licensee cures the violation within 30 days following receipt of notice
 
of the violation, then any of the licensee's GPL rights that have been
 
terminated by the copyright holder are ``automatically reinstated''.
 

	
 

	
 
Finally, if a licensee violates the GPL, a contributor may terminate any
 
patent licenses that it granted under GPLv3~\S11, in addition to any
 
copyright permissions the contributor granted to the licensee.
 

	
 
% FIXME-LATER: write more here, perhaps linking up to enforcement
 

	
 
\section{GPLv3~\S9: Acceptance}
 

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

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

	
 
GPLv3~\S10 is a generally straightforward section that ensures that everyone
 
downstream receives licenses from all copyright holders.  Each time you
 
redistribute a GPL'd program, the recipient automatically receives a license,
 
under the terms of GPL, from every upstream licensor whose copyrighted
 
material is present in the work you redistribute.  You could think of this as
 
creating a three-dimensional rather than linear flow of license rights.
 
Every recipient of the work is ``in privity,'' or is directly receiving a
 
license from every licensor.
 

	
 
This mechanism of automatic downstream licensing is central to copyleft's
 
function.  Every licensor independently grants licenses, and every licensor
 
independently terminates the license on violation.  Parties further
 
downstream from the infringing party remain licensed, so long as they don't
 
themselves commit infringing actions.  Their licenses come directly from all
 
the upstream copyright holders, and are not dependent on the license of the breaching
 
party who distributed to them.  For the same reason, an infringer who acquires
 
another copy of the program has not thereby acquired any new license rights:
 
once any upstream licensor of that program has terminated the license for
 
breach of its terms, no new automatic license will issue to the recipient
 
just by acquiring another
 
copy\footnote{Footnote~\ref{German-reinstatement-footnote} also applies here
 
  in discussion of GPLv3 just as it did in discussion of GPLv2.}
 

	
 
Meanwhile, one specific addition in GPLv3 here in GPLv3~\S10 deserves special
 
mention.  Specifically, GPLv3 removed the words ``at no charge'' from
 
GPLv2~\S2(b) (which, BTW, became GPLv3~\S5(b)) because it contributed to a misconception that the GPL did not
 
permit charging for distribution of copies.  The purpose of the ``at no
 
charge'' wording was to prevent attempts to collect royalties from third
 
parties.  The removal of these words created the danger that the imposition
 
of licensing fees would no longer be seen as a license violation.  Therefore,
 
GPLv3~\S10 adds a new explicit prohibition on imposition of licensing fees or
 
royalties.  This section is an appropriate place for such a clause, since it
 
is a specific consequence of the general requirement that no further
 
restrictions be imposed on downstream recipients of GPL-covered code.
 

	
 
% FIXME-LATER: This text needs further study before I can conclude it belongs
 
% in this tutorial:
 

	
 
%% Careful readers of the GPL have suggested that its explicit prohibition
 
%% against imposition of further restrictions\footnote{GPLv2, section 6; Draft
 
%%   3, section 10, third paragraph.} has, or ought to have, implications for
 
%% those who assert patents against other licensees.  Draft 2 took some steps to
 
%% clarify this point in a manner not specific to patents, by describing the
 
%% imposition of ``a license fee, royalty, or other charge'' for exercising GPL
 
%% rights as one example of an impermissible further restriction.  In Draft 3 we
 
%% have clarified further that the requirement of non-imposition of further
 
%% restrictions has specific consequences for litigation accusing GPL-covered
 
%% programs of infringement.  Section 10 now states that ``you may not initiate
 
%% litigation (including a cross-claim or counterclaim in a lawsuit) alleging
 
%% that any patent claim is infringed by making, using, selling, offering for
 
%% sale, or importing the Program (or the contribution of any contributor).''
 
%% That is to say, a patent holder's licensed permissions to use a work under
 
%% GPLv3 may be terminated under section 8 if the patent holder files a lawsuit
 
%% alleging that use of the work, or of any upstream GPLv3-licensed work on
 
%% which the work is based, infringes a patent.
 

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

	
 
Software patenting is a harmful and unjust policy, and should be abolished;
 
recent experience makes this all the more evident. Since many countries grant
 
patents that can apply to and prohibit software packages, in various guises
 
and to varying degrees, GPLv3 seeks to protect the users of GPL-covered programs
 
from those patents, while at the same time making it feasible for patent
 
holders to contribute to and distribute GPL-covered programs as long as they
 
do not attack the users of those programs.
 

	
 
It is generally understood that GPLv2 implies some limits on a licensee's
 
power to assert patent claims against the use of GPL-covered works.
 
However, the patent licensing practices that GPLv2~\S7 (corresponding to
 
GPLv3~\S12) is designed to prevent is only one of several ways in which
 
software patents threaten to make free programs non-free and to prevent users
 
from exercising their rights under the GPL. GPLv3 takes a more comprehensive
 
approach to combating the danger of patents.
 

	
 
GPLv2~\S7 has seen some success in deterring conduct that would otherwise
 
result in denial of full downstream enjoyment of GPL rights, and thus it is
 
preserved in GPLv3~\S12.  Experience has shown that more is necessary,
 
however, to ensure adequate community safety where companies act in concert
 
to heighten the anticompetitive use of patents that they hold or license.
 

	
 
Therefore,  GPLv3 is designed to reduce the patent risks that distort and
 
threaten the activities of users who make, run, modify and share Free
 
Software.  At the same time, GPLv3 gives favorable consideration to practical
 
goals such as certainty and administrability for patent holders that
 
participate in distribution and development of GPL-covered software.  GPLv3's
 
policy requires each such patent holder to provide appropriate levels of
 
patent assurance to users, according to the nature of the patent holder's
 
relationship to the program.
 

	
 
In general, GPLv3 provides for two classes of patent commitments:
 

	
 
\begin{itemize}
 
\item Grant of license to claims in contributor versions: GPLv3~\S11
 
  introduces an affirmative grant of rights to patent claims by those who
 
  contribute code to GPL'd programs. The intent is to prevent parties from
 
  aggressively asserting patents against users of code those parties have
 
  themselves modified --- in theory preventing betrayal by ``insiders'' of
 
  the copyleft community.  A contributor's patent claims necessarily
 
  infringed by the version of the program created by the incorporation of its
 
  modifications are licensed to all subsequent users and modifiers of the
 
  program, or programs based on the program.  No patent claims only infringed
 
  by subsequent modifications by other parties are thus licensed.  Patent
 
  claims acquired after the making of the ``contributor version'' necessarily
 
  infringed by that version are also licensed by this provision at the time
 
  of their acquisition or perfection.
 

	
 
\item Prohibition of enforcement of patent claims against those to whom you
 
  distribute: GPLv3~\S10 makes explicit that licensees who directly
 
  distribute may not make demands for acceptance of patent licenses or
 
  payment of patent royalties from distribution recipients.  This provision
 
  establishes a uniform rule of patent exhaustion with respect to GPL'd
 
  programs regardless of the domestic patent law in any particular system or
 
  locale.
 
\end{itemize}
 

	
 
The following two subsections discuss in order each of the above mentioned
 
classes of patent commitments.
 

	
 
\subsection{The Contributor's Explicit Patent License}
 

	
 
Specifically, the ideal might have been for GPLv3 to feature a patent license
 
grant triggered by all acts of distribution of GPLv3-covered works.  The FSF
 
considered it during the GPLv3 drafting process, but many patent-holding
 
companies objected to this policy.  They have made two objections: (1) the
 
far-reaching impact of the patent license grant on the patent holder is
 
disproportionate to the act of merely distributing code without modification
 
or transformation, and (2) it is unreasonable to expect an owner of vast
 
patent assets to exercise requisite diligence in reviewing all the
 
GPL-covered software that it provides to others.  Some expressed particular
 
concern about the consequences of ``inadvertent'' distribution.
 

	
 
The argument that the impact of the patent license grant would be
 
``disproportionate'',  that is to say unfair, is not valid. Since
 
software patents are weapons that no one should have, and using them for
 
aggression against free software developers is an egregious act (thus
 
preventing that act cannot be unfair). 
 

	
 
However, the second argument seems valid in a practical sense.  A
 
typical GNU/Linux distribution includes thousands of programs.  It would
 
be quite difficult for a re-distributor with a large patent portfolio to
 
review all those programs against that portfolio every time it receives
 
and passes on a new version of the distribution.  Moreover, this question
 
raises a strategic issue. If the GPLv3 patent license requirements
 
convince patent-holding companies to remain outside the distribution
 
path of all GPL-covered software, then these requirements, no matter how
 
strong, will cover few patents. 
 

	
 
GPLv3 therefore makes a partial concession
 
which would lead these companies to feel secure in doing the
 
distribution themselves. GPLv3~\S11
 
applies only to those distributors that have
 
modified the program.  The other changes we have made in sections 10 and
 
11 provide strengthened defenses against patent assertion and compensate
 
partly for this concession. 
 

	
 
Therefore, GPLv3~\S11 introduces the terms ``contributor'', ``contributor version'', and
 
``essential patent claims'', which are
 
used in the GPLv3~\S11\P3.   Viewed from the perspective of a recipient of the
 
Program, contributors include all the copyright holders for the Program,
 
other than copyright holders of material originally licensed under non-GPL
 
terms and later incorporated into a GPL-covered work.  The contributors are
 
therefore the initial GPLv3 licensors of the Program and all subsequent
 
upstream licensors who convey, under the terms of GPLv3~\S5, modified covered
 
works.
 
Thus, the ``contributor version'' includes the material the contributor has copied from the
 
upstream version that the contributor has modified.  GPLv3~\S11\P3
 
 does not apply to those that redistribute the program
 
without change.\footnote{An implied patent license from the distributor,
 
however, often arises.  See \S~\ref{gpl-implied-patent-grant} in this tutorial}
 
In other words, the ``contributor version'' includes not just
 
the material added or altered by the contributor, but also the pre-existing
 
material the contributor copied from the upstream version and retained in the
 
modified version.  (GPLv3's usage of ``contributor'' and ``contribution'' should
 
not be confused with the various other ways in which those terms are used in
 
certain other free software licenses.\footnote{Cf., e.g., Apache License,
 
  version 2.0, section 1; Eclipse Public License, version 1.0, section 1;
 
  Mozilla Public License, version 1.1, section 1.1.})
 

	
 
Some details of the ``essential patent claims'' definition deserve special
 
mention.  ``Essential patent claims'', for a given party, are a subset of the
 
claims ``owned or controlled'' by the party.  They do include sublicensable
 
claims that have been licensed to the contributor by a third
 
party.\footnote{This issue is typically handled in other software freedom
 
  licenses having patent licensing provisions by use of the unhelpful term
 
  ``licensable,'' which is either left undefined or is given an ambiguous
 
  definition.}  Most commercial patent license agreements that permit
 
sublicensing do so under restrictive terms that are inconsistent with the
 
requirements of the GPL\@.  For example, some patent licenses allow the
 
patent licensee to sublicense but require collection of royalties from any
 
sublicensees.  The patent licensee could not distribute a GPL-covered program
 
and grant the recipient a patent sublicense for the program without violating
 
section 12 of GPLv3.\footnote{GPLv3 also provides an example in section 12
 
  that makes this point clear.}  In rare cases, however, a conveying party
 
can freely grant patent sublicenses to downstream recipients without
 
violating the GPL\@.
 

	
 
Additionally, ``essential patent claims'' are those patents ``that would be
 
infringed by some manner, permitted by this License, of making, using, or
 
selling the work''.  This intends to make clear that a patent claim is
 
``essential'' if some mode of usage would infringe that claim, even if there
 
are other modes of usage that would not infringe.
 

	
 
Finally, ``essential patent claims \ldots do not include
 
claims that would be infringed only as a consequence of further
 
modification of the work.''  The set of essential patent
 
claims licensed  is fixed by the
 
particular version of the work that was contributed.  The claim set
 
cannot expand as a work is further modified downstream.  (If it could,
 
then any software patent claim would be included, since any software
 
patent claim can be infringed by some further modification of the
 
work.)\footnote{However, ``the work'' should not be understood to be
 
restricted to a particular mechanical affixation of, or medium for
 
distributing, a program, where the same program might be provided in
 
other forms or in other ways that may be captured by other patent claims
 
held by the contributor.}
 

	
 
\medskip
 

	
 
Ideally, this contributor patent policy will result in fairly frequent licensing of patent
 
claims by contributors.  A contributor is charged with awareness of the fact
 
that it has modified a work and provided it to others; no act of contribution
 
should be treated as inadvertent.  GPLv3's rule also requires no more work, for a
 
contributor, than the weaker rule proposed by the patent holders.  Under
 
their rule, the contributor must always compare the entire work against its
 
patent portfolio to determine whether the combination of the modifications
 
with the remainder of the work cause it to read on any of the contributor's
 
patent claims.
 

	
 
Finally, GPLv3's explicit patent license for contributors has an interesting
 
and useful side effect.  When a company with a large number of such claims
 
acquires the program's modifier, all claims held or thereafter acquired by
 
the purchaser are automatically licensed under this provision.  For example,
 
Microsoft's acquisition of Nokia resulted in the automatic licensing of all
 
Microsoft patent claims now or hereafter acquired which read on any
 
contributor version of any GPLv3 program ever modified by Nokia.
 

	
 
\subsection{Conveyors' Patent Licensing}
 

	
 
The remaining patent licensing in GPLv3 deals with patent licenses that are
 
granted by conveyance.  The licensing is not as complete or far reaching as
 
the contributor patent licenses discussed in the preceding section.
 

	
 
The term ``patent license,'' as used in GPLv3~\S11\P4--6, is not meant to be
 
confined to agreements formally identified or classified as patent licenses.
 
GPLv3~\S11\P3  makes this clear by defining ``patent
 
license,'' for purposes of the subsequent three paragraphs, as ``any express
 
agreement or commitment, however denominated, not to enforce a patent
 
(such as an express permission to practice a patent or covenant not to
 
sue for patent infringement)''
 

	
 
% FIXME-LATER: I want to ask Fontana about this before adding it.
 

	
 
% The definition does not include patent licenses that arise by
 
% implication or operation of law, because the third through fifth paragraphs
 
% of section 11 are specifically concerned with explicit promises that purport
 
% to be legally enforceable.
 

	
 
GPLv3~\S11\P5 is commonly called GPLv3's downstream shielding provision.  It
 
responds particularly to the problem of exclusive deals between patent
 
holders and distributors, which threaten to distort the free software
 
distribution system in a manner adverse to developers and users.  The
 
fundamental idea is to make a trade-off between assuring a patent license for
 
downstream and making  (possibly patent-encumbered) CCS publicly available.
 

	
 
Simply put, in nearly all cases in which the ``knowingly relying'' test is
 
met, the patent license will indeed not be sublicensable or generally
 
available to all on free terms.  If, on the other hand, the patent license is
 
generally available under terms consistent with the requirements of the GPL,
 
the distributor is automatically in compliance, because the patent license
 
has already been extended to all downstream recipients.  Finally, if the
 
patent license is sublicensable on GPL-consistent terms, the distributor may
 
choose to grant sublicenses to downstream recipients instead of causing the
 
CCS to be publicly available.  (In such a case, if the distributor is also a
 
contributor, it will already have granted a patent sublicense anyway, and so
 
it need not do anything further to comply with the third paragraph.)
 

	
 
Admittedly, public disclosure of CCS is not necessarily required by other
 
sections of the GPL, and the FSF in drafting GPLv3 did not necessarily wish
 
to impose a general requirement to make source code available to all, which
 
has never been a GPL condition.  However, many vendors who produce products
 
that include copylefted software, and who are most likely to be affected by the
 
downstream shielding provision, lobbied for the addition of the source code
 
availability option, so it remains.
 

	
 
% FIXME-LATER: This text is likely redundant and a bit confusing.  Needs work
 
% to use.
 

	
 
%% If A takes a patent license from B that benefits A only, rather than A's
 
%% customers or their distributees, A imposes risk from B's patents on others
 
%% that it does not suffer itself. Under many circumstances, this is an
 
%% acceptable outcome. If, however, A is the only possible source of the
 
%% program, by taking such a license and distributing in reliance on it, A is in
 
%% effect helping B to ``take the program private.''
 

	
 
% FIXME-LATER: end
 

	
 
Meanwhile, two specific alternatives to the source code availability option
 
are also available. The distributor may comply by disclaiming the patent
 
license it has been granted for the conveyed work, or by arranging to extend
 
the patent license to downstream recipients.\footnote{The latter option, if
 
  chosen, must be done ``in a manner consistent with the requirements of this
 
  License''; for example, it is unavailable if extension of the patent
 
  license would result in a violation of GPLv3~\S 12.}  The GPL is intended
 
to permit private distribution as well as public distribution, and the
 
addition of these options ensures that this remains the case, even though it
 
remains likely that distributors in this situation will usually choose the
 
source code availability option.
 

	
 
Note that GPLv3~\S11\P5 is activated only if the CCS is not already otherwise
 
publicly available.  (Most often it will, in fact, already be available on
 
some network server operated by a third party.)  Even if it is not already
 
available, the option to ``cause the Corresponding Source to be so
 
available'' can then be satisfied by verifying that a third party has acted
 
to make it available.  That is to say, the affected distributor need not
 
itself host the CCS to take advantage of the source code availability option.
 
This subtlety may help the distributor avoid certain peculiar assumptions of
 
liability.
 

	
 
Note that GPLv3~\S11\P6--7 are designed to stop distributors from colluding with
 
third parties to offer selective patent protection.  GPLv3 is designed to
 
ensure that all users receive the same rights; arrangements that circumvent
 
this make a mockery of free software, and we must do everything in our power
 
to stop them.
 

	
 
First, GPLv3~\S11\P6 states that any license that protects some recipients of
 
GPL'd software must be extended to all recipients of the software.  
 
If conveyors arrange to provide patent
 
protection to some of the people who get the software from you, that
 
protection is automatically extended to everyone who receives the software,
 
no matter how they get it. 
 

	
 
Second, GPLv3~\S11\P7
 
prohibit anyone who made such an agreement from distributing software
 
released under GPLv3.    Conveyors are prohibited from
 
distributing software under GPLv3 if the conveyor makes an agreement of that
 
nature in the future.
 

	
 
The date in GPLv3~\S11\P7 likely seems arbitrary to those who did not follow
 
the GPLv3 drafting process.  This issue was hotly debated during the drafting of
 
GPLv3, but ultimately one specific deal of this type --- a deal between Microsoft
 
and Novell for Microsoft to provide so-called ``coupons'' to Microsoft customers to redeem
 
for copies of Novell's GNU/Linux distribution with a Microsoft patent license -- was
 
designed to be excluded.
 

	
 
The main reason for this was a tactical decision by the FSF.  FSF believed they can do more to
 
protect the community by allowing Novell to use software under GPLv3
0 comments (0 inline, 0 general)