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