% 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}

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

\vfill

CC-By-SA-licensed published works: \\

\begin{itemize}

\item \hrefnofollow{http://www.softwarefreedom.org/resources/2008/compliance-guide.html}{\textit{The Practical Guide GPL Compliance}}, by Bradley M. Kuhn, Aaron

Williamson and Karen Sandler, first published on 2008-08-20. \\

\item \hrefnofollow{http://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html}{\textit{Software Freedom Law Center Guide to GPL Compliance, 2nd

  Edition}} by Eben Moglen and Mishi Choudhary, first published on 2014-10-31. \\

\end{itemize}

However, this work is primarily composed of the many contributions it

receives as a public, collaborative project.  Please

\href{https://gitorious.org/copyleft-org/tutorial/history/master:compliance-guide.tex}{review

  its Git logs} for full documentation of all contributions.

\end{center}

}

\pagebreak

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

%      Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course

% License: CC-By-SA-4.0

% The copyright holders 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.

% This text is distributed in the hope that it will be useful, but

% WITHOUT ANY WARRANTY; without even the implied warranty of

% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% You should have received a copy of the license with this document in

% a file called 'CC-By-SA-4.0.txt'.  If not, please visit

% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive

% the license text.

\part{Case Studies in GPL Enforcement}

{\parindent 0in

This part is: \\

\begin{tabbing}

Copyright \= \copyright{} 2003, 2004, 2014 \hspace{1mm} \= \hspace{1.mm} \=  \kill

Copyright \> \copyright{} 2014 \>  Bradley M. Kuhn. \\

Copyright \> \copyright{} 2014 \>  Denver Gingerich \\

Copyright \> \copyright{} 2003, 2004, 2014 \> Free Software Foundation, Inc. \\

\end{tabbing}

\vspace{.2in}

\begin{center}

The copyright holders 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}

\vfill

CC-By-SA-licensed published works: \\

\begin{itemize}

\item \textit{Enforcement Case Studies}, written by Bradley M. Kuhn and published by the Free

  Software Foundation for its CLE courses  on 2004-01-20, 2004-08-24, and 2014-03-24.

\end{itemize}

However, this work is primarily composed of the many contributions it

receives as a public, collaborative project.  Please

\href{https://gitorious.org/copyleft-org/tutorial/history/master:enforcement-case-studies.tex}{review

  its Git logs} for full documentation of all contributions.

}

% =====================================================================

% START OF SECOND DAY SEMINAR SECTION

% =====================================================================

\chapter*{Preface}

This one-day course presents the details of five different GPL

compliance cases handled by FSF's GPL Compliance Laboratory. Each case

offers unique insights into problems that can arise when the terms of

the GPL are not properly followed, and how diplomatic negotiation between

the violator and the copyright holder can yield positive results for

both parties.

Attendees should have successfully completely the course, a ``Detailed

Study and Analysis of the GPL and LGPL,'' as the material from that

course forms the building blocks for this material.

This course is of most interest to lawyers who have clients or

employers that deal with Free Software on a regular basis. However,

technical managers and executives whose businesses use or distribute

Free Software will also find the course very helpful.

\bigskip

These course materials are merely a summary of the highlights of the

course presented. Please be aware that during the actual GPL course, class

discussion supplements this printed curriculum. Simply reading it is

not equivalent to attending the course.

%FIXME-LATER: write these

%\chapter{Not All GPL Enforcement is Created Equal}

%\section{For-Profit Enforcement}

%\section{Community and Non-Profit Enforcement}

\chapter{Overview of Community Enforcement}

The GPL is a Free Software license with legal teeth. Unlike licenses like

the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is

designed to defend as well as grant freedom. We saw in the last course

that the GPL uses copyright law as a mechanism to grant all the key freedoms

essential in Free Software, but also to ensure that those freedoms

propagate throughout the distribution chain of the software.

\section{Termination Begins Enforcement}

As we have learned, the assurance that Free Software under the GPL remains

Free Software is accomplished through various terms of the GPL: \S 3 ensures

that binaries are always accompanied with source; \S 2 ensures that the

sources are adequate, complete and usable; \S 6 and \S 7 ensure that the

license of the software is always the GPL for everyone, and that no other

legal agreements or licenses trump the GPL. It is \S 4, however, that ensures

that the GPL can be enforced.

Thus, \S 4 is where we begin our discussion of GPL enforcement. This

clause is where the legal teeth of the license are rooted. As a copyright

license, the GPL governs only the activities governed by copyright law ---

copying, modifying and redistributing computer software. Unlike most

copyright licenses, the GPL gives wide grants of permission for engaging with

these activities. Such permissions continue, and all parties may exercise

them until such time as one party violates the terms of the GPL\@. At the

moment of such a violation (i.e., the engaging of copying, modifying or

redistributing in ways not permitted by the GPL) \S 4 is invoked. While other

parties may continue to operate under the GPL, the violating party loses their

rights.

Specifically, \S 4 terminates the violators' rights to continue

engaging in the permissions that are otherwise granted by the GPL\@.

Effectively, their rights revert to the copyright defaults ---

no permission is granted to copy, modify, nor redistribute the work.

Meanwhile, \S 5 points out that if the violator has no rights under

the GPL, they are prohibited by copyright law from engaging in the

activities of copying, modifying and distributing. They have lost

these rights because they have violated the GPL, and no other license

gives them permission to engage in these activities governed by copyright law.

\section{Ongoing Violations}

In conjunction with \S 4's termination of violators' rights, there is

one final industry fact added to the mix: rarely does one engage in a

single, solitary act of copying, distributing or modifying software.

Almost always, a violator will have legitimately acquired a copy of a

GPL'd program, either making modifications or not, and then begun

distributing that work. For example, the violator may have put the

software in boxes and sold them at stores. Or perhaps the software

was put up for download on the Internet. Regardless of the delivery

mechanism, violators almost always are engaged in {\em ongoing\/}

violation of the GPL\@.

In fact, when we discover a GPL violation that occurred only once --- for

example, a user group who distributed copies of a GNU/Linux system without

source at one meeting --- we rarely pursue it with a high degree of

tenacity. In our minds, such a violation is an educational problem, and

unless the user group becomes a repeat offender (as it turns out, they

never do), we simply forward along a FAQ entry that best explains how user

groups can most easily comply with the GPL, and send them on their merry way.

It is only the cases of {\em ongoing\/} GPL violation that warrant our

active attention. We vehemently pursue those cases where dozens, hundreds

or thousands of customers are receiving software that is out of

compliance, and where the company continually offers for sale (or

distributes gratis as a demo) software distributions that include GPL'd

components out of compliance. Our goal is to maximize the impact of

enforcement and educate industries who are making such a mistake on a

large scale.

In addition, such ongoing violation shows that a particular company is

committed to a GPL'd product line. We are thrilled to learn that someone

is benefiting from Free Software, and we understand that sometimes they

become confused about the rules of the road. Rather than merely

giving us a postmortem to perform on a past mistake, an ongoing violation

gives us an active opportunity to educate a new contributor to the GPL'd

commons about proper procedures to contribute to the community.

Our central goal is not, in fact, to merely clear up a particular violation.

In fact, over time, we hope that our compliance lab will be out of

business. We seek to educate the businesses that engage in commerce

related to GPL'd software to obey the rules of the road and allow them to

operate freely under them. Just as a traffic officer would not revel in

reminding people which side of the road to drive on, so we do not revel in

violations. By contrast, we revel in the successes of educating an

ongoing violator about the GPL so that GPL compliance becomes a second-nature

matter, allowing that company to join the GPL ecosystem as a contributor.

\section{How are Violations Discovered?}

Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL

Compliance Lab runs at a loss (in other words, it is subsided by our

donors). Our violation reports come from volunteers, who have encountered,

in their business or personal life, a device or software product that

appears to contain GPL'd software. These reports are almost always sent

via email to $<$license-violation@fsf.org$>$.

Our first order of business, upon receiving such a report, is to seek

independent confirmation. When possible, we get a copy of the software

product. For example, if it is an offering that is downloadable from a

Web site, we download it and investigate ourselves. When it is not

possible for us to actually get a copy of the software, we ask the

reporter to go through the same process we would use in examining the

software.

By rough estimation, about 95\% of violations at this stage can be

confirmed by simple commands. Almost all violators have merely made an

error and have no nefarious intentions. They have made no attempt to

remove our copyright notices from the software. Thus, given the

third-party binary, {\tt tpb}, usually, a simple command (on a GNU/Linux

system) such as the following will find a Free Software copyright notice

and GPL reference:

\begin{quotation}

{\tt strings tpb | grep Copyright}

\end{quotation}

In other words, it is usually more than trivial to confirm that GPL'd

software is included.

Once we have confirmed that a violation has indeed occurred, we must then

determine whose copyright has been violated. Contrary to popular belief,

FSF does not have the power to enforce the GPL in all cases. Since the GPL

operates under copyright law, the powers of enforcement --- to seek

redress once \S 4 has been invoked --- lie with the copyright holder of

the software. FSF is one of the largest copyright holders in the world of

GPL'd software, but we are by no means the only one. Thus, we sometimes

discover that while GPL'd code is present in the software, there is no

software copyrighted by FSF present.

In cases where FSF does not hold copyright interest in the software, but

we have confirmed a violation, we contact the copyright holders of the

software, and encourage them to enforce the GPL\@. We offer our good offices

to help negotiate compliance on their behalf, and many times, we help as a

third party to settle such GPL violations. However, what we will describe

primarily in this course is FSF's first-hand experience enforcing its own

copyrights and the GPL\@.

\section{First Contact}

The Free Software community is built on a structure of voluntary

cooperation and mutual help. Our community has learned that cooperation

works best when you assume the best of others, and only change policy,

procedures and attitudes when some specific event or occurrence indicates

that a change is necessary. We treat the process of GPL enforcement in

the same way. Our goal is to encourage violators to join the cooperative

community of software sharing, so we want to open our hand in friendship.

Therefore, once we have confirmed a violation, our first assumption is

that the violation is an oversight or otherwise a mistake due to confusion

about the terms of the license. We reach out to the violator and ask them

to work with us in a collaborative way to bring the product into

compliance. We have received the gamut of possible reactions to such

requests, and in this course, we examine four specific examples of such

compliance work.

% FIXME: make this section properly TeX-formatted

\chapter{ThinkPenguin Wireless Router: Excellent CCS}

\label{pristine-example}

Too often, case studies examine failure and mistakes.  Indeed, most of the

chapters that follow herein will consider the myriad difficulties discovered

in community-oriented GPL enforcement for the last two decades.  However, to

begin, this is a case study in how copyleft compliance can indeed be done correctly.

This example is, in fact, more than ten years in the making.  Since almost

the inception of for-profit corporate adoption of Free Software, companies

have requested a clear example of a model citizen to emulate.  Sadly, while

community-oriented enforcers have vetted uncounted thousands of ``Complete,

Corresponding Source'' (CCS) candidates from hundreds of companies, this

particular CCS release described herein is the first ever declared a ``pristine

example''.

% FIXME (above): link to a further discussion of CCS in the compliance guide

% when a good spot exists, then (below) link to a ``CCS iteration''

% discussion in compliance-guide.tex when one exists.  (the ``iteration

% process'' is discussed in~\ref{} of this guide)

Of course, most CCS examined for the last decade has (eventually) complied

with the GPL, perhaps after many iterations of review by the enforcer.

However, in the experience of the two primary community-oriented enforcers

(Conservancy and the FSF), such CCS results routinely 

``barely comply with GPL's requirements''.  To use an academic analogy:

while a ``C'' is certainly a passing grade, any instructor prefers to

disseminate to the class an exemplar sample that earned an ``A''.

Fortunately, thanks in large part to the FSF's

``Respects Your Freedom'' (RYF) certification campaign\footnote{\href{http://www.fsf.org/resources/hw/endorsement/respects-your-freedom}{RYF is

    a campaign by FSF to certify products that truly meet the principles of

    software freedom}.  Products must meet

  \href{http://www.fsf.org/resources/hw/endorsement/criteria}{strict

    standards for RYF certification}, and among them is a pristine example of

  CCS\@.}, a few electronics products on the market meet

a higher standard of copyleft compliance.  As such, for the first

time in the history of copyleft, CCS experts have pristine examples to study

and present as exemplars worthy of emulation.

This case study therefore examines the entire life-cycle of a GPL compliance

investigation: from product purchase, to source request, to CCS review, and concluding

in a final compliance determination.

Specifically, this chapter discusses the purchase, CCS provision, and a

step-by-step build and installation analysis of a specific, physical,

embedded electronics product:

\href{https://www.thinkpenguin.com/gnu-linux/free-software-wireless-n-broadband-router-gnu-linux-tpe-nwifirouter}{the

  ``TPE-NWIFIROUTER'' wireless router by ThinkPenguin}.\footnote{The FSF of

  course performed a thorough CCS check as part of its certification process.

  The analysis discussed herein was independently performed by Software

  Freedom Conservancy without reviewing the FSF's findings.  Thus, this

  analysis is ``true to form'', and explains the typical procedures Conservancy

  uses when investigating a potential GPL violation.  In this case, obviously, no

  violation was uncovered.}

\section{Consumer Purchase and Unboxing}

The process for copyleft compliance investigation, when properly conducted,

determines whether users inclined to exercise their rights under a copyleft

license will be successful in their attempt.  Therefore, at every stage, the

investigator seeks to take actions that reasonably technically knowledgeable

users would during the ordinary course of their acquisition and use of

copyleft-covered products.  As such, the investigator typically purchases the device on the

open market to verify that distribution of the copylefted software therein

complies with binary distribution requirements (such as those

\tutorialpartsplit{discussed in \textit{Detailed Analysis of the GNU GPL and

    Related Licenses}}{discussed earlier in \S~\ref{GPLv2s3} and

  \S~\ref{GPLv3s6}}).

% FIXME: Above is my only use of \tutorialpartsplit in this chapter.  I just

% got lazy and that should be fixed by someone.

\label{thinkpenguin-included-ccs}

Therefore, the investigator first purchased the TPE-NWIFIROUTER through an

online order, and when the package arrived, examined the contents of the box.

The investigator immediately discovered that ThinkPenguin had taken advice

from \S~\ref{offer-for-source}, and exercised

\hyperref[GPLv2s3a]{GPLv2\S3(a)} and \hyperref[GPLv3s6]{GPLv3\S6}, rather than

using the \hyperref[offer-for-source]{problematic offer for source

  provisions}.  This choice not only accelerated the investigation (since there

was no CCS offer to ``test''), but also simplified the compliance requirements for

ThinkPenguin.

\section{Root Filesystem and Kernel Compilation}

The CD found in the box was labeled ``libreCMC v1.2.1 source code'', and

contained 407 megabytes of data.  The investigator copied this ISO to a

desktop GNU/Linux system and

examined its contents.  Upon doing so, the investigator immediately found a

file called ``README'' at the top-level directory:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

$ dd if=/dev/cdrom of=libreCMC_v1.2.1_SRC.iso

$ mkdir libCMC

$ sudo mount -o loop ./libreCMC_v1.2.1_SRC.iso libCMC

mount: block device /path/to/libreCMC_v1.2.1_SRC.iso

       is write-protected, mounting read-only

$ ls -1 libCMC

bin

librecmc-u-boot.tar.bz2

librecmc-v1.2.1.tar.bz2

README

u-boot_reflash

$ cat libCMC/README

...

\end{lstlisting}

\label{thinkpenguin-toplevel-readme}

The investigator therefore knew immediately to begin the CCS check should

begin with a study of the contents of ``README''.  Indeed, that file contained the appropriate

details to start the build:

\begin{quotation}

In order to build firmware images for your router, the following needs to be

installed:

gcc, binutils, bzip2, flex, python, perl, make, find, grep, diff, unzip,

gawk, getopt, libz-dev and libc headers.

Please use ``make menuconfig'' to configure your appreciated configuration

for the toolchain and firmware. Please note that the default configuration is

what was used to build the firmware image for your router. It is advised that

you use this configuration.

Simply running ``make'' will build your firmware.  The build system will

download all sources, build the cross-compile toolchain, the kernel and all

chosen applications.

To build your own firmware you need to have access to a GNU/Linux system

(case-sensitive filesystem required).

\end{quotation}

In other words, the first ``script'' that investigator ``ran'' was the above.

This was not a software script, rather the processor for the script was the investigator's own

brain --- like a script of a play.  Less glibly stated: instructions written in

English are usually necessary for the build and installation operations

that demand actual intelligence.

In this case, the investigator ascertained the host system requirements

for construction of this embedded firmware.

GPL does not give specific guidance on the form or location of

``scripts used to control compilation and installation of the executable''

and/or ``Installation Information''.  Community-oriented GPL enforcers apply a

``reasonableness standard'' to evaluate such instructions.  If an investigator of

average skill in embedded firmware construction can surmise the proper

procedures to build and install a replacement firmware, the instructions are

likely sufficient to meet GPL's requirements.  Fortunately, in this case, the

instructions are more abundant and give extra detail.

Nevertheless, these instructions offer more options than the reader

typically sees in other CCS candidates.  More typically, top-level build

instructions name an exact host distribution to use, such as

``Debian 7 installed on an amd64 system with the following packages

installed''.  Of course, if the build will fail on any other system,

instructions \textit{should} include such details.  However, this CCS builds

on a wide range of distributions, and thus it was appropriate (and preferred)

that the build instructions do not  specify a specific distribution.

\label{thinkpenguin-specific-host-system}

In this specific case, the developers of the libreCMC project (a Free

Software project that forms the base system for the TPE-NWIFIROUTER) have

clearly made an effort to ensure the CCS builds on a variety of host systems.

The investigator was in fact dubious upon seeing these instructions, since

finicky embedded build processes usually require a very specific host system.

Fortunately, it seems such doubts were generally unfounded (although the

investigator did find

\hyperref[thinkpenguin-glibc-214-issue]{a minor annoyance that could be

  resolved with more detailed instructions}).

Anyway, since these instructions did not specify a specific host system, the

investigator simply used his own amd64 Debian GNU/Linux 6 desktop system.  Before

beginning, the investigator used the following command:

\lstset{tabsize=2}

\begin{lstlisting}[language=bash]

% gpl-lgpl.tex                                                  -*- LaTeX -*-

%      Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course

%

% License: CC-By-SA-4.0

% The copyright holders 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.

% This text is distributed in the hope that it will be useful, but

% WITHOUT ANY WARRANTY; without even the implied warranty of

% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% You should have received a copy of the license with this document in

% a file called 'CC-By-SA-4.0.txt'.  If not, please visit

% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive

% the license text.

% FIXME-LATER: I should make a macro like the Texinfo @xref stuff for places

%      where I'm saying ``see section X in this tutorial'', so that the extra

%      verbiage isn't there in the HTML versions that I'll eventually do.

%      Maybe something like that already exists?  In the worst case, I could

%      adapt @xref from texinfo.texi for it.

\newcommand{\defn}[1]{\emph{#1}}

\part{Detailed Analysis of the GNU GPL and Related Licenses}

\label{gpl-lgpl-part}

{\parindent 0in

\tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\