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

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

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

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 invoking these requirements) are already well aware of their

  reality, this issue is not relevant to the vast majority of companies

  distributing GPL'd software.  Those interested in this issue should study

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

However, experienced  GPL enforcers find that few redistributors'

compliance challenges relate directly to the copyleft provisions; this is

particularly true for most embedders.  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,

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

Admittedly, a tiny

do involve close questions about derivative and combined works.  Those

situations admittedly do require a highly

fact-dependent analysis and cannot be addressed in a general-purpose

document, anyway.

\medskip

Most companies accused of violations lack a basic understanding

of how to comply even in the former 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

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

Simple, engineering-oriented rules help provide a stable foundation for

Free Software integration.  For example, simply 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.  Further, make sure developers use a revision control

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, separately, any local changes.

Such procedures are best instituted at your project's launch.  Once 

chaotic and poorly-sourced development processes begin, cataloging the

presence of GPL'd components  becomes challenging.

Such a situation often requires use of a tool to ``catch up'' your knowledge

about what software your product includes.  Most commonly, companies choose

some software licensing scanning tool to inspect the codebase.  However,

there are few tools that are themselves Free Software.  Thus, GPL enforcers

usually recommend the GPL'd

source code base and produces a list of Free Software licenses that may apply to

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 explained in further detail below, the most important component of GPL

compliance is the one most often ignored: proper inclusion of CCS in all

distributions  of GPL'd

software.  To comply with GPL's CCS requirements, the distributor

\textit{must} always know precisely what sources generated a given binary

distribution.

In an unfortunately large number of our enforcement cases, the violating

company's engineering team had difficulty reconstructing the CCS

for binaries distributed by the company.  Here are three simple rules to

follow to decrease the likelihood of this occurrence:

\begin{itemize}

\item Ensure that your

developers are using revision control systems properly.

\item Have developers mark or ``tag'' the full source tree corresponding to

\item Check that your developers store all parts of the software

development in the revision control system, including {\sc readme}s, build

scripts, engineers' notes, and documentation.

\end{itemize}

Your developers will benefit anyway from these rules.  Developers will be

happier in their jobs if their tools already track the precise version of

source that corresponds to any deployed binary.

\section{Avoid the ``Build Guru''}

Too many software projects rely on only one or a very few team members who

know how to build and assemble the final released product.  Such knowledge

centralization not only creates engineering redundancy issues, but also

thwarts GPL compliance.  Specifically, CCS does not just require source code,

but scripts and other material that explain how to control compilation and

installation of the executable and object code.

Thus, avoid relying on a ``build guru'', a single developer who is the only one

who knows how to produce your final product. Make sure the build process

is well defined.  Train every developer on the build process for the final

binary distribution, including (in the case of embedded software)

generating a final firmware image suitable for distribution to the

(``GPLv2-only'').  You cannot provide only Internet-based source request

fulfillment for the latter programs.

If you determine that all GPL'd works in your whole product allow upgrade

to GPLv3 (or were already GPLv3'd to start), your offer for source may be

as simple as this:

\begin{quote}

The software included in this product contains copyrighted software that

is licensed under the GPLv3\@.  A copy of that license is included in this

document on page $X$\@.  You may obtain the complete Corresponding Source

code from us for a period of three years after our last shipment of this

product and/or spare parts therefor, which will be no earlier than

2011-08-01, on our website at

\verb0http://www.example.com/sources/productnum/0.

\end{quote}

\medskip

Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of

the license itself, either electronically or in print, with every

distribution.

Finally, it is unacceptable to use option (b) merely because you do not have

because writing an offer is easy, but producing a source distribution as

an afterthought to a hasty development process is difficult.  The offer

for source does not exist as a stop-gap solution for companies rushing to

market with an out-of-compliance product.  If you ship an offer for source

with your product but cannot actually deliver \emph{immediately} on that

action.

\subsection{Option (c): Noncommercial Offers}

As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply

only to noncommercial use.  These options are not available to businesses

software packaged for them by an upstream vendor cannot merely pass along

the offer they received from the vendor; they must provide their own offer

or corresponding source to their distributees.  We talk in detail about

upstream software providers in \S~\ref{upstream}.

\subsection{Option 6(d) in GPLv3: Internet Distribution}

Under GPLv2, your formal provisioning options for Corresponding Source

ended with \S~3(c).  But even under GPLv2, pure Internet source

distribution was a common practice and generally considered to be

compliant.  GPLv2 mentions Internet-only distribution almost as aside in

the language, in text at the end of the section after the three

provisioning options are listed.  To quote that part of GPLv2~\S~3:

\begin{quote}

If distribution of executable or object code is made by offering access to

copy from a designated place, then offering equivalent access to copy the

source code from the same place counts as distribution of the source code,

even though third parties are not compelled to copy the source along with

the object code.

\end{quote}

When that was written in 1991, Internet distribution of software was the

exception, not the rule.  Some FTP sites existed, but generally software

was sent on magnetic tape or CDs.  GPLv2 therefore mostly assumed that

build guru to document his or her work!

\chapter{When The Letter Comes}

Unfortunately, many GPL violators ignore their obligations until they are

contacted by a copyright holder or the lawyer of a copyright holder.  You

should certainly contact your own lawyer if you have received a letter

alleging that you have infringed copyrights that were licensed to you

under the GPL\@.  This section outlines a typical enforcement case and

provides some guidelines for response.  These discussions are

generalizations and do not all apply to every alleged violation.

\section{Understanding Who's Enforcing}

\label{compliance-understanding-whos-enforcing}

% FIXME-LATER: this text needs work.

Both  FSF and Conservancy has, as part their mission,  to spread software

freedom. When FSF or Conservancy

enforces GPL, the goal is to bring the violator back into compliance as

quickly as possible, and redress the damage caused by the violation.

That is FSF's steadfast position in a violation negotiation --- comply

with the license and respect freedom.

However, other entities who do not share the full ethos of software freedom

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 that FSF nor Conservancy would ever

holders to proceed.

Generally, GPL enforcers come in two varieties.  First, there are

policy goals of GPL (software freedom), and see financial compensation as

ultimately secondary to those goals.  Second, there are ``for-profit

induce infringement merely to gain proprietary licensing revenue.

the copyrights in the infringed work.  As such, multi-copyright-held works

are fully insulated from these tactics.

\section{Communication Is Key}

GPL violations are typically only escalated when a company ignores the

copyright holder's initial communication or fails to work toward timely

compliance.  Accused violators should respond very promptly to the

initial request.  As the process continues, violators should follow up weekly with the

copyright holders to make sure everyone agrees on targets and deadlines

for resolving the situation.

Ensure that any staff who might receive communications regarding alleged

GPL violations understands how to channel the communication appropriately

within your organization.  Often, initial contact is addressed for general

correspondence (e.g., by mail to corporate headquarters or by e-mail to

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

\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:

\begin{itemize}

\item What are all the licenses that cover the software in this device?

\item From which upstream vendors, be they companies or individuals, did

\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?

\end{itemize}

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

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 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 software freedom 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:  makefiles violator's

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

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

Bortez.

This statement does not negate, limit or restrict any rights you already

have under the GNU General Public License version 2.

\end{quotation}

This quelled Bortez's concerns about other patent licensing they sought to

do outside of the GPL'd software, and satisfied FSF's concerns that Bortez

give proper permissions to exercise teachings of patents that were

exercised in their GPL'd software release.

Finally, a GPL Compliance Officer inside Bortez was appointed to take

responsibility for all matters of GPL compliance inside the company.

Darvik is responsible for informing FSF if the position is given to

someone else inside the company, and making sure that FSF has direct

contact with Darvik's Compliance Officer.

\section{Lessons}

This case introduces a number of concepts regarding GPL enforcement.

\begin{enumerate}

\item {\bf Enforcement should not begin until the evidence is confirmed.}

  times, violation reports are mistaken. Even with extensive efforts in

  GPL education, many users do not fully understand their rights and the

  obligations that companies have. By working through the investigation

  with reporters, the violation can be properly confirmed, and {\bf the

    user of the software can be educated about what to expect with GPL'd

    software}. When users and customers of GPL'd products know their

  rights, what to expect, and how to properly exercise their rights

  (particularly under \S 3(b)), it reduces the chances for user

  frustration and inappropriate community outcry about an alleged GPL

  violation.

\item {\bf GPL compliance requires friendly negotiation and cooperation.}

  Often, attorneys and managers are legitimately surprised to find out

  GPL'd software is included in their company's products. Engineers

  sometimes include GPL'd software without understanding the requirements.

  This does not excuse companies from their obligations under the license,

  but it does mean that care and patience are essential for reaching GPL

  compliance. We want companies to understand that participating and

  benefiting from a collaborative Free Software community is not a burden,

  so we strive to make the process of coming into compliance as smooth as

  possible.

\item {\bf Confirming compliance is a community effort.}  The whole point

  of making sure that software distributors respect the terms of the GPL is to

  cannot effectively replace them.

  Such an outcome is simply further evidence that the combined work in

  question is indeed a derivative work of the original GPL'd component.

  If the other components cannot stand on their own and be useful without

  the GPL'd portions, then one cannot effectively argue that the work as a

  whole is not a derivative of the GPL'd portions.

\item {\bf The whole product is not always covered.}  In this case,

  Vigorien had additional works aggregated. The backup system was a suite

  of utilities, some of which were the GPL and some of which were not. While

  the cryptographic routines were tightly coupled with GNU tar and clearly

  derivative works, the various GUI utilities were separate and

  independent works merely aggregated with the distribution of the

  GNU-tar-based product.

\item {\bf ``Security'' concerns do not exonerate a distributor from GPL

  obligations, and ``security through obscurity'' does not work anyway.}

  The argument that ``this is security software, so it cannot be released

  in source form'' is not a valid defense for explaining why the terms of

  the GPL are ignored. If companies do not want to release source code

  for some reason, then they should not base the work on GPL'd software.

  No external argument for noncompliance can hold weight if the work as

  The ``security concerns'' argument is often floated as a reason to keep

  software proprietary, but the computer security community has on

  numerous occasions confirmed that such arguments are entirely specious.

  Security experts have found --- since the beginnings of the field of

  cryptography in the ancient world --- that sharing results about systems

  and having such systems withstand peer review and scrutiny builds the

  most secure systems. While full disclosure may help some who wish to

  compromise security, it helps those who want to fix problems even more

  by identifying them early.

\item {\bf External regulatory problems can be difficult to resolve.}

  The GPL, though grounded in copyright law, does not have the power to trump

  regulations like export controls. While Vigorien's ``security

  concerns'' were specious, their export control concerns were not. It is

  indeed a difficult problem that FSF acknowledges. We want compliance

  with the GPL and respect for users' freedoms, but we certainly do not expect

  companies to commit criminal offenses for the sake of compliance. We

  will see more about this issue in our next case study.

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Haxil, Polgara, and Thesulac: Mergers, Upstream Providers and Radio Devices}