Changeset - e7ff8ce2af19
[Not reviewed]
0 1 0
Bradley Kuhn (bkuhn) - 10 years ago 2014-03-19 17:38:07
bkuhn@ebb.org
Make plurals agree.
1 file changed with 1 insertions and 1 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
 
% gpl-lgpl.tex                                                  -*- LaTeX -*-
 
%      Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course
 
%
 
% Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
 
% Copyright (C) 2014                   Bradley M. Kuhn
 

	
 
% License: CC-By-SA-4.0
 

	
 
% The copyright holders hereby grant the freedom to copy, modify, convey,
 
% Adapt, and/or redistribute this work under the terms of the Creative
 
% Commons Attribution Share Alike 4.0 International License.
 

	
 
% This text is distributed in the hope that it will be useful, but
 
% WITHOUT ANY WARRANTY; without even the implied warranty of
 
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 

	
 
% You should have received a copy of the license with this document in
 
% a file called 'CC-By-SA-4.0.txt'.  If not, please visit
 
% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive
 
% the license text.
 

	
 
\newcommand{\defn}[1]{\emph{#1}}
 

	
 
\part{Detailed Analysis of the GNU GPL and Related Licenses}
 

	
 
\begin{center}
 

	
 
{\parindent 0in
 
\tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\
 
\begin{tabbing}
 
Copyright \= \copyright{} 2003, 2004, 2005, 2006 \= \hspace{.2in} Free Software Foundation, Inc. \\
 
Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn \\
 
Copyright \= \copyright{} 2014 \= \hspace{.2in} Anthony K. Sebro, Jr. \\
 
\end{tabbing}
 

	
 
Authors of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} are: \\
 

	
 
Free Software Foundation, Inc. \\
 
Bradley M. Kuhn \\
 
David ``Novalis'' Turner \\
 
Daniel B. Ravicher \\
 
Tony Sebro \\
 
John Sullivan
 

	
 
\vspace{.3in}
 

	
 
The copyright holders of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} hereby grant the freedom to copy, modify,
 
convey, Adapt, and/or redistribute this work under the terms of the Creative
 
Commons Attribution Share Alike 4.0 International License.  A copy of that
 
license is available at
 
\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.  }
 

	
 
\end{center}
 

	
 
\bigskip
 

	
 
\bigskip
 

	
 
\tutorialpartsplit{This tutorial}{This part of the tutorial} gives a
 
comprehensive explanation of the most popular Free Software copyright
 
license, the GNU General Public License (``GNU GPL'', or sometimes just
 
``GPL'') -- both version 2 (``GPLv2'') and version 3 (``GPLv3'') -- and
 
teaches lawyers, software developers, managers and business people how to use
 
the GPL (and GPL'd software) successfully both as a community-building
 
``Constitution'' for a software project, and to incorporate copylefted
 
software into a new Free Software business and in existing, successful
 
enterprises.
 

	
 
To successfully benefit of from this part of the tutorial, readers should
 
have a general familiarity with software development processes.  A basic
 
understanding of how copyright law applies to software is also helpful.  The
 
tutorial is of most interest to lawyers, software developers and managers who
 
run or advise software businesses that modify and/or redistribute software
 
under the terms of the GNU GPL (or who wish to do so in the future), and those
 
who wish to make use of existing GPL'd software in their enterprise.
 

	
 
Upon completion of this part of the tutorial, successful readers can expect
 
to have learned the following:
 

	
 
\begin{itemize}
 

	
 
  \item The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3.
 

	
 
  \item The differences between GPLv2 and GPLv3.
 

	
 
  \item The redistribution options under the GPLv2 and GPLv3.
 

	
 
  \item The obligations when modifying GPLv2'd or GPLv3'd software.
 

	
 
  \item How to build a plan for proper and successful compliance with the GPL.
 

	
 
  \item The business advantages that the GPL provides.
 

	
 
  \item The most common business models used in conjunction with the GPL.
 

	
 
  \item How existing GPL'd software can be used in existing enterprises.
 

	
 
  \item The basics of LGPLv2.1 and LGPLv3, and how they
 
    differs from the GPLv2 and GPLv3, respectively.
 

	
 
  \item The basics to begin understanding the complexities regarding
 
    derivative and combined works of software.
 
\end{itemize}
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
% END OF ABSTRACTS SECTION
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
% START OF DAY ONE COURSE
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 

	
 
\chapter{What Is Software Freedom?}
 

	
 
Study of the GNU General Public License (herein, abbreviated as \defn{GNU
 
  GPL} or just \defn{GPL}) must begin by first considering the broader world
 
of software freedom. The GPL was not created in a vacuum. Rather, it was
 
created to embody and defend a set of principles that were set forth at the
 
founding of the GNU project and the Free Software Foundation (FSF) -- the
 
preeminent organization that upholds, defends and promotes the philosophy of software
 
freedom. A prerequisite for understanding both of the popular versions
 
of the GPL
 
(GPLv2 and GPLv3) and their terms and conditions is a basic understanding of
 
the principles behind them.  The GPL family of licenses are unlike nearly all
 
other software licenses in that they are designed to defend and uphold these
 
principles.
 

	
 
\section{The Free Software Definition}
 
\label{Free Software Definition}
 

	
 
The Free Software Definition is set forth in full on FSF's website at
 
\verb0http://fsf.org/0 \verb0philosophy/free-sw.html0. This section presents
 
an abbreviated version that will focus on the parts that are most pertinent
 
to the GPL\@.
 

	
 
A particular program grants software freedom to a particular user if that
 
user is granted the following freedoms:
 

	
 
\begin{itemize}
 

	
 

	
 
\item The freedom to run the program, for any purpose.
 

	
 
\item The freedom to study how the program works, and modify it
 

	
 
\item The freedom to redistribute copies.
 

	
 
\item The freedom to distribute copies of  modified versions to others.
 

	
 
\end{itemize}
 

	
 
The focus on ``a particular user'' is particularly pertinent here.  It is not
 
uncommon for the same version of a specific program to grant these freedoms
 
to some subset of its user base, while others have none or only some of these
 
freedoms.  Section~\ref{Proprietary Relicensing} talks in detail about how
 
this can unfortunately happen even if a program is released under the GPL\@.
 

	
 
Many people refer to software that gives these freedoms as ``Open Source.''
 
Besides having a different political focus than those who call it Free
 
Software,\footnote{The political differences between the Free Software
 
  Movement and the Open Source Movement are documented on FSF's Web site at
 
  {\tt http://www.fsf.org/licensing/essays/free-software-for-freedom.html}.}
 
Those who call the software ``Open Source'' are often focused on a side
 
issue.  Specifically, user access to the source code of a program is a
 
prerequisite to make use of the freedom to modify.  However, the important
 
issue is what freedoms are granted in the license of that source code.
 

	
 
Software freedom is only complete when no restrictions are imposed on how
 
these freedoms are exercised.  Specifically, users and programmers can
 
exercise these freedoms noncommercially or commercially.  Licenses that grant
 
these freedoms for noncommercial activities but prohibit them for commercial
 
activities are considered non-free.  Even the Open Source Initiative
 
(\defn{OSI}) (the arbiter of what is considered ``Open Source'') also rules
 
such licenses not in fitting with its ``Open Source Definition''.
 

	
 
In general, software for which most or all of these freedoms are
 
restricted in any way is called ``non-Free Software.''  Typically, the
 
term ``proprietary software'' is used more or less interchangeably with
 
``non-Free Software.''  Personally, I tend to use the term ``non-Free
 
Software'' to refer to noncommercial software that restricts freedom
 
(such as ``shareware'') and ``proprietary software'' to refer to
 
commercial software that restricts freedom (such as nearly all of
 
Microsoft's and Oracle's offerings).
 

	
 
Keep in mind that the none of the terms ``software freedom'', ``open source''
 
and ``free software'' are known to be trademarked or otherwise legally
 
restricted by any organization in
 
any jurisdiction.  As such, it's quite common that these terms are abused and
 
misused by parties who wish to bank on the popularity of software freedom.
 
When one considers using, modifying or redistributing a software package that
 
purports to be Open Source or Free Software, one \textbf{must} verify that
 
the license grants software freedom.
 

	
 
Furthermore, throughout this text, we generally prefer the term ``software
 
freedom'', as this is the least ambiguous term available to describe software
 
that meets the Free Software Definition.  For example, it is well known and
 
often discussed that the adjective ``free'' has two unrelated meanings in
 
English: ``free as in freedom'' and ``free as in price''.  Meanwhile, the
 
term ``open source'' is even more confusing, because it appears to refer only to the
 
``freedom to study'', which is merely a subset of one of the four freedoms.
 

	
 
The remainder of this section considers each of each component of software
 
freedom in detail.
 

	
 
\subsection{The Freedom to Run}
 

	
 
The first tenet of software freedom is the user's fully unfettered right to
 
run the program.  The software's license must permit any conceivable use of
 
the software.  Perhaps, for example, the user has discovered an innovative
 
use for a particular program, one that the programmer never could have
 
predicted.  Such a use must not be restricted.
 

	
 
It was once rare that this freedom was restricted by even proprietary
 
software; but such is quite common today. Most End User License Agreements
 
(EULAs) that cover most proprietary software typically restrict some types of
 
uses.  Such restrictions of any kind are an unacceptable restriction on
 
software freedom.
 

	
 
\subsection{The Freedom to Change and Modify}
 

	
 
Perhaps the most useful right of software freedom is the users' right to
 
change, modify and adapt the software to suit their needs.  Access to the
 
source code and related build and installation scripts are an essential part
 
of this freedom.  Without the source code, and the ability to build and
 
install the binary applications from that source, users cannot effectively
 
exercise this freedom.
 

	
 
Programmers directly benefit from this freedom.  However, this freedom
 
remains important to users who are not programmers.  While it may seem
 
counterintuitive at first, non-programmer users often exercise this freedom
 
indirectly in both commercial and noncommercial settings.  For example, users
 
often seek noncommercial help with the software on email lists and in user
 
groups.  To make use of such help they must either have the freedom to
 
recruit programmers who might altruistically assist them to modify their
 
software, or to at least follow rote instructions to make basic modifications
 
themselves.
 

	
 
More commonly, users also exercise this freedom commercially.  Each user, or
 
group of users, may hire anyone they wish in a competitive free market to
 
modify and change the software.  This means that companies have a right to
 
hire anyone they wish to modify their Free Software.  Additionally, such
 
companies may contract with other companies to commission software
 
modification.
 

	
 
\subsection{The Freedom to Copy and Share}
 

	
 
Users share Free Software in a variety of ways. Software freedom advocates
 
work to eliminate a fundamental ethical dilemma of the software age: choosing
 
between obeying a software license and friendship (by giving away a copy of a
 
program to your friend who likes the software you are using). Licenses that
 
respect software freedom, therefore, permit altruistic sharing of software
 
among friends.
 

	
 
The commercial environment also benefits of this freedom.  Commercial sharing
 
includes selling copies of Free Software: that is, Free Software can
 
be distribted for any monetary
 
price to anyone.  Those who redistribute Free Software commercially also have
 
the freedom to selectively distribute (i.e., you can pick your customers) and
 
to set prices at any level that redistributor sees fit.
 

	
 
Of course, most people get copies of Free Software very cheaply (and
 
sometimes without charge).  The competitive free market of Free Software
 
tends to keep prices low and reasonable.  However, if someone is willing to
 
pay billions of dollars for one copy of the GNU Compiler Collection, such a
 
sale is completely permitted.
 

	
 
Another common instance of commercial sharing is service-oriented
 
distribution.  For example, some distribution vendors provide immediate
 
security and upgrade distribution via a special network service.  Such
 
distribution is not necessarily contradictory with software freedom.
 

	
 
(Section~\ref{Business Models} of this tutorial talks in detail about some
 
common Free Software business models that take advantage of the freedom to
 
share commercially.)
 

	
 
\subsection{The Freedom to Share Improvements}
 

	
 
The freedom to modify and improve is somewhat empty without the freedom to
 
share those improvements.  The Software freedom community is built on the
 
pillar of altruistic sharing of improved Free Software. Historically
 
it was typical for a
 
Free Software project to sprout a mailing list where improvements
 
would be shared
 
freely among members of the development community\footnote{This is still
 
commonly the case, though today there are other or additional ways of
 
sharing Free Software.}.   Such noncommercial
 
sharing is the primary reason that Free Software thrives.
 

	
 
Commercial sharing of modified Free Software is equally important.
 
For commercial support to exist in a competitive free market, all
 
developers -- from single-person contractors to large software
 
companies -- must have the freedom to market their services as
 
improvers of Free Software.  All forms of such service marketing must
 
be equally available to all.
 

	
 
For example, selling support services for Free Software is fully
 
permitted. Companies and individuals can offer themselves as ``the place
 
to call'' when software fails or does not function properly.  For such a
 
service to be meaningful, the entity offering that service needs the
 
right to modify and improve the software for the customer to correct any
 
problems that are beyond mere user error.
 

	
 
Software freedom licenses also permit any entity to distribute modified
 
versions of Free Software.  Most Free Software programs have a ``standard
 
version'' that is made available from the primary developers of the software.
 
However, all who have the software have the ``freedom to fork'' -- that is,
 
make available nontrivial modified versions of the software on a permanent or
 
semi-permanent basis.  Such freedom is central to vibrant developer and user
 
interaction.
 

	
 
Companies and individuals have the right to make true value-added versions
 
of Free Software.  They may use freedom to share improvements to
 
distribute distinct versions of Free Software with different functionality
 
and features.  Furthermore, this freedom can be exercised to serve a
 
disenfranchised subset of the user community.  If the developers of the
 
standard version refuse to serve the needs of some of the software's
 
users, other entities have the right to create a long- or short-lived fork
 
to serve that sub-community.
 

	
 
\section{How Does Software Become Free?}
 

	
 
The previous section set forth key freedoms and rights that are referred to
 
as ``software freedom''.  This section discusses the licensing mechanisms
 
used to enable software freedom.  These licensing mechanism were ultimately
 
created as a community-oriented ``answer'' to the existing proprietary
 
software licensing mechanisms.  Thus, first, consider carefully why
 
proprietary software exists in the first place.
 

	
 
Proprietary software exists at all only because it is governed by copyright
 
law.\footnote{This statement is admittedly an oversimplification. Patents and
 
  trade secrets can cover software and make it effectively non-Free, and one
 
  can contract away their rights and freedoms regarding software, or source
 
  code can be practically obscured in binary-only distribution without
 
  reliance on any legal system.  However, the primary control mechanism for
 
  software is copyright, and therefore this section focuses on how copyright
 
  restrictions make software proprietary.} Copyright law, with respect to
 
software, typically governs copying, modifying, and redistributing that
 
software (For details of this in the USA, see
 
\href{http://www.copyright.gov/title17/92chap1.html#106}{\S~106} and
 
\href{http://www.copyright.gov/title17/92chap1.html#117}{\S~117} of
 
\href{http://www.law.cornell.edu/uscode/text/17}{Title 17} of the
 
\textit{United States Code}).\footnote{Copyright law in general also governs
 
  ``public performance'' of copyrighted works. There is no generally agreed
 
  definition for public performance of software and both GPLv2 and GPLv3 do
 
  not restrict public performance.} By law (in the USA and in most other
 
jurisdictions), the copyright holder (most typically, the author) of the work controls
 
how others may copy, modify and/or distribute the work. For proprietary
 
software, these controls are used to prohibit these activities. In addition,
 
proprietary software distributors further impede modification in a practical
 
sense by distributing only binary code and keeping the source code of the
 
software secret.
 

	
 
Copyright is not a natural state, it is a legal construction. In the USA, the
 
Constitution permits, but does not require, the creation of copyright law as
 
federal legislation.  Software, since it is ``an original works of authorship
 
fixed in any tangible medium of expression ...  from which they can be
 
perceived, reproduced, or otherwise communicated, either directly or with the
 
aid of a machine or device'' (as stated in
 
\href{http://www.law.cornell.edu/uscode/text/17/102}{17 USC \S~102}), is thus
 
covered by the statute, and is copyrighted by default.
 

	
 
However, software, in its natural state without copyright, is Free
 
Software. In an imaginary world with no copyright, the rules would be
 
different. In this world, when you received a copy of a program's source
 
code, there would be no default legal system to restrict you from sharing it
 
with others, making modifications, or redistributing those modified
 
versions.\footnote{Note that this is again an oversimplification; the
 
  complexities with this argument are discussed in
 
  Section~\ref{software-and-non-copyright}.}
 

	
 
Software in the real world is copyrighted by default and is automatically
 
covered by that legal system.  However, it is possible to move software out
 
of the domain of the copyright system.  A copyright holder can often
 
\defn{disclaim} their copyright. (For example, under USA copyright law
 
it is possible for a copyright holder to engage in conduct resulting
 
in abandonment of copyright.)  If copyright is disclaimed, the software is
 
effectively no longer restricted by copyright law.   Software not restricted by copyright is in the
 
``public domain.''
 

	
 
\subsection{Public Domain Software}
 

	
 
In the USA and other countries that
 
are parties to the Berne convention on copyright, software is copyrighted
 
automatically by the author when she fixes the software in a tangible
 
medium.  In the software world, this usually means typing the source code
 
of the software into a file.
 

	
 
Imagine if authors could truly disclaim those default control of copyright
 
law.  If so, the software is in the public domain -- no longer covered by
 
copyright.  Since copyright law is the construction allowing for most
 
restrictions on software (i.e., prohibition of copying, modification, and
 
redistribution), removing the software from the copyright system usually
 
yields software freedom for its users.
 

	
 
Carefully note that software truly in the public domain is \emph{not} licensed
 
in any way. It is confusing to say software is ``licensed for the
 
public domain,'' or any phrase that implies the copyright holder gave
 
express permission to take actions governed by copyright law.
 

	
 
Copyright holders who state that they are releasing their code into
 
the public domain are effectively renouncing copyright controls on
 
the work.  The law gave the copyright holder exclusive controls over the
 
the work.  The law gave the copyright holders exclusive controls over the
 
work, and they chose to waive those controls.  Software that is, in
 
this sense, in the public domain
 
is conceptualized by the developer as having no copyright and thus no license. The software freedoms discussed in
 
Section~\ref{Free Software Definition} are all granted because there is no
 
legal system in play to take them away.
 

	
 
Admittedly, a discussion of public domain software is an oversimplified
 
example.  
 
Because copyright controls are usually automatically granted and because, in
 
some jurisdictions, some copyright controls cannot be waived (See
 
Section~\ref{non-usa-copyright} for further discussion), many copyright
 
holders sometimes incorrectly believe a work has been placed in the public
 
domain.  Second, due to aggressive lobbying by the entertainment industry,
 
the ``exclusive Right'' of copyright, that was supposed to only exist for
 
``Limited Times'' according to the USA Constitution, appears to be infinite:
 
simply purchased on the installment plan rather than in whole.  Thus, we must
 
assume no works of software will fall into the public domain merely due to
 
the passage of time.
 

	
 
Nevertheless, under USA law it is likely that the typical
 
disclaimers of copyright or public domain dedications we see in the
 
Free Software world would be interpreted by courts as copyright
 
abandonment, leading to a situation in which the user effectively receives a
 
maximum grant of copyright freedoms, similar to a maximally-permissive
 
Free Software license.
 

	
 
The best example of software known to truly be in the public domain is software
 
that is published by the USA government.  Under
 
\href{http://www.law.cornell.edu/uscode/text/17/105}{17 USC 101 \S~105}, all
 
works published by the USA Government are not copyrightable in the USA.
 

	
 
\subsection{Why Copyright Free Software?}
 

	
 
If simply disclaiming copyright on software yields Free Software, then it
 
stands to reason that putting software into the public domain is the
 
easiest and most straightforward way to produce Free Software. Indeed,
 
some major Free Software projects have chosen this method for making their
 
software Free. However, most of the Free Software in existence \emph{is}
 
copyrighted. In most cases (particularly in those of FSF and the GNU
 
Project), this was done due to very careful planning.
 

	
 
Software released into the public domain does grant freedom to those users
 
who receive the standard versions on which the original author disclaimed
 
copyright. However, since the work is not copyrighted, any nontrivial
 
modification made to the work is fully copyrightable.
 

	
 
Free Software released into the public domain initially is Free, and
 
perhaps some who modify the software choose to place their work into the
 
public domain as well. However, over time, some entities will choose to
 
proprietarize their modified versions. The public domain body of software
 
feeds the proprietary software. The public commons disappears, because
 
fewer and fewer entities have an incentive to contribute back to the
 
commons. They know that any of their competitors can proprietarize their
 
enhancements. Over time, almost no interesting work is left in the public
 
domain, because nearly all new work is done by proprietarization.
 

	
 
A legal mechanism is needed to redress this problem. FSF was in fact
 
originally created primarily as a legal entity to defend software freedom,
 
and that work of defending software freedom is a substantial part of
 
its work today. Specifically because of this ``embrace, proprietarize and
 
extend'' cycle, FSF made a conscious choice to copyright its Free Software,
 
and then license it under ``copyleft'' terms. Many, including the
 
developers of the kernel named Linux, have chosen to follow this paradigm.
 

	
 
\label{copyleft-definition}
 

	
 
Copyleft is a legal strategy and mechanism to defend, uphold and propagate software
 
freedom. The basic technique of copyleft is as follows: copyright the
 
software, license it under terms that give all the software freedoms, but
 
use the copyright law controls to ensure that all who receive a copy of
 
the software have equal rights and freedom. In essence, copyleft grants
 
freedom, but forbids others to forbid that freedom to anyone else along
 
the distribution and modification chains.
 

	
 
Copyleft is a general concept. Much like ideas for what a computer might
 
do must be \emph{implemented} by a program that actually does the job, so
 
too must copyleft be implemented in some concrete legal structure.
 
``Share and share alike'' is a phrase that is used often enough to explain the
 
concept behind copyleft, but to actually make it work in the real world, a
 
true implementation in legal text must exist. The GPL is the primary
 
implementation of copyleft in copyright licensing language.
 

	
 
\subsection{Software and Non-Copyright Legal Regimes}
 
\label{software-and-non-copyright}
 

	
 
The use, modification and distribution of software, like many endeavors,
 
simultaneously interacts with multiple different legal regimes.  As was noted
 
early via footnotes, copyright is merely the \textit{most common way} to
 
restrict users' rights to copy, share, modify and/or redistribute software.
 
However, proprietary software licenses typically use every mechanism
 
available to subjugate users.  For example:
 

	
 
\begin{itemize}
 

	
 
\item Unfortunately, despite much effort by many in the software freedom
 
  community to end patents that read on software (i.e., patents on
 
  computational ideas), they still ultimately exist.  As such, a software
 
  program might otherwise be seemly unrestricted, but a patent might read on
 
  the software and ruin everything for its users.\footnote{See
 
  \S\S~\ref{gpl-implied-patent-grant},~\ref{GPLv2s7},~\ref{GPLv3s11} for more
 
  discussion on how the patent system interacts with copyleft, and read
 
  Richard M.~Stallman's essay,
 
  \href{http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/}{\textit{Let’s
 
      Limit the Effect of Software Patents, Since We Can’t Eliminate Them}}
 
  for more information on the problems these patents present to society.}
 

	
 
\item Digital Restrictions Management (usually called \defn{DRM}) is often
 
  used to impose technological restrictions on users' ability to exercise
 
  software freedom that they might otherwise be granted\footnote{See
 
    \S~\ref{GPLv3s3} for more information on how GPL deals with this issue.}.
 
  The simplest (and perhaps oldest) form of DRM, of course, is separating
 
  software source code (read by humans), from their compiled binaries (read
 
  only by computers).  Furthermore,
 
  \href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC 1201} often
 
  prohibits users legally from circumventing some of these DRM systems.
 

	
 
\item Most EULAs also include a contractual agreement that bind users further
 
  by forcing them to agree to a contractual, prohibitive software license
 
  before ever even using the software.
 

	
 
\end{itemize}
 

	
 
Thus, most proprietary software restricts users via multiple interlocking
 
legal and technological means.  Any license that truly respect the software
 
freedom of all users must not only grant appropriate copyright permissions,
 
but also \textit{prevent} restrictions from other legal and technological
 
means like those listed above.
 

	
 
\subsection{Non-USA Copyright Regimes}
 
\label{non-usa-copyright}
 

	
 
Generally speaking, copyright law operates similarly enough in countries that
 
have signed the Berne Convention on Copyright, and software freedom licenses
 
have generally taken advantage of this international standardization of
 
copyright law.  However, copyright law does differ from country to country,
 
and commonly, software freedom licenses like GPL must be considered under the
 
copyright law in the jurisdiction where any licensing dispute occurs.
 

	
 
Those who are most familiar with the USA's system of copyright often are
 
surprised to learn that there are certain copyright controls that cannot be
 
waived nor disclaimed.  Specifically, many copyright regimes outside the USA
 
recognize a concept of moral rights of authors.  Typically, moral rights are
 
fully compatible with respecting software freedom, as they are usually
 
centered around controls that software freedom licenses generally respect,
 
such as the right of an authors to require proper attribution for their work.
 

	
 
\section{A Community of Equality}
 

	
 
The previous section described the principles of software freedom, a brief
 
introduction to mechanisms that typically block these freedoms, and the
 
simplest ways that copyright holders might grant those freedoms to their
 
users for their copyrighted works of software.  The previous section also
 
introduced the idea of \textit{copyleft}: a licensing mechanism to use
 
copyright to not only grant software freedom to users, but also to uphold
 
those rights against those who might seek to curtail them.
 

	
 
Copyleft, as defined in \S~\ref{copyleft-definition}, is a general term this
 
mechanism.  The remainder of this text will discuss details of various
 
real-world implementations of copyleft -- most notably, the GPL\@.
 

	
 
This discussion begins first with some general explanation of what the GPL is
 
able to do in software development communities.  After that brief discussion
 
in this section, deeper discussion of how GPL accomplishes this in practice
 
follows in the next chapter.
 

	
 
Simply put, though, the GPL ultimately creates an community of equality for
 
both business and noncommercial users.
 

	
 
\subsection{The Noncommercial Community}
 

	
 
A GPL'd code base becomes a center of a vibrant development and user
 
community.  Traditionally, volunteers, operating noncommercially out of
 
keen interest or ``scratch an itch'' motivations, produce initial versions
 
of a GPL'd system.  Because of the efficient distribution channels of the
 
Internet, any useful GPL'd system is adopted quickly by noncommercial
 
users.
 

	
 
Fundamentally, the early release and quick distribution of the software
 
gives birth to a thriving noncommercial community.  Users and developers
 
begin sharing bug reports and bug fixes across a shared intellectual
 
commons.  Users can trust the developers, because they know that if the
 
developers fail to address their needs or abandon the project, the GPL
 
ensures that someone else has the right to pick up development.
 
Developers know that the users cannot redistribute their software without
 
passing along the rights granted by GPL, so they are assured that every
 
one of their users is treated equally.
 

	
 
Because of the symmetry and fairness inherent in GPL'd distribution,
 
nearly every GPL'd package in existence has a vibrant noncommercial user
 
and developer base.
 

	
 
\subsection{The Commercial Community}
 

	
 
By the same token, nearly all established GPL'd software systems have a
 
vibrant commercial community.  Nearly every GPL'd system that has gained
 
wide adoption from noncommercial users and developers eventually begins
 
to fuel a commercial system around that software.
 

	
 
For example, consider the Samba file server system that allows Unix-like
 
systems (including GNU/Linux) to serve files to Microsoft Windows systems.
 
Two graduate students originally developed Samba in their spare time and
 
it was deployed noncommercially in academic environments\footnote{See
 
  \href{http://turtle.ee.ncku.edu.tw/docs/samba/history}{Andrew Tridgell's
 
    ``A bit of history and a bit of fun''}}.  However, very
 
soon for-profit companies discovered that the software could work for them
 
as well, and their system administrators began to use it in place of
 
Microsoft Windows NT file-servers.  This served to lower the cost of
 
running such servers by orders of magnitude. There was suddenly room in
 
Windows file-server budgets to hire contractors to improve Samba.  Some of
 
the first people hired to do such work were those same two graduate
 
students who originally developed the software.
 

	
 
The noncommercial users, however, were not concerned when these two
 
fellows began collecting paychecks off of their GPL'd work.  They knew
 
that because of the nature of the GPL that improvements that were
 
distributed in the commercial environment could easily be folded back into
 
the standard version.  Companies are not permitted to proprietarize
 
Samba, so the noncommercial users, and even other commercial users are
 
safe in the knowledge that the software freedom ensured by GPL will remain
 
protected.
 

	
 
Commercial developers also work in concert with noncommercial
 
developers.  Those two now-long-since graduated students continue to
 
contribute to Samba altruistically, but also get paid work doing it.
 
Priorities change when a client is in the mix, but all the code is
 
contributed back to the standard version.  Meanwhile, many other
 
individuals have gotten involved noncommercially as developers,
 
because they want to ``cut their teeth on Free Software,'' or because
 
the problems interest them.  When they get good at it, perhaps they
 
will move on to another project, or perhaps they will become
 
commercial developers of the software themselves.
 

	
 
No party is a threat to another in the GPL software scenario because
 
everyone is on equal ground.  The GPL protects rights of the commercial
 
and noncommercial contributors and users equally. The GPL creates trust,
 
because it is a level playing field for all.
 

	
 
\subsection{Law Analogy}
 

	
 
In his introduction to Stallman's \emph{Free Software, Free Society},
 
Lawrence Lessig draws an interesting analogy between the law and Free
 
Software. He argues that the laws of a free society must be protected
 
much like the GPL protects software.  So that I might do true justice to
 
Lessig's argument, I quote it verbatim:
 

	
 
\begin{quotation}
 

	
 
A ``free society'' is regulated by law. But there are limits that any free
 
society places on this regulation through law: No society that kept its
 
laws secret could ever be called free.  No government that hid its
 
regulations from the regulated could ever stand in our tradition. Law
 
controls.  But it does so justly only when visibly.  And law is visible
 
only when its terms are knowable and controllable by those it regulates,
 
or by the agents of those it regulates (lawyers, legislatures).
 

	
 
This condition on law extends beyond the work of a legislature.  Think
 
about the practice of law in American courts.  Lawyers are hired by their
 
clients to advance their clients' interests.  Sometimes that interest is
 
advanced through litigation. In the course of this litigation, lawyers
 
write briefs. These briefs in turn affect opinions written by judges.
 
These opinions decide who wins a particular case, or whether a certain law
 
can stand consistently with a constitution.
 

	
 
All the material in this process is free in the sense that Stallman means.
 
Legal briefs are open and free for others to use.  The arguments are
 
transparent (which is different from saying they are good), and the
 
reasoning can be taken without the permission of the original lawyers.
 
The opinions they produce can be quoted in later briefs.  They can be
 
copied and integrated into another brief or opinion.  The ``source code''
 
for American law is by design, and by principle, open and free for anyone
 
to take. And take lawyers do---for it is a measure of a great brief that
 
it achieves its creativity through the reuse of what happened before.  The
 
source is free; creativity and an economy is built upon it.
 

	
 
This economy of free code (and here I mean free legal code) doesn't starve
 
lawyers.  Law firms have enough incentive to produce great briefs even
 
though the stuff they build can be taken and copied by anyone else.  The
 
lawyer is a craftsman; his or her product is public.  Yet the crafting is
 
not charity. Lawyers get paid; the public doesn't demand such work
 
without price.  Instead this economy flourishes, with later work added to
 
the earlier.
 

	
 
We could imagine a legal practice that was different --- briefs and
 
arguments that were kept secret; rulings that announced a result but not
 
the reasoning. Laws that were kept by the police but published to no one
 
else. Regulation that operated without explaining its rule.
 

	
 
We could imagine this society, but we could not imagine calling it
 
``free.''  Whether or not the incentives in such a society would be better
 
or more efficiently allocated, such a society could not be known as free.
 
The ideals of freedom, of life within a free society, demand more than
 
efficient application.  Instead, openness and transparency are the
 
constraints within which a legal system gets built, not options to be
 
added if convenient to the leaders.  Life governed by software code should
 
be no less.
 

	
 
Code writing is not litigation.  It is better, richer, more
 
productive.  But the law is an obvious instance of how creativity and
 
incentives do not depend upon perfect control over the products
 
created.  Like jazz, or novels, or architecture, the law gets built
 
upon the work that went before. This adding and changing is what
 
creativity always is.  And a free society is one that assures that its
 
most important resources remain free in just this sense.\footnote{This
 
quotation is Copyright \copyright{} 2002, Lawrence Lessig. It is
 
licensed under the terms of
 
\href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution
 
License'' version 1.0} or any later version as published by Creative
 
Commons.}
 
\end{quotation}
 

	
 
In essence, lawyers are paid to service the shared commons of legal
 
infrastructure.  Few citizens defend themselves in court or write their
 
own briefs (even though they are legally permitted to do so) because
 
everyone would prefer to have an expert do that job.
 

	
 
The Free Software economy is a market ripe for experts.  It
 
functions similarly to other well established professional fields like the
 
law. The GPL, in turn, serves as the legal scaffolding that permits the
 
creation of this vibrant commercial and noncommercial Free Software
 
economy.
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{A Tale of Two Copyleft Licenses}
 
\label{tale-of-two-copylefts}
 

	
 
While determining the proper methodology and criteria to yield an accurate
 
count remains difficult, the GPL is generally considered one of the most
 
widely used Free Software licenses.  For most of its history --- for 16 years
 
from June 1991 to June 2007 --- there was really only one version of the GPL,
 
version 2.
 

	
 
However, the GPL had both earlier versions before version 2, and, more well
 
known, a revision to version 3. 
 

	
 
\section{Historical Motivations for the General Public License}
 

	
 
The earliest license to grant software freedom was likely the Berkeley
 
Software Distribution (``BSD'') license.  This license is typical of what are
 
often called lax, highly permissive licenses.  Not unlike software in the
 
public domain, these non-copyleft licenses (usually) grant software freedom
 
to users, but they do not go to any effort to uphold that software freedom
 
for users.  The so-called ``downstream'' (those who receive the software and
 
then build new things based on that software) can restrict the software and
 
distribute further.
 

	
 
The GNU's Not Unix (``GNU'') project, which Richard M.~Stallman (``RMS'')
 
founded in 1984 to make a complete Unix-compatible operating system
 
implementation that assured software freedom for all.  However, RMS saw that
 
using a license that gave but did not assure software freedom would be
 
counter to the goals of the GNU project.  RMS invented ``copyleft'' as an
 
answer to that problem, and began using various copyleft licenses for the
 
early GNU project programs\footnote{RMS writes more fully about this topic in
 
  his essay entitled simply
 
  \href{http://www.gnu.org/gnu/thegnuproject.html}{\textit{The GNU Project}}.
 
    For those who want to hear the story in his own voice,
 
    \href{http://audio-video.gnu.org/audio/}{speech recordings} of his talk,
 
    \textit{The Free Software Movement and the GNU/Linux Operating System}
 
    are also widely available}.
 

	
 
\section{Proto-GPLs And Their Impact}
 

	
 
The earliest copyleft licenses were specific to various GNU programs.  For
 
example, \href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs
 
  General Public License} was likely the first copyleft license ever
 
published.  Interesting to note that even this earliest copyleft license
 
contains a version of the well-known GPL copyleft clause:
 

	
 
\begin{quotation}
 
You may modify your copy or copies of GNU Emacs \ldots provided that you also
 
\ldots cause the whole of any work that you distribute or publish, that in
 
whole or in part contains or is a derivative of GNU Emacs or any part
 
thereof, to be licensed at no charge to all third parties on terms identical
 
to those contained in this License Agreement.
 
\end{quotation}
 

	
 
This simply stated clause is the fundamental innovation of copyleft.
 
Specifically, copyleft \textit{uses} the copyright holders' controls on
 
permission to modify the work to add a conditional requirement.  Namely,
 
downstream users may only have permission to modify  the work if they pass
 
along the same permissions on the modified version that came originally to
 
them.
 

	
 
These original program-specific proto-GPLs give an interesting window into
 
the central ideas and development of copyleft.  In particular, reviewing them
 
shows how the text of the GPL we know has evolved to address more of the
 
issues discussed earlier in \S~\ref{software-and-non-copyright}.
 

	
 
\section{The GNU General Public License, Version 1}
 
\label{GPLv1}
 

	
 
In January 1989, the FSF announced that the GPL had been converted into a
 
``subroutine'' that could be reused not just for all FSF-copyrighted
 
programs, but also by anyone else.  As the FSF claimed in its announcement of
 
the GPLv1\footnote{The announcement of GPLv1 was published in the
 
  \href{http://www.gnu.org/bulletins/bull6.html\#SEC8}{GNU'S Bulletin, vol 1,
 
    number 6 dated January 1989}.  (Thanks very much to Andy Tai for his
 
  \href{http://www.free-soft.org/gpl_history/}{consolidation of research on
 
    the history of the pre-v1 GPL's}.)}:
 
\begin{quotation}
 
To make it easier to copyleft programs, we have been improving on the
 
legalbol architecture of the General Public License to produce a new version
 
that serves as a general-purpose subroutine: it can apply to any program
 
without modification, no matter who is publishing it.
 
\end{quotation}
 

	
 
This, like many inventive ideas, seems somewhat obvious in retrospect.  But,
 
the FSF had some bright people and access to good lawyers when it started.
 
It took almost five years from the first copyleft licenses to get to a
 
generalized, reusable GPLv1.  In the context and mindset of the 1980s, this
 
is not surprising.  The idea of reusable licensing infrastructure was not
 
only uncommon, it was virtually nonexistent!  Even the early BSD licenses
 
were simply copied and rewritten slightly for each new use\footnote{It
 
  remains an interesting accident of history that the early BSD problematic
 
  ``advertising clause'' (discussion of which is somewhat beyond the scope of
 
  this tutorial) lives on into current day, simply because while the
 
  University of California at Berkeley gave unilateral permission to remove
 
  the clause from \textit{its} copyrighted works, others who adapted the BSD
 
  license with their own names in place of UC-Berkeley's never have.}.  The
 
GPLv1's innovation of reuable licensing infrastructure, an obvious fact
 
today, was indeed a novel invention for its day\footnote{We're all just
 
  grateful that the FSF also opposes business method patents, since the FSF's
 
  patent on a ``method for reusable licensing infrastructure'' would have
 
  not expired until 2006!}.
 

	
 
\section{The GNU General Public License, Version 2}
 

	
 
The GPLv2 was released two and a half years after GPLv1, and over the
 
following sixteen years, it became the standard for copyleft licensing until
 
the release of GPLv3 in 2007 (discussed in more detail in the next section).
 

	
 
While this tutorial does not discuss the terms of GPLv1 in detail, it is
 
worth noting below the three key changes that GPLv2 brought:
 

	
 
\begin{itemize}
 

	
 
\item Software patents and their danger are explicitly mentioned, inspiring
 
  (in part) the addition of GPLv2~\S\S5--7.  (These sections are discussed in
 
  detail in \S~\ref{GPLv2s5}, \S~\ref{GPLv2s6} and \S~\ref{GPLv2s7} of this
 
  tutorial.)
 

	
 
\item GPLv2~\S2's copyleft terms are expanded to more explicitly discuss the
 
  issue of combined works.  (GPLv2~\S2 is discussed in detail in
 
  \S~\ref{GPLv2s2} in this tutorial).
 

	
 
\item GPLv2~\S3 includes more detailed requirements, including the phrase
 
 ``the scripts used to control compilation and installation of the
 
  executable'', which is a central component of current GPLv2 enforcement
 
  .  (GPLv2~\S3 is discussed in detail in
 
  \S~\ref{GPLv2s3} in this tutorial).
 
\end{itemize}
 

	
 
The next chapter discusses GPLv2 in full detail, and readers who wish to dive
 
into the section-by-section discussion of the GPL should jump ahead now to
 
that chapter.  However, the most interesting fact to note here is how GPLv2
 
was published with little fanfare and limited commentary.  This contrasts
 
greatly with the creation of GPLv3.
 

	
 
\section{The GNU General Public License, Version 3}
 

	
 
RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups
 
during that era about new text of that license.  However, rampant violations
 
of the GPL required more immediate attention of FSF's licensing staff, and as
 
such, much of the early 2000's was spent doing GPL enforcement
 
work\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a
 
    companion tutorial, \texit{A Practical Guide to GPL
 
      Compliance}}{Part~\ref{gpl-compliance-guide} of this tutorial}.}.  In
 
2006, FSF began in earnest drafting work for GPLv3.
 

	
 
The GPLv3 process began in earnest in January 2006.  It became clear that
 
many provisions of the GPL could benefit from modification to fit new
 
circumstances and to reflect what the entire community learned from
 
experience with version 2.  Given the scale of revision it seems proper to
 
approach the work through public discussion in a transparent and accessible
 
manner.
 

	
 
The GPLv3 process continued through June 2007, culminating in publication of
 
GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC
 
Runtime Library Exception on 27 January 2009.
 

	
 
All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3
 
and two discussion drafts of AGPLv3 were published and discussed.
 
Ultimately, FSF remained the final arbiter and publisher of the licenses, and
 
RMS himself their primary author, but input was sought from many parties, and
 
these licenses do admittedly look and read more like legislation as a result.
 
Nevertheless, all of the ``v3'' group are substantially better and improved
 
licenses.
 

	
 
GPLv3 and its terms are discussed in detail in Chapter\~ref{GPLv3}.
 

	
 
\section{The Innovation of Optional ``Or Any Later'' Version}
 

	
 
An interesting fact of all GPL licenses is that the are ultimate multiple
 
choices for use of the license.  The FSF is the primary steward of GPL (as
 
discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv2s14}).  However, those
 
who wish to license works under GPL are not required to automatically accept
 
changes made by the FSF for their own copyrighted works.
 

	
 
Each licensor may chose three different methods of licensing, as follows:
 

	
 
\begin{itemize}
 

	
 
\item explicitly name a single version of GPL for their work (usually
 
  indicated in shorthand by saying the license is ``GPLv$X$-only''), or
 

	
 
\item name no version of the GPL, thus they allow their downstream recipients
 
  to select any version of the GPL they chose (usually indicated in shorthand
 
  by saying the license is simply ``GPL''), or
 

	
 
\item name a specific version of GPL and give downstream recipients the
 
  option to chose that version ``or any later version as published by the
 
  FSF'' (usually indicated by saying the license is
 
  ``GPLv$X$-or-later'')\footnote{The shorthand of ``GPL$X+$'' is also popular
 
    for this situation.  The authors of this tutorial prefer ``-or-later''
 
    syntax, because it (a) mirrors the words ``or'' and ``later from the
 
    licensing statement, (b) the $X+$ doesn't make it abundantly clear that
 
    $X$ is clearly included as a license option and (c) the $+$ symbol has
 
    other uses in computing (such as with regular expressions) that mean
 
    something different.}
 
\end{itemize}
 

	
 
\label{license-compatibility-first-mentioned}
 

	
 
Oddly, this flexibility has received (in the opinion of the authors, undue)
 
criticism, primarily because of the complex and oft-debated notion of
 
``license compatibility'' (which is explained in detail in
 
\S~\ref{license-compatibility}).  Copyleft licenses are generally
 
incompatible with each other, because the details of how they implement
 
copyleft differs.  Specifically, copyleft works only because of its
 
requirement that downstream licensors use the \textit{same} license for
 
combined and modified works.  As such, software licensed under the terms of
 
``GPLv2-only'' cannot be combined with works licensed ``GPLv3-or-later''.
 
This is admittedly a frustrating outcome.
 

	
 
Other copyleft licenses that appeared after GPL, such
 
as the Creative Commons ``Share Alike'' licenses, the Eclipse Public License
 
and the Mozilla Public License \textbf{require} all copyright holders chosing
 
to use any version of those licenses to automatically accept and relicense
 
their copyrighted works under new versions.  Of course ,Creative Commons, the
 
Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally
 
served as excellent stewards of their licenses.  Copyright holders using
 
those licenses seems to find it acceptable that to fully delegate all future
 
licensing decisions for their copyrights to these organizations without a
 
second thought.
 

	
 
However, note that FSF gives herein the control of copyright holders to
 
decide whether or not to implicitly trust the FSF in its work of drafting
 
future GPL versions.  The FSF, for its part, does encourage copyright holders
 
to chose by default ``GPLv$X$-or-later'' (where $X$ is the most recent
 
version of the GPL published by the FSF).  However, the FSF \textbf{does not
 
  mandate} that a choice to use any GPL requires a copyright holder ceding
 
its authority for future licensing decisions to the FSF.  In fact, the FSF
 
considered this possibility for GPLv3 and chose not to do so, instead opting
 
for the third-party steward designation clause discussed in
 
Section~\ref{GPlv3S14}.
 

	
 
\section{Complexities of Two Simultaneously Popular Copylefts}
 

	
 
Obviously most GPL advocates would prefer widespread migration to GPLv3, and
 
many newly formed projects who seek a copyleft license tend to choose a
 
GPLv3-based license.  However, many existing copylefted projects continue
 
with GPLv2-only or GPLv2-or-later as their default license.
 

	
 
While GPLv3 introduces many improvements --- many of which were designed to
 
increase adoption by for-profit companies --- GPLv2 remains a widely used and
 
extremely popular license.  The GPLv2 is, no doubt, a good and useful
 
license.
 

	
 
However, unlike GPLv1, which (as pointed out in \S~\ref{GPLv1}), which is
 
completely out of use by the mid-1990s.  However, unlike GPLv1 before it,
 
GPLv2 remains a integral part of the copyleft licensing infrastructure for
 
some time to come.  As such, those who seek to have expertise in current
 
topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of
 
licenses.
 

	
 
Furthermore, GPLv3 can is more easily understood by first studying GPLv2.
 
This is not only because of their chronological order, but also because much
 
of the discussion material available for GPLv3 tends to talk about GPLv3 in
 
contrast to GPLv2.  As such, a strong understanding of GPLv2 helps in
 
understanding most of the third-party material found regarding GPLv3.  Thus,
 
the following chapter begins a deep discussion of GPLv2.
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
\chapter{GPLv2: Running Software and Verbatim Copying}
 
\label{run-and-verbatim}
 

	
 

	
 
This chapter begins the deep discussion of the details of the terms of
 
GPLv2\@. In this chapter, we consider the first two sections: GPLv2 \S\S
 
0--2. These are the straightforward sections of the GPL that define the
 
simplest rights that the user receives.
 

	
 
\section{GPLv2~\S0: Freedom to Run}
 
\label{GPLv2s0}
 

	
 
GPLv2~\S0, the opening section of GPLv2, sets forth that the copyright law governs
 
the work.  It specifically points out that it is the ``copyright
 
holder'' who decides if a work is licensed under its terms and explains
 
how the copyright holder might indicate this fact.
 

	
 
A bit more subtly, GPLv2~\S0 makes an inference that copyright law is the only
 
system that can restrict the software.  Specifically, it states:
 
\begin{quote}
 
Activities other than copying, distribution and modification are not
 
covered by this License; they are outside its scope.
 
\end{quote}
 
In essence, the license governs \emph{only} those activities, and all other
 
activities are unrestricted, provided that no other agreements trump GPLv2
 
(which they cannot; see Sections~\ref{GPLv2s6} and~\ref{GPLv2s7}).  This is
 
very important, because the Free Software community heavily supports
 
users' rights to ``fair use'' and ``unregulated use'' of copyrighted
 
material.  GPLv2 asserts through this clause that it supports users' rights
 
to fair and unregulated uses.
 

	
 
Fair use (called ``fair dealing'' in some jurisdictions) of copyrighted
 
material is an established legal doctrine that permits certain activities
 
regardless of whether copyright law would other restrict those activities.
 
Discussion of the various types of fair use activity are beyond the scope of
 
this tutorial.  However, one important example of fair use is the right to
 
quote portions of the text in larger work so as to criticize or suggest
 
changes.  This fair use rights is commonly used on mailing lists when
 
discussing potential improvements or changes to Free Software.
 

	
 
Fair use is a doctrine established by the courts or by statute.  By
 
contrast, unregulated uses are those that are not covered by the statue
 
nor determined by a court to be covered, but are common and enjoyed by
 
many users.  An example of unregulated use is reading a printout of the
 
program's source code like an instruction book for the purpose of learning
 
how to be a better programmer.  The right to read something that you have
 
access is and should remain unregulated and unrestricted.
 

	
 
\medskip
 

	
 
Thus, the GPLv2 protects users fair and unregulated use rights precisely by
 
not attempting to cover them.  Furthermore, the GPLv2 ensures the freedom
 
to run specifically by stating the following:
 
\begin{quote}
 
''The act of running the Program is not restricted.''
 
\end{quote}
 
Thus, users are explicitly given the freedom to run by GPLv2~\S0.
 

	
 
\medskip
 

	
 
The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used
 
throughout.  The only one worth discussing in detail is ``work based on
 
the Program''.  The reason this definition is particularly interesting is
 
not for the definition itself, which is rather straightforward, but
 
because it clears up a common misconception about the GPL\@.
 

	
 
The GPL is often mistakenly criticized because it fails to give a
 
definition of ``derivative work''.  In fact, it would be incorrect and
 
problematic if the GPL attempted to define this.  A copyright license, in
 
fact, has no control over what may or may not be a derivative work.  This
 
matter is left up to copyright law and the courts --- not the licenses that utilize it.
 

	
 
It is certainly true that copyright law as a whole does not propose clear
 
and straightforward guidelines for what is and is not a derivative
 
software work under copyright law.  However, no copyright license --- not
 
even the GNU GPL --- can be blamed for this.  Legislators and court
 
opinions must give us guidance to decide the border cases.
 

	
 
\section{GPLv2~\S1: Verbatim Copying}
 
\label{GPLv2s1}
 

	
 
GPLv2~\S1 covers the matter of redistributing the source code of a program
 
exactly as it was received. This section is quite straightforward.
 
However, there are a few details worth noting here.
 

	
 
The phrase ``in any medium'' is important.  This, for example, gives the
 
freedom to publish a book that is the printed copy of the program's source
 
code.  It also allows for changes in the medium of distribution.  Some
 
vendors may ship Free Software on a CD, but others may place it right on
 
the hard drive of a pre-installed computer.  Any such redistribution media
 
is allowed.
 

	
 
Preservation of copyright notice and license notifications are mentioned
 
specifically in GPLv2~\S1.  These are in some ways the most important part of
 
the redistribution, which is why they are mentioned by name.  GPL
 
always strives to make it abundantly clear to anyone who receives the
 
software what its license is.  The goal is to make sure users know their
 
rights and freedoms under GPL, and to leave no reason that users might be
 
surprised the software is GPL'd. Thus
 
throughout the GPL, there are specific references to the importance of
 
notifying others down the distribution chain that they have rights under
 
GPL.
 

	
 
Also mentioned by name is the warranty disclaimer. Most people today do
 
not believe that software comes with any warranty.  Notwithstanding the
 
\href{http://mlis.state.md.us/2000rs/billfile/hb0019.htm}{Maryland's} and \href{http://leg1.state.va.us/cgi-bin/legp504.exe?001+ful+SB372ER}{Virginia's} UCITA bills, there are few or no implied warranties with software.
 
However, just to be on the safe side, GPL clearly disclaims them, and the
 
GPL requires redistributors to keep the disclaimer very visible. (See
 
Sections~\ref{GPLv2s11} and~\ref{GPLv2s12} of this tutorial for more on GPL's
 
warranty disclaimers.)
 

	
 
Note finally that GPLv2~\S1 creates groundwork for the important defense of
 
commercial freedom.  GPLv2~\S1 clearly states that in the case of verbatim
 
copies, one may make money.  Redistributors are fully permitted to charge
 
for the redistribution of copies of Free Software. In addition, they may
 
provide the warranty protection that the GPL disclaims as an additional
 
service for a fee. (See Section~\ref{Business Models} for more discussion
 
on making a profit from Free Software redistribution.)
 

	
 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 

	
 
\chapter{Derivative Works: Statute and Case Law}
 

	
 
We digress for this chapter from our discussion of GPL's exact text to
 
consider the matter of derivative works --- a concept that we must
 
understand fully before considering GPLv2~\S\S2--3\@. GPL, and Free
 
Software licensing in general, relies critically on the concept of
 
``derivative work'' since software that is ``independent,'' (i.e., not
 
``derivative'') of Free Software need not abide by the terms of the
 
applicable Free Software license. As much is required by \S~106 of the
 
Copyright Act, 17 U.S.C. \S~106 (2002), and admitted by Free Software
 
licenses, such as the GPL, which (as we have seen) states in GPLv2~\S0 that ``a
 
`work based on the Program' means either the Program or any derivative
 
work under copyright law.'' It is being a derivative work of Free Software
 
that triggers the necessity to comply with the terms of the Free Software
 
license under which the original work is distributed. Therefore, one is
 
left to ask, just what is a ``derivative work''? The answer to that
 
question differs depending on which court is being asked.
 

	
 
The analysis in this chapter sets forth the differing definitions of
 
derivative work by the circuit courts. The broadest and most
 
established definition of derivative work for software is the
 
abstraction, filtration, and comparison test (``the AFC test'') as
 
created and developed by the Second Circuit. Some circuits, including
 
the Ninth Circuit and the First Circuit, have either adopted narrower
 
versions of the AFC test or have expressly rejected the AFC test in
 
favor of a narrower standard. Further, several other circuits have yet
 
to adopt any definition of derivative work for software.
 

	
 
As an introductory matter, it is important to note that literal copying of
 
a significant portion of source code is not always sufficient to establish
 
that a second work is a derivative work of an original
 
program. Conversely, a second work can be a derivative work of an original
 
program even though absolutely no copying of the literal source code of
 
the original program has been made. This is the case because copyright
 
protection does not always extend to all portions of a program's code,
 
while, at the same time, it can extend beyond the literal code of a
 
program to its non-literal aspects, such as its architecture, structure,
 
sequence, organization, operational modules, and computer-user interface.
 

	
 
\section{The Copyright Act}
 

	
 
The copyright act is of little, if any, help in determining the definition
 
of a derivative work of software. However, the applicable provisions do
 
provide some, albeit quite cursory, guidance. Section 101 of the Copyright
 
Act sets forth the following definitions:
 

	
 
\begin{quotation}
 
A ``computer program'' is a set of statements or instructions to be used
 
directly or indirectly in a computer in order to bring about a certain
 
result.
 

	
 
A ``derivative work'' is a work based upon one or more preexisting works,
 
such as a translation, musical arrangement, dramatization,
 
fictionalization, motion picture version, sound recording, art
 
reproduction, abridgment, condensation, or any other form in which a work
 
may be recast, transformed, or adapted. A work consisting of editorial
 
revisions, annotations, elaborations, or other modifications which, as a
 
whole, represent an original work of authorship, is a ``derivative work.''
 
\end{quotation}
 

	
 
These are the only provisions in the Copyright Act relevant to the
 
determination of what constitutes a derivative work of a computer
 
program. Another provision of the Copyright Act that is also relevant to
 
the definition of derivative work is \S~102(b), which reads as follows:
 

	
 
\begin{quotation}
 
In no case does copyright protection for an original work of authorship
 
extend to any idea, procedure, process, system, method of operation,
 
concept, principle, or discovery, regardless of the form in which it is
 
described, explained, illustrated, or embodied in such work.
 
\end{quotation}
 

	
 
Therefore, before a court can ask whether one program is a derivative work
 
of another program, it must be careful not to extend copyright protection
 
to any ideas, procedures, processes, systems, methods of operation,
 
concepts, principles, or discoveries contained in the original program. It
 
is the implementation of this requirement to ``strip out'' unprotectable
 
elements that serves as the most frequent issue over which courts
 
disagree.
 

	
 
\section{Abstraction, Filtration, Comparison Test}
 

	
 
As mentioned above, the AFC test for determining whether a computer
 
program is a derivative work of an earlier program was created by the
 
Second Circuit and has since been adopted in the Fifth, Tenth, and
 
Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982
 
F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural
 
Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe,
 
Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates
 
Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993);
 
Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman
 
v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings,
 
Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).
 

	
 
Under the AFC test, a court first abstracts from the original program its
 
constituent structural parts. Then, the court filters from those
 
structural parts all unprotectable portions, including incorporated ideas,
 
expression that is necessarily incidental to those ideas, and elements
 
that are taken from the public domain. Finally, the court compares any and
 
all remaining kernels of creative expression to the structure of the
 
second program to determine whether the software programs at issue are
 
substantially similar so as to warrant a finding that one is the
 
derivative work of the other.
 

	
 
Often, the courts that apply the AFC test will perform a quick initial
 
comparison between the entirety of the two programs at issue in order to
 
help determine whether one is a derivative work of the other. Such a
 
holistic comparison, although not a substitute for the full application of
 
the AFC test, sometimes reveals a pattern of copying that is not otherwise
 
obvious from the application of the AFC test when, as discussed below,
 
only certain components of the original program are compared to the second
 
program. If such a pattern is revealed by the quick initial comparison,
 
the court is more likely to conclude that the second work is indeed a
 
derivative of the original.
 

	
 
\subsection{Abstraction}
 

	
 
The first step courts perform under the AFC test is separation of the
 
work's ideas from its expression. In a process akin to reverse
 
engineering, the courts dissect the original program to isolate each level
 
of abstraction contained within it. Courts have stated that the
 
abstractions step is particularly well suited for computer programs
 
because it breaks down software in a way that mirrors the way it is
 
typically created. However, the courts have also indicated that this step
 
of the AFC test requires substantial guidance from experts, because it is
 
extremely fact and situation specific.
 

	
 
By way of example, one set of abstraction levels is, in descending order
 
of generality, as follows: the main purpose, system architecture, abstract
 
data types, algorithms and data structures, source code, and object
 
code. As this set of abstraction levels shows, during the abstraction step
 
of the AFC test, the literal elements of the computer program, namely the
 
source and object code, are defined as particular levels of
 
abstraction. Further, the source and object code elements of a program are
 
not the only elements capable of forming the basis for a finding that a
 
second work is a derivative of the program. In some cases, in order to
 
avoid a lengthy factual inquiry by the court, the owner of the copyright in
 
the original work will submit its own list of what it believes to be the
 
protected elements of the original program. In those situations, the court
 
will forgo performing its own abstraction, and proceed to the second step of
 
the AFC test.
 

	
 
\subsection{Filtration}
 

	
 
The most difficult and controversial part of the AFC test is the second
 
step, which entails the filtration of protectable expression contained in
 
the original program from any unprotectable elements nestled therein. In
 
determining which elements of a program are unprotectable, courts employ a
 
myriad of rules and procedures to sift from a program all the portions
 
that are not eligible for copyright protection.
 

	
 
First, as set forth in \S~102(b) of the Copyright Act, any and all ideas
 
embodied in the program are to be denied copyright protection. However,
 
implementing this rule is not as easy as it first appears. The courts
 
readily recognize the intrinsic difficulty in distinguishing between ideas
 
and expression and that, given the varying nature of computer programs,
 
doing so will be done on an ad hoc basis. The first step of the AFC test,
 
the abstraction, exists precisely to assist in this endeavor by helping
 
the court separate out all the individual elements of the program so that
 
they can be independently analyzed for their expressive nature.
 

	
 
A second rule applied by the courts in performing the filtration step of
 
the AFC test is the doctrine of merger, which denies copyright protection
 
to expression necessarily incidental to the idea being expressed. The
 
reasoning behind this doctrine is that when there is only one way to
 
express an idea, the idea and the expression merge, meaning that the
 
expression cannot receive copyright protection due to the bar on copyright
 
protection extending to ideas. In applying this doctrine, a court will ask
 
whether the program's use of particular code or structure is necessary for
 
the efficient implementation of a certain function or process. If so, then
 
that particular code or structure is not protected by copyright and, as a
 
result, it is filtered away from the remaining protectable expression.
 

	
 
A third rule applied by the courts in performing the filtration step of
 
the AFC test is the doctrine of scenes a faire, which denies copyright
 
protection to elements of a computer program that are dictated by external
 
factors. Such external factors can include:
 

	
 
\begin{itemize}
 

	
 
  \item The mechanical
 
specifications of the computer on which a particular program is intended
 
to operate
 

	
 
  \item Compatibility requirements of other programs with which a
 
program is designed to operate in conjunction
 

	
 
  \item Computer manufacturers'
 
design standards
 

	
 
  \item Demands of the industry being serviced, and
 

	
 
widely accepted programming practices within the computer industry
 

	
 
\end{itemize}
 

	
 
Any code or structure of a program that was shaped predominantly in
 
response to these factors is filtered out and not protected by
 
copyright. Lastly, elements of a computer program are also to be filtered
 
out if they were taken from the public domain or fail to have sufficient
 
originality to merit copyright protection.
 

	
 
Portions of the source or object code of a computer program are rarely
 
filtered out as unprotectable elements. However, some distinct parts of
 
source and object code have been found unprotectable. For example,
 
constant s, the invariable integers comprising part of formulas used to
 
perform calculations in a program, are unprotectable. Further, although
 
common errors found in two programs can provide strong evidence of
 
copying, they are not afforded any copyright protection over and above the
 
protection given to the expression containing them.
 

	
 
\subsection{Comparison}
 

	
 
The third and final step of the AFC test entails a comparison of the
 
original program's remaining protectable expression to a second
 
program. The issue will be whether any of the protected expression is
 
copied in the second program and, if so, what relative importance the
 
copied portion has with respect to the original program overall. The
 
ultimate inquiry is whether there is ``substantial'' similarity between
 
the protected elements of the original program and the potentially
 
derivative work. The courts admit that this process is primarily
 
qualitative rather than quantitative and is performed on a case-by-case
 
basis. In essence, the comparison is an ad hoc determination of whether
 
the protectable elements of the original program that are contained in the
 
second work are significant or important parts of the original program. If
 
so, then the second work is a derivative work of the first. If, however,
 
the amount of protectable elements copied in the second work are so small
 
as to be de minimis, then the second work is not a derivative work of the
 
original.
 

	
 
\section{Analytic Dissection Test}
 

	
 
The Ninth Circuit has adopted the analytic dissection test to determine
 
whether one program is a derivative work of another. Apple Computer,
 
Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic
 
dissection test first considers whether there are substantial similarities
 
in both the ideas and expressions of the two works at issue. Once the
 
similar features are identified, analytic dissection is used to determine
 
whether any of those similar features are protected by copyright. This
 
step is the same as the filtration step in the AFC test. After identifying
 
the copyrightable similar features of the works, the court then decides
 
whether those features are entitled to ``broad'' or ``thin''
 
protection. ``Thin'' protection is given to non-copyrightable facts or
 
ideas that are combined in a way that affords copyright protection only
 
from their alignment and presentation, while ``broad'' protection is given
 
to copyrightable expression itself. Depending on the degree of protection
 
afforded, the court then sets the appropriate standard for a subjective
 
comparison of the works to determine whether, as a whole, they are
 
sufficiently similar to support a finding that one is a derivative work of
 
the other. ``Thin'' protection requires the second work be virtually
 
identical in order to be held a derivative work of an original, while
 
``broad'' protection requires only a ``substantial similarity.''
 

	
 
\section{No Protection for ``Methods of Operation''}
 

	
 
The First Circuit has taken the position that the AFC test is inapplicable 
 
when the works in question relate to unprotectable elements set forth in 
 
\S~102(b).  Their approach results in a much narrower definition
 
of derivative work for software in comparison to other circuits. Specifically, 
 
the
 
First Circuit holds that ``method of operation,'' as used in \S~102(b) of
 
the Copyright Act, refers to the means by which users operate
 
computers. Lotus Development Corp. v. Borland Int’l., Inc., 49 F.3d 807
 
(1st Cir. 1995).  In Lotus, the court held that a menu command
 
hierarchy for a computer program was uncopyrightable because it did not
 
merely explain and present the program’s functional capabilities to the
 
user, but also served as a method by which the program was operated and
 
controlled. As a result, under the First Circuit’s test, literal copying
 
of a menu command hierarchy, or any other ``method of operation,'' cannot
 
form the basis for a determination that one work is a derivative of
 
another.  As a result, courts in the First Circuit that apply the AFC test
 
do so only after applying a broad interpretation of \S~102(b) to filter out
 
unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc., 
 
683 F. Supp.2d 147, 154 (D. Mass. 2010).
 

	
 

	
 
\section{No Test Yet Adopted}
 

	
 
Several circuits, most notably the Fourth and Seventh, have yet to
 
declare their definition of derivative work and whether or not the
 
AFC, Analytic Dissection, or some other test best fits their
 
interpretation of copyright law. Therefore, uncertainty exists with
 
respect to determining the extent to which a software program is a
 
derivative work of another in those circuits. However, one may presume
 
that they would give deference to the AFC test since it is by far the
 
majority rule amongst those circuits that have a standard for defining
 
a software derivative work.
 

	
 
\section{Cases Applying Software Derivative Work Analysis}
 

	
 
In the preeminent case regarding the definition of a derivative work for
 
software, Computer Associates v. Altai, the plaintiff alleged that its
 
program, Adapter, which was used to handle the differences in operating
 
system calls and services, was infringed by the defendant's competitive
 
program, Oscar. About 30\% of Oscar was literally the same code as
 
that in Adapter. After the suit began, the defendant rewrote those
 
portions of Oscar that contained Adapter code in order to produce a new
 
version of Oscar that was functionally competitive with Adapter, without
 
have any literal copies of its code. Feeling slighted still, the
 
plaintiff alleged that even the second version of Oscar, despite having no
 
literally copied code, also infringed its copyrights. In addressing that
 
question, the Second Circuit promulgated the AFC test.
 

	
 
In abstracting the various levels of the program, the court noted a
 
similarity between the two programs' parameter lists and macros. However,
 
following the filtration step of the AFC test, only a handful of the lists
 
and macros were protectable under copyright law because they were either
 
in the public domain or required by functional demands on the
 
program. With respect to the handful of parameter lists and macros that
 
did qualify for copyright protection, after performing the comparison step
 
of the AFC test, it was reasonable for the district court to conclude that
 
they did not warrant a finding of infringement given their relatively minor
 
contribution to the program as a whole. Likewise, the similarity between
 
the organizational charts of the two programs was not substantial enough
 
to support a finding of infringement because they were too simple and
 
obvious to contain any original expression.
 

	
 
In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012),
 
the Northern District of California District Court examined the question of 
 
whether the application program interfaces (APIs) associated with the Java
 
programming language are entitled to copyright protection.  While the 
0 comments (0 inline, 0 general)