professionals from whose work your company has benefited.  Indeed, you are

unlikely to find a better value or more generous license terms for similar

software elsewhere.  Treat the copyright holders with the same respect you

treat your corporate partners and collaborators.

\chapter{Special Topics in Compliance}

There are several other issues that are less common, but also relevant in

a GPL compliance situation.  To those who face them, they tend to be of

particular interest.

\section{LGPL Compliance}

\label{lgpl}

GPL compliance and LGPL compliance mostly involve the same issues.  As we

discussed in \S~\ref{derivative-works}, questions of modified versions of

software are highly fact-dependent and cannot be easily addressed in any

overview document.  The LGPL adds some additional complexity to the

analysis.  Namely, the various LGPL versions permit proprietary licensing

of certain types of modified versions.  These issues are discussed in greater

detail in Chapter~\ref{LGPLv2} and~\ref{LGPLv3}.  However, as a rule of thumb, once you have determined

(in accordance with LGPLv3) what part of the work is the ``Application''

and what portions of the source are ``Minimal Corresponding Source'', then

you can usually proceed to follow the GPL compliance rules that

discussed above, replacing our discussion of ``Corresponding Source'' with

``Minimal Corresponding Source''.

LGPL also requires that you provide a mechanism to combine the Application

with a modified version of the library, and outlines some options for

this.  Also, the license of the whole work must permit ``reverse

engineering for debugging such modifications'' to the library.  Therefore,

you should take care that the EULA used for the Application does not

contradict this permission.

Thus, under the terms of LGPL, you must refrain from license terms on works

based on the licensed work that prohibit replacement of the licensed

components of the larger non-LGPL'd work, or prohibit decompilation or

reverse engineering in order to enhance or fix bugs in the LGPL'd components.

LGPLv3 is not surprisingly easier to understand and examine from a compliance

lens, since the FSF was influenced in LGPLv3's drafting by questions and

comments on LGPLv2.1 over a period of years.  Admittedly, LGPLv2.1 is still

in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you

may encounter.  The best advice there is careful study of

Chapter~\ref{LGPLv2}.

However, to repeat a key point here made within that chapter: Note though

that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the

worst case you simply need to comply as if the software was licensed under

GPLv2.  The only reason you must consider the question of whether you have a

``work that uses the library'' or a ``work based on the library'' is when you

wish to take advantage of the ``weak copyleft'' effect of the Lesser GPL\@.

If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the

entire work anyway), you may find this an easier option.

\section{Upstream Providers}

\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

  \emph{you} receive your software before distributing it to us?

\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 enforcement actions 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

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.

In particular, any time your vendor incorporates copylefted software, you

\textit{must} exercise your own rights as a user to request CCS for all the

copylefted programs that your suppliers provided to you.  Furthermore, you

must ensure that CCS is correct and adequate yourself.  Good vendors should

help you do this, and make it easy.  If those vendors cannot, pick a

different vendor before proceeding with the product. 

\section{Mergers and Acquisitions}

Often, larger companies often encounter copyleft licensing during a Mergers

and Acquisitions (M\&A) process.  Ultimately, a merger or acquisition causes

all of the other company's problems to become yours.  Therefore, for most

concerns, the acquirer ``simply'' must apply the compliance analysis and

methodologies discussed earlier across the acquired company's entire product

line.  Of course, this is not so simple, as such effort may be substantial,

but a well-defined process for compliance investigation means the required

work, while voluminous, is likely rote.

A few sections of GPL require careful attention and legal analysis to

determine the risk of acquisitions.  Those handling M\&A issues should pay

particular attention to the requirements of GPLv2~\S7 and GPLv3~\S10--12 ---

focusing on how they relate to the acquired assets may be of particular

importance.

For example, GPLv3\S10 clarifies that in business acquisitions, whether by

sale of assets or transfers of control, the acquiring party is downstream

from the party acquired.  This results in new automatic downstream licenses

from upstream copyright holders, licenses to all modifications made by the

acquired business, and rights to source code provisioning for the

now-downstream purchaser.  However, despite this aid given by explicit

language in GPLv3, acquirers must still confirm compliance by the acquired

(even if GPLv3\S10 does assert the the acquirers rights under GPL, that does

not help if the acquired is out of compliance altogether).  Furthermore, for

fear of later reprisal by the acquirer if a GPL violation is later discovered

in the acquired's product line, the acquired may need to seek a waiver and

release of from additional damages beyond a requirement to comply fully (and

a promise of rights restoration) if a GPL violation by the acquired is later

uncovered during completion of the acquisition or thereafter.

Finally, other advice available regarding handling of GPL compliance in an

M\&A situation tends to ignore the most important issue: most essential

copylefted software is not wholly copyrighted by the entities involved in the

M\&A transaction.  Therefore, copyleft obligations likely reach out to the

customers of all entities involved, as well as to the original copyright

holders of the copylefted work.  As such, notwithstanding the two paragraphs

in GPLv3\S10, the entities involved in M\&A should read the copyleft licenses

through the lens of third parties whose software freedom rights under those

licenses are of equal importance to then entities inside the transaction.

\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

as it appears in the final license is reasonable and easy to understand.

If you put GPLv3'd software into a User Product (as defined by the

license) and \emph{you} have the ability to install modified versions onto

that device, you must provide information that makes it possible for the

user to install functioning, modified versions of the software.  Note that

if no one, including you, can install a modified version, this provision

does not apply.  For example, if the software is burned onto an

non-field-upgradable ROM chip, and the only way that chip can be upgraded

is by producing a new one via a hardware factory process, then it is

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

% FIXME-soon: write a full section on Javascript compliance.  Here's a

%             potentially useful one-sentence introduction for such a

%             section.

% Non-compliance with GPLv3 in the

% distribution of Javascript on the Web is becoming more frequent

%FIXME-soon: END

\section{Beware The Consultant in Enforcers' Clothing}

There are admittedly portions of the GPL enforcement community that function

somewhat like the

\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Classifications}{computer

  security and network penetration testing hacker community}.  By analogy,

most COGEO's consider themselves

\href{http://en.wikipedia.org/wiki/White_hat_%28computer_security%29}{white hats},

while some might appropriately call

\hyperref[Proprietary Relicensing]{proprietary relicensing} by the name ``\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Black_hat}{black hats}''.

And, to finalize the analogy, there are indeed few

\href{http://en.wikipedia.org/wiki/Grey_hat}{grey hat} GPL enforcers.

Grey hat GPL enforcers usually have done some community-oriented GPL

enforcement themselves, typically working as a volunteer for a COGEO, but make

their living as a ``hired gun'' consultant to find GPL violations and offer

to ``fix them'' for companies.  Other such operators hold copyrights in some

key piece of copylefted software and enforce as a mechanism to find out who

is most likely to fund improvements on the software.

A few companies report that they have formed beneficial consulting or

employment relationships with developers they first encountered through

enforcement.  In some such cases, companies have worked with such consultants

to alter the mode of use of the project's code in the company's products.

More often in these cases, the communication channels opened in the course of

the inquiry served other consulting purposes later.

Feelings and opinions about this behavior are mixed within the larger

copyleft community.  Some see it as a reasonable business model and others

renounce it as corrupt behavior.  Regardless, a GPL

violator should always immediately determine the motivations of the

enforcer via documented, verifiable facts.  For example, COGEOs such as the FSF and Conservancy have made substantial

public commitments to enforce in a way that is uniform, transparent, and

publicly documented.  Furthermore, since these specific organizations are

public charities in the USA, they

are accountable to the IRS (and the public at large) in their annual Form 990

filings.   Everyone may examine their revenue models and scrutinize their

work.

However, entities and individuals who do GPL enforcement centered primarily

around a profit motive are likely the most dangerous enforcement entities for

one simple reason: an agreement to comply fully with the GPL for past and

future products --- always the paramount goal to COGEOs --- may not suffice as

adequate resolution for a proprietary relicensing company or grey hat GPL

enforcer.  Therefore, violators must consider carefully who has

made the enforcement inquiry and ask when and where the enforcer made public

commitments and reports regarding their enforcement work and perhaps even ask

the enforcer to directly mimic CEOGEO's detailed public disclosures and

  resolution} found in this document.

\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 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:  roadmap README upstream's Ravicher's FOSSology readme CDs iPhone

% LocalWords:  makefiles violator's Michlmayr Stallman RMS GPL'd Harald LGPL

%%  LocalWords:  GPL's resellers copylefted sublicenses GPLv unmanaged MySQL

%%  LocalWords:  misassessments licensor COGEOs COGEO LGPLv CCS Requestors

%%  LocalWords:  codebase Yocto distributees COGEO's Coreboot ERP reseller

%%  LocalWords:  redistributor reinstatements decompilation acquired's grey

%%  LocalWords:  upgradable unmodifiable Relicensing relicensing