4970 lines
271 KiB
TeX
4970 lines
271 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}
|
|
\label{gpl-lgpl-part}
|
|
|
|
{\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 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, 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
|
|
differ 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 user has software freedom with respect to a particular program if that
|
|
user has 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 a subset of a specific program's user base to have these freedoms, while other
|
|
users of the same version the program 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}
|
|
|
|
Copyleft is a strategy of utilizing copyright law to pursue the policy goal
|
|
of fostering and encouraging the equal and inalienable right to copy, share,
|
|
modify and improve creative works of authorship. Copyleft (as a general
|
|
term) describes any method that utilizes the copyright system to achieve the
|
|
aforementioned goal. Copyleft as a concept is usually implemented in the
|
|
details of a specific copyright license, such as the
|
|
\hyperref[GPLv3-full-text]{GNU General Public License (GPL)} and the Creative
|
|
Commons Attribution Share Alike License (the latter of which is the license
|
|
of this work itself). Copyright holders of creative work can unilaterally
|
|
implement these licenses for their own works to build communities that
|
|
collaboratively share and improve those copylefted creative works.
|
|
|
|
Copyleft uses functional parts of the copyright system to achieve an unusual
|
|
result (legal protection for free sharing). Copyleft modifies, or ``hacks''
|
|
copyright law, which is usually employed to strengthen the rights of authors
|
|
or publishers, to strengthen instead the rights of users. Thus, Copyleft is
|
|
a legal strategy and mechanism to defend, uphold and propagate software
|
|
freedom. The basic technique of copyleft is as follows: copyright the
|
|
software, license it under terms that give all the software freedoms, but use
|
|
the copyright law controls to ensure that all who receive a copy of the
|
|
software have equal rights and freedom. In essence, copyleft grants freedom,
|
|
but forbids others to forbid that freedom to anyone else along the
|
|
distribution and modification chains.
|
|
|
|
Copyleft's ``reciprocity'' or ``share and share alike'' rule protects both
|
|
developers, who avoid facing a ``prioritized'' competitor of their project,
|
|
and users, who can be sure that they will have all four software freedoms ---
|
|
not only in the present version of the program they use, but in all its
|
|
future improved versions.
|
|
|
|
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, written as a ``copyright
|
|
license''. The GPL implements the concept of copyleft for software-oriented
|
|
and other functional works of a technical nature. The ``CC BY SA'' license
|
|
implements copyleft for works of textual, musical and visual authorship, such
|
|
as this tutorial.
|
|
|
|
Copyleft advocates often distinguish between the concept of a ``strong
|
|
copyleft'' or a ``weak copyleft''. However, ``strong vs. weak'' copyleft is
|
|
not a dichotomy, it's a spectrum. The strongest copylefts strive to the
|
|
exclusive rights that copyright grants to authors as extensively as possible
|
|
to maximize software freedom. As a copyleft gets ``weaker'', the copyleft
|
|
license typically makes ``trade offs'' that might impede software freedom,
|
|
but reach other tactic goals for the community of users and developers of the
|
|
work.
|
|
|
|
In other words, strong copyleft licenses place the more requirements on how
|
|
``the work'' is licensed. 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. Strong
|
|
copyleft licenses exercise their scope fully. Anything which is ``a work''
|
|
or a ``work based on a work'' licensed under a strong copyleft is subject to
|
|
its requirements, including the requirement of complete, corresponding source
|
|
code\footnote{Copyleft communities' use of the term ``strong copyleft'' is
|
|
undoubtedly imprecise. For example, most will call the GNU GPL a ``strong
|
|
copyleft'' license, even though the GPL itself has various exceptions, such
|
|
as the \hyperref[GPLv3-system-library-exception]{GPLv3's system library
|
|
exception} written into the text of the license itself. Furthermore, the
|
|
copyleft community continues to debate where the a license cross the line
|
|
from ``strong copyleft'' to ``license that fails to respect software
|
|
freedom'', although ultimately these debates are actually regarding whether
|
|
the license fits \hyperref[Free Software Definition]{Free Software
|
|
definition} at all.}. Thus, copyleft licenses, particularly strong ones,
|
|
seek to ensure the same license covers every version of ``work based on the
|
|
work'', as recognized by local copyright law, and thereby achieve the
|
|
specific strategic policy aim of ensuring software freedom for all users,
|
|
developers, authors, and readers who encounter the copylefted work.
|
|
|
|
\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 does not 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.
|
|
Meanwhile, lawyers will likely based their conclusions on the application of rules
|
|
made in the context of literary or artistic copyright to the different
|
|
context of computer programming and by analyzing the (somewhat limited) case
|
|
law and guidance available from various sources.
|
|
(Chapter~\ref{derivative-works} discusses this issue in depth.)
|
|
|
|
|
|
\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}
|
|
|
|
As described in the \hyperref[copyleft-definition]{earlier general discussion
|
|
of copyleft}, strong copyleft licenses such as the GPL seek to uphold
|
|
software freedom via the copyright system. This principle often causes
|
|
theoretical or speculative dispute among lawyers, because ``the work'' ---
|
|
the primary unit of consideration under most copyright rules -- 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.
|
|
|
|
Therefore, this chapter digresses from discussion of GPL's exact text to
|
|
consider the matter of combined and/or derivative works --- a concept that we must
|
|
understand fully before considering GPLv2~\S\S2--3\@. At least under USA
|
|
copyright law, 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.
|
|
|
|
\subsection{The Simpler Parts of GPLv2~\S2}
|
|
|
|
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.
|
|
|
|
GPLv2~\S2(c), a relatively simple section, requires that any program which
|
|
(before modification) ``normally reads commands interactively when run'' and
|
|
displays or prints legal information also display all copyright notices,
|
|
warranty disclaimer, modification indications and a pointer to the license,
|
|
even in modified versions. The requirement is relatively simple, and relates
|
|
to an important policy goal of copyleft: downstream users should be informed
|
|
of their rights. Its implications and details are straightforward and
|
|
simple.
|
|
|
|
\subsection{GPLv2~\S2(b)}
|
|
|
|
Meanwhile, GPLv2~\S2(b) requires careful and extensive study. Its four short lines embody
|
|
the some of the essential 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}
|
|
|
|
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.
|
|
|
|
The GPL recognizes what is outside its scope. When 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. Thus, Far from attempting to extend copyleft beyond the
|
|
scope of copyright, the licenses explicitly recognize.
|
|
|
|
Thus, GPL recognizes what is outside its scope. When a programmer's work is
|
|
``separate and independent'' from any GPL'd program code with which it could
|
|
be combined, then copyleft obligations do not extend to the independent work
|
|
separately distributed. Thus, far from attempting to extend copyleft beyond
|
|
the scope of copyright, GPL explicitly limits the scope of copyleft to the
|
|
scope of copyright.
|
|
|
|
GPL does not, however (as is sometimes suggested) distinguish ``dynamic''
|
|
from ``static'' linking of program code. 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, as such permission was
|
|
either not available or was available on terms that were not observed.
|
|
|
|
In other words, when combining other software with GPL'd components, the only
|
|
available permission is GPL. The combiner must observe and respect the GPL
|
|
observed on the combination as a whole. It matters not if that combination
|
|
is made with a linker before distribution of the executable, is made by the
|
|
operating system in order to share libraries for execution efficiency at
|
|
runtime, or results from runtime references in the language at runtime (as in
|
|
Java programs).
|
|
|
|
\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.
|
|
|
|
\label{GPLv2s3b}
|
|
GPLv2~\S3(b) allows a distributor of binaries to instead provide a written
|
|
offer for source code alongside those binaries. This is useful in two
|
|
specific ways. First, it may turn out that most users do not request the
|
|
source, and thus the cost of producing the CDs is saved --- a financial
|
|
and environmental windfall. In addition, along with a GPLv2~\S3(b) compliant
|
|
offer for source, a binary distributor might choose to \emph{also} give a
|
|
URL for source code. Many who would otherwise need a CD with source might
|
|
turn out to have those coveted high bandwidth connections, and are able to
|
|
download the source instead --- again yielding environmental and financial
|
|
windfalls.
|
|
|
|
However, note that regardless of how many users prefer to get the
|
|
source online, GPLv2~\S3(b) does place lasting long-term obligations on the
|
|
binary distributor. The binary distributor must be prepared to honor
|
|
that offer for source for three years and ship it out (just as they
|
|
would have had to do under GPLv2~\S3(a)) at a moment's notice when they
|
|
receive such a request. There is real organizational cost here:
|
|
support engineers must be trained how to route source requests, and
|
|
source CD images for every release version for the last three years
|
|
must be kept on hand to burn such CDs quickly. The requests might not
|
|
even come from actual customers; the offer for source must be valid
|
|
for ``any third party''.
|
|
|
|
That phrase is another place where some get confused --- thinking again
|
|
that full public distribution of source is required. The offer for source
|
|
must be valid for ``any third party'' because of the freedoms of
|
|
redistribution granted by GPLv2~\S\S1--2. A company may ship a binary image
|
|
and an offer for source to only one customer. However, under GPL, that
|
|
customer has the right to redistribute that software to the world if she
|
|
likes. When she does, that customer has an obligation to make sure that
|
|
those who receive the software from her can exercise their freedoms under
|
|
GPL --- including the freedom to modify, rebuild, and redistribute the
|
|
source code.
|
|
|
|
GPLv2~\S3(c) is created to save her some trouble, because by itself GPLv2~\S3(b)
|
|
would unfairly favor large companies. GPLv2~\S3(b) allows the
|
|
separation of the binary software from the key tool that people can use
|
|
to exercise their freedom. The GPL permits this separation because it is
|
|
good for re-distributors, and those users who turn out not to need the
|
|
source. However, to ensure equal rights for all software users, anyone
|
|
along the distribution chain must have the right to get the source and
|
|
exercise those freedoms that require it.
|
|
|
|
Meanwhile, GPLv2~\S3(b)'s compromise primarily benefits companies that
|
|
distribute binary software commercially. Without GPLv2~\S3(c), that benefit
|
|
would be at the detriment of the companies' customers; the burden of
|
|
source code provision would be unfairly shifted to the companies'
|
|
customers. A customer, who had received binaries with a GPLv2~\S3(b)-compliant
|
|
offer, would be required under GPLv2 (sans GPLv2~\S3(c)) to acquire the source,
|
|
merely to give a copy of the software to a friend who needed it. GPLv2~\S3(c)
|
|
reshifts this burden to entity who benefits from GPLv2~\S3(b).
|
|
|
|
GPLv2~\S3(c) allows those who undertake \emph{noncommercial} distribution to
|
|
simply pass along a GPLv2~\S3(b)-compliant source code offer. The customer who
|
|
wishes to give a copy to her friend can now do so without provisioning the
|
|
source, as long as she gives that offer to her friend. By contrast, if
|
|
she wanted to go into business for herself selling CDs of that software,
|
|
she would have to acquire the source and either comply via GPLv2~\S3(a), or
|
|
write her own GPLv2~\S3(b)-compliant source offer.
|
|
|
|
This process is precisely the reason why a GPLv2~\S3(b) source offer must be
|
|
valid for all third parties. At the time the offer is made, there is no
|
|
way of knowing who might end up noncommercially receiving a copy of the
|
|
software. Companies who choose to comply via GPLv2~\S3(b) must thus be
|
|
prepared to honor all incoming source code requests. For this and the
|
|
many other additional necessary complications under GPLv2~\S\S3(b--c), it is
|
|
only rarely a better option than complying via GPLv2~\S3(a).
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{GPL's Implied Patent Grant}
|
|
\label{gpl-implied-patent-grant}
|
|
|
|
We digress again briefly from our section-by-section consideration of GPLv2
|
|
to consider the interaction between the terms of GPL and patent law. The
|
|
GPLv2, despite being silent with respect to patents, actually confers on its
|
|
licensees more rights to a licensor's patents than those licenses that
|
|
purport to address the issue. This is the case because patent law, under
|
|
the doctrine of implied license, gives to each distributee of a patented
|
|
article a license from the distributor to practice any patent claims owned
|
|
or held by the distributor that cover the distributed article. The
|
|
implied license also extends to any patent claims owned or held by the
|
|
distributor that cover ``reasonably contemplated uses'' of the patented
|
|
article. To quote the Federal Circuit Court of Appeals, the highest court
|
|
for patent cases other than the Supreme Court:
|
|
|
|
\begin{quotation}
|
|
Generally, when a seller sells a product without restriction, it in
|
|
effect promises the purchaser that in exchange for the price paid, it will
|
|
not interfere with the purchaser's full enjoyment of the product
|
|
purchased. The buyer has an implied license under any patents of the
|
|
seller that dominate the product or any uses of the product to which the
|
|
parties might reasonably contemplate the product will be put.
|
|
\end{quotation}
|
|
Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d
|
|
1445, 1451 (Fed. Cir. 1997).
|
|
|
|
Of course, Free Software is licensed, not sold, and there are indeed
|
|
restrictions placed on the licensee, but those differences are not likely
|
|
to prevent the application of the implied license doctrine to Free
|
|
Software, because software licensed under the GPL grants the licensee the
|
|
right to make, use, and sell the software, each of which are exclusive
|
|
rights of a patent holder. Therefore, although the GPLv2 does not expressly
|
|
grant the licensee the right to do those things under any patents the
|
|
licensor may have that cover the software or its reasonably contemplated
|
|
uses, by licensing the software under the GPLv2, the distributor impliedly
|
|
licenses those patents to the GPLv2 licensee with respect to the GPLv2'd
|
|
software.
|
|
|
|
An interesting issue regarding this implied patent license of GPLv2'd
|
|
software is what would be considered ``uses of the [software] to which
|
|
the parties might reasonably contemplate the product will be put.'' A
|
|
clever advocate may argue that the implied license granted by GPLv2 is
|
|
larger in scope than the express license in other Free Software
|
|
licenses with express patent grants, in that the patent license
|
|
clause of many of those other Free Software licenses are specifically
|
|
limited to the patent claims covered by the code as licensed by the patentee.
|
|
|
|
In contrast, a GPLv2 licensee, under the doctrine of implied patent license,
|
|
is free to practice any patent claims held by the licensor that cover
|
|
``reasonably contemplated uses'' of the GPL'd code, which may very well
|
|
include creation and distribution of modified works since the GPL's terms,
|
|
under which the patented code is distributed, expressly permits such activity.
|
|
|
|
|
|
Further supporting this result is the Federal Circuit's pronouncement that
|
|
the recipient of a patented article has, not only an implied license to
|
|
make, use, and sell the article, but also an implied patent license to
|
|
repair the article to enable it to function properly, Bottom Line Mgmt.,
|
|
Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the
|
|
Federal Circuit extended that rule to include any future recipients of the
|
|
patented article, not just the direct recipient from the distributor.
|
|
This theory comports well with the idea of Free Software, whereby software
|
|
is distributed among many entities within the community for the purpose
|
|
of constant evolution and improvement. In this way, the law of implied
|
|
patent license used by the GPLv2 ensures that the community mutually
|
|
benefits from the licensing of patents to any single community member.
|
|
|
|
Note that simply because GPLv2'd software has an implied patent license does
|
|
not mean that any patents held by a distributor of GPLv2'd code become
|
|
worthless. To the contrary, the patents are still valid and enforceable
|
|
against either:
|
|
|
|
\begin{enumerate}
|
|
\renewcommand{\theenumi}{\alph{enumi}}
|
|
\renewcommand{\labelenumi}{\textup{(\theenumi)}}
|
|
|
|
\item any software other than that licensed under the GPLv2 by the patent
|
|
holder, and
|
|
|
|
\item any party that does not comply with the GPLv2
|
|
with respect to the licensed software.
|
|
\end{enumerate}
|
|
|
|
\newcommand{\compB}{$\mathcal{B}$}
|
|
\newcommand{\compA}{$\mathcal{A}$}
|
|
|
|
For example, if Company \compA{} has a patent on advanced Web browsing, but
|
|
also licenses a Web browsing program under the GPLv2, then it
|
|
cannot assert the patent against any party based on that party's use of
|
|
Company \compA{}'s GPL'd Web browsing software program, or on that party's
|
|
creation and use of modified versions of that GPL'd program. However, if a
|
|
party uses that program without
|
|
complying with the GPLv2, then Company \compA{} can assert both copyright
|
|
infringement claims against the non-GPLv2-compliant party and
|
|
infringement of the patent, because the implied patent license only
|
|
extends to use of the software in accordance with the GPLv2. Further, if
|
|
Company \compB{} distributes a competitive advanced Web browsing program
|
|
that is not a modified version of Company \compA{}'s GPL'd Web browsing software
|
|
program, Company \compA{} is free to assert its patent against any user or
|
|
distributor of that product. It is irrelevant whether Company \compB's
|
|
program is also distributed under the GPLv2, as Company \compB{} can not grant
|
|
implied licenses to Company \compA's patent.
|
|
|
|
This result also reassures companies that they need not fear losing their
|
|
proprietary value in patents to competitors through the GPLv2 implied patent
|
|
license, as only those competitors who adopt and comply with the GPLv2's
|
|
terms can benefit from the implied patent license. To continue the
|
|
example above, Company \compB{} does not receive a free ride on Company
|
|
\compA's patent, as Company \compB{} has not licensed-in and then
|
|
redistributed Company A's advanced Web browser under the GPLv2. If Company
|
|
\compB{} does do that, however, Company \compA{} still has not lost
|
|
competitive advantage against Company \compB{}, as Company \compB{} must then,
|
|
when it re-distributes Company \compA's program, grant an implied license
|
|
to any of its patents that cover the program. Further, if Company \compB{}
|
|
relicenses an improved version of Company A's program, it must do so under
|
|
the GPLv2, meaning that any patents it holds that cover the improved version
|
|
are impliedly licensed to any licensee. As such, the only way Company
|
|
\compB{} can benefit from Company \compA's implied patent license, is if it,
|
|
itself, distributes Company \compA's software program and grants an
|
|
implied patent license to any of its patents that cover that program.
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Defending Freedom on Many Fronts}
|
|
|
|
Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the
|
|
core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3.
|
|
GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are
|
|
not infringed, are enforceable, are kept to the confines of copyright law but
|
|
also not trumped by other copyright agreements or components of other
|
|
entirely separate legal systems. In short, while GPLv2~\S\S0--3 are the parts
|
|
of the license that defend the freedoms of users and programmers,
|
|
GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear
|
|
so that \S\S~0--3 can do their jobs.
|
|
|
|
\section{GPLv2~\S4: Termination on Violation}
|
|
\label{GPLv2s4}
|
|
|
|
GPLv2~\S4 is GPLv2's termination clause. Upon first examination, it seems
|
|
strange that a license with the goal of defending users' and programmers'
|
|
freedoms for perpetuity in an irrevocable way would have such a clause.
|
|
However, upon further examination, the difference between irrevocability
|
|
and this termination clause becomes clear.
|
|
|
|
The GPL is irrevocable in the sense that once a copyright holder grants
|
|
rights for someone to copy, modify and redistribute the software under terms
|
|
of the GPL, they cannot later revoke that grant. Since the GPL has no
|
|
provision allowing the copyright holder to take such a prerogative, the
|
|
license is granted as long as the copyright remains in effect.\footnote{In
|
|
the USA, due to unfortunate legislation, the length of copyright is nearly
|
|
perpetual, even though the Constitution forbids perpetual copyright.} The
|
|
copyright holders have the right to relicense the same work under different
|
|
licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to
|
|
stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used),
|
|
but they may not revoke the rights under GPLv2 already granted.
|
|
|
|
In fact, when an entity loses their right to copy, modify and distribute
|
|
GPL'd software, it is because of their \emph{own actions}, not that of the
|
|
copyright holder. The copyright holder does not decide when GPLv2~\S4
|
|
termination occurs (if ever); rather, the actions of the licensee determine
|
|
that.
|
|
|
|
Under copyright law, the GPL has granted various rights and freedoms to
|
|
the licensee to perform specific types of copying, modification, and
|
|
redistribution. By default, all other types of copying, modification, and
|
|
redistribution are prohibited. GPLv2~\S4 says that if you undertake any of
|
|
those other types (e.g., redistributing binary-only in violation of GPLv2~\S3),
|
|
then all rights under the license --- even those otherwise permitted for
|
|
those who have not violated --- terminate automatically.
|
|
|
|
GPLv2~\S4 makes GPLv2 enforceable. If licensees fail to adhere to the
|
|
license, then they are stuck without any permission under to engage in
|
|
activities covered by copyright law. They must completely cease and desist
|
|
from all copying, modification and distribution of the GPL'd software.
|
|
|
|
At that point, violating licensees must gain the forgiveness of the copyright
|
|
holders to have their rights restored. Alternatively, the violators could
|
|
negotiate another agreement, separate from GPL, with the copyright
|
|
holder. Both are common practice, although
|
|
\tutorialpartsplit{as discussed in \textit{A Practical Guide to GPL
|
|
Compliance}, there are }{Chapter~\ref{compliance-understanding-whos-enforcing}
|
|
explains further} key differences between these two very different uses of GPL.
|
|
|
|
\section{GPLv2~\S5: Acceptance, Copyright Style}
|
|
\label{GPLv2s5}
|
|
|
|
GPLv2~\S5 brings us to perhaps the most fundamental misconception and common
|
|
confusion about GPLv2\@. Because of the prevalence of proprietary software,
|
|
most users, programmers, and lawyers alike tend to be more familiar with
|
|
EULAs. EULAs are believed by their authors to be contracts, requiring
|
|
formal agreement between the licensee and the software distributor to be
|
|
valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap''
|
|
as mechanisms to perform acceptance ceremonies with EULAs.
|
|
|
|
The GPL does not need contract law to ``transfer rights.'' Usually, no rights
|
|
are transferred between parties. By contrast, the GPL is primarily a permission
|
|
slip to undertake activities that would otherwise have been prohibited
|
|
by copyright law. As such, GPL needs no acceptance ceremony; the
|
|
licensee is not even required to accept the license.
|
|
|
|
However, without the GPL, the activities of copying, modifying and
|
|
distributing the software would have otherwise been prohibited. So, the
|
|
GPL says that you only accepted the license by undertaking activities that
|
|
you would have otherwise been prohibited without your license under GPL\@.
|
|
This is a certainly subtle point, and requires a mindset quite different
|
|
from the contractual approach taken by EULA authors.
|
|
|
|
An interesting side benefit to GPLv2~\S5 is that the bulk of users of Free
|
|
Software are not required to accept the license. Undertaking fair and
|
|
unregulated use of the work, for example, does not bind you to the GPL,
|
|
since you are not engaging in activity that is otherwise controlled by
|
|
copyright law. Only when you engage in those activities that might have an
|
|
impact on the freedom of others does license acceptance occur, and the
|
|
terms begin to bind you to fair and equitable sharing of the software. In
|
|
other words, the GPL only kicks in when it needs to for the sake of
|
|
freedom.
|
|
|
|
While GPL is by default a copyright license, it is certainly still possible
|
|
to consider GPL as a contract as well. For example, some distributors chose
|
|
to ``wrap'' their software in an acceptance ceremony to the GPL, and nothing in
|
|
the GPL prohibits that use. Furthermore, the ruling in \textit{Jacobsen
|
|
v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008)} indicates that \textbf{both}
|
|
copyright and contractual remedies may be sought by a copyright holder
|
|
seeking to enforce a license designed to uphold software freedom.
|
|
|
|
% FIXME-LATER: Write this
|
|
|
|
%\section{Using GPL Both as a Contract and Copyright License}
|
|
|
|
\section{GPLv2~\S6: GPL, My One and Only}
|
|
\label{GPLv2s6}
|
|
|
|
A point that was glossed over in Section~\ref{GPLv2s4}'s discussion of GPLv2~\S4
|
|
was the irrevocable nature of the GPL\@. The GPLv2 is indeed irrevocable,
|
|
and it is made so formally by GPLv2~\S6.
|
|
|
|
The first sentence in GPLv2~\S6 ensures that as software propagates down the
|
|
distribution chain, that each licensor can pass along the license to each
|
|
new licensee. Under GPLv2~\S6, the act of distributing automatically grants a
|
|
license from the original licensor to the next recipient. This creates a
|
|
chain of grants that ensure that everyone in the distribution has rights
|
|
under the GPLv2\@. In a mathematical sense, this bounds the bottom ---
|
|
making sure that future licensees get no fewer rights than the licensee before.
|
|
|
|
The second sentence of GPLv2~\S6 does the opposite; it bounds from the top. It
|
|
prohibits any licensor along the distribution chain from placing
|
|
additional restrictions on the user. In other words, no additional
|
|
requirements may trump the rights and freedoms given by GPLv2\@.
|
|
|
|
The final sentence of GPLv2~\S6 makes it abundantly clear that no individual
|
|
entity in the distribution chain is responsible for the compliance of any
|
|
other. This is particularly important for noncommercial users who have
|
|
passed along a source offer under GPLv2~\S3(c), as they cannot be assured that
|
|
the issuer of the offer will honor their GPLv2~\S3 obligations.
|
|
|
|
In short, GPLv2~\S6 says that your license for the software is your one and
|
|
only copyright license allowing you to copy, modify and distribute the
|
|
software.
|
|
|
|
GPLv2~\S6 is GPLv2's ``automatic downstream licensing''
|
|
provision\footnote{This section was substantially expanded for clarity and
|
|
detail in \hyperref[GPLv3s10]{GPLv3~\S10}.}. Each time you
|
|
redistribute a GPL'd program, the recipient automatically receives a license
|
|
from each original licensor to copy, distribute or modify the program subject
|
|
to the conditions of the license. The redistributor need not take any
|
|
to ensure the downstream recipient's acceptance of the license terms.
|
|
This places every copyright holder in the chain of descent of the code
|
|
in legal privity, or direct relationship, with every downstream
|
|
redistributor. Two legal effects follow. First, downstream parties
|
|
who remain in compliance have valid permissions for all actions
|
|
(including modification and redistribution) even if their immediate upstream
|
|
supplier of the software has been terminated for license
|
|
violation\footnote{\label{German-reinstatement-footnote} While this is legally true, as a practical matter, a
|
|
failure of ``complete, corresponding source'' (CCS) provisioning by an
|
|
upstream could make it effectively impossible for a downstream party to
|
|
engage in a commercial redistribution pursuant to
|
|
\hyperref[GPLv2s3]{GPLv2~\S3(a--b)}. (\S~\ref{upstream} in the Compliance
|
|
Guide portion of this tutorial discussed related details.)}.
|
|
Downstream's
|
|
licensed rights are not dependent on compliance of their upstream, because
|
|
their licenses issue directly from the copyright holder. Second, automatic
|
|
termination cannot be cured by obtaining additional copies from an alternate
|
|
supplier: the license permissions emanate only from the original licensors,
|
|
and if they have automatically terminated permission, no act by any
|
|
intermediate license holder can restore those terminated
|
|
rights\footnote{While nearly all attorneys and copyleft theorists are in
|
|
agreement on this point, German copyleft legal expert
|
|
\href{http://www.jbb.de/en/attorneys/till-jaeger/}{Till Jaeger}
|
|
vehemently disagrees. Jaeger's position is as follows: under German
|
|
copyright law, a new copy of GPL'd software is a ``fresh'' license under
|
|
GPL, and if compliance continues from that point further, the violator's
|
|
permissions under copyright law are automatically restored, notwithstanding
|
|
the strict termination provision in \hyperref[GPLv2s4]{GPLv2~\S4}.
|
|
However, in
|
|
practice, this issue is only salient with regard to \hyperref[Proprietary
|
|
Relicensing]{proprietary relicensing} business models, since other copyright
|
|
holders typically formally restore distributions rights once the only
|
|
remaining compliance issue is ``you lost copyright permission due to
|
|
GPLv2~\S4''. Therefore, the heated debates, which have raged between
|
|
Jaeger and almost everyone else in the copyleft community for nearly a
|
|
decade, regard an almost moot and wholly esoteric legal detail.}.
|
|
|
|
\section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''}
|
|
\label{GPLv2s7}
|
|
|
|
In essence, GPLv2~\S7 is a verbosely worded way of saying for non-copyright
|
|
systems what GPLv2~\S6 says for copyright. If there exists any reason that a
|
|
distributor knows of that would prohibit later licensees from exercising
|
|
their full rights under GPL, then distribution is prohibited.
|
|
|
|
Originally, this was designed as the title of this section suggests --- as
|
|
a last ditch effort to make sure that freedom was upheld. However, in
|
|
modern times, it has come to give much more. Now that the body of GPL'd
|
|
software is so large, patent holders who would want to be distributors of
|
|
GPL'd software have a tough choice. They must choose between avoiding
|
|
distribution of GPL'd software that exercises the teachings of their
|
|
patents, or grant a royalty-free, irrevocable, non-exclusive license to
|
|
those patents. Many companies have chosen the latter.
|
|
|
|
Thus, GPLv2~\S7 rarely gives software death by stopping its distribution.
|
|
Instead, it is inspiring patent holders to share their patents in the same
|
|
freedom-defending way that they share their copyrighted works.
|
|
|
|
\section{GPLv2~\S8: Excluding Problematic Jurisdictions}
|
|
\label{GPLv2s8}
|
|
|
|
GPLv2~\S8 is rarely used by copyright holders. Its intention is that if a
|
|
particular country, say Unfreedonia, grants particular patents or allows
|
|
copyrighted interfaces (no country to our knowledge even permits those
|
|
yet), that the GPLv2'd software can continue in free and unabated
|
|
distribution in the countries where such controls do not exist.
|
|
|
|
As far as is currently known, GPLv2~\S8 has very rarely been formally used by
|
|
copyright holders. Admittedly, some have used GPLv2~\S8 to explain various
|
|
odd special topics of distribution (usually related in some way to
|
|
GPLv2~\S7). However, generally speaking, this section is not proven
|
|
particularly useful in the more than two decades of GPLv2 history.
|
|
|
|
Meanwhile, despite many calls by the FSF (and others) for those licensors who
|
|
explicitly use this section to come forward and explain their reasoning, no
|
|
one ever did. Furthermore, research conducted during the GPLv3 drafting
|
|
process found exactly one licensor who had invoked this section to add an
|
|
explicit geographical distribution limitation, and the reasoning for that one
|
|
invocation was not fitting with FSF's intended spirit of GPLv2~\S8. As such,
|
|
GPLv2~\S8 was not included at all in GPLv3.
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\chapter{Odds, Ends, and Absolutely No Warranty}
|
|
|
|
GPLv2~\S\S0--7 constitute the freedom-defending terms of the GPLv2. The remainder
|
|
of the GPLv2 handles administrivia and issues concerning warranties and
|
|
liability.
|
|
|
|
\section{GPLv2~\S9: FSF as Stewards of GPL}
|
|
\label{GPLv2s9}
|
|
|
|
FSF reserves the exclusive right to publish future versions of the GPL\@;
|
|
GPLv2~\S9 expresses this. While the stewardship of the copyrights on the body
|
|
of GPL'd software around the world is shared among thousands of
|
|
individuals and organizations, the license itself needs a single steward.
|
|
Forking of the code is often regrettable but basically innocuous. Forking
|
|
of licensing is disastrous.
|
|
|
|
(Chapter~\ref{tale-of-two-copylefts} discusses more about the various
|
|
versions of GPL.)
|
|
|
|
\section{GPLv2~\S10: Relicensing Permitted}
|
|
\label{GPLv2s10}
|
|
|
|
GPLv2~\S10 reminds the licensee of what is already implied by the nature of
|
|
copyright law. Namely, the copyright holder of a particular software
|
|
program has the prerogative to grant alternative agreements under separate
|
|
copyright licenses.
|
|
|
|
\section{GPLv2~\S11: No Warranty}
|
|
\label{GPLv2s11}
|
|
|
|
Most warranty disclaimer language 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\footnote{(Ironically, most criticism of USA-specific legal
|
|
terminology in GPLv2's ``work based on the Program'' definition historically
|
|
came not primarily from readers outside the USA, but from those within
|
|
it. The FSF noted in that it did not generally agree with these
|
|
views, and expressed puzzlement by the energy with which they were
|
|
expressed, given the existence of many other, more difficult legal issues
|
|
implicated by the GPL. Nevertheless, the FSF argued that it made sense to
|
|
eliminate usage of local copyright terminology to good effect.}. GPLv2
|
|
always sought to cover all rights governed by relevant copyright law, in the
|
|
USA and elsewhere.
|
|
Even though differently-labeled concepts corresponding to the
|
|
derivative work are recognized in all copyright law systems, these
|
|
counterpart concepts might differ to some degree in scope and breadth from
|
|
the USA derivative work. GPLv3 therefore takes the task of
|
|
internationalizing the license further by removing references to derivative
|
|
works and by providing a more globally useful definition.
|
|
GPLv3 drops all reference to USA ``derivative works'' and returns
|
|
to the base concept only: GPL covers the licensed work and all works where
|
|
copyright permission from the licensed work's copyright holder.
|
|
|
|
The new definitions returns to the common elements of copyright law. Copyright
|
|
holders of works of software have the exclusive right to form new works by
|
|
modification of the original --- a right that may be expressed in various
|
|
ways in different legal systems. GPLv3 operates to grant this right to
|
|
successive generations of users (particularly through the copyleft conditions
|
|
set forth in GPLv3~\S5, as described later in this tutorial in its
|
|
\S~\ref{GPLv3s5}). Here in GPLv3~\S0, ``modify'' refers to basic copyright
|
|
rights, and then this definition of ``modify'' is used to define ``modified
|
|
version of'' and ``work based on'' as synonyms.
|
|
|
|
\subsection{The Covered Work}
|
|
|
|
GPLv3 uses a common license drafting technique of building upon simpler
|
|
definitions to make complex ones. The Program is a defined term found
|
|
throughout GPLv2, and the word ``covered'' and the phrase ``covered by this
|
|
license'' are used in tandem with the Program in GPLv2, but not as part of a
|
|
definition. GPLv3 offers a single term ``covered work'', which enables some
|
|
of the wording in GPLv3 to be simpler and clearer than its GPLv2
|
|
counterparts.
|
|
|
|
Next, to avoid locking GPLv3 into specific copyright statues, the GPLv3
|
|
defines two terms that are otherwise exotic to the language of international
|
|
copyright.
|
|
|
|
\subsection{Propagate}
|
|
|
|
To ``propagate'' a work covered by the license means any activity in a locale
|
|
that requires permission of copyright holders in that locale's legal system.
|
|
However, personal use or modification for personal use are activities explicitly
|
|
excluded from ``propagation'' \textit{regardless} of domestic copyright law.
|
|
|
|
The term ``propagate'' serves two purposes. First, ``propagate'' provides a
|
|
simple and convenient means for distinguishing between the kinds of uses of a
|
|
work that GPL imposes conditions on and the kinds of uses that GPL does not
|
|
(for the most part) impose conditions on.
|
|
|
|
Second, ``propagate'' helps globalize GPL in its wording and effect:
|
|
``derivative work'' was in fact not the only term commonly used by local
|
|
copyright statutes. A term like ``distribute'' (or its equivalent in
|
|
languages other than English) is also used in several national copyright
|
|
statutes. Practical experience with GPLv2 revealed the awkwardness of using
|
|
the term ``distribution'' in a license intended for global use: the scope of
|
|
``distribution'' in the copyright context can differ from country to country.
|
|
The GPL never necessarily intended the specific meaning of ``distribution''
|
|
that exists under USA (or any other country's) copyright law.
|
|
|
|
Indeed, even within a single country and language, the term distribution may
|
|
be ambiguous; as a legal term of art, distribution varies significantly in
|
|
meaning among those countries that recognize it. For example, comments
|
|
during GPLv3's drafting process indicated that in at least one country,
|
|
distribution may not include network transfers of software but may include
|
|
interdepartmental transfers of physical copies within an organization.
|
|
Meanwhile, the copyright laws of many countries, as well as certain
|
|
international copyright treaties, recognize ``making available to the
|
|
public'' or ``communication to the public'' as one of the exclusive rights of
|
|
copyright holders.
|
|
|
|
Therefore, the GPLv3 defines the term ``propagate'' by reference to activities
|
|
that require permission under ``applicable copyright law'', but excludes
|
|
execution and private modification from the definition. GPLv3's definition
|
|
also gives examples of activities that may be included within ``propagation''
|
|
but it also makes clear that, under the copyright laws of a given country,
|
|
``propagation'' may include other activities as well.
|
|
|
|
Thus, propagation is defined by behavior, and not by categories drawn from
|
|
some particular national copyright statute. This helps not only with
|
|
internationalization, but also factually-based terminology aids in
|
|
developers' and users' understanding of the GPL\@.
|
|
|
|
As a further benefit, because ``propagation'' includes all
|
|
exclusive rights granted under any particular copyright regime, the term
|
|
automatically accounts for all exclusive rights under that regime.
|
|
|
|
\subsection{Convey}
|
|
|
|
Next, GPLv3 defines a subset of propagate --- ``convey''.
|
|
Conveying includes activities that constitute propagation of copies to
|
|
others. As with the definition of propagate, GPLv3 thus addresses transfers
|
|
of copies of software in behavioral rather than statutory terms.
|
|
Any propagation that enables other parties to receive or make copies of the
|
|
work, is called ``conveying''. Usually, conveying is the activity that
|
|
triggers most of the other obligations of GPLv3.
|
|
|
|
\subsection{Appropriate Legal Notices}
|
|
|
|
GPLv2 used the term ``appropriate copyright notice and disclaimer of
|
|
warranty'' in two places, which is a rather bulk term. Also, experience with
|
|
GPLv2 and other licenses that grant software freedom showed throughout the
|
|
1990s that the scope of types of notices that need preservation upon
|
|
conveyance were more broad that merely the copyright notices. The
|
|
Appropriate Legal Notice definition consolidates the material that GPLv2
|
|
traditionally required preserved into one definition.
|
|
|
|
\subsection{Other Defined Terms}
|
|
|
|
Note finally that not all defined terms in GPLv3 appear in GPLv3~\S0.
|
|
Specifically, those defined terms that are confined in use to a single
|
|
section are defined in the section in which they are used, and GPLv3~\S1
|
|
contains those definitions focused on source code. In this tutorial, those
|
|
defined terms are discussed in the section where they are defined and/or
|
|
used.
|
|
|
|
\section{GPLv3~\S1: Understanding CCS}
|
|
\label{GPLv3s1}
|
|
|
|
Ensuring that users have the source code to the software they receive and the
|
|
freedom to modify remains the paramount right embodied in the Free Software
|
|
Definition (found in \S~\ref{Free Software Definition} of this tutorial). As
|
|
such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it
|
|
contains all the defined terms related to this important software freedom.
|
|
|
|
\subsection{Source Code Definition}
|
|
|
|
First, GPLv3~\S1 retains GPLv2's definition of ``source code'' and adds an
|
|
explicit definition of ``object code'' as ``any non-source version of a
|
|
work''. Object code is not restricted to a narrow technical meaning and is
|
|
understood broadly to include any form of the work other than the preferred
|
|
form for making modifications to it. Object code therefore includes any kind
|
|
of transformed version of source code, such as bytecode or minified
|
|
Javascript. The definition of object code also ensures that licensees cannot
|
|
escape their obligations under the GPL by resorting to shrouded source or
|
|
obfuscated programming.
|
|
|
|
\subsection{CCS Definition}
|
|
\label{CCS Definition}
|
|
|
|
The definition of CCS\footnote{Note that the preferred term for those who
|
|
work regularly with both GPLv2 and GPLv3 is ``Complete Corresponding
|
|
Source'', abbreviated to ``CCS''. Admittedly, the word ``complete'' no
|
|
longer appears in GPLv3 (which uses the word ``all'' instead). However,
|
|
both GPLv2 and the early drafts of GPLv3 itself used the word ``complete'',
|
|
and early GPLv3 drafts even called this defined term ``Complete
|
|
Corresponding Source''. Meanwhile, use of the acronym ``CCS'' (sometimes,
|
|
``C\&CS'') was so widespread among GPL enforcers that its use continues
|
|
even though GPLv3-focused experts tend to say just the defined term of
|
|
``Corresponding Source''.}, or, as GPLv3 officially calls it,
|
|
``Corresponding Source'' in GPLv3~\S1\P4 is possibly the most complex
|
|
definition in the license.
|
|
|
|
The CCS definition is broad so as to protect users' exercise of their rights
|
|
under the GPL\@. The definition includes with particular examples to remove
|
|
any doubt that they are to be considered CCS\@. GPLv3 seeks to make it
|
|
completely clear that a licensee cannot avoid complying with the requirements
|
|
of the GPL by dynamically linking a subprogram component to the original
|
|
version of a program. The example also clarifies that the shared libraries
|
|
and dynamically linked subprograms that are included in Corresponding Source
|
|
are those that the work is ``specifically'' designed to require, which
|
|
clarifies that they do not include libraries invoked by the work that can be
|
|
readily substituted by other existing implementations. While copyleft
|
|
advocates never doubted this was required under GPLv2's definition of CCS,
|
|
GPLv3 makes it abundantly clear with an extra example.
|
|
|
|
The GPL, as always, seeks to ensure users are truly in a position to install and
|
|
run their modified versions of the program; the CCS definition is designed to
|
|
be expansive to ensure this software freedom. However, although the
|
|
definition of CCS is expansive, it is not sufficient to protect users'
|
|
freedoms in many circumstances. For example, a GPL'd program, or a modified
|
|
version of such a program, might be locked-down and restricted. The
|
|
requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this
|
|
tutorial) handle that issue. (Early drafts of GPLv3 included those
|
|
requirements in the definition of CCS; however, given that the lock-down
|
|
issue only comes up in distribution of object code, it is more logical to
|
|
place those requirements with the parts of GPLv3 dealing directly with object
|
|
code distribution).
|
|
|
|
The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does
|
|
not require source that can be automatically generated. Many code
|
|
generators, preprocessors and take source code as input and sometimes even
|
|
have output that is still source code. Source code should always be whatever
|
|
the original programmer preferred to modify.
|
|
|
|
GPLv3\S1's final paragraph removes any ambiguity about what should be done on
|
|
source-only distributions. Specifically, the right to convey source code
|
|
that does not compile, does not work, or otherwise is experimental
|
|
in-progress work is fully permitted, \textit{provided that} no object code
|
|
form is conveyed as well. Indeed, when combined with the permissions in
|
|
GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can
|
|
never be required to provide more than that. One always has the right to
|
|
modify a source code work by deleting any part of it, and there can be no
|
|
requirement that free software source code be a whole functioning program.
|
|
|
|
\subsection{The System Library Exception}
|
|
\label{GPLv3-system-library-exception}
|
|
|
|
The previous section skipped over one part of the CCS definition, the
|
|
so-called system library exception. The ``System Libraries'' definition (and
|
|
the ``Standard Interface'' and ``Major Component'' definitions, which it
|
|
includes) are designed as part
|
|
to permit certain distribution arrangements that are considered reasonable by
|
|
copyleft advocates. The system library exception is designed to allow
|
|
copylefted software to link with these libraries when prohibition of that linking would hurt
|
|
software freedom more than it would hurt proprietary software.
|
|
|
|
The system library exception has two parts. Part (a) rewords the GPLv2
|
|
exception for clarity replacing GPLv2's words ``unless that component itself
|
|
accompanies the executable'' with ``which is not part of the Major
|
|
Component''. The goal here is to not require disclosure of source code of
|
|
certain libraries, such as necessary Microsoft Windows DLLs (which aren't
|
|
part of Windows' kernel but accompany it) that are required for functioning
|
|
of copylefted programs compiled for Windows.
|
|
|
|
However, in isolation, (a) would be too permissive, as it would sometimes
|
|
allowing distributors to evade important GPL requirements. Part (b) reigns
|
|
in (a). Specifically, (b) specifies only a few functionalities that a
|
|
system library may provide and still qualify for the exception. The goal is
|
|
to ensure system libraries are truly adjunct to a major essential operating
|
|
system component, compiler, or interpreter. The more low-level the
|
|
functionality provided by the library, the more likely it is to be qualified
|
|
for this exception.
|
|
|
|
Admittedly, the system library exception is a frequently discussed topic of
|
|
obsessed GPL theorists. The amount that has been written on the system
|
|
library exception (both the GPLv2 and GPLv3 versions of it), if included
|
|
herein, could easily increase this section of the tutorial to a length
|
|
greater than all the others.
|
|
|
|
Like any exception to the copyleft requirements of GPL, would-be GPL
|
|
violators frequently look to the system library exception as a potential
|
|
software freedom circumvention technique. When considering whether or not a
|
|
library qualifies for the system library exception, here is a pragmatic
|
|
thesis to consider, based on the combined decades of experience in GPL
|
|
interpretation of this tutorial's authors: the harder and more strained the
|
|
reader must study and read the system library exception, the more likely it
|
|
is that the library in question does not qualify for it.
|
|
|
|
\section{GPLv3~\S2: Basic Permissions}
|
|
\label{GPLv3S2}
|
|
|
|
GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed
|
|
in \S~\ref{GPLv2s0} of this tutorial). However, the usual style of
|
|
improvements found in GPLv3 are found here as well. For example, the first
|
|
sentence of GPLv3~\S2 furthers the goal internationalization. Under the
|
|
copyright laws of some countries, it may be necessary for a copyright license
|
|
to include an explicit provision setting forth the duration of the rights
|
|
being granted. In other countries, including the USA, such a provision is
|
|
unnecessary but permissible.
|
|
|
|
GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of
|
|
copyright fair use, or the equivalent under applicable law. These rights are
|
|
compatible with, and not in conflict with, the freedoms that the GPL seeks to
|
|
protect, and the GPL cannot and should not restrict them.
|
|
|
|
However, note that (sadly to some copyleft advocates) the unlimited freedom
|
|
to run is confined to the \textit{unmodified} Program. This confinement is
|
|
unfortunately necessary since Programs that do not qualify as a User Product
|
|
in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain
|
|
unfortunate restrictions on the freedom to run.\footnote{See
|
|
\S~\ref{freedom-to-run} of this tutorial for the details on ``the freedom to
|
|
run''.}
|
|
|
|
GPLv3~\S2\P2 distinguishes between activities of a licensee that are
|
|
permitted without limitation and activities that trigger additional
|
|
requirements. Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of
|
|
privately modifying and running the program. While these basic freedoms were
|
|
generally considered a standard part of users' rights under GPLv2 as well,
|
|
the GPLv3 states them herein more explicitly. In other words, there is no
|
|
direct analog to the first sentence of GPLv3~\S2\P2 in GPLv2
|
|
(See \S~\ref{gplv2-private-modification} of this tutorial for more on this issue.)
|
|
|
|
Also, GPLv3~\S2\P2 gives an explicit permission for a client to provide a
|
|
copy of its modified software to a contractor exclusively for that contractor
|
|
to modify it further, or run it, on behalf of the client. However, the
|
|
client can \textit{only} exercise this control over its own copyrighted
|
|
changes to the GPL-covered program. The parts of the program it obtained
|
|
from other contributors must be provided to the contractor with the usual GPL
|
|
freedoms. Thus, GPLv3 permits users to convey covered works to contractors
|
|
operating exclusively on the users' behalf, under the users' direction and
|
|
control, and to require the contractors to keep the users' copyrighted
|
|
changes confidential, but \textit{only if} the contractor is limited to acting
|
|
on the users' behalf (just as the users' employees would have to act).
|
|
|
|
The strict conditions in this ``contractors provision'' are needed so that it
|
|
cannot be twisted to fit other activities, such as making a program available
|
|
to downstream users or customers. By making the limits on this provision
|
|
very narrow, GPLv3 ensures that, in all other cases, contractor gets the
|
|
full freedoms of the GPL that they deserve.
|
|
|
|
The FSF was specifically asked to add this ``contractors provisions'' by
|
|
large enterprise users of Free Software, who often contract with non-employee
|
|
developers, working offsite, to make modifications intended for the user's
|
|
private or internal use, and often arrange with other companies to operate
|
|
their data centers. Whether GPLv2 permits these activities is not clear and
|
|
may depend on variations in copyright law in different jurisdictions. The
|
|
practices seem basically harmless, so FSF decided to make it clear they are
|
|
permitted.
|
|
|
|
GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing.
|
|
This provision ensures that GPL enforcement is always by the copyright
|
|
holder. Usually, sublicensing is regarded as a practical convenience or
|
|
necessity for the licensee, to avoid having to negotiate a license with each
|
|
licensor in a chain of distribution. The GPL solves this problem in another
|
|
way --- through its automatic licensing provision found in GPLv3~\S10 (which
|
|
is discussed in more detail in \S~\ref{GPLv3s10} of this tutorial).
|
|
|
|
\section{GPLv3's views on DRM and Device Lock-Down}
|
|
\label{GPLv3-drm}
|
|
|
|
The issues of DRM, device lock-down and encryption key disclosure were the
|
|
most hotly debated during the GPLv3 process. FSF's views on this were sadly
|
|
frequently misunderstood and, comparing the provisions related to these
|
|
issues in the earliest drafts of GPLv3 to the final version of GPLv3 shows
|
|
the FSF's willingness to compromise on tactical issues to reach the larger
|
|
goal of software freedom.
|
|
|
|
Specifically, GPLv3 introduced provisions that respond to the growing
|
|
practice of distributing GPL-covered programs in devices that employ
|
|
technical means to restrict users from installing and running modified
|
|
versions. This practice thwarts the expectations of developers and users
|
|
alike, because the right to modify is one of the core freedoms the GPL is
|
|
designed to secure.
|
|
|
|
Technological measures to defeat users' rights. These measures are often
|
|
described by such Orwellian phrases, such as ``digital rights management,''
|
|
which actually means limitation or outright destruction of users' legal
|
|
rights, or ``trusted computing,'' which actually means selling people
|
|
computers they cannot trust. However, these measures are alike in one basic
|
|
respect. They all employ technical means to turn the system of copyright law
|
|
(where the powers of the copyright holder are limited exceptions to general
|
|
freedom) into a virtual prison, where everything not specifically permitted
|
|
is utterly forbidden. This system of ``para-copyright'' was created well
|
|
after GPLv2 was written --- initially through legislation in the USA and the
|
|
EU, and later in other jurisdictions as well. This legislation creates
|
|
serious civil or even criminal penalties to escape from these restrictions
|
|
(commonly and aptly called ``jail-breaking a device''), even where the
|
|
purpose in doing so is to restore the users' legal rights that the technology
|
|
wrongfully prevents them from exercising.
|
|
|
|
GPLv2 did not address the use of technical measures to take back the rights
|
|
that the GPL granted, because such measures did not exist in 1991, and would
|
|
have been irrelevant to the forms in which software was then delivered to
|
|
users. GPLv3 addresses these issues, particularly because copylefted
|
|
software is ever more widely embedded in devices that impose technical
|
|
limitations on the user's freedom to change it.
|
|
|
|
However, FSF always made a clear distinction to avoid conflating these
|
|
``lock-down'' measures with legitimate applications that give users control,
|
|
as by enabling them to choose higher levels of system or data security within
|
|
their networks, or by allowing them to protect the security of their
|
|
communications using keys they can generate or copy to other devices for
|
|
sending or receiving messages. Such technologies present no obstacles to
|
|
software freedom and the goals of copyleft.
|
|
|
|
The public GPLv3 drafting process sought to balance these positions of
|
|
copyleft advocates with various 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}
|
|
|
|
GPLv3~\S6 states the compliance obligations for distributing ``non-source
|
|
forms'' of a program (which means any form other than CCS). As noted in \S~\ref{GPLv3s0}, ``object code'' in GPLv3
|
|
is defined broadly to mean any non-source version of a work, and thus
|
|
includes not only binaries or executables, but also obfuscated, minimized, compressed or otherwise
|
|
non-preferred forms for modification. Thus, GPLv3~\S6 clarifies and revises GPLv2~\S3.
|
|
Indeed, GPLv3~\S6's CCS requirement under
|
|
closely parallels the provisions of \hyperref[GPLv2s3]{GPLv2~\S3}, with changes
|
|
designed to make compliant provisioning easier under contemporary
|
|
technological conditions. Distributors of GPLv3'd
|
|
object code must provide access to the corresponding source code, in one of
|
|
four specified ways.
|
|
|
|
% FIXME: probably mostly still right, needs some updates, though.
|
|
|
|
GPLv3~\S6(a--b) now apply specifically to distribution of object code in a
|
|
physical product. Physical products include embedded systems, as well as
|
|
physical software distribution media such as CDs. As in GPLv2~\S3 (discussed
|
|
in \S~\ref{GPLv2s3} of this tutorial), the distribution of object code may
|
|
either be accompanied by the machine-readable source code, or it may be
|
|
accompanied by a valid written offer to provide the machine-readable source
|
|
code. However, unlike in GPLv2, that offer cannot be exercised by any third
|
|
party; rather, only those ``who possess the object code'' can exercise
|
|
the offer. (Note that this is a substantial narrowing of requirements of
|
|
offer fulfillment, and is a wonderful counterexample to dispute claims that
|
|
the GPLv3 has more requirements than GPLv2.)
|
|
|
|
% FIXME: probably mostly still right, needs some updates, though.
|
|
|
|
GPLv3~\S6(b) further revises the requirements for the written offer to
|
|
provide source code. As before, the offer must remain valid for at least
|
|
three years. In addition, even after three years, a distributor of a product
|
|
containing GPL'd object code must offer to provide source code for as long as
|
|
the distributor also continues to offer spare parts or customer support for
|
|
the product model. This is a reasonable and appropriate requirement; a
|
|
distributor should be prepared to provide source code if he or she is
|
|
prepared to provide support for other aspects of a physical product.
|
|
|
|
GPLv3~\S6(a--b) clarifies that the medium for software interchange on which
|
|
the machine-readable source code is provided must be a durable physical
|
|
medium. GPLv3~\S6(b)(2), however, permits a distributor to instead offer to
|
|
provide source code from a network server instead, which is yet another
|
|
example GPLv3 looser in its requirements than GPLv2 (see
|
|
\S~\ref{GPLv2s3-medium-customarily} for details).
|
|
|
|
% FIXME-LATER: more information about source provision, cost of physically
|
|
% performing, reasonable fees, medium customary clearly being said durable
|
|
% connecting back to previous text
|
|
|
|
GPLv3\S6(c) gives narrower permission than GPLv2\S3(c). The ``pass along''
|
|
option for GPLv3\S6(c)(1) offers is now available only for individual
|
|
distribution of object code; moreover, such individual distribution can occur
|
|
only ``occasionally and noncommercially.'' A distributor cannot comply with
|
|
the GPL merely by making object code available on a publicly-accessible
|
|
network server accompanied by a copy of the written offer to provide source
|
|
code received from an upstream distributor.
|
|
|
|
%FIXME-LATER: tie back to the discussion of the occasional offer pass along
|
|
% stuff in GPLv2 this tutorial.
|
|
|
|
GPLv3~\S6(d) revises and improves GPLv2~\S3's final paragraph. When object
|
|
code is provided by offering access to copy the code from a designated place
|
|
(such as by enabling electronic access to a network server), the distributor
|
|
must merely offer equivalent access to copy the source code ``in the same way
|
|
through the same place''. This wording also permits a distributor to offer a
|
|
third party access to both object code and source code on a single network
|
|
portal or web page, even though the access may include links to different
|
|
physical servers. For example, a downstream distributor may provide a link
|
|
to an upstream distributor's server and arrange with the operator of that
|
|
server to keep the source code available for copying for as long as the
|
|
downstream distributor enables access to the object code. Thus,
|
|
the obligation remains on the party distributing object code to point
|
|
prominently (``next to'' the object code download) to the third-party source
|
|
code provisioning server, and to ensure that this third-party server remains
|
|
in operation for required period. This codifies formally the typical
|
|
historical interpretation of GPLv2.
|
|
|
|
% FIXME-LATER: perhaps in enforcement section, but maybe here, note about
|
|
% ``slow down'' on source downloads being a compliance problem.
|
|
|
|
Furthermore, under GPLv3~\S6(d), distributors may charge for the conveyed
|
|
object code; however, those who pay to obtain the object code must be given
|
|
equivalent and gratis access to obtain the CCS. (If distributors convey the
|
|
object code gratis, distributors must likewise make CCS available without
|
|
charge.) Those who do not obtain the object code from that distributors
|
|
(perhaps because they choose not to pay the fee for object code) are outside
|
|
the scope of the provision; distributors are under no specific obligation to
|
|
give CCS to someone who has not purchased an object code download under
|
|
GPLv3~\S6(d). (Note: this does not change nor impact any obligations under
|
|
GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)
|
|
|
|
\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}
|
|
|
|
GPLv3~\S6(e) allows provision of CCS via another server when the binary or
|
|
other non-source form is distributed by peer-to-peer protocols such as
|
|
BitTorrent. Here the requirement is only that each peer be effectively
|
|
informed of the location of the source code on a server as above.
|
|
|
|
GPLv3 really did require this addition, even though it adds complexity to
|
|
a key section of GPL\@. In particular,
|
|
Decentralized peer-to-peer file sharing present a challenge
|
|
to the unidirectional view of distribution that is implicit in GPLv2 and
|
|
initial drafts of GPLv3. Identification of an upstream/downstream link in
|
|
BitTorrent distribution is neither straightforward nor reasonable; such
|
|
distribution is multidirectional, cooperative and (somewhat) anonymous. In peer-to-peer
|
|
distribution systems, participants act both as transmitters and recipients of
|
|
blocks of a particular file, but they perceive the experience merely as users
|
|
and receivers, and not as distributors in any conventional sense. At any
|
|
given moment of time, most peers will not have the complete file.
|
|
|
|
Meanwhile, GPLv3~\S6(d) permits distribution of a work in object code form
|
|
over a network, provided that the distributor offers equivalent access to
|
|
copy the Corresponding Source Code ``in the same way through the same
|
|
place''. This wording might be interpreted to permit peer-to-peer
|
|
distribution of binaries \textit{if} they are packaged together with the CCS,
|
|
but such packaging is impractical, for at least three reasons. First, even if
|
|
the CCS is packaged with the object code, it will only be available to a
|
|
non-seeding peer at the end of the distribution process, but the peer will
|
|
already have been providing parts of the binary to others in the network.
|
|
Second, in practice, peer-to-peer forms of transmission are poorly suited
|
|
means for distributing CCS. In large distributions, packaging CCS with the
|
|
object code may result in a substantial increase in file size and
|
|
transmission time. Third, in current practice, CCS packages themselves tend
|
|
\textit{not} to be transmitted through BitTorrent --- owing to reduced demand
|
|
-- thus, there generally will be too few participants downloading the same
|
|
source package at the same time to enable effective seeding and distribution.
|
|
|
|
GPLv3~\S6(e) addresses these issues. If a licensee conveys such a work of
|
|
object code using peer-to-peer transmission, that licensee is in compliance
|
|
with GPLv3~\S6 if the licensee informs other peers where the object code and
|
|
its CCS are publicly available at no charge under subsection GPLv3~\S6(d).
|
|
The CCS therefore need not be provided through the peer-to-peer system that
|
|
was used for providing the binary.
|
|
|
|
Second, GPLv3\S9 also clarifies that ancillary propagation of a covered work
|
|
that occurs as part of the process of peer-to-peer file transmission does not
|
|
require acceptance, just as mere receipt and execution of the Program does
|
|
not require acceptance. Such ancillary propagation is permitted without
|
|
limitation or further obligation.
|
|
|
|
% FIXME-LATER: Would be nice to explain much more about interactions between
|
|
% the various options of GPLv3~\S6(a-e), which might all be in play at once!
|
|
|
|
\subsection{User Products, Installation Information and Device Lock-Down}
|
|
|
|
As discussed in \S~\ref{GPLv3-drm} of this tutorial, GPLv3 seeks to thwart
|
|
technical measures such as signature checks in hardware to prevent
|
|
modification of GPL'd software on a device.
|
|
|
|
To address this issue, GPLv3~\S6 requires that parties distributing object
|
|
code provide recipients with the source code through certain means. When
|
|
those distributors pass on the CCS, they are also required to pass on any
|
|
information or data necessary to install modified software on the particular
|
|
device that included it. (This strategy is not unlike that used in LGPLv2.1
|
|
to enable users to link proprietary programs to modified libraries.)
|
|
|
|
% FIXME-LATER: LGPLv2.1 section should talk about this explicitly and this
|
|
% should be a forward reference here
|
|
|
|
\subsubsection{User Products}
|
|
|
|
\label{user-product}
|
|
|
|
The scope of these requirements is narrow. GPLv3~\S6 introduces the concept
|
|
of a ``User Product'', which includes devices that are sold for personal,
|
|
family, or household use. Distributors are only required to provide
|
|
Installation Information when they convey object code in a User Product.
|
|
|
|
In brief, the right to convey object code in a defined class of ``User
|
|
Products,'' under certain circumstances, depends on providing whatever information
|
|
is required to enable a recipient to replace the object code with a functioning
|
|
modified version.
|
|
|
|
This was a compromise that was difficult for the FSF to agree to during the
|
|
GPLv3 drafting process. However, companies and governments that use
|
|
specialized or enterprise-level computer facilities reported that they
|
|
actually \textit{want} their systems not to be under their own control.
|
|
Rather than agreeing to this as a concession, or bowing to pressure, they ask
|
|
for this as a \textit{preference}. It is not clear that the GPL should interfere
|
|
here, since the main problem lies elsewhere.
|
|
|
|
While imposing technical barriers to modification is wrong regardless of
|
|
circumstances, the areas where restricted devices are of the greatest
|
|
practical concern today fall within the User Product definition. Most, if
|
|
not all, technically-restricted devices running GPL-covered programs are
|
|
consumer electronics devices. Moreover, the disparity in clout between the
|
|
manufacturers and these users makes it difficult for the users to reject
|
|
technical restrictions through their weak and unorganized market power. Even
|
|
limited to User Products, this provision addresses the fundamental problem.
|
|
|
|
% FIXME-LATER: link \href to USC 2301
|
|
|
|
The core of the User Product definition is a subdefinition of ``consumer
|
|
product'' adapted from the Magnuson-Moss Warranty Act, a federal
|
|
consumer protection law in the USA found in 15~USC~\S2301: ``any tangible
|
|
personal property which is normally used for personal, family, or household
|
|
purposes.'' The USA has had three decades of experience of liberal
|
|
judicial and administrative interpretation of this definition in a manner
|
|
favorable to consumer rights.\footnote{The Magnuson-Moss consumer product
|
|
definition itself has been influential in the USA and Canada, having been
|
|
adopted in several state and provincial consumer protection laws.}
|
|
Ideally, this body of interpretation\footnote{The FSF, however, was very
|
|
clear that incorporation of such legal interpretation was in no way
|
|
intended to work as a general choice of USA law for GPLv3.} will guide
|
|
interpretation of the consumer product subdefinition in GPLv3~\S6, and this
|
|
will hopefully provide a degree of legal certainty advantageous to device
|
|
manufacturers and downstream licensees alike.
|
|
|
|
One well-established interpretive principle under Magnuson-Moss is that
|
|
ambiguities are resolved in favor of coverage. That is, in cases where
|
|
it is not clear whether a product falls under the definition of consumer
|
|
product, the product will be treated as a consumer product.\footnote{16
|
|
CFR~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54
|
|
UCC~Rep.~Serv.2d 934 (D.~Ore.~2004).} Moreover, for a given product,
|
|
``normally used'' is understood to refer to the typical use of that type
|
|
of product, rather than a particular use by a particular buyer.
|
|
Products that are commonly used for personal as well as commercial
|
|
purposes are consumer products, even if the person invoking rights is a
|
|
commercial entity intending to use the product for commercial
|
|
purposes.\footnote{16 CFR \S \ 700.1(a). Numerous court decisions
|
|
interpreting Magnuson-Moss are in accord; see, e.g., \textit{Stroebner
|
|
Motors, Inc.~v.~Automobili Lamborghini S.p.A.}, 459 F.~Supp.2d 1028,
|
|
1033 (D.~Hawaii 2006).} Even a small amount of ``normal'' personal use
|
|
is enough to cause an entire product line to be treated as a consumer
|
|
product under Magnuson-Moss\footnote{\textit{Tandy Corp.~v.~Marymac
|
|
Industries, Inc.}, 213 U.S.P.Q.~702 (S.D.~Tex.~1981). In this case, the
|
|
court concluded that TRS-80 microcomputers were consumer products, where
|
|
such computers were designed and advertised for a variety of users,
|
|
including small businesses and schools, and had only recently been
|
|
promoted for use in the home.}.
|
|
|
|
However, Magnuson-Moss is not a perfect fit because in the area of components
|
|
of dwellings, the settled interpretation under Magnuson-Moss is under-inclusive.
|
|
Depending on how such components are manufactured or sold, they may or may
|
|
not be considered Magnuson-Moss consumer products.\footnote{Building
|
|
materials that are purchased directly by a consumer from a retailer, for
|
|
improving or modifying an existing dwelling, are consumer products under
|
|
Magnuson-Moss, but building materials that are integral component parts of
|
|
the structure of a dwelling at the time that the consumer buys the dwelling
|
|
are not consumer products. 16 C.F.R.~\S\S~700.1(c)--(f); Federal Trade
|
|
Commission, Final Action Concerning Review of Interpretations of
|
|
Magnuson-Moss Warranty Act, 64 Fed.~Reg.~19,700 (April 22, 1999); see also,
|
|
e.g., \textit{McFadden}, 54 U.C.C.~Rep.~Serv.2d at 934.} Therefore, GPLv3
|
|
defines User Products as a superset of consumer products that also includes
|
|
``anything designed or sold for incorporation into a dwelling.''
|
|
|
|
Thus, the three sentences in the center of GPLv3's User Product definition
|
|
encapsulate the judicial and administrative principles established over the
|
|
past three decades in the USA concerning the Magnuson-Moss consumer product
|
|
definition. First, it states that doubtful cases are resolved in favor of
|
|
coverage under the definition. Second, it indicate that the words ``normally
|
|
used'' in the consumer product definition refer to a typical or common use of
|
|
a class of product, and not the status of a particular user or expected or
|
|
actual uses by a particular user. Third, it clearly states that the
|
|
existence of substantial non-consumer uses of a product does not negate a
|
|
determination that it is a consumer product, unless such non-consumer uses
|
|
represent the only significant mode of use of that product.
|
|
|
|
It should be clear from these added sentences that it is the general mode of
|
|
use of a product that determines objectively whether or not it is a consumer
|
|
product. One could not escape the effects of the User Products provisions by
|
|
labeling what is demonstrably a consumer product in ways that suggest it is
|
|
``for professionals'', for example.
|
|
|
|
|
|
\subsubsection{Installation Information}
|
|
|
|
\label{GPLv3-installation-information}
|
|
|
|
With the User Products definition complete, The ``Installation Information''
|
|
definition uses that to define what those receiving object code inside a User
|
|
Product must receive.
|
|
|
|
Installation Information is information that is ``required to install and
|
|
execute modified versions of a covered work \dots from a modified version of
|
|
its'' CCS, in the same User Product for which the covered work is conveyed.
|
|
GPLv3 provides guidance concerning how much information must be provided: it
|
|
``must suffice to ensure that the continued functioning of the modified
|
|
object code is in no case prevented or interfered with solely because
|
|
modification has been made.'' For example, the information provided would be
|
|
insufficient if it enabled a modified version to run only in a disabled
|
|
fashion, solely because of the fact of modification (regardless of the actual
|
|
nature of the modification). The information need not consist of
|
|
cryptographic keys; Installation Information may be ``any methods,
|
|
procedures, authorization keys, or other information''.
|
|
|
|
Note that GPLv3 does not define ``continued functioning'' further. However,
|
|
GPLv3 does provide some additional guidance concerning the scope of
|
|
GPLv3-compliant action or inaction that distributors of
|
|
technically-restricted User Products can take with respect to a downstream
|
|
recipient who replaces the conveyed object code with a modified version.
|
|
First of all, GPLv3 makes clear that GPLv3 implies no obligation ``to
|
|
continue to provide support service, warranty, or updates'' for such a work.
|
|
|
|
Second, most technically-restricted User Products are designed to communicate
|
|
across networks. It is important for both users and network providers to
|
|
know when denial of network access to devices running modified versions
|
|
becomes a GPL violation. GPLv3 permits denial of access in two cases: ``when
|
|
the modification itself materially and adversely affects the operation of the
|
|
network,'' and when the modification itself ``violates the rules and
|
|
protocols for communication across the network''. The second case is
|
|
deliberately drawn in general terms, and it serves as a foundation for
|
|
reasonable enforcement policies that respect recipients' right to modify
|
|
while recognizing the legitimate interests of network providers.
|
|
|
|
Note that GPLv3 permits the practice of conveying object code in a mode not
|
|
practically susceptible to modification by any party, such as code burned in
|
|
ROM or embedded in silicon. The goal of the Installation Information
|
|
requirement is to ensure the downstream licensee receives the real right to
|
|
modify when the device manufacturer or some other party retains that right.
|
|
Accordingly, GPLv3\S6's ante-penultimate paragraph states that the
|
|
requirement to provide Installation Information ``does not apply if neither
|
|
you nor any third party retains the ability to install modified object code
|
|
on the User Product''.
|
|
|
|
Finally, GPLv3\S6 makes it clear that there is also no requirement to
|
|
provide warranty or support for the User Product itself.
|
|
|
|
\subsection{GPLv3~\S7: Additional Permissions}
|
|
\label{GPLv3s7}
|
|
|
|
The GPL is a statement of permissions, some of which have conditions.
|
|
Additional terms --- terms that supplement those of the GPL --- may come to be
|
|
placed on, or removed from, GPL-covered code in certain common ways.
|
|
Copyleft licensing theorists have generally called
|
|
those added terms ``additional permissions'' if they grant
|
|
exceptions from the conditions of the GPL, and ``additional requirements'' if
|
|
they add conditions to the basic permissions of the GPL\@. The treatment of
|
|
additional permissions and additional requirements under GPLv3 is necessarily
|
|
asymmetrical, because they do not raise the same interpretive
|
|
issues; in particular, additional requirements, if allowed without careful
|
|
limitation, could transform a GPL'd program into a non-free one.
|
|
|
|
Due to the latter fear, historically, GPLv2 did not permit any additional
|
|
requirements. However, over time,
|
|
many copyright holders generally tolerated certain types of benign additional requirements
|
|
merely through a ``failure to enforce'' estoppel-esque scenario. Therefore, GPLv3 allows
|
|
for some specific limited requirement variations that GPLv2 technically prohibits.
|
|
|
|
With these principles in the background, GPLv3~\S7 answers the following
|
|
questions:
|
|
\begin{enumerate}
|
|
\item How does the presence of additional terms on all or part of a GPL'd program
|
|
affect users' rights?
|
|
|
|
\item When and how may a licensee add terms to code being
|
|
distributed under the GPL?
|
|
|
|
\item When may a licensee remove additional terms?
|
|
\end{enumerate}
|
|
|
|
Additional permissions present the easier case. Since the mid-1990s,
|
|
permissive exceptions often appeared alongside GPLv2 to allow combination
|
|
with certain non-free code. Typically, downstream
|
|
stream recipients could remove those exceptions and operate under pure GPLv2.
|
|
Similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,
|
|
and it permits relicensing under the GPL\@.
|
|
|
|
These practices are now generalized via GPLv3~\S7.
|
|
A licensee may remove any additional permission from
|
|
a covered work, whether it was placed by the original author or by an
|
|
upstream distributor. A licensee may also add any kind of additional
|
|
permission to any part of a work for which the licensee has, or can give,
|
|
appropriate copyright permission. For example, if the licensee has written
|
|
that part, the licensee is the copyright holder for that part and can
|
|
therefore give additional permissions that are applicable to it.
|
|
Alternatively, the part may have been written by someone else and licensed,
|
|
with the additional permissions, to that licensee. Any additional
|
|
permissions on that part are, in turn, removable by downstream recipients.
|
|
As GPLv3~\S7\P1 explains, the effect of an additional permission depends on
|
|
whether the permission applies to the whole work or a part.
|
|
|
|
% FIXME-LATER: LGPLv3 will have its own section
|
|
|
|
Indeed, LGPLv3 is itself simply a list of additional permissions supplementing the
|
|
terms of GPLv3. GPLv3\S7 has thus provided the basis for recasting a
|
|
formally complex license as an elegant set of added terms, without changing
|
|
any of the fundamental features of the existing LGPL\@. LGPLv3 is thus a model for developers wishing to license their works under the
|
|
GPL with permissive exceptions. The removability of additional permissions
|
|
under GPLv3\S7 does not alter any existing behavior of the LGPL since the LGPL
|
|
has always allowed relicensing under the ordinary GPL\@.
|
|
|
|
\section{GPLv3~\S7: Understanding License Compatibility}
|
|
\label{license-compatibility}
|
|
|
|
A challenge that faced the Free Software community heavily through out the
|
|
early 2000s was the proliferation of incompatible Free Software licenses. Of
|
|
course, the GPL cannot possibly be compatible with all such licenses.
|
|
However, GPLv3
|
|
contains provisions that are designed to reduce license incompatibility by
|
|
making it easier for developers to combine code carrying non-GPL terms with
|
|
GPL'd code.
|
|
|
|
This license compatibility issue arises for
|
|
three reasons. First, the GPL is a strong copyleft license, requiring
|
|
modified versions to be distributed under the GPL\@. Second, the GPL states
|
|
that no further restrictions may be placed on the rights of recipients.
|
|
Third, all other software freedom respecting licenses in common use contain certain
|
|
requirements, many of which are not conditions made by the GPL\@. Thus, when
|
|
GPL'd code is modified by combination with code covered by another formal
|
|
license that specifies other requirements, and that modified code is then
|
|
distributed to others, the freedom of recipients may be burdened by
|
|
additional requirements in violation of the GPL. It can be seen that
|
|
additional permissions in other licenses do not raise any problems of license
|
|
compatibility.
|
|
|
|
GPLv3 took a new approach to the issue of combining GPL'd code with
|
|
code governed by the terms of other software freedom licenses. Traditional
|
|
GPLv2 license compatibility theory (which was not explicitly stated in GPLv2
|
|
itself, but treated as a license interpretation matter by the FSF) held that GPLv2 allowed such
|
|
combinations only if the non-GPL licensing terms permitted distribution under
|
|
the GPL and imposed no restrictions on the code that were not also imposed by
|
|
the GPL\@. In practice, the FSF historically supplemented that policy with a structure of
|
|
exceptions for certain kinds of combinations.
|
|
|
|
GPLv3~\S7 implements a more explicit policy on license
|
|
compatibility. It formalizes the circumstances under which a licensee may
|
|
release a covered work that includes an added part carrying non-GPL terms.
|
|
GPLv3~\S7 distinguish between terms that provide additional permissions, and terms that
|
|
place additional requirements on the code, relative to the permissions and
|
|
requirements established by applying the GPL to the code.
|
|
|
|
As discussed in the previous section of this tutorial, GPLv3~\S7 first and foremost explicitly allows added parts covered by terms with
|
|
additional permissions to be combined with GPL'd code. This codifies the
|
|
existing practice of regarding such licensing terms as compatible with the
|
|
GPL\@. A downstream user of a combined GPL'd work who modifies such an added
|
|
part may remove the additional permissions, in which case the broader
|
|
permissions no longer apply to the modified version, and only the terms of
|
|
the GPL apply to it.
|
|
|
|
In its treatment of terms that impose additional requirements, GPLv3\S7
|
|
extends the range of licensing terms with which the GPL is compatible. An
|
|
added part carrying additional requirements may be combined with GPL'd code,
|
|
but only if those requirements belong to an set enumerated in GPLv3\S7. There
|
|
are, of course, limits on the acceptable additional requirements, which
|
|
ensures that enhanced license compatibility does not
|
|
defeat the broader software-freedom-defending terms of the GPL\@. Unlike terms that grant
|
|
additional permissions, terms that impose additional requirements cannot be
|
|
removed by a downstream user of the combined GPL'd work, because only in the
|
|
pathological case\footnote{Theoretically, a user could collect copyright
|
|
assignment from all known contributors and then do this, but this would
|
|
indeed be the pathological case.} would a user have the right to do so.
|
|
|
|
In general, the types of additional requirements were those terms in regular
|
|
use by other non-copyleft Free Software licenses that the FSF found
|
|
unobjectionable. The specific details GPLv3's permitted additional
|
|
requirements hat GPLv3 are as follows:
|
|
|
|
\begin{enumerate}[label=7(\alph*):,ref=GPLv3s7\alph*]
|
|
|
|
\item This provision allows alternative ``disclaimer of warranty''
|
|
forms. Copyright holders can disclaim warranty or limit liability
|
|
differently from the terms as provided under GPLv3\S~\S15--16. Drafters
|
|
included this permission to advance the internationalization goals of
|
|
GPLv3; international treaties lack adequate harmonization for laws
|
|
regarding warranty and disclaimer.
|
|
|
|
\item This provision allows alternative requirements for preservation of
|
|
appropriate legal notices. GPLv3 permits additional requirements regarding
|
|
preservation of legal notices, including on output from execution of
|
|
covered works. Preserved information can include information about the
|
|
origins of the code or alterations of the code.
|
|
|
|
\item This provision allows prohibition of misrepresentation of original
|
|
material. The provision yields compatibility with non-copyleft Free
|
|
Software licenses that require marking of modified versions in
|
|
``reasonable''ways which differ from GPL's own precise marking
|
|
requirements.
|
|
|
|
\item This provision allows limitations on the use of names of licensor for
|
|
publicity purposes. This provision also yields additional compatibility
|
|
with non-copyleft Free Software licenses that prohibit the use of the
|
|
licensor's name on unmodified versions (or other prohibitions on
|
|
advertising rights). The third clause of the
|
|
\href{http://opensource.org/licenses/BSD-3-Clause}{3-Clause BSD
|
|
License}, for example, long considered de-facto compatible with GPLv2
|
|
anyway, is via this clause unequivocally compatible with GPLv3. However,
|
|
\href{https://www.gnu.org/licenses/license-list.html#OriginalBSD}{this
|
|
clause \textit{does not} make GPL compatible with the old BSD
|
|
advertising clause} that the FSF
|
|
\href{https://www.gnu.org/philosophy/bsd.html}{long ago identified as
|
|
problematic}.
|
|
|
|
\item This provision clarifies that refusal to grant trademark rights for a
|
|
GPLv3'd covered work remains compatible with GPLv3. Again, some
|
|
non-copyleft permissive licenses include such clauses.
|
|
|
|
\item This provision allows indemnification requirements of authors and
|
|
licensors. The FSF specifically designed this clause to achieve GPLv3
|
|
compatibility for the
|
|
\href{http://www.apache.org/licenses/LICENSE-2.0.html}{Apache Software
|
|
License, Version 2.0}.
|
|
|
|
\end{enumerate}
|
|
|
|
During the GPLv3 drafting process, some questioned the necessity of GPLv3~\S7;
|
|
those critics suggested that it creates complexity that did not previously
|
|
exist. However, by the time of GPLv3's drafting, many existing GPLv2'd
|
|
software packages already combined with various non-copylefted Free Software
|
|
licensed code that carried such additional terms. Therefore, GPLv3~\S7 is
|
|
rationalized existing practices of those package authors and modifiers, since
|
|
it sets clear guidelines regarding the removal and addition of these
|
|
additional terms. With its carefully limited list of allowed additional
|
|
requirements, GPLv3\S7 accomplishes additional objectives as well, since it
|
|
permits the expansion of the base of code available for GPL developers, while
|
|
also encouraging useful experimentation with requirements the GPLv3 does not
|
|
include by default.
|
|
|
|
However, any other non-permissive additional terms apart from those stated
|
|
above are considered ``further'' restrictions which
|
|
\hyperref[GPLv3s10]{GPLv3~\S10} prohibits. Furthermore, as a compliance
|
|
matter, if you add additional terms in accordance with GPLv3~\S7, you must
|
|
ensure that the terms are placed in the relevant source files or provide a
|
|
conspicuous notice about where to find the additional terms.
|
|
|
|
\section{GPLv3~\S8: A Lighter Termination}
|
|
|
|
GPLv2 provided for automatic termination of the rights of a person who
|
|
copied, modified, sublicensed, or distributed a work in violation of the
|
|
license. Automatic termination can be too harsh for those who have committed
|
|
an inadvertent violation, particularly in cases involving distribution of
|
|
large collections of software having numerous copyright holders. A violator
|
|
who resumes compliance with GPLv2 technically needs to obtain forgiveness
|
|
from all copyright holders, and even contacting them all might be impossible.
|
|
|
|
GPLv3~\S8 now grants opportunities for provisional and permanent
|
|
reinstatement of rights. The termination procedure provides a limited
|
|
opportunity to cure license violations. If a licensee has committed a
|
|
first-time violation of the GPL with respect to a given copyright holder, but
|
|
the licensee cures the violation within 30 days following receipt of notice
|
|
of the violation, then any of the licensee's GPL rights that have been
|
|
terminated by the copyright holder are ``automatically reinstated''.
|
|
|
|
|
|
Finally, if a licensee violates the GPL, a contributor may terminate any
|
|
patent licenses that it granted under GPLv3~\S11, in addition to any
|
|
copyright permissions the contributor granted to the licensee.
|
|
|
|
% FIXME-LATER: write more here, perhaps linking up to enforcement
|
|
|
|
\section{GPLv3~\S9: Acceptance}
|
|
|
|
GPLv3~\S9 means what it says: mere receipt or execution of code neither
|
|
requires nor signifies contractual acceptance under the GPL. Speaking more
|
|
broadly, GPLv3 is intentionally structured as a unilateral grant
|
|
of copyright permissions, the basic operation of which exists outside of any
|
|
law of contract. Whether and when a contractual relationship is formed
|
|
between licensor and licensee under local law do not necessarily matter to
|
|
the working of the license.
|
|
|
|
\section{GPLv3~\S10: Explicit Downstream License}
|
|
\label{GPLv3s10}
|
|
|
|
GPLv3~\S10 is a generally straightforward section that ensures that everyone
|
|
downstream receives licenses from all copyright holders. Each time you
|
|
redistribute a GPL'd program, the recipient automatically receives a license,
|
|
under the terms of GPL, from every upstream licensor whose copyrighted
|
|
material is present in the work you redistribute. You could think of this as
|
|
creating a three-dimensional rather than linear flow of license rights.
|
|
Every recipient of the work is ``in privity,'' or is directly receiving a
|
|
license from every licensor.
|
|
|
|
This mechanism of automatic downstream licensing is central to copyleft's
|
|
function. Every licensor independently grants licenses, and every licensor
|
|
independently terminates the license on violation. Parties further
|
|
downstream from the infringing party remain licensed, so long as they don't
|
|
themselves commit infringing actions. Their licenses come directly from all
|
|
the upstream copyright holders, and are not dependent on the license of the breaching
|
|
party who distributed to them. For the same reason, an infringer who acquires
|
|
another copy of the program has not thereby acquired any new license rights:
|
|
once any upstream licensor of that program has terminated the license for
|
|
breach of its terms, no new automatic license will issue to the recipient
|
|
just by acquiring another
|
|
copy\footnote{Footnote~\ref{German-reinstatement-footnote} also applies here
|
|
in discussion of GPLv3 just as it did in discussion of GPLv2.}
|
|
|
|
Meanwhile, one specific addition in GPLv3 here in GPLv3~\S10 deserves special
|
|
mention. Specifically, GPLv3 removed the words ``at no charge'' from
|
|
GPLv2~\S2(b) (which, BTW, became GPLv3~\S5(b)) because it contributed to a misconception that the GPL did not
|
|
permit charging for distribution of copies. The purpose of the ``at no
|
|
charge'' wording was to prevent attempts to collect royalties from third
|
|
parties. The removal of these words created the danger that the imposition
|
|
of licensing fees would no longer be seen as a license violation. Therefore,
|
|
GPLv3~\S10 adds a new explicit prohibition on imposition of licensing fees or
|
|
royalties. This section is an appropriate place for such a clause, since it
|
|
is a specific consequence of the general requirement that no further
|
|
restrictions be imposed on downstream recipients of GPL-covered code.
|
|
|
|
% FIXME-LATER: This text needs further study before I can conclude it belongs
|
|
% in this tutorial:
|
|
|
|
%% Careful readers of the GPL have suggested that its explicit prohibition
|
|
%% against imposition of further restrictions\footnote{GPLv2, section 6; Draft
|
|
%% 3, section 10, third paragraph.} has, or ought to have, implications for
|
|
%% those who assert patents against other licensees. Draft 2 took some steps to
|
|
%% clarify this point in a manner not specific to patents, by describing the
|
|
%% imposition of ``a license fee, royalty, or other charge'' for exercising GPL
|
|
%% rights as one example of an impermissible further restriction. In Draft 3 we
|
|
%% have clarified further that the requirement of non-imposition of further
|
|
%% restrictions has specific consequences for litigation accusing GPL-covered
|
|
%% programs of infringement. Section 10 now states that ``you may not initiate
|
|
%% litigation (including a cross-claim or counterclaim in a lawsuit) alleging
|
|
%% that any patent claim is infringed by making, using, selling, offering for
|
|
%% sale, or importing the Program (or the contribution of any contributor).''
|
|
%% That is to say, a patent holder's licensed permissions to use a work under
|
|
%% GPLv3 may be terminated under section 8 if the patent holder files a lawsuit
|
|
%% alleging that use of the work, or of any upstream GPLv3-licensed work on
|
|
%% which the work is based, infringes a patent.
|
|
|
|
\section{GPLv3~\S11: Explicit Patent Licensing}
|
|
\label{GPLv3s11}
|
|
|
|
Software patenting is a harmful and unjust policy, and should be abolished;
|
|
recent experience makes this all the more evident. Since many countries grant
|
|
patents that can apply to and prohibit software packages, in various guises
|
|
and to varying degrees, GPLv3 seeks to protect the users of GPL-covered programs
|
|
from those patents, while at the same time making it feasible for patent
|
|
holders to contribute to and distribute GPL-covered programs as long as they
|
|
do not attack the users of those programs.
|
|
|
|
It is generally understood that GPLv2 implies some limits on a licensee's
|
|
power to assert patent claims against the use of GPL-covered works.
|
|
However, the patent licensing practices that GPLv2~\S7 (corresponding to
|
|
GPLv3~\S12) is designed to prevent is only one of several ways in which
|
|
software patents threaten to make free programs non-free and to prevent users
|
|
from exercising their rights under the GPL. GPLv3 takes a more comprehensive
|
|
approach to combating the danger of patents.
|
|
|
|
GPLv2~\S7 has seen some success in deterring conduct that would otherwise
|
|
result in denial of full downstream enjoyment of GPL rights, and thus it is
|
|
preserved in GPLv3~\S12. Experience has shown that more is necessary,
|
|
however, to ensure adequate community safety where companies act in concert
|
|
to heighten the anticompetitive use of patents that they hold or license.
|
|
|
|
Therefore, GPLv3 is designed to reduce the patent risks that distort and
|
|
threaten the activities of users who make, run, modify and share Free
|
|
Software. At the same time, GPLv3 gives favorable consideration to practical
|
|
goals such as certainty and administrability for patent holders that
|
|
participate in distribution and development of GPL-covered software. GPLv3's
|
|
policy requires each such patent holder to provide appropriate levels of
|
|
patent assurance to users, according to the nature of the patent holder's
|
|
relationship to the program.
|
|
|
|
In general, GPLv3 provides for two classes of patent commitments:
|
|
|
|
\begin{itemize}
|
|
\item Grant of license to claims in contributor versions: GPLv3~\S11
|
|
introduces an affirmative grant of rights to patent claims by those who
|
|
contribute code to GPL'd programs. The intent is to prevent parties from
|
|
aggressively asserting patents against users of code those parties have
|
|
themselves modified --- in theory preventing betrayal by ``insiders'' of
|
|
the copyleft community. A contributor's patent claims necessarily
|
|
infringed by the version of the program created by the incorporation of its
|
|
modifications are licensed to all subsequent users and modifiers of the
|
|
program, or programs based on the program. No patent claims only infringed
|
|
by subsequent modifications by other parties are thus licensed. Patent
|
|
claims acquired after the making of the ``contributor version'' necessarily
|
|
infringed by that version are also licensed by this provision at the time
|
|
of their acquisition or perfection.
|
|
|
|
\item Prohibition of enforcement of patent claims against those to whom you
|
|
distribute: GPLv3~\S10 makes explicit that licensees who directly
|
|
distribute may not make demands for acceptance of patent licenses or
|
|
payment of patent royalties from distribution recipients. This provision
|
|
establishes a uniform rule of patent exhaustion with respect to GPL'd
|
|
programs regardless of the domestic patent law in any particular system or
|
|
locale.
|
|
\end{itemize}
|
|
|
|
The following two subsections discuss in order each of the above mentioned
|
|
classes of patent commitments.
|
|
|
|
\subsection{The Contributor's Explicit Patent License}
|
|
|
|
Specifically, the ideal might have been for GPLv3 to feature a patent license
|
|
grant triggered by all acts of distribution of GPLv3-covered works. The FSF
|
|
considered it during the GPLv3 drafting process, but many patent-holding
|
|
companies objected to this policy. They have made two objections: (1) the
|
|
far-reaching impact of the patent license grant on the patent holder is
|
|
disproportionate to the act of merely distributing code without modification
|
|
or transformation, and (2) it is unreasonable to expect an owner of vast
|
|
patent assets to exercise requisite diligence in reviewing all the
|
|
GPL-covered software that it provides to others. Some expressed particular
|
|
concern about the consequences of ``inadvertent'' distribution.
|
|
|
|
The argument that the impact of the patent license grant would be
|
|
``disproportionate'', that is to say unfair, is not valid. Since
|
|
software patents are weapons that no one should have, and using them for
|
|
aggression against free software developers is an egregious act (thus
|
|
preventing that act cannot be unfair).
|
|
|
|
However, the second argument seems valid in a practical sense. A
|
|
typical GNU/Linux distribution includes thousands of programs. It would
|
|
be quite difficult for a re-distributor with a large patent portfolio to
|
|
review all those programs against that portfolio every time it receives
|
|
and passes on a new version of the distribution. Moreover, this question
|
|
raises a strategic issue. If the GPLv3 patent license requirements
|
|
convince patent-holding companies to remain outside the distribution
|
|
path of all GPL-covered software, then these requirements, no matter how
|
|
strong, will cover few patents.
|
|
|
|
GPLv3 therefore makes a partial concession
|
|
which would lead these companies to feel secure in doing the
|
|
distribution themselves. GPLv3~\S11
|
|
applies only to those distributors that have
|
|
modified the program. The other changes we have made in sections 10 and
|
|
11 provide strengthened defenses against patent assertion and compensate
|
|
partly for this concession.
|
|
|
|
Therefore, GPLv3~\S11 introduces the terms ``contributor'', ``contributor version'', and
|
|
``essential patent claims'', which are
|
|
used in the GPLv3~\S11\P3. Viewed from the perspective of a recipient of the
|
|
Program, contributors include all the copyright holders for the Program,
|
|
other than copyright holders of material originally licensed under non-GPL
|
|
terms and later incorporated into a GPL-covered work. The contributors are
|
|
therefore the initial GPLv3 licensors of the Program and all subsequent
|
|
upstream licensors who convey, under the terms of GPLv3~\S5, modified covered
|
|
works.
|
|
Thus, the ``contributor version'' includes the material the contributor has copied from the
|
|
upstream version that the contributor has modified. GPLv3~\S11\P3
|
|
does not apply to those that redistribute the program
|
|
without change.\footnote{An implied patent license from the distributor,
|
|
however, often arises. See \S~\ref{gpl-implied-patent-grant} in this tutorial}
|
|
In other words, the ``contributor version'' includes not just
|
|
the material added or altered by the contributor, but also the pre-existing
|
|
material the contributor copied from the upstream version and retained in the
|
|
modified version. (GPLv3's usage of ``contributor'' and ``contribution'' should
|
|
not be confused with the various other ways in which those terms are used in
|
|
certain other free software licenses\footnote{Cf., e.g., Apache License,
|
|
version 2.0, section 1; Eclipse Public License, version 1.0, section 1;
|
|
Mozilla Public License, version 1.1, section 1.1.}.)
|
|
|
|
Some details of the ``essential patent claims'' definition deserve special
|
|
mention. ``Essential patent claims'', for a given party, are a subset of the
|
|
claims ``owned or controlled'' by the party. They do include sublicensable
|
|
claims that have been licensed to the contributor by a third
|
|
party.\footnote{This issue is typically handled in other software freedom
|
|
licenses having patent licensing provisions by use of the unhelpful term
|
|
``licensable,'' which is either left undefined or is given an ambiguous
|
|
definition.} Most commercial patent license agreements that permit
|
|
sublicensing do so under restrictive terms that are inconsistent with the
|
|
requirements of the GPL\@. For example, some patent licenses allow the
|
|
patent licensee to sublicense but require collection of royalties from any
|
|
sublicensees. The patent licensee could not distribute a GPL-covered program
|
|
and grant the recipient a patent sublicense for the program without violating
|
|
section 12 of GPLv3.\footnote{GPLv3 also provides an example in section 12
|
|
that makes this point clear.} In rare cases, however, a conveying party
|
|
can freely grant patent sublicenses to downstream recipients without
|
|
violating the GPL\@.
|
|
|
|
Additionally, ``essential patent claims'' are those patents ``that would be
|
|
infringed by some manner, permitted by this License, of making, using, or
|
|
selling the work''. This intends to make clear that a patent claim is
|
|
``essential'' if some mode of usage would infringe that claim, even if there
|
|
are other modes of usage that would not infringe.
|
|
|
|
Finally, ``essential patent claims \ldots do not include
|
|
claims that would be infringed only as a consequence of further
|
|
modification of the work.'' The set of essential patent
|
|
claims licensed is fixed by the
|
|
particular version of the work that was contributed. The claim set
|
|
cannot expand as a work is further modified downstream. (If it could,
|
|
then any software patent claim would be included, since any software
|
|
patent claim can be infringed by some further modification of the
|
|
work.)\footnote{However, ``the work'' should not be understood to be
|
|
restricted to a particular mechanical affixation of, or medium for
|
|
distributing, a program, where the same program might be provided in
|
|
other forms or in other ways that may be captured by other patent claims
|
|
held by the contributor.}
|
|
|
|
\medskip
|
|
|
|
Ideally, this contributor patent policy will result in fairly frequent licensing of patent
|
|
claims by contributors. A contributor is charged with awareness of the fact
|
|
that it has modified a work and provided it to others; no act of contribution
|
|
should be treated as inadvertent. GPLv3's rule also requires no more work, for a
|
|
contributor, than the weaker rule proposed by the patent holders. Under
|
|
their rule, the contributor must always compare the entire work against its
|
|
patent portfolio to determine whether the combination of the modifications
|
|
with the remainder of the work cause it to read on any of the contributor's
|
|
patent claims.
|
|
|
|
Finally, GPLv3's explicit patent license for contributors has an interesting
|
|
and useful side effect. When a company with a large number of such claims
|
|
acquires the program's modifier, all claims held or thereafter acquired by
|
|
the purchaser are automatically licensed under this provision. For example,
|
|
Microsoft's acquisition of Nokia resulted in the automatic licensing of all
|
|
Microsoft patent claims now or hereafter acquired which read on any
|
|
contributor version of any GPLv3 program ever modified by Nokia.
|
|
|
|
\subsection{Conveyors' Patent Licensing}
|
|
|
|
The remaining patent licensing in GPLv3 deals with patent licenses that are
|
|
granted by conveyance. The licensing is not as complete or far reaching as
|
|
the contributor patent licenses discussed in the preceding section.
|
|
|
|
The term ``patent license,'' as used in GPLv3~\S11\P4--6, is not meant to be
|
|
confined to agreements formally identified or classified as patent licenses.
|
|
GPLv3~\S11\P3 makes this clear by defining ``patent
|
|
license,'' for purposes of the subsequent three paragraphs, as ``any express
|
|
agreement or commitment, however denominated, not to enforce a patent
|
|
(such as an express permission to practice a patent or covenant not to
|
|
sue for patent infringement)''
|
|
|
|
% FIXME-LATER: I want to ask Fontana about this before adding it.
|
|
|
|
% The definition does not include patent licenses that arise by
|
|
% implication or operation of law, because the third through fifth paragraphs
|
|
% of section 11 are specifically concerned with explicit promises that purport
|
|
% to be legally enforceable.
|
|
|
|
GPLv3~\S11\P5 is commonly called GPLv3's downstream shielding provision. It
|
|
responds particularly to the problem of exclusive deals between patent
|
|
holders and distributors, which threaten to distort the free software
|
|
distribution system in a manner adverse to developers and users. The
|
|
fundamental idea is to make a trade-off between assuring a patent license for
|
|
downstream and making (possibly patent-encumbered) CCS publicly available.
|
|
|
|
Simply put, in nearly all cases in which the ``knowingly relying'' test is
|
|
met, the patent license will indeed not be sublicensable or generally
|
|
available to all on free terms. If, on the other hand, the patent license is
|
|
generally available under terms consistent with the requirements of the GPL,
|
|
the distributor is automatically in compliance, because the patent license
|
|
has already been extended to all downstream recipients. Finally, if the
|
|
patent license is sublicensable on GPL-consistent terms, the distributor may
|
|
choose to grant sublicenses to downstream recipients instead of causing the
|
|
CCS to be publicly available. (In such a case, if the distributor is also a
|
|
contributor, it will already have granted a patent sublicense anyway, and so
|
|
it need not do anything further to comply with the third paragraph.)
|
|
|
|
Admittedly, public disclosure of CCS is not necessarily required by other
|
|
sections of the GPL, and the FSF in drafting GPLv3 did not necessarily wish
|
|
to impose a general requirement to make source code available to all, which
|
|
has never been a GPL condition. However, many vendors who produce products
|
|
that include copylefted software, and who are most likely to be affected by the
|
|
downstream shielding provision, lobbied for the addition of the source code
|
|
availability option, so it remains.
|
|
|
|
% FIXME-LATER: This text is likely redundant and a bit confusing. Needs work
|
|
% to use.
|
|
|
|
%% If A takes a patent license from B that benefits A only, rather than A's
|
|
%% customers or their distributees, A imposes risk from B's patents on others
|
|
%% that it does not suffer itself. Under many circumstances, this is an
|
|
%% acceptable outcome. If, however, A is the only possible source of the
|
|
%% program, by taking such a license and distributing in reliance on it, A is in
|
|
%% effect helping B to ``take the program private.''
|
|
|
|
% FIXME-LATER: end
|
|
|
|
Meanwhile, two specific alternatives to the source code availability option
|
|
are also available. The distributor may comply by disclaiming the patent
|
|
license it has been granted for the conveyed work, or by arranging to extend
|
|
the patent license to downstream recipients\footnote{The latter option, if
|
|
chosen, must be done ``in a manner consistent with the requirements of this
|
|
License''; for example, it is unavailable if extension of the patent
|
|
license would result in a violation of GPLv3~\S 12.}. The GPL is intended
|
|
to permit private distribution as well as public distribution, and the
|
|
addition of these options ensures that this remains the case, even though it
|
|
remains likely that distributors in this situation will usually choose the
|
|
source code availability option.
|
|
|
|
Note that GPLv3~\S11\P5 is activated only if the CCS is not already otherwise
|
|
publicly available. (Most often it will, in fact, already be available on
|
|
some network server operated by a third party.) Even if it is not already
|
|
available, the option to ``cause the Corresponding Source to be so
|
|
available'' can then be satisfied by verifying that a third party has acted
|
|
to make it available. That is to say, the affected distributor need not
|
|
itself host the CCS to take advantage of the source code availability option.
|
|
This subtlety may help the distributor avoid certain peculiar assumptions of
|
|
liability.
|
|
|
|
Note that GPLv3~\S11\P6--7 are designed to stop distributors from colluding with
|
|
third parties to offer selective patent protection. GPLv3 is designed to
|
|
ensure that all users receive the same rights; arrangements that circumvent
|
|
this make a mockery of free software, and we must do everything in our power
|
|
to stop them.
|
|
|
|
First, GPLv3~\S11\P6 states that any license that protects some recipients of
|
|
GPL'd software must be extended to all recipients of the software.
|
|
If conveyors arrange to provide patent
|
|
protection to some of the people who get the software from you, that
|
|
protection is automatically extended to everyone who receives the software,
|
|
no matter how they get it.
|
|
|
|
Second, GPLv3~\S11\P7
|
|
prohibit anyone who made such an agreement from distributing software
|
|
released under GPLv3. Conveyors are prohibited from
|
|
distributing software under GPLv3 if the conveyor makes an agreement of that
|
|
nature in the future.
|
|
|
|
The date in GPLv3~\S11\P7 likely seems arbitrary to those who did not follow
|
|
the GPLv3 drafting process. This issue was hotly debated during the drafting of
|
|
GPLv3, but ultimately one specific deal of this type --- a deal between Microsoft
|
|
and Novell for Microsoft to provide so-called ``coupons'' to Microsoft customers to redeem
|
|
for copies of Novell's GNU/Linux distribution with a Microsoft patent license -- was
|
|
designed to be excluded.
|
|
|
|
The main reason for this was a tactical decision by the FSF. FSF believed they can do more to
|
|
protect the community by allowing Novell to use software under GPLv3
|
|
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}
|
|
\label{GPLv3s12}
|
|
|
|
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. In particular, when a combined work is made by linking GPLv3-covered code
|
|
with AGPLv3-covered code, the copyleft on one part will not extend to the
|
|
other part. In such combinations, the Affero requirement will apply only to
|
|
the part originally brought into the combination under the Affero license.
|
|
In theory, 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. (Admittedly, in practice, de-mingling of combined code can be
|
|
technically difficult.)
|
|
|
|
|
|
\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}
|
|
\label{LGPLv2}
|
|
|
|
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.
|
|
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.
|
|
|
|
\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.''
|
|
|
|
You can also perform a similar same analysis through careful consideration of
|
|
the license text itself. LGPLv2~\S2(a) states that if a licensed work is a
|
|
software library (defined in LGPLv2~\S0 as ``a collection of software
|
|
functions and/or data prepared so as to be conveniently linked with
|
|
application programs (which use some of those functions and data) to form
|
|
executables''), you have permission to distribute modified versions only if
|
|
those versions are themselves libraries. LGPLv2.1 code can therefore not be
|
|
compliantly taken from its context in a library and placed in a non-library
|
|
modified version or work based on the work. For its part, LGPLv2~\S6 does
|
|
not provide an exception for this rule: a combination may be made of a
|
|
modified version of an LGPL'd library with other code, but the LGPL'd code
|
|
must continue to be structured as a library, and to that library the terms of
|
|
the license continue to apply.
|
|
|
|
|
|
Either way you view the rules, these issues are admittedly complicated.
|
|
Nevertheless, In our years of work with the LGPLv2.1, however, we have never
|
|
seen a work of software that was not clearly one or the other; the line is
|
|
quite bright. At times, though, we have seen cases where a particularly large
|
|
work in some ways seemed to be both to both a work that used the library and
|
|
a work based on the library. We overcame this problem by dividing the work
|
|
into smaller subunits. It was soon discovered that what we actually had were
|
|
three distinct components: the original LGPL'd work, a specific set of works
|
|
that used that library, and a specific set of works that were based on the
|
|
library. Once such distinctions are established, the licensing for each
|
|
component can be considered independently and the LGPLv2.1 applied to each
|
|
work as prescribed.
|
|
|
|
Finally, note though that, since the LGPLv2.1 can be easily upgraded to
|
|
GPLv2-or-later, in the worst case you simply need to comply as if the
|
|
software was licensed under GPLv2. The only reason you must consider the
|
|
question of whether you have a ``work that uses the library'' or a ``work
|
|
based on the library'' is when you wish to take advantage of the ``weak
|
|
copyleft'' effect of the Lesser GPL\@. If GPLv2-or-later is an acceptable
|
|
license (i.e., if you plan to copyleft the entire work anyway), you may find
|
|
this an easier option.
|
|
|
|
\section{Subtleties in Defining the Application}
|
|
|
|
In our discussion of the definition of ``works that use the library,'' we
|
|
left out a few more complex details that relate to lower-level programming
|
|
details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities,
|
|
and it has been a source of great confusion. Part of the confusion comes
|
|
because a deep understanding of how compiler programs work is nearly
|
|
mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to
|
|
cover. It helps some to note that this is a border case that we cover in
|
|
the license only so that when such a border case is hit, the implications
|
|
of using the LGPL continue in the expected way.
|
|
|
|
To understand this subtle point, we must recall the way that a compiler
|
|
operates. The compiler first generates object code, which are the binary
|
|
representations of various programming modules. Each of those modules is
|
|
usually not useful by itself; it becomes useful to a user of a full program
|
|
when those modules are {\em linked\/} into a full binary executable.
|
|
|
|
As we have discussed, the assembly of modules can happen at compile-time
|
|
or at runtime. Legally, there is no distinction between the two --- both
|
|
create a modified version of the work by copying and combining portions of one work and
|
|
mixing them with another. However, under LGPL, there is a case in the
|
|
compilation process where the legal implications are different.
|
|
To understand this phenomenon, we consider that a ``work that uses the
|
|
library'' is typically one whose final binary is a work based on the Program,
|
|
but whose source is not. However, sometimes, there
|
|
are cases where the object code --- that intermediate step between source
|
|
and final binary --- is a work created by copying and modifying code
|
|
from the LGPL'd software.
|
|
|
|
For efficiency, when a compiler turns source code into object code, it
|
|
sometimes places literal portions of the copyrighted library code into the
|
|
object code for an otherwise separate independent work. In the normal
|
|
scenario, the final combined work would not be created until final assembly and
|
|
linking of the executable occurred. However, when the compiler does this
|
|
efficiency optimization, at the intermediate object code step, a
|
|
combined work is created.
|
|
|
|
LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of
|
|
the license is clearly that simply compiling software to ``make use'' of
|
|
the library does not in itself cause the compiled work to be a ``work
|
|
based on the library.'' However, since the compiler copies verbatim,
|
|
copyrighted portions of the library into the object code for the otherwise
|
|
separate and independent work, it would actually cause that object file to be a
|
|
``work based on the library.'' It is not FSF's intent that a mere
|
|
compilation idiosyncrasy would change the requirements on the users of the
|
|
LGPLv2.1'd software. This paragraph removes that restriction, allowing the
|
|
implications of the license to be the same regardless of the specific
|
|
mechanisms the compiler uses underneath to create the ``work that uses the
|
|
library.''
|
|
|
|
As it turns out, we have only once had anyone worry about this specific
|
|
idiosyncrasy, because that particular vendor wanted to ship object code
|
|
(rather than final binaries) to their customers and was worried about
|
|
this edge condition. The intent of clarifying this edge condition is
|
|
primarily to quell the worries of software engineers who understand the
|
|
level of verbatim code copying that a compiler often does, and to help
|
|
them understand that the full implications of LGPLv2.1 are the same regardless
|
|
of the details of the compilation progress.
|
|
|
|
\section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}
|
|
\label{lgpl-section-6}
|
|
Now that we have established a good working definition of works that
|
|
``use'' and works that ``are based on'' the library, we will consider the
|
|
rules for distributing these two different works.
|
|
|
|
The rules for distributing ``works that use the library'' are covered in
|
|
LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release
|
|
of source when a binary version of the LGPL'd software is released. Of
|
|
course, it only requires that source code for the library itself be made
|
|
available. The work that ``uses'' the library need not be provided in
|
|
source form. However, there are also conditions in LGPLv2.1~\S6 to make sure
|
|
that a user who wishes to modify or update the library can do so.
|
|
|
|
LGPLv2.1~\S6 lists five choices with regard to supplying library source
|
|
and granting the freedom to modify that library source to users. We
|
|
will first consider the option given by \S~6(b), which describes the
|
|
most common way currently used for LGPLv2.1 compliance on a ``work that
|
|
uses the library.''
|
|
|
|
LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to
|
|
simply use a dynamically linked, shared library mechanism to link with the
|
|
library. This is by far the easiest and most straightforward option for
|
|
distribution. In this case, the executable of the work that uses the
|
|
library will contain only the ``stub code'' that is put in place by the
|
|
shared library mechanism, and at runtime the executable will combine with
|
|
the shared version of the library already resident on the user's computer.
|
|
If such a mechanism is used, it must allow the user to upgrade and
|
|
replace the library with interface-compatible versions and still be able
|
|
to use the ``work that uses the library.'' However, all modern shared
|
|
library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest
|
|
option, since it does not even require that the distributor of the ``work
|
|
based on the library'' ship copies of the library itself.
|
|
|
|
LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library
|
|
mechanism cannot be used. It requires that the source for the library be
|
|
included, in the typical GPL fashion, but it also has a requirement beyond
|
|
that. The user must be able to exercise her freedom to modify the library
|
|
to its fullest extent, and that means recombining it with the ``work based
|
|
on the library.'' If the full binary is linked without a shared library
|
|
mechanism, the user must have available the object code for the ``work
|
|
based on the library,'' so that the user can relink the application and
|
|
build a new binary.
|
|
|
|
Almost all known LGPL'd distributions exercise either LGPLv2.1~\S6(a) or
|
|
LGPLv2.1~\S6(b). However, LGPLv2.1~\S6 provides three other options.
|
|
LGPLv2.1~\S6(c) allows for a written offer for CCS (akin to
|
|
\hyperref[GPLv2s3b]{GPLv2~\S3(b)}). CCS may also be distributed by network
|
|
under the terms of LGPLv2.1~\S6(c). Furthermore, under LGPLv2.1~\S6(e) the
|
|
distributor may ``verify'' that the user has already received, or at least
|
|
that the distributor has already sent to this particular user, the relevant
|
|
source\footnote{Policy motivations for LGPLv2.1~\S6(d) are unclear, but it
|
|
presumably intended to prevent requiring duplicate deliveries in ``whole
|
|
distribution'' situations.}.
|
|
|
|
Finally, LGPLv3~\S6 also requires that:
|
|
|
|
\begin{quote}
|
|
You must give prominent notice with each copy of the work that the
|
|
Library is used in it and that the Library and its use are covered by
|
|
this License. You must supply a copy of this License. If the work during
|
|
execution displays copyright notices, you must include the copyright
|
|
notice for the Library among them, as well as a reference directing the
|
|
user to the copy of this License.
|
|
\end{quote}
|
|
|
|
This is not identical to the roughly parallel requirements of GPLv2 and
|
|
GPLv3. Compliance requires slightly different measures with respect to the
|
|
``credits'' or ``licenses'' or ``about'' screens in interactive programs.
|
|
|
|
\section{Distributing Works Based On the Library}
|
|
|
|
Essentially, ``works based on the library'' must be distributed under the
|
|
same conditions as works under full GPL\@. In fact, we note that
|
|
LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.
|
|
|
|
There are, however, subtle differences and additions. For example not only
|
|
is CCS required (as would be with normal versions of GPL), but also the CCS
|
|
provided must enable a developer to regenerate the modified version of the
|
|
entire combined work, using with a modified version of the LGPL'd work (as a
|
|
replacement for the version a distributor provided). For example, LGPL'd
|
|
code is statically linked to a non-copyleft executable, the required source
|
|
code must also include sufficient material to split the distributed
|
|
executable and relink with a modified version of the library.
|
|
|
|
\section{And the Rest}
|
|
|
|
The remaining variations between the LGPL and the GPL cover the following
|
|
conditions:
|
|
|
|
\begin{itemize}
|
|
|
|
\item Allowing a licensing ``upgrade'' from the LGPL to the GPL\@ (in LGPLv2.1~\S3).
|
|
Note, however, LGPLv2.1~\S3 allows relicensing of works under its terms
|
|
instead under the terms of GPLv2-or-later. This provides, for example, a
|
|
pathway for those who do not want to use code under the requirements of
|
|
LGPLv2.1 to do so under GPLv2 or GPLv3 at their discretion.
|
|
|
|
\item Binary distribution of the library only, covered in LGPLv2.1~\S4,
|
|
which is effectively equivalent to LGPLv2.1~\S3
|
|
|
|
\item Creating aggregates of libraries that are separate and independent works from
|
|
each other, and distributing them as a unit (in LGPLv2.1~\S7)
|
|
|
|
\end{itemize}
|
|
|
|
|
|
Due to time constraints, we cannot cover these additional terms in detail,
|
|
but they are mostly straightforward. The key to understanding LGPLv2.1 is
|
|
understanding the difference between a ``work based on the library'' and a
|
|
``work that uses the library.'' Once that distinction is clear, the
|
|
remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in
|
|
our more extensive GPL unit can be directly applied.
|
|
|
|
\chapter{LGPLv3}
|
|
\label{LGPLv3}
|
|
|
|
LGPLv3 was designed to rectify architectural flaws in the GNU family of
|
|
licenses. Historically , LGPLv2.1 was a textual modification of GPLv2.
|
|
Reconciliation of licensing terms upon combination of LGPLv2.1'd and GPLv2'd
|
|
works is cumbersome, from a licensing bookkeeping perspective.
|
|
|
|
LGPLv3 redresses this historical problem through extensive use of
|
|
\hyperref[GPLv3s7]{GPLv3~\S7}'s exception architecture. LGPLv3 is therefore
|
|
a set of additional permission to GPLv3.
|
|
|
|
%FIXME: harken back to policy motivations of LGPL and how GPLv3 as a whole is
|
|
%always an option.
|
|
|
|
\section{Section 0: Additional Definitions}
|
|
|
|
LGPLv3~\S0 defines the ``Library'' -- a work that presents one or more
|
|
interfaces at which a ``use'' can be made by an ``Application.'' Class
|
|
inheritance is ``deemed'' a use of an interface. An ``Application,'' which is
|
|
other program code using one or more ``Library'' interfaces can be combined
|
|
with the code on the other side of the interfaces it uses to form a
|
|
``Combined Work.''
|
|
|
|
\section{LGPLv3~\S1: Exception to GPLv3~\S3}
|
|
|
|
LGPLv3~\S1 excepts away the interference with use of LGPLv3 code as part of
|
|
``effective technological measures'' of access limitation for other copyrighted
|
|
works provided otherwise by GPLv3~\S3.
|
|
|
|
\section{LGPLv3~\S2: Conveying Modified Versions}
|
|
|
|
LGPLv3~\S2 continues to require, as LGPLv2.1~\S2(d) requires, that the Library
|
|
not be modified to require keys, tokens, tables, or other global non-argument
|
|
data unrelated to function. This is again stated as a ``good faith effort''
|
|
requirement, but failure to cure on notice is strong evidence of the absence
|
|
of good faith. LGPLv3~\S2(b) permits removal of the permissions entirely (as
|
|
prescribed by GPLv3~\S7); however, such removal reduces the license of the
|
|
entire covered work back to pure GPLv3. Thus, exercising LGPLv3~\S2(b) as a
|
|
compliance alternative to LGPLv3~\S2(a) likely creates more compliance
|
|
obligations than it removes.
|
|
|
|
\section{LGPLv3~\S3: Object Code Incorporating Material from Library Header Files}
|
|
|
|
LGPLv3~\S3's front matter assures incorporation of smaller header files into
|
|
non-copylefted object code can proceed unimpeded. More complex
|
|
header files (those that do not meet the limitations provided in the
|
|
section), can still be incorporated into object code, a copy of appropriate
|
|
licensing information must accompany distribution (per LGPLv3~\S3(a--b).
|
|
|
|
%FIXME: talk about copyrightabilty lines and the like and why the ten line rule.
|
|
|
|
\section{LGPLv3~\S4: Combined Works}
|
|
|
|
LGPLv3~\S4 is the combination permission at the heart of LGPLv3. It restates
|
|
the license limitation provision of LGPLv2.1~\S2 to clarify that the terms on
|
|
the Combined Work may not prohibit user modification of the Library code, or
|
|
the debugging of such modifications to the Library code by means of whatever
|
|
reverse engineering is necessary.
|
|
|
|
LGPLv3~\S4(d)(0) contains the source provision requirement, for the Minimal
|
|
Corresponding Source, which ``means the Corresponding Source for the Combined
|
|
Work, excluding any source code for portions of the Combined Work that,
|
|
considered in isolation, are based on the Application, and not on the Linked
|
|
Version [of the Library]''. The alternative to the provision of source code is
|
|
distribution by way of the ``shared library'' mechanism under LGPLv3~\S4(d)(1),
|
|
described with respect to LGPLv2.1~\S6.
|
|
|
|
In addition, LGPLv3~\S4(e) requires the delivery of ``installation information''
|
|
required to install the modified version of the Library in ``user products''
|
|
under GPLv3~\S6. Where Library Minimal Corresponding Source is not made
|
|
available under LGPLv3~\S4(d)(1), LGPLv3~\S4(e) reaffirms that ``installation information''
|
|
must still be compliantly delivered under the terms of GPLv3~\S6.
|
|
|
|
All other provisions of GPLv3 are in force as previously described, and are
|
|
not excepted by the additional permission granted in LGPLv3.
|
|
|
|
If the distributor of the combined work intends not to distribute or offer
|
|
the source code of the LGPL'd components, the LGPL'd work must be separately
|
|
distributed (subject to source code delivery requirements as part of that
|
|
separate distribution) and packaged in a ``shared library'' mechanism, which
|
|
means that it:
|
|
\begin{quote}
|
|
\begin{enumerate}[label=4(d)(\arabic*):,ref=LGPLv3s4d\arabic*]
|
|
\item uses at run time a copy of the library already present on
|
|
the user's computer system, rather than copying library functions into
|
|
the executable, and
|
|
|
|
\item will operate properly with a modified version of
|
|
the library, if the user installs one, as long as the modified version is
|
|
interface-compatible with the version that the work was made with.
|
|
\end{enumerate}
|
|
\end{quote}
|
|
|
|
Taken all together, LGPLv3~\S4's primary implications for redistributors are
|
|
two-fold, as follows:
|
|
\begin{itemize}
|
|
|
|
\item If you create a program that links through a shared library mechanism to
|
|
a work that is separately distributed under LGPLv3, then you can
|
|
distribute the resultant program under a license of your choice and you
|
|
need not convey the LGPLv3'd work's source code. If you distribute the
|
|
library along with your program, or are the separate distributor of the
|
|
work in another context or as another product, you must distribute its
|
|
corresponding source under the terms of LGPLv3 or GPLv3-or-later.
|
|
|
|
\item If you choose to statically link or otherwise combine your program with
|
|
an LGPLv3'd work via mechanisms other than a shared library, you may choose your own license for the work provided the
|
|
license terms limitations for user modification, reverse engineering and
|
|
debugging are met, and given that the LGPL'd components are still
|
|
governed by LGPL's terms. You must offer or provide CCS for the LGPL'd components. The source code
|
|
material provided must be sufficient to regenerate the combined work with
|
|
a user-modified version of the LGPL'd components.
|
|
\end{itemize}
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% FIXME-LATER: There should be a chapter on GPL Exceptions generally.
|
|
|
|
% Here is some CC-By-SA text from another source that would make an
|
|
% acceptable introduction to a section on the GCC RTL Exception if such a
|
|
% chapter is written:
|
|
|
|
% This GCC Runtime Library Exception (``Exception'') is an additional
|
|
% permission as provided by Section 7 of GPLv3. The purpose of this Exception
|
|
% is to allow compilation of non-GPL (including proprietary) programs making
|
|
% use of the header files and runtime libraries covered by this Exception and
|
|
% containing code from the copyleft toolchain embedded by the compiler in the
|
|
% object code of the program as part of the compilation process. The GCC
|
|
% Runtime Library Exception covers any file that has a notice in its license
|
|
% headers stating that the exception applies.
|
|
|
|
% FIXME-LATER: end
|
|
|
|
\chapter{Integrating the GPL into Business Practices}
|
|
|
|
Since GPL'd software is now extremely prevalent through the industry, it
|
|
is useful to have some basic knowledge about using GPL'd software in
|
|
business and how to build business models around GPL'd software.
|
|
|
|
\section{Using GPL'd Software In-House}
|
|
|
|
As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial,
|
|
the GPL only governs the activities of copying, modifying and
|
|
distributing software programs that are not governed by the license.
|
|
Thus, in FSF's view, simply installing the software on a machine and
|
|
using it is not controlled or limited in any way by the GPL\@. Using Free
|
|
Software in general requires substantially fewer agreements and less
|
|
license compliance activity than any known proprietary software.
|
|
|
|
Even if a company engages heavily in copying the software throughout the
|
|
enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is
|
|
encouraged! If the company simply deploys unmodified (or even modified)
|
|
Free Software throughout the organization for its employees to use, the
|
|
obligations under the license are very minimal. Using Free Software has a
|
|
substantially lower cost of ownership --- both in licensing fees and in
|
|
licensing checking and handling -- than the proprietary software
|
|
equivalents.
|
|
|
|
\section{Business Models}
|
|
\label{Business Models}
|
|
|
|
Using Free Software in house is certainly helpful, but a thriving
|
|
market for Free Software-oriented business models also exists. There is the
|
|
traditional model of selling copies of Free Software distributions.
|
|
Many companies make substantial revenue
|
|
from this model. Some choose this model because they have
|
|
found that for higher-end hardware, the profit made from proprietary
|
|
software licensing fees is negligible. The real profit is in the hardware,
|
|
but it is essential that software be stable, reliable and dependable, and
|
|
the users be allowed to have unfettered access to it. Free Software, and
|
|
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 Michlmayr Copyleft's
|
|
%% LocalWords: GPLRequireSourcePostedPublic privity Downstream's Jaeger
|
|
%% LocalWords: Jaeger's copyleft's executables estoppel infringer
|