@@ -83,102 +83,105 @@ are resolved privately via
cooperative communications with violators. As both FSF and Conservancy has 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 mistakes that can be,
for the most part, easily avoided. 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.
\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 appear initially
counter-intuitive to those more familiar with proprietary software
licenses, by comparison, its terms are in fact clear and quite favorable to
licensees. Indeed, the GPL's terms actually simplify compliance when
violations occur.
GPL violations occur (or, are compounded) most often when companies lack sound
practices for the incorporation of GPL'd components into their
internal development environment. This section introduces some best
practices for software tool selection, integration and distribution,
inspired by and congruent with software freedom methodologies. Companies should
establish such practices before building a product based on GPL'd
software.\footnote{This document addresses compliance with GPLv2,
GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common
errors differs little for compliance with these four licenses.
\S~\ref{lgpl} discusses the key differences between GPL and LGPL
compliance.}
\section{Evaluate License Applicability}
\label{derivative-works}
Political discussion about the GPL often centers around the ``copyleft''
requirements of the license. Indeed, the license was designed primarily
to embody this licensing feature. Most companies adding non-trivial
features (beyond mere porting and bug-fixing) to GPL'd software, and
thereby implicating these requirements, are already well aware of their
more complex obligations under the license.\footnote{There has been much legal
features (beyond mere porting and bug-fixing) to GPL'd software (and
thereby invoking these requirements) are already well aware of their
more complex obligations under the license.\footnote{While, there has been much legal
discussion regarding copyleft and derivative works. In practical
reality, this issue is not relevant to the vast majority of companies
distributing GPL'd software.}
distributing GPL'd software. Those interested in this issue should study
\tutorialpartsplit{\texit{Detailed Analysis of the GNU GPL and Related
Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
this tutorial}.}
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 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
provides that fundamental and generally applicable prerequisite knowledge.
For answers to rarer and more complicated legal questions, such as whether
your software is a derivative 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}.}
For this discussion, we will assume 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. In
such a case, the GPL requires you to provide complete and corresponding
source 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 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.