@@ -44,97 +44,97 @@ 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
reports, Welte successfully pursued many enforcement actions 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
@@ -1242,97 +1242,97 @@ Chapter~\ref{LGPLv2}.
However, to repeat a key point here made within that chapter: Note though
that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the
worst case you simply need to comply as if the software was licensed under
GPLv2. The only reason you must consider the question of whether you have a
``work that uses the library'' or a ``work based on the library'' is when you
wish to take advantage of the ``weak copyleft'' effect of the Lesser GPL\@.
If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the
entire work anyway), you may find this an easier option.
\section{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:
\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?
This last point is particularly important. Many GPL enforcements are
This last point is particularly important. Many GPL enforcement actions 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.
In particular, any time your vendor incorporates copylefted software, you
\textit{must} exercise your own rights as a user to request CCS for all the
copylefted programs that your suppliers provided to you. Furthermore, you
must ensure that CCS is correct and adequate yourself. Good vendors should
help you do this, and make it easy. If those vendors cannot, pick a
different vendor before proceeding with the product.
\section{Mergers and Acquisitions}
Often, larger companies often encounter copyleft licensing during a Mergers
and Acquisitions (M\&A) process. Ultimately, a merger or acquisition causes
all of the other company's problems to become yours. Therefore, for most
concerns, the acquirer ``simply'' must apply the compliance analysis and
methodologies discussed earlier across the acquired company's entire product
line. Of course, this is not so simple, as such effort may be substantial,
but a well-defined process for compliance investigation means the required
work, while voluminous, is likely rote.
A few sections of GPL require careful attention and legal analysis to
determine the risk of acquisitions. Those handling M\&A issues should pay
particular attention to the requirements of GPLv2~\S7 and GPLv3~\S10--12 ---
focusing on how they relate to the acquired assets may be of particular
importance.
For example, GPLv3\S10 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. However, despite this aid given by explicit
language in GPLv3, acquirers must still confirm compliance by the acquired
(even if GPLv3\S10 does assert the the acquirers rights under GPL, that does
not help if the acquired is out of compliance altogether). Furthermore, for
fear of later reprisal by the acquirer if a GPL violation is later discovered