Changeset - 37bdf9caddc1
[Not reviewed]
0 1 0
Mike Linksvayer (mlinksva) - 10 years ago 2014-11-16 15:35:50
ml@gondwanaland.com
typos/extra words
1 file changed with 3 insertions and 3 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -1761,1025 +1761,1025 @@ a work based on GPL'd software, the license of that whole
 
work must be GPL and only GPL\@.  In this manner, GPLv2~\S2(b) dovetails nicely
 
with GPLv2~\S6 (as discussed in Section~\ref{GPLv2s6} of this tutorial).
 

	
 
\medskip
 

	
 
The final paragraph of GPLv2~\S2 is worth special mention.  It is possible and
 
quite common to aggregate various software programs together on one
 
distribution medium.  Computer manufacturers do this when they ship a
 
pre-installed hard drive, and GNU/Linux distribution vendors do this to
 
give a one-stop CD or URL for a complete operating system with necessary
 
applications.  The GPL very clearly permits such ``mere aggregation'' with
 
programs under any license.  Despite what you hear from its critics, the
 
GPL is nothing like a virus, not only because the GPL is good for you and
 
a virus is bad for you, but also because simple contact with a GPL'd
 
code-base does not impact the license of other programs.  A programmer must
 
expend actual effort  to cause a work to fall under the terms
 
of the GPL.  Redistributors are always welcome to simply ship GPL'd
 
software alongside proprietary software or other unrelated Free Software,
 
as long as the terms of GPL are adhered to for those packages that are
 
truly GPL'd.
 

	
 
%FIXME: need discussion of GPLv2's system library exception somewhere in here.
 
\subsection{Right to Private Modification} 
 
\label{gplv2-private-modification}
 

	
 
The issue of private modifications of GPLv2'd works deserves special
 
attention.  While these rights are clearly explicit in GPLv3~\S2\P2 (see
 
\S~\ref{GPLv3S2} of this tutorial for details), the permission to create
 
private modifications is mostly implicit in GPLv2.  Most notably, the
 
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).
 

	
 
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.
 

	
 
\label{GPLv2s3-build-scripts}
 

	
 
Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been
 
seen in GPL enforcement.  Under GPL, if you pay a high price for
 
a copy of GPL'd binaries (which comes with corresponding source, 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.
 
Therefore, 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.
 

	
 
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
 
also not trumped by other copyright agreements or components of other
 
entirely separate legal systems.  In short, while GPLv2~\S\S0--3 are the parts
 
of the license that defend the freedoms of users and programmers,
 
GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear
 
so that \S\S~0--3 can do their jobs.
 

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

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

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

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

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

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

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

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

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

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

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

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

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

	
 
% FIXME-LATER: Write this
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	
 
Most warranty disclaimer language shout at you.  The
 
Most warranty disclaimer language shouts at you.  The
 
\href{http://www.law.cornell.edu/ucc/2/2-316}{Uniform Commercial
 
  Code~\S2-316} requires that disclaimers of warranty be ``conspicuous''.
 
There is apparently general acceptance that \textsc{all caps} is the
 
preferred way to make something conspicuous, and that has over decades worked
 
its way into the voodoo tradition of warranty disclaimer writing.
 

	
 
That said, there is admittedly some authority under USA law suggesting that
 
effective warranty disclaimers that conspicuousness can be established by
 
conspicuousness can be established by
 
capitalization and is absent when a disclaimer has the same typeface as the
 
terms surrounding it (see \textit{Stevenson v.~TRW, Inc.}, 987 F.2d 288, 296
 
(5th Cir.~1993)).  While GPLv3's drafters doubted that such authority would
 
apply to copyright licenses like the GPL, the FSF has nevertheless left
 
warranty and related disclaimers in \textsc{all caps} throughout all versions
 
of GPL\@\footnote{One of the authors of this tutorial, Bradley M.~Kuhn, has
 
  often suggested the aesthetically preferable compromise of a
 
  \textsc{specifically designed ``small caps'' font, such as this one, as an
 
    alternative to} WRITING IN ALL CAPS IN THE DEFAULT FONT (LIKE THIS),
 
  since the latter adds more ugliness than conspicuousness.  Kuhn once
 
  engaged in reversion war with a lawyer who disagreed, but that lawyer never
 
  answered Kuhn's requests for case law that argues THIS IS INHERENTLY MORE
 
  CONSPICUOUS \textsc{Than this is}.}.
 

	
 
Some have argued the GPL is unenforceable in some jurisdictions because
 
its disclaimer of warranties is impermissibly broad.  However, GPLv2~\S11
 
contains a jurisdictional savings provision, which states that it is to be
 
interpreted only as broadly as allowed by applicable law.  Such a
 
provision ensures that both it, and the entire GPL, is enforceable in any
 
jurisdiction, regardless of any particular law regarding the
 
permissibility of certain warranty disclaimers.
 

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

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

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

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

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

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{GPL Version 3}
 
\label{GPLv3}
 

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

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

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

	
 
\section{Understanding GPLv3 As An Upgraded GPLv2}
 

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

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

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

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

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

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

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

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

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

	
 
GPLv2 included a defined term, ``work based on the Program'', but also used
 
the term ``modify'' and ``based on'' throughout the license.  GPLv2's ``work
 
based on the Program'' definition made use of a legal term of art,
 
``derivative work'', which is peculiar to USA copyright
 
law\footnote{(Ironically, most criticism of USA-specific legal
 
terminology in GPLv2's ``work based on the Program'' definition historically
 
came not primarily from readers outside the USA, but from those within
 
it.  The FSF noted in that it did not generally agree with these
 
  views, and expressed puzzlement by the energy with which they were
 
  expressed, given the existence of many other, more difficult legal issues
 
  implicated by the GPL.  Nevertheless, the FSF argued that it made sense to
 
  eliminate usage of local copyright terminology to good effect.}.  GPLv2
 
always sought to cover all rights governed by relevant copyright law, in the
 
USA and elsewhere.
 
Even though differently-labeled concepts corresponding to the
 
derivative work are recognized in all copyright law systems, these
 
counterpart concepts might differ to some degree in scope and breadth from
 
the USA derivative work.  GPLv3 therefore takes the task of
 
internationalizing the license further by removing references to derivative
 
works and by providing a more globally useful definition.
 
GPLv3 drops all reference to USA ``derivative works'' and returns
 
to the base concept only: GPL covers the licensed work and all works where
 
copyright permission from the licensed work's copyright holder.
 

	
 
The new definitions returns to the common elements of copyright law.  Copyright
 
holders of works of software have the exclusive right to form new works by
 
modification of the original --- a right that may be expressed in various
 
ways in different legal systems.  GPLv3 operates to grant this right to
 
successive generations of users (particularly through the copyleft conditions
 
set forth in GPLv3~\S5, as described later in this tutorial in its
 
\S~\ref{GPLv3s5}).  Here in GPLv3~\S0, ``modify'' refers to basic copyright
 
rights, and then this definition of ``modify'' is used to define ``modified
 
version of'' and ``work based on'' as synonyms.
 

	
 
\subsection{The Covered Work}
 

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

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

	
 
\subsection{Propagate}
 

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

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

	
 
Second, ``propagate'' helps globalize GPL in its wording and effect:
 
``derivative work'' was in fact not the only term commonly used by local
 
copyright statutes.  A term like ``distribute'' (or its equivalent in
 
languages other than English) is also used in several national copyright
 
statutes.  Practical experience with GPLv2 revealed the awkwardness of using
 
the term ``distribution'' in a license intended for global use: the scope of
 
``distribution'' in the copyright context can differ from country to country.
 
The GPL never necessarily intended the specific meaning of ``distribution''
 
that exists under USA (or any other country's) copyright law.
 

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

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

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

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

	
 
\subsection{Convey}
 

	
 
Next, GPLv3 defines a subset of propagate --- ``convey''.
 
Conveying includes activities that constitute propagation of copies to
 
others.  As with the definition of propagate, GPLv3 thus addresses transfers
 
of copies of software in behavioral rather than statutory terms.  
 
Any propagation that enables other parties to receive or make copies of the
 
work, is called ``conveying''.  Usually, conveying is the activity that
 
triggers most of the other obligations of GPLv3.
 

	
 
\subsection{Appropriate Legal Notices}
 

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

	
 
\subsection{Other Defined Terms}
 

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

	
 
\section{GPLv3~\S1: Understanding CCS}
 
\label{GPLv3s1}
 

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

	
 
\subsection{Source Code Definition}
 

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

	
 
\subsection{CCS Definition}
 
\label{CCS Definition}
 

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

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

	
 
The GPL, as always, seeks to ensure users are truly in a position to install and
 
run their modified versions of the program; the CCS definition is designed to
 
be expansive to ensure this software freedom.  However, although the
 
definition of CCS is expansive, it is not sufficient to protect users'
 
freedoms in many circumstances.  For example, a GPL'd program, or a modified
 
version of such a program, might be locked-down and restricted.  The
 
requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this
 
tutorial) handle that issue.  (Early drafts of GPLv3 included those
 
requirements in the definition of CCS; however, given that the lock-down
 
issue only comes up in distribution of object code, it is more logical to
 
place those requirements with the parts of GPLv3 dealing directly with object
 
code distribution).
 

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

	
 
GPLv3\S1's final paragraph removes any ambiguity about what should be done on
 
source-only distributions.  Specifically, the right to convey source code
 
that does not compile, does not work, or otherwise is experimental
 
in-progress work is fully permitted, \textit{provided that} no object code
 
form is conveyed as well.  Indeed, when combined with the permissions in
 
GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can
 
never be required to provide more than that.  One always has the right to
 
modify a source code work by deleting any part of it, and there can be no
 
requirement that free software source code be a whole functioning program.
 

	
 
\subsection{The System Library Exception}
 
\label{GPLv3-system-library-exception}
 

	
 
The previous section skipped over one part of the CCS definition, the
 
so-called system library exception.  The ``System Libraries'' definition (and
 
the ``Standard Interface'' and ``Major Component'' definitions, which it
 
includes) are designed as part
 
to permit certain distribution arrangements that are considered reasonable by
 
copyleft advocates.  The system library exception is designed to allow
 
copylefted software to link with these libraries when prohibition of that linking would hurt
 
software freedom more than it would hurt proprietary software.
 

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

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

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

	
 
Like any exception to the copyleft requirements of GPL, would-be GPL
 
violators frequently look to the system library exception as a potential
 
software freedom circumvention technique.  When considering whether or not a
 
library qualifies for the system library exception, here is a pragmatic
 
thesis to consider, based on the combined decades of experience in GPL
0 comments (0 inline, 0 general)