Changeset - a2d90d4b73ff
[Not reviewed]
Merge master next
0 2 0
Bradley Kuhn (bkuhn) - 6 years ago 2018-09-26 17:31:16
bkuhn@ebb.org
Merge branch 'next'

New section regarding GPLv2 Irrevocability is ready to go live.
2 files changed with 120 insertions and 4 deletions:
0 comments (0 inline, 0 general)
comprehensive-gpl-guide.tex
Show inline comments
 
% comprehensive-gpl-guide.tex                                    -*- LaTeX -*-
 
%
 
% Toplevel file to build the entire book.
 
\documentclass[10pt, letterpaper, openany, oneside]{book}
 
% I'm somewhat convinced that this book would be better formatted using
 
%  the memoir class :
 
%    http://www.ctan.org/pkg/memoir
 
%   http://mirror.unl.edu/ctan/macros/latex/contrib/memoir/memman.pdf
 

	
 
% For the moment, I've thrown in fancychap because I don't have time to
 
% research memoir.
 

	
 

	
 
% FIXME: Some overall formatting hacks that would really help:
 

	
 
%   * I have started using  \hyperref[LABEL]{text} extensively, which seems
 
%     to work great in the PDF and HTML versions, but in the Postscript
 
%     version, the link lost entirely.  I think we need an additional command
 
%     to replace \hyperref which takes an optional third argument that will
 
%     insert additional text only when generating print versions, such as:
 
%      \newhyperref[GPLv2s3]{the requirements for binary distribution under
 
%      GPLv2}{(see section~\ref*{GPLv2s3} for more information)}
 
%
 
%     This is a careful balance, because it'd be all too easy to over-pepper
 
%     the printed version with back/forward references, but there are
 
%     probably times when this is useful.
 

	
 
%   * Similar issue: \href{} is well known not to carry the URLs in the print
 
%     versions.  Adding a footnote with the URL for the print version is
 
%     probably right.  (or maybe a References page?)
 

	
 
%   * The text is extremely inconsistent regarding formatting of code and
 
%     commands.  The following varied different methods have been used:
 
%         + the \verb%..% inline form
 
%         + verbatim environment (i.e., \begin{verbatim}
 
%         + {\tt }
 
%         + \texttt{}
 
%         + the lstlisting environment (i.e., \begin{lstlisting}
 
%     These should be made consistent, using only two forms: one for line and
 
%     one for a long quoted section.
 

	
 

	
 

	
 
% FIXME: s/GPL enforcers/COGEOs/g
 

	
 
%        (the term coined later but not used throughout) This can't be done
 
%        by rote, since it may not be appropriate everywhere and shouldn't be
 
%        used *before* it's coined in the early portions of
 
%        compliance-guide.tex (and it's probably difficult to coin it earlier
 
%        anyway).  BTW, I admit COGEOs isn't the best acronym, but I started
 
%        with ``Community Enforcement Organizations'', which makes CEO, which
 
%        is worse. :)  My other opting was   COEO, which seemed too close to
 
%        CEO.  Suggestions welcome.
 

	
 
\usepackage{listings}
 
\usepackage{enumerate}
 
\usepackage{enumitem}
 
\usepackage[Conny]{fncychap}
 
\usepackage[dvips]{graphicx}
 
\usepackage[verbose, twoside, dvips,
 
              paperwidth=8.5in, paperheight=11in,
 
              left=1in, right=1in, top=1.25in, bottom=.75in,
 
           ]{geometry}
 
% Make sure hyperref is last in the package list.  Order matters here, See:
 
%   http://tex.stackexchange.com/questions/77886/fncychap-and-hyperref-messes-up-page-references
 
\usepackage{hyperref}
 

	
 
\newcommand{\tutorialpartsplit}[2]{#2}
 

	
 
%\input{no-numbers-on-table-of-contents}
 
\providecommand{\hrefnofollow}[2]{\href{#1}{#2}}
 

	
 
\hypersetup{pdfinfo={Title={Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide}}}
 

	
 
    \begin{document}
 

	
 
\pagestyle{plain}
 
\pagenumbering{roman}
 

	
 
\frontmatter
 

	
 
\begin{titlepage}
 

	
 
\begin{center}
 

	
 
{\Huge
 
{\sc Copyleft and the  \\
 

	
 
GNU General Public License:
 

	
 
\vspace{.25in}
 

	
 
A Comprehensive Tutorial \\
 

	
 
\vspace{.1in}
 

	
 
and Guide
 
}}
 
\vfill
 

	
 
{\parindent 0in
 
\begin{tabbing}
 
Copyright \= \copyright{} 2003--2005, 2008, 2014--2015 \hspace{1.mm} \=  \kill
 
Copyright \> \copyright{} 2003--2005, 2008, 2014--2015 \>  Bradley M. Kuhn. \\
 
Copyright \= \copyright{} 2003--2005, 2008, 2014--2015, 2018 \hspace{1.mm} \=  \kill
 
Copyright \> \copyright{} 2018 \>  Chestek Legal. \\
 
Copyright \> \copyright{} 2003--2005, 2008, 2014--2015, 2018 \>  Bradley M. Kuhn. \\
 
Copyright \> \copyright{} 2014--2015 \>  Anthony K. Sebro, Jr. \\
 
Copyright \= \copyright{} 2014 \> Denver Gingerich. \\
 
Copyright \= \copyright{} 2003--2007, 2014 \>  Free Software Foundation, Inc. \\
 
Copyright \> \copyright{} 2008, 2014 \>  Software Freedom Law Center. \\
 
\end{tabbing}
 

	
 
\vspace{.3in}
 

	
 
The copyright holders grant the freedom to copy, modify, convey,
 
adapt, and/or redistribute this work (except
 
Appendices~\ref{GPLv2-full-text}--\ref{AGPLv3-full-text}) under the terms of the Creative Commons
 
Attribution Share Alike 4.0 International License.  A copy of that license is
 
available at \url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.
 

	
 
Appendices~\ref{GPLv2-full-text}--\ref{AGPLv3-full-text} include copies of the texts of various licenses published
 
by the FSF, and they are all licensed under the license, ``Everyone is permitted
 
to copy and distribute verbatim copies of this license document, but changing
 
it is not allowed.''.  However, those who seek to make modified versions of
 
those licenses should note the
 
\href{https://www.gnu.org/licenses/gpl-faq.html#ModifyGPL}{explanation given in the GPL FAQ}.
 

	
 
\vfill
 

	
 
As a public, collaborative project, this Guide is primarily composed of the
 
many contributions received via its
 
\href{https://k.copyleft.org/guide/files/master/CONTRIBUTING.md}{public
 
  contribution process}.  Please
 
\href{https://k.copyleft.org/guide/changelog/master/}{review its
 
  Git logs} for full documentation of all contributions, and
 
Appendix~\ref{third-party-citation-list}
 
  contains a list of third-party works from which some material herein was
 
adapted.
 

	
 
The most recent version is
 
available online at \url{https://copyleft.org/guide/}.  Patches
 
are indeed welcome to this material.  Sources can be found in the Git
 
repository at \url{https://k.copyleft.org/guide/}.
 
}
 
\end{center}
 

	
 
\end{titlepage}
 

	
 
\tableofcontents
 

	
 
\chapter{Preface}
 

	
 
This tutorial is the culmination of nearly a decade of studying and writing
 
about software freedom licensing and the GPL\@.  Each part of this tutorial
 
is a course unto itself, educating the reader on a myriad of topics from the
 
deep details of the GPLv2 and GPLv3, common business models in the copyleft
 
licensing area (both the friendly and unfriendly kind), best practices for
 
compliance with the GPL, for engineers, managers, and lawyers, as well as
 
real-world case studies of GPL enforcement matters.
 

	
 
It is unlikely that all the information herein is necessary to learn all at
 
once, and therefore this tutorial likely serves best as a reference book.
 
The material herein has been used as the basis for numerous live tutorials
 
and discussion groups since 2002, and the materials have been periodically
 
updated.   They likely stand on their own as excellent reference material.
 

	
 
However, if you are reading these course materials without attending a live
 
tutorial session, please note that this material is merely a summary of the
 
highlights of the various CLE and other tutorial courses based on this
 
material.  Please be aware that during the actual courses, class discussion
 
and presentation supplements this printed curriculum.  Simply reading this
 
material is \textbf{not equivalent} to attending a course.
 

	
 
\mainmatter
 

	
 
% FIXME: We need an Introduction.  I think ideally it goes here, before Part
 
%  I.  The introduction should cover initially:
 
%
 
%
 
%     * Why we cover the topics in the order that we do, in particular, why
 
%       we discuss all GPLv2 before mentioning  GPLv3 (i.e., explain why we
 
%       take a diachronic approach to study of GPL).
 
%
 
%     * It should briefly discuss Free Culture / Software Freedom stuff.
 
%       Maybe some early material currently living in gpl-lgpl.tex should move
 
%       to the introduction, maybe not.  The goal is to prepare for the
 
%       moment when we can merge in material about CC-BY-SA.
 

	
 
\input{gpl-lgpl}
 

	
 
\input{compliance-guide}
 

	
 
\input{enforcement-case-studies}
 

	
 
\appendix
 

	
 
\part{Appendices}
 

	
 
\input{third-party-citations}
 

	
 
\input{license-texts}
 

	
 

	
 
\end{document}
gpl-lgpl.tex
Show inline comments
...
 
@@ -1779,928 +1779,1043 @@ requirements of GPLv2~\S2 (and GPLv2~\S3, which will be discussed next) are
 
centered around two different copyright controls: both modification
 
\emph{and} distribution.  As such, GPLv2~\S2's requirements need only be met
 
when a modified version is distributed; one need not follow them for modified
 
versions that are not distributed.\footnote{As a matter of best practice, it's
 
  useful to assume that all software may eventually be distributed later,
 
  even if there no plans for distribution at this time.  Too often, GPL
 
  violations occur because of a late distribution decision of software that
 
  was otherwise never intended for distribution.}
 

	
 
However, the careful reader of GPLv2 will notice that, unlike GPLv3, no other
 
clauses of the license actually give explicit permission to make private
 
modifications.  Since modification of software is a control governed by
 
copyright, a modifier needs permission from the copyright holder to engage in
 
that activity.
 

	
 
In practice, however, traditional GPLv2 interpretation has always assumed
 
that blanket permission to create non-distributed modified versions was
 
available, and the
 
\href{http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic}{FSF
 
  has long opined that distribution of modified versions is never mandatory}.
 
This issue is one of many where GPLv3 clarifies in explicit text the implicit
 
policy and intent that was solidified via long-standing interpretation of
 
GPLv2.
 

	
 
\section{GPLv2~\S3: Producing Binaries}
 
\label{GPLv2s3}
 

	
 
Software is a strange beast when compared to other copyrightable works.
 
It is currently impossible to make a film or a book that can be truly
 
obscured.  Ultimately, the full text of a novel, even one written by
 
William Faulkner, must be presented to the reader as words in some
 
human-readable language so that they can enjoy the work.  A film, even one
 
directed by David Lynch, must be perceptible by human eyes and ears to
 
have any value.
 

	
 
Software is not so.  While the source code --- the human-readable
 
representation of software --- is of keen interest to programmers, users and
 
programmers alike cannot make the proper use of software in that
 
human-readable form.  Binary code --- the ones and zeros that the computer
 
can understand --- must be predicable and attainable for the software to
 
be fully useful.  Without the binaries, be they in object or executable
 
form, the software serves only the didactic purposes of computer science.
 

	
 
Under copyright law, binary representations of the software are simply
 
modified versions (and/or derivative works) of the source code.  Applying a systematic process (i.e.,
 
``compilation''\footnote{``Compilation'' in this context refers to the
 
  automated computing process of converting source code into binaries.  It
 
  has absolutely nothing to do with the term ``compilation'' in copyright statues.}) to a work of source code yields binary code. The binary
 
code is now a new work of expression fixed in the tangible medium of
 
electronic file storage.
 

	
 
Therefore, for GPL'd software to be useful, the GPL, since it governs the
 
rules for creation of modified works, must grant permission for the
 
generation of binaries.  Furthermore, notwithstanding the relative
 
popularity of source-based GNU/Linux distributions like Gentoo, users find
 
it extremely convenient to receive distribution of binary software.  Such
 
distribution is the redistribution of modified works of the software's
 
source code.  GPLv2~\S3 addresses the matter of creation and distribution of
 
binary versions.
 

	
 
Under GPLv2~\S3, binary versions may be created and distributed under the
 
terms of GPLv2~\S1--2, so all the material previously discussed applies
 
here.  However, GPLv2~\S3 must go a bit further.  Access to the software's
 
source code is an incontestable prerequisite for the exercise of the
 
fundamental freedoms to modify and improve the software.  Making even
 
the most trivial changes to a software program at the binary level is
 
effectively impossible.  GPLv2~\S3 must ensure that the binaries are never
 
distributed without the source code, so that these freedoms are passed
 
through the distribution chain.
 

	
 
GPLv2~\S3 permits distribution of binaries, and then offers three options for
 
distribution of source code along with binaries. The most common and the
 
least complicated is the option given under GPLv2~\S3(a).
 

	
 
\label{GPLv2s3a}
 
GPLv2~\S3(a) offers the option to directly accompany the source code alongside
 
the distribution of the binaries.  This is by far the most convenient
 
option for most distributors, because it means that the source-code
 
provision obligations are fully completed at the time of binary
 
distribution (more on that later).
 

	
 
\subsection{Complete, Corresponding Source (CCS)}
 

	
 
Under GPLv2~\S3(a), the source code provided must be the ``corresponding source
 
code.''  Here ``corresponding'' primarily means that the source code
 
provided must be that code used to produce the binaries being distributed.
 
That source code must also be ``complete''.   GPLv2~\S3's penultimate paragraph
 
explains in detail what is meant by ``complete''.  In essence, it is all
 
the material that a programmer of average skill would need to actually use
 
the source code to produce the binaries she has received.  Complete source
 
is required so that, if the licensee chooses, she should be able to
 
exercise her freedoms to modify and redistribute changes.  Without the
 
complete source, it would not be possible to make changes that were
 
actually directly derived from the version received.
 

	
 
Based on the appearance of those two words, GPL theorists will often refer to
 
the source code required under the previsions of this section as ``Complete,
 
Corresponding Source'', sometimes abbreviated as CCS\@.  CCS is not a formal,
 
defined term in GPLv2, but rather, GPL theorists coined the acronym CCS to
 
embody not just the concepts of ``complete'' and ``corresponding'' as found
 
in GPLv2, but the entirety of GPLv2's requirements for source code
 
provisioning.  In other words, GPL theorists might say: ``the company
 
provided some source, but it wasn't CCS'', which would mean the source code
 
failed in some ways to meet some term of GPLv2.
 

	
 
\label{GPLv2s3-build-scripts}
 

	
 
Indeed, CCS needs completely include not just that source which is directly
 
translated by the compiler into object code, but other materials necessary to
 
convert the source into equivalent binaries.  Specifically, GPLv2~\S3
 
requires that the source code include ``meta-material'' like scripts,
 
interface definitions, and other material that is used to ``control
 
compilation and installation'' of the binaries.  In this manner, those
 
further down the distribution chain are assured that they have the unabated
 
freedom to build their own modified works from the sources provided.
 

	
 
This requirement is not merely of theoretical value.  If you pay a high price
 
for a copy of GPL'd binaries (which comes with CCS, of course), you have the
 
freedom to redistribute that work at any fee you choose, or not at all.
 
Sometimes, companies attempt a GPL-violating cozenage whereby they produce
 
very specialized binaries (perhaps for an obscure architecture).  They then
 
give source code that does correspond, but withhold the ``incantations'' and
 
build plans they used to make that source compile into the specialized
 
binaries.  Such distributions violate GPL, since the downstream users cannot
 
effectively ``control compilation and installation'' of the binaries.
 

	
 
\subsection{Additional Source Provision Options}
 

	
 
Software distribution comes in many
 
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.
 
and this termination clause becomes clear. (See~\ref{gplv2-irrevocable} for
 
expanded discussion of GPLv2 irrevocability.)
 

	
 
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 Irrevocability}
 
\label{gplv2-irrevocable}
 

	
 
This section digresses briefly to examine the manner in which GPLv2\S\S~4--6
 
interact together to assure that the license grant is irrevocable.
 
There are two legal theories why a contributor cannot terminate their license
 
grant. First is an argument that the text of the GPL prevents it; second is
 
that a contributor would be estopped from succeeding on an infringement claim
 
for continued use of the code even if it wasn't removed.
 

	
 
\subsection{The text of the GPLv2}
 

	
 
The GPLv2 have several provisions that, when taken together, can be construed
 
as an irrevocable license from each contributor. First, the GPLv2 says ``by
 
\emph{modifying} or distributing the Program (or any work based on the Program), you
 
indicate your acceptance of this License to do so, and all its terms and
 
conditions for copying, distributing or modifying the Program or works based
 
on it'' (GPLv2\S5, emphasis added).  A contributor by definition is modifying
 
the code and therefore has agreed to all the terms in the GPLv2, which
 
includes the web of mechanisms in the GPLv2 that ensure the code can be used
 
by all.
 

	
 
More specifically, the downstream license grant says ``the recipient
 
automatically receives a license from the original licensor to copy,
 
distribute or modify the Program subject to these terms and conditions.''
 
(GPLv2\S6). So in this step, the contributor has granted a license to the
 
downstream, on the condition that the downstream complies with the license
 
terms.
 

	
 
That license granted to downstream is irrevocable, again provided that the
 
downstream user complies with the license terms: ``[P]arties who have
 
received copies, or rights, from you under this License will not have their
 
licenses terminated so long as such parties remain in full compliance''
 
(GPLv2\S4).
 

	
 
Thus, anyone downstream of the contributor (which is anyone using the
 
contributor's code), has an irrevocable license from the contributor. A
 
contributor may claim to revoke their grant, and subsequently sue for
 
copyright infringement, but a court would likely find the revocation was
 
ineffective and the downstream user had a valid license defense to a claim of
 
infringement.
 

	
 
Nevertheless, for purposes of argument, we will assume that for some
 
reason the GPLv2 is not enforceable against the contributor\footnote{For
 
  example, the argument has been made that there may be a failure of
 
  consideration on the part of the contributor. While \textit{Jacobsen
 
    v. Katzer}, 535 F.3d 1373 (Fed. Cir. 2008) is accepted as holding that
 
  there is consideration received by the contributor in a FOSS license, the
 
  posture of the case was one where the contributor advocated for the theory,
 
  not against it. The author is not aware of any other decisions that have analyzed
 
  the question in any depth, so it perhaps could be challenged in the right
 
  factual situation.}, or that the irrevocable license can be
 
revoked\footnote{A contract without a definable duration can be terminated on
 
  reasonable notice. \textit{Great W. Distillery Prod. v. John A. Wathen Distillery
 
  Co.}, 10 Cal. 2d 442, 447, 74 P.2d 745, 747 (1937). The term nevertheless
 
  can be a term of indefinite length where its continuing effect is tied to
 
  the conduct of the parties. \emph{Id}.}. In that case, the application of
 
promissory estoppel will likely mean that the contributor still cannot
 
enforce their copyright against downstream users.
 

	
 
\subsection{Promissory estoppel}
 

	
 
``Promissory estoppel'' is a legal theory that says, under some
 
circumstances, a promise is enforceable against the promisee even after the
 
promisee tries to renege on the promise. The test for how and when promissory
 
estoppel applies differs from state to state, but generally where there is a
 
``promise which the promisor should reasonably expect to induce action or
 
forbearance on the part of the promisee or a third person and which does
 
induce such action or forbearance is binding if injustice can be avoided only
 
by enforcement of the promise.''\footnote{\textit{Kajima/Ray Wilson v. Los Angeles
 
Cty. Metro. Transp. Auth.}, 23 Cal. 4th 305, 310, 1 P.3d 63, 66 (2000), \emph{citing}
 
Restatement (Second) of Contracts \S 90(1) (1979).} Breaking it down, it is:
 
\begin{enumerate}
 
\item where there is a clear and definite promise;
 
\item where the promisor has a reasonable expectation that the offer will
 
  induce action or forbearance on the part of the promisee;
 

	
 
\item which does induce actual and reasonable action or forbearance by the promisee; and
 

	
 
\item which causes a detriment which can only be avoided by the enforcement
 
  of the promise.
 
\end{enumerate}
 

	
 
In this case, the promisor is the contributor. This should be an easy
 
standard to meet in any widely used software.
 
\begin{enumerate}
 
\item The promise is contained in the GPL, which is a promise that one can
 
  continue to use the licensed software as long as the terms of the license
 
  are met.
 

	
 

	
 
\item A contributor knows that there is a broad user base and users consume
 
  the software relying on the grant in the GPL as assuring their continued
 
  ability to use the software (one might even say it is the \textit{sine qua
 
    non} of the intent of the GPL).
 

	
 
\item Users do, in fact, rely on the promises in the GPL, as they ingest the software
 
  and base their businesses on their continued ability to use the software.
 

	
 
\item Whether the user will suffer detriment is case-specific, but using
 
  Linux, a software program that is often fundamental to the operation of a
 
  business, as an example, the loss of its use would have a significantly
 
  detrimental, perhaps even fatal, effect on the continued operation of the
 
  business.
 

	
 
\end{enumerate}
 

	
 
\subsection{Conclusion}
 

	
 
Whether as a matter of a straightforward contractual obligation, or as a
 
matter of promissory estoppel, a contributor's attempt to revoke a copyright
 
license grant and then enforce their copyright against a user is highly
 
unlikely to succeed.
 

	
 
\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}, which most of the USA's states and commonwealths have adopted as their local
 
law, allows disclaimers of warranty, provided that the disclaimer is ``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}.}
 

	
 
% FIXME: Should UCITA be mentioned anywhere in here?  It was previously
 
% mentioned elsewhere in the tutorial but it was out of context and not
 
% useful.  If it should be mentioned anywhere, here is probably the spot, but
 
% it's not clear we should mention it at all, since it's specific just to two
 
% state/commonwealths in the USA: MD and VA.
 

	
 
Critics have occasionally questioned GPL's enforceability in some jurisdictions because its
 
disclaimer of warranties is impermissibly broad.  However,
 
critics
 
have generally failed to articulate specific precedents in their
 
jurisdictions that would directly indicate a problem with GPL's warranty
 
disclaimer.  Meanwhile,
 
\href{http://www.cisg.law.pace.edu/cisg/text/treaty.html#35}{Article 35 of
 
  the United Nations Convention on Contracts for the International Sale of
 
  Goods} (often abbreviated ``CISG'', which
 
\href{https://treaties.un.org/Pages/ViewDetails.aspx?src=TREATY&id=228&chapter=10&lang=en}{many
 
  countries have adopted}) permits the disclaimer of warranties, so
 
jurisdictions adopting this treaty allow some form of warranty
 
disclaimer\footnote{Scholars continue to debate to what extent CISG applies to software
 
  licenses.  For example, Diedrich concluded that ``CISG is prima facie
 
  applicable to international transactions involving the transfer of computer
 
  software for a price'', but Sono disagrees with this ``prevailing view'',
 
  presenting an ``analysis [that] restricts the applicability of the CISG to
 
  software transactions by excluding `license contracts'''.  (See
 
  \href{http://www.cisg.law.pace.edu/cisg/biblio/diedrich1.html}{Frank
 
    Diedrich, \textit{The CISG and Computer Software Revisited}}, 6 Vindobona
 
  Journal of International Commercial Law and Arbitration, Supplement 55--75
 
  (2002), and
 
\href{http://www.cisg.law.pace.edu/cisg/biblio/sono6.html}{Hiroo Sono,
 
  \textit{The Applicability and Non-Applicability of the CISG to Software
 
    Transactions}}, Camilla B. Andersen \& Ulrich G. Schroeter eds., Sharing
 
International Commercial Law across National Boundaries: Festschrift for
 
Albert H. Kritzer on the Occasion of his Eightieth Birthday, Wildy, Simmonds
 
\& Hill Publishing (2008) 512--526.)}.
 
Nevertheless, to account for possible jurisdictional variances regarding this
 
or any other issue, 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 definition 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 internationalizes
 
on this issue by removing GPLv2's 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.
 

	
...
 
@@ -4504,511 +4619,511 @@ first but ``yes'' to the second, you are in a gray area between ``work
 
based on the library'' and a ``work that uses the library.''
 

	
 
You can also perform a similar same analysis through careful consideration of
 
the license text itself.  LGPLv2~\S2(a) states that if a licensed work is a
 
software library (defined in LGPLv2~\S0 as ``a collection of software
 
functions and/or data prepared so as to be conveniently linked with
 
application programs (which use some of those functions and data) to form
 
executables''), you have permission to distribute modified versions only if
 
those versions are themselves libraries.  LGPLv2.1 code can therefore not be
 
compliantly taken from its context in a library and placed in a non-library
 
modified version or work based on the work.  For its part, LGPLv2~\S6 does
 
not provide an exception for this rule: a combination may be made of a
 
modified version of an LGPL'd library with other code, but the LGPL'd code
 
must continue to be structured as a library, and to that library the terms of
 
the license continue to apply.
 

	
 

	
 
Either way you view the rules, these issues are admittedly complicated.
 
Nevertheless, In our years of work with the LGPLv2.1, however, we have never
 
seen a work of software that was not clearly one or the other; the line is
 
quite bright. At times, though, we have seen cases where a particularly large
 
work in some ways seemed to be both to both a work that used the library and
 
a work based on the library. We overcame this problem by dividing the work
 
into smaller subunits.  It was soon discovered that what we actually had were
 
three distinct components: the original LGPL'd work, a specific set of works
 
that used that library, and a specific set of works that were based on the
 
library. Once such distinctions are established, the licensing for each
 
component can be considered independently and the LGPLv2.1 applied to each
 
work as prescribed.
 

	
 
Finally, note though that, since the LGPLv2.1 can be easily upgraded to
 
GPLv2-or-later, in the worst case you simply need to comply as if the
 
software was licensed under GPLv2.  The only reason you must consider the
 
question of whether you have a ``work that uses the library'' or a ``work
 
based on the library'' is when you wish to take advantage of the ``weak
 
copyleft'' effect of the Lesser GPL\@.  If GPLv2-or-later is an acceptable
 
license (i.e., if you plan to copyleft the entire work anyway), you may find
 
this an easier option.
 

	
 
\section{Subtleties in Defining the Application}
 

	
 
In our discussion of the definition of ``works that use the library,'' we
 
left out a few more complex details that relate to lower-level programming
 
details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities,
 
and it has been a source of great confusion. Part of the confusion comes
 
because a deep understanding of how compiler programs work is nearly
 
mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to
 
cover. It helps some to note that this is a border case that we cover in
 
the license only so that when such a border case is hit, the implications
 
of using the LGPL continue in the expected way.
 

	
 
To understand this subtle point, we must recall the way that a compiler
 
operates. The compiler first generates object code, which are the binary
 
representations of various programming modules. Each of those modules is
 
usually not useful by itself; it becomes useful to a user of a full program
 
when those modules are {\em linked\/} into a full binary executable.
 

	
 
As we have discussed, the assembly of modules can happen at compile-time
 
or at runtime. Legally, there is no distinction between the two --- both
 
create a modified version of the work by copying and combining portions of one work and
 
mixing them with another. However, under LGPL, there is a case in the
 
compilation process where the legal implications are different.
 
To understand this phenomenon, we consider that a ``work that uses the
 
library'' is typically one whose final binary is a work based on the Program,
 
but whose source is not.  However, sometimes, there
 
are cases where the object code --- that intermediate step between source
 
and final binary --- is a work created by copying and modifying code
 
from the LGPL'd software.
 

	
 
For efficiency, when a compiler turns source code into object code, it
 
sometimes places literal portions of the copyrighted library code into the
 
object code for an otherwise separate independent work. In the normal
 
scenario, the final combined work would not be created until final assembly and
 
linking of the executable occurred. However, when the compiler does this
 
efficiency optimization, at the intermediate object code step, a
 
combined work is created.
 

	
 
LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of
 
the license is clearly that simply compiling software to ``make use'' of
 
the library does not in itself cause the compiled work to be a ``work
 
based on the library.''  However, since the compiler copies verbatim,
 
copyrighted portions of the library into the object code for the otherwise
 
separate and independent work, it would actually cause that object file to be a
 
``work based on the library.''  It is not FSF's intent that a mere
 
compilation idiosyncrasy would change the requirements on the users of the
 
LGPLv2.1'd software. This paragraph removes that restriction, allowing the
 
implications of the license to be the same regardless of the specific
 
mechanisms the compiler uses underneath to create the ``work that uses the
 
library.''
 

	
 
As it turns out, we have only once had anyone worry about this specific
 
idiosyncrasy, because that particular vendor wanted to ship object code
 
(rather than final binaries) to their customers and was worried about
 
this edge condition. The intent of clarifying this edge condition is
 
primarily to quell the worries of software engineers who understand the
 
level of verbatim code copying that a compiler often does, and to help
 
them understand that the full implications of LGPLv2.1 are the same regardless
 
of the details of the compilation progress.
 

	
 
\section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}
 
\label{lgpl-section-6}
 
Now that we have established a good working definition of works that
 
``use'' and works that ``are based on'' the library, we will consider the
 
rules for distributing these two different works.
 

	
 
The rules for distributing ``works that use the library'' are covered in
 
LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release
 
of source when a binary version of the LGPL'd software is released. Of
 
course, it only requires that source code for the library itself be made
 
available. The work that ``uses'' the library need not be provided in
 
source form. However, there are also conditions in LGPLv2.1~\S6 to make sure
 
that a user who wishes to modify or update the library can do so.
 

	
 
LGPLv2.1~\S6 lists five choices with regard to supplying library source
 
and granting the freedom to modify that library source to users. We
 
will first consider the option given by \S~6(b), which describes the
 
most common way currently used for LGPLv2.1 compliance on a ``work that
 
uses the library.''
 

	
 
LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to
 
simply use a dynamically linked, shared library mechanism to link with the
 
library. This is by far the easiest and most straightforward option for
 
distribution. In this case, the executable of the work that uses the
 
library will contain only the ``stub code'' that is put in place by the
 
shared library mechanism, and at runtime the executable will combine with
 
the shared version of the library already resident on the user's computer.
 
If such a mechanism is used, it must allow the user to upgrade and
 
replace the library with interface-compatible versions and still be able
 
to use the ``work that uses the library.''  However, all modern shared
 
library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest
 
option, since it does not even require that the distributor of the ``work 
 
based on the library'' ship copies of the library itself.
 

	
 
LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library
 
mechanism cannot be used. It requires that the source for the library be
 
included, in the typical GPL fashion, but it also has a requirement beyond
 
that. The user must be able to exercise her freedom to modify the library
 
to its fullest extent, and that means recombining it with the ``work based
 
on the library.''  If the full binary is linked without a shared library
 
mechanism, the user must have available the object code for the ``work
 
based on the library,'' so that the user can relink the application and
 
build a new binary.
 

	
 
Almost all known LGPL'd distributions exercise either LGPLv2.1~\S6(a) or
 
LGPLv2.1~\S6(b).  However, LGPLv2.1~\S6 provides three other options.
 
LGPLv2.1~\S6(c) allows for a written offer for CCS (akin to
 
\hyperref[GPLv2s3b]{GPLv2~\S3(b)}).  CCS may also be distributed by network
 
under the terms of LGPLv2.1~\S6(c).  Furthermore, under LGPLv2.1~\S6(e) the
 
distributor may ``verify'' that the user has already received, or at least
 
that the distributor has already sent to this particular user, the relevant
 
source\footnote{Policy motivations for LGPLv2.1~\S6(d) are unclear, but it
 
  presumably intended to prevent requiring duplicate deliveries in ``whole
 
  distribution'' situations.}.
 

	
 
Finally, LGPLv3~\S6 also requires that:
 

	
 
\begin{quote}
 
    You must give prominent notice with each copy of the work that the
 
    Library is used in it and that the Library and its use are covered by
 
    this License. You must supply a copy of this License. If the work during
 
    execution displays copyright notices, you must include the copyright
 
    notice for the Library among them, as well as a reference directing the
 
    user to the copy of this License.
 
\end{quote}
 

	
 
This is not identical to the roughly parallel requirements of GPLv2 and
 
GPLv3. Compliance requires slightly different measures with respect to the
 
``credits'' or ``licenses'' or ``about'' screens in interactive programs.
 

	
 
\section{Distributing Works Based On the Library}
 

	
 
Essentially, ``works based on the library'' must be distributed under the
 
same conditions as works under full GPL\@. In fact, we note that 
 
LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.
 

	
 
There are, however, subtle differences and additions.  For example not only
 
is CCS required (as would be with normal versions of GPL), but also the CCS
 
provided must enable a developer to regenerate the modified version of the
 
entire combined work, using with a modified version of the LGPL'd work (as a
 
replacement for the version a distributor provided).  For example, LGPL'd
 
code is statically linked to a non-copyleft executable, the required source
 
code must also include sufficient material to split the distributed
 
executable and relink with a modified version of the library.
 

	
 
\section{And the Rest}
 

	
 
The remaining variations between the LGPL and the GPL cover the following
 
conditions:
 

	
 
\begin{itemize}
 

	
 
\item Allowing a licensing ``upgrade'' from the LGPL to the GPL\@ (in LGPLv2.1~\S3).
 
  Note, however, LGPLv2.1~\S3 allows relicensing of works under its terms
 
  instead under the terms of GPLv2-or-later.  This provides, for example, a
 
  pathway for those who do not want to use code under the requirements of
 
  LGPLv2.1 to do so under GPLv2 or GPLv3 at their discretion.
 

	
 
\item Binary distribution of the library only, covered in LGPLv2.1~\S4,
 
  which is effectively equivalent to LGPLv2.1~\S3
 

	
 
\item Creating aggregates of libraries that are separate and independent works from
 
  each other, and distributing them as a unit (in LGPLv2.1~\S7)
 

	
 
\end{itemize}
 

	
 

	
 
Due to time constraints, we cannot cover these additional terms in detail,
 
but they are mostly straightforward. The key to understanding LGPLv2.1 is
 
understanding the difference between a ``work based on the library'' and a
 
``work that uses the library.''  Once that distinction is clear, the
 
remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in
 
our more extensive GPL unit can be directly applied.
 

	
 
\chapter{LGPLv3}
 
\label{LGPLv3}
 

	
 
LGPLv3 was designed to rectify  architectural flaws in the GNU family of
 
licenses.  Historically , LGPLv2.1 was a textual modification of GPLv2.
 
Reconciliation of licensing terms upon combination of LGPLv2.1'd and GPLv2'd
 
works is cumbersome, from a licensing bookkeeping perspective.
 

	
 
LGPLv3 redresses this historical problem through extensive use of
 
\hyperref[GPLv3s7]{GPLv3~\S7}'s exception architecture.  LGPLv3 is therefore
 
a set of additional permission to GPLv3.
 

	
 
%FIXME: harken back to policy motivations of LGPL and how GPLv3 as a whole is
 
%always an option.
 

	
 
\section{Section 0: Additional Definitions}
 

	
 
LGPLv3~\S0 defines the ``Library'' -- a work that presents one or more
 
interfaces at which a ``use'' can be made by an ``Application.''  Class
 
inheritance is ``deemed'' a use of an interface.  An ``Application,'' which is
 
other program code using one or more ``Library'' interfaces can be combined
 
with the code on the other side of the interfaces it uses to form a
 
``Combined Work.''
 

	
 
\section{LGPLv3~\S1: Exception to GPLv3~\S3}
 

	
 
LGPLv3~\S1 excepts away the interference with use of LGPLv3 code as part of
 
``effective technological measures'' of access limitation for other copyrighted
 
works provided otherwise by GPLv3~\S3.
 

	
 
\section{LGPLv3~\S2: Conveying Modified Versions}
 

	
 
LGPLv3~\S2 continues to require, as LGPLv2.1~\S2(d) requires, that the Library
 
not be modified to require keys, tokens, tables, or other global non-argument
 
data unrelated to function. This is again stated as a ``good faith effort''
 
requirement, but failure to cure on notice is strong evidence of the absence
 
of good faith.  LGPLv3~\S2(b) permits removal of the permissions entirely (as
 
prescribed by GPLv3~\S7); however, such removal reduces the license of the
 
entire covered work back to pure GPLv3.   Thus, exercising LGPLv3~\S2(b) as a
 
compliance alternative to LGPLv3~\S2(a) likely creates more compliance
 
obligations than it removes.
 

	
 
\section{LGPLv3~\S3: Object Code Incorporating Material from Library Header Files}
 

	
 
LGPLv3~\S3's front matter assures incorporation of smaller header files into
 
non-copylefted object code can proceed unimpeded.  More complex
 
header files (those that do not meet the limitations provided in the
 
section), can still be incorporated into object code, a copy of appropriate
 
licensing information must accompany distribution (per LGPLv3~\S3(a--b).
 

	
 
%FIXME: talk about copyrightabilty lines and the like and why the ten line rule.
 

	
 
\section{LGPLv3~\S4: Combined Works}
 

	
 
LGPLv3~\S4 is the combination permission at the heart of LGPLv3. It restates
 
the license limitation provision of LGPLv2.1~\S2 to clarify that the terms on
 
the Combined Work may not prohibit user modification of the Library code, or
 
the debugging of such modifications to the Library code by means of whatever
 
reverse engineering is necessary.
 

	
 
LGPLv3~\S4(d)(0) contains the source provision requirement, for the Minimal
 
Corresponding Source, which ``means the Corresponding Source for the Combined
 
Work, excluding any source code for portions of the Combined Work that,
 
considered in isolation, are based on the Application, and not on the Linked
 
Version [of the Library]''. The alternative to the provision of source code is
 
distribution by way of the ``shared library'' mechanism under LGPLv3~\S4(d)(1),
 
described with respect to LGPLv2.1~\S6.
 

	
 
In addition, LGPLv3~\S4(e) requires the delivery of ``installation information''
 
required to install the modified version of the Library in ``user products''
 
under GPLv3~\S6. Where Library Minimal Corresponding Source is not made
 
available under LGPLv3~\S4(d)(1), LGPLv3~\S4(e) reaffirms that ``installation information''
 
must still be compliantly delivered under the terms of GPLv3~\S6.
 

	
 
All other provisions of GPLv3 are in force as previously described, and are
 
not excepted by the additional permission granted in LGPLv3.
 

	
 
If the distributor of the combined work intends not to distribute or offer
 
the source code of the LGPL'd components, the LGPL'd work must be separately
 
distributed (subject to source code delivery requirements as part of that
 
separate distribution) and packaged in a ``shared library'' mechanism, which
 
means that it:
 
\begin{quote}
 
\begin{enumerate}[label=4(d)(\arabic*):,ref=LGPLv3s4d\arabic*]
 
  \item uses at run time a copy of the library already present on
 
    the user's computer system, rather than copying library functions into
 
    the executable, and
 

	
 
  \item will operate properly with a modified version of
 
    the library, if the user installs one, as long as the modified version is
 
    interface-compatible with the version that the work was made with.
 
\end{enumerate}
 
\end{quote}
 

	
 
Taken all together, LGPLv3~\S4's primary implications for redistributors are
 
two-fold, as follows:
 
\begin{itemize}
 

	
 
\item  If you create a program that links through a shared library mechanism to
 
    a work that is separately distributed under LGPLv3, then you can
 
    distribute the resultant program under a license of your choice and you
 
    need not convey the LGPLv3'd work's source code. If you distribute the
 
    library along with your program, or are the separate distributor of the
 
    work in another context or as another product, you must distribute its
 
    corresponding source under the terms of LGPLv3 or GPLv3-or-later.
 

	
 
\item If you choose to statically link or otherwise combine your program with
 
    an LGPLv3'd work via mechanisms other than a shared library, you may choose your own license for the work provided the
 
    license terms limitations for user modification, reverse engineering and
 
    debugging are met, and given that the LGPL'd components are still
 
    governed by LGPL's terms. You must offer or provide CCS for the LGPL'd components. The source code
 
    material provided must be sufficient to regenerate the combined work with
 
    a user-modified version of the LGPL'd components.
 
\end{itemize}
 

	
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
% FIXME-LATER: There should be a chapter on GPL Exceptions generally.
 

	
 
% Here is some CC-By-SA text from another source that would make an
 
% acceptable introduction to a section on the GCC RTL Exception if such a
 
% chapter is written:
 

	
 
% This GCC Runtime Library Exception (``Exception'') is an additional
 
% permission as provided by Section 7 of GPLv3. The purpose of this Exception
 
% is to allow compilation of non-GPL (including proprietary) programs making
 
% use of the header files and runtime libraries covered by this Exception and
 
% containing code from the copyleft toolchain embedded by the compiler in the
 
% object code of the program as part of the compilation process. The GCC
 
% Runtime Library Exception covers any file that has a notice in its license
 
% headers stating that the exception applies.
 

	
 
% FIXME-LATER: end
 

	
 
\chapter{Integrating the GPL into Business Practices}
 

	
 
Since GPL'd software is now extremely prevalent through the industry, it
 
is useful to have some basic knowledge about using GPL'd software in
 
business and how to build business models around GPL'd software.
 

	
 
\section{Using GPL'd Software In-House}
 

	
 
As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial,
 
the GPL only governs the activities of copying, modifying and
 
distributing software programs that are not governed by the license.
 
Thus, in FSF's view, simply installing the software on a machine and
 
using it is not controlled or limited in any way by the GPL\@. Using Free
 
Software in general requires substantially fewer agreements and less
 
license compliance activity than any known proprietary software.
 

	
 
Even if a company engages heavily in copying the software throughout the
 
enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is
 
encouraged!  If the company simply deploys unmodified (or even modified)
 
Free Software throughout the organization for its employees to use, the
 
obligations under the license are very minimal. Using Free Software has a
 
substantially lower cost of ownership --- both in licensing fees and in
 
licensing checking and handling -- than the proprietary software
 
equivalents.
 

	
 
\section{Business Models}
 
\label{Business Models}
 

	
 
Using Free Software in house is certainly helpful, but a thriving
 
market for Free Software-oriented business models also exists. There is the
 
traditional model of selling copies of Free Software distributions.
 
Many companies make substantial revenue
 
from this model. Some choose this model because they have
 
found that for higher-end hardware, the profit made from proprietary
 
software licensing fees is negligible. The real profit is in the hardware,
 
but it is essential that software be stable, reliable and dependable, and
 
the users be allowed to have unfettered access to it. Free Software, and
 
GPLd software in particular, is the right choice. For instance IBM can be
 
GPL'd software in particular, is the right choice. For instance IBM can be
 
assured that proprietary versions of the their software will not exist to
 
compete on their hardware.
 

	
 

	
 
For example, charging a ``convenience fee'' for Free Software,
 
when set at a reasonable price (around \$60 or so), can produce some
 
profit. Even though Red Hat's system is fully downloadable on their
 
Web site, people still go to local computer stores and buy copies of their
 
box set, which is simply a printed version of the manual (available under
 
a Free license as well) and the Free Software system it documents.
 

	
 
\medskip
 

	
 
Custom support, service, and software improvement contracts
 
are the most widely used models for GPL'd software. The GPL is
 
central to their success, because it ensures that the code base
 
remains common, and that large and small companies are on equal
 
footing for access to the technology. Consider, for example, the GNU
 
Compiler Collection (GCC). Cygnus Solutions, a company started in the
 
early 1990s, was able to grow steadily simply by providing services
 
for GCC --- mostly consisting of new ports of GCC to different or new,
 
embedded targets. Eventually, Cygnus was so successful that
 
it was purchased by Red Hat where it remains a profitable division.
 

	
 
However, there are very small companies that compete in
 
this space. Modern industry demands the trust created by GPL protected
 
code-bases. Companies can cooperate on the software and
 
improve it for everyone. Meanwhile, companies who rely on GCC for their
 
work are happy to pay for improvements, and for ports to new target
 
platforms. Nearly all the changes fold back into the standard
 
versions, and those forks that exist remain freely available.
 

	
 
\medskip
 

	
 
\label{Proprietary Relicensing}
 

	
 
A final common business model that is perhaps the most controversial is
 
proprietary relicensing of a GPL'd code base. This is only an option for
 
software in which a particular entity holds exclusive rights to
 
relicense.\footnote{Entities typically hold exclusive relicensing rights
 
  either by writing all the software under their own copyrights, collecting
 
  copyright assignments from all contributors, or by otherwise demanding
 
  unconditional relicensing permissions from all contributors via some legal
 
  agreement} As discussed earlier in this tutorial, a copyright holder is
 
permitted under copyright law to license a software system under her
 
copyright as many different ways as she likes to as many different parties as
 
she wishes.
 

	
 
Some companies use this to their
 
financial advantage with regard to a GPL'd code base. The standard
 
version is available from the company under the terms of the GPL\@.
 
However, parties can purchase separate proprietary software licensing for
 
a fee.
 

	
 
This business model is at best problematic and at worst predatory because it means that the GPL'd code
 
base must be developed in a somewhat monolithic way, because volunteer
 
Free Software developers may be reluctant to assign their copyrights to
 
the company because it will not promise to always and forever license the
 
software as Free Software. Indeed, the company will surely use such code
 
contributions in proprietary versions licensed for fees.
 

	
 
\section{Ongoing Compliance}
 

	
 
GPL compliance is in fact a very simple matter --- much simpler than
 
typical proprietary software agreements and EULAs. Usually, the most
 
difficult hurdle is changing from a proprietary software mindset to one
 
that seeks to foster a community of sharing and mutual support. Certainly
 
complying with the GPL from a users' perspective gives substantially fewer
 
headaches than proprietary license compliance.
 

	
 
For those who go into the business of distributing {\em modified}
 
versions of GPL'd software, the burden is a bit higher, but not by
 
much. The glib answer is that by releasing the whole product as Free
 
Software, it is always easy to comply with the GPL. However,
 
admittedly to the dismay of FSF, many modern and complex software
 
systems are built using both proprietary and GPL'd components that are
 
clearly and legally separate and independent works, merely aggregated
 
together on the same device.
 

	
 
However, it sometimes is easier, quicker, and cheaper to simply
 
improve an existing GPL'd application than to start from scratch.  In
 
exchange for this amazing benefit, the license requires that the modifier gives
 
back to the commons that made the work easier in the first place. It is a
 
reasonable trade-off and a way to help build a better world while also
 
making a profit.
 

	
 
Note that FSF does provide services to assist companies who need
 
assistance in complying with the GPL. You can contact FSF's GPL
 
Compliance Labs at $<$licensing@fsf.org$>$.
 

	
 
%FIXME-LATER: should have \tutorialpart
 

	
 
If you are particularly interested in matters of GPL compliance, we
 
recommend the next two parts, which include both recommendations on good
 
compliance and compliance case studies.
 

	
 
% =====================================================================
 
% END OF FIRST DAY SEMINAR SECTION
 
% =====================================================================
 

	
 
%%  LocalWords:  Sebro Novalis Ravicher GPLv GPL'd copylefted LGPLv OSI USC
 
%%  LocalWords:  noncommercially counterintuitive Berne copyrightable DRM UC
 
%%  LocalWords:  proprietarize proprietarization Stallman's Tridgell's RMS
 
%%  LocalWords:  Lessig Lessig's Stallman Proto GPLs proto Tai pre GPL's ful
 
%%  LocalWords:  legalbol AGPLv Runtime licensor licensors relicense UCITA
 
%%  LocalWords:  unprotectable Intl nd th Kepner Tregoe Bando Indust Mitel
 
%%  LocalWords:  Iqtel Bateman Mitek Arce protectable hoc faire de minimis
 
%%  LocalWords:  Borland Int'l uncopyrightable LLC APIs Ent Connectix DVD's
 
%%  LocalWords:  redistributor diachronic unshared subpart redistributors
 
%%  LocalWords:  CDs userbase reshifts licensor's distributee impliedly Mgmt
 
%%  LocalWords:  patentee  relicenses irrevocability Jacobsen Katzer TRW CCS
 
%%  LocalWords:  Unfreedonia administrivia Relicensing impermissibly centric
 
%%  LocalWords:  permissibility firehose bytecode minified Javascript DLLs
 
%%  LocalWords:  preprocessors functionalities offsite sublicensing DMCA CFR
 
%%  LocalWords:  anticircumvention WIPO BitTorrent multidirectional Magnuson
 
%%  LocalWords:  subdefinition Dryvit Stroebner Tandy TRS superset LGPL SLES
 
%%  LocalWords:  cryptographic relicensing removability sublicensed Novell
 
%%  LocalWords:  anticompetitive administrability sublicensable licensable
 
%%  LocalWords:  sublicense sublicensees sublicenses affixation Novell's
 
%%  LocalWords:  severability Affero LGPL'd lingua franca glibc facto LGPL's
 
%%  LocalWords:  relicensed runtime subunits relink downloadable MontaVista
 
%%  LocalWords:  CodeSourcery OpenTV MySQL TrollTech Michlmayr Copyleft's
 
%%  LocalWords:  GPLRequireSourcePostedPublic privity Downstream's Jaeger
 
%%  LocalWords:  Jaeger's copyleft's executables estoppel infringer
 
%%  LocalWords:  unenforceability enforceability CISG
 

	
0 comments (0 inline, 0 general)