% compliance-guide.tex                            -*- LaTeX -*-

\part{A Practical Guide to GPL Compliance}

\label{gpl-compliance-guide}

{\parindent 0in

This part is: \\

\begin{tabbing}

Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn. \\

Copyright \> \copyright{} 2008 \> \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{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

\verb=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}

Early GPL enforcement 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 \verb0gpl-violations.org0, 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. 

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

best practices to encourage corporate Free Software users 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 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 software freedom 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

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

  discussion regarding copyleft and derivative works.  In practical

  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 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.