@@ -1164,105 +1164,105 @@ 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.
\end{itemize}
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