2ce793aa05
The enforcement section now has an integrated paragraph describing how enforcement relates to copyright, and refers back to a related section much earlier in the tutorial.
1413 lines
73 KiB
TeX
1413 lines
73 KiB
TeX
% compliance-guide.tex -*- LaTeX -*-
|
||
|
||
\part{A Practical Guide to GPL Compliance}
|
||
\label{gpl-compliance-guide}
|
||
|
||
{\parindent 0in
|
||
This part is: \\
|
||
\begin{tabbing}
|
||
Copyright \= \copyright{} 2008, 2014 \= \hspace{.2in} Bradley M. Kuhn. \\
|
||
Copyright \= \copyright{} 2014 \> \hspace{.2in} Free Software Foundation, Inc. \\
|
||
Copyright \> \copyright{} 2008, 2014 \> \hspace{.2in} Software Freedom Law Center. \\
|
||
\end{tabbing}
|
||
|
||
\vspace{1in}
|
||
|
||
\begin{center}
|
||
Authors of this part are: \\
|
||
|
||
Bradley M. Kuhn \\
|
||
Aaron Williamson \\
|
||
Karen M. Sandler \\
|
||
|
||
\vspace{1in}
|
||
|
||
Copy editors of this part include: \\
|
||
Martin Michlmayr
|
||
|
||
\vspace{3in}
|
||
|
||
The copyright holders of 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
|
||
\url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.
|
||
\end{center}
|
||
}
|
||
|
||
\bigskip
|
||
|
||
\chapter*{Executive Summary}
|
||
|
||
This is a guide to effective compliance with the GNU General Public
|
||
License (GPL) and related licenses. Copyleft advocates
|
||
usually seek to assist the community with
|
||
GPL compliance cooperatively. This guide focuses on complying from the
|
||
start, so that readers can learn to avoid enforcement actions entirely, or, at
|
||
least, minimize the negative impact when enforcement actions occur.
|
||
This guide introduces and explains basic legal concepts related to the GPL and its
|
||
enforcement by copyright holders. It also outlines business practices and
|
||
methods that lead to better GPL compliance. Finally, it recommends proper
|
||
post-violation responses to the concerns of copyright holders.
|
||
|
||
\chapter{Background}
|
||
|
||
Copyright law grants exclusive rights to authors. Authors who chose copyleft
|
||
seek to protect the freedom of users and developers to copy, share, modify
|
||
and redistribute the software. However, copyleft is ultimately implemented
|
||
through copyright, and the GPL is primarily and by default a copyright
|
||
license. (See \S~\ref{explaining-copyright} for more about the interaction
|
||
between copyright and copyleft.) Copyright law grants an unnatural exclusive
|
||
control to copyright holders regarding copyright-controlled permissions
|
||
related to the work. Therefore, copyright holders (or their agents) are the
|
||
ultimately the sole authorities to enforce copyleft and protect the rights of
|
||
users. Actions for copyright infringement are the ultimate legal mechanism
|
||
for enforcement. Therefore, copyright holders, or collaborative groups of
|
||
copyright holders, have historically been the actors in GPL enforcement.
|
||
|
||
The earliest of these efforts began soon after the GPL was written by
|
||
Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,
|
||
often in public Usenet discussions.\footnote{One example is the public
|
||
outcry over NeXT's attempt to make the Objective-C front-end to GCC
|
||
proprietary. RMS, in fact, handled this enforcement action personally and
|
||
the Objective-C front-end is still part of upstream GCC today.} Over the next decade, the Free Software Foundation (FSF),
|
||
which holds copyrights in many GNU programs, was the only visible entity
|
||
actively enforcing its GPL'd copyrights on behalf of the software freedom
|
||
community.
|
||
FSF's enforcement
|
||
was generally a private process; the FSF contacted violators
|
||
confidentially and helped them to comply with the license. Most
|
||
violations were pursued this way until the early 2000's.
|
||
|
||
By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in
|
||
embedded devices such as wireless routers. During this period, public
|
||
ridicule of violators in the press and on Internet fora supplemented
|
||
ongoing private enforcement and increased pressure on businesses to
|
||
comply. In 2003, the FSF formalized its efforts into the GPL Compliance
|
||
Lab, increased the volume of enforcement, and built community coalitions
|
||
to encourage copyright holders to together settle amicably with violators.
|
||
Beginning in 2004, Harald Welte took a more organized public enforcement
|
||
approach and launched \href{http://gpl-violations.org/}{gpl-violations.org}, a website and mailing
|
||
list for collecting reports of GPL violations. On the basis of these
|
||
reports, Welte successfully pursued many enforcements in Europe, including
|
||
formal legal action. Harald earns the permanent fame as the first copyright
|
||
holder to bring legal action in a court regarding GPL compliance.
|
||
|
||
In 2007, two copyright holders in BusyBox, in conjunction with the
|
||
Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit
|
||
based on a violation of the GPL\@ in the USA. While lawsuits are of course
|
||
quite public, the vast majority of Conservancy's enforcement actions
|
||
are resolved privately via
|
||
cooperative communications with violators. As both FSF and Conservancy have worked to bring
|
||
individual companies into compliance, both organizations have encountered numerous
|
||
violations resulting from preventable problems such as inadequate
|
||
attention to licensing of upstream software, misconceptions about the
|
||
GPL's terms, and poor communication between software developers and their
|
||
management. This document highlights these problems and describe
|
||
best practices to encourage corporate Free Software users to reevaluate their
|
||
approach to GPL'd software and avoid future violations.
|
||
|
||
Both FSF and Conservancy continue GPL enforcement and compliance efforts
|
||
for software under the GPL, the GNU Lesser
|
||
Public License (LGPL) and other copyleft licenses. In doing so, both organizations have
|
||
found that most violations stem from a few common, avoidable mistakes. All copyleft advocates hope to educate the community of
|
||
commercial distributors, redistributors, and resellers on how to avoid
|
||
violations in the first place, and to respond adequately and appropriately
|
||
when a violation occurs.
|
||
|
||
%FIXME-URGENT: integrate (into its own chapter)
|
||
\chapter{FIXME-URGENT}
|
||
|
||
\section{Who Has Compliance Obligations?}
|
||
|
||
Distributors of licensed works—whether they are distributing modified or
|
||
unmodified versions of the works, whether they have embedded executable
|
||
copies of licensed works in a device, or are selling or otherwise
|
||
transferring only a digital copy—have obligations to at least the users to
|
||
whom they or intermediary parties distributed those copies. Whether those
|
||
obligations run also to third parties not directly receiving their
|
||
distribution of the works depends on the precise license involved, and their
|
||
chosen mode of either distributing or offering to distribute source code. In
|
||
addition, they have obligations to upstream parties, to preserve reasonable
|
||
legal notices embedded in the code, and to mark modified versions
|
||
appropriately.
|
||
|
||
Both service providers and distributors have the obligation, in order to
|
||
protect users’ rights, to refrain from imposing any additional restrictions
|
||
on downstream parties. They must refrain from terms in ``umbrella licenses,''
|
||
EULAs, or sublicenses that restrict downstream users’ rights as described
|
||
above. Under the terms of LGPL, they must also refrain from license terms on
|
||
works based on the licensed work that prohibit replacement of the licensed
|
||
components of the larger non-LGPL’d work, or prohibit decompilation or
|
||
reverse engineering in order to enhance or fix bugs in the LGPL’d components.
|
||
|
||
Patent holders having claims reading on works they distribute have an
|
||
obligation to refrain from enforcing those claims against parties to whom
|
||
they distribute. Patent holders modifying and distributing works under the
|
||
version 3 family of licenses have an obligation to refrain from enforcing any
|
||
claims reading on the version they distributed, not only against that version
|
||
as distributed, but also against any subsequent version or work based thereon
|
||
that also practices those claims.
|
||
|
||
All parties have an obligation to refrain from acting as a provider of
|
||
services or distributor of licensed works if they have accepted, or had
|
||
imposed on them by judicial action, binding legal conditions that would
|
||
prevent them from meeting obligations to users as described. If a party is
|
||
under such conflicting obligations, it has a duty to refrain from playing the
|
||
role in which it is no longer free to meet its license obligations.
|
||
|
||
\section{FIXME: Understanding Risk}
|
||
|
||
we have observed that there is a significant mismatch between the assumptions
|
||
businesses make about compliance and the realities of what goes wrong, what
|
||
causes disputes, and how those disputes are resolved. Often, we have found
|
||
companies preparing at great expense to avoid unlikely risks that have low
|
||
historical incidence of occurrence and low cost of remediation, while leaving
|
||
unmanaged the risks that have historically resulted in all the litigation and
|
||
other adverse outcomes. In this section, we describe in broad terms the
|
||
activities that help businesses prepare to meet their compliance obligations
|
||
with minimal effort at minimal cost, dealing preventively with the compliance
|
||
risks they really face.
|
||
|
||
The mismatch between actual compliance risk and compliance risk management,
|
||
in our experience, results from a misunderstanding of licensor
|
||
intentions. Commercial parties often expect copyleft project communities to
|
||
approach compliance as a form of copyright monetization, or else as an
|
||
ideological effort to force proprietary software to be relicensed under
|
||
copyleft terms. Under the assumption that the intention of the licensors is
|
||
to take advantage of non-compliance to extract royalties, or to force the
|
||
business’s proprietary products to be distributed under copyleft, businesses
|
||
manage the risk that they will ``accidentally''—or as the result of
|
||
unsupervised activity by individual programmers—copy infringing ``snippets'' of
|
||
copylefted code into their own proprietary computer program. Risk management
|
||
involves the purchase of expensive proprietary ``code scanning'' services that
|
||
purport to detect such accidental inclusions. Effort is concentrated on how
|
||
proprietary computer programs are made, to prevent ``infection'' by free
|
||
software.
|
||
|
||
In fact, however, development communities that use copyleft regard compliance
|
||
failures as an opportunity to improve compliance. Every compliance failure
|
||
downstream from their project represents a loss of rights by their users. The
|
||
project, as copyright holder, is the guardian of its users’ rights. Their
|
||
activity is designed to restore those rights, and to protect the project’s
|
||
contributors’ intentions in the making of their software. Projects’ goals in
|
||
seeking compliance are more often frustrated by the way software is delivered
|
||
to users than by the way combinations of proprietary and free software are
|
||
made. In particular,
|
||
|
||
\begin{itemize}
|
||
|
||
\item Users aren’t provided with required information about the presence of
|
||
copylefted programs and their applicable license terms in the product they
|
||
have purchased; or
|
||
|
||
\item Users can’t reliably get complete and corresponding source code to
|
||
copylefted programs the distributor knew it was using and intended to use
|
||
pursuant to the license terms; or
|
||
|
||
\item Users get no response when they communicate with published addresses
|
||
requesting fulfillment of businesses’ obligations.
|
||
\end{itemize}
|
||
|
||
|
||
In these and similar situations, the project’s goal is compliance with
|
||
obligations intentionally incurred by intentional use of copylefted programs,
|
||
through observance of fulfillment obligations to downstream users. Failures
|
||
of this type, which are uncaught by scanning programs or other similar
|
||
services, have resulted in all the litigation ever brought by copyleft
|
||
communities around the world.
|
||
|
||
Inclusions of free software in commercial proprietary products do happen. In
|
||
our practice on behalf of copyleft-using development communities, we
|
||
encounter such problems not frequently, but regularly. To the best of our
|
||
knowledge, not one such instance has ever resulted in compliance litigation
|
||
by a community party. These issues are regularly settled in an amicable and
|
||
cooperative fashion.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\chapter{Best Practices to Avoid Common Violations}
|
||
\label{best-practices}
|
||
|
||
Unlike highly permissive licenses (such as the ISC license), which
|
||
typically only require preservation of copyright notices, licensees face many
|
||
important requirements from the GPL. These requirements are
|
||
carefully designed to uphold certain values and standards of the software
|
||
freedom community. While the GPL's requirements may initially appear
|
||
counter-intuitive to those more familiar with proprietary software
|
||
licenses, by comparison, its terms are in fact clear and quite favorable to
|
||
licensees. Indeed, the GPL's terms actually simplify compliance when
|
||
violations occur.
|
||
|
||
GPL violations occur (or, are compounded) most often when companies lack sound
|
||
practices for the incorporation of GPL'd components into their
|
||
internal development environment. This section introduces some best
|
||
practices for software tool selection, integration and distribution,
|
||
inspired by and congruent with software freedom methodologies. Companies should
|
||
establish such practices before building a product based on GPL'd
|
||
software.\footnote{This document addresses compliance with GPLv2,
|
||
GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common
|
||
errors differs little for compliance with these four licenses.
|
||
\S~\ref{lgpl} discusses the key differences between GPL and LGPL
|
||
compliance.}
|
||
|
||
\section{Evaluate License Applicability}
|
||
\label{derivative-works}
|
||
Political discussion about the GPL often centers around the ``copyleft''
|
||
requirements of the license. Indeed, the license was designed primarily
|
||
to embody this licensing feature. Most companies adding non-trivial
|
||
features (beyond mere porting and bug-fixing) to GPL'd software (and
|
||
thereby invoking these requirements) are already well aware of their
|
||
more complex obligations under the license.\footnote{There has been much legal
|
||
discussion regarding copyleft and derivative works. In practical
|
||
reality, this issue is not relevant to the vast majority of companies
|
||
distributing GPL'd software. Those interested in this issue should study
|
||
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
|
||
Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
|
||
this tutorial}.}
|
||
|
||
However, experienced GPL enforcers find that few redistributors'
|
||
compliance challenges relate directly to combined work issues in copyleft.
|
||
Instead, the distributions of GPL'd
|
||
systems most often encountered typically consist of a full operating system
|
||
including components under the GPL (e.g., Linux, BusyBox) and components
|
||
under the LGPL (e.g., the GNU C Library). Sometimes, these programs have
|
||
been patched or slightly improved by direct modification of their sources,
|
||
and thus the result is unequivocally a modified version. Alongside these programs,
|
||
companies often distribute fully independent, proprietary programs,
|
||
developed from scratch, which are designed to run on the Free Software operating
|
||
system but do not combine with, link to, modify, derive from, or otherwise
|
||
create a combined work with
|
||
the GPL'd components.\footnote{However, these programs do often combine
|
||
with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}
|
||
In the latter case, where the work is unquestionably a separate work of
|
||
creative expression, no copyleft provisions are invoked.
|
||
The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a
|
||
combined, derivative, and/or modified version of the work, but rather, issues related to distribution and
|
||
conveyance of binary works based on GPL'd source, but without Complete,
|
||
Corresponding Source. This tutorial therefore focuses primarily on that issue.
|
||
|
||
Admittedly, a tiny
|
||
minority of compliance situations relate to question of derivative,
|
||
combined, or modified versions of the work. Those
|
||
situations are so rare, and the details from situation to situation differ
|
||
greatly. Thus, such situations require a highly
|
||
fact-dependent analysis and cannot be addressed in a general-purpose
|
||
document such as this one.
|
||
|
||
\medskip
|
||
|
||
Most companies accused of violations lack a basic understanding
|
||
of how to comply even in the straightforward scenario. This document
|
||
provides those companies with the fundamental and generally applicable prerequisite knowledge.
|
||
For answers to rarer and more complicated legal questions, such as whether
|
||
your software is a derivative or combined work of some copylefted software, consult
|
||
with an attorney.\footnote{If you would like more information on the
|
||
application of derivative works doctrine to software, a detailed legal
|
||
discussion is presented in our colleague Dan Ravicher's article,
|
||
\textit{Software Derivative Work: A Circuit Dependent Determination} and in
|
||
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
|
||
Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
|
||
this tutorial}.}
|
||
|
||
This discussion thus assumes that you have already identified the
|
||
``work'' covered by the license, and that any components not under the GPL
|
||
(e.g., applications written entirely by your developers that merely happen
|
||
to run on a Linux-based operating system) distributed in conjunction with
|
||
those works are separate works within the meaning of copyright law and the GPL\@. In
|
||
such a case, the GPL requires you to provide complete corresponding
|
||
source (CCS)\footnote{For more on CCS, see
|
||
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
|
||
Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of
|
||
this tutorial}.}
|
||
for the GPL'd components and your modifications thereto, but not
|
||
for independent proprietary applications. The procedures described in
|
||
this document address this typical scenario.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
Use of these terms allows GPLv3 to be interpreted authoritatively based
|
||
solely on local legal knowledge and the technical facts. Parties who may have
|
||
questions about compliance with GPLv3 under domestic copyright provisions
|
||
need only to ask two questions, one legal and the other factual:
|
||
|
||
Do I need a license under local copyright law to carry out this activity?
|
||
|
||
Does my activity enable any other party to make or receive a copy of the program?
|
||
|
||
If question 1 is answered by a local copyright lawyer in the negative, then
|
||
the activity involved is not propagation and is permitted by GPLv3 without
|
||
more. If the answers to both questions are positive, then the activity
|
||
involved is ``conveying'', and copyleft obligations apply.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\section{Monitor Software Acquisition}
|
||
|
||
Software engineers deserve the freedom to innovate and import useful
|
||
software components to improve products. However, along with that
|
||
freedom should come rules and reporting procedures to make sure that you
|
||
are aware of what software that you include with your product.
|
||
|
||
The most typical response to an initial enforcement action is: ``We
|
||
didn't know there was GPL'd stuff in there''. This answer indicates
|
||
failure in the software acquisition and procurement process. Integration
|
||
of third-party proprietary software typically requires a formal
|
||
arrangement and management/legal oversight before the developers
|
||
incorporate the software. By contrast, developers often obtain and
|
||
integrate Free Software without intervention nor oversight. That ease of acquisition, however,
|
||
does not mean the oversight is any less necessary. Just as your legal
|
||
and/or management team negotiates terms for inclusion of any proprietary
|
||
software, they should gently facilitate all decisions to bring Free Software into your
|
||
product.
|
||
|
||
Simple, engineering-oriented rules help provide a stable foundation for
|
||
Free Software integration. For example, simply ask your software developers to send an email to a
|
||
standard place describing each new Free Software component they add to the system,
|
||
and have them include a brief description of how they will incorporate it
|
||
into the product. Further, make sure developers use a revision control
|
||
system (such as Git or Mercurial), and
|
||
store the upstream versions of all software in a ``vendor branch'' or
|
||
similar mechanism, whereby they can easily track and find the main version
|
||
of the software and, separately, any local changes.
|
||
|
||
Such procedures are best instituted at your project's launch. Once
|
||
chaotic and poorly-sourced development processes begin, cataloging the
|
||
presence of GPL'd components becomes challenging.
|
||
|
||
Such a situation often requires use of a tool to ``catch up'' your knowledge
|
||
about what software your product includes. Most commonly, companies choose
|
||
some software licensing scanning tool to inspect the codebase. However,
|
||
there are few tools that are themselves Free Software. Thus, GPL enforcers
|
||
usually recommend the GPL'd
|
||
\href{http://fossology.org/}{FOSSology system}, which analyzes a
|
||
source code base and produces a list of Free Software licenses that may apply to
|
||
the code. FOSSology can help you build a catalog of the sources you have
|
||
already used to build your product. You can then expand that into a more
|
||
structured inventory and process.
|
||
|
||
\section{Track Your Changes and Releases}
|
||
|
||
As explained in further detail below, the most important component of GPL
|
||
compliance is the one most often ignored: proper inclusion of CCS in all
|
||
distributions of GPL'd
|
||
software. To comply with GPL's CCS requirements, the distributor
|
||
\textit{must} always know precisely what sources generated a given binary
|
||
distribution.
|
||
|
||
In an unfortunately large number of our enforcement cases, the violating
|
||
company's engineering team had difficulty reconstructing the CCS
|
||
for binaries distributed by the company. Here are three simple rules to
|
||
follow to decrease the likelihood of this occurrence:
|
||
|
||
\begin{itemize}
|
||
|
||
\item Ensure that your
|
||
developers are using revision control systems properly.
|
||
|
||
\item Have developers mark or ``tag'' the full source tree corresponding to
|
||
builds distributed to customers.
|
||
|
||
\item Check that your developers store all parts of the software
|
||
development in the revision control system, including {\sc readme}s, build
|
||
scripts, engineers' notes, and documentation.
|
||
\end{itemize}
|
||
|
||
Your developers will benefit anyway from these rules. Developers will be
|
||
happier in their jobs if their tools already track the precise version of
|
||
source that corresponds to any deployed binary.
|
||
|
||
\section{Avoid the ``Build Guru''}
|
||
|
||
Too many software projects rely on only one or a very few team members who
|
||
know how to build and assemble the final released product. Such knowledge
|
||
centralization not only creates engineering redundancy issues, but also
|
||
thwarts GPL compliance. Specifically, CCS does not just require source code,
|
||
but scripts and other material that explain how to control compilation and
|
||
installation of the executable and object code.
|
||
|
||
Thus, avoid relying on a ``build guru'', a single developer who is the only one
|
||
who knows how to produce your final product. Make sure the build process
|
||
is well defined. Train every developer on the build process for the final
|
||
binary distribution, including (in the case of embedded software)
|
||
generating a final firmware image suitable for distribution to the
|
||
customer. Require developers to use revision control for build processes.
|
||
Make a rule that adding new components to the system without adequate
|
||
build instructions (or better yet, scripts) is unacceptable engineering
|
||
practice.
|
||
|
||
\chapter{Details of Compliant Distribution}
|
||
|
||
This section explains the specific requirements placed upon
|
||
distributors of GPL'd software. Note that this section refers heavily to
|
||
specific provisions and language in
|
||
\href{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section3}{GPLv2}
|
||
and \href{http://www.fsf.org/licensing/licenses/gpl.html#section6}{GPLv3}.
|
||
It may be helpful to have a copy of each license open while reading this
|
||
section.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
with Section 1 is the source of the requirement that
|
||
the full license text must accompany every distribution of a source or binary
|
||
version of each licensed work, to ensure that users have actual notice of
|
||
their rights. This requirement is responsible for a surprisingly significant
|
||
fraction of compliance complaints, primarily because users are not provided
|
||
with required information about the presence of GPL’d programs and the
|
||
applicable license terms in physical products that they have purchased. The
|
||
most effective mode of compliance engineering is to treat the required
|
||
license texts as a ``make target'' in the compiling, packaging and distribution
|
||
of the software, so that license texts and other ``collateral'' for the
|
||
software in a product stack are produced and verified at the same stages and
|
||
in the same fashion that the binaries themselves are generated, tested and
|
||
packaged.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\section{Binary Distribution Permission}
|
||
\label{binary-distribution-permission}
|
||
|
||
% be careful below, you cannot refill the \if section, so don't refill
|
||
% this paragraph without care.
|
||
|
||
The various versions of the GPL are copyright licenses that grant
|
||
permission to make certain uses of software that are otherwise restricted
|
||
by copyright law. This permission is conditioned upon compliance with the
|
||
GPL's requirements.
|
||
|
||
This section walks through the requirements (of both GPLv2 and GPLv3) that
|
||
apply when you distribute GPL'd programs in binary (i.e., executable or
|
||
object code) form, which is typical for embedded applications. Because a
|
||
binary application derives from a program's original sources, you need
|
||
permission from the copyright holder to distribute it. \S~3 of GPLv2 and
|
||
\S~6 of GPLv3 contain the permissions and conditions related to binary
|
||
distributions of GPL'd programs.\footnote{These sections cannot be fully
|
||
understood in isolation; read the entire license thoroughly before
|
||
focusing on any particular provision. However, once you have read and
|
||
understood the entire license, look to these sections to guide
|
||
compliance for binary distributions.}
|
||
|
||
GPL's binary distribution sections offer a choice of compliance methods,
|
||
each of which we consider in turn. Each option refers to the
|
||
``Corresponding Source'' code for the binary distribution, which includes
|
||
the source code from which the binary was produced. This abbreviated and
|
||
simplified definition is sufficient for the binary distribution discussion
|
||
in this section, but you may wish to refer back to this section after
|
||
reading the thorough discussion of ``Corresponding Source'' that appears
|
||
in \S~\ref{corresponding-source}.
|
||
|
||
\subsection{Option (a): Source Alongside Binary}
|
||
|
||
GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing
|
||
source code: including Corresponding Source with every binary
|
||
distribution. While other options appear initially less onerous, this
|
||
option invariably minimizes potential compliance problems, because when
|
||
you distribute Corresponding Source with the binary, \emph{your GPL
|
||
obligations are satisfied at the time of distribution}. This is not
|
||
true of other options, and for this reason, we urge you to seriously
|
||
consider this option. If you do not, you may extend the duration of your
|
||
obligations far beyond your last binary distribution.
|
||
|
||
Compliance under this option is straightforward. If you ship a product
|
||
that includes binary copies of GPL'd software (e.g., in firmware, or on a
|
||
hard drive, CD, or other permanent storage medium), you can store the
|
||
Corresponding Source alongside the binaries. Alternatively, you can
|
||
include the source on a CD or other removable storage medium in the box
|
||
containing the product.
|
||
|
||
GPLv2 refers to the various storage mechanisms as ``medi[a] customarily
|
||
used for software interchange''. While the Internet has attained primacy
|
||
as a means of software distribution where super-fast Internet connections
|
||
are available, GPLv2 was written at a time when downloading software was
|
||
not practical (and was often impossible). For much of the world, this
|
||
condition has not changed since GPLv2's publication, and the Internet
|
||
still cannot be considered ``a medium customary for software
|
||
interchange''. GPLv3 clarifies this matter, requiring that source be
|
||
``fixed on a durable physical medium customarily used for software
|
||
interchange''. This language affirms that option (a) requires binary
|
||
redistributors to provide source on a physical medium.
|
||
|
||
Please note that while selection of option (a) requires distribution on a
|
||
physical medium, voluntary distribution via the Internet is very useful. This
|
||
is discussed in detail in \S~\ref{offer-with-internet}.
|
||
|
||
\subsection{Option (b): The Offer}
|
||
\label{offer-for-source}
|
||
|
||
Many distributors prefer to ship only an offer for source with the binary
|
||
distribution, rather than the complete source package. This
|
||
option has value when the cost of source distribution is a true
|
||
per-unit cost. For example, this option might be a good choice for
|
||
embedded products with permanent storage too small to fit the source, and
|
||
which are not otherwise shipped with a CD but \emph{are} shipped with a
|
||
manual or other printed material.
|
||
|
||
However, this option increases the duration of your obligations
|
||
dramatically. An offer for source must be good for three full years from
|
||
your last binary distribution (under GPLv2), or your last binary or spare
|
||
part distribution (under GPLv3). Your source code request and
|
||
provisioning system must be designed to last much longer than your product
|
||
life cycle.
|
||
|
||
% FIXME-URGENT: integrate
|
||
it also increases your compliance costs in the long
|
||
run
|
||
%FIXME-URGENT: END
|
||
|
||
In addition, if you are required to comply with the terms of GPLv2, you
|
||
{\bf cannot} use a network service to provide the source code. For GPLv2,
|
||
the source code offer is fulfilled only with physical media. This usually
|
||
means that you must continue to produce an up-to-date ``source code CD''
|
||
for years after the product's end-of-life.
|
||
|
||
\label{offer-with-internet}
|
||
|
||
Under GPLv2, it is acceptable and advisable for your offer for source code
|
||
to include an Internet link for downloadable source \emph{in addition} to
|
||
offering source on a physical medium. This practice enables those with
|
||
fast network connections to get the source more quickly, and typically
|
||
decreases the number of physical media fulfillment requests.
|
||
(GPLv3~\S~6(b) permits provision of source with a public
|
||
network-accessible distribution only and no physical media. We discuss
|
||
this in detail at the end of this section.)
|
||
|
||
The following is a suggested compliant offer for source under GPLv2 (and
|
||
is also acceptable for GPLv3) that you would include in your printed
|
||
materials accompanying each binary distribution:
|
||
|
||
\begin{quote}
|
||
The software included in this product contains copyrighted software that
|
||
is licensed under the GPL\@. A copy of that license is included in this
|
||
document on page $X$\@. You may obtain the complete Corresponding Source
|
||
code from us for a period of three years after our last shipment of this
|
||
product, which will be no earlier than 2011-08-01, by sending a money
|
||
order or check for \$5 to: \\
|
||
GPL Compliance Division \\
|
||
Our Company \\
|
||
Any Town, US 99999 \\
|
||
\\
|
||
Please write ``source for product $Y$'' in the memo line of your
|
||
payment.
|
||
|
||
You may also find a copy of the source at
|
||
\url{http://www.example.com/sources/Y/}.
|
||
|
||
This offer is valid to anyone in receipt of this information.
|
||
\end{quote}
|
||
|
||
There are a few important details about this offer. First, it requires a
|
||
copying fee. GPLv2 permits ``a charge no more than your cost of
|
||
physically performing source distribution''. This fee must be reasonable.
|
||
If your cost of copying and mailing a CD is more than around \$10, you
|
||
should perhaps find a cheaper CD stock and shipment method. It is simply
|
||
not in your interest to try to overcharge the community. Abuse of this
|
||
provision in order to make a for-profit enterprise of source code
|
||
provision will likely trigger enforcement action.
|
||
|
||
Second, note that the last line makes the offer valid to anyone who
|
||
requests the source. This is because v2~\S~3(b) requires that offers be
|
||
``to give any third party'' a copy of the Corresponding Source. GPLv3 has
|
||
a similar requirement, stating that an offer must be valid for ``anyone
|
||
who possesses the object code''. These requirements indicated in
|
||
v2~\S~3(c) and v3~\S~6(c) are so that noncommercial redistributors may
|
||
pass these offers along with their distributions. Therefore, the offers
|
||
must be valid not only to your customers, but also to anyone who received
|
||
a copy of the binaries from them. Many distributors overlook this
|
||
requirement and assume that they are only required to fulfill a request
|
||
from their direct customers.
|
||
|
||
The option to provide an offer for source rather than direct source
|
||
distribution is a special benefit to companies equipped to handle a
|
||
fulfillment process. GPLv2~\S~3(c) and GPLv3~\S~6(c) avoid burdening
|
||
noncommercial, occasional redistributors with fulfillment request
|
||
obligations by allowing them to pass along the offer for source as they
|
||
received it.
|
||
|
||
Note that commercial redistributors cannot avail themselves of the option
|
||
(c) exception, and so while your offer for source must be good to anyone
|
||
who receives the offer (under v2) or the object code (under v3), it
|
||
\emph{cannot} extinguish the obligations of anyone who commercially
|
||
redistributes your product. The license terms apply to anyone who
|
||
distributes GPL'd software, regardless of whether they are the original
|
||
distributor. Take the example of Vendor $V$, who develops a software
|
||
platform from GPL'd sources for use in embedded devices. Manufacturer $M$
|
||
contracts with $V$ to install the software as firmware in $M$'s device.
|
||
$V$ provides the software to $M$, along with a compliant offer for source.
|
||
In this situation, $M$ cannot simply pass $V$'s offer for source along to
|
||
its customers. $M$ also distributes the GPL'd software commercially, so
|
||
$M$ too must comply with the GPL and provide source (or $M$'s \emph{own}
|
||
offer for source) to $M$'s customers.
|
||
|
||
This situation illustrates that the offer for source is often a poor
|
||
choice for products that your customers will likely redistribute. If you
|
||
include the source itself with the products, then your distribution to
|
||
your customers is compliant, and their (unmodified) distribution to their
|
||
customers is likewise compliant, because both include source. If you
|
||
include only an offer for source, your distribution is compliant but your
|
||
customer's distribution does not ``inherit'' that compliance, because they
|
||
have not made their own offer to accompany their distribution.
|
||
|
||
The terms related to the offer for source are quite different if you
|
||
distribute under GPLv3. Under v3, you may make source available only over
|
||
a network server, as long as it is available to the general public and
|
||
remains active for three years from the last distribution of your product
|
||
or related spare part. Accordingly, you may satisfy your fulfillment
|
||
obligations via Internet-only distribution. This makes the ``offer for
|
||
source'' option less troublesome for v3-only distributions, easing
|
||
compliance for commercial redistributors. However, before you switch to a
|
||
purely Internet-based fulfillment process, you must first confirm that you
|
||
can actually distribute \emph{all} of the software under GPLv3. Some
|
||
programs are indeed licensed under ``GPLv2, \emph{or any later version}''
|
||
(often abbreviated ``GPLv2-or-later''). Such licensing gives you the
|
||
option to redistribute under GPLv3. However, a few popular programs are
|
||
only licensed under GPLv2 and not ``or any later version''
|
||
(``GPLv2-only''). You cannot provide only Internet-based source request
|
||
fulfillment for the latter programs.
|
||
|
||
If you determine that all GPL'd works in your whole product allow upgrade
|
||
to GPLv3 (or were already GPLv3'd to start), your offer for source may be
|
||
as simple as this:
|
||
|
||
\begin{quote}
|
||
The software included in this product contains copyrighted software that
|
||
is licensed under the GPLv3\@. A copy of that license is included in this
|
||
document on page $X$\@. You may obtain the complete Corresponding Source
|
||
code from us for a period of three years after our last shipment of this
|
||
product and/or spare parts therefor, which will be no earlier than
|
||
2011-08-01, on our website at
|
||
\url{http://www.example.com/sources/productnum/}.
|
||
\end{quote}
|
||
|
||
\medskip
|
||
|
||
Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of
|
||
the license itself, either electronically or in print, with every
|
||
distribution.
|
||
|
||
Finally, it is unacceptable to use option (b) merely because you do not have
|
||
Corresponding Source ready. We find that some companies choose this option
|
||
because writing an offer is easy, but producing a source distribution as
|
||
an afterthought to a hasty development process is difficult. The offer
|
||
for source does not exist as a stop-gap solution for companies rushing to
|
||
market with an out-of-compliance product. If you ship an offer for source
|
||
with your product but cannot actually deliver \emph{immediately} on that
|
||
offer when your customers request it, you should expect an enforcement
|
||
action.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Failure to provide or offer complete and corresponding source code is the
|
||
single largest failure mode leading to compliance disputes.
|
||
%FIXME-URGENT: END
|
||
|
||
\subsection{Option (c): Noncommercial Offers}
|
||
|
||
As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply
|
||
only to noncommercial use. These options are not available to businesses
|
||
distributing GPL'd software. Consequently, companies that redistribute
|
||
software packaged for them by an upstream vendor cannot merely pass along
|
||
the offer they received from the vendor; they must provide their own offer
|
||
or corresponding source to their distributees. We talk in detail about
|
||
upstream software providers in \S~\ref{upstream}.
|
||
|
||
\subsection{Option 6(d) in GPLv3: Internet Distribution}
|
||
|
||
Under GPLv2, your formal provisioning options for Corresponding Source
|
||
ended with \S~3(c). But even under GPLv2, pure Internet source
|
||
distribution was a common practice and generally considered to be
|
||
compliant. GPLv2 mentions Internet-only distribution almost as aside in
|
||
the language, in text at the end of the section after the three
|
||
provisioning options are listed. To quote that part of GPLv2~\S~3:
|
||
\begin{quote}
|
||
If distribution of executable or object code is made by offering access to
|
||
copy from a designated place, then offering equivalent access to copy the
|
||
source code from the same place counts as distribution of the source code,
|
||
even though third parties are not compelled to copy the source along with
|
||
the object code.
|
||
\end{quote}
|
||
|
||
When that was written in 1991, Internet distribution of software was the
|
||
exception, not the rule. Some FTP sites existed, but generally software
|
||
was sent on magnetic tape or CDs. GPLv2 therefore mostly assumed that
|
||
binary distribution happened on some physical media. By contrast,
|
||
GPLv3~\S~6(d) explicitly gives an option for this practice that the
|
||
community has historically considered GPLv2-compliant.
|
||
|
||
Thus, you may fulfill your source-provision obligations by providing the
|
||
source code in the same way and from the same location. When exercising
|
||
this option, you are not obligated to ensure that users download the
|
||
source when they download the binary, and you may use separate servers as
|
||
needed to fulfill the requests as long as you make the source as
|
||
accessible as the binary. However, you must ensure that users can easily
|
||
find the source code at the time they download the binary. GPLv3~\S~6(d)
|
||
thus clarifies a point that has caused confusion about source provision in
|
||
v2. Indeed, many such important clarifications are included in v3 which
|
||
together provide a compelling reason for authors and redistributors alike
|
||
to adopt GPLv3.
|
||
|
||
\subsection{Option 6(e) in GPLv3: Software Torrents}
|
||
|
||
Peer-to-peer file sharing arose well after GPLv2 was written, and does not
|
||
easily fit any of the v2 source provision options. GPLv3~\S~6(e)
|
||
addresses this issue, explicitly allowing for distribution of source and
|
||
binary together on a peer-to-peer file sharing network. If you distribute
|
||
solely via peer-to-peer networks, you can exercise this option. However,
|
||
peer-to-peer source distribution \emph{cannot} fulfill your source
|
||
provision obligations for non-peer-to-peer binary distributions. Finally,
|
||
you should ensure that binaries and source are equally seeded upon initial
|
||
peer-to-peer distribution.
|
||
|
||
\section{Preparing Corresponding Source}
|
||
\label{corresponding-source}
|
||
|
||
Most enforcement cases involve companies that have unfortunately not
|
||
implemented procedures like our \S~\ref{best-practices} recommendations
|
||
and have no source distribution arranged at all. These companies must
|
||
work backwards from a binary distribution to come into compliance. Our
|
||
recommendations in \S~\ref{best-practices} are designed to make it easy to
|
||
construct a complete and Corresponding Source release from the outset. If
|
||
you have followed those principles in your development, you can meet the
|
||
following requirements with ease. If you have not, you may have
|
||
substantial reconstruction work to do.
|
||
|
||
\subsection{Assemble the Sources}
|
||
|
||
For every binary that you produce, you should collect and maintain a copy
|
||
of the sources from which it was built. A large system, such as an
|
||
embedded firmware, will probably contain many GPL'd and LGPL'd components
|
||
for which you will have to provide source. The binary distribution may
|
||
also contain proprietary components which are separate and independent
|
||
works that are covered by neither the GPL nor LGPL\@.
|
||
|
||
The best way to separate out your sources is to have a subdirectory for
|
||
each component in your system. You can then easily mark some of them as
|
||
required for your Corresponding Source releases. Collecting
|
||
subdirectories of GPL'd and LGPL'd components is the first step toward
|
||
preparing your release.
|
||
|
||
\subsection{Building the Sources}
|
||
|
||
Few distributors, particularly of embedded systems, take care to read the
|
||
actual definition of Corresponding Source in the GPL\@. Consider
|
||
carefully the definition, from GPLv3:
|
||
\begin{quote}
|
||
The ``Corresponding Source'' for a work in object code form means all
|
||
the source code needed to generate, install, and (for an executable
|
||
work) run the object code and to modify the work, including scripts to
|
||
control those activities.
|
||
\end{quote}
|
||
|
||
and the definition from GPLv2:
|
||
\begin{quote}
|
||
The source code for a work means the preferred form of the work for making
|
||
modifications to it. For an executable work, complete source code means
|
||
all the source code for all modules it contains, plus any associated
|
||
interface definition files, plus the scripts used to control compilation
|
||
and installation of the executable.
|
||
\end{quote}
|
||
|
||
Note that you must include ``scripts used to control compilation and
|
||
installation of the executable'' and/or anything ``needed to generate,
|
||
install, and (for an executable work) run the object code and to modify
|
||
the work, including scripts to control those activities''. These phrases
|
||
are written to cover different types of build environments and systems.
|
||
Therefore, the details of what you need to provide with regard to scripts
|
||
and installation instructions vary depending on the software details. You
|
||
must provide all information necessary such that someone generally skilled
|
||
with computer systems could produce a binary similar to the one provided.
|
||
|
||
Take as an example an embedded wireless device. Usually, a company
|
||
distributes a firmware, which includes a binary copy of
|
||
Linux\footnote{``Linux'' refers only to the kernel, not the larger system
|
||
as a whole.} and a filesystem. That filesystem contains various binary
|
||
programs, including some GPL'd binaries, alongside some proprietary
|
||
binaries that are separate works (i.e., not derived from, nor based on
|
||
freely-licensed sources). Consider what, in this case, constitutes adequate
|
||
``scripts to control compilation and installation'' or items ``needed to
|
||
generate, install and run'' the GPL'd programs.
|
||
|
||
Most importantly, you must provide some sort of roadmap that allows
|
||
technically sophisticated users to build your software. This can be
|
||
complicated in an embedded environment. If your developers use scripts to
|
||
control the entire compilation and installation procedure, then you can
|
||
simply provide those scripts to users along with the sources they act
|
||
upon. Sometimes, however, scripts were never written (e.g., the
|
||
information on how to build the binaries is locked up in the mind of your
|
||
``build guru''). In that case, we recommend that you write out build
|
||
instructions in a natural language as a detailed, step-by-step {\sc
|
||
readme}.
|
||
|
||
No matter what you offer, you need to give those who receive source a
|
||
clear path from your sources to binaries similar to the ones you ship. If
|
||
you ship a firmware (kernel plus filesystem), and the filesystem contains
|
||
binaries of GPL'd programs, then you should provide whatever is necessary
|
||
to enable a reasonably skilled user to build any given GPL'd source
|
||
program (and modified versions thereof), and replace the given binary in
|
||
your filesystem. If the kernel is Linux, then the users must have the
|
||
instructions to do the same with the kernel. The best way to achieve this
|
||
is to make available to your users whatever scripts or process your
|
||
engineers would use to do the same.
|
||
|
||
These are the general details for how installation instructions work.
|
||
Details about what differs when the work is licensed under LGPL is
|
||
discussed in \S~\ref{lgpl}, and specific details that are unique to
|
||
GPLv3's installation instructions are in \S~\ref{user-products}.
|
||
|
||
\subsection{What About the Compiler?}
|
||
|
||
The GPL contains no provision that requires distribution of the compiler
|
||
used to build the software. While companies are encouraged to make it as
|
||
easy as possible for their users to build the sources, inclusion of the
|
||
compiler itself is not normally considered mandatory. The Corresponding
|
||
Source definition -- both in GPLv2 and GPLv3 -- has not been typically
|
||
read to include the compiler itself, but rather things like makefiles,
|
||
build scripts, and packaging scripts.
|
||
|
||
Nonetheless, in the interest of goodwill and the spirit of the GPL, most
|
||
companies do provide the compiler itself when they are able, particularly
|
||
when the compiler is based on GCC\@ or another copylefted compiler. If you have
|
||
a GCC-based system, it is your prerogative to redistribute that GCC
|
||
version (binaries plus sources) to your customers. We in the software freedom
|
||
community encourage you to do this, since it often makes it easier for
|
||
users to exercise their software freedom. However, if you chose to take
|
||
this recommendation, ensure that your GCC distribution is itself
|
||
compliant.
|
||
|
||
If you have used a proprietary, third-party compiler to build the
|
||
software, then you probably cannot ship it to your customers. We consider
|
||
the name of the compiler, its exact version number, and where it can be
|
||
acquired as information that \emph{must} be provided as part of the
|
||
Corresponding Source. This information is essential to anyone who wishes
|
||
to produce a binary. It is not the intent of the GPL to require you to
|
||
distribute third-party software tools to your customer (provided the tools
|
||
themselves are not based on the GPL'd software shipped), but we do believe
|
||
it requires that you give the user all the essential non-proprietary facts
|
||
that you had at your disposal to build the software. Therefore, if you
|
||
choose not to distribute the compiler, you should include a {\sc readme}
|
||
about where you got it, what version it was, and who to contact to acquire
|
||
it, regardless of whether your compiler is Free Software, proprietary, or
|
||
internally developed.
|
||
|
||
\section{Best Practices and Corresponding Source}
|
||
|
||
\S~\ref{best-practices} and \S~\ref{corresponding-source} above are
|
||
closely related. If you follow the best practices outlined above, you
|
||
will find that preparing your Corresponding Source release is an easier
|
||
task, perhaps even a trivial one.
|
||
|
||
Indeed, the enforcement process itself has historically been useful to
|
||
software development teams. Development on a deadline can lead
|
||
organizations to cut corners in a way that negatively impacts its
|
||
development processes. We have frequently been told by violators that
|
||
they experience difficulty when determining the exact source for a binary
|
||
in production (in some cases because their ``build guru'' quit during the
|
||
release cycle). When management rushes a development team to ship a
|
||
release, they are less likely to keep release sources tagged and build
|
||
systems well documented.
|
||
|
||
We suggest that, if contacted about a violation, product builders use GPL
|
||
enforcement as an opportunity to improve their development practices. No
|
||
developer would argue that their system is better for having a mysterious
|
||
build system and no source tracking. Address these issues by installing a
|
||
revision system, telling your developers to use it, and requiring your
|
||
build guru to document his or her work!
|
||
|
||
|
||
% FIXME-URGENT: integrate, possibly create:
|
||
% \section{Non-Technical Compliance Issues}
|
||
|
||
Compliance with GPLv2 \S7 is therefore a matter of legal review rather than
|
||
technical or engineering practice.
|
||
|
||
%FIXME-URGENT: integrate
|
||
% Possibly call this: \section{Self-Assessment of Compliance}
|
||
|
||
\section{FIXME}
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Measure your compliance from the position of the user downstream from you
|
||
trying to exercise rights conveyed by the licenses. Has the user received
|
||
notice of the copylefted software intentionally included in your product? Is
|
||
complete, corresponding source code and applicable installation information
|
||
available to the user easily, preferably by automated means? Tools that
|
||
measure what you deliver are more valuable than tools that only measure what
|
||
you build.
|
||
|
||
Always exercise your own right to request complete and corresponding source
|
||
code for all copylefted works from all your providers of software and of
|
||
components embedding software, preferably in an automated process directly
|
||
feeding your overall software governance system. Where possible, reject as
|
||
non-conforming components provided to you containing copylefted software for
|
||
which complete and corresponding source code is not furnished in response to
|
||
your request or which is not accompanied by a ``stackmark'' for automated
|
||
provisioning of source code. If you rely on an upstream provider for your
|
||
software you cannot ignore your GPL compliance requirements simply because
|
||
someone else packaged the software that you distribute.
|
||
|
||
%FIXME-URGENT: integrate
|
||
% Possibly call this: \section{Third-Party Compliance Assessors}
|
||
|
||
\section{FIXME}
|
||
|
||
|
||
Concentrate on the copylefted software you know you are using. Historically,
|
||
the risk from a copylefted code snippet that some programmer dropped in your
|
||
proprietary product careless of the consequences is a problem far more
|
||
infrequent and less difficult to resolve. Efficient management of the risks
|
||
of higher concern lies in making sure you can provide, for example, precisely
|
||
corresponding source code and makefiles for a copy of the Coreboot
|
||
bootloader, Linux kernel, Busybox, or GNU tar that you included in a product
|
||
you shipped two years ago.
|
||
|
||
Don’t rely blindly on code scanners as they work too late in the process to
|
||
improve your governance and too early in the process to catch problems in
|
||
your delivery and post-sale provisioning. They do less important parts of the
|
||
job expensively, and more important parts of the job not at all. Use them,
|
||
where they are cost-effective, as a supplement to your own governance and
|
||
verification processes, not as a primary tool of risk management.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\chapter{When The Letter Comes}
|
||
|
||
Unfortunately, many GPL violators ignore their obligations until they are
|
||
contacted by a copyright holder or the lawyer of a copyright holder. You
|
||
should certainly contact your own lawyer if you have received a letter
|
||
alleging that you have infringed copyrights that were licensed to you
|
||
under the GPL\@. This section outlines a typical enforcement case and
|
||
provides some guidelines for response. These discussions are
|
||
generalizations and do not all apply to every alleged violation.
|
||
|
||
\section{Understanding Who's Enforcing}
|
||
\label{compliance-understanding-whos-enforcing}
|
||
% FIXME-LATER: this text needs work.
|
||
|
||
Both FSF and Conservancy has, as part their mission, to spread software
|
||
freedom. When FSF or Conservancy
|
||
enforces GPL, the goal is to bring the violator back into compliance as
|
||
quickly as possible, and redress the damage caused by the violation.
|
||
That is FSF's steadfast position in a violation negotiation --- comply
|
||
with the license and respect freedom.
|
||
|
||
However, other entities who do not share the full ethos of software freedom
|
||
as institutionalized by FSF and Conservancy pursue GPL violations differently. Oracle, a
|
||
company that produces the GPL'd MySQL database, upon discovering GPL
|
||
violations typically negotiates a proprietary software license separately for
|
||
a fee. While this practice is not one that FSF nor Conservancy would ever
|
||
consider undertaking or even endorsing, it is a legal way for copyright
|
||
holders to proceed.
|
||
|
||
Generally, GPL enforcers come in two varieties. First, there are
|
||
Conservancy, FSF, and other ``community enforcers'', who primarily seek the
|
||
policy goals of GPL (software freedom), and see financial compensation as
|
||
ultimately secondary to those goals. Second, there are ``for-profit
|
||
enforcers'' who use the GPL either as a crippleware license, or sneakily
|
||
induce infringement merely to gain proprietary licensing revenue.
|
||
|
||
Note that the latter model \textit{only} works for companies that hold 100\% of
|
||
the copyrights in the infringed work. As such, multi-copyright-held works
|
||
are fully insulated from these tactics.
|
||
|
||
% FIXME-URGENT: integrate, and rewrite so it doesn't laud behavior that is
|
||
% ultimately problematic.
|
||
|
||
companies have often formed beneficial consulting or employment relationships
|
||
with project developers they first encountered through compliance
|
||
inquiries. In some cases, working together to alter the mode of use of the
|
||
project’s code in the company’s products was an explicit element in dispute
|
||
resolution. More often, the communication channels opened in the course of
|
||
the inquiry served other and more fruitful purposes later.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
|
||
\section{Communication Is Key}
|
||
|
||
GPL violations are typically only escalated when a company ignores the
|
||
copyright holder's initial communication or fails to work toward timely
|
||
compliance. Accused violators should respond very promptly to the
|
||
initial request. As the process continues, violators should follow up weekly with the
|
||
copyright holders to make sure everyone agrees on targets and deadlines
|
||
for resolving the situation.
|
||
|
||
Ensure that any staff who might receive communications regarding alleged
|
||
GPL violations understands how to channel the communication appropriately
|
||
within your organization. Often, initial contact is addressed for general
|
||
correspondence (e.g., by mail to corporate headquarters or by e-mail to
|
||
general informational or support-related addresses). Train the staff that
|
||
processes such communications to escalate them to someone with authority
|
||
to take action. An unknowledgable response to such an inquiry (e.g., from
|
||
a first-level technical support person) can cause negotiations to fail
|
||
prematurely.
|
||
|
||
Answer promptly by multiple means (paper letter, telephone call, and
|
||
email), even if your response merely notifies the sender that you are
|
||
investigating the situation and will respond by a certain date. Do not
|
||
let the conversation lapse until the situation is fully resolved.
|
||
Proactively follow up with synchronous communication means to be sure
|
||
communications sent by non-reliable means (such as email) were received.
|
||
|
||
Remember that the software freedom community generally values open communication and
|
||
cooperation, and these values extend to GPL enforcement. You will
|
||
generally find that software freedom developers and their lawyers are willing to
|
||
have a reasonable dialogue and will work with you to resolve a violation
|
||
once you open the channels of communication in a friendly way.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Assume preparation on the complainant’s side. The organizations
|
||
traditionally bringing complaints of copyleft non-compliance all
|
||
fully investigate and verify complaints referred to them before making
|
||
contact with apparently non-complying parties. Complainants will be
|
||
prepared to substantiate the facts on which their complaint is based.
|
||
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
|
||
Let engineers be a part of the process. The most time-consuming and
|
||
difficult part of resolving most compliance matters, in our experience,
|
||
is verifying that source code is indeed complete and
|
||
corresponding. Without direct contact between software engineers on both
|
||
sides, the resolution of the technical issues involved in demonstrating
|
||
that the binary distributed was built from the source provided is likely
|
||
to be tortuous, expensive, and potentially tense. Counsel are
|
||
understandably reluctant to expose their client’s employees to direct
|
||
inquiry from potentially hostile parties. But facilitated exchanges of
|
||
information among software engineers communicating on technical subjects
|
||
shortens the time to resolution, substantially reduces the cost of
|
||
reaching resolution, and prevents unnecessary escalation due to mutual
|
||
misunderstanding.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Use compliance discussions to improve relationships. Development
|
||
communities make software to benefit users, which includes you. When you
|
||
use copylefted community software in your products, you are an important
|
||
and valuable part of the commons, from the developers’ point of
|
||
view. Resolving a compliance matter is an occasion to strengthen your
|
||
relationship to the commons, by increasing communication between your
|
||
engineers and the project whose output you use for business benefit.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\section{Termination}
|
||
|
||
Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and
|
||
GPLv3~\S~8). Under v2, violators forfeit their rights to redistribute and
|
||
modify the GPL'd software until those rights are explicitly reinstated by
|
||
the copyright holder. In contrast, v3 allows violators to rapidly resolve
|
||
some violations without consequence.
|
||
|
||
If you have redistributed an application under GPLv2\footnote{This applies
|
||
to all programs licensed to you under only GPLv2 (``GPLv2-only'').
|
||
However, most so-called GPLv2 programs are actually distributed with
|
||
permission to redistribute under GPLv2 \emph{or any later version of the
|
||
GPL} (``GPLv2-or-later''). In the latter cases, the redistributor can
|
||
choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even
|
||
GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the
|
||
v2 termination provision will always apply. If the redistributor has
|
||
chosen v3, the v3 termination provision will always apply. If the
|
||
redistributor has chosen GPLv2-or-later, then the redistributor may want
|
||
to narrow to GPLv3-only upon violation, to take advantage of the
|
||
termination provisions in v3.}, but have violated the terms of GPLv2,
|
||
you must request a reinstatement of rights from the copyright holders
|
||
before making further distributions, or else cease distribution and
|
||
modification of the software forever. Different copyright holders
|
||
condition reinstatement upon different requirements, and these
|
||
requirements can be (and often are) wholly independent of the GPL\@. The
|
||
terms of your reinstatement will depend upon what you negotiate with the
|
||
copyright holder of the GPL'd program.
|
||
|
||
Since your rights under GPLv2 terminate automatically upon your initial
|
||
violation, \emph{all your subsequent distributions} are violations and
|
||
infringements of copyright. Therefore, even if you resolve a violation on
|
||
your own, you must still seek a reinstatement of rights from the copyright
|
||
holders whose licenses you violated, lest you remain liable for
|
||
infringement for even compliant distributions made subsequent to the
|
||
initial violation.
|
||
|
||
GPLv3 is more lenient. If you have distributed only v3-licensed programs,
|
||
you may be eligible under v3~\S~8 for automatic reinstatement of rights.
|
||
You are eligible for automatic reinstatement when:
|
||
\begin{itemize}
|
||
\item you correct the violation and are not contacted by a copyright
|
||
holder about the violation within sixty days after the correction, or
|
||
|
||
\item you receive, from a copyright holder, your first-ever contact
|
||
regarding a GPL violation, and you correct that violation within thirty
|
||
days of receipt of copyright holder's notice.
|
||
\end{itemize}
|
||
|
||
In addition to these permanent reinstatements provided under v3, violators
|
||
who voluntarily correct their violation also receive provisional
|
||
permission to continue distributing until they receive contact from the
|
||
copyright holder. If sixty days pass without contact, that reinstatement
|
||
becomes permanent. Nonetheless, you should be prepared to cease
|
||
distribution during those initial sixty days should you receive a
|
||
termination notice from the copyright holder.
|
||
|
||
Given that much discussion of v3 has focused on its so-called more
|
||
complicated requirements, it should be noted that v3 is, in this regard,
|
||
more favorable to violators than v2.
|
||
|
||
However, note that most Linux-based systems typically include some software
|
||
licensed under GPLv2-only, and thus the copyright holders have withheld
|
||
permission to redistribute under terms of GPLv3. In larger aggregate
|
||
distributions which include GPLv2-only works (such as the kernel named
|
||
Linux), redistributors must operate as if termination is immediate and
|
||
permanent, since the technological remove of GPLv2-only works from the larger
|
||
distribution requires much more engineering work than the negotiation
|
||
required to seek restoration of rights for distribution under GPLv2-only
|
||
after permanent termination.
|
||
|
||
\chapter{Standard Requests}
|
||
|
||
As we noted above, different copyright holders have different requirements
|
||
for reinstating a violator's distribution rights. Upon violation, you no
|
||
longer have a license under the GPL\@. Copyright holders can therefore
|
||
set their own requirements outside the license before reinstatement of
|
||
rights. We have collected below a list of reinstatement demands that
|
||
copyright holders often require.
|
||
|
||
\begin{itemize}
|
||
|
||
\item {\bf Compliance on all Free Software copyrights}. Copyright holders of Free Software
|
||
often want a company to demonstrate compliance for all GPL'd software in
|
||
a distribution, not just their own. A copyright holder may refuse to
|
||
reinstate your right to distribute one program unless and until you
|
||
comply with the licenses of all Free Software in your distribution.
|
||
|
||
\item {\bf Notification to past recipients}. Users to whom you previously
|
||
distributed non-compliant software should receive a communication
|
||
(email, letter, bill insert, etc.) indicating the violation, describing
|
||
their rights under the GPL, and informing them how to obtain a gratis source
|
||
distribution. If a customer list does not exist (such as in reseller
|
||
situations), an alternative form of notice may be required (such as a
|
||
magazine advertisement).
|
||
|
||
\item {\bf Appointment of a GPL Compliance Officer.} The software freedom community
|
||
values personal accountability when things go wrong. Copyright holders
|
||
often require that you name someone within the violating company
|
||
officially responsible for Free Software license compliance, and that this
|
||
individual serve as the key public contact for the community when
|
||
compliance concerns arise.
|
||
|
||
\item {\bf Periodic Compliance Reports.} Many copyright holders wish to
|
||
monitor future compliance for some period of time after the violation.
|
||
For some period, your company may be required to send regular reports on
|
||
how many distributions of binary and source have occurred.
|
||
\end{itemize}
|
||
|
||
These are just a few possible requirements for reinstatement. In the
|
||
context of a GPL violation, and particularly under v2's termination
|
||
provision, the copyright holder may have a range of requests in exchange
|
||
for reinstatement of rights. These software developers are talented
|
||
professionals from whose work your company has benefited. Indeed, you are
|
||
unlikely to find a better value or more generous license terms for similar
|
||
software elsewhere. Treat the copyright holders with the same respect you
|
||
treat your corporate partners and collaborators.
|
||
|
||
\chapter{Special Topics in Compliance}
|
||
|
||
There are several other issues that are less common, but also relevant in
|
||
a GPL compliance situation. To those who face them, they tend to be of
|
||
particular interest.
|
||
|
||
% FIXME-URGENT: integrate
|
||
Non-compliance with GPLv3 in the
|
||
distribution of Javascript on the Web is becoming more frequent
|
||
%FIXME-URGENT: END
|
||
|
||
\section{LGPL Compliance}
|
||
\label{lgpl}
|
||
|
||
GPL compliance and LGPL compliance mostly involve the same issues. As we
|
||
discussed in \S~\ref{derivative-works}, questions of modified versions of
|
||
software are highly fact-dependant and cannot be easily addressed in any
|
||
overview document. The LGPL adds some additional complexity to the
|
||
analysis. Namely, the various LGPL versions permit proprietary licensing
|
||
of certain types of modified versions. These issues are well beyond the
|
||
scope of this document, but as a rule of thumb, once you have determined
|
||
(in accordance with LGPLv3) what part of the work is the ``Application''
|
||
and what portions of the source are ``Minimal Corresponding Source'', then
|
||
you can usually proceed to follow the GPL compliance rules that we
|
||
discussed, replacing our discussion of ``Corresponding Source'' with
|
||
``Minimal Corresponding Source''.
|
||
|
||
LGPL also requires that you provide a mechanism to combine the Application
|
||
with a modified version of the library, and outlines some options for
|
||
this. Also, the license of the whole work must permit ``reverse
|
||
engineering for debugging such modifications'' to the library. Therefore,
|
||
you should take care that the EULA used for the Application does not
|
||
contradict this permission.
|
||
|
||
%FIXME-URGENT: integrate
|
||
|
||
Section 2(a) states that if a licensed work is a software library (defined in
|
||
\S0 as ``a collection of software functions and/or data prepared so as to be
|
||
conveniently linked with application programs (which use some of those
|
||
functions and data) to form executables'') permission is given to distribute
|
||
modified versions only if those versions are themselves libraries. LGPLv2.1
|
||
code can therefore not be compliantly taken from its context in a library and
|
||
placed in a non-library modified version or work based on the work. Section 6
|
||
does not provide an exception for this rule: a combination may be made of a
|
||
modified version of an LGPL’d library with other code, but the LGPL’d code
|
||
must continue to be structured as a library, and to that library the terms of
|
||
the license continue to apply.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\section{Upstream Providers}
|
||
\label{upstream}
|
||
|
||
With ever-increasing frequency, software development (particularly for
|
||
embedded devices) is outsourced to third parties. If you rely on an
|
||
upstream provider for your software, note that you \emph{cannot ignore
|
||
your GPL compliance requirements} simply because someone else packaged
|
||
the software that you distribute. If you redistribute GPL'd software
|
||
(which you do, whenever you ship a device with your upstream's software in
|
||
it), you are bound by the terms of the GPL\@. No distribution (including
|
||
redistribution) is permissible absent adherence to the license terms.
|
||
|
||
Therefore, you should introduce a due diligence process into your software
|
||
acquisition plans. This is much like the software-oriented
|
||
recommendations we make in \S~\ref{best-practices}. Implementing
|
||
practices to ensure that you are aware of what software is in your devices
|
||
can only improve your general business processes. You should ask a clear
|
||
list of questions of all your upstream providers and make sure the answers
|
||
are complete and accurate. The following are examples of questions you
|
||
should ask:
|
||
\begin{itemize}
|
||
|
||
\item What are all the licenses that cover the software in this device?
|
||
|
||
\item From which upstream vendors, be they companies or individuals, did
|
||
\emph{you} receive your software before distributing it to us?
|
||
|
||
\item What are your GPL compliance procedures?
|
||
|
||
\item If there is GPL'd software in your distribution, we will be
|
||
redistributors of this GPL'd software. What mechanisms do you have in
|
||
place to aid us with compliance?
|
||
|
||
\item If we follow your recommended compliance procedures, will you
|
||
formally indemnify us in case we are nonetheless found to be in
|
||
violation of the GPL?
|
||
|
||
\end{itemize}
|
||
|
||
This last point is particularly important. Many GPL enforcements are
|
||
escalated because of petty finger-pointing between the distributor and its
|
||
upstream. In our experience, agreements regarding GPL compliance issues
|
||
and procedures are rarely negotiated up front. However, when they are,
|
||
violations are resolved much more smoothly (at least from the point of
|
||
view of the redistributor).
|
||
|
||
Consider the cost of potential violations in your acquisition process.
|
||
Using Free Software allows software vendors to reduce costs significantly, but be
|
||
wary of vendors who have done so without regard for the licenses. If your
|
||
vendor's costs seem ``too good to be true,'' you may ultimately bear the
|
||
burden of the vendor's inattention to GPL compliance. Ask the right
|
||
questions, demand an account of your vendors' compliance procedures, and
|
||
seek indemnity from them.
|
||
|
||
% FIXME-URGENT: integrate
|
||
|
||
In such instances it is advisable that you exercise your own rights as a user
|
||
to request C&CS for all the GPL programs that your suppliers provided to you,
|
||
preferably in an automated process. Once you receive such C&CS, passing it
|
||
along with your product will ensure your compliance with the license.
|
||
|
||
% FIXME-URGENT: Needs a new section
|
||
% \section{Mergers and Acquisitions}
|
||
|
||
[GPLv3] Section 10 also clarifies that in business acquisitions, whether by
|
||
sale of assets or transfers of control, the acquiring party is downstream
|
||
from the party acquired. This results in new automatic downstream licenses
|
||
from upstream copyright holders, licenses to all modifications made by the
|
||
acquired business, and rights to source code provisioning for the
|
||
now-downstream purchaser.
|
||
|
||
In our experience, the process whereby these matters are adjusted in most M&A
|
||
situations are ludicrously expensive and inefficient. A simple waiver and
|
||
release of all claims to GPL compliance against the purchased entity by the
|
||
purchaser, issued before closure, removes the problem. If the purchasing
|
||
entity has adequate software governance systems in place, all software
|
||
acquired in the course of the entity transaction is input to the standard
|
||
governance processes for acquired software, and downstream compliance by the
|
||
new merged entity is automatically handled.
|
||
|
||
%FIXME-URGENT: END
|
||
|
||
\section{User Products and Installation Information}
|
||
\label{user-products}
|
||
|
||
GPLv3 requires you to provide ``Installation Information'' when v3
|
||
software is distributed in a ``User Product.'' During the drafting of v3,
|
||
the debate over this requirement was contentious. However, the provision
|
||
as it appears in the final license is reasonable and easy to understand.
|
||
|
||
If you put GPLv3'd software into a User Product (as defined by the
|
||
license) and \emph{you} have the ability to install modified versions onto
|
||
that device, you must provide information that makes it possible for the
|
||
user to install functioning, modified versions of the software. Note that
|
||
if no one, including you, can install a modified version, this provision
|
||
does not apply. For example, if the software is burned onto an
|
||
non-field-upgradable ROM chip, and the only way that chip can be upgraded
|
||
is by producing a new one via a hardware factory process, then it is
|
||
acceptable that the users cannot electronically upgrade the software
|
||
themselves.
|
||
|
||
Furthermore, you are permitted to refuse support service, warranties, and
|
||
software updates to a user who has installed a modified version. You may
|
||
even forbid network access to devices that behave out of specification due
|
||
to such modifications. Indeed, this permission fits clearly with usual
|
||
industry practice. While it is impossible to provide a device that is
|
||
completely unmodifiable\footnote{Consider that the iPhone, a device
|
||
designed primarily to restrict users' freedom to modify it, was unlocked
|
||
and modified within 48 hours of its release.}, users are generally on
|
||
notice that they risk voiding their warranties and losing their update and
|
||
support services when they make modifications.\footnote{A popular t-shirt
|
||
in the software freedom community reads: ``I void warranties.''. Our community is
|
||
well-known for modifying products with full knowledge of the
|
||
consequences. GPLv3's ``Installation Instructions'' section merely
|
||
confirms that reality, and makes sure GPL rights can be fully exercised,
|
||
even if users exercise those rights at their own peril.}
|
||
|
||
GPLv3 is in many ways better for distributors who seek some degree of
|
||
device lock-down. Technical processes are always found for subverting any
|
||
lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike
|
||
with GPLv2, the license gives you clear provisions that you can rely on
|
||
when you are forced to cut off support, service or warranty for a customer
|
||
who has chosen to modify.
|
||
|
||
\chapter{Conclusion}
|
||
|
||
GPL compliance need not be an onerous process. Historically, struggles
|
||
have been the result of poor development methodologies and communications,
|
||
rather than any unexpected application of the GPL's source code disclosure
|
||
requirements.
|
||
|
||
Compliance is straightforward when the entirety of your enterprise is
|
||
well-informed and well-coordinated. The receptionists should know how to
|
||
route a GPL source request or accusation of infringement. The lawyers
|
||
should know the basic provisions of Free Software licenses and your source
|
||
disclosure requirements, and should explain those details to the software
|
||
developers. The software developers should use a version control system
|
||
that allows them to associate versions of source with distributed
|
||
binaries, have a well-documented build process that anyone skilled in the
|
||
art can understand, and inform the lawyers when they bring in new
|
||
software. Managers should build systems and procedures that keep everyone
|
||
on target. With these practices in place, any organization can comply
|
||
with the GPL without serious effort, and receive the substantial benefits
|
||
of good citizenship in the software freedom community, and lots of great code
|
||
ready-made for their products.
|
||
|
||
\vfill
|
||
|
||
% LocalWords: redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox
|
||
% LocalWords: someone's downloadable subdirectory subdirectories filesystem
|
||
% LocalWords: roadmap README upstream's Ravicher's FOSSology readme CDs iPhone
|
||
% LocalWords: makefiles violator's
|