2ce793aa05
The enforcement section now has an integrated paragraph describing how enforcement relates to copyright, and refers back to a related section much earlier in the tutorial.
4946 lines
265 KiB
TeX
4946 lines
265 KiB
TeX
% gpl-lgpl.tex -*- LaTeX -*-
|
||
% Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course
|
||
%
|
||
|
||
% 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.
|
||
|
||
% FIXME-LATER: I should make a macro like the Texinfo @xref stuff for places
|
||
% where I'm saying ``see section X in this tutorial'', so that the extra
|
||
% verbiage isn't there in the HTML versions that I'll eventually do.
|
||
% Maybe something like that already exists? In the worst case, I could
|
||
% adapt @xref from texinfo.texi for it.
|
||
|
||
\newcommand{\defn}[1]{\emph{#1}}
|
||
|
||
\part{Detailed Analysis of the GNU GPL and Related Licenses}
|
||
|
||
{\parindent 0in
|
||
\tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\
|
||
\begin{tabbing}
|
||
Copyright \= \copyright{} 2003--2007, 2014 \hspace{.1mm} \= \kill
|
||
Copyright \> \copyright{} 2014 \> Bradley M. Kuhn \\
|
||
Copyright \> \copyright{} 2014 \> Anthony K. Sebro, Jr. \\
|
||
Copyright \> \copyright{} 2003--2007, 2014 \> Free Software Foundation, Inc. \\
|
||
Copyright \> \copyright{} 2014 \> Software Freedom Law Center.
|
||
\end{tabbing}
|
||
|
||
|
||
\vspace{.3in}
|
||
|
||
\begin{center}
|
||
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{.2in}
|
||
|
||
Copy editors of this part include: \\
|
||
Martin Michlmayr
|
||
|
||
\vspace{.2in}
|
||
|
||
|
||
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
|
||
|
||
\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 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
|
||
\url{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 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}
|
||
\label{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
|
||
modifications.
|
||
|
||
\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 from this freedom. Commercial sharing
|
||
includes selling copies of Free Software: that is, Free Software can
|
||
be distributed 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
|
||
augmenters 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 mechanisms 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.
|
||
|
||
\label{explaining-copyright}
|
||
|
||
The primary legal regime that applies to software is copyright law.
|
||
Proprietary software exists at all only because copyright law governs
|
||
software.\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 work 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 controls 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 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}
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
Copyleft,
|
||
which uses functional parts of copyright law to achieve an unusual result
|
||
(legal protection for free sharing) forms the core legal principle of these
|
||
licenses. It modifies, or ``hacks'' copyright law, which is usually employed to
|
||
strengthen the rights of authors or publishers, to strengthen instead the
|
||
rights of users. %FIXME-URGENT: end
|
||
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.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
This ``reciprocity'' or ``share and share alike'' rule protects both
|
||
developers, who avoid facing a ``proprietized'' competitor of their project,
|
||
and users, who can be sure that they will have all four basic freedoms not
|
||
only in the present version of the program they use, but in all its future
|
||
improved versions.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
The unit of copyright law is ``the work''. In that sense, the ``work''
|
||
referenced by the licenses is anything that can be copyrighted or will be
|
||
subject to the terms of copyright law. The GNU licenses exercise their scope
|
||
fully. Anything which is ``a work'' or a ``work based on a work'' licensed
|
||
under GPL is subject to its requirements, including the requirement of
|
||
complete and corresponding source code, unless it is specifically
|
||
excepted. This principle often causes theoretical or speculative dispute
|
||
among lawyers, because ``the work'' is not a unit of computer programming. In
|
||
order to determine whether a ``routine'' an ``object'', a ``function'', a
|
||
``library'' or any other unit of software is part of one ``work'' when combined
|
||
with other GPL’d code, we must ask a question that copyright law will not
|
||
directly answer in the same technical terms.
|
||
|
||
The key here is that the GNU GPL licenses mean to ``plow fence row to fence
|
||
row'', covering every version of ``work based on the work'' recognized by local
|
||
copyright law, but no further.
|
||
|
||
%FIXME-URGENT: end
|
||
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{GPLv3-drm} 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~\S1201} 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 the 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 for 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 a 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 the 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 the 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}
|
||
|
||
%FIXME-LATER: bad line break:
|
||
%\href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs
|
||
% General Public License}
|
||
The earliest copyleft licenses were specific to various GNU programs. For
|
||
example, 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 reusable 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, \textit{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 there are ultimately 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{GPLv3s14}). 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 choose (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 choose 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 choosing
|
||
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 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 before it,
|
||
GPLv2 remains an integral part of the copyleft licensing infrastructure. 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 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{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 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 otherwise 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 a larger work so as to criticize or suggest
|
||
changes. This fair use right 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 to 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'' or ``combined work''. In fact, it would be incorrect and
|
||
problematic if the GPL attempted to define these terms. A copyright license, in
|
||
fact, has no control over the rules of copyright themselves. Such rules are
|
||
the domain of copyright law and the courts --- not the licenses that utilize
|
||
those systems.
|
||
|
||
Copyright law as a whole doesn't propose clear and straightforward guidelines
|
||
for identifying the derivative and/or combined works of software. However,
|
||
no copyright license --- not even the GNU GPL --- can be blamed for this.
|
||
Legislators and court opinions must give us guidance in borderline cases.
|
||
|
||
% FIXME-URGENT: integrate (and back ref to copyleft section)
|
||
|
||
A
|
||
lawyer’s conclusion on that subject will be based on the application of rules
|
||
made in the context of literary or artistic copyright to the different
|
||
context of computer programming.
|
||
%FIXME-URGENT: end
|
||
|
||
\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 re-distributors 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. Re-distributors are fully permitted to charge
|
||
for the re-distribution 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}
|
||
\label{derivative-works}
|
||
|
||
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\@. The 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,
|
||
constants, 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 among 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
|
||
having 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
|
||
court expressly declined to rule whether all APIs are free to use without
|
||
license (872 F. Supp.2d 974 at 1002), the court held that the command
|
||
structure and taxonomy of the APIs were not protectable under copyright law.
|
||
Specifically, the court characterized the command structure and taxonomy as
|
||
both a ``method of operation'' (using an approach not dissimilar to the
|
||
First Circuit's analysis in Lotus) and a ``functional requirement for
|
||
compatibility'' (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and
|
||
Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies),
|
||
and thus unprotectable subject matter under \S~102(b).
|
||
|
||
Perhaps not surprisingly, there have been few other cases involving a highly
|
||
detailed software derivative work analysis. Most often, cases involve
|
||
clearer basis for decision, including frequent bad faith on the part of
|
||
the defendant or over-aggressiveness on the part of the plaintiff.
|
||
|
||
\section{How Much Do Derivative Works Matter?}
|
||
|
||
It is certainly true that GPL intends for any work that is determined a
|
||
``derivative work'' under copyright law must be licensed as a whole under
|
||
GPL\@, as will be discussed in the following chapter. However, as we finish
|
||
up our discussion derivative works, we must note that preparation of a
|
||
derivative work is by far not the only way to create a new work covered by
|
||
GPL\@.
|
||
|
||
In fact, while derivative work preparation is perhaps the most exciting area
|
||
of legal issues to consider, the more mundane ways to create a new work
|
||
covered by GPL are much more common. For example, copyright statutes
|
||
generally require permission from the copyright holder to grant explicit
|
||
permission to modify a work in any manner. As discussed in the next chapter,
|
||
the GPL {\em does} grants such permission, but requires the modified work must
|
||
also be licensed under the terms of the GPL (and only GPL:
|
||
see\S~\label{GPLv2s6} in this tutorial). Determining whether software was
|
||
modified is a substantially easier analysis than the derivative work
|
||
discussions and considerations in this chapter.
|
||
|
||
The question of derivative works, when and how they are made, is undoubtedly
|
||
an essential discussion in the interpretation and consideration of copyleft.
|
||
That is why this chapter was included in this tutorial. However, as we
|
||
return from this digression and resume discussion of the detailed text of the
|
||
GPLv2, we must gain a sense of perspective: most GPL questions center around
|
||
questions of modification and distribution, not preparation of derivative
|
||
works. Derivative work preparation is ultimately a small subset of the types
|
||
of modified versions of the software a developer might create, thus, while an
|
||
excessive focus on derivative works indulges us in the more exciting areas of
|
||
copyleft, we must keep a sense of perspective regarding their relative
|
||
importance.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
|
||
\chapter{Modified Source and Binary Distribution}
|
||
\label{source-and-binary}
|
||
|
||
In this chapter, we discuss the two core sections that define the rights
|
||
and obligations for those who modify, improve, and/or redistribute GPL'd
|
||
software. These sections, GPLv2~\S\S2--3, define the central core rights and
|
||
requirements of GPLv2\@.
|
||
|
||
\section{GPLv2~\S2: Share and Share Alike}
|
||
\label{GPLv2s2}
|
||
|
||
For many, this is where the ``magic'' happens that defends software
|
||
freedom upon redistribution. GPLv2~\S2 is the only place in GPLv2
|
||
that governs the modification controls of copyright law. If users
|
||
distribute modified versions a GPLv2'd program, they must follow the terms of GPLv2~\S2 in making
|
||
those changes. Thus, this sections ensures that the body of GPL'd software, as it
|
||
continues and develops, remains Free as in freedom.
|
||
|
||
To achieve that goal, GPLv2~\S2 first sets forth that the rights of
|
||
redistribution of modified versions are the same as those for verbatim
|
||
copying, as presented in GPLv2~\S1. Therefore, the details of charging money,
|
||
keeping copyright notices intact, and other GPLv2~\S1 provisions are intact
|
||
here as well. However, there are three additional requirements.
|
||
|
||
The first (GPLv2~\S2(a)) requires that modified files carry ``prominent
|
||
notices'' explaining what changes were made and the date of such
|
||
changes. This section does not prescribe some specific way of
|
||
marking changes nor does it control the process of how changes are made.
|
||
Primarily, GPLv2~\S2(a) seeks to ensure that those receiving modified
|
||
versions know the history of changes to the software. For some users,
|
||
it is important to know that they are using the standard version of
|
||
program, because while there are many advantages to using a fork,
|
||
there are a few disadvantages. Users should be informed about the
|
||
historical context of the software version they use, so that they can
|
||
make proper support choices. Finally, GPLv2~\S2(a) serves an academic
|
||
purpose --- ensuring that future developers can use a diachronic
|
||
approach to understand the software.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
section 2(c)
|
||
provides that if the program before modification ``normally reads commands
|
||
interactively when run'' and displays or prints legal information, all
|
||
copyright notices, warranty disclaimer, modification indications and a
|
||
pointer to the license text must be displayed or printed in interactive
|
||
use.
|
||
%FIXME-URGENT: end
|
||
\medskip
|
||
|
||
The second requirement (GPLv2~\S2(b)) contains the four short lines that embody
|
||
the legal details of ``share and share alike''. These 46 words are
|
||
considered by some to be the most worthy of careful scrutiny because
|
||
GPLv2~\S2(b), and they
|
||
can be a source of great confusion when not properly understood.
|
||
|
||
In considering GPLv2~\S2(b), first note the qualifier: it \textit{only} applies to
|
||
derivative, combined and/or modified works that ``you distribute or publish''. Despite years of
|
||
education efforts on this matter, many still believe that modifiers
|
||
of GPL'd software \textit{must} publish or otherwise
|
||
share their changes. On the contrary, GPLv2~\S2(b) {\bf does not apply if} the
|
||
changes are never distributed. Indeed, the freedom to make private,
|
||
personal, unshared changes to software for personal use only should be
|
||
protected and defended.\footnote{Most Free Software enthusiasts believe there is a {\bf
|
||
moral} obligation to redistribute changes that are generally useful,
|
||
and they often encourage companies and individuals to do so. However, there
|
||
is a clear distinction between what one {\bf ought} to do and what one
|
||
{\bf must} do.}
|
||
|
||
Next, we again encounter the same matter that appears in GPLv2~\S0, in the
|
||
following text:
|
||
\begin{quote}
|
||
``...that in whole or part contains or is derived from the Program or any part thereof.''
|
||
\end{quote}
|
||
Again, the GPL relies here on copyright law.
|
||
If, under copyright law, the modified version ``contains or is
|
||
derived from'' the GPL'd software, then the requirements of GPLv2~\S2(b)
|
||
apply. The GPL invokes its control as a copyright license over the
|
||
modification of the work in combination with its control over distribution
|
||
of the work.
|
||
|
||
The final clause of GPLv2~\S2(b) describes what the licensee must do if she
|
||
distributes or publishes a modified version of the work --- namely, the following:
|
||
\begin{quote}
|
||
[The work must] be licensed as a whole at no charge to all third parties
|
||
under the terms of this License.
|
||
\end{quote}
|
||
That is probably the most tightly-packed phrase in all of the GPL\@.
|
||
Consider each subpart carefully.
|
||
|
||
The work ``as a whole'' is what is to be licensed. This is an important
|
||
point that GPLv2~\S2 spends an entire paragraph explaining; thus this phrase is
|
||
worthy of a lengthy discussion here. As a programmer modifies a software
|
||
program, she generates new copyrighted material --- fixing expressions of
|
||
ideas into the tangible medium of electronic file storage. That
|
||
programmer is indeed the copyright holder of those new changes. However,
|
||
those changes are part and parcel to the original work distributed to
|
||
the programmer under GPL\@. Thus, the license of the original work
|
||
affects the license of the new whole combined and/or derivative work.
|
||
|
||
% {\cal I}
|
||
\newcommand{\gplusi}{$\mathcal{G\!\!+\!\!I}$}
|
||
\newcommand{\worki}{$\mathcal{I}$}
|
||
\newcommand{\workg}{$\mathcal{G}$}
|
||
|
||
\label{separate-and-independent}
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
But the GNU GPL licenses recognize what is outside their scope. Where a programmer’s work is
|
||
``separate and independent'' from any GPL’d program code with which it could be
|
||
combined, then the obligations of copyleft do not extend to the work
|
||
separately distributed. Far from attempting to extend copyleft beyond the
|
||
scope of copyright, the licenses explicitly recognize.
|
||
|
||
%FIXME-URGENT: end
|
||
It is certainly possible to take an existing independent work (called
|
||
\worki{}) and combine it with a GPL'd program (called \workg{}). The
|
||
license of \worki{}, when it is distributed as a separate and independent
|
||
work, remains the prerogative of the copyright holder of \worki{}.
|
||
However, when \worki{} is combined with \workg{}, it produces a new work
|
||
that is the combination of the two (called \gplusi{}). The copyright of
|
||
this combined work, \gplusi{}, is held by the original copyright
|
||
holder of each of the two works.
|
||
|
||
In this case, GPLv2~\S2 lays out the terms by which \gplusi{} may be
|
||
distributed and copied. By default, under copyright law, the copyright
|
||
holder of \worki{} would not have been permitted to distribute \gplusi{};
|
||
copyright law forbids it without the expressed permission of the copyright
|
||
holder of \workg{}. (Imagine, for a moment, if \workg{} were a proprietary
|
||
product --- would its copyright holders give you permission to create and distribute
|
||
\gplusi{} without paying them a hefty sum?) The license of \workg{}, the
|
||
GPL, states the options for the copyright holder of \worki{}
|
||
who may want to create and distribute \gplusi{}. The GPL's pre-granted
|
||
permission to create and distribute combined and/or derivative works, provided the terms
|
||
of the GPL are upheld, goes far above and beyond the permissions that one
|
||
would get with a typical work not covered by a copyleft license. (Thus, to
|
||
say that this condition is any way unreasonable is simply ludicrous.)
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
The GPL licenses, then, are explicit about limiting the scope of copyleft to
|
||
the scope of copyright. They do not, however, as is sometimes suggested, do
|
||
so in a way that distinguishes ``dynamic'' from ``static'' linking of program
|
||
code in ``early-binding'' programming languages. It is occasionally suggested
|
||
that a subroutine ``dynamically'' linked to GPL’d code is, by virtue of the
|
||
linking alone, inherently outside the scope of copyleft on the main
|
||
work. This is a misunderstanding. When two software components are joined
|
||
together to make one work (whether a main and some library subroutines, two
|
||
objects with their respective methods, or a program and a ``plugin'') the
|
||
combination infringes the copyright on the components if the combination
|
||
required copyright permission from the component copyright holders, and such
|
||
permission was either not available or was available on terms that were not
|
||
observed.
|
||
|
||
Where a combination is made with GPL’d or AGPL’d components, the
|
||
only available permission is copyleft, and its terms must be observed on the
|
||
combination as a whole if the GPL’d component is to be used at all. Whether
|
||
the combination is made with a linker before distribution of the executable,
|
||
is made by the OS kernel in order to share libraries for execution efficiency
|
||
at runtime, or results from ``late-binding'' of references in the language at
|
||
runtime (as in Java programs) is irrelevant.
|
||
%FIXME-URGENT: end
|
||
\medskip
|
||
|
||
\label{GPLv2s2-at-no-charge}
|
||
The next phrase of note in GPLv2~\S2(b) is ``licensed \ldots at no charge.''
|
||
This phrase confuses many. The sloppy reader points out this as ``a
|
||
contradiction in GPL'' because (in their confused view) that clause of GPLv2~\S2 says that re-distributors cannot
|
||
charge for modified versions of GPL'd software, but GPLv2~\S1 says that
|
||
they can. Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit re-distributors from
|
||
charging when performing the acts governed by copyright
|
||
law,\footnote{Recall that you could by default charge for any acts not
|
||
governed by copyright law, because the license controls are confined
|
||
by copyright.} but rather that they cannot charge a fee for the
|
||
\emph{license itself}. In other words, redistributors of (modified
|
||
and unmodified) GPL'd works may charge any amount they choose for
|
||
performing the modifications on contract or the act of transferring
|
||
the copy to the customer, but they may not charge a separate licensing
|
||
fee for the software.
|
||
|
||
GPLv2~\S2(b) further states that the software must ``be licensed \ldots to all
|
||
third parties.'' This too yields some confusion, and feeds the
|
||
misconception mentioned earlier --- that all modified versions must be made
|
||
available to the public at large. However, the text here does not say
|
||
that. Instead, it says that the licensing under terms of the GPL must
|
||
extend to anyone who might, through the distribution chain, receive a copy
|
||
of the software. Distribution to all third parties is not mandated here,
|
||
but GPLv2~\S2(b) does require re-distributors to license the whole work in
|
||
a way that extends to all third parties who may ultimately receive a
|
||
copy of the software.
|
||
|
||
In summary, GPLv2\ 2(b) says what terms under which the third parties must
|
||
receive this no-charge license. Namely, they receive it ``under the terms
|
||
of this License'', the GPLv2. When an entity \emph{chooses} to redistribute
|
||
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.
|
||
|
||
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'ed Web browsing software program, or on that party's
|
||
creation and use of modified versions of that GPL'ed program. However, if a
|
||
party uses that program without
|
||
complying with the GPLv2, then Company \compA{} can assert both copyright
|
||
infringement claims against the non-GPLv2-compliant party and
|
||
infringement of the patent, because the implied patent license only
|
||
extends to use of the software in accordance with the GPLv2. Further, if
|
||
Company \compB{} distributes a competitive advanced Web browsing program
|
||
that is not a modified version of Company \compA{}'s GPL'd Web browsing software
|
||
program, Company \compA{} is free to assert its patent against any user or
|
||
distributor of that product. It is irrelevant whether Company \compB's
|
||
program is also distributed under the GPLv2, as Company \compB{} can not grant
|
||
implied licenses to Company \compA's patent.
|
||
|
||
This result also reassures companies that they need not fear losing their
|
||
proprietary value in patents to competitors through the GPLv2 implied patent
|
||
license, as only those competitors who adopt and comply with the GPLv2's
|
||
terms can benefit from the implied patent license. To continue the
|
||
example above, Company \compB{} does not receive a free ride on Company
|
||
\compA's patent, as Company \compB{} has not licensed-in and then
|
||
redistributed Company A's advanced Web browser under the GPLv2. If Company
|
||
\compB{} does do that, however, Company \compA{} still has not lost
|
||
competitive advantage against Company \compB{}, as Company \compB{} must then,
|
||
when it re-distributes Company \compA's program, grant an implied license
|
||
to any of its patents that cover the program. Further, if Company \compB{}
|
||
relicenses an improved version of Company A's program, it must do so under
|
||
the GPLv2, meaning that any patents it holds that cover the improved version
|
||
are impliedly licensed to any licensee. As such, the only way Company
|
||
\compB{} can benefit from Company \compA's implied patent license, is if it,
|
||
itself, distributes Company \compA's software program and grants an
|
||
implied patent license to any of its patents that cover that program.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{Defending Freedom on Many Fronts}
|
||
|
||
Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the
|
||
core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3.
|
||
GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are
|
||
not infringed, are enforceable, are kept to the confines of copyright law but
|
||
also not trumped by other copyright agreements or components of other
|
||
entirely separate legal systems. In short, while GPLv2~\S\S0--3 are the parts
|
||
of the license that defend the freedoms of users and programmers,
|
||
GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear
|
||
so that \S\S~0--3 can do their jobs.
|
||
|
||
\section{GPLv2~\S4: Termination on Violation}
|
||
\label{GPLv2s4}
|
||
|
||
GPLv2~\S4 is GPLv2's termination clause. Upon first examination, it seems
|
||
strange that a license with the goal of defending users' and programmers'
|
||
freedoms for perpetuity in an irrevocable way would have such a clause.
|
||
However, upon further examination, the difference between irrevocability
|
||
and this termination clause becomes clear.
|
||
|
||
The GPL is irrevocable in the sense that once a copyright holder grants
|
||
rights for someone to copy, modify and redistribute the software under terms
|
||
of the GPL, they cannot later revoke that grant. Since the GPL has no
|
||
provision allowing the copyright holder to take such a prerogative, the
|
||
license is granted as long as the copyright remains in effect.\footnote{In
|
||
the USA, due to unfortunate legislation, the length of copyright is nearly
|
||
perpetual, even though the Constitution forbids perpetual copyright.} The
|
||
copyright holders have the right to relicense the same work under different
|
||
licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to
|
||
stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used),
|
||
but they may not revoke the rights under GPLv2 already granted.
|
||
|
||
In fact, when an entity loses their right to copy, modify and distribute
|
||
GPL'd software, it is because of their \emph{own actions}, not that of the
|
||
copyright holder. The copyright holder does not decide when GPLv2~\S4
|
||
termination occurs (if ever); rather, the actions of the licensee determine
|
||
that.
|
||
|
||
Under copyright law, the GPL has granted various rights and freedoms to
|
||
the licensee to perform specific types of copying, modification, and
|
||
redistribution. By default, all other types of copying, modification, and
|
||
redistribution are prohibited. GPLv2~\S4 says that if you undertake any of
|
||
those other types (e.g., redistributing binary-only in violation of GPLv2~\S3),
|
||
then all rights under the license --- even those otherwise permitted for
|
||
those who have not violated --- terminate automatically.
|
||
|
||
GPLv2~\S4 makes GPLv2 enforceable. If licensees fail to adhere to the
|
||
license, then they are stuck without any permission under to engage in
|
||
activities covered by copyright law. They must completely cease and desist
|
||
from all copying, modification and distribution of the GPL'd software.
|
||
|
||
At that point, violating licensees must gain the forgiveness of the copyright
|
||
holders to have their rights restored. Alternatively, the violators could
|
||
negotiate another agreement, separate from GPL, with the copyright
|
||
holder. Both are common practice, although
|
||
\tutorialpartsplit{as discussed in \textit{A Practical Guide to GPL
|
||
Compliance}, there are }{Chapter~\ref{compliance-understanding-whos-enforcing}
|
||
explains further} key differences between these two very different uses of GPL.
|
||
|
||
\section{GPLv2~\S5: Acceptance, Copyright Style}
|
||
\label{GPLv2s5}
|
||
|
||
GPLv2~\S5 brings us to perhaps the most fundamental misconception and common
|
||
confusion about GPLv2\@. Because of the prevalence of proprietary software,
|
||
most users, programmers, and lawyers alike tend to be more familiar with
|
||
EULAs. EULAs are believed by their authors to be contracts, requiring
|
||
formal agreement between the licensee and the software distributor to be
|
||
valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap''
|
||
as mechanisms to perform acceptance ceremonies with EULAs.
|
||
|
||
The GPL does not need contract law to ``transfer rights.'' Usually, no rights
|
||
are transferred between parties. By contrast, the GPL is primarily a permission
|
||
slip to undertake activities that would otherwise have been prohibited
|
||
by copyright law. As such, GPL needs no acceptance ceremony; the
|
||
licensee is not even required to accept the license.
|
||
|
||
However, without the GPL, the activities of copying, modifying and
|
||
distributing the software would have otherwise been prohibited. So, the
|
||
GPL says that you only accepted the license by undertaking activities that
|
||
you would have otherwise been prohibited without your license under GPL\@.
|
||
This is a certainly subtle point, and requires a mindset quite different
|
||
from the contractual approach taken by EULA authors.
|
||
|
||
An interesting side benefit to GPLv2~\S5 is that the bulk of users of Free
|
||
Software are not required to accept the license. Undertaking fair and
|
||
unregulated use of the work, for example, does not bind you to the GPL,
|
||
since you are not engaging in activity that is otherwise controlled by
|
||
copyright law. Only when you engage in those activities that might have an
|
||
impact on the freedom of others does license acceptance occur, and the
|
||
terms begin to bind you to fair and equitable sharing of the software. In
|
||
other words, the GPL only kicks in when it needs to for the sake of
|
||
freedom.
|
||
|
||
While GPL is by default a copyright license, it is certainly still possible
|
||
to consider GPL as a contract as well. For example, some distributors chose
|
||
to ``wrap'' their software in an acceptance ceremony to the GPL, and nothing in
|
||
the GPL prohibits that use. Furthermore, the ruling in \textit{Jacobsen
|
||
v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008)} indicates that \textbf{both}
|
||
copyright and contractual remedies may be sought by a copyright holder
|
||
seeking to enforce a license designed to uphold software freedom.
|
||
|
||
% FIXME-LATER: Write this
|
||
|
||
%\section{Using GPL Both as a Contract and Copyright License}
|
||
|
||
\section{GPLv2~\S6: GPL, My One and Only}
|
||
\label{GPLv2s6}
|
||
|
||
A point that was glossed over in Section~\ref{GPLv2s4}'s discussion of GPLv2~\S4
|
||
was the irrevocable nature of the GPL\@. The GPLv2 is indeed irrevocable,
|
||
and it is made so formally by GPLv2~\S6.
|
||
|
||
The first sentence in GPLv2~\S6 ensures that as software propagates down the
|
||
distribution chain, that each licensor can pass along the license to each
|
||
new licensee. Under GPLv2~\S6, the act of distributing automatically grants a
|
||
license from the original licensor to the next recipient. This creates a
|
||
chain of grants that ensure that everyone in the distribution has rights
|
||
under the GPLv2\@. In a mathematical sense, this bounds the bottom ---
|
||
making sure that future licensees get no fewer rights than the licensee before.
|
||
|
||
The second sentence of GPLv2~\S6 does the opposite; it bounds from the top. It
|
||
prohibits any licensor along the distribution chain from placing
|
||
additional restrictions on the user. In other words, no additional
|
||
requirements may trump the rights and freedoms given by GPLv2\@.
|
||
|
||
The final sentence of GPLv2~\S6 makes it abundantly clear that no individual
|
||
entity in the distribution chain is responsible for the compliance of any
|
||
other. This is particularly important for noncommercial users who have
|
||
passed along a source offer under GPLv2~\S3(c), as they cannot be assured that
|
||
the issuer of the offer will honor their GPLv2~\S3 obligations.
|
||
|
||
In short, GPLv2~\S6 says that your license for the software is your one and
|
||
only copyright license allowing you to copy, modify and distribute the
|
||
software.
|
||
|
||
% FIXME-URGENT: integrate
|
||
% Also, link to GPLv3 section
|
||
|
||
This is GPLv2’s ``automatic downstream licensing'' provision. 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. There is no requirement to take any action
|
||
to ensure the downstream recipient’s acceptance of the license terms, see
|
||
above. 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, as \S6 says, parties
|
||
themselves remaining 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. Their
|
||
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.
|
||
|
||
%FIXME-URGENT: end
|
||
\section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''}
|
||
\label{GPLv2s7}
|
||
|
||
In essence, GPLv2~\S7 is a verbosely worded way of saying for non-copyright
|
||
systems what GPLv2~\S6 says for copyright. If there exists any reason that a
|
||
distributor knows of that would prohibit later licensees from exercising
|
||
their full rights under GPL, then distribution is prohibited.
|
||
|
||
Originally, this was designed as the title of this section suggests --- as
|
||
a last ditch effort to make sure that freedom was upheld. However, in
|
||
modern times, it has come to give much more. Now that the body of GPL'd
|
||
software is so large, patent holders who would want to be distributors of
|
||
GPL'd software have a tough choice. They must choose between avoiding
|
||
distribution of GPL'd software that exercises the teachings of their
|
||
patents, or grant a royalty-free, irrevocable, non-exclusive license to
|
||
those patents. Many companies have chosen the latter.
|
||
|
||
Thus, GPLv2~\S7 rarely gives software death by stopping its distribution.
|
||
Instead, it is inspiring patent holders to share their patents in the same
|
||
freedom-defending way that they share their copyrighted works.
|
||
|
||
\section{GPLv2~\S8: Excluding Problematic Jurisdictions}
|
||
\label{GPLv2s8}
|
||
|
||
GPLv2~\S8 is rarely used by copyright holders. Its intention is that if a
|
||
particular country, say Unfreedonia, grants particular patents or allows
|
||
copyrighted interfaces (no country to our knowledge even permits those
|
||
yet), that the GPLv2'd software can continue in free and unabated
|
||
distribution in the countries where such controls do not exist.
|
||
|
||
As far as is currently known, GPLv2~\S8 has very rarely been formally used by
|
||
copyright holders. Admittedly, some have used GPLv2~\S8 to explain various
|
||
odd special topics of distribution (usually related in some way to
|
||
GPLv2~\S7). However, generally speaking, this section is not proven
|
||
particularly useful in the more than two decades of GPLv2 history.
|
||
|
||
Meanwhile, despite many calls by the FSF (and others) for those licensors who
|
||
explicitly use this section to come forward and explain their reasoning, no
|
||
one ever did. Furthermore, research conducted during the GPLv3 drafting
|
||
process found exactly one licensor who had invoked this section to add an
|
||
explicit geographical distribution limitation, and the reasoning for that one
|
||
invocation was not fitting with FSF's intended spirit of GPLv2~\S8. As such,
|
||
GPLv2~\S8 was not included at all in GPLv3.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{Odds, Ends, and Absolutely No Warranty}
|
||
|
||
GPLv2~\S\S0--7 constitute the freedom-defending terms of the GPLv2. The remainder
|
||
of the GPLv2 handles administrivia and issues concerning warranties and
|
||
liability.
|
||
|
||
\section{GPLv2~\S9: FSF as Stewards of GPL}
|
||
\label{GPLv2s9}
|
||
|
||
FSF reserves the exclusive right to publish future versions of the GPL\@;
|
||
GPLv2~\S9 expresses this. While the stewardship of the copyrights on the body
|
||
of GPL'd software around the world is shared among thousands of
|
||
individuals and organizations, the license itself needs a single steward.
|
||
Forking of the code is often regrettable but basically innocuous. Forking
|
||
of licensing is disastrous.
|
||
|
||
(Chapter~\ref{tale-of-two-copylefts} discusses more about the various
|
||
versions of GPL.)
|
||
|
||
\section{GPLv2~\S10: Relicensing Permitted}
|
||
\label{GPLv2s10}
|
||
|
||
GPLv2~\S10 reminds the licensee of what is already implied by the nature of
|
||
copyright law. Namely, the copyright holder of a particular software
|
||
program has the prerogative to grant alternative agreements under separate
|
||
copyright licenses.
|
||
|
||
\section{GPLv2~\S11: No Warranty}
|
||
\label{GPLv2s11}
|
||
|
||
Most warranty disclaimer language shout at you. The
|
||
\href{http://www.law.cornell.edu/ucc/2/2-316}{Uniform Commercial
|
||
Code~\S2-316} requires that disclaimers of warranty be ``conspicuous''.
|
||
There is apparently general acceptance that \textsc{all caps} is the
|
||
preferred way to make something conspicuous, and that has over decades worked
|
||
its way into the voodoo tradition of warranty disclaimer writing.
|
||
|
||
That said, there is admittedly some authority under USA law suggesting that
|
||
effective warranty disclaimers that conspicuousness can be established by
|
||
capitalization and is absent when a disclaimer has the same typeface as the
|
||
terms surrounding it (see \textit{Stevenson v.~TRW, Inc.}, 987 F.2d 288, 296
|
||
(5th Cir.~1993)). While GPLv3's drafters doubted that such authority would
|
||
apply to copyright licenses like the GPL, the FSF has nevertheless left
|
||
warranty and related disclaimers in \textsc{all caps} throughout all versions
|
||
of GPL\@\footnote{One of the authors of this tutorial, Bradley M.~Kuhn, has
|
||
often suggested the aesthetically preferable compromise of a
|
||
\textsc{specifically designed ``small caps'' font, such as this one, as an
|
||
alternative to} WRITING IN ALL CAPS IN THE DEFAULT FONT (LIKE THIS),
|
||
since the latter adds more ugliness than conspicuousness. Kuhn once
|
||
engaged in reversion war with a lawyer who disagreed, but that lawyer never
|
||
answered Kuhn's requests for case law that argues THIS IS INHERENTLY MORE
|
||
CONSPICUOUS \textsc{Than this is}.}.
|
||
|
||
Some have argued the GPL is unenforceable in some jurisdictions because
|
||
its disclaimer of warranties is impermissibly broad. However, GPLv2~\S11
|
||
contains a jurisdictional savings provision, which states that it is to be
|
||
interpreted only as broadly as allowed by applicable law. Such a
|
||
provision ensures that both it, and the entire GPL, is enforceable in any
|
||
jurisdiction, regardless of any particular law regarding the
|
||
permissibility of certain warranty disclaimers.
|
||
|
||
Finally, one important point to remember when reading GPLv2~\S11 is that GPLv2~\S1
|
||
permits the sale of warranty as an additional service, which GPLv2~\S11 affirms.
|
||
|
||
\section{GPLv2~\S12: Limitation of Liability}
|
||
\label{GPLv2s12}
|
||
|
||
There are many types of warranties, and in some jurisdictions some of them
|
||
cannot be disclaimed. Therefore, usually agreements will have both a
|
||
warranty disclaimer and a limitation of liability, as we have in GPLv2~\S12.
|
||
GPLv2~\S11 thus gets rid of all implied warranties that can legally be
|
||
disavowed. GPLv2~\S12, in turn, limits the liability of the actor for any
|
||
warranties that cannot legally be disclaimed in a particular jurisdiction.
|
||
|
||
Again, some have argued the GPL is unenforceable in some jurisdictions
|
||
because its limitation of liability is impermissibly broad. However, \S
|
||
12, just like its sister, GPLv2~\S11, contains a jurisdictional savings
|
||
provision, which states that it is to be interpreted only as broadly as
|
||
allowed by applicable law. As stated above, such a provision ensures that
|
||
both GPLv2~\S12, and the entire GPL, is enforceable in any jurisdiction,
|
||
regardless of any particular law regarding the permissibility of limiting
|
||
liability.
|
||
|
||
So end the terms and conditions of the GNU General Public License.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{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. However,
|
||
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\footnote{The FSF noted in
|
||
that it did not generally agree with these views, and expressed puzzlement
|
||
by the energy with which they were expressed, given the existence of many
|
||
other, more difficult legal issues implicated by the GPL. Nevertheless,
|
||
the FSF argued that it made sense to eliminate usage of local copyright
|
||
terminology to good effect.}. Admittedly, even though differently-labeled
|
||
concepts corresponding to the derivative work are recognized in all copyright
|
||
law systems, these counterpart concepts might differ to some degree in scope
|
||
and breadth from the USA derivative work.
|
||
|
||
% FIXME: integrate
|
||
|
||
So in GPLv3, we and our clients at the Free Software Foundation
|
||
decided to drop all illustrative reference to US ``derivative works,''
|
||
returning to the base concept only: GPL covers the licensed work and all
|
||
works based on the work, where ``based on the work'' is defined as any
|
||
modification or combination with the licensed work that requires copyright
|
||
permission to make.
|
||
% FIXME-URGENT: end
|
||
|
||
The goal and intention of GPLv2 was always to cover all rights governed by
|
||
relevant copyright law, in the USA and elsewhere. GPLv3 therefore takes the
|
||
task of internationalizing the license further by removing references to
|
||
derivative works and by providing a more globally useful definition. The new
|
||
definition returns to the common elements of copyright law. Copyright
|
||
holders of works of software have the exclusive right to form new works by
|
||
modification of the original --- a right that may be expressed in various
|
||
ways in different legal systems. GPLv3 operates to grant this right to
|
||
successive generations of users (particularly through the copyleft conditions
|
||
set forth in GPLv3~\S5, as described later in this tutorial in its
|
||
\S~\ref{GPLv3s5}). Here in GPLv3~\S0, ``modify'' refers to basic copyright
|
||
rights, and then this definition of ``modify'' is used to define ``modified
|
||
version of'' and ``work based on'' as synonyms.
|
||
|
||
\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.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
Two terms are used in GPLv3 deliberately exotic to the language of
|
||
international copyright.
|
||
|
||
\subsection{Propagate}
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
To ``propagate'' a work covered by the license means any activity that
|
||
requires permission of copyright holders in the local legal system where the
|
||
activities are carried on. Personal use or modification for personal use are
|
||
activities explicitly excluded from ``propagation'' regardless of domestic
|
||
copyright law, in order to prevent domestic copyright law from trenching on
|
||
freedoms 0 to 2.
|
||
%FIXME-URGENT: end
|
||
|
||
The term ``propagate'' serves two purposes. First, ``propagate'' provides a
|
||
simple and convenient means for distinguishing between the kinds of uses of a
|
||
work that GPL imposes conditions on and the kinds of uses that GPL does not
|
||
(for the most part) impose conditions on.
|
||
|
||
Second, ``propagate'' helps globalize GPL in its wording and effect. When a
|
||
work is GPL'd, the copyright law of some particular country will govern
|
||
certain legal issues arising under the license. A term like ``distribute''
|
||
(or its equivalent in languages other than English) is used in several
|
||
national copyright statutes. Yet, practical experience with GPLv2 revealed
|
||
the awkwardness of using the term ``distribution'' in a license intended for
|
||
global use: the scope of ``distribution'' in the copyright context can differ
|
||
from country to country. The GPL never necessarily intended the specific
|
||
meaning of ``distribution'' that exists under USA (or any other country's)
|
||
copyright law.
|
||
|
||
Indeed, even within a single country and language, the term distribution may
|
||
be ambiguous; as a legal term of art, distribution varies significantly in
|
||
meaning among those countries that recognize it. For example, comments
|
||
during GPLv3's drafting process indicated that in at least one country,
|
||
distribution may not include network transfers of software but may include
|
||
interdepartmental transfers of physical copies within an organization.
|
||
Meanwhile, the copyright laws of many countries, as well as certain
|
||
international copyright treaties, recognize ``making available to the
|
||
public'' or ``communication to the public'' as one of the exclusive rights of
|
||
copyright holders.
|
||
|
||
Therefore, the GPL defines the term ``propagate'' by reference to activities
|
||
that require permission under ``applicable copyright law'', but excludes
|
||
execution and private modification from the definition. GPLv3's definition
|
||
also gives examples of activities that may be included within ``propagation''
|
||
but it also makes clear that, under the copyright laws of a given country,
|
||
``propagation'' may include other activities as well.
|
||
|
||
Thus, propagation is defined by behavior, and not by categories drawn from
|
||
some particular national copyright statute. This helps not only with
|
||
internationalization, but also factually-based terminology aids in
|
||
developers' and users' understanding of the GPL\@.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
As a further benefit, because ``propagation'' includes all
|
||
exclusive rights granted under any particular copyright regime, regimes that
|
||
require a valid license to account for all exclusive rights are automatically
|
||
complied with.
|
||
% FIXME-URGENT: end
|
||
|
||
\subsection{Convey}
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Any propagation that enables other parties to receive or make copies of the
|
||
work, is called ``conveying''. In general, conveying is the activity that
|
||
triggers copyleft obligations.
|
||
% FIXME-URGENT: end
|
||
|
||
Further to this point, a subset of propagate --- ``convey'' --- is defined.
|
||
Conveying includes activities that constitute propagation of copies to
|
||
others. As with the definition of propagate, GPLv3 thus addresses transfers
|
||
of copies of software in behavioral rather than statutory terms.
|
||
|
||
\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}
|
||
|
||
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}
|
||
|
||
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
|
||
interpretation of this tutorial's authors: the harder and more strained the
|
||
reader must study and read the system library exception, the more likely it
|
||
is that the library in question does not qualify for it.
|
||
|
||
\section{GPLv3~\S2: Basic Permissions}
|
||
\label{GPLv3S2}
|
||
|
||
%FIXME-URGENT: integrate
|
||
GPLv3 explicitly affirms your unlimited permission to run the
|
||
unmodified program. You can only make modifications, or otherwise propagate a
|
||
covered work, even one that you do not convey, so long as you are in
|
||
compliance with the license terms. If your license is terminated, then, for
|
||
example, you cannot continue to service your copies by making new modified
|
||
versions.
|
||
% FIXME-URGENT: end
|
||
|
||
GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed
|
||
in \S~\ref{GPLv2s0} of this tutorial). However, the usual style of
|
||
improvements found in GPLv3 are found here as well. For example, the first
|
||
sentence of GPLv3~\S2 furthers the goal internationalization. Under the
|
||
copyright laws of some countries, it may be necessary for a copyright license
|
||
to include an explicit provision setting forth the duration of the rights
|
||
being granted. In other countries, including the USA, such a provision is
|
||
unnecessary but permissible.
|
||
|
||
GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of
|
||
copyright fair use, or the equivalent under applicable law. These rights are
|
||
compatible with, and not in conflict with, the freedoms that the GPL seeks to
|
||
protect, and the GPL cannot and should not restrict them.
|
||
|
||
However, note that (sadly to some copyleft advocates) the unlimited freedom
|
||
to run is confined to the \textit{unmodified} Program. This confinement is
|
||
unfortunately necessary since Programs that do not qualify as a User Product
|
||
in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain
|
||
unfortunate restrictions on the freedom to run.\footnote{See
|
||
\S~\ref{freedom-to-run} of this tutorial for the details on ``the freedom to
|
||
run''.}
|
||
|
||
GPLv3~\S2\P2 distinguishes between activities of a licensee that are
|
||
permitted without limitation and activities that trigger additional
|
||
requirements. Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of
|
||
privately modifying and running the program. While these basic freedoms were
|
||
generally considered a standard part of users' rights under GPLv2 as well,
|
||
the GPLv3 states them herein more explicitly. In other words, there is no
|
||
direct analog to the first sentence of GPLv3~\S2\P2 in GPLv2
|
||
(See \S~\ref{gplv2-private-modification} of this tutorial for more on this issue.)
|
||
|
||
Also, GPLv3~\S2\P2 gives an explicit permission for a client to provide a
|
||
copy of its modified software to a contractor exclusively for that contractor
|
||
to modify it further, or run it, on behalf of the client. However, the
|
||
client can \textit{only} exercise this control over its own copyrighted
|
||
changes to the GPL-covered program. The parts of the program it obtained
|
||
from other contributors must be provided to the contractor with the usual GPL
|
||
freedoms. Thus, GPLv3 permits users to convey covered works to contractors
|
||
operating exclusively on the users' behalf, under the users' direction and
|
||
control, and to require the contractors to keep the users' copyrighted
|
||
changes confidential, but \textit{only if} the contractor is limited to acting
|
||
on the users' behalf (just as the users' employees would have to act).
|
||
|
||
The strict conditions in this ``contractors provision'' are needed so that it
|
||
cannot be twisted to fit other activities, such as making a program available
|
||
to downstream users or customers. By making the limits on this provision
|
||
very narrow, GPLv3 ensures that, in all other cases, contractor gets the
|
||
full freedoms of the GPL that they deserve.
|
||
|
||
The FSF was specifically asked to add this ``contractors provisions'' by
|
||
large enterprise users of Free Software, who often contract with non-employee
|
||
developers, working offsite, to make modifications intended for the user's
|
||
private or internal use, and often arrange with other companies to operate
|
||
their data centers. Whether GPLv2 permits these activities is not clear and
|
||
may depend on variations in copyright law in different jurisdictions. The
|
||
practices seem basically harmless, so FSF decided to make it clear they are
|
||
permitted.
|
||
|
||
GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing.
|
||
This provision ensures that GPL enforcement is always by the copyright
|
||
holder. Usually, sublicensing is regarded as a practical convenience or
|
||
necessity for the licensee, to avoid having to negotiate a license with each
|
||
licensor in a chain of distribution. The GPL solves this problem in another
|
||
way --- through its automatic licensing provision found in GPLv3~\S10 (which
|
||
is discussed in more detail in \S~\ref{GPLv3s10} of this tutorial).
|
||
|
||
\section{GPLv3's views on DRM and Device Lock-Down}
|
||
\label{GPLv3-drm}
|
||
|
||
The issues of DRM, device lock-down and encryption key disclosure were the
|
||
most hotly debated during the GPLv3 process. FSF's views on this were sadly
|
||
frequently misunderstood and, comparing the provisions related to these
|
||
issues in the earliest drafts of GPLv3 to the final version of GPLv3 shows
|
||
the FSF's willingness to compromise on tactical issues to reach the larger
|
||
goal of software freedom.
|
||
|
||
Specifically, GPLv3 introduced provisions that respond to the growing
|
||
practice of distributing GPL-covered programs in devices that employ
|
||
technical means to restrict users from installing and running modified
|
||
versions. This practice thwarts the expectations of developers and users
|
||
alike, because the right to modify is one of the core freedoms the GPL is
|
||
designed to secure.
|
||
|
||
Technological measures to defeat users' rights. These measures are often
|
||
described by such Orwellian phrases, such as ``digital rights management,''
|
||
which actually means limitation or outright destruction of users' legal
|
||
rights, or ``trusted computing,'' which actually means selling people
|
||
computers they cannot trust. However, these measures are alike in one basic
|
||
respect. They all employ technical means to turn the system of copyright law
|
||
(where the powers of the copyright holder are limited exceptions to general
|
||
freedom) into a virtual prison, where everything not specifically permitted
|
||
is utterly forbidden. This system of ``para-copyright'' was created well
|
||
after GPLv2 was written --- initially through legislation in the USA and the
|
||
EU, and later in other jurisdictions as well. This legislation creates
|
||
serious civil or even criminal penalties to escape from these restrictions
|
||
(commonly and aptly called ``jail-breaking a device''), even where the
|
||
purpose in doing so is to restore the users' legal rights that the technology
|
||
wrongfully prevents them from exercising.
|
||
|
||
GPLv2 did not address the use of technical measures to take back the rights
|
||
that the GPL granted, because such measures did not exist in 1991, and would
|
||
have been irrelevant to the forms in which software was then delivered to
|
||
users. GPLv3 addresses these issues, particularly because copylefted
|
||
software is ever more widely embedded in devices that impose technical
|
||
limitations on the user's freedom to change it.
|
||
|
||
However, FSF always made a clear distinction to avoid conflating these
|
||
``lock-down'' measures with legitimate applications that give users control,
|
||
as by enabling them to choose higher levels of system or data security within
|
||
their networks, or by allowing them to protect the security of their
|
||
communications using keys they can generate or copy to other devices for
|
||
sending or receiving messages. Such technologies present no obstacles to
|
||
software freedom and the goals of copyleft.
|
||
|
||
The public GPLv3 drafting process sought to balance these positions of
|
||
copyleft advocates with various desperate views of the larger
|
||
Free-Software-using community. Ultimately, FSF compromised to the GPLv3\S3
|
||
and GPLv3\S6 provisions that, taken together, are a minimalist set of terms
|
||
sufficient to protect the software freedom against the threat of invasive
|
||
para-copyright.
|
||
|
||
The compromises made were ultimately quite reasonable. The primary one is
|
||
embodied in GPLv3\S6's ``User Product'' definition (see \S~\ref{user-product}
|
||
in this tutorial for details). Additionally, some readers of early GPLv3
|
||
drafts seem to have assumed GPLv3 contained a blanket prohibition on DRM; but
|
||
it does not. In fact, no part of GPLv3 forbids DRM regarding non-GPL'd
|
||
works; rather, GPLv3 forbids the use of DRM specifically to lock-down
|
||
restrictions on users' ability to install modified versions of the GPL'd
|
||
software itself, but again, \textit{only} with regard to User Products.
|
||
|
||
\section{GPLv3~\S3: What Hath DMCA Wrought}
|
||
\label{GPLv3s3}
|
||
|
||
As discussed in \S~\ref{software-and-non-copyright} of this tutorial,
|
||
\href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC~\S1201} and
|
||
relate sections\footnote{These sections of the USC are often referred to as
|
||
the ``Digital Millennium Copyright Act'', or ``DMCA'', as that was the name
|
||
of the bill that so-modified these sections of the USC\@.} prohibits users
|
||
from circumventing technological measures that implement DRM\@. Since this
|
||
is part of copyright law and the GPL is primarily a copyright license, and
|
||
since what the DMCA calls ``circumvention'' is simply ``modifying the
|
||
software'' under the GPL, GPLv3 must disclaim that such anti-circumvention
|
||
provisions are not applicable to the GPLv3'd software. GPLv3\S3 shields
|
||
users from being subjected to liability under anti-circumvention law for
|
||
exercising their rights under the GPL, so far as the GPL can do so.
|
||
|
||
First, GPLv3\S3\P1 declares that no GPL'd program is part of an effective
|
||
technological protection measure, regardless of what the program does. Early
|
||
drafts of GPLv3\S3\P1 referred directly to the DMCA, but the final version
|
||
instead includes instead an international legal reference to
|
||
anticircumvention laws enacted pursuant to the 1996 WIPO treaty and any
|
||
similar laws. Lawyers outside the USA worried that a USA statutory reference
|
||
could be read as indicating a choice for application of USA law to the
|
||
license as a whole. While the FSF did not necessarily agree with that view,
|
||
the FSF decided anyway to refer to the WIPO treaty rather than DMCA, since
|
||
several national anticircumvention laws were (or will likely be) structured
|
||
more similarly to the anticircumvention provisions of the DMCA in their
|
||
implementation of WIPO\@. Furthermore, the addition of ``or similar laws''
|
||
provides an appropriate catch-all.
|
||
|
||
Furthermore, GPLv3\S3\P2 states precisely that a conveying party waives the
|
||
power to forbid circumvention of technological measures only to the extent
|
||
that such circumvention is accomplished through the exercise of GPL rights in
|
||
the conveyed work. GPLv3\S3\P2 makes clear that the referenced ``legal
|
||
rights'' are specifically rights arising under anticircumvention law. and
|
||
refers to both the conveying party's rights and to third party rights, as in
|
||
some cases the conveying party will also be the party legally empowered to
|
||
enforce or invoke rights arising under anticircumvention law.
|
||
|
||
These disclaimers by each licensor of any intention to use GPL'd software to
|
||
stringently control access to other copyrighted works should effectively
|
||
prevent any private or public parties from invoking DMCA-like laws against
|
||
users who escape technical restriction measures implemented by GPL'd
|
||
software.
|
||
|
||
\section{GPLv3~\S4: Verbatim Copying}
|
||
\label{GPLv3s4}
|
||
|
||
GPLv3~\S4 is a revision of GPLv2~\S1 (as discussed in \S~\ref{GPLv2s1} of
|
||
this tutorial). There are almost no changes to this section from the
|
||
GPLv2~\S1, other than to use the new defined terms.
|
||
|
||
The only notable change of ``a fee'' to ``any price or no price'' in the
|
||
first sentence of GPLv3\S4\P2. The GPLv2\S1\P1 means that the GPL permits
|
||
one to charge money for the distribution of software. Despite efforts by
|
||
copyleft advocates to explain this in GPLv2 itself and in other documents,
|
||
there are evidently some people who still believe that GPLv2 allows charging
|
||
for services but not for selling copies of software and/or that the GPL
|
||
requires downloads to be gratis. Perhaps this is because GPLv2 referred to
|
||
charging a ``fee''; the term ``fee'' is generally used in connection with
|
||
services.
|
||
|
||
GPLv2's wording also referred to ``the physical act of transferring.'' The
|
||
intention was to distinguish charging for transfers from attempts to impose
|
||
licensing fees on all third parties. ``Physical'' might be read, however, as
|
||
suggesting ``distribution in a physical medium only''.
|
||
|
||
To address these two issues, GPLv3 says ``price'' in place of ``fee,'' and
|
||
removes the term ``physical.''
|
||
|
||
GPLv3~\S4 has also been revised from its corresponding section in GPLv2 in
|
||
light of the GPLv3~\S7 (see \S~\ref{GPLv3s7} in this tutorial for more).
|
||
Specifically, a distributor of verbatim copies of the program's source code
|
||
must obey any existing additional terms that apply to parts of the program
|
||
pursuant to GPLv3~\S7. In addition, the distributor is required to keep
|
||
intact all license notices, including notices of such additional terms.
|
||
|
||
Finally, there is no harm in explicitly pointing out what ought to be
|
||
obvious: that those who convey GPL-covered software may offer commercial
|
||
services for the support of that software.
|
||
|
||
\section{GPLv3~\S5: Modified Source}
|
||
\label{GPLv3s5}
|
||
|
||
GPLv3\S5 is the rewrite of GPLv2\S2, which was discussed in \S~\ref{GPLv2s2}
|
||
of this tutorial. This section discusses the changes found in GPLv3\S5
|
||
compared to GPLv2\S2.
|
||
|
||
GPLv3\S5(a) still requires modified versions be marked with ``relevant
|
||
date'', but no longer says ``the date of any change''. The best practice is
|
||
to include the date of the latest and/or most significant changes and who
|
||
made those. Of course, compared to its GPLv2\S2(a), GPLv3\S5(a) slightly
|
||
relaxes the requirements regarding notice of changes to the program. In
|
||
particular, the modified files themselves need no longer be marked. This
|
||
reduces administrative burdens for developers of modified versions of GPL'd
|
||
software.
|
||
|
||
GPLv3\S5(b) is a new but simple provision. GPLv3\S5(b) requires that the
|
||
license text itself must be unmodified (except as permitted by GPLv3\S7; see
|
||
\S~\ref{GPLv3s7} in this tutorial). Furthermore, it removes any perceived
|
||
conflict between the words ``keep intact all notices'' in GPLv3\S4, since
|
||
operating under GPLv3\S5 still includes all the requirements of GPLv3\S4 by
|
||
reference.
|
||
|
||
GPLv3\S5(c) is the primary source-code-related copyleft provision of GPL. (The
|
||
object-code-related copyleft provisions are in GPLv3\S6, discussed in
|
||
\S~\ref{GPLv3s6} of this tutorial). Compared to GPLv2\S2(b), GPLv3\S5(c)
|
||
states that the GPL applies to the whole of the work. Such was stated
|
||
already in GPLv2\S2(b), in ``in whole or in part'', but this simplified
|
||
wording makes it clear it applies to the entire covered work.
|
||
|
||
Another change in GPLv3\S5(c) is the removal of the
|
||
words ``at no charge,'' which was often is misunderstood upon na\"{i}ve
|
||
reading of in GPLv2\S(b) (as discussed in \S~\ref{GPLv2s2-at-no-charge} of this
|
||
tutorial).
|
||
|
||
% FIXME-LATER: Write up something on 5d, and related it to Appropriate Legal Notices.
|
||
|
||
|
||
Note that of GPLv2~\S2's penultimate and ante-penultimate paragraphs are now
|
||
handled adequately by the definitions in GPLv3\S0 and as such, have no direct
|
||
analogs in GPLv3.
|
||
|
||
GPLv2~\S2's final paragraph, however, is reworded and expanded into the final
|
||
paragraph of GPLv3\S5, which now also covers issues related to copyright
|
||
compilations (but not compilations into object code --- that's in the next
|
||
section!). The intent and scope is the same as was intended in GPLv2.
|
||
|
||
\section{GPLv3~\S6: Non-Source and Corresponding Source}
|
||
\label{GPLv3s6}
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Section 6 states the compliance obligations for distributing ``non-source
|
||
forms'' of a program, which means any form other than the form preferred for
|
||
making modifications. In addition to binaries or executables, non-source
|
||
forms therefore include obfuscated, minimized, compressed or otherwise
|
||
non-preferred forms for modification. The requirement to provide complete and corresponding source code under \S6
|
||
closely parallels the provisions of GPLv2 \S3, above, but with changes
|
||
designed to make compliant provisioning easier under contemporary
|
||
technological conditions.
|
||
% FIXME-URGENT: end
|
||
GPLv3~\S6 clarifies and revises GPLv2~\S3. It requires distributors of GPL'd
|
||
object code to provide access to the corresponding source code, in one of
|
||
four specified ways. As noted in \S~\ref{GPLv3s0}, ``object code'' in GPLv3
|
||
is defined broadly to mean any non-source version of a work.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
GPLv3~\S6(a--b) now apply specifically to distribution of object code in a
|
||
physical product. Physical products include embedded systems, as well as
|
||
physical software distribution media such as CDs. As in GPLv2~\S3 (discussed
|
||
in \S~\ref{GPLv2s3} of this tutorial), the distribution of object code may
|
||
either be accompanied by the machine-readable source code, or it may be
|
||
accompanied by a valid written offer to provide the machine-readable source
|
||
code. However, unlike in GPLv2, that offer cannot be exercised by any third
|
||
party; rather, only those ``who possess the object code'' can exercise
|
||
the offer. (Note that this is a substantial narrowing of requirements of
|
||
offer fulfillment, and is a wonderful counterexample to dispute claims that
|
||
the GPLv3 has more requirements than GPLv2.)
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
GPLv3~\S6(b) further revises the requirements for the written offer to
|
||
provide source code. As before, the offer must remain valid for at least
|
||
three years. In addition, even after three years, a distributor of a product
|
||
containing GPL'd object code must offer to provide source code for as long as
|
||
the distributor also continues to offer spare parts or customer support for
|
||
the product model. This is a reasonable and appropriate requirement; a
|
||
distributor should be prepared to provide source code if he or she is
|
||
prepared to provide support for other aspects of a physical product.
|
||
|
||
GPLv3~\S6(a--b) clarifies that the medium for software interchange on which
|
||
the machine-readable source code is provided must be a durable physical
|
||
medium. GPLv3~\S6(b)(2), however, permits a distributor to instead offer to
|
||
provide source code from a network server instead, which is yet another
|
||
example GPLv3 looser in its requirements than GPLv2 (see
|
||
\S~\ref{GPLv2s3-medium-customarily} for details).
|
||
|
||
% FIXME-LATER: more information about source provision, cost of physically
|
||
% performing, reasonable fees, medium customary clearly being said durable
|
||
% connecting back to previous text
|
||
|
||
GPLv3\S6(c) gives narrower permission than GPLv2\S3(c). The ``pass along''
|
||
option for GPLv3\S6(c)(1) offers is now available only for individual
|
||
distribution of object code; moreover, such individual distribution can occur
|
||
only ``occasionally and noncommercially.'' A distributor cannot comply with
|
||
the GPL merely by making object code available on a publicly-accessible
|
||
network server accompanied by a copy of the written offer to provide source
|
||
code received from an upstream distributor.
|
||
|
||
%FIXME-LATER: tie back to the discussion of the occasional offer pass along
|
||
% stuff in GPLv2 this tutorial.
|
||
|
||
GPLv3~\S6(d) revises and improves GPLv2~\S3's final paragraph. When object
|
||
code is provided by offering access to copy the code from a designated place
|
||
(such as by enabling electronic access to a network server), the distributor
|
||
must merely offer equivalent access to copy the source code ``in the same way
|
||
through the same place''. This wording also permits a distributor to offer a
|
||
third party access to both object code and source code on a single network
|
||
portal or web page, even though the access may include links to different
|
||
physical servers. For example, a downstream distributor may provide a link
|
||
to an upstream distributor's server and arrange with the operator of that
|
||
server to keep the source code available for copying for as long as the
|
||
downstream distributor enables access to the object code. This codifies
|
||
formally the typical historical interpretation of GPLv2.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
This provision allows, for the first time, for third-party provision of
|
||
complete and corresponding source code in commercial distribution
|
||
situations. The obligation remains on the party distributing the non-source
|
||
form to point prominently (``next to'' the non-source download) to the
|
||
third-party source code provisioning server, and to ensure that this
|
||
third-party server remains in operation for required period.
|
||
% FIXME-URGENT: end
|
||
|
||
% FIXME-LATER: perhaps in enforcement section, but maybe here, note about
|
||
% ``slow down'' on source downloads being a compliance problem.
|
||
|
||
Furthermore, under GPLv3~\S6(d), distributors may charge for the conveyed
|
||
object code; however, those who pay to obtain the object code must be given
|
||
equivalent and gratis access to obtain the CCS. (If distributors convey the
|
||
object code gratis, distributors must likewise make CCS available without
|
||
charge.) Those who do not obtain the object code from that distributors
|
||
(perhaps because they choose not to pay the fee for object code) are outside
|
||
the scope of the provision; distributors are under no specific obligation to
|
||
give CCS to someone who has not purchased an object code download under
|
||
GPLv3~\S6(d). (Note: this does not change nor impact any obligations under
|
||
GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)
|
||
|
||
\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}
|
||
|
||
% FIXME-urgent: integrate
|
||
|
||
Section 6 also allows the provision of source via such a server when the
|
||
binary or other non-source form is distributed by peer-to-peer protocols such
|
||
as BitTorrent. Here the requirement is only that each peer be effectively
|
||
informed of the location of the source code on a server as above.
|
||
% FIXME-URGENT: end
|
||
|
||
Certain decentralized forms of peer-to-peer file sharing present a challenge
|
||
to the unidirectional view of distribution that is implicit in GPLv2 and
|
||
Draft 1 of GPLv3. Identification of an upstream/downstream link in
|
||
BitTorrent distribution is neither straightforward nor reasonable; such
|
||
distribution is multidirectional, cooperative and anonymous. In peer-to-peer
|
||
distribution systems, participants act both as transmitters and recipients of
|
||
blocks of a particular file, but they perceive the experience merely as users
|
||
and receivers, and not as distributors in any conventional sense. At any
|
||
given moment of time, most peers will not have the complete file.
|
||
|
||
Meanwhile, GPLv3~\S6(d) permits distribution of a work in object code form
|
||
over a network, provided that the distributor offers equivalent access to
|
||
copy the Corresponding Source Code ``in the same way through the same
|
||
place''. This wording might be interpreted to permit peer-to-peer
|
||
distribution of binaries \textit{if} they are packaged together with the CCS,
|
||
but such packaging is impractical, for at least three reasons. First, even if
|
||
the CCS is packaged with the object code, it will only be available to a
|
||
non-seeding peer at the end of the distribution process, but the peer will
|
||
already have been providing parts of the binary to others in the network.
|
||
Second, in practice, peer-to-peer forms of transmission are poorly suited
|
||
means for distributing CCS. In large distributions, packaging CCS with the
|
||
object code may result in a substantial increase in file size and
|
||
transmission time. Third, in current practice, CCS packages themselves tend
|
||
\textit{not} to be transmitted through BitTorrent --- owing to reduced demand
|
||
-- thus, there generally will be too few participants downloading the same
|
||
source package at the same time to enable effective seeding and distribution.
|
||
|
||
GPLv3~\S6(e) addresses these issues. If a licensee conveys such a work of
|
||
object code using peer-to-peer transmission, that licensee is in compliance
|
||
with GPLv3~\S6 if the licensee informs other peers where the object code and
|
||
its CCS are publicly available at no charge under subsection GPLv3~\S6(d).
|
||
The CCS therefore need not be provided through the peer-to-peer system that
|
||
was used for providing the binary.
|
||
|
||
Second, GPLv3\S9 also clarifies that ancillary propagation of a covered work
|
||
that occurs as part of the process of peer-to-peer file transmission does not
|
||
require acceptance, just as mere receipt and execution of the Program does
|
||
not require acceptance. Such ancillary propagation is permitted without
|
||
limitation or further obligation.
|
||
|
||
% FIXME-LATER: Would be nice to explain much more about interactions between
|
||
% the various options of GPLv3~\S6(a-e), which might all be in play at once!
|
||
|
||
\subsection{User Products, Installation Information and Device Lock-Down}
|
||
|
||
As discussed in \S~\ref{GPLv3-drm} of this tutorial, GPLv3 seeks to thwart
|
||
technical measures such as signature checks in hardware to prevent
|
||
modification of GPL'd software on a device.
|
||
|
||
To address this issue, GPLv3~\S6 requires that parties distributing object
|
||
code provide recipients with the source code through certain means. When
|
||
those distributors pass on the CCS, they are also required to pass on any
|
||
information or data necessary to install modified software on the particular
|
||
device that included it. (This strategy is not unlike that used in LGPLv2.1
|
||
to enable users to link proprietary programs to modified libraries.)
|
||
|
||
% FIXME-LATER: LGPLv2.1 section should talk about this explicitly and this
|
||
% should be a forward reference here
|
||
|
||
\subsubsection{User Products}
|
||
|
||
\label{user-product}
|
||
|
||
The scope of these requirements is narrow. GPLv3~\S6 introduces the concept
|
||
of a ``User Product'', which includes devices that are sold for personal,
|
||
family, or household use. Distributors are only required to provide
|
||
Installation Information when they convey object code in a User Product.
|
||
|
||
In brief, the right to convey object code in a defined class of ``User
|
||
Products,'' under certain circumstances, depends on providing whatever information
|
||
is required to enable a recipient to replace the object code with a functioning
|
||
modified version.
|
||
|
||
This was a compromise that was difficult for the FSF to agree to during the
|
||
GPLv3 drafting process. However, companies and governments that use
|
||
specialized or enterprise-level computer facilities reported that they
|
||
actually \textit{want} their systems not to be under their own control.
|
||
Rather than agreeing to this as a concession, or bowing to pressure, they ask
|
||
for this as a \textit{preference}. It is not clear that the GPL should interfere
|
||
here, since the main problem lies elsewhere.
|
||
|
||
While imposing technical barriers to modification is wrong regardless of
|
||
circumstances, the areas where restricted devices are of the greatest
|
||
practical concern today fall within the User Product definition. Most, if
|
||
not all, technically-restricted devices running GPL-covered programs are
|
||
consumer electronics devices. Moreover, the disparity in clout between the
|
||
manufacturers and these users makes it difficult for the users to reject
|
||
technical restrictions through their weak and unorganized market power. Even
|
||
limited to User Products, this provision addresses the fundamental problem.
|
||
|
||
% FIXME-LATER: link \href to USC 2301
|
||
|
||
The core of the User Product definition is a subdefinition of ``consumer
|
||
product'' adapted from the Magnuson-Moss Warranty Act, a federal
|
||
consumer protection law in the USA found in 15~USC~\S2301: ``any tangible
|
||
personal property which is normally used for personal, family, or household
|
||
purposes.'' The USA has had three decades of experience of liberal
|
||
judicial and administrative interpretation of this definition in a manner
|
||
favorable to consumer rights.\footnote{The Magnuson-Moss consumer product
|
||
definition itself has been influential in the USA and Canada, having been
|
||
adopted in several state and provincial consumer protection laws.}
|
||
Ideally, this body of interpretation\footnote{The FSF, however, was very
|
||
clear that incorporation of such legal interpretation was in no way
|
||
intended to work as a general choice of USA law for GPLv3.} will guide
|
||
interpretation of the consumer product subdefinition in GPLv3~\S6, and this
|
||
will hopefully provide a degree of legal certainty advantageous to device
|
||
manufacturers and downstream licensees alike.
|
||
|
||
One well-established interpretive principle under Magnuson-Moss is that
|
||
ambiguities are resolved in favor of coverage. That is, in cases where
|
||
it is not clear whether a product falls under the definition of consumer
|
||
product, the product will be treated as a consumer product.\footnote{16
|
||
CFR~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54
|
||
UCC~Rep.~Serv.2d 934 (D.~Ore.~2004).} Moreover, for a given product,
|
||
``normally used'' is understood to refer to the typical use of that type
|
||
of product, rather than a particular use by a particular buyer.
|
||
Products that are commonly used for personal as well as commercial
|
||
purposes are consumer products, even if the person invoking rights is a
|
||
commercial entity intending to use the product for commercial
|
||
purposes.\footnote{16 CFR \S \ 700.1(a). Numerous court decisions
|
||
interpreting Magnuson-Moss are in accord; see, e.g., \textit{Stroebner
|
||
Motors, Inc.~v.~Automobili Lamborghini S.p.A.}, 459 F.~Supp.2d 1028,
|
||
1033 (D.~Hawaii 2006).} Even a small amount of ``normal'' personal use
|
||
is enough to cause an entire product line to be treated as a consumer
|
||
product under Magnuson-Moss\footnote{\textit{Tandy Corp.~v.~Marymac
|
||
Industries, Inc.}, 213 U.S.P.Q.~702 (S.D.~Tex.~1981). In this case, the
|
||
court concluded that TRS-80 microcomputers were consumer products, where
|
||
such computers were designed and advertised for a variety of users,
|
||
including small businesses and schools, and had only recently been
|
||
promoted for use in the home.}.
|
||
|
||
However, Magnuson-Moss is not a perfect fit because in the area of components
|
||
of dwellings, the settled interpretation under Magnuson-Moss is under-inclusive.
|
||
Depending on how such components are manufactured or sold, they may or may
|
||
not be considered Magnuson-Moss consumer products.\footnote{Building
|
||
materials that are purchased directly by a consumer from a retailer, for
|
||
improving or modifying an existing dwelling, are consumer products under
|
||
Magnuson-Moss, but building materials that are integral component parts of
|
||
the structure of a dwelling at the time that the consumer buys the dwelling
|
||
are not consumer products. 16 C.F.R.~\S\S~700.1(c)--(f); Federal Trade
|
||
Commission, Final Action Concerning Review of Interpretations of
|
||
Magnuson-Moss Warranty Act, 64 Fed.~Reg.~19,700 (April 22, 1999); see also,
|
||
e.g., \textit{McFadden}, 54 U.C.C.~Rep.~Serv.2d at 934.} Therefore, GPLv3
|
||
defines User Products as a superset of consumer products that also includes
|
||
``anything designed or sold for incorporation into a dwelling.''
|
||
|
||
Thus, the three sentences in the center of GPLv3's User Product definition
|
||
encapsulate the judicial and administrative principles established over the
|
||
past three decades in the USA concerning the Magnuson-Moss consumer product
|
||
definition. First, it states that doubtful cases are resolved in favor of
|
||
coverage under the definition. Second, it indicate that the words ``normally
|
||
used'' in the consumer product definition refer to a typical or common use of
|
||
a class of product, and not the status of a particular user or expected or
|
||
actual uses by a particular user. Third, it clearly states that the
|
||
existence of substantial non-consumer uses of a product does not negate a
|
||
determination that it is a consumer product, unless such non-consumer uses
|
||
represent the only significant mode of use of that product.
|
||
|
||
It should be clear from these added sentences that it is the general mode of
|
||
use of a product that determines objectively whether or not it is a consumer
|
||
product. One could not escape the effects of the User Products provisions by
|
||
labeling what is demonstrably a consumer product in ways that suggest it is
|
||
``for professionals'', for example.
|
||
|
||
|
||
\subsubsection{Installation Information}
|
||
|
||
\label{GPLv3-installation-information}
|
||
|
||
With the User Products definition complete, The ``Installation Information''
|
||
definition uses that to define what those receiving object code inside a User
|
||
Product must receive.
|
||
|
||
Installation Information is information that is ``required to install and
|
||
execute modified versions of a covered work \dots from a modified version of
|
||
its'' CCS, in the same User Product for which the covered work is conveyed.
|
||
GPLv3 provides guidance concerning how much information must be provided: it
|
||
``must suffice to ensure that the continued functioning of the modified
|
||
object code is in no case prevented or interfered with solely because
|
||
modification has been made.'' For example, the information provided would be
|
||
insufficient if it enabled a modified version to run only in a disabled
|
||
fashion, solely because of the fact of modification (regardless of the actual
|
||
nature of the modification). The information need not consist of
|
||
cryptographic keys; Installation Information may be ``any methods,
|
||
procedures, authorization keys, or other information''.
|
||
|
||
Note that GPLv3 does not define ``continued functioning'' further. However,
|
||
GPLv3 does provide some additional guidance concerning the scope of
|
||
GPLv3-compliant action or inaction that distributors of
|
||
technically-restricted User Products can take with respect to a downstream
|
||
recipient who replaces the conveyed object code with a modified version.
|
||
First of all, GPLv3 makes clear that GPLv3 implies no obligation ``to
|
||
continue to provide support service, warranty, or updates'' for such a work.
|
||
|
||
Second, most technically-restricted User Products are designed to communicate
|
||
across networks. It is important for both users and network providers to
|
||
know when denial of network access to devices running modified versions
|
||
becomes a GPL violation. GPLv3 permits denial of access in two cases: ``when
|
||
the modification itself materially and adversely affects the operation of the
|
||
network,'' and when the modification itself ``violates the rules and
|
||
protocols for communication across the network''. The second case is
|
||
deliberately drawn in general terms, and it serves as a foundation for
|
||
reasonable enforcement policies that respect recipients' right to modify
|
||
while recognizing the legitimate interests of network providers.
|
||
|
||
Note that GPLv3 permits the practice of conveying object code in a mode not
|
||
practically susceptible to modification by any party, such as code burned in
|
||
ROM or embedded in silicon. The goal of the Installation Information
|
||
requirement is to ensure the downstream licensee receives the real right to
|
||
modify when the device manufacturer or some other party retains that right.
|
||
Accordingly, GPLv3\S6's ante-penultimate paragraph states that the
|
||
requirement to provide Installation Information ``does not apply if neither
|
||
you nor any third party retains the ability to install modified object code
|
||
on the User Product''.
|
||
|
||
Finally, GPLv3\S6 makes it clear that there is also no requirement to
|
||
provide warranty or support for the User Product itself.
|
||
|
||
\subsection{GPLv3~\S7: Additional Permissions}
|
||
\label{GPLv3s7}
|
||
|
||
The GPL is a statement of permissions, some of which have conditions.
|
||
Additional terms --- terms that supplement those of the GPL --- may come to be
|
||
placed on, or removed from, GPL-covered code in certain common ways.
|
||
Copyleft licensing theorists have generally called
|
||
those added terms ``additional permissions'' if they grant
|
||
exceptions from the conditions of the GPL, and ``additional requirements'' if
|
||
they add conditions to the basic permissions of the GPL\@. The treatment of
|
||
additional permissions and additional requirements under GPLv3 is necessarily
|
||
asymmetrical, because they do not raise the same interpretive
|
||
issues; in particular, additional requirements, if allowed without careful
|
||
limitation, could transform a GPL'd program into a non-free one.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
While GPLv2 does not allow for any additional restrictive terms, GPLv3 allows
|
||
for some specific limited variations, thus varying the strict copyleft of
|
||
GPLv2 in the interest of broader compatibility with other licenses.
|
||
% FIXME-URGENT: end
|
||
|
||
With these principles in the background, GPLv3~\S7 answers the following
|
||
questions:
|
||
\begin{enumerate}
|
||
\item How does the presence of additional terms on all or part of a GPL'd program
|
||
affect users' rights?
|
||
|
||
\item When and how may a licensee add terms to code being
|
||
distributed under the GPL?
|
||
|
||
\item When may a licensee remove additional terms?
|
||
\end{enumerate}
|
||
|
||
Additional permissions present the easier case. Since the mid-1990s,
|
||
permissive exceptions often appeared alongside GPLv2 to allow combination
|
||
with certain non-free code. Typically, downstream
|
||
stream recipients could remove those exceptions and operate under pure GPLv2.
|
||
Similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,
|
||
and it permits relicensing under the GPL\@.
|
||
|
||
These practices are now generalized via GPLv3~\S7.
|
||
A licensee may remove any additional permission from
|
||
a covered work, whether it was placed by the original author or by an
|
||
upstream distributor. A licensee may also add any kind of additional
|
||
permission to any part of a work for which the licensee has, or can give,
|
||
appropriate copyright permission. For example, if the licensee has written
|
||
that part, the licensee is the copyright holder for that part and can
|
||
therefore give additional permissions that are applicable to it.
|
||
Alternatively, the part may have been written by someone else and licensed,
|
||
with the additional permissions, to that licensee. Any additional
|
||
permissions on that part are, in turn, removable by downstream recipients.
|
||
As GPLv3~\S7\P1 explains, the effect of an additional permission depends on
|
||
whether the permission applies to the whole work or a part.
|
||
|
||
% FIXME-LATER: LGPLv3 will have its own section
|
||
|
||
Indeed, LGPLv3 is itself simply a list of additional permissions supplementing the
|
||
terms of GPLv3. GPLv3\S7 has thus provided the basis for recasting a
|
||
formally complex license as an elegant set of added terms, without changing
|
||
any of the fundamental features of the existing LGPL\@. LGPLv3 is thus a model for developers wishing to license their works under the
|
||
GPL with permissive exceptions. The removability of additional permissions
|
||
under GPLv3\S7 does not alter any existing behavior of the LGPL since the LGPL
|
||
has always allowed relicensing under the ordinary GPL\@.
|
||
|
||
\section{GPLv3~\S7: Understanding License Compatibility}
|
||
\label{license-compatibility}
|
||
|
||
A challenge that faced the Free Software community heavily through out the
|
||
early 2000s was the proliferation of incompatible Free Software licenses. Of
|
||
course, the GPL cannot possibly be compatible with all such licenses.
|
||
However, GPLv3
|
||
contains provisions that are designed to reduce license incompatibility by
|
||
making it easier for developers to combine code carrying non-GPL terms with
|
||
GPL'd code.
|
||
|
||
This license compatibility issue arises for
|
||
three reasons. First, the GPL is a strong copyleft license, requiring
|
||
modified versions to be distributed under the GPL\@. Second, the GPL states
|
||
that no further restrictions may be placed on the rights of recipients.
|
||
Third, all other software freedom respecting licenses in common use contain certain
|
||
requirements, many of which are not conditions made by the GPL\@. Thus, when
|
||
GPL'd code is modified by combination with code covered by another formal
|
||
license that specifies other requirements, and that modified code is then
|
||
distributed to others, the freedom of recipients may be burdened by
|
||
additional requirements in violation of the GPL. It can be seen that
|
||
additional permissions in other licenses do not raise any problems of license
|
||
compatibility.
|
||
|
||
GPLv3 took a new approach to the issue of combining GPL'd code with
|
||
code governed by the terms of other software freedom licenses. Traditional
|
||
GPLv2 license compatibility theory (which was not explicitly stated in GPLv2
|
||
itself, but treated as a license interpretation matter by the FSF) held that GPLv2 allowed such
|
||
combinations only if the non-GPL licensing terms permitted distribution under
|
||
the GPL and imposed no restrictions on the code that were not also imposed by
|
||
the GPL\@. In practice, the FSF historically supplemented that policy with a structure of
|
||
exceptions for certain kinds of combinations.
|
||
|
||
GPLv3~\S7 implements a more explicit policy on license
|
||
compatibility. It formalizes the circumstances under which a licensee may
|
||
release a covered work that includes an added part carrying non-GPL terms.
|
||
GPLv3~\S7 distinguish between terms that provide additional permissions, and terms that
|
||
place additional requirements on the code, relative to the permissions and
|
||
requirements established by applying the GPL to the code.
|
||
|
||
As discussed in the previous section of this tutorial, GPLv3~\S7 first and foremost explicitly allows added parts covered by terms with
|
||
additional permissions to be combined with GPL'd code. This codifies the
|
||
existing practice of regarding such licensing terms as compatible with the
|
||
GPL\@. A downstream user of a combined GPL'd work who modifies such an added
|
||
part may remove the additional permissions, in which case the broader
|
||
permissions no longer apply to the modified version, and only the terms of
|
||
the GPL apply to it.
|
||
|
||
In its treatment of terms that impose additional requirements, GPLv3\S7
|
||
extends the range of licensing terms with which the GPL is compatible. An
|
||
added part carrying additional requirements may be combined with GPL'd code,
|
||
but only if those requirements belong to an set enumerated in GPLv3\S7. There
|
||
are, of course, limits on the acceptable additional requirements, which
|
||
ensures that enhanced license compatibility does not
|
||
defeat the broader software-freedom-defending terms of the GPL\@. Unlike terms that grant
|
||
additional permissions, terms that impose additional requirements cannot be
|
||
removed by a downstream user of the combined GPL'd work, because only in the
|
||
pathological case\footnote{Theoretically, a user could collect copyright
|
||
assignment from all known contributors and then do this, but this would
|
||
indeed be the pathological case.} would a user have the right to do so.
|
||
|
||
% FIXME-LATER: It would be good to have detailed info on each of 7a-f.
|
||
% Here's some commented-out text that might be useful for 7a-b
|
||
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
Section 7(a) – Disclaimer of warranty: Copyright holders can disclaim
|
||
warranty or limit liability differently from the terms as provided under \S\S15
|
||
& 16. Internationalization of GPL required the drafters to permit the
|
||
variation in such terms necessary to deal with the absence of any
|
||
international harmonization of the laws of warranty and disclaimer.
|
||
|
||
Section 7(b) – Preservation of appropriate legal notices. Section 7 permits
|
||
additional terms requiring preservation of legal notices, including on output
|
||
from execution of covered works.
|
||
|
||
Section 7(c) – This provision allows for prohibition of misrepresentation of
|
||
original material and makes GPLv3 compatible with permissive licenses that
|
||
require modified versions be marked in ``reasonable''ways which are different
|
||
from the precise marking requirements of GPL itself.
|
||
|
||
Section 7(d) – Limiting the use of names of licensor for publicity
|
||
purposes. This provision was added to provide compatibility with licenses
|
||
which prohibit the use of the licensor’s name on unmodified versions and
|
||
other prohibitions on advertising rights. The long-standing and occasionally
|
||
troublesome incompatibility with the ``BSD advertising clause'' is an example
|
||
of the friction removed by this provision.
|
||
|
||
Section 7(e) – No grant of rights under Trademark Law. This provision serves
|
||
a similar function with respect to ``no trademark grant'' clauses in permissive
|
||
licenses.
|
||
|
||
Section 7(f) – allows for requiring of Indemnification of authors and
|
||
licensors, removing one of two primary sources of incompatibility with the
|
||
Apache Software License version 2.0.
|
||
% FIXME-URGENT: end
|
||
|
||
%% Under subsections 7a and 7b, the requirements may include preservation of
|
||
%% copyright notices, information about the origins of the code or alterations
|
||
%% of the code, and different warranty disclaimers. Under subsection 7c, the
|
||
%% requirements may include limitations on the use of names of contributors and
|
||
%% on the use of trademarks for publicity purposes. In general, we permit these
|
||
%% requirements in added terms because many free software licenses include them
|
||
%% and we consider them to be unobjectionable. Because we support trademark fair
|
||
%% use, the limitations on the use of trademarks may seek to enforce only what
|
||
%% is required by trademark law, and may not prohibit what would constitute fair
|
||
%% use.
|
||
|
||
% FIXME-LATER: Say removing additional restrictions
|
||
|
||
% FIXME-LATER: This text may be useful later:
|
||
|
||
%% Some have questioned whether section 7 is needed, and some have suggested
|
||
%% that it creates complexity that did not previously exist. We point out to
|
||
%% those readers that there is already GPLv2-licensed code that carries
|
||
%% additional terms. One of the objectives of section 7 is to rationalize
|
||
%% existing practices of program authors and modifiers by setting clear
|
||
%% guidelines regarding the removal and addition of such terms. With its
|
||
%% carefully limited list of allowed additional requirements, section 7
|
||
%% accomplishes additional objectives, permitting the expansion of the base of
|
||
%% code available for GPL developers, while also encouraging useful
|
||
%% experimentation with requirements we do not include in the GPL itself.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
Any other non-permissive additional terms apart from those stated above are
|
||
considered ``further'' restrictions and are prohibited by \S10. If you add any
|
||
kind of additional terms in accordance with \S7, you must ensure that the
|
||
terms are placed in the relevant source files or provide a conspicuous notice
|
||
about where to find the additional terms.
|
||
% FIXME-URGENT: end
|
||
|
||
\section{GPLv3~\S8: A Lighter Termination}
|
||
|
||
GPLv2 provided for automatic termination of the rights of a person who
|
||
copied, modified, sublicensed, or distributed a work in violation of the
|
||
license. Automatic termination can be too harsh for those who have committed
|
||
an inadvertent violation, particularly in cases involving distribution of
|
||
large collections of software having numerous copyright holders. A violator
|
||
who resumes compliance with GPLv2 technically needs to obtain forgiveness
|
||
from all copyright holders, and even contacting them all might be impossible.
|
||
|
||
GPLv3~\S8 now grants opportunities for provisional and permanent
|
||
reinstatement of rights. The termination procedure provides a limited
|
||
opportunity to cure license violations. If a licensee has committed a
|
||
first-time violation of the GPL with respect to a given copyright holder, but
|
||
the licensee cures the violation within 30 days following receipt of notice
|
||
of the violation, then any of the licensee's GPL rights that have been
|
||
terminated by the copyright holder are ``automatically reinstated''.
|
||
|
||
|
||
Finally, if a licensee violates the GPL, a contributor may terminate any
|
||
patent licenses that it granted under GPLv3~\S11, in addition to any
|
||
copyright permissions the contributor granted to the licensee.
|
||
|
||
% FIXME-LATER: write more here, perhaps linking up to enforcement
|
||
|
||
\section{GPLv3~\S9: Acceptance}
|
||
|
||
GPLv3~\S9 means what it says: mere receipt or execution of code neither
|
||
requires nor signifies contractual acceptance under the GPL. Speaking more
|
||
broadly, GPLv3 is intentionally structured as a unilateral grant
|
||
of copyright permissions, the basic operation of which exists outside of any
|
||
law of contract. Whether and when a contractual relationship is formed
|
||
between licensor and licensee under local law do not necessarily matter to
|
||
the working of the license.
|
||
|
||
\section{GPLv3~\S10: Explicit Downstream License}
|
||
\label{GPLv3s10}
|
||
|
||
% FIXME-LATER: this is a punt: need more time to write!
|
||
|
||
GPLv3~\S10 ensures that everyone downstream receives licenses from all
|
||
copyright holders. It really is a generally straightforward section.
|
||
|
||
% FIXME-URGENT:
|
||
|
||
Each time you redistribute a GPL’d program, the recipient automatically
|
||
receives a license, under the terms of the GPL involved, from every upstream
|
||
licensor whose copyrighted material is present in the work you
|
||
redistribute. You can think of this as creating a three-dimensional rather
|
||
than linear flow of license rights. Every recipient of the work is ``in
|
||
privity,'' or is directly receiving a license from every licensor.
|
||
|
||
This mechanism of automatic downstream licensing is central to the working of
|
||
copyleft. Every licensor independently grants licenses, and every licensor
|
||
independently terminates the license on violation.
|
||
|
||
Parties further downstream from
|
||
the infringing party remain licensed, so long as they don’t themselves commit
|
||
infringing actions. Their licenses come directly from all the upstream
|
||
holders, and are not dependent on the license of the breaching party who
|
||
distributed to them. For the same reason, an infringer who acquires another
|
||
copy of the program has not thereby acquired any new license rights: once any
|
||
upstream licensor of that program has terminated the license for breach of
|
||
its terms, no new automatic license will issue to the recipient just by
|
||
acquiring another copy.
|
||
% FIXME-URGENT: end
|
||
|
||
% FIXME-LATER: link up this paragraph to above sections.
|
||
|
||
Note, however, GPLv3 removed the words ``at no charge'' from GPLv2~\S2(b) (in
|
||
GPLv3,~\S5(b)) because it contributed to a misconception that the GPL did not
|
||
permit charging for distribution of copies. The purpose of the ``at no
|
||
charge'' wording was to prevent attempts to collect royalties from third
|
||
parties. The removal of these words created the danger that the imposition
|
||
of licensing fees would no longer be seen as a license violation. Therefore,
|
||
GPLv3~\S10 adds a new explicit prohibition on imposition of licensing fees or
|
||
royalties. This section is an appropriate place for such a clause, since it
|
||
is a specific consequence of the general requirement that no further
|
||
restrictions be imposed on downstream recipients of GPL-covered code.
|
||
|
||
% FIXME-LATER: This text needs further study before I can conclude it belongs
|
||
% in this tutorial:
|
||
|
||
%% Careful readers of the GPL have suggested that its explicit prohibition
|
||
%% against imposition of further restrictions\footnote{GPLv2, section 6; Draft
|
||
%% 3, section 10, third paragraph.} has, or ought to have, implications for
|
||
%% those who assert patents against other licensees. Draft 2 took some steps to
|
||
%% clarify this point in a manner not specific to patents, by describing the
|
||
%% imposition of ``a license fee, royalty, or other charge'' for exercising GPL
|
||
%% rights as one example of an impermissible further restriction. In Draft 3 we
|
||
%% have clarified further that the requirement of non-imposition of further
|
||
%% restrictions has specific consequences for litigation accusing GPL-covered
|
||
%% programs of infringement. Section 10 now states that ``you may not initiate
|
||
%% litigation (including a cross-claim or counterclaim in a lawsuit) alleging
|
||
%% that any patent claim is infringed by making, using, selling, offering for
|
||
%% sale, or importing the Program (or the contribution of any contributor).''
|
||
%% That is to say, a patent holder's licensed permissions to use a work under
|
||
%% GPLv3 may be terminated under section 8 if the patent holder files a lawsuit
|
||
%% alleging that use of the work, or of any upstream GPLv3-licensed work on
|
||
%% which the work is based, infringes a patent.
|
||
|
||
\section{GPLv3~\S11: Explicit Patent Licensing}
|
||
\label{GPLv3s11}
|
||
|
||
Software patenting is a harmful and unjust policy, and should be abolished;
|
||
recent experience makes this all the more evident. Since many countries grant
|
||
patents that can apply to and prohibit software packages, in various guises
|
||
and to varying degrees, GPLv3 seeks to protect the users of GPL-covered programs
|
||
from those patents, while at the same time making it feasible for patent
|
||
holders to contribute to and distribute GPL-covered programs as long as they
|
||
do not attack the users of those programs.
|
||
|
||
It is generally understood that GPLv2 implies some limits on a licensee's
|
||
power to assert patent claims against the use of GPL-covered works.
|
||
However, the patent licensing practices that GPLv2~\S7 (corresponding to
|
||
GPLv3~\S12) is designed to prevent is only one of several ways in which
|
||
software patents threaten to make free programs non-free and to prevent users
|
||
from exercising their rights under the GPL. GPLv3 takes a more comprehensive
|
||
approach to combating the danger of patents.
|
||
|
||
GPLv2~\S7 has seen some success in deterring conduct that would otherwise
|
||
result in denial of full downstream enjoyment of GPL rights, and thus it is
|
||
preserved in GPLv3~\S12. Experience has shown that more is necessary,
|
||
however, to ensure adequate community safety where companies act in concert
|
||
to heighten the anticompetitive use of patents that they hold or license.
|
||
|
||
Therefore, GPLv3 is designed to reduce the patent risks that distort and
|
||
threaten the activities of users who make, run, modify and share Free
|
||
Software. At the same time, GPLv3 gives favorable consideration to practical
|
||
goals such as certainty and administrability for patent holders that
|
||
participate in distribution and development of GPL-covered software. GPLv3's
|
||
policy requires each such patent holder to provide appropriate levels of
|
||
patent assurance to users, according to the nature of the patent holder's
|
||
relationship to the program.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
GPLv3 provides for two classes of patent commitments:
|
||
|
||
Prohibition of Enforcement of patent claims against those to whom you
|
||
distribute: GPLv3 \S10 makes explicit that demands for acceptance of
|
||
patent licenses or payment of patent royalties by those to whom a
|
||
licensee directly distributes are additional conditions that may not
|
||
imposed. This provision establishes a uniform rule of patent exhaustion
|
||
with respect to GPL’d programs regardless of the domestic patent law in
|
||
any particular system or locale.
|
||
|
||
Grant of license to claims in contributor versions: Section 11 introduces
|
||
an affirmative grant of rights to patent claims by those who contribute
|
||
code to GPL’d programs. The intent is to prevent parties within the
|
||
commons from aggressively asserting patents against users of code they
|
||
have themselves modified, preventing a form of commons betrayal by
|
||
``insiders'' to the community. A contributor’s patent claims necessarily
|
||
infringed by the version of the program created by the incorporation of
|
||
its modifications are licensed to all subsequent users and modifiers of
|
||
the program, or programs based on the program. No patent claims only
|
||
infringed by subsequent modifications by other parties are thus
|
||
licensed. Patent claims acquired after the making of the ``contributor
|
||
version'' necessarily infringed by that version are also licensed by this
|
||
provision at the time of their acquisition or perfection. When a company
|
||
with a large number of such claims acquires the program’s modifier, all
|
||
claims held or thereafter acquired by the purchaser are automatically
|
||
licensed under this provision. The acquisition of Nokia by Microsoft, for
|
||
example, resulted in the automatic licensing of all Microsoft claims now
|
||
or hereafter acquired which read on any contributor version of any GPLv3
|
||
program ever modified by Nokia. The wholesale decimation of Microsoft
|
||
patent claims on GPLv3 programs arising from the purchase of Nokia has so
|
||
far been unremarked in the industry.
|
||
% FIXME-URGENT: end
|
||
|
||
\subsection{The Contributor's Explicit Patent License}
|
||
|
||
Specifically, the ideal might have been for GPLv3 to feature a patent license
|
||
grant triggered by all acts of distribution of GPLv3-covered works. The FSF
|
||
considered it during the GPLv3 drafting process, but many patent-holding
|
||
companies objected to this policy. They have made two objections: (1) the
|
||
far-reaching impact of the patent license grant on the patent holder is
|
||
disproportionate to the act of merely distributing code without modification
|
||
or transformation, and (2) it is unreasonable to expect an owner of vast
|
||
patent assets to exercise requisite diligence in reviewing all the
|
||
GPL-covered software that it provides to others. Some expressed particular
|
||
concern about the consequences of ``inadvertent'' distribution.
|
||
|
||
The argument that the impact of the patent license grant would be
|
||
``disproportionate'', that is to say unfair, is not valid. Since
|
||
software patents are weapons that no one should have, and using them for
|
||
aggression against free software developers is an egregious act (thus
|
||
preventing that act cannot be unfair).
|
||
|
||
However, the second argument seems valid in a practical sense. A
|
||
typical GNU/Linux distribution includes thousands of programs. It would
|
||
be quite difficult for a re-distributor with a large patent portfolio to
|
||
review all those programs against that portfolio every time it receives
|
||
and passes on a new version of the distribution. Moreover, this question
|
||
raises a strategic issue. If the GPLv3 patent license requirements
|
||
convince patent-holding companies to remain outside the distribution
|
||
path of all GPL-covered software, then these requirements, no matter how
|
||
strong, will cover few patents.
|
||
|
||
GPLv3 therefore makes a partial concession
|
||
which would lead these companies to feel secure in doing the
|
||
distribution themselves. GPLv3~\S11
|
||
applies only to those distributors that have
|
||
modified the program. The other changes we have made in sections 10 and
|
||
11 provide strengthened defenses against patent assertion and compensate
|
||
partly for this concession.
|
||
|
||
Therefore, GPLv3~\S11 introduces the terms ``contributor'', ``contributor version'', and
|
||
``essential patent claims'', which are
|
||
used in the GPLv3~\S11\P3. Viewed from the perspective of a recipient of the
|
||
Program, contributors include all the copyright holders for the Program,
|
||
other than copyright holders of material originally licensed under non-GPL
|
||
terms and later incorporated into a GPL-covered work. The contributors are
|
||
therefore the initial GPLv3 licensors of the Program and all subsequent
|
||
upstream licensors who convey, under the terms of GPLv3~\S5, modified covered
|
||
works.
|
||
Thus, the ``contributor version'' includes the material the contributor has copied from the
|
||
upstream version that the contributor has modified. GPLv3~\S11\P3
|
||
does not apply to those that redistribute the program
|
||
without change.\footnote{An implied patent license from the distributor,
|
||
however, often arises. See \S~\ref{gpl-implied-patent-grant} in this tutorial}
|
||
In other words, the ``contributor version'' includes not just
|
||
the material added or altered by the contributor, but also the pre-existing
|
||
material the contributor copied from the upstream version and retained in the
|
||
modified version. (GPLv3's usage of ``contributor'' and ``contribution'' should
|
||
not be confused with the various other ways in which those terms are used in
|
||
certain other free software licenses\footnote{Cf., e.g., Apache License,
|
||
version 2.0, section 1; Eclipse Public License, version 1.0, section 1;
|
||
Mozilla Public License, version 1.1, section 1.1.}.)
|
||
|
||
Some details of the ``essential patent claims'' definition deserve special
|
||
mention. ``Essential patent claims'', for a given party, are a subset of the
|
||
claims ``owned or controlled'' by the party. They do include sublicensable
|
||
claims that have been licensed to the contributor by a third
|
||
party.\footnote{This issue is typically handled in other software freedom
|
||
licenses having patent licensing provisions by use of the unhelpful term
|
||
``licensable,'' which is either left undefined or is given an ambiguous
|
||
definition.} Most commercial patent license agreements that permit
|
||
sublicensing do so under restrictive terms that are inconsistent with the
|
||
requirements of the GPL\@. For example, some patent licenses allow the
|
||
patent licensee to sublicense but require collection of royalties from any
|
||
sublicensees. The patent licensee could not distribute a GPL-covered program
|
||
and grant the recipient a patent sublicense for the program without violating
|
||
section 12 of GPLv3.\footnote{GPLv3 also provides an example in section 12
|
||
that makes this point clear.} In rare cases, however, a conveying party
|
||
can freely grant patent sublicenses to downstream recipients without
|
||
violating the GPL\@.
|
||
|
||
Additionally, ``essential patent claims'' are those patents ``that would be
|
||
infringed by some manner, permitted by this License, of making, using, or
|
||
selling the work''. This intends to make clear that a patent claim is
|
||
``essential'' if some mode of usage would infringe that claim, even if there
|
||
are other modes of usage that would not infringe.
|
||
|
||
Finally, ``essential patent claims \ldots do not include
|
||
claims that would be infringed only as a consequence of further
|
||
modification of the work.'' The set of essential patent
|
||
claims licensed is fixed by the
|
||
particular version of the work that was contributed. The claim set
|
||
cannot expand as a work is further modified downstream. (If it could,
|
||
then any software patent claim would be included, since any software
|
||
patent claim can be infringed by some further modification of the
|
||
work.)\footnote{However, ``the work'' should not be understood to be
|
||
restricted to a particular mechanical affixation of, or medium for
|
||
distributing, a program, where the same program might be provided in
|
||
other forms or in other ways that may be captured by other patent claims
|
||
held by the contributor.}
|
||
|
||
\medskip
|
||
|
||
Ideally, this contributor patent policy will result in fairly frequent licensing of patent
|
||
claims by contributors. A contributor is charged with awareness of the fact
|
||
that it has modified a work and provided it to others; no act of contribution
|
||
should be treated as inadvertent. GPLv3's rule also requires no more work, for a
|
||
contributor, than the weaker rule proposed by the patent holders. Under
|
||
their rule, the contributor must always compare the entire work against its
|
||
patent portfolio to determine whether the combination of the modifications
|
||
with the remainder of the work cause it to read on any of the contributor's
|
||
patent claims.
|
||
|
||
\subsection{Conveyors' Patent Licensing}
|
||
|
||
The remaining patent licensing in GPLv3 deals with patent licenses that are
|
||
granted by conveyance. The licensing is not as complete or far reaching as
|
||
the contributor patent licenses discussed in the preceding section.
|
||
|
||
The term ``patent license,'' as used in GPLv3~\S11\P4--6, is not meant to be
|
||
confined to agreements formally identified or classified as patent licenses.
|
||
GPLv3~\S11\P3 makes this clear by defining ``patent
|
||
license,'' for purposes of the subsequent three paragraphs, as ``any express
|
||
agreement or commitment, however denominated, not to enforce a patent
|
||
(such as an express permission to practice a patent or covenant not to
|
||
sue for patent infringement)''
|
||
|
||
% FIXME-LATER: I want to ask Fontana about this before adding it.
|
||
|
||
% The definition does not include patent licenses that arise by
|
||
% implication or operation of law, because the third through fifth paragraphs
|
||
% of section 11 are specifically concerned with explicit promises that purport
|
||
% to be legally enforceable.
|
||
|
||
GPLv3~\S11\P5 is commonly called GPLv3's downstream shielding provision. It
|
||
responds particularly to the problem of exclusive deals between patent
|
||
holders and distributors, which threaten to distort the free software
|
||
distribution system in a manner adverse to developers and users. The
|
||
fundamental idea is to make a trade-off between assuring a patent license for
|
||
downstream and making (possibly patent-encumbered) CCS publicly available.
|
||
|
||
Simply put, in nearly all cases in which the ``knowingly relying'' test is
|
||
met, the patent license will indeed not be sublicensable or generally
|
||
available to all on free terms. If, on the other hand, the patent license is
|
||
generally available under terms consistent with the requirements of the GPL,
|
||
the distributor is automatically in compliance, because the patent license
|
||
has already been extended to all downstream recipients. Finally, if the
|
||
patent license is sublicensable on GPL-consistent terms, the distributor may
|
||
choose to grant sublicenses to downstream recipients instead of causing the
|
||
CCS to be publicly available. (In such a case, if the distributor is also a
|
||
contributor, it will already have granted a patent sublicense anyway, and so
|
||
it need not do anything further to comply with the third paragraph.)
|
||
|
||
Admittedly, public disclosure of CCS is not necessarily required by other
|
||
sections of the GPL, and the FSF in drafting GPLv3 did not necessarily wish
|
||
to impose a general requirement to make source code available to all, which
|
||
has never been a GPL condition. However, many vendors who produce products
|
||
that include copylefted software, and who are most likely to be affected by the
|
||
downstream shielding provision, lobbied for the addition of the source code
|
||
availability option, so it remains.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
If A takes a patent license from B that benefits A only, rather than A’s
|
||
customers or their distributees, A imposes risk from B’s patents on others
|
||
that it does not suffer itself. Under many circumstances, this is an
|
||
acceptable outcome. If, however, A is the only possible source of the
|
||
program, by taking such a license and distributing in reliance on it, A is in
|
||
effect helping B to ``take the program private.''
|
||
% FIXME-URGENT: end
|
||
|
||
Meanwhile, two specific alternatives to the source code availability option
|
||
are also available. The distributor may comply by disclaiming the patent
|
||
license it has been granted for the conveyed work, or by arranging to extend
|
||
the patent license to downstream recipients\footnote{The latter option, if
|
||
chosen, must be done ``in a manner consistent with the requirements of this
|
||
License''; for example, it is unavailable if extension of the patent
|
||
license would result in a violation of GPLv3~\S 12.}. The GPL is intended
|
||
to permit private distribution as well as public distribution, and the
|
||
addition of these options ensures that this remains the case, even though it
|
||
remains likely that distributors in this situation will usually choose the
|
||
source code availability option.
|
||
|
||
Note that GPLv3~\S11\P5 is activated only if the CCS is not already otherwise
|
||
publicly available. (Most often it will, in fact, already be available on
|
||
some network server operated by a third party.) Even if it is not already
|
||
available, the option to ``cause the Corresponding Source to be so
|
||
available'' can then be satisfied by verifying that a third party has acted
|
||
to make it available. That is to say, the affected distributor need not
|
||
itself host the CCS to take advantage of the source code availability option.
|
||
This subtlety may help the distributor avoid certain peculiar assumptions of
|
||
liability.
|
||
|
||
Note that GPLv3~\S11\P6--7 are designed to stop distributors from colluding with
|
||
third parties to offer selective patent protection. GPLv3 is designed to
|
||
ensure that all users receive the same rights; arrangements that circumvent
|
||
this make a mockery of free software, and we must do everything in our power
|
||
to stop them.
|
||
|
||
First, GPLv3~\S11\P6 states that any license that protects some recipients of
|
||
GPL'd software must be extended to all recipients of the software.
|
||
If conveyors arrange to provide patent
|
||
protection to some of the people who get the software from you, that
|
||
protection is automatically extended to everyone who receives the software,
|
||
no matter how they get it.
|
||
|
||
Second, GPLv3~\S11\P7
|
||
prohibit anyone who made such an agreement from distributing software
|
||
released under GPLv3. Conveyors are prohibited from
|
||
distributing software under GPLv3 if the conveyor makes an agreement of that
|
||
nature in the future.
|
||
|
||
The date in GPLv3~\S11\P7 likely seems arbitrary to those who did not follow
|
||
the GPLv3 drafting process. This issue was hotly debated during the drafting of
|
||
GPLv3, but ultimately one specific deal of this type --- a deal between Microsoft
|
||
and Novell for Microsoft to provide so-called ``coupons'' to Microsoft customers to redeem
|
||
for copies of Novell's GNU/Linux distribution with a Microsoft patent license -- was
|
||
designed to be excluded.
|
||
|
||
The main reason for this was a tactical decision by the FSF. FSF believed they can do more to
|
||
protect the community by allowing Novell to use software under GPLv3
|
||
than by forbidding it to do so. This is because of
|
||
paragraph 6 of section 11 (corresponding to paragraph 4 in Draft 3).
|
||
It will apply, under the Microsoft/Novell deal, because of the coupons
|
||
that Microsoft has acquired that essentially commit it to participate
|
||
in the distribution of the Novell SLES GNU/Linux system.
|
||
|
||
The FSF also gave a secondary reason: to avoid affecting other kinds of agreements for
|
||
other kinds of activities. While GPLv3 sought to
|
||
distinguish pernicious deals of the Microsoft/Novell type from
|
||
business conduct that is not particularly harmful, the FSF also did not
|
||
assume success in that drafting, and thus there remained some risk that other
|
||
unchangeable past agreements could fall within the scope of GPLv3~\S11\P7.
|
||
In future deals, distributors engaging in ordinary business practices
|
||
can structure the agreements so that they do not fall under GPLv3~\S11\P7.
|
||
|
||
\section{GPLv3~\S12: Familiar as GPLv2~\S7}
|
||
|
||
GPLv2~\S12 remains almost completely unchanged from the text that appears in
|
||
GPLv2~\S7. This is an important provision that ensures a catch-all to ensure
|
||
that nothing ``surprising'' interferes with the continued conveyance safely
|
||
under copyleft.
|
||
|
||
The wording in the first sentence of GPLv3~\S12 has been revised slightly to
|
||
clarify that an agreement -- such as a litigation settlement agreement or a
|
||
patent license agreement -- is one of the ways in which conditions may be
|
||
``imposed'' on a GPL licensee that may contradict the conditions of the GPL,
|
||
but which do not excuse the licensee from compliance with those conditions.
|
||
This change codifies the historical interpretation of GPLv2.
|
||
|
||
GPLv3 removed the limited severability clause of GPLv2~\S7 as a
|
||
matter of tactical judgment, believing that this is the best way to ensure
|
||
that all provisions of the GPL will be upheld in court. GPLv3 also removed
|
||
the final sentence of GPLv2 section 7, which the FSF consider to be unnecessary.
|
||
|
||
\section{GPLv3~\S13: The Great Affero Compromise}
|
||
|
||
The Affero GPL was written with the expectation that its
|
||
additional requirement would be incorporated into the terms of GPLv3
|
||
itself. Many software freedom advocates, including some authors of this
|
||
tutorial, advocated heavily for that, and fully expected it to happen.
|
||
|
||
The FSF, however, chose not to include the Affero clause in GPLv3, due to
|
||
what it called ``irreconcilable views from
|
||
different parts of the community''. Many
|
||
commercial users of Free Software were opposed to the inclusion of a
|
||
mandatory Affero-like requirement in the body of GPLv3 itself. In fact, some
|
||
wealthier companies even threatened to permanently fund forks of many FSF
|
||
copyrighted-programs under GPLv2 if the Affero clause appeared in GPLv3.
|
||
|
||
Meanwhile, there was disagreement even among copyleft enthusiasts about the
|
||
importance of the provision. A coalition never formed, and ultimately the
|
||
more powerful interest implicitly allied with the companies who deeply opposed
|
||
the Affero clause such that the FSF felt the Affero clause would need its own
|
||
license, but one compatible with GPLv3.
|
||
|
||
GPLv3~\S13 makes GPLv3 compatible with the AGPLv3, so that at least code can
|
||
be shared between AGPLv3'd and GPLv3'd projects, even if the Affero clause
|
||
does not automatically apply to all GPLv3'd works.
|
||
|
||
%FIXME-LATER: no time to do this justice, will come back later, instead the
|
||
%above.
|
||
|
||
%% Some of this hostility seemed to be based on a misapprehension that
|
||
%% Affero-like terms placed on part of a covered work would somehow extend
|
||
%% to the whole of the work.\footnote{It is possible that the presence of
|
||
%% the GPLv2-derived copyleft clause in the existing Affero GPL contributed
|
||
%% to this misunderstanding.} Our explanations to the contrary did little
|
||
%% to satisfy these critics; their objections to 7b4 instead evolved into a
|
||
%% broader indictment of the additional requirements scheme of section 7.
|
||
%% It was clear, however, that much of the concern about 7b4 stemmed from
|
||
%% its general formulation. Many were alarmed at the prospect of GPLv3
|
||
%% compatibility for numerous Affero-like licensing conditions,
|
||
%% unpredictable in their details but potentially having significant
|
||
%% commercial consequences.
|
||
|
||
%% On the other hand, many developers, otherwise sympathetic to the policy
|
||
%% goals of the Affero GPL, have objected to the form of the additional
|
||
%% requirement in that license. These developers were generally
|
||
%% disappointed with our decision to allow Affero-like terms through
|
||
%% section 7, rather than adopt a condition for GPLv3. Echoing their
|
||
%% concerns about the Affero GPL itself, they found fault with the wording
|
||
%% of the section 7 clause in both of the earlier drafts. We drafted 7b4
|
||
%% at a higher level than its Draft 1 counterpart based in part on comments
|
||
%% from these developers. They considered the Draft 1 clause too closely
|
||
%% tied to the Affero mechanism of preserving functioning facilities for
|
||
%% downloading source, which they found too restrictive of the right of
|
||
%% modification. The 7b4 rewording did not satisfy them, however. They
|
||
%% objected to its limitation to terms requiring compliance by network
|
||
%% transmission of source, and to the technically imprecise or inaccurate
|
||
%% use of the phrase ``same network session.''
|
||
|
||
%% We have concluded that any redrafting of the 7b4 clause would fail to
|
||
%% satisfy the concerns of both sets of its critics. The first group
|
||
%% maintains that GPLv3 should do nothing about the problem of public
|
||
%% use. The second group would prefer for GPLv3 itself to have an
|
||
%% Affero-like condition, but that seems to us too drastic. By permitting
|
||
%% GPLv3-covered code to be linked with code covered by version 2 of the
|
||
%% Affero GPL, the new section 13 honors our original commitment to
|
||
%% achieving GPL compatibility for the Affero license.
|
||
|
||
%% Version 2 of the Affero GPL is not yet published. We will work with
|
||
%% Affero, Inc., and with all other interested members of our community, to
|
||
%% complete the drafting of this license following the release of Draft 3,
|
||
%% with a goal of having a final version available by the time of our
|
||
%% adoption of the final version of GPLv3. We hope the new Affero license
|
||
%% will satisfy those developers who are concerned about the issue of
|
||
%% public use of unconveyed versions but who have concerns about the
|
||
%% narrowness of the condition in the existing Affero license.
|
||
|
||
%% As the second sentence in section 13 indicates, when a combined work is
|
||
%% made by linking GPLv3-covered code with Affero-covered code, the
|
||
%% copyleft on one part will not extend to the other part.\footnote{The
|
||
%% plan is that the additional requirement of the new Affero license will
|
||
%% state a reciprocal limitation.} That is to say, in such combinations,
|
||
%% the Affero requirement will apply only to the part that was brought into
|
||
%% the combination under the Affero license. Those who receive such a
|
||
%% combination and do not wish to use code under the Affero requirement may
|
||
%% remove the Affero-covered portion of the combination.
|
||
|
||
Meanwhile, those who criticize the permission to link with code under the Affero
|
||
GPL should recognize that most other free software licenses also permit
|
||
such linking.
|
||
|
||
%FIXME-URGENT: integrate
|
||
% A section on combinations with Affero is necessary anyway here.
|
||
|
||
When a combined work is made by linking GPLv3-covered code with AGPL-covered
|
||
code, the copyleft on one part will not extend to the other part. That is to
|
||
say, in such combinations, the Affero requirement will apply only to the part
|
||
that was brought into the combination under the Affero license. Those who
|
||
receive such a combination and do not wish to use code under the Affero
|
||
requirement may remove the Affero-covered portion of the combination.
|
||
% FIXME-URGENT: end
|
||
|
||
\section{GPLv3~\S14: So, When's GPLv4?}
|
||
\label{GPLv3s14}
|
||
|
||
No substantive change has been made in section 14. The wording of the section
|
||
has been revised slightly to make it clearer.
|
||
|
||
It's unclear when the FSF might consider publishing GPLv4. However, this
|
||
section makes it clear that the FSF is the sole authority who can decide
|
||
such.
|
||
|
||
The main addition to this section allows a third-party proxy to be appointed
|
||
by contributors who wish someone else to make relicensing to new versions of
|
||
GPL when they are released. This is a ``halfway'' point between using ``-only''
|
||
or ``-or-later'' by consolidating the decision-making on that issue to a
|
||
single authority.
|
||
|
||
% FIXME-LATER: better proxy description
|
||
|
||
\section{GPLv3~\S15--17: Warranty Disclaimers and Liability Limitation}
|
||
|
||
No substantive changes have been made in sections 15 and 16.
|
||
|
||
% FIXME-LATER: more, plus 17
|
||
|
||
% FIXME-LATER: Section header needed here about choice of law.
|
||
|
||
% FIXME-LATER: reword into tutorial
|
||
|
||
%% Some have asked us to address the difficulties of internationalization
|
||
%% by including, or permitting the inclusion of, a choice of law
|
||
%% provision. We maintain that this is the wrong approach. Free
|
||
%% software licenses should not contain choice of law clauses, for both
|
||
%% legal and pragmatic reasons. Choice of law clauses are creatures of
|
||
%% contract, but the substantive rights granted by the GPL are defined
|
||
%% under applicable local copyright law. Contractual free software
|
||
%% licenses can operate only to diminish these rights. Choice of law
|
||
%% clauses also raise complex questions of interpretation when works of
|
||
%% software are created by combination and extension. There is also the
|
||
%% real danger that a choice of law clause will specify a jurisdiction
|
||
%% that is hostile to free software principles.
|
||
|
||
%% % FIXME-LATER: reword into tutorial, \ref to section 7.
|
||
|
||
%% Our revised version of section 7 makes explicit our view that the
|
||
%% inclusion of a choice of law clause by a licensee is the imposition of
|
||
%% an additional requirement in violation of the GPL. Moreover, if a
|
||
%% program author or copyright holder purports to supplement the GPL with
|
||
%% a choice of law clause, section 7 now permits any licensee to remove
|
||
%% that clause.
|
||
|
||
|
||
% FIXME-LATER: does this need to be a section, describing how it was out then in
|
||
% then out then in? :)
|
||
|
||
Finally, the FSF shortened the section on ``How to Apply These
|
||
Terms to Your New Programs'' to just the bare essentials.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{The Lesser GPL}
|
||
|
||
As we have seen in our consideration of the GPL, its text is specifically
|
||
designed to cover all possible derivative, modified and/or combined works under copyright law. Our
|
||
goal in designing the GPL was to maximize its use of the controls of
|
||
copyright law to maximize the number of works that were covered by GPL.
|
||
|
||
However, while the strategic goal of software freedom is to bring as much Free Software
|
||
into the world as possible, particular tactical considerations
|
||
regarding software freedom dictate different means. Extending the
|
||
copyleft effect as far as copyright law allows is not always the most
|
||
prudent course in reaching the goal. In particular situations, even
|
||
those of us with the goal of building a world where all published
|
||
software is Free Software realize that full copyleft does not best
|
||
serve us. The GNU Lesser General Public License (``GNU LGPL'') was
|
||
designed as a solution for such situations.
|
||
|
||
% FIXME: integrate
|
||
|
||
The Lesser General Public License is sometimes described as a ``weak copyleft''
|
||
license, because code licensed under LGPL’s terms can be combined with code
|
||
under non-free licenses, and is sometimes used in that fashion.
|
||
% FIXME-URGENT: end
|
||
\section{The First LGPL'd Program}
|
||
|
||
The first example that FSF encountered where such altered tactics were
|
||
needed was when work began on the GNU C Library. The GNU C Library would
|
||
become (and today, now is) a drop-in replacement for existing C libraries.
|
||
On a Unix-like operating system, C is the lingua franca and the C library
|
||
is an essential component for all programs. It is extremely difficult to
|
||
construct a program that will run with ease on a Unix-like operating
|
||
system without making use of services provided by the C library --- even
|
||
if the program is written in a language other than C\@. Effectively, all
|
||
user application programs that run on any modern Unix-like system must
|
||
make use of the C library.
|
||
|
||
By the time work began on the GNU implementation of the C libraries, there
|
||
were already many C libraries in existence from a variety of vendors.
|
||
Every proprietary Unix vendor had one, and many third parties produced
|
||
smaller versions for special purpose use. However, our goal was to create
|
||
a C library that would provide equivalent functionality to these other C
|
||
libraries on a Free Software operating system (which in fact happens today
|
||
on modern GNU/Linux systems, which all use the GNU C Library).
|
||
|
||
Unlike existing GNU application software, however, the licensing
|
||
implications of releasing the GNU C Library (``glibc'') under the GPL were
|
||
somewhat different. Applications released under the GPL would never
|
||
themselves become part of proprietary software. However, if glibc were
|
||
released under the GPL, it would require that any application distributed for
|
||
the GNU/Linux platform be released under the GPL\@.
|
||
|
||
Since all applications on a Unix-like system depend on the C library, it
|
||
means that they must link with that library to function on the system. In
|
||
other words, all applications running on a Unix-like system must be
|
||
combined with the C library to form a new whole work that is
|
||
composed of the original application and the C library. Thus, if glibc
|
||
were GPL'd, each and every application distributed for use on GNU/Linux
|
||
would also need to be GPL'd, since to even function, such applications
|
||
would need to be combined into larger works by linking with
|
||
glibc.
|
||
|
||
At first glance, such an outcome seems like a windfall for Free Software
|
||
advocates, since it stops all proprietary software development on
|
||
GNU/Linux systems. However, the outcome is a bit more subtle. In a world
|
||
where many C libraries already exist, many of which could easily be ported
|
||
to GNU/Linux, a GPL'd glibc would be unlikely to succeed. Proprietary
|
||
vendors would see the excellent opportunity to license their C libraries
|
||
to anyone who wished to write proprietary software for GNU/Linux systems.
|
||
The de-facto standard for the C library on GNU/Linux would likely be not
|
||
glibc, but the most popular proprietary one.
|
||
|
||
Meanwhile, the actual goal of releasing glibc under the GPL --- to ensure no
|
||
proprietary applications on GNU/Linux --- would be unattainable in this
|
||
scenario. Furthermore, users of those proprietary applications would also
|
||
be users of a proprietary C library, not the Free glibc.
|
||
|
||
The Lesser GPL was initially conceived to handle this scenario. It was
|
||
clear that the existence of proprietary applications for GNU/Linux was
|
||
inevitable. Since there were so many C libraries already in existence, a
|
||
new one under the GPL would not stop that tide. However, if the new C library
|
||
were released under a license that permitted proprietary applications
|
||
to link with it, but made sure that the library itself remained Free,
|
||
an ancillary goal could be met. Users of proprietary applications, while
|
||
they would not have the freedom to copy, share, modify and redistribute
|
||
the application itself, would have the freedom to do so with respect to
|
||
the C library.
|
||
|
||
There was no way the license of glibc could stop or even slow the creation
|
||
of proprietary applications on GNU/Linux. However, loosening the
|
||
restrictions on the licensing of glibc ensured that nearly all proprietary
|
||
applications at least used a Free C library rather than a proprietary one.
|
||
This trade-off is central to the reasoning behind the LGPL\@.
|
||
|
||
Of course, many people who use the LGPL today are not thinking in these
|
||
terms. In fact, they are often choosing the LGPL because they are looking
|
||
for a ``compromise'' between the GPL and the X11-style liberal licensing.
|
||
However, understanding FSF's reasoning behind the creation of the LGPL is
|
||
helpful when studying the license.
|
||
|
||
|
||
\section{What's the Same?}
|
||
|
||
Much of the text of the LGPL is identical to the GPL\@. As we begin our
|
||
discussion of the LGPL, we will first eliminate the sections that are
|
||
identical, or that have the minor modification changing the word
|
||
``Program'' to ``Library.''
|
||
|
||
First, LGPLv2.1~\S1, the rules for verbatim copying of source, are
|
||
equivalent to those in GPLv2~\S1.
|
||
|
||
Second, LGPLv2.1~\S8 is equivalent GPLv2~\S4\@. In both licenses, this
|
||
section handles termination in precisely the same manner.
|
||
|
||
LGPLv2.1~\S9 is equivalent to GPLv2~\S5\@. Both sections assert that
|
||
the license is a copyright license, and handle the acceptance of those
|
||
copyright terms.
|
||
|
||
LGPLv2.1~\S10 is equivalent to GPLv2~\S6. They both protect the
|
||
distribution system of Free Software under these licenses, to ensure that
|
||
up, down, and throughout the distribution chain, each recipient of the
|
||
software receives identical rights under the license and no other
|
||
restrictions are imposed.
|
||
|
||
LGPLv2.1~\S11 is GPLv2~\S7. As discussed, it is used to ensure that
|
||
other claims and legal realities, such as patent licenses and court
|
||
judgments, do not trump the rights and permissions granted by these
|
||
licenses, and requires that distribution be halted if such a trump is
|
||
known to exist.
|
||
|
||
LGPLv2.1~\S12 adds the same features as GPLv2~\S8. These sections are
|
||
used to allow original copyright holders to forbid distribution in
|
||
countries with draconian laws that would otherwise contradict these
|
||
licenses.
|
||
|
||
LGPLv2.1~\S13 sets up the FSF as the steward of the LGPL, just as GPLv2~\S9
|
||
does for GPL. Meanwhile, LGPLv2.1~\S14 reminds licensees that copyright
|
||
holders can grant exceptions to the terms of LGPL, just as GPLv2~\S10
|
||
reminds licensees of the same thing.
|
||
|
||
Finally, the assertions of no warranty and limitations of liability are
|
||
identical; thus LGPLv2.1~\S15 and LGPLv2.1~\S16 are the same as GPLv2~\S11 and \S
|
||
12.
|
||
|
||
As we see, the entire latter half of the license is identical.
|
||
The parts which set up the legal boundaries and meta-rules for the license
|
||
are the same. It is our intent that the two licenses operate under the
|
||
same legal mechanisms and are enforced precisely the same way.
|
||
|
||
We strike a difference only in the early portions of the license.
|
||
Namely, in the LGPL we go into deeper detail of granting various permissions to
|
||
create certain types of combinations, modifications and derivations.
|
||
The LGPL does not stretch the requirements as far as copyright law does regarding what
|
||
works must be relicensed under the same terms. Therefore, LGPL must
|
||
in detail explain which works can be proprietary. Thus, we'll see that the front matter of the LGPL is a
|
||
bit more wordy and detailed with regards to the permissions granted to
|
||
those who modify or redistribute the software.
|
||
|
||
\section{Additions to the Preamble}
|
||
|
||
Most of the LGPL's Preamble is identical, but the last seven paragraphs
|
||
introduce the concepts and reasoning behind creation of the license,
|
||
presenting a more generalized and briefer version of the story with which
|
||
we began our consideration of the LGPL\@.
|
||
|
||
In short, FSF designed the LGPL for those edge cases where the freedom of the
|
||
public can better be served by a more lax licensing system. FSF doesn't
|
||
encourage use of the LGPL automatically for any software that happens to be a
|
||
library; rather, FSF suggests that it only be used in specific cases, such
|
||
as the following:
|
||
|
||
\begin{itemize}
|
||
|
||
\item To encourage the widest possible use of a Free Software library, so
|
||
it becomes a de-facto standard over similar, although not
|
||
interface-identical, proprietary alternatives
|
||
|
||
\item To encourage use of a Free Software library that already has
|
||
interface-identical proprietary competitors that are more developed
|
||
|
||
\item To allow a greater number of users to get freedom, by encouraging
|
||
proprietary companies to pick a Free alternative for its otherwise
|
||
proprietary products
|
||
|
||
\end{itemize}
|
||
|
||
The LGPL's preamble sets forth the limits to which the license seeks to go in
|
||
chasing these goals. The LGPL is designed to ensure that users who happen to
|
||
acquire software linked with such libraries have full freedoms with
|
||
respect to that library. They should have the ability to upgrade to a newer
|
||
or modified Free version or to make their own modifications, even if they
|
||
cannot modify the primary software program that links to that library.
|
||
|
||
Finally, the preamble introduces two terms used throughout the license to
|
||
clarify between the different types of combined works: ``works that use
|
||
the library,'' and ``works based on the library.'' Unlike the GPL, the LGPL must
|
||
draw some lines regarding permissibly proprietary combined works. We do this here in this
|
||
license because we specifically seek to liberalize the rights afforded to
|
||
those who make combined works. In the GPL, we reach as far as copyright law
|
||
allows. In the LGPL, we want to draw a line that allows some derivative works
|
||
copyright law would otherwise prohibit if the copyright holder exercised
|
||
his full permitted controls over the work.
|
||
|
||
\section{An Application: A Work that Uses the Library}
|
||
|
||
In the effort to allow certain proprietary works and prohibit
|
||
others, the LGPL distinguishes between two classes of works:
|
||
``works based on the library,'' and ``works that use the library.'' The
|
||
distinction is drawn on the bright line of binary (or runtime) combined
|
||
works and modified versions of source code. We will first consider the definition
|
||
of a ``work that uses the library,'' which is set forth in LGPLv2.1~\S5.
|
||
|
||
We noted in our discussion of GPLv2~\S3 (discussed in
|
||
Section~\ref{GPLv2s3} of this document) that binary programs when
|
||
compiled and linked with GPL'd software are covered as a whole by GPL\@.
|
||
This includes both linking that happens at compile-time (when
|
||
the binary is created) or at runtime (when the binary -- including library
|
||
and main program both -- is loaded into memory by the user). In GPL,
|
||
binary works are controlled by the terms of the license (in GPLv2~\S3),
|
||
and distributors of such binary works must release full
|
||
corresponding source\@.
|
||
|
||
The LGPL, by contrast, allows partial proprietarization of such binary works.
|
||
This scenario, defined in LGPL as ``a work that uses the library,'' works as
|
||
follows:
|
||
|
||
\newcommand{\workl}{$\mathcal{L}$}
|
||
\newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$}
|
||
|
||
\begin{itemize}
|
||
|
||
\item A new copyright holder creates a separate and independent work,
|
||
\worki{}, that makes interface calls (e.g., function calls) to the
|
||
LGPL'd work, called \workl{}, whose copyright is held by some other
|
||
party. Note that since \worki{} and \workl{} are separate and
|
||
independent works, there is no copyright obligation on this new copyright
|
||
holder with regard to the licensing of \worki{}, at least with regard to
|
||
the source code.
|
||
|
||
\item The new copyright holder, for her software to be useful, realizes
|
||
that it cannot run without combining \worki{} and \workl{}.
|
||
Specifically, when she creates a running binary program, that running
|
||
binary must be a combined work, called \lplusi{}, that the user can
|
||
run.
|
||
|
||
\item Since \lplusi{} is a based on both \worki{} and \workl{},
|
||
the license of \workl{} (the LGPL) can put restrictions on the license
|
||
of \lplusi{}. In fact, this is what the LGPL does.
|
||
|
||
\end{itemize}
|
||
|
||
We will talk about the specific restrictions LGPLv2.1 places on ``works
|
||
that use the library'' in detail in Section~\ref{lgpl-section-6}. For
|
||
now, focus on the logic related to how the LGPLv2.1 places requirements on
|
||
the license of \lplusi{}. Note, first of all, the similarity between
|
||
this explanation and that in Section~\ref{separate-and-independent},
|
||
which discussed the combination of otherwise separate and independent
|
||
works with GPL'd code. Effectively, what LGPLv2.1 does is say that when a
|
||
new work is otherwise separate and independent, but has interface
|
||
calls out to an LGPL'd library, then it is considered a ``work that
|
||
uses the library.''
|
||
|
||
In addition, the only reason that LGPLv2.1 has any control over the licensing
|
||
of a ``work that uses the library'' is for the same reason that GPL has
|
||
some say over separate and independent works. Namely, such controls exist
|
||
because the {\em binary combination\/} (\lplusi{}) that must be created to
|
||
make the separate work (\worki{}) at all useful is a work based on
|
||
the LGPLv2.1'd software (\workl{}).
|
||
|
||
Thus, a two-question test that will help indicate if a particular work is
|
||
a ``work that uses the library'' under LGPLv2.1 is as follows:
|
||
|
||
\begin{enumerate}
|
||
|
||
\item Is the source code of the new copyrighted work, \worki{}, a
|
||
completely independent work that stands by itself, and includes no
|
||
source code from \workl{}?
|
||
|
||
\item When the source code is compiled, does it combine into a single work
|
||
with \workl{}, either by static (compile-time) or dynamic
|
||
(runtime) linking, to create a new binary work, \lplusi{}?
|
||
\end{enumerate}
|
||
|
||
If the answers to both questions are ``yes,'' then \worki{} is most likely
|
||
a ``work that uses the library.'' If the answer to the first question
|
||
``yes,'' but the answer to the second question is ``no,'' then most likely
|
||
\worki{} is neither a ``work that uses the library'' nor a ``work based on
|
||
the library.'' If the answer to the first question is ``no,'' but the
|
||
answer to the second question is ``yes,'' then an investigation into
|
||
whether or not \worki{} is in fact a ``work based on the library'' is
|
||
warranted.
|
||
|
||
\section{The Library, and Works Based On It}
|
||
|
||
In short, a ``work based on the library'' could be defined as any
|
||
work based on the LGPL'd software that cannot otherwise fit the
|
||
definition of a ``work that uses the library.'' A ``work based on the
|
||
library'' extends the full width and depth of derivative, combined and/or
|
||
modified works under copyright law, in the same sense that the GPL does.
|
||
|
||
Most typically, one creates a ``work based on the library'' by directly
|
||
modifying the source of the library. Such a work could also be created by
|
||
tightly integrating new software with the library. The lines are no doubt
|
||
fuzzy, just as they are with GPL'd works, since copyright law gives us no
|
||
litmus test for determining if a given work is a derivative or otherwise a
|
||
modified version of another software program.
|
||
|
||
Thus, the test to use when considering whether something is a ``work
|
||
based on the library'' is as follows:
|
||
|
||
\begin{enumerate}
|
||
|
||
\item Is the new work, when in source form, a derivative and/or modified
|
||
work of, and/or a combined work with the LGPL'd work under
|
||
copyright law?
|
||
|
||
\item Is there no way in which the new work fits the definition of a
|
||
``work that uses the library''?
|
||
\end{enumerate}
|
||
|
||
|
||
If the answer is ``yes'' to both these questions, then you most likely
|
||
have a ``work based on the library.'' If the answer is ``no'' to the
|
||
first but ``yes'' to the second, you are in a gray area between ``work
|
||
based on the library'' and a ``work that uses the library.''
|
||
|
||
In our years of work with the LGPLv2.1, however, we have never seen a work
|
||
of software that was not clearly one or the other; the line is quite
|
||
bright. At times, though, we have seen cases where a particularly large work
|
||
in some ways seemed to be both to both a work that used the library and
|
||
a work based on the library. We overcame this problem by
|
||
dividing the work into smaller subunits. It was soon discovered that
|
||
what we actually had were three distinct components: the original
|
||
LGPL'd work, a specific set of works that used that library, and a
|
||
specific set of works that were based on the library. Once such
|
||
distinctions are established, the licensing for each component can be
|
||
considered independently and the LGPLv2.1 applied to each work as
|
||
prescribed.
|
||
|
||
|
||
\section{Subtleties in Defining the Application}
|
||
|
||
In our discussion of the definition of ``works that use the library,'' we
|
||
left out a few more complex details that relate to lower-level programming
|
||
details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities,
|
||
and it has been a source of great confusion. Part of the confusion comes
|
||
because a deep understanding of how compiler programs work is nearly
|
||
mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to
|
||
cover. It helps some to note that this is a border case that we cover in
|
||
the license only so that when such a border case is hit, the implications
|
||
of using the LGPL continue in the expected way.
|
||
|
||
To understand this subtle point, we must recall the way that a compiler
|
||
operates. The compiler first generates object code, which are the binary
|
||
representations of various programming modules. Each of those modules is
|
||
usually not useful by itself; it becomes useful to a user of a full program
|
||
when those modules are {\em linked\/} into a full binary executable.
|
||
|
||
As we have discussed, the assembly of modules can happen at compile-time
|
||
or at runtime. Legally, there is no distinction between the two --- both
|
||
create a modified version of the work by copying and combining portions of one work and
|
||
mixing them with another. However, under LGPL, there is a case in the
|
||
compilation process where the legal implications are different.
|
||
To understand this phenomenon, we consider that a ``work that uses the
|
||
library'' is typically one whose final binary is a work based on the Program,
|
||
but whose source is not. However, sometimes, there
|
||
are cases where the object code --- that intermediate step between source
|
||
and final binary --- is a work created by copying and modifying code
|
||
from the LGPL'd software.
|
||
|
||
For efficiency, when a compiler turns source code into object code, it
|
||
sometimes places literal portions of the copyrighted library code into the
|
||
object code for an otherwise separate independent work. In the normal
|
||
scenario, the final combined work would not be created until final assembly and
|
||
linking of the executable occurred. However, when the compiler does this
|
||
efficiency optimization, at the intermediate object code step, a
|
||
combined work is created.
|
||
|
||
LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of
|
||
the license is clearly that simply compiling software to ``make use'' of
|
||
the library does not in itself cause the compiled work to be a ``work
|
||
based on the library.'' However, since the compiler copies verbatim,
|
||
copyrighted portions of the library into the object code for the otherwise
|
||
separate and independent work, it would actually cause that object file to be a
|
||
``work based on the library.'' It is not FSF's intent that a mere
|
||
compilation idiosyncrasy would change the requirements on the users of the
|
||
LGPLv2.1'd software. This paragraph removes that restriction, allowing the
|
||
implications of the license to be the same regardless of the specific
|
||
mechanisms the compiler uses underneath to create the ``work that uses the
|
||
library.''
|
||
|
||
As it turns out, we have only once had anyone worry about this specific
|
||
idiosyncrasy, because that particular vendor wanted to ship object code
|
||
(rather than final binaries) to their customers and was worried about
|
||
this edge condition. The intent of clarifying this edge condition is
|
||
primarily to quell the worries of software engineers who understand the
|
||
level of verbatim code copying that a compiler often does, and to help
|
||
them understand that the full implications of LGPLv2.1 are the same regardless
|
||
of the details of the compilation progress.
|
||
|
||
\section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}
|
||
\label{lgpl-section-6}
|
||
Now that we have established a good working definition of works that
|
||
``use'' and works that ``are based on'' the library, we will consider the
|
||
rules for distributing these two different works.
|
||
|
||
The rules for distributing ``works that use the library'' are covered in
|
||
LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release
|
||
of source when a binary version of the LGPL'd software is released. Of
|
||
course, it only requires that source code for the library itself be made
|
||
available. The work that ``uses'' the library need not be provided in
|
||
source form. However, there are also conditions in LGPLv2.1~\S6 to make sure
|
||
that a user who wishes to modify or update the library can do so.
|
||
|
||
LGPLv2.1~\S6 lists five choices with regard to supplying library source
|
||
and granting the freedom to modify that library source to users. We
|
||
will first consider the option given by \S~6(b), which describes the
|
||
most common way currently used for LGPLv2.1 compliance on a ``work that
|
||
uses the library.''
|
||
|
||
LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to
|
||
simply use a dynamically linked, shared library mechanism to link with the
|
||
library. This is by far the easiest and most straightforward option for
|
||
distribution. In this case, the executable of the work that uses the
|
||
library will contain only the ``stub code'' that is put in place by the
|
||
shared library mechanism, and at runtime the executable will combine with
|
||
the shared version of the library already resident on the user's computer.
|
||
If such a mechanism is used, it must allow the user to upgrade and
|
||
replace the library with interface-compatible versions and still be able
|
||
to use the ``work that uses the library.'' However, all modern shared
|
||
library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest
|
||
option, since it does not even require that the distributor of the ``work
|
||
based on the library'' ship copies of the library itself.
|
||
|
||
LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library
|
||
mechanism cannot be used. It requires that the source for the library be
|
||
included, in the typical GPL fashion, but it also has a requirement beyond
|
||
that. The user must be able to exercise her freedom to modify the library
|
||
to its fullest extent, and that means recombining it with the ``work based
|
||
on the library.'' If the full binary is linked without a shared library
|
||
mechanism, the user must have available the object code for the ``work
|
||
based on the library,'' so that the user can relink the application and
|
||
build a new binary.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Under \S6(c), this source code may be offered in writing rather than provided,
|
||
or it may be distributed by network under the terms of \S6(d). In addition,
|
||
under \S6(e) the distributor may ``verify'' that the user has already received,
|
||
or at least that the distributor has already sent to this particular user,
|
||
the relevant source. This is evidently intended to prevent requiring
|
||
duplicate deliveries in ``whole distribution'' situations.
|
||
|
||
If the distributor of the combined work intends not to distribute or offer
|
||
the source code of the LGPL’d components, the LGPL’d work must be separately
|
||
distributed (subject to source code delivery requirements as part of that
|
||
separate distribution) and packaged in a ``shared library'' mechanism, which
|
||
means
|
||
|
||
\begin{quotation}
|
||
that [it] (1) uses at run time a copy of the library already present on
|
||
the user’s computer system, rather than copying library functions into
|
||
the executable, and (2) will operate properly with a modified version of
|
||
the library, if the user installs one, as long as the modified version is
|
||
interface-compatible with the version that the work was made with.
|
||
\end{quotation}
|
||
|
||
|
||
Taken together, these provisions mean:
|
||
|
||
\begin{itemize}
|
||
|
||
\item If you create a program that links through a shared library mechanism to
|
||
a work that is separately distributed under LGPLv2.1, then you can
|
||
distribute the resultant program under a license of your choice and you
|
||
need not convey the LGPL’d work’s source code. If you distribute the
|
||
library along with your program, or are the separate distributor of the
|
||
work in another context or as another product, you must distribute its
|
||
corresponding source under the terms of LGPLv2.1 or GPLv2+, at your
|
||
option.
|
||
|
||
\item If you choose to statically link or otherwise combine your program with
|
||
an LGPL’d work, you may choose your own license for the work provided the
|
||
license terms limitations for user modification, reverse engineering and
|
||
debugging are met, and given that the LGPL’d components are still
|
||
governed by LGPL’s terms. You must offer or provide complete and
|
||
corresponding source code for the LGPL’d components. The source code
|
||
material provided must be sufficient to regenerate the combined work with
|
||
a user-modified version of the LGPL’d components.
|
||
\end{itemize}
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
\S6 also requires that:
|
||
|
||
\begin{quotation}
|
||
You must give prominent notice with each copy of the work that the
|
||
Library is used in it and that the Library and its use are covered by
|
||
this License. You must supply a copy of this License. If the work during
|
||
execution displays copyright notices, you must include the copyright
|
||
notice for the Library among them, as well as a reference directing the
|
||
user to the copy of this License.
|
||
\end{quotation}
|
||
|
||
This is not identical to the roughly parallel requirements of GPLv2 and
|
||
GPLv3. Compliance requires slightly different measures with respect to the
|
||
``credits'' or ``licenses'' or ``about'' screens in interactive programs.
|
||
|
||
%FIXME-URGENT: end
|
||
|
||
|
||
The remaining options in LGPLv2.1~\S6 are very similar to the other choices
|
||
provided by GPLv2~\S3. There are some additional options, but time does
|
||
not permit us in this course to go into those additional options. In
|
||
almost all cases of distribution under LGPL, either LGPLv2.1~\S6(a) or LGPLv2.1~\S6(b) are
|
||
exercised.
|
||
|
||
\section{Distribution of the Combined Works}
|
||
|
||
Essentially, ``works based on the library'' must be distributed under the
|
||
same conditions as works under full GPL\@. In fact, we note that
|
||
LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.
|
||
There are again subtle differences and additions, which time does not
|
||
permit us to cover in this course.
|
||
|
||
%FIXME-urgent; integrate
|
||
|
||
Not only must the source code be complete and corresponding, but it must be
|
||
provided in such a way that a modified version of the entire combined work
|
||
can be regenerated with a modified version of the LGPL’d work replacing the
|
||
version originally provided to the user. When LGPL’d code is statically
|
||
linked to a non-copyleft executable, for example, the required source code
|
||
must also include sufficient material to split the distributed executable and
|
||
relink with a modified version of the library.
|
||
%FIXME-URGENT: end
|
||
|
||
\section{And the Rest}
|
||
|
||
The remaining variations between the LGPL and the GPL cover the following
|
||
conditions:
|
||
|
||
\begin{itemize}
|
||
|
||
\item Allowing a licensing ``upgrade'' from the LGPL to the GPL\@ (in LGPLv2.1~\S3)
|
||
|
||
%FIXME-URGENT: integrate
|
||
But LGPLv2.1 \S3 allows all works under its
|
||
terms, copy by copy, to be used instead under the terms of GPLv2 or any later
|
||
version. This provides a pathway for those who do not want to use code under
|
||
the requirements of LGPLv2.1 to do so under GPLv2 or GPLv3 at their
|
||
discretion.
|
||
%FIXME-URGENT: end
|
||
|
||
\item Binary distribution of the library only, covered in LGPLv2.1~\S4,
|
||
which is effectively equivalent to LGPLv2.1~\S3
|
||
|
||
\item Creating aggregates of libraries that are separate and independent works from
|
||
each other, and distributing them as a unit (in LGPLv2.1~\S7)
|
||
|
||
\end{itemize}
|
||
|
||
|
||
Due to time constraints, we cannot cover these additional terms in detail,
|
||
but they are mostly straightforward. The key to understanding LGPLv2.1 is
|
||
understanding the difference between a ``work based on the library'' and a
|
||
``work that uses the library.'' Once that distinction is clear, the
|
||
remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in
|
||
our more extensive GPL unit can be directly applied.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
\chapter{LGPLv3}
|
||
|
||
LGPLv3 was designed to rectify the architectural plan of the GNU family of
|
||
licenses, by making the copyleft license from which LGPLv3 is a combination
|
||
exception GPLv3. LGPLv3 is therefore an additional permission in the form
|
||
provided for in GPLv3 \S7, above.
|
||
|
||
\section{Section 0: Additional Definitions}
|
||
|
||
Section 0 defines the ``Library'' it covers as a work that presents one or more
|
||
interfaces at which a ``use'' can be made by an ``Application.'' Class
|
||
inheritance is ``deemed'' a use of an interface. An ``Application,'' which is
|
||
other program code using one or more ``Library'' interfaces can be combined
|
||
with the code on the other side of the interfaces it uses to form a ``Combined
|
||
Work.''
|
||
|
||
\section{Section 1: Exception to Section 3 of the GNU GPL}
|
||
|
||
Section 1 excepts away the interference with use of LGPLv3 code as part of
|
||
``effective technological measures'' of access limitation for other copyrighted
|
||
works provided otherwise by GPLv3 \S3.
|
||
|
||
|
||
\section{Section 2 Conveying Modified Versions}
|
||
|
||
Section 2 continues to require, as LGPLv2.1 \S2(d) required, that the Library
|
||
not be modified to require keys, tokens, tables, or other global non-argument
|
||
data unrelated to function. This is again stated as a ``good faith effort''
|
||
requirement, but failure to cure on notice is strong evidence of the absence
|
||
of good faith. Use of GPLv3 terms by removal of the additional permission, as
|
||
provided for by GPLv3 \S7, is the alternate path to compliance.
|
||
|
||
\section{Section 3: Object Code Incorporating Material from Library Header Files}
|
||
|
||
Section 3 disposes entirely [FIXME: with deep technical discussion of
|
||
combination mechanisms] in the use of header files and other such forms of
|
||
Library material covered by LGPLv2.1 \S5 by stating a rule applicable at the
|
||
user’s discretion to all such uses within copyright scope: giving notice that
|
||
the library is used in the program and providing copies of GPLv3 and LGPLv3
|
||
along with the work.
|
||
|
||
\section{ Section 4: Combined Works}
|
||
|
||
Section 4 is the combination permission at the heart of LGPLv3. It restates
|
||
the license limitation provision of LGPLv2.1 \S2 to clarify that the terms on
|
||
the Combined Work may not prohibit user modification of the Library code, or
|
||
the debugging of such modifications to the Library code by means of whatever
|
||
reverse engineering is necessary.
|
||
|
||
Section 4(d)(0) contains the source provision requirement, for the Minimal
|
||
Corresponding Source, which ``means the Corresponding Source for the Combined
|
||
Work, excluding any source code for portions of the Combined Work that,
|
||
considered in isolation, are based on the Application, and not on the Linked
|
||
Version [of the Library].'' The alternative to the provision of source code is
|
||
distribution by way of the ``shared library'' mechanism under \S4(d)(1),
|
||
described with respect to LGPLv2.1 \S6, above.
|
||
|
||
In addition, \S4(e) requires the delivery of ``installation information''
|
||
required to install the modified version of the Library in ``user products''
|
||
under GPLv3 \S6. Where Library Minimal Corresponding Source is not made
|
||
available under \S4(d)(1), \S4(e) reaffirms that ``installation information''
|
||
must still be compliantly delivered under the terms of GPLv3 \S6.
|
||
|
||
All other provisions of GPLv3 are in force as previously described, and are
|
||
not excepted by the additional permission granted in LGPLv3.
|
||
%FIXME-URGENT: end
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% FIXME-LATER: There should be a chapter on GPL Exceptions generally.
|
||
|
||
% Here is some CC-By-SA text from another source that would make an
|
||
% acceptable introduction to a section on the GCC RTL Exception if such a
|
||
% chapter is written:
|
||
|
||
% This GCC Runtime Library Exception (``Exception'') is an additional
|
||
% permission as provided by Section 7 of GPLv3. The purpose of this Exception
|
||
% is to allow compilation of non-GPL (including proprietary) programs making
|
||
% use of the header files and runtime libraries covered by this Exception and
|
||
% containing code from the copyleft toolchain embedded by the compiler in the
|
||
% object code of the program as part of the compilation process. The GCC
|
||
% Runtime Library Exception covers any file that has a notice in its license
|
||
% headers stating that the exception applies.
|
||
|
||
% FIXME-LATER: end
|
||
|
||
\chapter{Integrating the GPL into Business Practices}
|
||
|
||
Since GPL'd software is now extremely prevalent through the industry, it
|
||
is useful to have some basic knowledge about using GPL'd software in
|
||
business and how to build business models around GPL'd software.
|
||
|
||
\section{Using GPL'd Software In-House}
|
||
|
||
As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial,
|
||
the GPL only governs the activities of copying, modifying and
|
||
distributing software programs that are not governed by the license.
|
||
Thus, in FSF's view, simply installing the software on a machine and
|
||
using it is not controlled or limited in any way by the GPL\@. Using Free
|
||
Software in general requires substantially fewer agreements and less
|
||
license compliance activity than any known proprietary software.
|
||
|
||
Even if a company engages heavily in copying the software throughout the
|
||
enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is
|
||
encouraged! If the company simply deploys unmodified (or even modified)
|
||
Free Software throughout the organization for its employees to use, the
|
||
obligations under the license are very minimal. Using Free Software has a
|
||
substantially lower cost of ownership --- both in licensing fees and in
|
||
licensing checking and handling -- than the proprietary software
|
||
equivalents.
|
||
|
||
\section{Business Models}
|
||
\label{Business Models}
|
||
|
||
Using Free Software in house is certainly helpful, but a thriving
|
||
market for Free Software-oriented business models also exists. There is the
|
||
traditional model of selling copies of Free Software distributions.
|
||
Many companies make substantial revenue
|
||
from this model. Some choose this model because they have
|
||
found that for higher-end hardware, the profit made from proprietary
|
||
software licensing fees is negligible. The real profit is in the hardware,
|
||
but it is essential that software be stable, reliable and dependable, and
|
||
the users be allowed to have unfettered access to it. Free Software, and
|
||
GPL'd software in particular (because IBM can be assured that proprietary
|
||
versions of the same software will not exist to compete on their hardware)
|
||
is the right choice.
|
||
|
||
For example, charging a ``convenience fee'' for Free Software,
|
||
when set at a reasonable price (around \$60 or so), can produce some
|
||
profit. Even though Red Hat's system is fully downloadable on their
|
||
Web site, people still go to local computer stores and buy copies of their
|
||
box set, which is simply a printed version of the manual (available under
|
||
a Free license as well) and the Free Software system it documents.
|
||
|
||
\medskip
|
||
|
||
However, custom support, service, and software improvement contracts
|
||
are the most widely used models for GPL'd software. The GPL is
|
||
central to their success, because it ensures that the code base
|
||
remains common, and that large and small companies are on equal
|
||
footing for access to the technology. Consider, for example, the GNU
|
||
Compiler Collection (GCC). Cygnus Solutions, a company started in the
|
||
early 1990s, was able to grow steadily simply by providing services
|
||
for GCC --- mostly consisting of new ports of GCC to different or new,
|
||
embedded targets. Eventually, Cygnus was so successful that
|
||
it was purchased by Red Hat where it remains a profitable division.
|
||
|
||
However, there are very small companies that compete in
|
||
this space. Because the code-base is protected by the GPL, it creates and
|
||
demands industry trust. Companies can cooperate on the software and
|
||
improve it for everyone. Meanwhile, companies who rely on GCC for their
|
||
work are happy to pay for improvements, and for ports to new target
|
||
platforms. Nearly all the changes fold back into the standard
|
||
versions, and those forks that exist remain freely available.
|
||
|
||
\medskip
|
||
|
||
\label{Proprietary Relicensing}
|
||
|
||
A final common business model that is perhaps the most controversial is
|
||
proprietary relicensing of a GPL'd code base. This is only an option for
|
||
software in which a particular entity holds exclusive rights to
|
||
relicense\footnote{Entities typically hold exclusive relicensing rights
|
||
either by writing all the software under their own copyrights, collecting
|
||
copyright assignments from all contributors, or by otherwise demanding
|
||
unconditional relicensing permissions from all contributors via some legal
|
||
agreement}. As discussed earlier in this tutorial, a copyright holder is
|
||
permitted under copyright law to license a software system under her
|
||
copyright as many different ways as she likes to as many different parties as
|
||
she wishes.
|
||
|
||
Some companies use this to their
|
||
financial advantage with regard to a GPL'd code base. The standard
|
||
version is available from the company under the terms of the GPL\@.
|
||
However, parties can purchase separate proprietary software licensing for
|
||
a fee.
|
||
|
||
This business model is at best problematic and at worst predatory because it means that the GPL'd code
|
||
base must be developed in a somewhat monolithic way, because volunteer
|
||
Free Software developers may be reluctant to assign their copyrights to
|
||
the company because it will not promise to always and forever license the
|
||
software as Free Software. Indeed, the company will surely use such code
|
||
contributions in proprietary versions licensed for fees.
|
||
|
||
\section{Ongoing Compliance}
|
||
|
||
GPL compliance is in fact a very simple matter --- much simpler than
|
||
typical proprietary software agreements and EULAs. Usually, the most
|
||
difficult hurdle is changing from a proprietary software mindset to one
|
||
that seeks to foster a community of sharing and mutual support. Certainly
|
||
complying with the GPL from a users' perspective gives substantially fewer
|
||
headaches than proprietary license compliance.
|
||
|
||
For those who go into the business of distributing {\em modified}
|
||
versions of GPL'd software, the burden is a bit higher, but not by
|
||
much. The glib answer is that by releasing the whole product as Free
|
||
Software, it is always easy to comply with the GPL. However,
|
||
admittedly to the dismay of FSF, many modern and complex software
|
||
systems are built using both proprietary and GPL'd components that are
|
||
clearly and legally separate and independent works, merely aggregated
|
||
together on the same device.
|
||
|
||
However, it's sometimes is easier, quicker, and cheaper to simply to
|
||
improve existing GPL'd application than to start from scratch. In
|
||
exchange for this amazing benefit, the license requires that the modifier gives
|
||
back to the commons that made the work easier in the first place. It is a
|
||
reasonable trade-off and a way to help build a better world while also
|
||
making a profit.
|
||
|
||
Note that FSF does provide services to assist companies who need
|
||
assistance in complying with the GPL. You can contact FSF's GPL
|
||
Compliance Labs at $<$licensing@fsf.org$>$.
|
||
|
||
%FIXME-LATER: should have \tutorialpart
|
||
|
||
If you are particularly interested in matters of GPL compliance, we
|
||
recommend the next two parts, which include both recommendations on good
|
||
compliance and compliance case studies.
|
||
|
||
% =====================================================================
|
||
% END OF FIRST DAY SEMINAR SECTION
|
||
% =====================================================================
|
||
|
||
%% LocalWords: Sebro Novalis Ravicher GPLv GPL'd copylefted LGPLv OSI USC
|
||
%% LocalWords: noncommercially counterintuitive Berne copyrightable DRM UC
|
||
%% LocalWords: proprietarize proprietarization Stallman's Tridgell's RMS
|
||
%% LocalWords: Lessig Lessig's Stallman Proto GPLs proto Tai pre GPL's ful
|
||
%% LocalWords: legalbol AGPLv Runtime licensor licensors relicense UCITA
|
||
%% LocalWords: unprotectable Intl nd th Kepner Tregoe Bando Indust Mitel
|
||
%% LocalWords: Iqtel Bateman Mitek Arce protectable hoc faire de minimis
|
||
%% LocalWords: Borland Int'l uncopyrightable LLC APIs Ent Connectix DVD's
|
||
%% LocalWords: redistributor diachronic unshared subpart redistributors
|
||
%% LocalWords: CDs userbase reshifts licensor's distributee impliedly Mgmt
|
||
%% LocalWords: patentee relicenses irrevocability Jacobsen Katzer TRW CCS
|
||
%% LocalWords: Unfreedonia administrivia Relicensing impermissibly centric
|
||
%% LocalWords: permissibility firehose bytecode minified Javascript DLLs
|
||
%% LocalWords: preprocessors functionalities offsite sublicensing DMCA CFR
|
||
%% LocalWords: anticircumvention WIPO BitTorrent multidirectional Magnuson
|
||
%% LocalWords: subdefinition Dryvit Stroebner Tandy TRS superset LGPL SLES
|
||
%% LocalWords: cryptographic relicensing removability sublicensed Novell
|
||
%% LocalWords: anticompetitive administrability sublicensable licensable
|
||
%% LocalWords: sublicense sublicensees sublicenses affixation Novell's
|
||
%% LocalWords: severability Affero LGPL'd lingua franca glibc facto LGPL's
|
||
%% LocalWords: relicensed runtime subunits relink downloadable MontaVista
|
||
%% LocalWords: CodeSourcery OpenTV MySQL TrollTech
|