1424 lines
76 KiB
TeX
1424 lines
76 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.
|
||
|
||
\section{Who Has Compliance Obligations?}
|
||
|
||
All distributors of modified or unmodified versions of copylefted works
|
||
unmodified versions of the works have compliance obligations. Common methods
|
||
of modifying the works include innumerable common acts, such as:
|
||
|
||
\begin{itemize}
|
||
|
||
\item embedding those works as executable copies
|
||
into a device,
|
||
|
||
\item transferring a digital copy of excutable copies to someone else,
|
||
|
||
\item posting a patch to the copylefted software to a public mailing list.
|
||
|
||
\end{itemize}
|
||
|
||
Such distributors have obligations to (at least) the users to whom they (or
|
||
intermediary parties) distribute those copies. In some cases, distributors
|
||
have obligations to third parties not directly receiving their distribution
|
||
of the works (depending on the distributors chosen licensing options, as
|
||
described later in \S~\ref{binary-distribution-permission}). In addition,
|
||
distributors have compliance obligations to upstream parties, such as
|
||
preservation of reasonable legal notices embedded in the code, and
|
||
appropriate labeling of modified versions.
|
||
|
||
Online service providers and distributors alike have other compliance
|
||
obligations. In general, they must refrain from imposing any additional
|
||
restrictions on downstream parties. Most typically, such compliance problems
|
||
arise from ``umbrella licenses:'' EULAs, or sublicenses that restrict
|
||
downstream users’ rights under copyleft. (See \S~\ref{GPLv2s6} and
|
||
\S~\ref{GPLv3s10}).
|
||
|
||
Patent holders having claims reading on GPL'd works they distribute must
|
||
refrain from enforcing those claims against parties to whom they distribute.
|
||
Furthermore, patent holders holding copyrights on GPLv3'd works must further
|
||
grant an explicit patent license for any patent claims reading on the version
|
||
they distributed, and therefore cannot enforce those specific patent claims
|
||
against anyone making, using or selling a work based on their distributed
|
||
version. All parties must 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, any legal conditions that would prevent them from meeting
|
||
any obligation under GPL\@. (See \S~\ref{GPLv2s7}, \S~\ref{GPLv3s11} and
|
||
\S~\ref{GPLv3s12}.
|
||
|
||
\section{What Are The Risks of Non-Compliance?}
|
||
|
||
Copyleft experts have for decades observed a significant mismatch between the
|
||
assumptions most businesses make about copyleft compliance and the realities.
|
||
Possibly due to excessive marketing of proprietary tools and services from
|
||
the for-profit compliance industry, businesses perennially focus on the wrong
|
||
concerns. This tutorial seeks to educate those businesses about what
|
||
actually goes wrong, what causes disputes, and how to resolve those disputes.
|
||
|
||
Many businesses currently invest undue resources 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. For example, some ``compliance
|
||
industry''\footnote{``Compliance industry'' refers to third-party for-profit
|
||
companies that market proprietary software tools and/or consulting services
|
||
that purport to aid businesses with their Free Software license compliance
|
||
obligations, such as those found in GPL and other copyleft licenses. This
|
||
tutorial leaves the term in quotes throughout, primarily to communicate the
|
||
skepticism most of this tutorial's authors feel regarding the mere
|
||
existence of this industry. Not only do copyleft advocates object on
|
||
principle to proprietary software tools in general, and to their ironic use
|
||
specifically to comply with copyleft, but also to the ``compliance
|
||
industry'' vendors' marketing messaging, which some copyleft advocates
|
||
claim as a cause in the risk misassessments discussed herein. Bradley
|
||
M.~Kuhn, specifically, regularly uses the term ``compliance industrial
|
||
complex''
|
||
\href{http://en.wikipedia.org/wiki/Military-industrial_complex}{to
|
||
analogize the types of problems in this industry to those warned against
|
||
in the phrase of origin}.} vendors insist that great effort must be
|
||
expended to carefully list, in the menus or manuals of embedded electronics
|
||
products, copyright notices for every last copyright holder that contributed
|
||
to the Free Software included in the product. While nearly all Free Software
|
||
licenses, including copylefts like GPL, require preservation and display of
|
||
copyright notices, failure to meet this specific requirement is trivially
|
||
remedied. Therefore, businesses should spend just reasonable efforts to
|
||
properly display copyright notices, and note that failure to do so is simply
|
||
remedied: add the missing copyright notice!
|
||
|
||
\section{Understanding Who's Enforcing}
|
||
\label{compliance-understanding-whos-enforcing}
|
||
|
||
The mismatch between actual compliance risk and compliance risk management
|
||
typically results from a misunderstanding of licensor intentions. For-profit
|
||
businesses often err by assuming other actors have kindred motivations. The
|
||
primary enforcers of the GPL, however, have goals that for-profit businesses
|
||
will find strange and perhaps downright alien.
|
||
|
||
Specifically, community-oriented GPL enforcement organizations (called
|
||
``COGEOs'' throughout the remainder of this tutorial) are typically
|
||
non-profit charities (such as the FSF and Software Freedom Conservancy) who
|
||
declare, as part of their charitable mission, advancement of software freedom
|
||
for all users. In the USA, these COGEOs are all classified as charitable
|
||
under the IRS's 501(c)(3) designation, which is reserved for organizations
|
||
that have a mission to enhance the public good.
|
||
|
||
As such, these COGEOs enforce GPL primarily to pursue the policy goals and
|
||
motivations discussed throughout this tutorial: to spread software freedom
|
||
further. As such, COGEOs are unified in their primary goal to bring the
|
||
violator back into compliance as quickly as possible, and redress the damage
|
||
caused by the violation. COGEOs are steadfast in their position in a
|
||
violation negotiation: comply with the license and respect freedom.
|
||
|
||
Certainly, other entities do not share the full ethos of software freedom as
|
||
institutionalized by COGEOs, and those entities 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 a COGEO would
|
||
undertaking nor endorsing, a copyleft license technically permits this
|
||
behavior. To put a finer point on this practice already discussed
|
||
in~\S~\ref{Proprietary Relicensing}, copyleft advocates usually find copyleft
|
||
enforcement efforts focused on extract alternative proprietary licenses
|
||
distasteful at best, and a corrupt manipulation of copyleft at worst. Much
|
||
to the advocates' chagrin, such for-profit enforcement efforts seem to
|
||
increase rather than decrease.
|
||
|
||
Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly
|
||
assume that all copyright holders seek royalties. Businesses therefore focus
|
||
on the risk of so-called ``accidental'' (typically as the result of
|
||
unsupervised activity by individual programmers) infringe copyright by
|
||
incorporating ``snippets'' of copylefted code into their own proprietary
|
||
computer program. ``Compliance industry'' flagship products, therefore,
|
||
focus on ``code scanning'' services that purport to detect accidental
|
||
inclusions. Such effort focuses on proprietary software development and view
|
||
Free Software as a foreign interloper. Such approach not only ignores
|
||
current reality that many companies build their products directly on major
|
||
copylefted projects (e.g., Android vendor's use of the kernel named Linux),
|
||
but also creates a culture of fear among developers, leading them into a
|
||
downward spiral of further hiding their necessary reliance on copylefted
|
||
software in the company's products.
|
||
|
||
Fortunately, COGEOs regard GPL compliance failures as an opportunity to
|
||
improve compliance. Every compliance failure downstream represents a loss of
|
||
rights by their users. The COGEOs are the guardian of its users’ and
|
||
developers' rights. Their activity seeks to restore those rights, and
|
||
to protect the project’s contributors’ intentions in the making of their
|
||
software.
|
||
|
||
\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 determining the
|
||
``work'' that must be licensed under GPL, or in other words, ``what is the
|
||
derivative and/or combined work that was created''. Nearly ever esoteric
|
||
question asked by lawyers seek to consider that question
|
||
\footnote{\tutorialpartsplit{In fact, a companion work, \textit{Detailed Analysis of the GNU GPL and Related
|
||
Licenses} contains an entire section discussing derivative works}{This tutorial in fact
|
||
also addresses the issue at length in~\S~\ref{derivative-works}}.} (perhaps because
|
||
that question explores exciting legal issues while the majority of the GPL
|
||
deals with much more mundane ones).
|
||
Of course, GPL was designed
|
||
primarily to embody the licensing feature of copyleft.
|
||
|
||
However, most companies who add
|
||
complex features to and make combinations with GPL'd software
|
||
are already well aware of their
|
||
more complex obligations under the license that require complex legal
|
||
analysis. And, there are few companies overall that engage in such
|
||
activities. Thus, in practical reality, this issue is not relevant to the vast
|
||
majority of companies distributing GPL'd software.
|
||
|
||
Thus, 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.
|
||
|
||
As such, issues of software delivery are the primary frustration for GPL
|
||
enforcers. In particular, the following short list accounts for at least 95\%
|
||
of the GPL violations ever encountered:
|
||
|
||
\begin{itemize}
|
||
|
||
\item The violator fails to provide required information about the presence
|
||
of copylefted programs and their applicable license terms in the product
|
||
they have purchased.
|
||
|
||
\item The violator fails to reliably deliver \hyperref[CCS
|
||
Definition]{complete, corresponding source} (CCS) for copylefted programs
|
||
the violator knew were included (i.e., the CCS is either delivered but
|
||
incomplete, or is not delivered at all).
|
||
|
||
\item Requestors are ignored when they communicate with violator's published
|
||
addresses requesting fulfillment of businesses’ obligations.
|
||
\end{itemize}
|
||
|
||
This tutorial therefore focuses primarily on these 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.
|
||
|
||
|
||
\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}
|
||
|
||
Distribution of GPL'd works has requirements; copyleft will not function
|
||
without placing requirements on redistribution. However, some requirements
|
||
are more likely to cause compliance difficult than others. This
|
||
chapter\footnote{Note that this chapter refers heavily to specific provisions
|
||
and language in
|
||
\hyperref[GPLv2s3-full-text]{GPLv2\S3}
|
||
and \hyperref[GPLv3s6-full-text]{GPLv3\S6}.
|
||
It may be helpful to review \S~\ref{GPLv2s3} and \S~\ref{GPLv3s6} first,
|
||
and then have a copy of each license open while reading this
|
||
section.} explains some the specific requirements placed upon
|
||
distributors of GPL'd software that redistributors are most likely to
|
||
overlook, yielding compliance problems.
|
||
|
||
First, \hyperref[GPLv2s1]{GPLv2\S1} and \hyperref[GPLv2s4]{GPLv2\S4} require
|
||
that the full license text must accompany every distribution (either in
|
||
source or binary form) of each licensed work. Strangely, this requirement is
|
||
responsible for a surprisingly significant fraction of compliance errors; too
|
||
often, physical products lack required information about the presence of
|
||
GPL’d programs and the applicable license terms. Automated build processes
|
||
can and should carry a copy of the license from the the source distribution
|
||
into the final binary firmware package for embedded products. Such
|
||
automation usually achieves compliance regarding license inclusion
|
||
requirements\footnote{At least one COGEO recommends the
|
||
\href{https://www.yoctoproject.org/}{Yocto Project}, since its engineers
|
||
have designed such features into it build process.}
|
||
|
||
\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.} Failure to provide or offer CCS is the
|
||
single largest failure mode leading to compliance disputes.
|
||
|
||
|
||
|
||
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. Thus, it also increases your compliance costs in the long
|
||
run.
|
||
|
||
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.
|
||
|
||
\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!
|
||
|
||
|
||
\section{Non-Technical Compliance Issues}
|
||
|
||
Certainly, the overwhelming majority of compliance issues are, in fact,
|
||
either procedural or technical. Thus, the primary material in this chapter
|
||
so far has covered those issues. However, a few compliance issues do require
|
||
more direct consideration of a legal situation. This portion guide does not
|
||
consider those in detail, as a careful reading of the earlier chapters of
|
||
Part~\ref{gpl-lgpl-part} shows various places where legal considerations are
|
||
necessary for considering compliance activity.
|
||
|
||
For example, specific compliance issues related to
|
||
\hyperref[GPLv2s7]{GPLv2\S7}, \hyperref[GPLv3s7]{GPLv3\S7}, and
|
||
\hyperref[GPLv3s7]{GPLv3\S11} demand a more traditional approach to legal
|
||
license compliance. Of course, such analysis and consideration can be
|
||
complicated, and some are considered in the enforcement case studies that
|
||
follow in the next part. However, compliance issues related to such sections
|
||
are not rare, and, as is typical, no specific training is available for
|
||
dealing with extremely rare occurrences.
|
||
|
||
\section{Self-Assessment of Compliance}
|
||
|
||
Most companies that adopt copylefted software believe they have complied.
|
||
Humans usually have difficult admitting their own mistakes, particularly
|
||
systematic ones. Therefore, perhaps the most important necessary step to
|
||
stay in compliance is a company's regular evaluation of their own compliance.
|
||
|
||
First, exercise a request CCS for all copylefted works from all your upstream
|
||
providers of software and of components embedding software. Then, perform
|
||
your own CCS check on this material first, and verify that it meets the
|
||
requirements. This tutorial presents later a case study of a CEGEO's CCS
|
||
check in \S~\ref{pristine-example}, which you can emulate when examining
|
||
their own CCS\@.
|
||
|
||
Second, measure all copyleft compliance from the position of the
|
||
users\footnote{Realizing of course that user very well may not be your own
|
||
customer.} downstream from you exercising their rights under GPL\@. Have
|
||
those users received notice of the copylefted software included in your
|
||
product? Is CCS available to the users easily (preferably by automated
|
||
means)? Ask yourself these questions frequently. If you cannot answer these
|
||
questions with certainty in the positive, dig deeper and modify your process.
|
||
|
||
Avoid ``compliance industry'' marketing distractions and concentrate on the
|
||
copylefted software you already know is in your product. 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
|
||
CCS for a copy of Coreboot, the kernel named Linux, Busybox, or GNU tar that
|
||
you included in a product your company shipped two years ago than in the risk
|
||
of 10 lines of GPL'd Java code an engineer accidentally pasted into the
|
||
source of your ERP system.
|
||
|
||
Thus, reject the ``compliance industry'' suggestions that code scanners find
|
||
and help solve fundamental compliance problems. Consider how CEGEO's tend to
|
||
use code scanners. FOSSology is indeed an important part of a violation
|
||
investigation, but such is the last step and catches only some (usually
|
||
minor) licensing notice problems. Thus, code scanners can help solve minor
|
||
compliance problems once you have resolved the major ones. Code scanners
|
||
do not manage risk.
|
||
|
||
\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. However,
|
||
CEGEO's in particular universally follow the processes described herein.
|
||
|
||
\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.
|
||
|
||
Furthermore, if the complaint comes from a CEGEO, assume they are
|
||
well-prepared. CEGEO's fully investigate compliance issues before raising
|
||
the issue. The claims and concerns will be substantiated, and immediate
|
||
denials will likely lead the CEGEO to suspect malice rather than honest
|
||
mistake.
|
||
|
||
However, the biggest and most perennial mistake that all CEGEOs see during
|
||
enforcement is this: failure to include the violators' software development
|
||
teams in the enforcement discussions and negotiations. As described above,
|
||
CCS verification and approval is the most time-consuming and difficult part
|
||
of resolving most compliance matters. Without direct contact between
|
||
software developers 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 tense. Your lawyers
|
||
will certainly be understandably reluctant to expose your employees to direct
|
||
inquiry from potentially adverse parties. However, 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. Furthermore, such frank technical discussion will often be
|
||
the only way to avoid compliance litigation once a violation has occurred.
|
||
|
||
Fortunately, these frank discussions will improve your company's
|
||
relationships. Free Software development communities improve software to
|
||
benefit everyone, which includes you and your company. When you use
|
||
copylefted community software in your products, you are part of that
|
||
community. Therefore, resolving a compliance matter is an occasion to
|
||
strengthen your relationship to the community, by increasing communication
|
||
between your developers and the project whose work you use for business
|
||
benefit.
|
||
|
||
\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.
|
||
|
||
\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
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
% FIXME-soon: write a full section on Javascript compliance. Here's a
|
||
% potentially useful one-sentence introduction for such a
|
||
% section.
|
||
|
||
% Non-compliance with GPLv3 in the
|
||
% distribution of Javascript on the Web is becoming more frequent
|
||
%FIXME-soon: END
|
||
|
||
|
||
% FIXME-URGENT: integrate, and rewrite so it doesn't laud behavior that is
|
||
% ultimately problematic.
|
||
\section{FIXME}
|
||
|
||
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
|
||
|
||
\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
|