@@ -1020,393 +1020,393 @@ CEGEO's in particular universally follow the processes described herein.
\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
email), even if your response merely notifies the sender that you are
investigating the situation and will respond by a certain date. Do not
let the conversation lapse until the situation is fully resolved.
Proactively follow up with synchronous communication means to be sure
communications sent by non-reliable means (such as email) were received.
Remember that the software freedom community generally values open communication and
cooperation, and these values extend to GPL enforcement. You will
generally find that software freedom developers and their lawyers are willing to
have a reasonable dialogue and will work with you to resolve a violation
once you open the channels of communication in a friendly way.
Furthermore, if the complaint comes from a CEGEO, assume they are
well-prepared. CEGEO's fully investigate compliance issues before raising
the issue. The claims and concerns will be substantiated, and immediate
denials will likely lead the CEGEO to suspect malice rather than honest
mistake.
However, the biggest and most perennial mistake that all CEGEOs see during
enforcement is this: failure to include the violators' software development
teams in the enforcement discussions and negotiations. As described above,
CCS verification and approval is the most time-consuming and difficult part
of resolving most compliance matters. Without direct contact between
software developers on both sides, the resolution of the technical issues
involved in demonstrating that the binary distributed was built from the
source provided is likely to be tortuous, expensive, and tense. Your lawyers
will certainly be understandably reluctant to expose your employees to direct
inquiry from potentially adverse parties. However, facilitated exchanges of
information among software engineers communicating on technical subjects
shortens the time to resolution, substantially reduces the cost of reaching
resolution, and prevents unnecessary escalation due to mutual
misunderstanding. Furthermore, such frank technical discussion will often be
the only way to avoid compliance litigation once a violation has occurred.
Fortunately, these frank discussions will improve your company's
relationships. Free Software development communities improve software to
benefit everyone, which includes you and your company. When you use
copylefted community software in your products, you are part of that
community. Therefore, resolving a compliance matter is an occasion to
strengthen your relationship to the community, by increasing communication
between your developers and the project whose work you use for business
benefit.
\section{Termination}
Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and
GPLv3~\S~8). Under v2, violators forfeit their rights to redistribute and
modify the GPL'd software until those rights are explicitly reinstated by
the copyright holder. In contrast, v3 allows violators to rapidly resolve
some violations without consequence.
If you have redistributed an application under GPLv2\footnote{This applies
to all programs licensed to you under only GPLv2 (``GPLv2-only'').
However, most so-called GPLv2 programs are actually distributed with
permission to redistribute under GPLv2 \emph{or any later version of the
GPL} (``GPLv2-or-later''). In the latter cases, the redistributor can
choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even
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:
\begin{itemize}
\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.
\end{itemize}
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-dependant and cannot be easily addressed in any
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 well beyond the
scope of this document, but as a rule of thumb, once you have determined
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 we
discussed, replacing our discussion of ``Corresponding Source'' with
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.
%FIXME-URGENT: integrate
Under the terms of LGPL, they must also 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.
Section 2(a) states that if a licensed work is a software library (defined in
\S0 as ``a collection of software functions and/or data prepared so as to be
conveniently linked with application programs (which use some of those
functions and data) to form executables'') permission is given to distribute
modified versions only if those versions are themselves libraries. LGPLv2.1
code can therefore not be compliantly taken from its context in a library and
placed in a non-library modified version or work based on the work. Section 6
does not provide an exception for this rule: a combination may be made of a
modified version of an LGPL’d library with other code, but the LGPL’d code
must continue to be structured as a library, and to that library the terms of
the license continue to apply.
%FIXME-URGENT: END
\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
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.
% FIXME-URGENT: integrate
In such instances it is advisable that you exercise your own rights as a user
to request C\&CS for all the GPL programs that your suppliers provided to you,
preferably in an automated process. Once you receive such C\&CS, passing it
along with your product will ensure your compliance with the license.
% FIXME-URGENT: Needs a new section
% \section{Mergers and Acquisitions}
[GPLv3] Section 10 also 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.
In our experience, the process whereby these matters are adjusted in most M\&A
situations are ludicrously expensive and inefficient. A simple waiver and
release of all claims to GPL compliance against the purchased entity by the
purchaser, issued before closure, removes the problem. If the purchasing
entity has adequate software governance systems in place, all software
acquired in the course of the entity transaction is input to the standard
governance processes for acquired software, and downstream compliance by the
new merged entity is automatically handled.
\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
% FIXME-URGENT: integrate, and rewrite so it doesn't laud behavior that is
% ultimately problematic.
\section{FIXME}
companies have often formed beneficial consulting or employment relationships
with project developers they first encountered through compliance
inquiries. 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.
\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