% 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}
Authors of this part are: \\
Bradley M. Kuhn \\
Aaron Williamson \\
Karen M. Sandler \\
Copy editors of this part include: \\
Martin Michlmayr
\vspace{3in}
The copyright holders of this part hereby grant the freedom to copy, modify,
convey, Adapt, and/or redistribute this work under the terms of the Creative
Commons Attribution Share Alike 4.0 International License. A copy of that
license is available at
\url{https://creativecommons.org/licenses/by-sa/4.0/legalcode}.
\end{center}
}
\bigskip
\chapter*{Executive Summary}
This is a guide to effective compliance with the GNU General Public
License (GPL) and related licenses. Copyleft advocates
usually seek to assist the community with
GPL compliance cooperatively. This guide focuses on complying from the
start, so that readers can learn to avoid enforcement actions entirely, or, at
least, minimize the negative impact when enforcement actions occur.
This guide introduces and explains basic legal concepts related to the GPL and its
enforcement by copyright holders. It also outlines business practices and
methods that lead to better GPL compliance. Finally, it recommends proper
post-violation responses to the concerns of copyright holders.
\chapter{Background}
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 enforcements in Europe, including
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 excutable 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.}
@@ -1098,383 +1098,383 @@ If you have redistributed an application under GPLv2\footnote{This applies
GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the
v2 termination provision will always apply. If the redistributor has
chosen v3, the v3 termination provision will always apply. If the
redistributor has chosen GPLv2-or-later, then the redistributor may want
to narrow to GPLv3-only upon violation, to take advantage of the
termination provisions in v3.}, but have violated the terms of GPLv2,
you must request a reinstatement of rights from the copyright holders
before making further distributions, or else cease distribution and
modification of the software forever. Different copyright holders
condition reinstatement upon different requirements, and these
requirements can be (and often are) wholly independent of the GPL\@. The
terms of your reinstatement will depend upon what you negotiate with the
copyright holder of the GPL'd program.
Since your rights under GPLv2 terminate automatically upon your initial
violation, \emph{all your subsequent distributions} are violations and
infringements of copyright. Therefore, even if you resolve a violation on
your own, you must still seek a reinstatement of rights from the copyright
holders whose licenses you violated, lest you remain liable for
infringement for even compliant distributions made subsequent to the
initial violation.
GPLv3 is more lenient. If you have distributed only v3-licensed programs,
you may be eligible under v3~\S~8 for automatic reinstatement of rights.
You are eligible for automatic reinstatement when:
\item you correct the violation and are not contacted by a copyright
holder about the violation within sixty days after the correction, or
\item you receive, from a copyright holder, your first-ever contact
regarding a GPL violation, and you correct that violation within thirty
days of receipt of copyright holder's notice.
In addition to these permanent reinstatements provided under v3, violators
who voluntarily correct their violation also receive provisional
permission to continue distributing until they receive contact from the
copyright holder. If sixty days pass without contact, that reinstatement
becomes permanent. Nonetheless, you should be prepared to cease
distribution during those initial sixty days should you receive a
termination notice from the copyright holder.
Given that much discussion of v3 has focused on its so-called more
complicated requirements, it should be noted that v3 is, in this regard,
more favorable to violators than v2.
However, note that most Linux-based systems typically include some software
licensed under GPLv2-only, and thus the copyright holders have withheld
permission to redistribute under terms of GPLv3. In larger aggregate
distributions which include GPLv2-only works (such as the kernel named
Linux), redistributors must operate as if termination is immediate and
permanent, since the technological remove of GPLv2-only works from the larger
distribution requires much more engineering work than the negotiation
required to seek restoration of rights for distribution under GPLv2-only
after permanent termination.
\chapter{Standard Requests}
As we noted above, different copyright holders have different requirements
for reinstating a violator's distribution rights. Upon violation, you no
longer have a license under the GPL\@. Copyright holders can therefore
set their own requirements outside the license before reinstatement of
rights. We have collected below a list of reinstatement demands that
copyright holders often require.
\item {\bf Compliance on all Free Software copyrights}. Copyright holders of Free Software
often want a company to demonstrate compliance for all GPL'd software in
a distribution, not just their own. A copyright holder may refuse to
reinstate your right to distribute one program unless and until you
comply with the licenses of all Free Software in your distribution.
\item {\bf Notification to past recipients}. Users to whom you previously
distributed non-compliant software should receive a communication
(email, letter, bill insert, etc.) indicating the violation, describing
their rights under the GPL, and informing them how to obtain a gratis source
distribution. If a customer list does not exist (such as in reseller
situations), an alternative form of notice may be required (such as a
magazine advertisement).
\item {\bf Appointment of a GPL Compliance Officer.} The software freedom community
values personal accountability when things go wrong. Copyright holders
often require that you name someone within the violating company
officially responsible for Free Software license compliance, and that this
individual serve as the key public contact for the community when
compliance concerns arise.
\item {\bf Periodic Compliance Reports.} Many copyright holders wish to
monitor future compliance for some period of time after the violation.
For some period, your company may be required to send regular reports on
how many distributions of binary and source have occurred.
These are just a few possible requirements for reinstatement. In the
context of a GPL violation, and particularly under v2's termination
provision, the copyright holder may have a range of requests in exchange
for reinstatement of rights. These software developers are talented
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:
\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?
This last point is particularly important. Many GPL enforcements are
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 as 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 stories abound in the GPL enforcement community that companies have
often formed beneficial consulting or employment relationships with
developers they first encountered through enforcement. In some cases,
working together to alter the mode of use of the project's code in the
company's products was an explicit element in dispute resolution. More
often, the communication channels opened in the course of the inquiry served
other and more fruitful 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. However, from the point of view of a GPL
violator, the most important issue is to determine the motivations of the
enforcer. The COGEOs such as the FSF and Conservancy have made substantial
public commitments to enforce in a way that is uniform, transparent, and
publicly documented. Since these organizations are public charities, they
are accountable to the IRS and the public at large in their annual Form 990
filings, and everyone can 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, which is always the paramount goal to COGEOs, may not be an
adequate resolution for a proprietary relicensing company or grey hat GPL
enforcer. Therefore, violators are advised to consider carefully who has
made the enforcement inquiry and ask when and where they have made public
commitments and reports regarding their enforcement work, perhaps asking them
to directly mimic the detailed public disclosures done by COGEOs.
\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