dac68d1410
but it's for GPLv3§6.
4956 lines
269 KiB
TeX
4956 lines
269 KiB
TeX
% gpl-lgpl.tex -*- LaTeX -*-
|
||
% Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course
|
||
%
|
||
% Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
|
||
% Copyright (C) 2014 Bradley M. Kuhn
|
||
|
||
% License: CC-By-SA-4.0
|
||
|
||
% The copyright holders hereby grant the freedom to copy, modify, convey,
|
||
% Adapt, and/or redistribute this work under the terms of the Creative
|
||
% Commons Attribution Share Alike 4.0 International License.
|
||
|
||
% This text is distributed in the hope that it will be useful, but
|
||
% WITHOUT ANY WARRANTY; without even the implied warranty of
|
||
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
% You should have received a copy of the license with this document in
|
||
% a file called 'CC-By-SA-4.0.txt'. If not, please visit
|
||
% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive
|
||
% the license text.
|
||
|
||
% FIXME-LATER: I should make a macro like the Texinfo @xref stuff for places
|
||
% where I'm saying ``see section X in this tutorial'', so that the extra
|
||
% verbiage isn't there in the HTML versions that I'll eventually do.
|
||
% Maybe something like that already exists? In the worst case, I could
|
||
% adapt @xref from texinfo.texi for it.
|
||
|
||
\newcommand{\defn}[1]{\emph{#1}}
|
||
|
||
\part{Detailed Analysis of the GNU GPL and Related Licenses}
|
||
|
||
{\parindent 0in
|
||
\tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\
|
||
\begin{tabbing}
|
||
Copyright \= \copyright{} 2003--2007 \hspace{.1mm} \= \kill
|
||
Copyright \> \copyright{} 2014 \> Bradley M. Kuhn \\
|
||
Copyright \> \copyright{} 2014 \> Anthony K. Sebro, Jr. \\
|
||
Copyright \> \copyright{} 2003--2007 \> Free Software Foundation, Inc.
|
||
\end{tabbing}
|
||
|
||
|
||
\vspace{1in}
|
||
|
||
\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{.3in}
|
||
|
||
The copyright holders of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} hereby grant the freedom to copy, modify,
|
||
convey, Adapt, and/or redistribute this work under the terms of the Creative
|
||
Commons Attribution Share Alike 4.0 International License. A copy of that
|
||
license is available at
|
||
\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.
|
||
\end{center}
|
||
}
|
||
|
||
\bigskip
|
||
|
||
\bigskip
|
||
|
||
\tutorialpartsplit{This tutorial}{This part of the tutorial} gives a
|
||
comprehensive explanation of the most popular Free Software copyright
|
||
license, the GNU General Public License (``GNU GPL'', or sometimes just
|
||
``GPL'') -- both version 2 (``GPLv2'') and version 3 (``GPLv3'') -- and
|
||
teaches lawyers, software developers, managers and business people how to use
|
||
the GPL (and GPL'd software) successfully both as a community-building
|
||
``Constitution'' for a software project, and to incorporate copylefted
|
||
software into a new Free Software business and in existing, successful
|
||
enterprises.
|
||
|
||
To successfully benefit of from this part of the tutorial, readers should
|
||
have a general familiarity with software development processes. A basic
|
||
understanding of how copyright law applies to software is also helpful. The
|
||
tutorial is of most interest to lawyers, software developers and managers who
|
||
run or advise software businesses that modify and/or redistribute software
|
||
under the terms of the GNU GPL (or who wish to do so in the future), and those
|
||
who wish to make use of existing GPL'd software in their enterprise.
|
||
|
||
Upon completion of this part of the tutorial, successful readers can expect
|
||
to have learned the following:
|
||
|
||
\begin{itemize}
|
||
|
||
\item The freedom-defending purpose of various terms in the GNU GPLv2 and GPLv3.
|
||
|
||
\item The differences between GPLv2 and GPLv3.
|
||
|
||
\item The redistribution options under the GPLv2 and GPLv3.
|
||
|
||
\item The obligations when modifying GPLv2'd or GPLv3'd software.
|
||
|
||
\item How to build a plan for proper and successful compliance with the GPL.
|
||
|
||
\item The business advantages that the GPL provides.
|
||
|
||
\item The most common business models used in conjunction with the GPL.
|
||
|
||
\item How existing GPL'd software can be used in existing enterprises.
|
||
|
||
\item The basics of LGPLv2.1 and LGPLv3, and how they
|
||
differs from the GPLv2 and GPLv3, respectively.
|
||
|
||
\item The basics to begin understanding the complexities regarding
|
||
derivative and combined works of software.
|
||
\end{itemize}
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% END OF ABSTRACTS SECTION
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
% START OF DAY ONE COURSE
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
|
||
\chapter{What Is Software Freedom?}
|
||
|
||
Study of the GNU General Public License (herein, abbreviated as \defn{GNU
|
||
GPL} or just \defn{GPL}) must begin by first considering the broader world
|
||
of software freedom. The GPL was not created in a vacuum. Rather, it was
|
||
created to embody and defend a set of principles that were set forth at the
|
||
founding of the GNU project and the Free Software Foundation (FSF) -- the
|
||
preeminent organization that upholds, defends and promotes the philosophy of software
|
||
freedom. A prerequisite for understanding both of the popular versions
|
||
of the GPL
|
||
(GPLv2 and GPLv3) and their terms and conditions is a basic understanding of
|
||
the principles behind them. The GPL family of licenses are unlike nearly all
|
||
other software licenses in that they are designed to defend and uphold these
|
||
principles.
|
||
|
||
\section{The Free Software Definition}
|
||
\label{Free Software Definition}
|
||
|
||
The Free Software Definition is set forth in full on FSF's website at
|
||
\verb0http://fsf.org/0 \verb0philosophy/free-sw.html0. This section presents
|
||
an abbreviated version that will focus on the parts that are most pertinent
|
||
to the GPL\@.
|
||
|
||
A particular program grants software freedom to a particular user if that
|
||
user is granted the following freedoms:
|
||
|
||
\begin{itemize}
|
||
|
||
|
||
\item The freedom to run the program, for any purpose.
|
||
|
||
\item The freedom to study how the program works, and modify it
|
||
|
||
\item The freedom to redistribute copies.
|
||
|
||
\item The freedom to distribute copies of modified versions to others.
|
||
|
||
\end{itemize}
|
||
|
||
The focus on ``a particular user'' is particularly pertinent here. It is not
|
||
uncommon for the same version of a specific program to grant these freedoms
|
||
to some subset of its user base, while others have none or only some of these
|
||
freedoms. Section~\ref{Proprietary Relicensing} talks in detail about how
|
||
this can unfortunately happen even if a program is released under the GPL\@.
|
||
|
||
Many people refer to software that gives these freedoms as ``Open Source.''
|
||
Besides having a different political focus than those who call it Free
|
||
Software,\footnote{The political differences between the Free Software
|
||
Movement and the Open Source Movement are documented on FSF's Web site at
|
||
{\tt http://www.fsf.org/licensing/essays/free-software-for-freedom.html}.}
|
||
Those who call the software ``Open Source'' are often focused on a side
|
||
issue. Specifically, user access to the source code of a program is a
|
||
prerequisite to make use of the freedom to modify. However, the important
|
||
issue is what freedoms are granted in the license of that source code.
|
||
|
||
Software freedom is only complete when no restrictions are imposed on how
|
||
these freedoms are exercised. Specifically, users and programmers can
|
||
exercise these freedoms noncommercially or commercially. Licenses that grant
|
||
these freedoms for noncommercial activities but prohibit them for commercial
|
||
activities are considered non-free. Even the Open Source Initiative
|
||
(\defn{OSI}) (the arbiter of what is considered ``Open Source'') also rules
|
||
such licenses not in fitting with its ``Open Source Definition''.
|
||
|
||
In general, software for which most or all of these freedoms are
|
||
restricted in any way is called ``non-Free Software.'' Typically, the
|
||
term ``proprietary software'' is used more or less interchangeably with
|
||
``non-Free Software.'' Personally, I tend to use the term ``non-Free
|
||
Software'' to refer to noncommercial software that restricts freedom
|
||
(such as ``shareware'') and ``proprietary software'' to refer to
|
||
commercial software that restricts freedom (such as nearly all of
|
||
Microsoft's and Oracle's offerings).
|
||
|
||
Keep in mind that the none of the terms ``software freedom'', ``open source''
|
||
and ``free software'' are known to be trademarked or otherwise legally
|
||
restricted by any organization in
|
||
any jurisdiction. As such, it's quite common that these terms are abused and
|
||
misused by parties who wish to bank on the popularity of software freedom.
|
||
When one considers using, modifying or redistributing a software package that
|
||
purports to be Open Source or Free Software, one \textbf{must} verify that
|
||
the license grants software freedom.
|
||
|
||
Furthermore, throughout this text, we generally prefer the term ``software
|
||
freedom'', as this is the least ambiguous term available to describe software
|
||
that meets the Free Software Definition. For example, it is well known and
|
||
often discussed that the adjective ``free'' has two unrelated meanings in
|
||
English: ``free as in freedom'' and ``free as in price''. Meanwhile, the
|
||
term ``open source'' is even more confusing, because it appears to refer only to the
|
||
``freedom to study'', which is merely a subset of one of the four freedoms.
|
||
|
||
The remainder of this section considers each of each component of software
|
||
freedom in detail.
|
||
|
||
\subsection{The Freedom to Run}
|
||
\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
|
||
modification.
|
||
|
||
\subsection{The Freedom to Copy and Share}
|
||
|
||
Users share Free Software in a variety of ways. Software freedom advocates
|
||
work to eliminate a fundamental ethical dilemma of the software age: choosing
|
||
between obeying a software license and friendship (by giving away a copy of a
|
||
program to your friend who likes the software you are using). Licenses that
|
||
respect software freedom, therefore, permit altruistic sharing of software
|
||
among friends.
|
||
|
||
The commercial environment also benefits of this freedom. Commercial sharing
|
||
includes selling copies of Free Software: that is, Free Software can
|
||
be distribted for any monetary
|
||
price to anyone. Those who redistribute Free Software commercially also have
|
||
the freedom to selectively distribute (i.e., you can pick your customers) and
|
||
to set prices at any level that redistributor sees fit.
|
||
|
||
Of course, most people get copies of Free Software very cheaply (and
|
||
sometimes without charge). The competitive free market of Free Software
|
||
tends to keep prices low and reasonable. However, if someone is willing to
|
||
pay billions of dollars for one copy of the GNU Compiler Collection, such a
|
||
sale is completely permitted.
|
||
|
||
Another common instance of commercial sharing is service-oriented
|
||
distribution. For example, some distribution vendors provide immediate
|
||
security and upgrade distribution via a special network service. Such
|
||
distribution is not necessarily contradictory with software freedom.
|
||
|
||
(Section~\ref{Business Models} of this tutorial talks in detail about some
|
||
common Free Software business models that take advantage of the freedom to
|
||
share commercially.)
|
||
|
||
\subsection{The Freedom to Share Improvements}
|
||
|
||
The freedom to modify and improve is somewhat empty without the freedom to
|
||
share those improvements. The Software freedom community is built on the
|
||
pillar of altruistic sharing of improved Free Software. Historically
|
||
it was typical for a
|
||
Free Software project to sprout a mailing list where improvements
|
||
would be shared
|
||
freely among members of the development community\footnote{This is still
|
||
commonly the case, though today there are other or additional ways of
|
||
sharing Free Software.}. Such noncommercial
|
||
sharing is the primary reason that Free Software thrives.
|
||
|
||
Commercial sharing of modified Free Software is equally important.
|
||
For commercial support to exist in a competitive free market, all
|
||
developers -- from single-person contractors to large software
|
||
companies -- must have the freedom to market their services as
|
||
improvers of Free Software. All forms of such service marketing must
|
||
be equally available to all.
|
||
|
||
For example, selling support services for Free Software is fully
|
||
permitted. Companies and individuals can offer themselves as ``the place
|
||
to call'' when software fails or does not function properly. For such a
|
||
service to be meaningful, the entity offering that service needs the
|
||
right to modify and improve the software for the customer to correct any
|
||
problems that are beyond mere user error.
|
||
|
||
Software freedom licenses also permit any entity to distribute modified
|
||
versions of Free Software. Most Free Software programs have a ``standard
|
||
version'' that is made available from the primary developers of the software.
|
||
However, all who have the software have the ``freedom to fork'' -- that is,
|
||
make available nontrivial modified versions of the software on a permanent or
|
||
semi-permanent basis. Such freedom is central to vibrant developer and user
|
||
interaction.
|
||
|
||
Companies and individuals have the right to make true value-added versions
|
||
of Free Software. They may use freedom to share improvements to
|
||
distribute distinct versions of Free Software with different functionality
|
||
and features. Furthermore, this freedom can be exercised to serve a
|
||
disenfranchised subset of the user community. If the developers of the
|
||
standard version refuse to serve the needs of some of the software's
|
||
users, other entities have the right to create a long- or short-lived fork
|
||
to serve that sub-community.
|
||
|
||
\section{How Does Software Become Free?}
|
||
|
||
The previous section set forth key freedoms and rights that are referred to
|
||
as ``software freedom''. This section discusses the licensing mechanisms
|
||
used to enable software freedom. These licensing mechanism were ultimately
|
||
created as a community-oriented ``answer'' to the existing proprietary
|
||
software licensing mechanisms. Thus, first, consider carefully why
|
||
proprietary software exists in the first place.
|
||
|
||
Proprietary software exists at all only because it is governed by copyright
|
||
law.\footnote{This statement is admittedly an oversimplification. Patents and
|
||
trade secrets can cover software and make it effectively non-Free, and one
|
||
can contract away their rights and freedoms regarding software, or source
|
||
code can be practically obscured in binary-only distribution without
|
||
reliance on any legal system. However, the primary control mechanism for
|
||
software is copyright, and therefore this section focuses on how copyright
|
||
restrictions make software proprietary.} Copyright law, with respect to
|
||
software, typically governs copying, modifying, and redistributing that
|
||
software (For details of this in the USA, see
|
||
\href{http://www.copyright.gov/title17/92chap1.html#106}{\S~106} and
|
||
\href{http://www.copyright.gov/title17/92chap1.html#117}{\S~117} of
|
||
\href{http://www.law.cornell.edu/uscode/text/17}{Title 17} of the
|
||
\textit{United States Code}).\footnote{Copyright law in general also governs
|
||
``public performance'' of copyrighted works. There is no generally agreed
|
||
definition for public performance of software and both GPLv2 and GPLv3 do
|
||
not restrict public performance.} By law (in the USA and in most other
|
||
jurisdictions), the copyright holder (most typically, the author) of the work controls
|
||
how others may copy, modify and/or distribute the work. For proprietary
|
||
software, these controls are used to prohibit these activities. In addition,
|
||
proprietary software distributors further impede modification in a practical
|
||
sense by distributing only binary code and keeping the source code of the
|
||
software secret.
|
||
|
||
Copyright is not a natural state, it is a legal construction. In the USA, the
|
||
Constitution permits, but does not require, the creation of copyright law as
|
||
federal legislation. Software, since it is ``an original works of authorship
|
||
fixed in any tangible medium of expression ... from which they can be
|
||
perceived, reproduced, or otherwise communicated, either directly or with the
|
||
aid of a machine or device'' (as stated in
|
||
\href{http://www.law.cornell.edu/uscode/text/17/102}{17 USC \S~102}), is thus
|
||
covered by the statute, and is copyrighted by default.
|
||
|
||
However, software, in its natural state without copyright, is Free
|
||
Software. In an imaginary world with no copyright, the rules would be
|
||
different. In this world, when you received a copy of a program's source
|
||
code, there would be no default legal system to restrict you from sharing it
|
||
with others, making modifications, or redistributing those modified
|
||
versions.\footnote{Note that this is again an oversimplification; the
|
||
complexities with this argument are discussed in
|
||
Section~\ref{software-and-non-copyright}.}
|
||
|
||
Software in the real world is copyrighted by default and is automatically
|
||
covered by that legal system. However, it is possible to move software out
|
||
of the domain of the copyright system. A copyright holder can often
|
||
\defn{disclaim} their copyright. (For example, under USA copyright law
|
||
it is possible for a copyright holder to engage in conduct resulting
|
||
in abandonment of copyright.) If copyright is disclaimed, the software is
|
||
effectively no longer restricted by copyright law. Software not restricted by copyright is in the
|
||
``public domain.''
|
||
|
||
\subsection{Public Domain Software}
|
||
|
||
In the USA and other countries that
|
||
are parties to the Berne Convention on Copyright, software is copyrighted
|
||
automatically by the author when she fixes the software in a tangible
|
||
medium. In the software world, this usually means typing the source code
|
||
of the software into a file.
|
||
|
||
Imagine if authors could truly disclaim those default control of copyright
|
||
law. If so, the software is in the public domain --- no longer covered by
|
||
copyright. Since copyright law is the construction allowing for most
|
||
restrictions on software (i.e., prohibition of copying, modification, and
|
||
redistribution), removing the software from the copyright system usually
|
||
yields software freedom for its users.
|
||
|
||
Carefully note that software truly in the public domain is \emph{not} licensed
|
||
in any way. It is confusing to say software is ``licensed for the
|
||
public domain,'' or any phrase that implies the copyright holder gave
|
||
express permission to take actions governed by copyright law.
|
||
|
||
Copyright holders who state that they are releasing their code into
|
||
the public domain are effectively renouncing copyright controls on
|
||
the work. The law gave the copyright holders exclusive controls over the
|
||
work, and they chose to waive those controls. Software that is, in
|
||
this sense, in the public domain
|
||
is conceptualized by the developer as having no copyright and thus no license. The software freedoms discussed in
|
||
Section~\ref{Free Software Definition} are all granted because there is no
|
||
legal system in play to take them away.
|
||
|
||
Admittedly, a discussion of public domain software is an oversimplified
|
||
example.
|
||
Because copyright controls are usually automatically granted and because, in
|
||
some jurisdictions, some copyright controls cannot be waived (see
|
||
Section~\ref{non-usa-copyright} for further discussion), many copyright
|
||
holders sometimes incorrectly believe a work has been placed in the public
|
||
domain. Second, due to aggressive lobbying by the entertainment industry,
|
||
the ``exclusive Right'' of copyright, that was supposed to only exist for
|
||
``Limited Times'' according to the USA Constitution, appears to be infinite:
|
||
simply purchased on the installment plan rather than in whole. Thus, we must
|
||
assume no works of software will fall into the public domain merely due to
|
||
the passage of time.
|
||
|
||
Nevertheless, under USA law it is likely that the typical
|
||
disclaimers of copyright or public domain dedications we see in the
|
||
Free Software world would be interpreted by courts as copyright
|
||
abandonment, leading to a situation in which the user effectively receives a
|
||
maximum grant of copyright freedoms, similar to a maximally-permissive
|
||
Free Software license.
|
||
|
||
The best example of software known to truly be in the public domain is software
|
||
that is published by the USA government. Under
|
||
\href{http://www.law.cornell.edu/uscode/text/17/105}{17 USC 101 \S~105}, all
|
||
works published by the USA Government are not copyrightable in the USA.
|
||
|
||
\subsection{Why Copyright Free Software?}
|
||
|
||
If simply disclaiming copyright on software yields Free Software, then it
|
||
stands to reason that putting software into the public domain is the
|
||
easiest and most straightforward way to produce Free Software. Indeed,
|
||
some major Free Software projects have chosen this method for making their
|
||
software Free. However, most of the Free Software in existence \emph{is}
|
||
copyrighted. In most cases (particularly in those of FSF and the GNU
|
||
Project), this was done due to very careful planning.
|
||
|
||
Software released into the public domain does grant freedom to those users
|
||
who receive the standard versions on which the original author disclaimed
|
||
copyright. However, since the work is not copyrighted, any nontrivial
|
||
modification made to the work is fully copyrightable.
|
||
|
||
Free Software released into the public domain initially is Free, and
|
||
perhaps some who modify the software choose to place their work into the
|
||
public domain as well. However, over time, some entities will choose to
|
||
proprietarize their modified versions. The public domain body of software
|
||
feeds the proprietary software. The public commons disappears, because
|
||
fewer and fewer entities have an incentive to contribute back to the
|
||
commons. They know that any of their competitors can proprietarize their
|
||
enhancements. Over time, almost no interesting work is left in the public
|
||
domain, because nearly all new work is done by proprietarization.
|
||
|
||
A legal mechanism is needed to redress this problem. FSF was in fact
|
||
originally created primarily as a legal entity to defend software freedom,
|
||
and that work of defending software freedom is a substantial part of
|
||
its work today. Specifically because of this ``embrace, proprietarize and
|
||
extend'' cycle, FSF made a conscious choice to copyright its Free Software,
|
||
and then license it under ``copyleft'' terms. Many, including the
|
||
developers of the kernel named Linux, have chosen to follow this paradigm.
|
||
|
||
\label{copyleft-definition}
|
||
|
||
Copyleft is a legal strategy and mechanism to defend, uphold and propagate software
|
||
freedom. The basic technique of copyleft is as follows: copyright the
|
||
software, license it under terms that give all the software freedoms, but
|
||
use the copyright law controls to ensure that all who receive a copy of
|
||
the software have equal rights and freedom. In essence, copyleft grants
|
||
freedom, but forbids others to forbid that freedom to anyone else along
|
||
the distribution and modification chains.
|
||
|
||
Copyleft is a general concept. Much like ideas for what a computer might
|
||
do must be \emph{implemented} by a program that actually does the job, so
|
||
too must copyleft be implemented in some concrete legal structure.
|
||
``Share and share alike'' is a phrase that is used often enough to explain the
|
||
concept behind copyleft, but to actually make it work in the real world, a
|
||
true implementation in legal text must exist. The GPL is the primary
|
||
implementation of copyleft in copyright licensing language.
|
||
|
||
\subsection{Software and Non-Copyright Legal Regimes}
|
||
\label{software-and-non-copyright}
|
||
|
||
The use, modification and distribution of software, like many endeavors,
|
||
simultaneously interacts with multiple different legal regimes. As was noted
|
||
early via footnotes, copyright is merely the \textit{most common way} to
|
||
restrict users' rights to copy, share, modify and/or redistribute software.
|
||
However, proprietary software licenses typically use every mechanism
|
||
available to subjugate users. For example:
|
||
|
||
\begin{itemize}
|
||
|
||
\item Unfortunately, despite much effort by many in the software freedom
|
||
community to end patents that read on software (i.e., patents on
|
||
computational ideas), they still ultimately exist. As such, a software
|
||
program might otherwise be seemly unrestricted, but a patent might read on
|
||
the software and ruin everything for its users.\footnote{See
|
||
\S\S~\ref{gpl-implied-patent-grant},~\ref{GPLv2s7},~\ref{GPLv3s11} for more
|
||
discussion on how the patent system interacts with copyleft, and read
|
||
Richard M.~Stallman's essay,
|
||
\href{http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/}{\textit{Let’s
|
||
Limit the Effect of Software Patents, Since We Can’t Eliminate Them}}
|
||
for more information on the problems these patents present to society.}
|
||
|
||
\item Digital Restrictions Management (usually called \defn{DRM}) is often
|
||
used to impose technological restrictions on users' ability to exercise
|
||
software freedom that they might otherwise be granted\footnote{See
|
||
\S~\ref{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 GPL must be considered under the
|
||
copyright law in the jurisdiction where any licensing dispute occurs.
|
||
|
||
Those who are most familiar with the USA's system of copyright often are
|
||
surprised to learn that there are certain copyright controls that cannot be
|
||
waived nor disclaimed. Specifically, many copyright regimes outside the USA
|
||
recognize a concept of moral rights of authors. Typically, moral rights are
|
||
fully compatible with respecting software freedom, as they are usually
|
||
centered around controls that software freedom licenses generally respect,
|
||
such as the right of an authors to require proper attribution for their work.
|
||
|
||
\section{A Community of Equality}
|
||
|
||
The previous section described the principles of software freedom, a brief
|
||
introduction to mechanisms that typically block these freedoms, and the
|
||
simplest ways that copyright holders might grant those freedoms to their
|
||
users for their copyrighted works of software. The previous section also
|
||
introduced the idea of \textit{copyleft}: a licensing mechanism to use
|
||
copyright to not only grant software freedom to users, but also to uphold
|
||
those rights against those who might seek to curtail them.
|
||
|
||
Copyleft, as defined in \S~\ref{copyleft-definition}, is a general term this
|
||
mechanism. The remainder of this text will discuss details of various
|
||
real-world implementations of copyleft -- most notably, the GPL\@.
|
||
|
||
This discussion begins first with some general explanation of what the GPL is
|
||
able to do in software development communities. After that brief discussion
|
||
in this section, deeper discussion of how GPL accomplishes this in practice
|
||
follows in the next chapter.
|
||
|
||
Simply put, though, the GPL ultimately creates an community of equality for
|
||
both business and noncommercial users.
|
||
|
||
\subsection{The Noncommercial Community}
|
||
|
||
A GPL'd code base becomes a center of a vibrant development and user
|
||
community. Traditionally, volunteers, operating noncommercially out of
|
||
keen interest or ``scratch an itch'' motivations, produce initial versions
|
||
of a GPL'd system. Because of the efficient distribution channels of the
|
||
Internet, any useful GPL'd system is adopted quickly by noncommercial
|
||
users.
|
||
|
||
Fundamentally, the early release and quick distribution of the software
|
||
gives birth to a thriving noncommercial community. Users and developers
|
||
begin sharing bug reports and bug fixes across a shared intellectual
|
||
commons. Users can trust the developers, because they know that if the
|
||
developers fail to address their needs or abandon the project, the GPL
|
||
ensures that someone else has the right to pick up development.
|
||
Developers know that the users cannot redistribute their software without
|
||
passing along the rights granted by GPL, so they are assured that every
|
||
one of their users is treated equally.
|
||
|
||
Because of the symmetry and fairness inherent in GPL'd distribution,
|
||
nearly every GPL'd package in existence has a vibrant noncommercial user
|
||
and developer base.
|
||
|
||
\subsection{The Commercial Community}
|
||
|
||
By the same token, nearly all established GPL'd software systems have a
|
||
vibrant commercial community. Nearly every GPL'd system that has gained
|
||
wide adoption from noncommercial users and developers eventually begins
|
||
to fuel a commercial system around that software.
|
||
|
||
For example, consider the Samba file server system that allows Unix-like
|
||
systems (including GNU/Linux) to serve files to Microsoft Windows systems.
|
||
Two graduate students originally developed Samba in their spare time and
|
||
it was deployed noncommercially in academic environments\footnote{See
|
||
\href{http://turtle.ee.ncku.edu.tw/docs/samba/history}{Andrew Tridgell's
|
||
``A bit of history and a bit of fun''}}. However, very
|
||
soon for-profit companies discovered that the software could work for them
|
||
as well, and their system administrators began to use it in place of
|
||
Microsoft Windows NT file-servers. This served to lower the cost of
|
||
running such servers by orders of magnitude. There was suddenly room in
|
||
Windows file-server budgets to hire contractors to improve Samba. Some of
|
||
the first people hired to do such work were those same two graduate
|
||
students who originally developed the software.
|
||
|
||
The noncommercial users, however, were not concerned when these two
|
||
fellows began collecting paychecks off of their GPL'd work. They knew
|
||
that because of the nature of the GPL that improvements that were
|
||
distributed in the commercial environment could easily be folded back into
|
||
the standard version. Companies are not permitted to proprietarize
|
||
Samba, so the noncommercial users, and even other commercial users are
|
||
safe in the knowledge that the software freedom ensured by GPL will remain
|
||
protected.
|
||
|
||
Commercial developers also work in concert with noncommercial
|
||
developers. Those two now-long-since graduated students continue to
|
||
contribute to Samba altruistically, but also get paid work doing it.
|
||
Priorities change when a client is in the mix, but all the code is
|
||
contributed back to the standard version. Meanwhile, many other
|
||
individuals have gotten involved noncommercially as developers,
|
||
because they want to ``cut their teeth on Free Software,'' or because
|
||
the problems interest them. When they get good at it, perhaps they
|
||
will move on to another project, or perhaps they will become
|
||
commercial developers of the software themselves.
|
||
|
||
No party is a threat to another in the GPL software scenario because
|
||
everyone is on equal ground. The GPL protects rights of the commercial
|
||
and noncommercial contributors and users equally. The GPL creates trust,
|
||
because it is a level playing field for all.
|
||
|
||
\subsection{Law Analogy}
|
||
|
||
In his introduction to Stallman's \emph{Free Software, Free Society},
|
||
Lawrence Lessig draws an interesting analogy between the law and Free
|
||
Software. He argues that the laws of a free society must be protected
|
||
much like the GPL protects software. So that I might do true justice to
|
||
Lessig's argument, I quote it verbatim:
|
||
|
||
\begin{quotation}
|
||
|
||
A ``free society'' is regulated by law. But there are limits that any free
|
||
society places on this regulation through law: No society that kept its
|
||
laws secret could ever be called free. No government that hid its
|
||
regulations from the regulated could ever stand in our tradition. Law
|
||
controls. But it does so justly only when visibly. And law is visible
|
||
only when its terms are knowable and controllable by those it regulates,
|
||
or by the agents of those it regulates (lawyers, legislatures).
|
||
|
||
This condition on law extends beyond the work of a legislature. Think
|
||
about the practice of law in American courts. Lawyers are hired by their
|
||
clients to advance their clients' interests. Sometimes that interest is
|
||
advanced through litigation. In the course of this litigation, lawyers
|
||
write briefs. These briefs in turn affect opinions written by judges.
|
||
These opinions decide who wins a particular case, or whether a certain law
|
||
can stand consistently with a constitution.
|
||
|
||
All the material in this process is free in the sense that Stallman means.
|
||
Legal briefs are open and free for others to use. The arguments are
|
||
transparent (which is different from saying they are good), and the
|
||
reasoning can be taken without the permission of the original lawyers.
|
||
The opinions they produce can be quoted in later briefs. They can be
|
||
copied and integrated into another brief or opinion. The ``source code''
|
||
for American law is by design, and by principle, open and free for anyone
|
||
to take. And take lawyers do---for it is a measure of a great brief that
|
||
it achieves its creativity through the reuse of what happened before. The
|
||
source is free; creativity and an economy is built upon it.
|
||
|
||
This economy of free code (and here I mean free legal code) doesn't starve
|
||
lawyers. Law firms have enough incentive to produce great briefs even
|
||
though the stuff they build can be taken and copied by anyone else. The
|
||
lawyer is a craftsman; his or her product is public. Yet the crafting is
|
||
not charity. Lawyers get paid; the public doesn't demand such work
|
||
without price. Instead this economy flourishes, with later work added to
|
||
the earlier.
|
||
|
||
We could imagine a legal practice that was different --- briefs and
|
||
arguments that were kept secret; rulings that announced a result but not
|
||
the reasoning. Laws that were kept by the police but published to no one
|
||
else. Regulation that operated without explaining its rule.
|
||
|
||
We could imagine this society, but we could not imagine calling it
|
||
``free.'' Whether or not the incentives in such a society would be better
|
||
or more efficiently allocated, such a society could not be known as free.
|
||
The ideals of freedom, of life within a free society, demand more than
|
||
efficient application. Instead, openness and transparency are the
|
||
constraints within which a legal system gets built, not options to be
|
||
added if convenient to the leaders. Life governed by software code should
|
||
be no less.
|
||
|
||
Code writing is not litigation. It is better, richer, more
|
||
productive. But the law is an obvious instance of how creativity and
|
||
incentives do not depend upon perfect control over the products
|
||
created. Like jazz, or novels, or architecture, the law gets built
|
||
upon the work that went before. This adding and changing is what
|
||
creativity always is. And a free society is one that assures that its
|
||
most important resources remain free in just this sense.\footnote{This
|
||
quotation is Copyright \copyright{} 2002, Lawrence Lessig. It is
|
||
licensed under the terms of
|
||
\href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution
|
||
License'' version 1.0} or any later version as published by Creative
|
||
Commons.}
|
||
\end{quotation}
|
||
|
||
In essence, lawyers are paid to service the shared commons of legal
|
||
infrastructure. Few citizens defend themselves in court or write their
|
||
own briefs (even though they are legally permitted to do so) because
|
||
everyone would prefer to have an expert do that job.
|
||
|
||
The Free Software economy is a market ripe for experts. It
|
||
functions similarly to other well established professional fields like the
|
||
law. The GPL, in turn, serves as the legal scaffolding that permits the
|
||
creation of this vibrant commercial and noncommercial Free Software
|
||
economy.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{A Tale of Two Copyleft Licenses}
|
||
\label{tale-of-two-copylefts}
|
||
|
||
While determining the proper methodology and criteria to yield an accurate
|
||
count remains difficult, the GPL is generally considered one of the most
|
||
widely used Free Software licenses. For most of its history --- for 16 years
|
||
from June 1991 to June 2007 --- there was really only one version of the GPL,
|
||
version 2.
|
||
|
||
However, the GPL had both earlier versions before version 2, and, more well
|
||
known, a revision to version 3.
|
||
|
||
\section{Historical Motivations for the General Public License}
|
||
|
||
The earliest license to grant software freedom was likely the Berkeley
|
||
Software Distribution (``BSD'') license. This license is typical of what are
|
||
often called lax, highly permissive licenses. Not unlike software in the
|
||
public domain, these non-copyleft licenses (usually) grant software freedom
|
||
to users, but they do not go to any effort to uphold that software freedom
|
||
for users. The so-called ``downstream'' (those who receive the software and
|
||
then build new things based on that software) can restrict the software and
|
||
distribute further.
|
||
|
||
The GNU's Not Unix (``GNU'') project, which Richard M.~Stallman (``RMS'')
|
||
founded in 1984 to make a complete Unix-compatible operating system
|
||
implementation that assured software freedom for all. However, RMS saw that
|
||
using a license that gave but did not assure software freedom would be
|
||
counter to the goals of the GNU project. RMS invented ``copyleft'' as an
|
||
answer to that problem, and began using various copyleft licenses for the
|
||
early GNU project programs\footnote{RMS writes more fully about this topic in
|
||
his essay entitled simply
|
||
\href{http://www.gnu.org/gnu/thegnuproject.html}{\textit{The GNU Project}}.
|
||
For those who want to hear the story in his own voice,
|
||
\href{http://audio-video.gnu.org/audio/}{speech recordings} of his talk,
|
||
\textit{The Free Software Movement and the GNU/Linux Operating System}
|
||
are also widely available}.
|
||
|
||
\section{Proto-GPLs And Their Impact}
|
||
|
||
The earliest copyleft licenses were specific to various GNU programs. For
|
||
example, \href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs
|
||
General Public License} was likely the first copyleft license ever
|
||
published. Interesting to note that even this earliest copyleft license
|
||
contains a version of the well-known GPL copyleft clause:
|
||
|
||
\begin{quotation}
|
||
You may modify your copy or copies of GNU Emacs \ldots provided that you also
|
||
\ldots cause the whole of any work that you distribute or publish, that in
|
||
whole or in part contains or is a derivative of GNU Emacs or any part
|
||
thereof, to be licensed at no charge to all third parties on terms identical
|
||
to those contained in this License Agreement.
|
||
\end{quotation}
|
||
|
||
This simply stated clause is the fundamental innovation of copyleft.
|
||
Specifically, copyleft \textit{uses} the copyright holders' controls on
|
||
permission to modify the work to add a conditional requirement. Namely,
|
||
downstream users may only have permission to modify the work if they pass
|
||
along the same permissions on the modified version that came originally to
|
||
them.
|
||
|
||
These original program-specific proto-GPLs give an interesting window into
|
||
the central ideas and development of copyleft. In particular, reviewing them
|
||
shows how the text of the GPL we know has evolved to address more of the
|
||
issues discussed earlier in \S~\ref{software-and-non-copyright}.
|
||
|
||
\section{The GNU General Public License, Version 1}
|
||
\label{GPLv1}
|
||
|
||
In January 1989, the FSF announced that the GPL had been converted into a
|
||
``subroutine'' that could be reused not just for all FSF-copyrighted
|
||
programs, but also by anyone else. As the FSF claimed in its announcement of
|
||
the GPLv1\footnote{The announcement of GPLv1 was published in the
|
||
\href{http://www.gnu.org/bulletins/bull6.html\#SEC8}{GNU'S Bulletin, vol 1,
|
||
number 6 dated January 1989}. (Thanks very much to Andy Tai for his
|
||
\href{http://www.free-soft.org/gpl_history/}{consolidation of research on
|
||
the history of the pre-v1 GPL's}.)}:
|
||
\begin{quotation}
|
||
To make it easier to copyleft programs, we have been improving on the
|
||
legalbol architecture of the General Public License to produce a new version
|
||
that serves as a general-purpose subroutine: it can apply to any program
|
||
without modification, no matter who is publishing it.
|
||
\end{quotation}
|
||
|
||
This, like many inventive ideas, seems somewhat obvious in retrospect. But,
|
||
the FSF had some bright people and access to good lawyers when it started.
|
||
It took almost five years from the first copyleft licenses to get to a
|
||
generalized, reusable GPLv1. In the context and mindset of the 1980s, this
|
||
is not surprising. The idea of reusable licensing infrastructure was not
|
||
only uncommon, it was virtually nonexistent! Even the early BSD licenses
|
||
were simply copied and rewritten slightly for each new use\footnote{It
|
||
remains an interesting accident of history that the early BSD problematic
|
||
``advertising clause'' (discussion of which is somewhat beyond the scope of
|
||
this tutorial) lives on into current day, simply because while the
|
||
University of California at Berkeley gave unilateral permission to remove
|
||
the clause from \textit{its} copyrighted works, others who adapted the BSD
|
||
license with their own names in place of UC-Berkeley's never have.}. The
|
||
GPLv1's innovation of reuable licensing infrastructure, an obvious fact
|
||
today, was indeed a novel invention for its day\footnote{We're all just
|
||
grateful that the FSF also opposes business method patents, since the FSF's
|
||
patent on a ``method for reusable licensing infrastructure'' would have
|
||
not expired until 2006!}.
|
||
|
||
\section{The GNU General Public License, Version 2}
|
||
|
||
The GPLv2 was released two and a half years after GPLv1, and over the
|
||
following sixteen years, it became the standard for copyleft licensing until
|
||
the release of GPLv3 in 2007 (discussed in more detail in the next section).
|
||
|
||
While this tutorial does not discuss the terms of GPLv1 in detail, it is
|
||
worth noting below the three key changes that GPLv2 brought:
|
||
|
||
\begin{itemize}
|
||
|
||
\item Software patents and their danger are explicitly mentioned, inspiring
|
||
(in part) the addition of GPLv2~\S\S5--7. (These sections are discussed in
|
||
detail in \S~\ref{GPLv2s5}, \S~\ref{GPLv2s6} and \S~\ref{GPLv2s7} of this
|
||
tutorial.)
|
||
|
||
\item GPLv2~\S2's copyleft terms are expanded to more explicitly discuss the
|
||
issue of combined works. (GPLv2~\S2 is discussed in detail in
|
||
\S~\ref{GPLv2s2} in this tutorial).
|
||
|
||
\item GPLv2~\S3 includes more detailed requirements, including the phrase
|
||
``the scripts used to control compilation and installation of the
|
||
executable'', which is a central component of current GPLv2 enforcement
|
||
. (GPLv2~\S3 is discussed in detail in
|
||
\S~\ref{GPLv2s3} in this tutorial).
|
||
\end{itemize}
|
||
|
||
The next chapter discusses GPLv2 in full detail, and readers who wish to dive
|
||
into the section-by-section discussion of the GPL should jump ahead now to
|
||
that chapter. However, the most interesting fact to note here is how GPLv2
|
||
was published with little fanfare and limited commentary. This contrasts
|
||
greatly with the creation of GPLv3.
|
||
|
||
\section{The GNU General Public License, Version 3}
|
||
|
||
RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups
|
||
during that era about new text of that license. However, rampant violations
|
||
of the GPL required more immediate attention of FSF's licensing staff, and as
|
||
such, much of the early 2000's was spent doing GPL enforcement
|
||
work\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a
|
||
companion tutorial, \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 the are ultimate multiple
|
||
choices for use of the license. The FSF is the primary steward of GPL (as
|
||
discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv2s14}). However, those
|
||
who wish to license works under GPL are not required to automatically accept
|
||
changes made by the FSF for their own copyrighted works.
|
||
|
||
Each licensor may chose three different methods of licensing, as follows:
|
||
|
||
\begin{itemize}
|
||
|
||
\item explicitly name a single version of GPL for their work (usually
|
||
indicated in shorthand by saying the license is ``GPLv$X$-only''), or
|
||
|
||
\item name no version of the GPL, thus they allow their downstream recipients
|
||
to select any version of the GPL they chose (usually indicated in shorthand
|
||
by saying the license is simply ``GPL''), or
|
||
|
||
\item name a specific version of GPL and give downstream recipients the
|
||
option to chose that version ``or any later version as published by the
|
||
FSF'' (usually indicated by saying the license is
|
||
``GPLv$X$-or-later'')\footnote{The shorthand of ``GPL$X+$'' is also popular
|
||
for this situation. The authors of this tutorial prefer ``-or-later''
|
||
syntax, because it (a) mirrors the words ``or'' and ``later from the
|
||
licensing statement, (b) the $X+$ doesn't make it abundantly clear that
|
||
$X$ is clearly included as a license option and (c) the $+$ symbol has
|
||
other uses in computing (such as with regular expressions) that mean
|
||
something different.}
|
||
\end{itemize}
|
||
|
||
\label{license-compatibility-first-mentioned}
|
||
|
||
Oddly, this flexibility has received (in the opinion of the authors, undue)
|
||
criticism, primarily because of the complex and oft-debated notion of
|
||
``license compatibility'' (which is explained in detail in
|
||
\S~\ref{license-compatibility}). Copyleft licenses are generally
|
||
incompatible with each other, because the details of how they implement
|
||
copyleft differs. Specifically, copyleft works only because of its
|
||
requirement that downstream licensors use the \textit{same} license for
|
||
combined and modified works. As such, software licensed under the terms of
|
||
``GPLv2-only'' cannot be combined with works licensed ``GPLv3-or-later''.
|
||
This is admittedly a frustrating outcome.
|
||
|
||
Other copyleft licenses that appeared after GPL, such
|
||
as the Creative Commons ``Share Alike'' licenses, the Eclipse Public License
|
||
and the Mozilla Public License \textbf{require} all copyright holders chosing
|
||
to use any version of those licenses to automatically accept and relicense
|
||
their copyrighted works under new versions. Of course ,Creative Commons, the
|
||
Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally
|
||
served as excellent stewards of their licenses. Copyright holders using
|
||
those licenses seems to find it acceptable that to fully delegate all future
|
||
licensing decisions for their copyrights to these organizations without a
|
||
second thought.
|
||
|
||
However, note that FSF gives herein the control of copyright holders to
|
||
decide whether or not to implicitly trust the FSF in its work of drafting
|
||
future GPL versions. The FSF, for its part, does encourage copyright holders
|
||
to chose by default ``GPLv$X$-or-later'' (where $X$ is the most recent
|
||
version of the GPL published by the FSF). However, the FSF \textbf{does not
|
||
mandate} that a choice to use any GPL requires a copyright holder ceding
|
||
its authority for future licensing decisions to the FSF. In fact, the FSF
|
||
considered this possibility for GPLv3 and chose not to do so, instead opting
|
||
for the third-party steward designation clause discussed in
|
||
Section~\ref{GPLv3s14}.
|
||
|
||
\section{Complexities of Two Simultaneously Popular Copylefts}
|
||
|
||
Obviously most GPL advocates would prefer widespread migration to GPLv3, and
|
||
many newly formed projects who seek a copyleft license tend to choose a
|
||
GPLv3-based license. However, many existing copylefted projects continue
|
||
with GPLv2-only or GPLv2-or-later as their default license.
|
||
|
||
While GPLv3 introduces many improvements --- many of which were designed to
|
||
increase adoption by for-profit companies --- GPLv2 remains a widely used and
|
||
extremely popular license. The GPLv2 is, no doubt, a good and useful
|
||
license.
|
||
|
||
However, unlike GPLv1, which (as pointed out in \S~\ref{GPLv1}), which is
|
||
completely out of use by the mid-1990s. However, unlike GPLv1 before it,
|
||
GPLv2 remains a integral part of the copyleft licensing infrastructure for
|
||
some time to come. As such, those who seek to have expertise in current
|
||
topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of
|
||
licenses.
|
||
|
||
Furthermore, GPLv3 can is more easily understood by first studying GPLv2.
|
||
This is not only because of their chronological order, but also because much
|
||
of the discussion material available for GPLv3 tends to talk about GPLv3 in
|
||
contrast to GPLv2. As such, a strong understanding of GPLv2 helps in
|
||
understanding most of the third-party material found regarding GPLv3. Thus,
|
||
the following chapter begins a deep discussion of GPLv2.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{Running Software and Verbatim Copying}
|
||
\label{run-and-verbatim}
|
||
|
||
|
||
This chapter begins the deep discussion of the details of the terms of
|
||
GPLv2\@. In this chapter, we consider the first two sections: GPLv2 \S\S
|
||
0--2. These are the straightforward sections of the GPL that define the
|
||
simplest rights that the user receives.
|
||
|
||
\section{GPLv2~\S0: Freedom to Run}
|
||
\label{GPLv2s0}
|
||
|
||
GPLv2~\S0, the opening section of GPLv2, sets forth that the copyright law governs
|
||
the work. It specifically points out that it is the ``copyright
|
||
holder'' who decides if a work is licensed under its terms and explains
|
||
how the copyright holder might indicate this fact.
|
||
|
||
A bit more subtly, GPLv2~\S0 makes an inference that copyright law is the only
|
||
system that can restrict the software. Specifically, it states:
|
||
\begin{quote}
|
||
Activities other than copying, distribution and modification are not
|
||
covered by this License; they are outside its scope.
|
||
\end{quote}
|
||
In essence, the license governs \emph{only} those activities, and all other
|
||
activities are unrestricted, provided that no other agreements trump GPLv2
|
||
(which they cannot; see Sections~\ref{GPLv2s6} and~\ref{GPLv2s7}). This is
|
||
very important, because the Free Software community heavily supports
|
||
users' rights to ``fair use'' and ``unregulated use'' of copyrighted
|
||
material. GPLv2 asserts through this clause that it supports users' rights
|
||
to fair and unregulated uses.
|
||
|
||
Fair use (called ``fair dealing'' in some jurisdictions) of copyrighted
|
||
material is an established legal doctrine that permits certain activities
|
||
regardless of whether copyright law would other restrict those activities.
|
||
Discussion of the various types of fair use activity are beyond the scope of
|
||
this tutorial. However, one important example of fair use is the right to
|
||
quote portions of the text in larger work so as to criticize or suggest
|
||
changes. This fair use rights is commonly used on mailing lists when
|
||
discussing potential improvements or changes to Free Software.
|
||
|
||
Fair use is a doctrine established by the courts or by statute. By
|
||
contrast, unregulated uses are those that are not covered by the statue
|
||
nor determined by a court to be covered, but are common and enjoyed by
|
||
many users. An example of unregulated use is reading a printout of the
|
||
program's source code like an instruction book for the purpose of learning
|
||
how to be a better programmer. The right to read something that you have
|
||
access is and should remain unregulated and unrestricted.
|
||
|
||
\medskip
|
||
|
||
Thus, the GPLv2 protects users fair and unregulated use rights precisely by
|
||
not attempting to cover them. Furthermore, the GPLv2 ensures the freedom
|
||
to run specifically by stating the following:
|
||
\begin{quote}
|
||
''The act of running the Program is not restricted.''
|
||
\end{quote}
|
||
Thus, users are explicitly given the freedom to run by GPLv2~\S0.
|
||
|
||
\medskip
|
||
|
||
The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used
|
||
throughout. The only one worth discussing in detail is ``work based on
|
||
the Program''. The reason this definition is particularly interesting is
|
||
not for the definition itself, which is rather straightforward, but
|
||
because it clears up a common misconception about the GPL\@.
|
||
|
||
The GPL is often mistakenly criticized because it fails to give a
|
||
definition of ``derivative work''. In fact, it would be incorrect and
|
||
problematic if the GPL attempted to define this. A copyright license, in
|
||
fact, has no control over what may or may not be a derivative work. This
|
||
matter is left up to copyright law and the courts --- not the licenses that utilize it.
|
||
|
||
It is certainly true that copyright law as a whole does not propose clear
|
||
and straightforward guidelines for what is and is not a derivative
|
||
software work under copyright law. However, no copyright license --- not
|
||
even the GNU GPL --- can be blamed for this. Legislators and court
|
||
opinions must give us guidance to decide the border cases.
|
||
|
||
\section{GPLv2~\S1: Verbatim Copying}
|
||
\label{GPLv2s1}
|
||
|
||
GPLv2~\S1 covers the matter of redistributing the source code of a program
|
||
exactly as it was received. This section is quite straightforward.
|
||
However, there are a few details worth noting here.
|
||
|
||
The phrase ``in any medium'' is important. This, for example, gives the
|
||
freedom to publish a book that is the printed copy of the program's source
|
||
code. It also allows for changes in the medium of distribution. Some
|
||
vendors may ship Free Software on a CD, but others may place it right on
|
||
the hard drive of a pre-installed computer. Any such redistribution media
|
||
is allowed.
|
||
|
||
Preservation of copyright notice and license notifications are mentioned
|
||
specifically in GPLv2~\S1. These are in some ways the most important part of
|
||
the redistribution, which is why they are mentioned by name. GPL
|
||
always strives to make it abundantly clear to anyone who receives the
|
||
software what its license is. The goal is to make sure users know their
|
||
rights and freedoms under GPL, and to leave no reason that users might be
|
||
surprised the software is GPL'd. Thus
|
||
throughout the GPL, there are specific references to the importance of
|
||
notifying others down the distribution chain that they have rights under
|
||
GPL.
|
||
|
||
Also mentioned by name is the warranty disclaimer. Most people today do
|
||
not believe that software comes with any warranty. Notwithstanding the
|
||
\href{http://mlis.state.md.us/2000rs/billfile/hb0019.htm}{Maryland's} and \href{http://leg1.state.va.us/cgi-bin/legp504.exe?001+ful+SB372ER}{Virginia's} UCITA bills, there are few or no implied warranties with software.
|
||
However, just to be on the safe side, GPL clearly disclaims them, and the
|
||
GPL requires redistributors to keep the disclaimer very visible. (See
|
||
Sections~\ref{GPLv2s11} and~\ref{GPLv2s12} of this tutorial for more on GPL's
|
||
warranty disclaimers.)
|
||
|
||
Note finally that GPLv2~\S1 creates groundwork for the important defense of
|
||
commercial freedom. GPLv2~\S1 clearly states that in the case of verbatim
|
||
copies, one may make money. Redistributors are fully permitted to charge
|
||
for the redistribution of copies of Free Software. In addition, they may
|
||
provide the warranty protection that the GPL disclaims as an additional
|
||
service for a fee. (See Section~\ref{Business Models} for more discussion
|
||
on making a profit from Free Software redistribution.)
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
|
||
\chapter{Derivative Works: Statute and Case Law}
|
||
|
||
We digress for this chapter from our discussion of GPL's exact text to
|
||
consider the matter of derivative works --- a concept that we must
|
||
understand fully before considering GPLv2~\S\S2--3\@. GPL, and Free
|
||
Software licensing in general, relies critically on the concept of
|
||
``derivative work'' since software that is ``independent,'' (i.e., not
|
||
``derivative'') of Free Software need not abide by the terms of the
|
||
applicable Free Software license. As much is required by \S~106 of the
|
||
Copyright Act, 17 U.S.C. \S~106 (2002), and admitted by Free Software
|
||
licenses, such as the GPL, which (as we have seen) states in GPLv2~\S0 that ``a
|
||
`work based on the Program' means either the Program or any derivative
|
||
work under copyright law.'' It is being a derivative work of Free Software
|
||
that triggers the necessity to comply with the terms of the Free Software
|
||
license under which the original work is distributed. Therefore, one is
|
||
left to ask, just what is a ``derivative work''? The answer to that
|
||
question differs depending on which court is being asked.
|
||
|
||
The analysis in this chapter sets forth the differing definitions of
|
||
derivative work by the circuit courts. The broadest and most
|
||
established definition of derivative work for software is the
|
||
abstraction, filtration, and comparison test (``the AFC test'') as
|
||
created and developed by the Second Circuit. Some circuits, including
|
||
the Ninth Circuit and the First Circuit, have either adopted narrower
|
||
versions of the AFC test or have expressly rejected the AFC test in
|
||
favor of a narrower standard. Further, several other circuits have yet
|
||
to adopt any definition of derivative work for software.
|
||
|
||
As an introductory matter, it is important to note that literal copying of
|
||
a significant portion of source code is not always sufficient to establish
|
||
that a second work is a derivative work of an original
|
||
program. Conversely, a second work can be a derivative work of an original
|
||
program even though absolutely no copying of the literal source code of
|
||
the original program has been made. This is the case because copyright
|
||
protection does not always extend to all portions of a program's code,
|
||
while, at the same time, it can extend beyond the literal code of a
|
||
program to its non-literal aspects, such as its architecture, structure,
|
||
sequence, organization, operational modules, and computer-user interface.
|
||
|
||
\section{The Copyright Act}
|
||
|
||
The copyright act is of little, if any, help in determining the definition
|
||
of a derivative work of software. However, the applicable provisions do
|
||
provide some, albeit quite cursory, guidance. Section 101 of the Copyright
|
||
Act sets forth the following definitions:
|
||
|
||
\begin{quotation}
|
||
A ``computer program'' is a set of statements or instructions to be used
|
||
directly or indirectly in a computer in order to bring about a certain
|
||
result.
|
||
|
||
A ``derivative work'' is a work based upon one or more preexisting works,
|
||
such as a translation, musical arrangement, dramatization,
|
||
fictionalization, motion picture version, sound recording, art
|
||
reproduction, abridgment, condensation, or any other form in which a work
|
||
may be recast, transformed, or adapted. A work consisting of editorial
|
||
revisions, annotations, elaborations, or other modifications which, as a
|
||
whole, represent an original work of authorship, is a ``derivative work.''
|
||
\end{quotation}
|
||
|
||
These are the only provisions in the Copyright Act relevant to the
|
||
determination of what constitutes a derivative work of a computer
|
||
program. Another provision of the Copyright Act that is also relevant to
|
||
the definition of derivative work is \S~102(b), which reads as follows:
|
||
|
||
\begin{quotation}
|
||
In no case does copyright protection for an original work of authorship
|
||
extend to any idea, procedure, process, system, method of operation,
|
||
concept, principle, or discovery, regardless of the form in which it is
|
||
described, explained, illustrated, or embodied in such work.
|
||
\end{quotation}
|
||
|
||
Therefore, before a court can ask whether one program is a derivative work
|
||
of another program, it must be careful not to extend copyright protection
|
||
to any ideas, procedures, processes, systems, methods of operation,
|
||
concepts, principles, or discoveries contained in the original program. It
|
||
is the implementation of this requirement to ``strip out'' unprotectable
|
||
elements that serves as the most frequent issue over which courts
|
||
disagree.
|
||
|
||
\section{Abstraction, Filtration, Comparison Test}
|
||
|
||
As mentioned above, the AFC test for determining whether a computer
|
||
program is a derivative work of an earlier program was created by the
|
||
Second Circuit and has since been adopted in the Fifth, Tenth, and
|
||
Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982
|
||
F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural
|
||
Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe,
|
||
Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates
|
||
Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993);
|
||
Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman
|
||
v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings,
|
||
Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).
|
||
|
||
Under the AFC test, a court first abstracts from the original program its
|
||
constituent structural parts. Then, the court filters from those
|
||
structural parts all unprotectable portions, including incorporated ideas,
|
||
expression that is necessarily incidental to those ideas, and elements
|
||
that are taken from the public domain. Finally, the court compares any and
|
||
all remaining kernels of creative expression to the structure of the
|
||
second program to determine whether the software programs at issue are
|
||
substantially similar so as to warrant a finding that one is the
|
||
derivative work of the other.
|
||
|
||
Often, the courts that apply the AFC test will perform a quick initial
|
||
comparison between the entirety of the two programs at issue in order to
|
||
help determine whether one is a derivative work of the other. Such a
|
||
holistic comparison, although not a substitute for the full application of
|
||
the AFC test, sometimes reveals a pattern of copying that is not otherwise
|
||
obvious from the application of the AFC test when, as discussed below,
|
||
only certain components of the original program are compared to the second
|
||
program. If such a pattern is revealed by the quick initial comparison,
|
||
the court is more likely to conclude that the second work is indeed a
|
||
derivative of the original.
|
||
|
||
\subsection{Abstraction}
|
||
|
||
The first step courts perform under the AFC test is separation of the
|
||
work's ideas from its expression. In a process akin to reverse
|
||
engineering, the courts dissect the original program to isolate each level
|
||
of abstraction contained within it. Courts have stated that the
|
||
abstractions step is particularly well suited for computer programs
|
||
because it breaks down software in a way that mirrors the way it is
|
||
typically created. However, the courts have also indicated that this step
|
||
of the AFC test requires substantial guidance from experts, because it is
|
||
extremely fact and situation specific.
|
||
|
||
By way of example, one set of abstraction levels is, in descending order
|
||
of generality, as follows: the main purpose, system architecture, abstract
|
||
data types, algorithms and data structures, source code, and object
|
||
code. As this set of abstraction levels shows, during the abstraction step
|
||
of the AFC test, the literal elements of the computer program, namely the
|
||
source and object code, are defined as particular levels of
|
||
abstraction. Further, the source and object code elements of a program are
|
||
not the only elements capable of forming the basis for a finding that a
|
||
second work is a derivative of the program. In some cases, in order to
|
||
avoid a lengthy factual inquiry by the court, the owner of the copyright in
|
||
the original work will submit its own list of what it believes to be the
|
||
protected elements of the original program. In those situations, the court
|
||
will forgo performing its own abstraction, and proceed to the second step of
|
||
the AFC test.
|
||
|
||
\subsection{Filtration}
|
||
|
||
The most difficult and controversial part of the AFC test is the second
|
||
step, which entails the filtration of protectable expression contained in
|
||
the original program from any unprotectable elements nestled therein. In
|
||
determining which elements of a program are unprotectable, courts employ a
|
||
myriad of rules and procedures to sift from a program all the portions
|
||
that are not eligible for copyright protection.
|
||
|
||
First, as set forth in \S~102(b) of the Copyright Act, any and all ideas
|
||
embodied in the program are to be denied copyright protection. However,
|
||
implementing this rule is not as easy as it first appears. The courts
|
||
readily recognize the intrinsic difficulty in distinguishing between ideas
|
||
and expression and that, given the varying nature of computer programs,
|
||
doing so will be done on an ad hoc basis. The first step of the AFC test,
|
||
the abstraction, exists precisely to assist in this endeavor by helping
|
||
the court separate out all the individual elements of the program so that
|
||
they can be independently analyzed for their expressive nature.
|
||
|
||
A second rule applied by the courts in performing the filtration step of
|
||
the AFC test is the doctrine of merger, which denies copyright protection
|
||
to expression necessarily incidental to the idea being expressed. The
|
||
reasoning behind this doctrine is that when there is only one way to
|
||
express an idea, the idea and the expression merge, meaning that the
|
||
expression cannot receive copyright protection due to the bar on copyright
|
||
protection extending to ideas. In applying this doctrine, a court will ask
|
||
whether the program's use of particular code or structure is necessary for
|
||
the efficient implementation of a certain function or process. If so, then
|
||
that particular code or structure is not protected by copyright and, as a
|
||
result, it is filtered away from the remaining protectable expression.
|
||
|
||
A third rule applied by the courts in performing the filtration step of
|
||
the AFC test is the doctrine of scenes a faire, which denies copyright
|
||
protection to elements of a computer program that are dictated by external
|
||
factors. Such external factors can include:
|
||
|
||
\begin{itemize}
|
||
|
||
\item The mechanical
|
||
specifications of the computer on which a particular program is intended
|
||
to operate
|
||
|
||
\item Compatibility requirements of other programs with which a
|
||
program is designed to operate in conjunction
|
||
|
||
\item Computer manufacturers'
|
||
design standards
|
||
|
||
\item Demands of the industry being serviced, and
|
||
|
||
widely accepted programming practices within the computer industry
|
||
|
||
\end{itemize}
|
||
|
||
Any code or structure of a program that was shaped predominantly in
|
||
response to these factors is filtered out and not protected by
|
||
copyright. Lastly, elements of a computer program are also to be filtered
|
||
out if they were taken from the public domain or fail to have sufficient
|
||
originality to merit copyright protection.
|
||
|
||
Portions of the source or object code of a computer program are rarely
|
||
filtered out as unprotectable elements. However, some distinct parts of
|
||
source and object code have been found unprotectable. For example,
|
||
constant s, the invariable integers comprising part of formulas used to
|
||
perform calculations in a program, are unprotectable. Further, although
|
||
common errors found in two programs can provide strong evidence of
|
||
copying, they are not afforded any copyright protection over and above the
|
||
protection given to the expression containing them.
|
||
|
||
\subsection{Comparison}
|
||
|
||
The third and final step of the AFC test entails a comparison of the
|
||
original program's remaining protectable expression to a second
|
||
program. The issue will be whether any of the protected expression is
|
||
copied in the second program and, if so, what relative importance the
|
||
copied portion has with respect to the original program overall. The
|
||
ultimate inquiry is whether there is ``substantial'' similarity between
|
||
the protected elements of the original program and the potentially
|
||
derivative work. The courts admit that this process is primarily
|
||
qualitative rather than quantitative and is performed on a case-by-case
|
||
basis. In essence, the comparison is an ad hoc determination of whether
|
||
the protectable elements of the original program that are contained in the
|
||
second work are significant or important parts of the original program. If
|
||
so, then the second work is a derivative work of the first. If, however,
|
||
the amount of protectable elements copied in the second work are so small
|
||
as to be de minimis, then the second work is not a derivative work of the
|
||
original.
|
||
|
||
\section{Analytic Dissection Test}
|
||
|
||
The Ninth Circuit has adopted the analytic dissection test to determine
|
||
whether one program is a derivative work of another. Apple Computer,
|
||
Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic
|
||
dissection test first considers whether there are substantial similarities
|
||
in both the ideas and expressions of the two works at issue. Once the
|
||
similar features are identified, analytic dissection is used to determine
|
||
whether any of those similar features are protected by copyright. This
|
||
step is the same as the filtration step in the AFC test. After identifying
|
||
the copyrightable similar features of the works, the court then decides
|
||
whether those features are entitled to ``broad'' or ``thin''
|
||
protection. ``Thin'' protection is given to non-copyrightable facts or
|
||
ideas that are combined in a way that affords copyright protection only
|
||
from their alignment and presentation, while ``broad'' protection is given
|
||
to copyrightable expression itself. Depending on the degree of protection
|
||
afforded, the court then sets the appropriate standard for a subjective
|
||
comparison of the works to determine whether, as a whole, they are
|
||
sufficiently similar to support a finding that one is a derivative work of
|
||
the other. ``Thin'' protection requires the second work be virtually
|
||
identical in order to be held a derivative work of an original, while
|
||
``broad'' protection requires only a ``substantial similarity.''
|
||
|
||
\section{No Protection for ``Methods of Operation''}
|
||
|
||
The First Circuit has taken the position that the AFC test is inapplicable
|
||
when the works in question relate to unprotectable elements set forth in
|
||
\S~102(b). Their approach results in a much narrower definition
|
||
of derivative work for software in comparison to other circuits. Specifically,
|
||
the
|
||
First Circuit holds that ``method of operation,'' as used in \S~102(b) of
|
||
the Copyright Act, refers to the means by which users operate
|
||
computers. Lotus Development Corp. v. Borland Intl., 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 programs 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 Circuits test, literal copying
|
||
of a menu command hierarchy, or any other ``method of operation,'' cannot
|
||
form the basis for a determination that one work is a derivative of
|
||
another. As a result, courts in the First Circuit that apply the AFC test
|
||
do so only after applying a broad interpretation of \S~102(b) to filter out
|
||
unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc.,
|
||
683 F. Supp.2d 147, 154 (D. Mass. 2010).
|
||
|
||
|
||
\section{No Test Yet Adopted}
|
||
|
||
Several circuits, most notably the Fourth and Seventh, have yet to
|
||
declare their definition of derivative work and whether or not the
|
||
AFC, Analytic Dissection, or some other test best fits their
|
||
interpretation of copyright law. Therefore, uncertainty exists with
|
||
respect to determining the extent to which a software program is a
|
||
derivative work of another in those circuits. However, one may presume
|
||
that they would give deference to the AFC test since it is by far the
|
||
majority rule amongst those circuits that have a standard for defining
|
||
a software derivative work.
|
||
|
||
\section{Cases Applying Software Derivative Work Analysis}
|
||
|
||
In the preeminent case regarding the definition of a derivative work for
|
||
software, Computer Associates v. Altai, the plaintiff alleged that its
|
||
program, Adapter, which was used to handle the differences in operating
|
||
system calls and services, was infringed by the defendant's competitive
|
||
program, Oscar. About 30\% of Oscar was literally the same code as
|
||
that in Adapter. After the suit began, the defendant rewrote those
|
||
portions of Oscar that contained Adapter code in order to produce a new
|
||
version of Oscar that was functionally competitive with Adapter, without
|
||
have any literal copies of its code. Feeling slighted still, the
|
||
plaintiff alleged that even the second version of Oscar, despite having no
|
||
literally copied code, also infringed its copyrights. In addressing that
|
||
question, the Second Circuit promulgated the AFC test.
|
||
|
||
In abstracting the various levels of the program, the court noted a
|
||
similarity between the two programs' parameter lists and macros. However,
|
||
following the filtration step of the AFC test, only a handful of the lists
|
||
and macros were protectable under copyright law because they were either
|
||
in the public domain or required by functional demands on the
|
||
program. With respect to the handful of parameter lists and macros that
|
||
did qualify for copyright protection, after performing the comparison step
|
||
of the AFC test, it was reasonable for the district court to conclude that
|
||
they did not warrant a finding of infringement given their relatively minor
|
||
contribution to the program as a whole. Likewise, the similarity between
|
||
the organizational charts of the two programs was not substantial enough
|
||
to support a finding of infringement because they were too simple and
|
||
obvious to contain any original expression.
|
||
|
||
In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012),
|
||
the Northern District of California District Court examined the question of
|
||
whether the application program interfaces (APIs) associated with the Java
|
||
programming language are entitled to copyright protection. While the
|
||
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
|
||
compatability'' (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 overaggressiveness on the part of the plaintiff.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
|
||
\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
|
||
modifies 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 in tact
|
||
here as well. However, there are three additional requirements.
|
||
|
||
The first (GPLv2~\S2(a)) requires that modified files carry ``prominent
|
||
notices'' explaining what changes were made and the date of such
|
||
changes. This section does not prescribe some specific way of
|
||
marking changes nor does it control the process of how changes are made.
|
||
Primarily, GPLv2~\S2(a) seeks to ensure that those receiving modified
|
||
versions know the history of changes to the software. For some users,
|
||
it is important to know that they are using the standard version of
|
||
program, because while there are many advantages to using a fork,
|
||
there are a few disadvantages. Users should be informed about the
|
||
historical context of the software version they use, so that they can
|
||
make proper support choices. Finally, GPLv2~\S2(a) serves an academic
|
||
purpose --- ensuring that future developers can use a diachronic
|
||
approach to understand the software.
|
||
|
||
\medskip
|
||
|
||
The second requirement (GPLv2~\S2(b)) contains the four short lines that embody
|
||
the legal details of ``share and share alike''. These 46 words are
|
||
considered by some to be the most worthy of careful scrutiny because
|
||
GPLv2~\S2(b), and they
|
||
can be a source of great confusion when not properly understood.
|
||
|
||
In considering GPLv2~\S2(b), first note the qualifier: it \textit{only} applies to
|
||
derivative 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} to 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 an {\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 what the copyright law says is a derivative
|
||
work. 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 is
|
||
distributing or publishing a work that is deemed a derivative work under
|
||
copyright law --- 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 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{}. GPL's pregranted
|
||
permission to create and distribute derivative works, provided the terms
|
||
of 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 restriction is any way unreasonable is simply ludicrous.)
|
||
|
||
\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 redistributors 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 redistributors 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 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 redistributors to license the derivative works 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 derivative work of 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
|
||
expended 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.
|
||
|
||
\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 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
|
||
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 derivative 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 derivative 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).
|
||
|
||
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.
|
||
|
||
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 derivative 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 infeasible.
|
||
|
||
\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 GPLv22 was first published in June
|
||
1991, distribution on magnetic tape was still common, and CD was
|
||
relatively new. By 2002, CD is the default. By 2007, DVD's were the
|
||
default. Now, it's common to give software on USB drives and SD card. This
|
||
language in the license must adapt with changing technology.
|
||
|
||
Meanwhile, the binding created by the word ``customarily'' is key. Many
|
||
incorrectly believe that distributing binary on CD and source on the
|
||
Internet is acceptable. In the corporate world in industrialized countries, it is indeed customary to
|
||
simply download a CDs' worth of data quickly. However, even today in the USA, many computer users are not connected to the Internet, and most people connected
|
||
to the Internet still have limited download speeds. Downloading
|
||
CDs full of data is not customary for them in the least. In some cities
|
||
in Africa, computers are becoming more common, but Internet connectivity
|
||
is still available only at a few centralized locations. Thus, the
|
||
``customs'' here are normalized for a worldwide userbase. Simply
|
||
providing source on the Internet --- while it is a kind, friendly and
|
||
useful thing to do --- is not usually sufficient.
|
||
|
||
Note, however, a major exception to this rule, given by the last paragraph
|
||
of GPLv2~\S3. \emph{If} distribution of the binary files is made only on the
|
||
Internet (i.e., ``from a designated place''), \emph{then} simply providing
|
||
the source code right alongside the binaries in the same place is
|
||
sufficient to comply with GPLv2~\S3.
|
||
|
||
\medskip
|
||
|
||
As is shown above, Under GPLv2~\S3(a), embedded manufacturers can put the
|
||
binaries on the device and ship the source code along on a CD\@. However,
|
||
sometimes this turns out to be too costly. Including a CD with every
|
||
device could prove too costly, and may practically (although not legally)
|
||
prohibit using GPL'd software. For this situation and others like it, GPLv2\S~3(b) is available.
|
||
|
||
GPLv2~\S3(b) allows a distributor of binaries to instead provide a written
|
||
offer for source code alongside those binaries. This is useful in two
|
||
specific ways. First, it may turn out that most users do not request the
|
||
source, and thus the cost of producing the CDs is saved --- a financial
|
||
and environmental windfall. In addition, along with a GPLv2~\S3(b) compliant
|
||
offer for source, a binary distributor might choose to \emph{also} give a
|
||
URL for source code. Many who would otherwise need a CD with source might
|
||
turn out to have those coveted high bandwidth connections, and are able to
|
||
download the source instead --- again yielding environmental and financial
|
||
windfalls.
|
||
|
||
However, note that regardless of how many users prefer to get the
|
||
source online, GPLv2~\S3(b) does place lasting long-term obligations on the
|
||
binary distributor. The binary distributor must be prepared to honor
|
||
that offer for source for three years and ship it out (just as they
|
||
would have had to do under GPLv2~\S3(a)) at a moment's notice when they
|
||
receive such a request. There is real organizational cost here:
|
||
support engineers must be trained how to route source requests, and
|
||
source CD images for every release version for the last three years
|
||
must be kept on hand to burn such CDs quickly. The requests might not
|
||
even come from actual customers; the offer for source must be valid
|
||
for ``any third party''.
|
||
|
||
That phrase is another place where some get confused --- thinking again
|
||
that full public distribution of source is required. The offer for source
|
||
must be valid for ``any third party'' because of the freedoms of
|
||
redistribution granted by GPLv2~\S\S1--2. A company may ship a binary image
|
||
and an offer for source to only one customer. However, under GPL, that
|
||
customer has the right to redistribute that software to the world if she
|
||
likes. When she does, that customer has an obligation to make sure that
|
||
those who receive the software from her can exercise their freedoms under
|
||
GPL --- including the freedom to modify, rebuild, and redistribute the
|
||
source code.
|
||
|
||
GPLv2~\S3(c) is created to save her some trouble, because by itself GPLv2~\S3(b)
|
||
would unfairly favor large companies. GPLv2~\S3(b) allows the
|
||
separation of the binary software from the key tool that people can use
|
||
to exercise their freedom. The GPL permits this separation because it is
|
||
good for redistributors, 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 who
|
||
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 derivative 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 amongst 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 software program under the GPLv2, then it
|
||
cannot assert the patent against any party based on that party's use of
|
||
Company \compA{}'s GPL'ed Web browsing software program, or on that party's
|
||
creation and use of derivative works of that GPL'ed program. However, if a
|
||
party uses that program without
|
||
complying with the GPLv2, then Company \compA{} can assert both copyright
|
||
infringement claims against the non-GPLv2-compliant party and
|
||
infringement of the patent, because the implied patent license only
|
||
extends to use of the software in accordance with the GPLv2. Further, if
|
||
Company \compB{} distributes a competitive advanced Web browsing program
|
||
that is not a derivative work of Company \compA{}'s GPL'ed 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 looses 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 decided 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 transfered 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 GPL, and nothing in
|
||
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.
|
||
|
||
\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.
|
||
|
||
\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 discussed 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 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 of 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 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 statue. 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''}
|
||
|
||
One of lawyers' most common complaints about GPLv2 is that defined terms in
|
||
the document appear throughout. Most licenses define terms up-front.
|
||
However, 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}
|
||
|
||
GPLv2 included a defined term, ``work based on the Program'', but also used
|
||
the term ``modify'' and ``based on'' throughout the license. GPLv2's ``work
|
||
based on the Program'' definition made use of a legal term of art,
|
||
``derivative work'', which is peculiar to USA copyright law. However,
|
||
ironically, the most criticism of USA-specific legal terminology in GPLv2's
|
||
``work based on the Program'' definition historically came not primarily from
|
||
readers outside the USA, but from those within it\footnote{The FSF noted in
|
||
that it did not generally agree with these views, and expressed puzzlement
|
||
by the energy with which they were expressed, given the existence of many
|
||
other, more difficult legal issues implicated by the GPL. Nevertheless,
|
||
the FSF argued that it made sense to eliminate usage of local copyright
|
||
terminology to good effect.}. Admittedly, even though differently-labeled
|
||
concepts corresponding to the derivative work are recognized in all copyright
|
||
law systems, these counterpart concepts might differ to some degree in scope
|
||
and breadth from the USA derivative work.
|
||
|
||
The goal and intention of GPLv2 was always to cover all rights governed by
|
||
relevant copyright law, in the USA and elsewhere. GPLv3 therefore takes the
|
||
task of internationalizing the license further by removing references to
|
||
derivative works and by providing a more globally useful definition. The new
|
||
definition returns to the common elements of copyright law. Copyright
|
||
holders of works of software have the exclusive right to form new works by
|
||
modification of the original --- a right that may be expressed in various
|
||
ways in different legal systems. GPLv3 operates to grant this right to
|
||
successive generations of users (particularly through the copyleft conditions
|
||
set forth in GPLv3~\S5, as described later in this tutorial in its
|
||
\S~\ref{GPLv3s5}). Here in GPLv3~\S0, ``modify'' refers to basic copyright
|
||
rights, and then this definition of ``modify'' is used to define ``modified
|
||
version of'' and ``work based on,'' as synonyms.
|
||
|
||
\section{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.
|
||
|
||
\section{Propagate}
|
||
|
||
The term ``propagate'' serves two purposes. First, ``propagate'' provides a
|
||
simple and convenient means for distinguishing between the kinds of uses of a
|
||
work that GPL imposes conditions on and the kinds of uses that GPL does not
|
||
(for the most part) impose conditions on.
|
||
|
||
Second, ``propagate'' helps globalize GPL in its wording and effect. When a
|
||
work is GPL'd, the copyright law of some particular country will govern
|
||
certain legal issues arising under the license. A term like ``distribute''
|
||
(or its equivalent in languages other than English) is used in several
|
||
national copyright statutes. Yet, practical experience with GPLv2 revealed
|
||
the awkwardness of using the term ``distribution'' in a license intended for
|
||
global use: the scope of ``distribution'' in the copyright context can differ
|
||
from country to country. The GPL never necessarily intended the specific
|
||
meaning of ``distribution'' that exists under USA (or any other country's)
|
||
copyright law.
|
||
|
||
Indeed, even within a single country and language, the term distribution may
|
||
be ambiguous; as a legal term of art, distribution varies significantly in
|
||
meaning among those countries that recognize it. For example, comments
|
||
during GPLv3's drafting process indicated that in at least one country,
|
||
distribution may not include network transfers of software but may include
|
||
interdepartmental transfers of physical copies within an organization.
|
||
Meanwhile, the copyright laws of many countries, as well as certain
|
||
international copyright treaties, recognize ``making available to the
|
||
public'' or ``communication to the public'' as one of the exclusive rights of
|
||
copyright holders.
|
||
|
||
Therefore, the GPL defines the term ``propagate'' by reference to activities
|
||
that require permission under ``applicable copyright law'', but excludes
|
||
execution and private modification from the definition. GPLv3's definition
|
||
also gives examples of activities that may be included within ``propagation''
|
||
but it also makes clear that, under the copyright laws of a given country,
|
||
``propagation'' may include other activities as well.
|
||
|
||
Thus, propagation is defined by behavior, and not by categories drawn from
|
||
some particular national copyright statute. This helps not only with
|
||
internationalization, but also factually-based terminology aids in
|
||
developers' and users' understanding of GPL\@.
|
||
|
||
\section{Convey}
|
||
|
||
Further to this point, a subset of propagate --- ``convey'' --- is defined.
|
||
Conveying includes activities that constitute propagation of copies to
|
||
others. As with the definition of propagate, GPLv3 thus addresses transfers
|
||
of copies of software in behavioral rather than statutory terms.
|
||
|
||
\section{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.
|
||
|
||
\section{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}
|
||
|
||
Ensuring that users have the source code to the software they receive and the
|
||
freedom to modify remains the paramount right embodied in the Free Software
|
||
Definition (found in \S~\ref{Free Software Definition} of this tutorial). As
|
||
such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it
|
||
contains all the defined terms related to this important software freedom.
|
||
|
||
\subsection{Source Code Definition}
|
||
|
||
First, GPLv3\~S1 retains GPLv2's definition of ``source code'' and adds an
|
||
explicit definition of ``object code'' as ``any non-source version of a
|
||
work''. Object code is not restricted to a narrow technical meaning and is
|
||
understood broadly to include any form of the work other than the preferred
|
||
form for making modifications to it. Object code therefore includes any kind
|
||
of transformed version of source code, such as bytecode or minified
|
||
Javascript. The definition of object code also ensures that licensees cannot
|
||
escape their obligations under the GPL by resorting to shrouded source or
|
||
obfuscated programming.
|
||
|
||
\subsection{CCS Definition}
|
||
|
||
The definition of CCS\footnote{Note that the preferred term for those who
|
||
work regularly with both GPLv2 and GPLv3 is ``Complete Corresponding
|
||
Source'', abbreviated to ``CCS''. Admittedly, the word ``complete'' no
|
||
longer appears in GPLv3 (which uses the word ``all'' instead). However,
|
||
both GPLv2 and the early drafts of GPLv3 itself used the word ``complete'',
|
||
and early GPLv3 drafts even called this defined term ``Complete
|
||
Corresponding Source''. Meanwhile, use of the acronym ``CCS'' (sometimes,
|
||
``C\&CS'') was so widespread among GPL enforcers that its use continues
|
||
even though GPLv3-focused experts tend to say just the defined term of
|
||
``Corresponding Source''.}, or, as GPLv3 officially calls it,
|
||
``Corresponding Source'' in GPLv3~\S1\P4 is possibly the most complex
|
||
definition in the license.
|
||
|
||
The CCS definition is broad so as to protect users' exercise of their rights
|
||
under the GPL\@. The definition includes with particular examples to remove
|
||
any doubt that they are to be considered CCS\@. GPLv3 seeks to make it
|
||
completely clear that a licensee cannot avoid complying with the requirements
|
||
of the GPL by dynamically linking a subprogram component to the original
|
||
version of a program. The example also clarifies that the shared libraries
|
||
and dynamically linked subprograms that are included in Corresponding Source
|
||
are those that the work is ``specifically'' designed to require, which
|
||
clarifies that they do not include libraries invoked by the work that can be
|
||
readily substituted by other existing implementations. While copyleft
|
||
advocates never doubted this was required under GPLv2's definition of CCS,
|
||
making it abundantly clear with an extra example.
|
||
|
||
GPL, as always, seeks to ensure users are truly in a position to install and
|
||
run their modified versions of the program; the CCS definition is designed to
|
||
be expansive to ensure this software freedom. However, although the
|
||
definition of CCS is expansive, it is not sufficient to protect users'
|
||
freedoms in many circumstances. For example, a GPL'd program, or a modified
|
||
version of such a program, might be locked-down and restricted. The
|
||
requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this
|
||
tutorial) handle that issue. (Early drafts of GPLv3 included those
|
||
requirements in the definition of CCS; however, given that the lock-down
|
||
issue only comes up in distribution of object code, it is more logical to
|
||
place those requirements with the parts of GPLv3 dealing directly with object
|
||
code distribution).
|
||
|
||
The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does
|
||
not require source that can be automatically generated. Many code
|
||
generators, preprocessors and take source code as input and sometimes even
|
||
have output that is still source code. Source code should always be whatever
|
||
the original programmer preferred to modify.
|
||
|
||
GPLv3\S1's final paragraph removes any ambiguity about what should be done on
|
||
source-only distributions. Specifically, the right to convey source code
|
||
that does not compile, does not work, or otherwise is experimental
|
||
in-progress work is fully permitted, \textit{provided that} no object code
|
||
form is conveyed as well. Indeed, when combined with the permissions in
|
||
GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can
|
||
never be required to provide more than that. One always has the right to
|
||
modify a source code work by deleting any part of it, and there can be no
|
||
requirement that free software source code be a whole functioning program.
|
||
|
||
\subsection{The System Library Exception}
|
||
|
||
The previous section skipped over one part of the CCS definition, the
|
||
so-called system library exception. The ``System Libraries'' definition (and
|
||
the ``Standard Interface'' and ``Major Component'' definitions, which it
|
||
includes) are designed as part
|
||
|
||
to permit certain distribution arrangements that are considered reasonable by
|
||
copyleft advocates. The system library exception is designed to allow
|
||
copylefted software to link with these libraries when such 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 replaces 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 the
|
||
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}
|
||
|
||
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.
|
||
|
||
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, contractors gets the
|
||
full freedoms of the GPL that they deserve.
|
||
|
||
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.
|
||
|
||
Large enterprise users of free software often contract with non-employee
|
||
developers, often 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.
|
||
The practices seem basically harmless, so we have decided to make it
|
||
clear they are permitted.
|
||
|
||
|
||
\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 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 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 clarifies and revises GPLv2~\S3. It requires distributors of GPL'd
|
||
object code to provide access to the corresponding source code, in one of
|
||
four specified ways. As noted in \S~\ref{GPLv3s0}, ``object code'' in GPLv3
|
||
is defined broadly to mean any non-source version of a work.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
GPLv3~\S6(a--b) now apply specifically to distribution of object code in a
|
||
physical product. Physical products include embedded systems, as well as
|
||
physical software distribution media such as CDs. As in GPLv2~\S3 (discussed
|
||
in \S~\ref{GPLv2s3} of this tutorial), the distribution of object code may
|
||
either be accompanied by the machine-readable source code, or it may be
|
||
accompanied by a valid written offer to provide the machine-readable source
|
||
code. However, unlike in GPLv2, that offer cannot be exercised by any third
|
||
party; rather, only those ``who possesses the object code'' it can exercised
|
||
the offer. (Note that this is a substantial narrowing of requirements of
|
||
offer fulfillment, and is a wonderful counterexample to dispute claims that
|
||
the GPLv3 has more requirements than GPLv2.)
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
GPLv3~\S6(b) further revises the requirements for the written offer to
|
||
provide source code. As before, the offer must remain valid for at least
|
||
three years. In addition, even after three years, a distributor of a product
|
||
containing GPL'd object code must offer to provide source code for as long as
|
||
the distributor also continues to offer spare parts or customer support for
|
||
the product model. This is a reasonable and appropriate requirement; a
|
||
distributor should be prepared to provide source code if he or she is
|
||
prepared to provide support for other aspects of a physical product.
|
||
|
||
GPLv3~\S6(a--b) clarifies that the medium for software interchange on which
|
||
the machine-readable source code is provided must be a durable physical
|
||
medium. GPLv3~\S6(b)(2), however, permits a distributor to instead offer to
|
||
provide source code from a network server instead, which is yet another
|
||
example GPLv3 looser in its requirements than GPLv2 (see
|
||
\S~\ref{GPLv2s3-medium-customarily} for details).
|
||
|
||
% FIXME-LATER: more information about source provision, cost of physically
|
||
% performing, reasonable fees, medium customary clearly being said durable
|
||
% connecting back to previous text
|
||
|
||
GPLv3\S6(c) gives narrower permission than GPLv2\S3(c). The ``pass along''
|
||
option for GPLv3\S6(c)(1) offers is now available only for individual
|
||
distribution of object code; moreover, such individual distribution can occur
|
||
only ``occasionally and noncommercially.'' A distributor cannot comply with
|
||
the GPL merely by making object code available on a publicly-accessible
|
||
network server accompanied by a copy of the written offer to provide source
|
||
code received from an upstream distributor.
|
||
|
||
%FIXME-LATER: tie back to the discussion of the occasional offer pass along
|
||
% stuff in GPLv2 this tutorial.
|
||
|
||
GPLv3~\S6(d) revises and improves GPLv2~\S3's final paragraph. When object
|
||
code is provided by offering access to copy the code from a designated place
|
||
(such as by enabling electronic access to a network server), the distributor
|
||
must merely offer equivalent access to copy the source code ``in the same way
|
||
through the same place''. This wording also permits a distributor to offer a
|
||
third party access to both object code and source code on a single network
|
||
portal or web page, even though the access may include links to different
|
||
physical servers. For example, a downstream distributor may provide a link
|
||
to an upstream distributor's server and arrange with the operator of that
|
||
server to keep the source code available for copying for as long as the
|
||
downstream distributor enables access to the object code. This codifies
|
||
formally 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}
|
||
|
||
Certain decentralized forms of peer-to-peer file sharing present a challenge
|
||
to the unidirectional view of distribution that is implicit in GPLv2 and
|
||
Draft 1 of GPLv3. It is neither straightforward nor reasonable to identify
|
||
an upstream/downstream link in BitTorrent distribution; such distribution is
|
||
multidirectional, cooperative and anonymous. In systems like BitTorrent,
|
||
participants act both as transmitters and recipients of blocks of a
|
||
particular file, but they see themselves 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.
|
||
|
||
% FIXME: rewrite a bit.
|
||
|
||
The GPL 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 BitTorrent distribution of binaries if
|
||
they are packaged together with the source code, but this impractical, for at
|
||
least two reasons. First, even if the source code is packaged with the
|
||
binary, 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, functioning rather like a router or a
|
||
cache proxy. Second, in practice BitTorrent and similar peer-to-peer forms
|
||
of transmission have been less suitable means for distributing source code.
|
||
In large distributions, packaging source code with the binary may result in a
|
||
substantial increase in file size and transmission time. Source code
|
||
packages themselves tend not to be transmitted through BitTorrent owing to
|
||
reduced demand. There generally will be too few participants downloading the
|
||
same source package at the same time to enable effective seeding and
|
||
distribution.
|
||
|
||
% FIXME: rewrite a bit.
|
||
|
||
We have made two changes that recognize and facilitate distribution of
|
||
covered works in object code form using BitTorrent or similar peer-to-peer
|
||
methods. First, under new subsection 6e, if a licensee conveys such a work
|
||
using peer-to-peer transmission, that licensee is in compliance with section
|
||
6 so long as the licensee knows, and informs other peers where, the object
|
||
code and its Corresponding Source are publicly available at no charge under
|
||
subsection 6d. The Corresponding Source therefore need not be provided
|
||
through the peer-to-peer system that was used for providing the binary.
|
||
Second, we have revised section 9 to make clear 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: where does this go?
|
||
|
||
Informing the peers is clearly enough; what seemed to be an additional
|
||
knowledge requirement was superfluous wording.
|
||
|
||
% 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!
|
||
|
||
% FIXME: Not final paragraph anymore.
|
||
|
||
The final paragraph of section 6 takes account of the fact that the Complete
|
||
Corresponding Source Code may include added parts that carry non-GPL terms,
|
||
as permitted by section 7.
|
||
|
||
% FIXME: update lock-down section to work with more recent drafts
|
||
|
||
Though the definition of Complete Corresponding Source Code in the second
|
||
paragraph of section 1 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 need to be signed with a key or authorized
|
||
with a code in order for it to run on a particular machine and function
|
||
properly. Similarly, a program that produces digitally-restricted files might
|
||
require a decryption code in order to read the output.
|
||
|
||
The third paragraph of section 1 addresses this problem by making clear that
|
||
Complete Corresponding Source Code includes any such encryption,
|
||
authorization, and decryption codes. By requiring the inclusion of this
|
||
information whenever the GPL requires distribution of Complete Corresponding
|
||
Source Code, we thwart efforts to obstruct the goals of the GPL, and we
|
||
ensure that users will remain in control over their own machines. We
|
||
recognize an exception where use of the program normally implies that the
|
||
user already has the codes. For example, in secure systems a computer owner
|
||
might possess any keys needed to run a program, while the distributor of the
|
||
program might not have the keys.
|
||
|
||
% FIXME: installation information??
|
||
|
||
|
||
% FIXME: perhaps this additional information isn't needed, next 3 paras, but
|
||
% there might be something good here
|
||
|
||
Another major goal for GPLv3 has been to thwart technical measures such as
|
||
signature checks in hardware to prevent modification of GPLed software on a
|
||
device. Previous drafts attempted to accomplish this by defining
|
||
"Corresponding Source" to include any encryption or authorization keys
|
||
necessary to install new versions of the software. A number of members of
|
||
the community questioned the impact and utility of such a definition.
|
||
|
||
The third discussion draft uses a different strategy to accomplish the same
|
||
task. Section 6 requires that parties distributing object code provide
|
||
recipients with the source code through certain means. Now, when those
|
||
distributors pass on the source, they are also required to pass on any
|
||
information or data necessary to install modified software on the
|
||
particular device that included it. We believe that this will more
|
||
precisely accomplish our goals, and avoid potential problems with expanding
|
||
the definition of source code. The new strategy should be familiar to free
|
||
software developers: the GNU LGPL has long had similar requirements that
|
||
enable users to link proprietary programs to modified libraries.
|
||
|
||
\label{user-product}
|
||
In addition, the scope of these requirements has been narrowed. This draft
|
||
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. After some discussion with committees, we discovered
|
||
that the proposals in the second discussion draft would interfere with a
|
||
number of existing business models that don't seem to be dangerous. We
|
||
believe that this compromise will achieve the greatest success in
|
||
preventing tivoization.
|
||
|
||
In brief, we condition the right to convey object code in a defined class of
|
||
``User Products,'' under certain circumstances, on providing whatever
|
||
information is required to enable a recipient to replace the object code with
|
||
a functioning modified version.
|
||
|
||
%FIXME: this really big section on user product stuff may be too much for the
|
||
% tutorial
|
||
|
||
In our earlier drafts, the requirement to provide encryption keys
|
||
applied to all acts of conveying object code, as this requirement was
|
||
part of the general definition of Corresponding Source. Section 6 of
|
||
Draft 3 now limits the applicability of the technical restrictions
|
||
provisions to object code conveyed in, with, or specifically for use in
|
||
a defined class of ``User Products.''
|
||
|
||
In our discussions with companies and governments that use specialized
|
||
or enterprise-level computer facilities, we found that sometimes these
|
||
organizations actually 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 preference. It is not clear that we
|
||
need to interfere, and 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, and we expect that to remain true in
|
||
the near future. 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 if limited to User Products, as defined in Draft 3, the
|
||
provision still does the job that needs to be done. Therefore we have
|
||
decided to limit the technical restrictions provisions to User Products
|
||
in this draft.
|
||
|
||
The core of the User Product definition is a subdefinition of ``consumer
|
||
product'' taken verbatim from the Magnuson-Moss Warranty Act, a federal
|
||
consumer protection law in the United States: ``any tangible personal
|
||
property which is normally used for personal, family, or household
|
||
purposes.''\footnote{15 U.S.C.~\S\ 2301.} The United States 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 United States and Canada, having been
|
||
adopted in several state and provincial consumer protection laws.} We
|
||
mean for this body of interpretation to guide interpretation of the
|
||
consumer product subdefinition in section 6, which will provide a degree
|
||
of legal certainty advantageous to device manufacturers and downstream
|
||
licensees alike. Our incorporation of such legal interpretation is in
|
||
no way intended to work a general choice of United States law for GPLv3
|
||
as a whole. The paragraph in section 6 defining ``User Product'' and
|
||
``consumer product'' contains an explicit statement to this effect,
|
||
bracketed for discussion. We will decide whether to retain this
|
||
statement in the license text after gathering comment on it.
|
||
|
||
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
|
||
C.F.R.~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54
|
||
U.C.C.~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 C.F.R. \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.}
|
||
|
||
We do not rely solely on the definition of consumer product, however,
|
||
because in the area of components of dwellings we consider the settled
|
||
interpretation under Magnuson-Moss underinclusive. 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, we define User Products as a
|
||
superset of consumer products that also includes ``anything designed or
|
||
sold for incorporation into a dwelling.''
|
||
|
||
Although the User Products rule of Draft 3 reflects a special concern
|
||
for individual purchasers of devices, we wrote the rule to cover a
|
||
category of products, rather than categorizing users. Discrimination
|
||
against organizational users has no place in a free software license.
|
||
Moreover, a rule that applied to individual use, rather than to use of
|
||
products normally used by individuals, would have too narrow an
|
||
effect. Because of its incorporation of the liberal Magnuson-Moss
|
||
interpretation of ``consumer product,'' the User Products rule benefits
|
||
not only individual purchasers of User Products but also all
|
||
organizational purchasers of those same kinds of products, regardless of
|
||
their intended use of the products.
|
||
|
||
we have replaced the Magnuson-Moss
|
||
reference with three sentences that encapsulate the judicial and
|
||
administrative principles established over the past three decades in the
|
||
United States concerning the Magnuson-Moss consumer product definition.
|
||
First, we state that doubtful cases are resolved in favor of coverage
|
||
under the definition. Second, we 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, we make clear 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, contrary
|
||
to what some critics of Draft 3 have suggested.
|
||
|
||
We have made one additional change to the User Products provisions of
|
||
section 6. In Draft 3 we made clear that the requirement to provide
|
||
Installation Information implies no requirement to provide warranty or
|
||
support for a work that has been modified or installed on a User
|
||
Product. The Final Draft adds that there is similarly no requirement to
|
||
provide warranty or support for the User Product itself.
|
||
|
||
% FIXME: this needs integration
|
||
|
||
In Draft 3 we instead use a definition of ``Installation Information'' in
|
||
section 6 that is as simple and clear as that goal. Installation Information
|
||
is information that is ``required to install and execute modified versions of
|
||
a covered work \dots from a modified version of its Corresponding Source,''
|
||
in the same User Product for which the covered work is conveyed. We provide
|
||
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.''
|
||
|
||
%FIXME: This probably needs work to be brought into clarity with tutorial,
|
||
%next three paragarphs.
|
||
|
||
Why do distributors only have to provide Installation Information for User
|
||
Products?
|
||
|
||
Some companies effectively outsource their entire IT department to another
|
||
company. Computers and applications are installed in the company's offices,
|
||
but managed remotely by some service provider. In some of these situations,
|
||
the hardware is locked down; only the service provider has the key, and the
|
||
customers consider that to be a desirable security feature.
|
||
|
||
We think it's unfortunate that people would be willing to give up their
|
||
freedom like this. But they should be able to fend for themselves, and the
|
||
market provides plenty of alternatives to these services that would not lock
|
||
them down. As a result, we have introduced this compromise to the draft:
|
||
distributors are only required to provide Installation Information when
|
||
they're distributing the software on a User Product, where the customers'
|
||
buying power is likely to be less organized.
|
||
|
||
This is a compromise of strategy, and not our ideals. Given the environment
|
||
we live in today --- where Digital Restrictions Management is focused largely
|
||
in consumer devices, and everyone, including large companies, is becoming
|
||
increasingly worried about the effects of DRM thanks to recent developments
|
||
like the release of Microsoft's Windows Vista --- we think that the proposed
|
||
language will still provide us with enough leverage to effectively thwart
|
||
DRM. We still believe you have a fundamental right to modify the software on
|
||
all the hardware you own; the preamble explains, ``If such problems [as
|
||
locked-down hardware] arise substantially in other domains, we stand ready
|
||
to extend this provision to those domains in future versions of the GPL, as
|
||
needed to protect the freedom of users.''
|
||
|
||
The definition of Installation Information states that the information
|
||
provided ``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.'' We did not consider it necessary to
|
||
define ``continued functioning'' further. However, we believed it would be
|
||
appropriate to 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. We
|
||
make clear that GPLv3 implies no obligation ``to continue to provide support
|
||
service, warranty, or updates'' for such a work.
|
||
|
||
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. We settled on a rule that 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. We intend it to serve as a foundation
|
||
for development of reasonable enforcement policies that respect recipients'
|
||
right to modify while recognizing the legitimate interests of network
|
||
providers.
|
||
|
||
% FIXME: This needs merged in somewhere in here
|
||
|
||
The mere fact that use of the work implies that the user \textit{has} the key
|
||
may not be enough to ensure the user's freedom in using it. The user must
|
||
also be able to read and copy the key; thus, its presence in a special
|
||
register inside the computer does not satisfy the requirement. In an
|
||
application in which the user's personal key is used to protect privacy or
|
||
limit distribution of personal data, the user clearly has the ability to read
|
||
and copy the key, which therefore is not included in the Corresponding
|
||
Source. On the other hand, if a key is generated based on the object code, or
|
||
is present in hardware, but the user cannot manipulate that key, then the key
|
||
must be provided as part of the Corresponding Source.
|
||
|
||
% FIXME: this came from Section 1 but is now mostly in Section 6
|
||
|
||
In section 1, we have tried to limit as precisely as possible the situation
|
||
in which an encryption or signing key is part of the Corresponding Source
|
||
Code of a GPL'd work. Where someone is provided a GPL'd work, he must
|
||
receive the whole of the power to use and modify the work that was available
|
||
to preceding licensors whose permissions he automatically receives. If a key
|
||
would be necessary to install a fully functional version of the GPL'd work
|
||
from source code, the user who receives the binary must receive the key along
|
||
with the source. The requirement of full functionality, which we have
|
||
illustrated with examples, is no more optional than it would be if GPL'd
|
||
software were redistributed with an additional license condition, rather than
|
||
a technical limitation, on the uses to which modified versions could be
|
||
put.\footnote{There is a clear distinction between this situation and the
|
||
situation of authenticated modules or plug-ins distributed as part of a
|
||
multi-component software system, so that instances of the software can
|
||
verify for the user the integrity of the collection. So long as the
|
||
decision about whether to run a modified version is the user's decision,
|
||
not controlled by a preceding licensor or a third party, the vendor's
|
||
authentication key would also not qualify as part of the Corresponding
|
||
Source under the language we have adopted for Draft 2.}
|
||
|
||
% FIXME: this needs the right place.
|
||
|
||
We do not object to 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. What we find ethically objectionable is the
|
||
refusal to pass on to the downstream licensee the real right to modify,
|
||
coupled with the retention of that right in the device manufacturer or some
|
||
other party. Our text has never prohibited distribution in ROM, but we have
|
||
decided to make the point explicitly, for clarity's sake. Accordingly, our
|
||
text 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.''
|
||
|
||
%FIXME: publicly documented format. This might work as a start on that:
|
||
|
||
Our primary objective here was to ensure that the
|
||
distributor use a generally-recognized mechanism for packaging source
|
||
code.
|
||
|
||
\section{Understanding License Compatibility}
|
||
\label{license-compatibility}
|
||
|
||
% FIXME: more about license compatibility here.
|
||
|
||
A challenge that faced the Free Software community heavily through out the
|
||
early 2000s was the proliferation of incompatible Free Software licenses. Of
|
||
course, we cannot make the GPL compatible with all such licenses. 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.
|
||
|
||
% FIXME: connecting text
|
||
|
||
\subsection{Additional Permissions}
|
||
|
||
% FIXME: rework and fix formatting.
|
||
|
||
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. We
|
||
consider 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 ethical and interpretive
|
||
issues; in particular, additional requirements, if allowed without careful
|
||
limitation, could transform a GPL'd program into a non-free one. With these
|
||
principles in the background, section 7 answers the following questions: (1)
|
||
How do the presence of additional terms on all or part of a GPL'd program
|
||
affect users' rights? (2) When and how may a licensee add terms to code being
|
||
distributed under the GPL? (3) When may a licensee remove additional terms?
|
||
|
||
% FIXME: FSF third person, etc.
|
||
|
||
Additional permissions present the easier case. We have licensed some of our
|
||
own software under GPLv2 with permissive exceptions that allow combination
|
||
with non-free code, and that allow removal of those permissions by downstream
|
||
recipients; similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,
|
||
and it permits relicensing under the GPL. We have generalized these
|
||
practices in section 7. 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 subsection 7a explains, the effect of an additional permission depends on
|
||
whether the permission applies to the whole work or a part.
|
||
|
||
% FIXME: rework this a bit
|
||
|
||
We have drafted version 3 of the GNU LGPL, which we have released with Draft
|
||
2 of GPLv3, as a simple list of additional permissions supplementing the
|
||
terms of GPLv3. Section 7 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. We offer this draft of
|
||
LGPLv3 as as a model for developers wishing to license their works under the
|
||
GPL with permissive exceptions. The removability of additional permissions
|
||
under section 7 does not alter any existing behavior of the LGPL; the LGPL
|
||
has always allowed relicensing under the ordinary GPL.
|
||
|
||
\subsection{Additional Requirements and License Compatibility}
|
||
|
||
% FIXME: minor rewrites needed
|
||
|
||
We broadened the title of section 7 because license compatibility, as it is
|
||
conventionally understood, is only one of several facets of the placement of
|
||
additional terms on GPL'd code. The 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 free software 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.
|
||
|
||
% FIXME: minor rewrites needed
|
||
|
||
Section 7 relaxes the prohibition on further restrictions slightly by
|
||
enumerating, in subsection 7b, a limited list of categories of additional
|
||
requirements that may be placed on code without violating GPLv3. The list
|
||
includes the items that were listed in Draft 1, though rewritten for clarity.
|
||
It also includes a new catchall category for terms that might not obviously
|
||
fall within one of the other categories but which are precisely equivalent to
|
||
GPLv3 conditions, or which deny permission for activities clearly not
|
||
permitted by GPLv3. We have carefully considered but rejected proposals to
|
||
expand this list further. We have also rejected suggestions, made by some
|
||
discussion committee members, that the Affero clause requirement (7d in Draft
|
||
1 and 7b4 in Draft 2) be removed, though we have revised it in response to
|
||
certain comments. We are unwavering in our view that the Affero requirement
|
||
is a legitimate one, and we are committed to achieving compatibility of the
|
||
Affero GPL with GPLv3.
|
||
|
||
% FIXME: minor rewrites needed
|
||
|
||
A GPL licensee may place an additional requirement on code for which the
|
||
licensee has or can give appropriate copyright permission, but only if that
|
||
requirement falls within the list given in subsection 7b. Placement of any
|
||
other kind of additional requirement continues to be a violation of the
|
||
license. Additional requirements that are in the 7b list may not be removed,
|
||
but if a user receives GPL'd code that purports to include an additional
|
||
requirement not in the 7b list, the user may remove that requirement. Here
|
||
we were particularly concerned to address the problem of program authors who
|
||
purport to license their works in a misleading and possibly
|
||
self-contradictory fashion, using the GPL together with unacceptable added
|
||
restrictions that would make those works non-free software.
|
||
|
||
\section{GPLv3~\S7: Explicit Compatibility}
|
||
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
In GPLv3 we take a new approach to the issue of combining GPL'd code with
|
||
code governed by the terms of other free software licenses. Our view, though
|
||
it was not explicitly stated in GPLv2 itself, was 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, we supplemented this policy with a structure of
|
||
exceptions for certain kinds of combinations.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
Section 7 of GPLv3 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. We
|
||
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.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
Section 7 first explicitly allows added parts covered by terms with
|
||
additional permissions to be combined with GPL'd code. This codifies our
|
||
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.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
In its treatment of terms that impose additional requirements, section 7
|
||
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 section 7. We
|
||
must, of course, place some limit on the kinds of additional requirements
|
||
that we will accept, to ensure that enhanced license compatibility does not
|
||
defeat the broader freedoms advanced by 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 no such user
|
||
would have the right to do so.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
Under subsections 7a and 7b, the requirements may include preservation of
|
||
copyright notices, information about the origins of the code or alterations
|
||
of the code, and different warranty disclaimers. Under subsection 7c, the
|
||
requirements may include limitations on the use of names of contributors and
|
||
on the use of trademarks for publicity purposes. In general, we permit these
|
||
requirements in added terms because many free software licenses include them
|
||
and we consider them to be unobjectionable. Because we support trademark fair
|
||
use, the limitations on the use of trademarks may seek to enforce only what
|
||
is required by trademark law, and may not prohibit what would constitute fair
|
||
use.
|
||
|
||
% FIXME: 7d-f
|
||
|
||
|
||
% FIXME: removing additional restrictions
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
Section 7 requires a downstream user of a covered work to preserve the
|
||
non-GPL terms covering the added parts just as they must preserve the GPL, as
|
||
long as any substantial portion of those parts is present in the user's
|
||
version.
|
||
|
||
% FIXME: minor rewrites needed
|
||
|
||
Section 7 points out that GPLv3 itself makes no assertion that an additional
|
||
requirement is enforceable by the copyright holder. However, section 7 makes
|
||
clear that enforcement of such requirements is expected to be by the
|
||
termination procedure given in section 8 of GPLv3.
|
||
|
||
% FIXME: better context, etc.
|
||
|
||
Some have questioned whether section 7 is needed, and some have suggested
|
||
that it creates complexity that did not previously exist. We point out to
|
||
those readers that there is already GPLv2-licensed code that carries
|
||
additional terms. One of the objectives of section 7 is to rationalize
|
||
existing practices of program authors and modifiers by setting clear
|
||
guidelines regarding the removal and addition of such terms. With its
|
||
carefully limited list of allowed additional requirements, section 7
|
||
accomplishes additional objectives, permitting the expansion of the base of
|
||
code available for GPL developers, while also encouraging useful
|
||
experimentation with requirements we do not include in the GPL itself.
|
||
|
||
\section{GPLv3~\S8: A Lighter Termination}
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
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 would need to obtain forgiveness from all
|
||
copyright holders, but even to contact them all might be impossible.
|
||
|
||
% FIXME: needs to be updated to describe more complex termination
|
||
|
||
Section 8 of GPLv3 replaces automatic termination with a non-automatic
|
||
termination process. Any copyright holder for the licensed work may opt to
|
||
terminate the rights of a violator of the license, provided that the
|
||
copyright holder has first given notice of the violation within 60 days of
|
||
its most recent occurrence. A violator who has been given notice may make
|
||
efforts to enter into compliance and may request that the copyright holder
|
||
agree not exercise the right of termination; the copyright holder may choose
|
||
to grant or refuse this request.
|
||
|
||
% FIXME: needs to be updated to describe more complex termination
|
||
|
||
If a licensee who is in violation of GPLv3 acts to correct the violation and
|
||
enter into compliance, and the licensee receives no notice of the past
|
||
violation within 60 days, then the licensee need not worry about termination
|
||
of rights under the license.
|
||
|
||
In Draft 3 the termination provision of section 8 has been revised to
|
||
indicate that, if a licensee violates the GPL, a contributor may terminate
|
||
any patent licenses that it granted under the first paragraph of section 11
|
||
to that licensee, in addition to any copyright permissions the contributor
|
||
granted to the licensee. Therefore, a contributor may terminate the patent
|
||
licenses it granted to a downstream licensee who brings patent infringement
|
||
litigation in violation of section 10.
|
||
|
||
We have made two substantive changes to section 8. First, we have clarified
|
||
that patent rights granted under the GPL are among the rights that a
|
||
copyright holder may terminate under section 8. Therefore, a contributor who
|
||
grants a patent license under the first paragraph of section 11 may terminate
|
||
that patent license, just as that contributor may terminate copyright rights,
|
||
to a downstream recipient who has violated the license. We think that this
|
||
is a reasonable result, and was already implicit in the wording of the
|
||
termination provision in our earlier drafts. Moreover, this clarification
|
||
should encourage patent holders to make contributions to GPL-covered
|
||
programs.
|
||
|
||
Second, we have modified the termination procedure by providing a limited
|
||
opportunity to cure license violations, an improvement that was requested by
|
||
many different members of our community. 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.'' The
|
||
addition of the cure opportunity achieves a better balance than our earlier
|
||
section 8 drafts between facilitating enforcement of the license and
|
||
protecting inadvertent violators against unfair results.
|
||
|
||
We have restructured the form of section 8 by replacing non-automatic
|
||
termination with automatic termination coupled with opportunities for
|
||
provisional and permanent reinstatement of rights. The revised wording does
|
||
not alter the underlying policy or details of procedure established in the
|
||
previous drafts, including the 60-day period of repose and 30-day cure
|
||
opportunity for first-time violators. The restoration of automatic
|
||
termination was motivated in part to facilitate enforcement in European
|
||
countries. We also believe the revised wording will be easier to understand
|
||
and apply in all jurisdictions.
|
||
|
||
\section{GPLv3~\S9: Acceptance}
|
||
|
||
% FIXME: needs some work here
|
||
|
||
Section 9 means what it says: mere receipt or execution of code neither
|
||
requires nor signifies contractual acceptance under the GPL. Speaking more
|
||
broadly, we have intentionally structured our license 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}
|
||
|
||
% FIXME: These don't belong here, but it's closer to where it ought to be now.
|
||
|
||
It is important to note that section 11, paragraph 3 refers to a work that is
|
||
conveyed, and section 10, paragraph 2 refers to a kind of automatic
|
||
counterpart to conveying achieved as the result of a transaction.
|
||
|
||
% FIXME: needs filled out and more here.
|
||
|
||
Draft1 removed the words ``at no charge'' from what is now subsection 5b, the
|
||
core copyleft provision, for reasons related to our current changes to the
|
||
second paragraph of section 4: it had 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.
|
||
|
||
We therefore have added a new explicit prohibition on imposition of licensing
|
||
fees or royalties in section 10. 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.
|
||
|
||
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}
|
||
|
||
The patent licensing practices that section 7 of GPLv2 (corresponding to
|
||
section 12 of GPLv3) was designed to prevent are 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 combatting the danger of patents.
|
||
|
||
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, we seek 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.
|
||
|
||
Therefore, we have designed GPLv3 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, we have given due consideration to practical
|
||
goals such as certainty and administrability for patent holders that
|
||
participate in distribution and development of GPL-covered software. Our
|
||
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.
|
||
|
||
Draft 3 features several significant changes concerning patents. We have
|
||
made improvements to earlier wording, clarified when patent assertion becomes
|
||
a prohibited restriction on GPL rights, and replaced a distribution-triggered
|
||
non-assertion covenant with a contribution-based patent license grant. We
|
||
have also added provisions to block collusion by patent holders with software
|
||
distributors that would extend patent licenses in a discriminatory way.
|
||
|
||
|
||
Draft 3 introduces the terms ``contributor'' and ``contribution,'' which are
|
||
used in the third paragraph of section 10 and the first paragraph of section
|
||
11, discussed successively in the following two subsections. Section 0
|
||
defines a contributor as ``a party who licenses under this License a work on
|
||
which the Program is based.'' That work is the ``contribution'' of that
|
||
contributor. In other words, each received GPLv3-covered work is associated
|
||
with one or more contributors, making up the finite set of upstream GPLv3
|
||
licensors for that work. 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 section 5, modified works
|
||
on which the Program is based.
|
||
|
||
For a contributor whose contribution is a modified work conveyed under
|
||
section 5, the contribution is ``the entire work, as a whole'' which the
|
||
contributor is required to license under GPLv3. The contribution therefore
|
||
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. Our 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.}
|
||
|
||
The term ``patent license,'' as used in the third through fifth
|
||
paragraphs of section 11, is not meant to be confined to agreements
|
||
formally identified or classified as patent licenses. The new second
|
||
paragraph of section 11 makes this clear by defining ``patent license,''
|
||
for purposes of the subsequent three paragraphs, as ``a patent license,
|
||
a covenant not to bring suit for patent infringement, or any other
|
||
express agreement or commitment, however denominated, not to enforce a
|
||
patent.'' 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.
|
||
|
||
Our previous drafts featured a patent license grant triggered by all
|
||
acts of distribution of GPLv3-covered works.\footnote{In Draft 2 we
|
||
rewrote the patent license as a covenant not to assert patent claims. We
|
||
explain why we reverted to the form of a patent license grant in \S\
|
||
\ref{cov}.} 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,
|
||
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 redistributor 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.
|
||
|
||
We concluded it would be more effective to make a partial concession
|
||
which would lead these companies to feel secure in doing the
|
||
distribution themselves, so that the conditions of section 10 would
|
||
apply to assertion of their patents. We therefore made the stricter
|
||
section 11 patent license apply 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, in Draft 3, the first paragraph of section 11 states that a
|
||
contributor's patent license covers all the essential patent claims
|
||
implemented by the whole program as that contributor distributes it.
|
||
Contributors of modified works grant a patent license to claims that
|
||
read on ``the entire work, as a whole.'' This is the work that the
|
||
copyleft clause in section 5 requires the contributor to license under
|
||
GPLv3; it includes the material the contributor has copied from the
|
||
upstream version that the contributor has modified. The first paragraph
|
||
of section 11 does not apply to those that redistribute the program
|
||
without change.\footnote{An implied patent license from the distributor,
|
||
however, may arise by operation of law. See the final paragraph of
|
||
section 11. Moreover, distributors are subject to the limits on patent
|
||
assertion contained in the third paragraph of section 10.}
|
||
|
||
We hope that this decision 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. Our 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.
|
||
|
||
|
||
|
||
We have made three changes to the definition of ``essential patent
|
||
claims'' in section 0. This definition now serves exclusively to
|
||
identify the set of patent claims licensed by a contributor under the
|
||
first paragraph of section 11.
|
||
|
||
First, we have clarified when essential patent claims include
|
||
sublicensable claims that have been licensed to the contributor by a
|
||
third party.\footnote{This issue is typically handled in other free
|
||
software 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{Draft 3 provides a new 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.
|
||
|
||
Draft 3 now defines essential patent claims, for a given party, as a
|
||
subset of the claims ``owned or controlled'' by the party. The
|
||
definition states that ``control includes the right to grant sublicenses
|
||
in a manner consistent with the requirements of this License.''
|
||
Therefore, in the case of a patent license that requires collection of
|
||
royalties from sublicensees, essential patent claims would not include
|
||
any claims sublicensable under that patent license, because sublicenses
|
||
to those claims could not be granted consistent with section 12.
|
||
|
||
Second, we now state that essential patent claims are those ``that would
|
||
be infringed by some manner, permitted by this License, of making,
|
||
using, or selling the work.'' This modified wording is intended 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.
|
||
|
||
Third, we have clarified that essential patent claims ``do not include
|
||
claims that would be infringed only as a consequence of further
|
||
modification of the work.'' That is to say, the set of essential patent
|
||
claims licensed under the first paragraph of section 11 is fixed by the
|
||
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.}
|
||
|
||
|
||
The downstream shielding provision of section 11 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. Draft 2 added a
|
||
source code availability option to this provision, as a specific
|
||
alternative to the general requirement to shield downstream users from
|
||
patent claims licensed to the distributor. A distributor conveying a
|
||
covered work knowingly relying on a patent license may comply with the
|
||
provision by ensuring that the Corresponding Source of the work is
|
||
publicly available, free of charge. We retained the shielding option in
|
||
Draft 2 because we did not wish to impose a general requirement to make
|
||
source code available to all, which has never been a GPL condition.
|
||
|
||
The addition of the source code availability option was supported by the
|
||
free software vendors most likely to be affected by the downstream
|
||
shielding provision. Enterprises that primarily use and occasionally
|
||
distribute free software, however, raised concerns regarding the
|
||
continued inclusion of a broadly-worded requirement to ``shield,'' which
|
||
appears to have been mistakenly read by those parties as creating an
|
||
obligation to indemnify. To satisfy these concerns, in Draft 3 we have
|
||
replaced the option to shield with two specific alternatives to the
|
||
source code availability option. 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 section 12. Cf.~the discussion of sublicensable patent
|
||
claims in \S\ \ref{epc}.} 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 we expect that
|
||
distributors in this situation will usually choose the source code
|
||
availability option.
|
||
|
||
Without altering its underlying logic, we have modified the phrasing of
|
||
the requirement to make clear that it is activated only if the
|
||
Corresponding Source 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 Corresponding Source to take advantage of the source code
|
||
availability option. This subtlety may help the distributor avoid
|
||
certain peculiar assumptions of liability.
|
||
|
||
We have made two other changes to the downstream shielding provision.
|
||
The phrase ``knowingly rely'' was left undefined in our earlier drafts;
|
||
in Draft 3 we have provided a detailed definition. We have also deleted
|
||
the condition precedent, added in Draft 2, that the relied-upon patent
|
||
license be one that is non-sublicensable and ``not generally available
|
||
to all''; this was imprecise in Draft 2 and is unnecessary in Draft
|
||
3. 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. If the patent license is sublicensable on GPL-consistent
|
||
terms, the distributor may choose to grant sublicenses to downstream
|
||
recipients instead of causing source code to be publicly available. In
|
||
such a case, if the distributor is also a contributor, it will already
|
||
have granted a patent sublicense by operation of the first paragraph of
|
||
section 11,\footnote{See \S\ \ref{epc}.} and so it need not do anything
|
||
further to comply with the third paragraph.
|
||
|
||
% FIXME: This probably needs editing
|
||
|
||
One major goal for GPLv3 is to provide developers with additional protection
|
||
from being sued for patent infringement. After much feedback and cooperation
|
||
from the committees, we are now proposing a patent license which closely
|
||
resembles those found in other free software licenses. This will be more
|
||
comfortable for everyone in the free software community to use, without
|
||
creating undue burdens for distributors.
|
||
|
||
We have also added new terms to stop distributors from colluding with third
|
||
parties to offer selective patent protection, as Microsoft and Novell have
|
||
recently done. The GPL 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.
|
||
|
||
Our strategy has two parts. First, any license that protects some
|
||
recipients of GPLed software must be extended to all recipients of the
|
||
software. Second, we prohibit anyone who made such an agreement from
|
||
distributing software released under GPLv3. We are still considering
|
||
whether or not this ban should apply when a deal was made before these
|
||
terms were written, and we look forward to community input on this issue.
|
||
|
||
The patent license grant of the first paragraph of section 11 no longer
|
||
applies to those who merely distribute works without modification. (We
|
||
explain why we made this change in the next subsection.) Such parties are
|
||
nonetheless subject to the conditions stated in section 10. Unlike the
|
||
patent license, which establishes a defense for downstream users lasting for
|
||
as long as they remain in compliance with the GPL, the commitment not to sue
|
||
that arises under section 10 is one that the distributor can end, so long as
|
||
the distributor also ceases to distribute. This is because a party who
|
||
initiates patent litigation in violation of section 10 risks termination of
|
||
its licensed permissions by the copyright holders of the work.
|
||
|
||
% FIXME: just brought in words here, needs rewriting.
|
||
|
||
is rooted in the basic principles of the GPL.
|
||
Our license has always stated that distributors may not impose further
|
||
restrictions on users' exercise of GPL rights. To make the suggested
|
||
distinction between contribution and distribution is to allow a
|
||
distributor to demand patent royalties from a direct or indirect
|
||
recipient, based on claims embodied in the distributed code. This
|
||
undeniably burdens users with an additional legal restriction on their
|
||
rights, in violation of the license.
|
||
|
||
%FIXME: possible useful text, but maybe not.
|
||
|
||
In the covenant provided in the revised section 11, the set of claims
|
||
that a party undertakes not to assert against downstream users are that
|
||
party's ``essential patent claims'' in the work conveyed by the party.
|
||
``Essential patent claims,'' a new term defined in section 0, are simply
|
||
all claims ``that would be infringed by making, using, or selling the
|
||
work.'' We have abandoned the phrase ``reasonably contemplated use.''
|
||
This change makes the obligations of distributing patent holders more
|
||
predictable.
|
||
|
||
% FIXME: probably needs a lot of work, these provisions changed over time.
|
||
|
||
GPLv3 adds a new section on licensing of patents. GPLv2 relies on an implied
|
||
patent license. The doctrine of implied license is one that is recognized
|
||
under United States patent law but may not be recognized in other
|
||
jurisdictions. We have therefore decided to make the patent license grant
|
||
explicit in GPLv3. Under section 11, a redistributor of a GPL'd work
|
||
automatically grants a nonexclusive, royalty-free and worldwide license for
|
||
any patent claims held by the redistributor, if those claims would be
|
||
infringed by the work or a reasonably contemplated use of the work.
|
||
|
||
% FIXME: probably needs a lot of work, these provisions changed over time.
|
||
|
||
The patent license is granted both to recipients of the redistributed work
|
||
and to any other users who have received any version of the work. Section 11
|
||
therefore ensures that downstream users of GPL'd code and works derived from
|
||
GPL'd code are protected from the threat of patent infringement allegations
|
||
made by upstream distributors, regardless of which country's laws are held to
|
||
apply to any particular aspect of the distribution or licensing of the GPL'd
|
||
code.
|
||
|
||
% FIXME: probably needs a lot of work, these provisions changed over time.
|
||
|
||
A redistributor of GPL'd code may benefit from a patent license that has been
|
||
granted by a third party, where the third party otherwise could bring a
|
||
patent infringement lawsuit against the redistributor based on the
|
||
distribution or other use of the code. In such a case, downstream users of
|
||
the redistributed code generally remain vulnerable to the applicable patent
|
||
claims of the third party. This threatens to defeat the purposes of the GPL,
|
||
for the third party could prevent any downstream users from exercising the
|
||
freedoms that the license seeks to guarantee.
|
||
|
||
% FIXME: probably needs a lot of work, these provisions changed over time.
|
||
|
||
The second paragraph of section 11 addresses this problem by requiring the
|
||
redistributor to act to shield downstream users from these patent claims. The
|
||
requirement applies only to those redistributors who distribute knowingly
|
||
relying on a patent license. Many companies enter into blanket patent
|
||
cross-licensing agreements. With respect to some such agreements, it would
|
||
not be reasonable to expect a company to know that a particular patent
|
||
license covered by the agreement, but not specifically mentioned in it,
|
||
protects the company's distribution of GPL'd code.
|
||
|
||
% FIXME: does this still fit with the final retaliation provision?
|
||
|
||
This narrowly-targeted patent retaliation provision is the only form of
|
||
patent retaliation that GPLv3 imposes by its own force. We believe that it
|
||
strikes a proper balance between preserving the freedom of a user to run and
|
||
modify a program, and protecting the rights of other users to run, modify,
|
||
copy, and distribute code free from threats by patent holders. It is
|
||
particularly intended to discourage a GPL licensee from securing a patent
|
||
directed to unreleased modifications of GPL'd code and then suing the
|
||
original developers or others for making their own equivalent modifications.
|
||
|
||
Several other free software licenses include significantly broader patent
|
||
retaliation provisions. In our view, too little is known about the
|
||
consequences of these forms of patent retaliation. As we explain below,
|
||
section 7 permits distribution of a GPL'd work that includes added parts
|
||
covered by terms other than those of the GPL. Such terms may include certain
|
||
kinds of patent retaliation provisions that are broader than those of section
|
||
2.
|
||
|
||
% FIXME: should we mention Microsoft-Novell at all?
|
||
|
||
Section 7 of GPLv2 (now section 12 of GPLv3) has seen some success in
|
||
deterring conduct that would otherwise result in denial of full downstream
|
||
enjoyment of GPL rights. Experience has shown us 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.
|
||
Previous drafts of GPLv3 included a ``downstream shielding'' provision in
|
||
section 11, which we have further refined in Draft 3; it is now found in the
|
||
third paragraph of section 11. In addition, Draft 3 introduces two new
|
||
provisions in section 11, located in the fourth and fifth paragraphs, that
|
||
address the problem of collusive extension of patent forbearance promises
|
||
that discriminate against particular classes of users and against the
|
||
exercise of particular freedoms. This problem has been made more acute by the
|
||
recent Microsoft/Novell deal.
|
||
|
||
We attack the Microsoft-Novell deal from two angles. First, in the sixth
|
||
paragraph of section 11, the draft says that if you 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. This means that the patent protection Microsoft
|
||
has extended to Novell's customers would be extended to everyone who uses any
|
||
software Novell distributes under GPLv3.
|
||
|
||
Second, in the seventh paragraph, the draft says that you are prohibited from
|
||
distributing software under GPLv3 if you make an agreement like the
|
||
Microsoft-Novell deal in the future. This will prevent other distributors
|
||
from trying to make other deals like it.
|
||
|
||
The main reason for this is tactical. We believe we can do more to
|
||
protect the community by allowing Novell to use software under GPL
|
||
version 3 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.
|
||
|
||
Microsoft is scrambling to dispose of as many Novell SLES coupons as
|
||
possible prior to the adoption of GPLv3. Unfortunately for Microsoft,
|
||
those coupons bear no expiration date, and paragraph 6 has no cut-off
|
||
date. Through its ongoing distribution of coupons, Microsoft will
|
||
have procured the distribution of GPLv3-covered programs as soon as
|
||
they are included in Novell SLES distributions, thereby extending
|
||
patent defenses to all downstream recipients of that software by
|
||
operation of paragraph 6.
|
||
|
||
A secondary reason is to avoid affecting other kinds of agreements for
|
||
other kinds of activities. We have tried to take care in paragraph 7
|
||
to distinguish pernicious deals of the Microsoft/Novell type from
|
||
business conduct that is not particularly harmful, but we cannot be
|
||
sure we have entirely succeeded. There remains some risk that other
|
||
unchangeable past agreements could fall within its scope.
|
||
|
||
In future deals, distributors engaging in ordinary business practices
|
||
can structure the agreements so that they do not fall under paragraph
|
||
7. However, it will block Microsoft and other patent aggressors from
|
||
further such attempts to subvert parts of our community.
|
||
|
||
A software patent forbids the use of a technique or algorithm, and its
|
||
existence is a threat to all software developers and users. A patent
|
||
holder can use a patent to suppress any program which implements the
|
||
patented technique, even if thousands of other techniques are
|
||
implemented together with it. Both free software and proprietary
|
||
software are threatened with death in this way.
|
||
|
||
However, patents threaten free software with a fate worse than death: a
|
||
patent holder might also try to use the patent to impose restrictions on
|
||
use or distribution of a free program, such as to make users feel they
|
||
must pay for permission to use it. This would effectively make it
|
||
proprietary software, exactly what the GPL is intended to prevent.
|
||
|
||
Novell and Microsoft have recently attempted a new way of using patents
|
||
against our community, which involves a narrow and discriminatory
|
||
promise by a patent holder not to sue customers of one particular
|
||
distributor of a GPL-covered program. Such deals threaten our community
|
||
in several ways, each of which may be regarded as de facto
|
||
proprietization of the software. If users are frightened into paying
|
||
that one distributor just to be safe from lawsuits, in effect they are
|
||
paying for permission to use the program. They effectively deny even
|
||
these customers the full and safe exercise of some of the freedoms
|
||
granted by the GPL. And they make disfavored free software developers
|
||
and distributors more vulnerable to attacks of patent aggression, by
|
||
dividing them from another part of our community, the commercial users
|
||
that might otherwise come to their defense.
|
||
|
||
We have added the fourth and fifth paragraphs of section 11 to combat
|
||
this threat. This subsection briefly describes the operation of the new
|
||
provisions. We follow it with a more detailed separate note on the
|
||
Microsoft/Novell patent deal, in which we provide an extensive rationale
|
||
for these measures.
|
||
|
||
As noted, one effect of the discriminatory patent promise is to divide
|
||
and isolate those who make free software from the commercial users to
|
||
whom the promise is extended. This deprives the noncommercial
|
||
developers of the communal defensive measures against patents made
|
||
possible by the support of those commercial users. The fourth paragraph
|
||
of section 11 operates to restore effective defenses to the targets of
|
||
patent aggression.
|
||
|
||
A patent holder becomes subject to the fourth paragraph of section 11
|
||
when it enters into a transaction or arrangement that involves two acts:
|
||
(1) conveying a GPLv3-covered work, and (2) offering to some, but not
|
||
all, of the work's eventual users a patent license for particular
|
||
activities using specific copies of the covered work. This paragraph
|
||
only operates when the two triggering acts are part of a single
|
||
arrangement, because the patent license is part of the arrangement for
|
||
conveying, which requires copyright permission. Under those conditions,
|
||
the discriminatory patent license is ``automatically extended to all
|
||
recipients of the covered work and works based on it.''
|
||
|
||
This provision establishes a defense to infringement allegations brought
|
||
by the patent holder against any users of the program who are not
|
||
covered by the discriminatory patent license. That is to say, it gives
|
||
all recipients the benefit of the patent promise that the patent holder
|
||
extended only to some. The effect is to make contributing discriminatory
|
||
promises of patent safety to a GPL distribution essentially like
|
||
contributing code. In both cases, the operation of the GPL extends
|
||
license permission to everyone that receives a copy of the program.
|
||
|
||
|
||
The fourth paragraph of section 11 gives users a defense against patent
|
||
aggression brought by the party who made the discriminatory patent
|
||
promise that excluded them. By contrast, the fifth paragraph stops free
|
||
software vendors from contracting with patent holders to make
|
||
discriminatory patent promises. In effect, the fifth paragraph extends
|
||
the principle of section 12 to situations involving collusion between a
|
||
patent holder and a distributor.
|
||
|
||
Under this provision, a distributor conveying a GPL-covered program may
|
||
not make an arrangement to get a discriminatory patent promise from a
|
||
third party for its customers, covering copies of the program (or
|
||
products that contain the program), if the arrangement requires the
|
||
distributor to make payment to the third party based on the extent of
|
||
its activity in conveying the program, and if the third party is itself
|
||
in the business of distributing software. Unlike the fourth paragraph,
|
||
which creates a legal defense for targets of patent aggression, the
|
||
consequence for violation of the fifth paragraph is termination of GPL
|
||
permissions for the distributor.
|
||
|
||
The business, technical, and patent cooperation agreement between
|
||
Microsoft and Novell announced in November 2006 has significantly
|
||
affected the development of Draft 3. The fourth and fifth paragraphs of
|
||
section 11 embody our response to the sort of threat represented by the
|
||
Microsoft/Novell deal, and are designed to protect users from such
|
||
deals, and prevent or deter the making of such deals.
|
||
|
||
The details of the agreements entered into between Microsoft and Novell,
|
||
though subject to eventual public disclosure through the securities
|
||
regulation system, have not been fully disclosed to this
|
||
point.\footnote{Lawyers employed by the Software Freedom Law Center,
|
||
which is counsel to the Free Software Foundation and other relevant free
|
||
software clients, were accorded limited access to the terms of the deal
|
||
under a non-disclosure agreement between SFLC and Novell. The reasons
|
||
for delay in the application of securities regulations requiring
|
||
publication of the relevant contracts are unrelated to the deal between
|
||
Microsoft and Novell.} It is a matter of public knowledge, however,
|
||
that the arrangement calls for Novell to pay a portion of the future
|
||
gross revenue of one of its divisions to Microsoft, and that (as one
|
||
other feature of a complex arrangement) Microsoft has promised Novell's
|
||
customers not to bring patent infringement actions against certain
|
||
specific copies of Novell's SUSE ``Linux''\footnote{This is a GNU/Linux
|
||
distribution, and is properly called SUSE GNU/Linux Enterprise Server.}
|
||
Enterprise Server product for which Novell receives revenue from the
|
||
user, so long as the user does not make or distribute additional copies
|
||
of SLES.
|
||
|
||
The basic harm that such an agreement can do is to make the free
|
||
software subject to it effectively proprietary. This result occurs to
|
||
the extent that users feel compelled, by the threat of the patent, to
|
||
get their copies in this way. So far, the Microsoft/Novell deal does
|
||
not seem to have had this result, or at least not very much: users do
|
||
not seem to be choosing Novell for this reason. But we cannot take for
|
||
granted that such threats will always fail to harm the community. We
|
||
take the threat seriously, and we have decided to act to block such
|
||
threats, and to reduce their potential to do harm. Such deals also
|
||
offer patent holders a crack through which to split the community.
|
||
Offering commercial users the chance to buy limited promises of patent
|
||
safety in effect invites each of them to make a separate peace with
|
||
patent aggressors, and abandon the rest of our community to its fate.
|
||
|
||
Microsoft has been restrained from patent aggression in the past by the
|
||
vocal opposition of its own enterprise customers, who now also use free
|
||
software systems to run critical applications. Public statements by
|
||
Microsoft concerning supposed imminent patent infringement actions have
|
||
spurred resistance from users Microsoft cannot afford to alienate. But
|
||
if Microsoft can gain royalties from commercial customers by assuring
|
||
them that \textit{their} copies of free software have patent licenses
|
||
through a deal between Microsoft and specific GNU/Linux vendors,
|
||
Microsoft would then be able to pressure each user individually, and
|
||
each distributor individually, to treat the software as proprietary. If
|
||
enough users succumb, it might eventually gain a position to terrify
|
||
noncommercial developers into abandoning the software entirely.
|
||
|
||
Preventing these harms is the goal of the new provisions of section 11.
|
||
The fourth paragraph deals with the most acute danger posed by
|
||
discrimination among customers, by ensuring that any party who
|
||
distributes others' GPL-covered programs, and makes promises of patent
|
||
safety limited to some but not all recipients of copies of those
|
||
specific programs, automatically extends its promises of patent safety
|
||
to cover all recipients of all copies of the covered works. This will
|
||
negate part of the harm of the Microsoft/Novell deal, for GPLv3-covered
|
||
software.
|
||
|
||
In addition to the present deal, however, GPLv3 must act to deter
|
||
similar future arrangements, and it cannot be assumed that all future
|
||
arrangements by Microsoft or other potential patent aggressors will
|
||
involve procuring the conveyance of the program by the party that grants
|
||
the discriminatory promises of patent safety. Therefore, we need the
|
||
fifth paragraph as well, which is aimed at parties that play the Novell
|
||
role in a different range of possible deals.
|
||
|
||
Drafting this paragraph was difficult because it is necessary to
|
||
distinguish between pernicious agreements and other kinds of agreements
|
||
which do not have an acutely harmful effect, such as patent
|
||
contributions, insurances, customary cross-license promises to
|
||
customers, promises incident to ordinary asset transfers, and standard
|
||
settlement practices. We believe that we have achieved this, but it is
|
||
hard to be sure, so we are considering making this paragraph apply only
|
||
to agreements signed in the future. If we do that, companies would only
|
||
need to structure future agreements in accord with the fifth paragraph,
|
||
and would not face problems from past agreements that cannot be changed
|
||
now. We are not yet convinced that this is necessary, and we plan to
|
||
ask for more comment on the question. This is why the date-based cutoff
|
||
is included in brackets.
|
||
|
||
One drawback of this cutoff date is that it would ``let Novell off''
|
||
from part of the response to its deal with Microsoft. However, this may
|
||
not be a great drawback, because the fourth paragraph will apply to that
|
||
deal. We believe it is sufficient to ensure either the deal's voluntary
|
||
modification by Microsoft or its reduction to comparative harmlessness.
|
||
Novell expected to gain commercial advantage from its patent deal with
|
||
Microsoft; the effects of the fourth paragraph in undoing the harm of
|
||
that deal will necessarily be visited upon Novell.
|
||
|
||
|
||
\section{GPLv3~\S12: Familiar as GPLv2 \S~7}
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
The wording in the first sentence of section 12 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 what has been
|
||
our interpretation of GPLv2.
|
||
|
||
% FIXME: probably mostly still right, needs some updates, though.
|
||
|
||
We have removed the limited severability clause of GPLv2 section 7 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. We have also removed
|
||
the final sentence of GPLv2 section 7, which we consider to be unnecessary.
|
||
|
||
\section{GPLv3~\S13: The Great Affero Compromise}
|
||
|
||
The main purpose of clause 7b4 was to attain GPLv3 compatibility for the
|
||
additional condition of version 1 of the Affero GPL, with a view to
|
||
achieving compatibility for a future version, since version 1 was
|
||
incompatible with GPLv3.\footnote{Version 1 of the Affero GPL contains
|
||
its own copyleft clause, worded identically to that in GPLv2, which
|
||
conflicts with the copyleft clause in GPLv3. The Affero GPL permits
|
||
relicensing under versions of the GPL later than version 2, but only if
|
||
the later version ``includes terms and conditions substantially
|
||
equivalent to those of this license'' (Affero GPL, version 1, section
|
||
9). The Affero license was written with the expectation that its
|
||
additional requirement would be incorporated into the terms of GPLv3
|
||
itself, rather than being placeable on parts added to a covered work
|
||
through the mechanism of section 7 of GPLv3.} However, we wrote the
|
||
clause broadly enough to cover a range of other possible terms that
|
||
would differ from the Affero condition in their details. Draft 3 no
|
||
longer pursues the more ambitious goal of allowing compatibility for a
|
||
whole category of Affero-like terms. In place of 7b4, we have added a
|
||
new section 13 that simply permits GPLv3-covered code to be linked with
|
||
code covered by the forthcoming version 2 of the Affero GPL.
|
||
|
||
We have made this decision in the face of irreconcilable views from
|
||
different parts of our community. While we had known that many
|
||
commercial users of free software were opposed to the inclusion of a
|
||
mandatory Affero-like requirement in the body of GPLv3 itself, we were
|
||
surprised at their opposition to its availability through section 7.
|
||
Free software vendors allied to these users joined in their objections,
|
||
as did a number of free software developers arguing on ethical as well
|
||
as practical grounds.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
\section{GPLv3~\S14: So, When's GPLv4?}
|
||
\label{GPLv3s14}
|
||
|
||
% FIXME Say more
|
||
|
||
No substantive change has been made in section 14. The wording of the section
|
||
has been revised slightly to make it clearer.
|
||
|
||
% FIXME; proxy
|
||
|
||
\section{GPLv3~\S15--17: Warranty Disclaimers and Liability Limitation}
|
||
|
||
No substantive changes have been made in sections 15 and 16.
|
||
|
||
% FIXME: more, plus 17
|
||
|
||
% FIXME: Section header needed here about choice of law.
|
||
|
||
% FIXME: 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: 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: does this need to be a section, describing how it was out then in
|
||
% then out then in? :)
|
||
|
||
We have removed from this draft the appended section on ``How to Apply These
|
||
Terms to Your New Programs.'' For brevity, the license document can instead
|
||
refer to a web page containing these instructions as a separate document.
|
||
|
||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||
\chapter{The Lesser GPL}
|
||
|
||
As we have seen in our consideration of the GPL, its text is specifically
|
||
designed to cover all possible derivative works under copyright law. Our
|
||
goal in designing GPL was to make sure that any derivative work of GPL'd
|
||
software was itself released under GPL when distributed. Reaching as far
|
||
as copyright law will allow is the most direct way to reach that goal.
|
||
|
||
However, while the strategic goal 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.
|
||
|
||
\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 GPL were
|
||
somewhat different. Applications released under GPL would never
|
||
themselves become part of proprietary software. However, if glibc were
|
||
released under GPL, it would require that any application distributed for
|
||
the GNU/Linux platform be released under 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 derivative 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 derivative 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 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 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 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 derivative works, so the redistributors can make
|
||
some proprietary derivatives. Since we simply do not allow the
|
||
license to stretch as far as copyright law does regarding what
|
||
derivative works must be relicensed under the same terms, we must go
|
||
further to explain which derivative works we will allow to 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 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 LGPL\@.
|
||
|
||
In short, FSF designed 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 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}
|
||
|
||
LGPL's preamble sets forth the limits to which the license seeks to go in
|
||
chasing these goals. 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 derivative works: ``works that use
|
||
the library,'' and ``works based on the library.'' Unlike GPL, LGPL must
|
||
draw some lines regarding derivative works. We do this here in this
|
||
license because we specifically seek to liberalize the rights afforded to
|
||
those who make derivative works. In GPL, we reach as far as copyright law
|
||
allows. In 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 derivative works and prohibit
|
||
others, LGPL distinguishes between two classes of derivative works:
|
||
``works based on the library,'' and ``works that use the library.'' The
|
||
distinction is drawn on the bright line of binary (or runtime) derivative
|
||
works and source code derivatives. 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 derivative works of that GPL'd
|
||
software. 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 derivative works are controlled by the terms of the license (in GPLv2~\S3),
|
||
and distributors of such binary derivatives must release full
|
||
corresponding source\@.
|
||
|
||
In the case of LGPL, these are precisely the types of derivative works
|
||
we wish to permit. 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 derivative work, called \lplusi{}, that the user can
|
||
run.
|
||
|
||
\item Since \lplusi{} is a derivative work of both \worki{} and \workl{},
|
||
the license of \workl{} (the LGPL) can put restrictions on the license
|
||
of \lplusi{}. In fact, this is what 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 derivative work of
|
||
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 create a derivative work
|
||
by combining 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
|
||
derivative work of 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 copyright derivative works,
|
||
in the same sense that 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 derivative works of a 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 work under
|
||
copyright law of the LGPL'd work?
|
||
|
||
\item Is there no way in which the new work fits the definition of a
|
||
``work that uses the library''?
|
||
\end{enumerate}
|
||
|
||
|
||
If the answer is ``yes'' to both these questions, then you most likely
|
||
have a ``work based on the library.'' If the answer is ``no'' to the
|
||
first but ``yes'' to the second, you are in a gray area between ``work
|
||
based on the library'' and a ``work that uses the library.''
|
||
|
||
In our years of work with the LGPLv2.1, however, we have never seen a work
|
||
of software that was not clearly one or the other; the line is quite
|
||
bright. At times, though, we have seen cases where a derivative work
|
||
appeared in some ways to be a work that used the library and in other
|
||
ways a work based on the library. We overcame this problem by
|
||
dividing the work into smaller subunits. It was soon discovered that
|
||
what we actually had were three distinct components: the original
|
||
LGPL'd work, a specific set of works that used that library, and a
|
||
specific set of works that were based on the library. Once such
|
||
distinctions are established, the licensing for each component can be
|
||
considered independently and the LGPLv2.1 applied to each work as
|
||
prescribed.
|
||
|
||
|
||
\section{Subtleties in Defining the Application}
|
||
|
||
In our discussion of the definition of ``works that use the library,'' we
|
||
left out a few more complex details that relate to lower-level programming
|
||
details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities,
|
||
and it has been a source of great confusion. Part of the confusion comes
|
||
because a deep understanding of how compiler programs work is nearly
|
||
mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to
|
||
cover. It helps some to note that this is a border case that we cover in
|
||
the license only so that when such a border case is hit, the implications
|
||
of using 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 derivative 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.
|
||
Specifically, while we know that a ``work that uses the library'' is one
|
||
whose final binary is a derivative work, but whose source is not, there
|
||
are cases where the object code --- that intermediate step between source
|
||
and final binary --- is a derivative work created by copying verbatim 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 derivative 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
|
||
derivative 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
|
||
2based 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.
|
||
|
||
The remaining options in LGPLv2.1~\S6 are very similar to the other choices
|
||
provided by GPLv2~\S3. There are some additional options, but time does
|
||
not permit us in this course to go into those additional options. In
|
||
almost all cases of distribution under LGPL, either LGPLv2.1~\S6(a) or LGPLv2.1~\S6(b) are
|
||
exercised.
|
||
|
||
\section{Distribution of the Combined Works}
|
||
|
||
Essentially, ``works based on the library'' must be distributed under the
|
||
same conditions as works under full GPL\@. In fact, we note that
|
||
LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.
|
||
There are again subtle differences and additions, which time does not
|
||
permit us to cover in this course.
|
||
|
||
\section{And the Rest}
|
||
|
||
The remaining variations between LGPL and GPL cover the following
|
||
conditions:
|
||
|
||
\begin{itemize}
|
||
|
||
\item Allowing a licensing ``upgrade'' from LGPL to GPL\@ (in LGPLv2.1~\S3)
|
||
|
||
\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 not derivative works of
|
||
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{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 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, including IBM and Red Hat, make substantial revenue
|
||
from this model. IBM primarily chooses this model because they have
|
||
found that for higher-end hardware, the cost of 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
|
||
exists to compete on their hardware) is the right choice.
|
||
|
||
Red Hat has actually found that 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 like CodeSourcery, as well as
|
||
other medium-sized companies like MontaVista and OpenTV that compete in
|
||
this space. Because the code-base is protect by 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 is the sole copyright holder. 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, such as MySQL AB and TrollTech, 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 problematic 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
|
||
not legally derivative works of each other. Sometimes, it is easier simply to
|
||
improve existing GPL'd application than to start from scratch. In
|
||
exchange for that benefit, the license requires that the modifier give
|
||
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 $<$compliance@fsf.org$>$.
|
||
|
||
If you are particularly interested in matters of GPL compliance, we
|
||
recommend the second course in this series, {\em GPL Compliance Case
|
||
Studies and Legal Ethics in Free Software Licensing\/}, in which we
|
||
discuss some real GPL violation cases that FSF has worked to resolve.
|
||
Consideration of such cases can help give insight on how to handle GPL
|
||
compliance in new situations.
|
||
|
||
|
||
% =====================================================================
|
||
% END OF FIRST DAY SEMINAR SECTION
|
||
% =====================================================================
|