@@ -44,25 +44,25 @@ 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}
Early GPL enforcement efforts began soon after the GPL was written by
Richard Stallman 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.} 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 community of
Free/Libre and Open Source Software (FOSS) developers. FSF's enforcement
Free/Libre and Open Source Software (free software) developers. 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 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
@@ -72,54 +72,54 @@ reports, Welte successfully pursued many enforcements in Europe, including
formal legal action.
In 2007, the SFLC filed the first U.S.~copyright infringement lawsuit
based on a violation of the GPL\@. While the lawsuits filed by SFLC on
behalf of its clients have been quite public, SFLC resolves the vast
majority of enforcement actions privately via
cooperative communications with violators. As we have worked to bring
individual companies into compliance, we 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. In this document, we highlight these problems and describe
best practices to encourage corporate users of FOSS to reevaluate their
best practices to encourage corporate users of free software to reevaluate their
approach to GPL'd software and avoid future violations.
SFLC continues to conduct GPL enforcement and compliance efforts for many
of its clients who release their software under the GPL, the GNU Lesser
Public License (LGPL) and other copyleft licenses. In doing so, we have
found that most violations stem from a few common mistakes that can be,
for the most part, easily avoided. We 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.
\chapter{Best Practices to Avoid Common Violations}
\label{best-practices}
Unlike highly permissive FOSS licenses (such as the ISC license), which
Unlike highly permissive free software licenses (such as the ISC license), which
typically only require preservation of copyright notices, the GPL places a
number of important requirements upon licensees. These requirements are
carefully designed to uphold certain values and standards of the software
freedom community. While the GPL's requirements may appear initially
counter-intuitive to those more familiar with proprietary software
licenses, by comparison its terms are in fact clear and favorable to
licensees. The terms of the GPL actually simplify compliance when
violations occur.
GPL violations are often caused or compounded by a failure to adopt sound
practices for the incorporation of GPL'd components into a company's
internal development environment. In this section, we introduce some best
practices for software tool selection, integration and distribution,
inspired by and congruent with FOSS methodologies. We suggest companies
inspired by and congruent with free software methodologies. We suggest companies
establish such practices before building a product based on GPL'd
software.\footnote{This document addresses compliance with GPLv2,
GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common
errors differs little for compliance with these four licenses.
\S~\ref{lgpl} discusses the key differences between GPL and LGPL
compliance.}
\section{Evaluate License Applicability}
\label{derivative-works}
Political discussion about the GPL often centers around the ``copyleft''
requirements of the license. Indeed, the license was designed primarily
to embody this licensing feature. Most companies adding non-trivial
@@ -130,25 +130,25 @@ more complex obligations under the license.\footnote{There has been much legal
reality, this issue is not relevant to the vast majority of companies
distributing GPL'd software.}
However, in our experience with GPL enforcement, few redistributors'
compliance challenges relate directly to the copyleft provisions; this is
doubly true for most embedders. Instead, the distributions of GPL'd
systems that we encounter 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,
resulting unequivocally in a derivative work. Alongside these programs,
companies often distribute fully independent, proprietary programs,
developed from scratch, which are designed to run on the FOSS operating
developed from scratch, which are designed to run on the free software operating
system but do not combine with, link to, modify, or otherwise derive from
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 derivative work has been created. The tiny
minority of situations which lie outside these two categories, and thus
involve close questions about derivative works, require a highly
fact-dependent analysis and cannot be addressed in a general-purpose
document.
Most companies accused of violations, however, lack a basic understanding
of how to comply even in the straightforward scenario. This document
@@ -174,45 +174,45 @@ this document address this typical scenario.
Software engineers should have the freedom to innovate and import useful
software components to improve your product. However, along with that
freedom should come rules and reporting procedures to make sure that you
are aware of what software is being tested or included with your product.
The companies we contact about GPL violations often respond with: ``We
didn't know there was GPL'd stuff in there''. This answer indicates a
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, your developers often obtain and
integrate FOSS without intervention. The ease of acquisition, however,
integrate free software without intervention. The 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 be involved in all decisions to bring FOSS into your
software, they should be involved in all decisions to bring free software into your
product.
Simple, engineering-oriented rules help provide a stable foundation for
FOSS integration. Ask your software developers to send an email to a
standard place describing each new FOSS component they add to the system,
free software integration. 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. Make sure they use a revision control system, and have
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 local changes made.
Such procedures are best instituted at your project's launch. Once a
chaotic and poorly-sourced development process has begun, the challenges
of determining and cataloging the presence of GPL'd components is
difficult. If you are in that situation, we recommend the
\href{http://fossology.org/}{Fossology system}, which analyzes a
source-code base and produces a list of FOSS licenses that may apply to
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 we will explain in further detail below, the most important component
to maintaining GPL compliance is inclusion of the complete and
corresponding source code in any distributions that you make of GPL'd
software. Knowing at all times what sources generated a given binary
distribution is paramount.
@@ -609,25 +609,25 @@ 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
FOSS sources). Consider what, in this case, constitutes adequate
free software 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
@@ -652,45 +652,45 @@ 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 FOSS compiler. If you have
when the compiler is based on GCC\@ or another free software 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 FOSS
version (binaries plus sources) to your customers. We in the free software
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 FOSS, proprietary, or
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
@@ -754,27 +754,27 @@ 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 FOSS community generally values open communication and
Remember that the free software community generally values open communication and
cooperation, and these values extend to GPL enforcement. You will
generally find that FOSS developers and their lawyers are willing to
generally find that free software 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.
\section{Termination}
Many redistributors overlook 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
@@ -831,42 +831,42 @@ more favorable to violators than v2.
\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 FOSS copyrights}. Copyright holders of FOSS
\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 FOSS in your distribution.
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 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 FOSS community
\item {\bf Appointment of a GPL Compliance Officer.} The free software community
values personal accountability when things go wrong. Copyright holders
often require that you name someone within the violating company
officially responsible for FOSS license compliance, and that this
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
@@ -943,25 +943,25 @@ should ask:
violation of the GPL?
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 FOSS allows software vendors to reduce costs significantly, but be
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.
\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
@@ -979,53 +979,53 @@ 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 FOSS community reads: ``I void warranties.''. Our community is
in the free software community reads: ``I void warranties.''. Our community is
well-known for modifying products with full knowledge of the
consequences. GPLv3's ``Installation Instructions'' section merely
confirms that reality, and makes sure GPL rights can be fully exercised,
even if users exercise those rights at their own peril.}
GPLv3 is in many ways better for distributors who seek some degree of
device lock-down. Technical processes are always found for subverting any
lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike
with GPLv2, the license gives you clear provisions that you can rely on
when you are forced to cut off support, service or warranty for a customer
who has chosen to modify.
\chapter{Conclusion}
GPL compliance need not be an onerous process. Historically, struggles
have been the result of poor development methodologies and communications,
rather than any unexpected application of the GPL's source code disclosure
requirements.
Compliance is straightforward when the entirety of your enterprise is
well-informed and well-coordinated. The receptionists should know how to
route a GPL source request or accusation of infringement. The lawyers
should know the basic provisions of FOSS licenses and your source
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 FOSS community, and lots of great code
of good citizenship in the free software 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