Title: bsd-4-clause-openssl section
initial draft of bsd-4-clause-openssl section * added initial draft of bsd4clause-openssl.tex file * grafted as new section of "Special Topics in Compliance" chapter * added reference to "GPLv3 §7: Understanding License Compatibility" section of "GPL Version 3" chapter make language more consistent and RFC's more concise * added historical fact regarding BSD license change * added RFC regarding FSF reserving authority to define "System Library" * added RFC regarding a "System Library" whitelist * made previous RFC-2, RFC-3, RFC-4 more concise (now RFC-4, RFC-5, RFC-6) * split concerns from previous RFC-5 into RFC-7 and RFC-8 * corrected some typos NOTE: many of the RFC's are contingent upon preceding ones; so presumably, some may be removed. Ideally, they will all be answered eventually and transformed more formally into advice rather than open questions.
Under review
There are no reviewers
git pull https://k.copyleft.org/guide-bill-auger bsd-4-clause
2016-11-05 18:03:53
bill auger (bill-auger)
mr.j.spam.me@gmail.com
Git pull requests don't support updates yet.
Pull Request Reviewers
Potential Reviewers
Click to add the repository owner as reviewer:
2 comments (1 inline, 1 general)
Showing 2 commits
2 2016-11-05 21:59:24
bill-auger
6230249f2f8a bsd-4-clause
make language more consistent and RFC's more concise * added historical fact regarding BSD license change * added RFC regarding FSF reserving authority to define "System Library" * added RFC regarding a "System Library" whitelist * made previous RFC-2, RFC-3, RFC-4 more concise (now RFC-4, RFC-5, RFC-6) * split concerns from previous RFC-5 into RFC-7 and RFC-8 * corrected some typos
1 2016-11-05 21:58:42
bill-auger
7286fe56bb36
initial draft of bsd-4-clause-openssl section * added initial draft of bsd4clause-openssl.tex file * grafted as new section of "Special Topics in Compliance" chapter * added reference to "GPLv3 §7: Understanding License Compatibility" section of "GPL Version 3" chapter
Common ancestor: 85bbbf1ec649
2 files changed
Changeset was too big and was cut off... Show full diff anyway
bsd4clause-openssl.tex | Added bsd-4-clause
 
new file 100644
1
 
\bf{NOTE: This section is a draft. It may contain errors. Please do correct any errors you find.}\newline
2
 

	
3
 

	
4
 
{\em This section assumes that the reader is somewhat familiar with the BSD-4-clause<->GPL conflict.  If not, a good \href{https://people.gnome.org/~markmc/openssl-and-the-gpl.html}{overview by Mark McLoughlin} can be read on the Gnome website.  The aim of this section is to clarify common misconceptions, to consolidate the most informative references, and to offer guidance for developers, project maintainers, and packagers regarding this issue.}
5
 

	
6
 

	
7
 
\subsection{Motivation}
8
 

	
9
 
The GPLv2 and GPLv3 both include a requirement of the form: "You may not impose any further restrictions ..." (GPLv2 Section 6 - GPLv3 Section 10), which the FSF (author and publisher of the GPL family of licenses) contends is in conflict, generally, with all licenses of the original "4-clause BSD" form (such as that of the widely-used OpenSSL license) due to it's "obnoxious" advertising clause. \footnotemark[1] \footnotemark[2] \footnotemark[3] \footnotemark[4]  Not surprisingly, it seems to be the general consensus among free software developers that any program or library which itself links to the OpenSSL library is incompatible with the GPLs; but there is some controversy as to whether or not the OpenSSL library is exempted by the GPL "System Library Exception" (GPLv2 Section 3 - GPLv3 Section 1) and whether or not the LGPL can be used as a remedy. \footnotemark[5]  Notions have been expressed from general apathy as "... In reality, GPL/OpenSSL linking is tolerated because few upstream GPL project developers care about the issue ...". \footnotemark[6] to frustration "... this [is] totally non-productive nonsense. Seriously, how many people actually care whether some GPL code links with OpenSSL?  My guess is two: RMS and EM. ...". \footnotemark[7]  Well, if you are reading this (and of course, you are), that makes at least three people.
10
 

	
11
 
These differences in opinion are manifest most plainly in the package repositories of various GNU/Linux distributions; with distros representing both sides of the debate.  As such, there are possibly hundreds of packages in the repos of major distros currently installing programs with GPL-family licenses that link to OpenSSL (or other libraries with similar licensing terms).  Some distros have chosen to offer custom versions of these libraries that either replace OpenSSL with a compatible library (such as GnuTLS or Mozilla NSS) or strip out the functionality that requires such libraries.  Some have chosen not to carry these libraries at all.
12
 

	
13
 
One thing that everyone should agree upon is that in order for licensing terms to be valid, they must not be subject to interpretation; so it must be the case that only one interpretation is defensible.  Therefore, it must be true either that distros that distribute OpenSSL-enabled forms of the conflicting libraries are violating the GPL or that the other distros are expending precious resources or limiting their packaging selection unnecessarily in order to avoid the perceived conflict.  The resolution to this debate would seem to hinge most strongly upon whether or not the FSF considers OpenSSL to be an essential "System Library" and if there is a precise notion of "System Library" that applies universally across all GNU/Linux systems or if a particular library such as OpenSSL can be essential on some distro but not others.  After all, in terms of core system components, most of systemd is essential on some systems with none of it's components present on others; and one certainly could not claim that any of systemd is essential on a Windows system.  Unfortunately, there is little authoritative information to be found regarding this nor examples of how this has been handled in the past; and one must muddle through megabytes of lawyer-speak in order to parse most of what is accessible and reach a conclusion on their own.
14
 

	
15
 
The OpenSSL library is focused upon here only because it is perhaps the most widely used library that induces this dilemma; but this section applies generally to any library with a license of the original "4-clause BSD" form.  One particular library (libircclient) is mentioned because it exemplifies a particular corner-case that should be highlighted.  It is an LGPLv3+ licensed library that is capable of linking to OpenSSL, but only if the user specifies an enabling switch to the ./configure script; otherwise it will not link to OpenSSL. \footnotemark[8]  This is a fairly common practice; but it is unclear whether or not such a switch is permitted by the LGPLv3 and whether or not the resulting binaries (even without OpenSSL support) are themselves legitimate.  In other words, does the licensing conflict exist before compile-time or does the conflict arise only at the moment the actual linkage occurs?
16
 

	
17
 

	
18
 
\subsection{The Facts}
19
 

	
20
 
The following bullet points constitute the entire body of unambiguous facts on this topic resulting from research to date:
21
 

	
22
 
\begin{itemize}
23
 
  \item This issue has haunted the free software community for a very long time.
24
 

	
25
 
  \item BSD removed this clause from it's license in 1999; but licenses retaining an analagous clause are still prevalent today, notably OpenSSL License of the OpenSSL library.
26
 

	
27
 
  \item The GNU license compatibility list categorizes both the Original BSD (4-clause) License and the OpenSSL License as "GPL-Incompatible Free Software Licenses". \footnotemark[9] \footnotemark[10]
28
 

	
29
 
  \item The LGPLv3 does not itself contain the same wording such as that in the which constitutes the conflict; but it does clearly state that it's terms are supplemental extensions to the GPLv3. \footnotemark[11]
30
 

	
31
 
  \item FedoraProject considers OpenSSL to be a "System Library" and so exempt from conflict per the "System Library Exception". \footnotemark[12]  Fedora distributes the libircclient binary package with OpenSSL linkage enabled as do third-party RPM repos. \footnotemark[13] \footnotemark[14]
32
 

	
33
 
  \item Debian has taken the opposite stance that OpenSSL is non-essential and therefore not exempted by the GPL "System Library Exception"; and has generally recommended that upstreams of GPL'ed programs add an exception for OpenSSL to their licenses. \footnotemark[15]  As an example of an LGPL'ed library, Debian distributes the libircclient binary package with OpenSSL linkage disabled. \footnotemark[16]  Debian even goes so far as to track and post on its website all such potential license collisions detected by it's automated Lintian package sanity checker and the final acceptance decisions. \footnotemark[17]
34
 

	
35
 
  \item Several other distros distribute libircclient binaries but no clear statements on this matter have yet to be found from these. The libircclient packages in ArchLinux (also AUR), Gentoo, and OpenSuse have OpenSSL linkage enabled; so presumably they are either unaware of the issue or are in the Fedora camp. \footnotemark[18] \footnotemark[19] \footnotemark[20] \footnotemark[21]  The libircclient package in Ubuntu does not have OpenSSL linkage enabled so they are presumably following Debian's lead. \footnotemark[22]
36
 

	
37
 
  \item The OpenSSL FAQs interpret the scope of the "System Library Exception" maximally, stating "... the GPL does not place restrictions on using libraries that are part of the normal operating system distribution ...". \footnotemark[23]
38
 

	
39
 
  \item The most definitive reference yet found as to the official FSF opinion of whether OpenSSL qualifies for the "System Library Exception" is a post to the debian-legal mailing list by Shane Coughlan of the FSFE who quoted Brett Smith of the FSF as saying, "... We do not believe that OpenSSL qualifies as a System Library in Debian. ...".  That "belief" was reportedly justified by the comparatively small number of reverse-dependencies for a genuinely essential system library and the fact that "... it isn't installed on a base system. ...".  \footnotemark[24]  Clearly though, this leaves open the possibility (however dubious) that it could be considered otherwise depending on the distribution; so it would be interesting to apply this measure against the distros that do take that position.
40
 

	
41
 
  \item A broad interpretation of the "System Library Exception" can be found in the "Software Freedom Law Center Guide to GPL Compliance 2nd Edition", stating that "... the intention of the “System Library exception” is to avoid the need for production of source code which the user can expect to receive with the copy of the operating system ...". \footnotemark[25]
42
 

	
43
 
  \item On 2015-08-01 OpenSSL announced plans to re-license as Apache-2.0 which is compatible with the GPLv3; but there has since been no news regarding this at the time of this writing (2016-11-02). \footnotemark[26]
44
 

	
45
 
  \item On 2016-10-31 Rich Salz, representing OpenSSL, announced their latest road-map which made no mention of re-licensing; so a reader asked if there was any progress in this direction. This was the response: \footnotemark[27]
46
 
    \begin{verbatim}
47
 
    Rich Salz 2016-11-01
48
 
    "We are still working on it.  Nothing to report.  Unlike public code development,
49
 
         this will mostly be a quiet behind the scenes venture."
50
 
    \end{verbatim}
51
 

	
52
 
  \item Perhaps a counter-fact, but the "Software Freedom Law Center Guide to GPL Compliance 2nd Edition" says of the GPLv3 Section 7(d): "... The long-standing and occasionally troublesome incompatibility with the “BSD advertising clause” is an example of the friction removed by this provision. ...". \footnotemark[25]  If that is to be taken literally ('removed', not 'eased'), then this section can perhaps shrink substantially.
53
 

	
54
 
  \item Currently, the simplest remedies are either to add a "Linking Exception" to the license header of each source file of the main program or to re-licence the entire project permissively.  \footnotemark[28]  The caveat is that all copyright holders must agree to this.  If it is not feasible to do so, then perhaps a replacement library can be found.  In the case of OpenSSL several such replacements exist for it's various functions such as GnuTLS, Mozilla NSS, and Nettle.
55
 
\end{itemize}
56
 

	
57
 
\subsection{Frequently Asked Questions}
58
 

	
59
 
\subsubsection{Should I inform the developer(s) that their library violates the GPL?  Should this be done privately via email or on the project's public forum?}
60
 

	
61
 
?
62
 

	
63
 
\subsubsection{Should I ask the distro packager(s) to stop distributing the offending library?}
64
 

	
65
 
?
66
 

	
67
 
\subsubsection{What if the developer(s) or packager(s) refuse or do not respond?}
68
 

	
69
 
The SFLC offers a form letter for engaging upstreams in "A Legal Issues Primer for Open Source and Free Software Projects" and recommends that they or other legal counsel be contacted if the issue can not be resolved in a timely manner. \footnotemark[29]
70
 

	
71
 
\subsubsection{If I have a GPL program which links to a library such as libircclient which is capable (but only as a compile-time option) of linking to OpenSSL, can I simply drop support for distros that enable this option and target only those who choose not to; or should I inform any distros that the such libraries violate the GPL whether they link it to OpenSSL or not?}
72
 

	
73
 
?
74
 

	
75
 
\subsubsection{Should I not care at all about this? Does the FSF care at all about this? Maybe, I can find a replacement library and forget about it.}
76
 

	
77
 
?
78
 

	
79
 
\subsubsection{If I have a GPL'ed program which has as a dependency some (otherwise compatible) library that itself links to OpenSSL, does this taint my GPL?}
80
 

	
81
 
?
82
 

	
83
 
\subsubsection{Should I myself cease distributing my program and request that packagers cease packaging it until the conflict is resolved (e.g. by re-licensing my project, replacing the library, or waiting until OpenSSL re-licenses)?}
84
 

	
85
 
?
86
 

	
87
 

	
88
 
\subsection{Interpretation and Caveats}
89
 

	
90
 
The following are among the most opaque but pragmatic points to be underlined as it concerns project maintainers and packagers:
91
 

	
92
 
\begin{itemize}
93
 
  \item{\bf{[RFC-1]\newline
94
 
Does the FSF concur with the FedoraProject that OpenSSL is a "System Library" exempted per the GPL "System Library Exception"; or does the FSF concur with Debian that OpenSSL is non-essential and not exempted by the GPL "System Library Exception"?  They are, above all, the authority on the matter, aren't they?}
95
 
    \begin{quote}
96
 
If Shane Coughlan's account or Brett Smith's statement is accurate, then the FSF does not consider OpenSSL to be an essential "System Library" and so does not qualify for the GPL "System Library Exception" (at least not on a Debian system).  No such statements have been found regarding other distros however.
97
 
    \end{quote}}
98
 

	
99
 
  \item{\bf{[RFC-2]\newline
100
 
Would the FSF prefer to be the authority on what qualifies as a "System Library" exempted per the GPL "System Library Exception"; or would the FSF prefer to delegate this to each distro, providing that they do so formally as a matter of published policy?}
101
 
    \begin{quote}
102
 
?
103
 
    \end{quote}}
104
 

	
105
 
  \item{\bf{[RFC-3]\newline
106
 
How feasilbe would it be for the FSF to maintain a white-list of "Essential Core System Libraries" in order to remove any doubt.  After all, leaving any such caveat as subject to interpretation is practically the same as omission - is it not?}
107
 
    \begin{quote}
108
 
?
109
 
    \end{quote}}
110
 

	
111
 
  \item{\bf{[RFC-4]\newline
112
 
Can a GPLv2 or GPLv3 main program (with or without an explicit linking exception) link itself to a library licensed under the corresponding LGPL version that, in turn, links itself to OpenSSL, or any other library, regardless of the license of latter sub-dependency?  If not, may the LGPLv2 or LGPLv3 library provide a "Linking Exception" to explicitly permit this.  All of the language in the LGPLv3 speaks in terms of a GPL-incompatible main program's ability to link itself to LGPL'ed libraries; but says nothing of linkage in the other direction (e.g. an LGPL'ed library that itself requires a proprietary or otherwise incompatibly licensed helper).  This is a point of confusion for many people.}
113
 

	
114
 
}
115
 
    \begin{quote}
116
 
?
117
 
    \end{quote}}
118
 

	
119
 
  \item{\bf{[RFC-5]\newline
120
 
If the answer to RFC-4 is negatory, that is, it is in no way possible for an LGPL'ed library to, itself, require a proprietary or otherwise incompatibly licensed helper legitimately, then can it be made compliant by disabling that feature as the default behavior and requiring the user to enable it with a compile-time switch?  In other words, does the licensing conflict exist simply because the code is capable of producing a binary that may, at the user's option, link to an incompatibly licensed library; or does the conflict not arise until compile-time or runtime, such that anyone can distribute the source code and the end user is free to compile with the switch enabled as long as they do not distribute the resulting binary?  Only one instance of someone raising this specific concern of a compile-time switch has been found; but the concern was not addressed.} \footnotemark[30]
121
 
    \begin{quote}
122
 
?
123
 
    \end{quote}}
124
 

	
125
 
  \item{\bf{[RFC-6]\newline
126
 
Conversely, if the answer to RFC-4 is affirmative, that is, it is indeed possible for an LGPL'ed library to itself require a proprietary or otherwise incompatibly licensed helper library as a sub-dependency, then does this taint the license of any main GPL'ed client program, such that it must, itself, re-license to the same LGPL version as the intermediate library (or more permissively) in order to use it (and the incompatibly licensed sub-dependency by proxy)?  This case is presumably fallacious but some people do believe this is a valid option, so it is probably noteworthy of contrasting this to the preceding concern (RFC-5). \footnotemark[5]  Otherwise, if this is permissible, then one can easily imagine a plethora of LGPL'ed libraries which are nothing more than thin wrappers around GPL-incompatible libraries.  Indeed, one can imagine a project devoted to consolidating such wrappers and/or a website devoted to indexing them.  It would be quite ironic to see such a wrapper indexed on the FSF Free Software Directory.}
127
 
    \begin{quote}
128
 
?
129
 
    \end{quote}}
130
 

	
131
 
  \item{\bf{[RFC-7]\newline
132
 
If the answer to RFC-4 is affirmative, then what does this imply for any GPLv3 program that links itself to such a library?  Could one add a "Linking Exception" to the license of the main program allowing it's dependency to link to OpenSSL as a sub-dependency (even if the dependency does not provide such an exception)?  If the dependency already provides such an exception, then must the main program also provide the same exception?}
133
 
    \begin{quote}
134
 
?
135
 
    \end{quote}}
136
 

	
137
 
  \item{\bf{[RFC-8]\newline
138
 
Instead of a "Linking Exception", could one state a disclaimer such as: "You may not run this program on any distro that links this program's dependencies to OpenSSL unless you compile those dependencies yourself with OpenSSL disabled and link this program to those instead."?  Could one further add something like: "... unless your distro has a public policy declaring OpenSSL to be an essential "System Library" on their distro and so exempted by the GPL "System Library Exception"."?}
139
 
    \begin{quote}
140
 
?
141
 
    \end{quote}}
142
 

	
143
 
  \item{\bf{[RFC-9]\newline
144
 
An important caveat regarding the definition of “Corresponding Source” in GPLv3 Section 1 is that it requires that the source can be compiled as to "... run the object code ..." but makes no accommodations nor constraints on any particular operating environment in which it must be able to run.  Presumably, it is not the intention that all GPL-licensed software must be executable on all architectures and operating systems.  So, it would follow that project maintainers are free to support only certain operating environments; and it can be easily argued based on dependency trees alone that Fedora and Debian (for example) are different operating environments; and so project maintainers should be free to support only certain distros and not necessarily all distros.  Otherwise, if the distribution requirements in GPLv3 Section 6d and the “Corresponding Source” definition are interpreted too stringently, the overall requirement would be that all GPL-licensed software projects must themselves distribute cross-platform source code for all dependencies (and sub-dependencies) in the dependency chain all the way down to the vaguely defined "System Libraries" allowing "The Program" to compile on any all operating systems and distros past, present, and future.  That is presumably not the intention and would likely lead to everyone distributing nothing but docker images.  If project maintainers are indeed free to selectively support only certain environments, then the GPL "System Library Exception" along with GPLv3 Sections 6d and 6e would seem to allow some isolation from this sort of licensing conflict as long the following conditions are met:
145
 
    \begin{itemize}
146
 
      \item{The Program must be licensed with a version of the GPL that allows third parties to distribute sources for dependencies of The Program (this is currently only the GPLv3)}
147
 
      \item{If the potentially conflicting dependency is LGPLv3 licensed, then the project maintainer of The Program must comply with the LGPL "Combined Works" section of the dependency's license (LGPLv3 Section 4) opting to "... Use a suitable shared library mechanism for linking with the Library ... already present on the user's computer system ..." (LGPLv3 Section 4d1).} % \footnotemark[11]
148
 
      \item{The end user's distro includes the potentially conflicting dependencies in it's base distribution media; or a "... third-party ..." (such as the user's distro) distributes them "... on a different server ..." than The Program "... for as long as needed ..." (which the GPL FAQs clarify to be "... as long as you distribute the object code ...")} % \footnotemark[31]
149
 
      \item{The project maintainer insists that end users obtain the dependencies themselves through their package manager but only if their distro hosts all of the dependencies in a form that does not conflict with the license of The Program.}
150
 
      \item{At least one such known distro is designated as "supported" by The Program.}
151
 
      \item{The project maintainer insists that end users of distros hosting The Program's dependencies in a form that conflicts with the it's license and end users of distros that do not host The Program's dependencies are not to expect a usable result (any more of than a Windows user could expect while compiling systemd in VisualStudio.  If such users can not obtain the source code for the dependencies somehow and compile themselves in a way that does not conflict with the license of The Program; they are still free to install a supported distro or run one in a VM to use The Program legitimately.  How could it be argued that such users are being deprived of their freedom in this way?}
152
 
      \item{If the day ever arrives that no distro that is designated as supported by The Program any longer hosts compatible versions of the tainted dependencies then The Program's maintainer would be obliged only to cease to "... distribute the object code ..." per GPLv3 Section 6d}
153
 

	
154
 
In this way the responsibility of resolving dependency and licensing compatibility conflicts is delegated to distro packagers and package management software which exist precisely for that purpose.  Note, that this is all assuming that the binary dependency with the previously mentioned conflict-enabling compile-time switch is not itself inherently illegitimate (per RFC-5); but is GPLv3-compatible if the switch is not activated.  Also, this proposal depends on a loose but reasonable interpretation of “Corresponding Source” which is defined somewhat inconsistently to include "... the source code for shared libraries and dynamically linked subprograms ..." but to exclude "... generally available free programs which are used unmodified ...".  It can be easily argued that shared binary libraries are both "generally available" and "used unmodified".
155
 
    \end{itemize}}
156
 
    \begin{quote}
157
 
?
158
 
    \end{quote}}
159
 
\end{itemize}
160
 

	
161
 

	
162
 
\subsection{References}
163
 

	
164
 
\footnotetext[1]{\href{https://www.gnu.org/licenses/old-licenses/gpl-2.0.html}{https://www.gnu.org/licenses/old-licenses/gpl-2.0.html}}
165
 
\footnotetext[2]{\href{https://www.gnu.org/licenses/gpl.html}{https://www.gnu.org/licenses/gpl.html}}
166
 
\footnotetext[3]{\href{https://spdx.org/licenses/BSD-4-Clause}{https://spdx.org/licenses/BSD-4-Clause}}
167
 
\footnotetext[4]{\href{https://www.openssl.org/source/license.txt}{https://www.openssl.org/source/license.txt}}
168
 
\footnotetext[5]{\href{https://github.com/JulyIGHOR/QtBitcoinTrader/issues/27\#issuecomment-32726728}{https://github.com/JulyIGHOR/QtBitcoinTrader/issues/27\#issuecomment-32726728}}
169
 
\footnotetext[6]{\href{http://www.lawseminars.com/materials/08OPSMA/opsma\%20m\%20fontana\%2010-29\%20new\%20up.pdf}{http://www.lawseminars.com/materials/08OPSMA/opsma\%20m\%20fontana\%2010-29\%20new\%20up.pdf (slide 10)}}
170
 
\footnotetext[7]{\href{https://lists.debian.org/debian-legal/2005/06/msg00033.html}{https://lists.debian.org/debian-legal/2005/06/msg00033.html}}
171
 
\footnotetext[8]{\href{http://www.ulduzsoft.com/libircclient/index.html\#required-libraries}{http://www.ulduzsoft.com/libircclient/index.html\#required-libraries}}
172
 
\footnotetext[9]{\href{https://www.gnu.org/licenses/license-list.html\#OpenSSL}{https://www.gnu.org/licenses/license-list.html\#OpenSSL}}
173
 
\footnotetext[10]{\href{https://www.gnu.org/licenses/license-list.html\#OriginalBSD}{https://www.gnu.org/licenses/license-list.html\#OriginalBSD}}
174
 
\footnotetext[11]{\href{https://www.gnu.org/licenses/lgpl.html}{https://www.gnu.org/licenses/lgpl.html}}
175
 
\footnotetext[12]{\href{https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ\#What.27s\_the\_deal\_with\_the\_OpenSSL\_license.3F}{https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ\#What.27s\_the\_deal\_with\_the\_OpenSSL\_license.3F}}
176
 
\footnotetext[13]{\href{http://koji.fedoraproject.org/koji/rpminfo?rpmID=8042289}{http://koji.fedoraproject.org/koji/rpminfo?rpmID=8042289}}
177
 
\footnotetext[14]{\href{http://rpmfind.net/linux/RPM/fedora/24/x86\_64/l/libircclient-1.8-6.fc24.x86\_64.html}{http://rpmfind.net/linux/RPM/fedora/24/x86\_64/l/libircclient-1.8-6.fc24.x86\_64.html}}
178
 
\footnotetext[15]{\href{https://lists.debian.org/debian-legal/2004/05/msg00595.html}{https://lists.debian.org/debian-legal/2004/05/msg00595.html}}
179
 
\footnotetext[16]{\href{https://packages.debian.org/jessie/libircclient1}{https://packages.debian.org/jessie/libircclient1}}
180
 
\footnotetext[17]{\href{https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html}{https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html}}
181
 
\footnotetext[18]{\href{https://www.archlinux.org/packages/community/x86\_64/libircclient/}{https://www.archlinux.org/packages/community/x86\_64/libircclient/}}
182
 
\footnotetext[19]{\href{https://aur.archlinux.org/packages/libircclient-openssl-ipv6/}{https://aur.archlinux.org/packages/libircclient-openssl-ipv6/}}
183
 
\footnotetext[20]{\href{https://packages.gentoo.org/packages/net-libs/libircclient}{https://packages.gentoo.org/packages/net-libs/libircclient}}
184
 
\footnotetext[21]{\href{https://build.opensuse.org/package/view\_file/devel:libraries:c\_c++/libircclient/libircclient.spec?expand=1}{https://build.opensuse.org/package/view\_file/devel:libraries:c\_c++/libircclient/libircclient.spec?expand=1}}
185
 
\footnotetext[22]{\href{http://packages.ubuntu.com/xenial/libircclient1}{http://packages.ubuntu.com/xenial/libircclient1}}
186
 
\footnotetext[23]{\href{https://www.openssl.org/docs/faq.html\#LEGAL2}{https://www.openssl.org/docs/faq.html\#LEGAL2}}
187
 
\footnotetext[24]{\href{https://lists.debian.org/debian-legal/2007/07/msg00194.html}{https://lists.debian.org/debian-legal/2007/07/msg00194.html}}
188
 
\footnotetext[25]{\href{https://www.softwarefreedom.org/resources/2014/SFLC-Guide\_to\_GPL\_Compliance\_2d\_ed.html\#gplv3}{https://www.softwarefreedom.org/resources/2014/SFLC-Guide\_to\_GPL\_Compliance\_2d\_ed.html\#gplv3}}
189
 
\footnotetext[26]{\href{https://www.openssl.org/blog/blog/2015/08/01/cla/}{https://www.openssl.org/blog/blog/2015/08/01/cla/}}
190
 
\footnotetext[27]{\href{https://www.openssl.org/blog/blog/2016/10/24/f2f-roadmap/}{https://www.openssl.org/blog/blog/2016/10/24/f2f-roadmap/}}
191
 
\footnotetext[28]{\href{https://www.gnu.org/licenses/gpl-faq.html\#GPLIncompatibleLibs}{https://www.gnu.org/licenses/gpl-faq.html\#GPLIncompatibleLibs}}
192
 
\footnotetext[29]{\href{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-170002.5.4}{http://www.softwarefreedom.org/resources/2008/foss-primer.html\#x1-170002.5.4}}
193
 
\footnotetext[30]{\href{https://lists.debian.org/debian-legal/2005/09/msg00024.html}{https://lists.debian.org/debian-legal/2005/09/msg00024.html}}
194
 
\footnotetext[31]{\href{https://www.gnu.org/licenses/gpl-faq.html\#SourceAndBinaryOnDifferentSites}{https://www.gnu.org/licenses/gpl-faq.html\#SourceAndBinaryOnDifferentSites}}
195
 

	
196
 
NOTES:
197
 

	
198
 
* regarding link 6 - the project maintainer refused the initial patch (relicensing to LGPL) and chose to add an exception for OpenSSL to it's existing GPLv3
compliance-guide.tex | next bsd-4-clause
1 1
 
% compliance-guide.tex                            -*- LaTeX -*-
2 2
 

	
3 3
 
\part{A Practical Guide to GPL Compliance}
4 4
 
\label{gpl-compliance-guide}
5 5
 

	
6 6
 
\chapter*{Executive Summary}
7 7
 

	
8 8
 
This is a guide to effective compliance with the GNU General Public
9 9
 
License (GPL) and related licenses.  Copyleft advocates
10 10
 
usually seek to assist the community with
11 11
 
GPL compliance cooperatively.   This guide focuses on complying from the
12 12
 
start, so that readers can learn to avoid enforcement actions entirely, or, at
13 13
 
least, minimize  the negative impact when enforcement actions occur.
14 14
 
This guide  introduces and explains basic legal concepts related to the GPL and its
15 15
 
enforcement by copyright holders. It also outlines business practices and
16 16
 
methods that lead to better GPL compliance.  Finally, it recommends proper
17 17
 
post-violation responses to the concerns of copyright holders.
18 18
 

	
19 19
 
\chapter{Background}
20 20
 

	
21 21
 
Copyright law grants exclusive rights to authors.  Authors who chose copyleft
22 22
 
seek to protect the freedom of users and developers to copy, share, modify
23 23
 
and redistribute the software.  However, copyleft is ultimately implemented
24 24
 
through copyright, and the GPL is primarily and by default a copyright
25 25
 
license.  (See \S~\ref{explaining-copyright} for more about the interaction
26 26
 
between copyright and copyleft.)  Copyright law grants an unnatural exclusive
27 27
 
control to copyright holders regarding copyright-controlled permissions
28 28
 
related to the work.  Therefore, copyright holders (or their agents) are the
29 29
 
ultimately the sole authorities to enforce copyleft and protect the rights of
30 30
 
users.  Actions for copyright infringement are the ultimate legal mechanism
31 31
 
for enforcement.  Therefore, copyright holders, or collaborative groups of
32 32
 
copyright holders, have historically been the actors in GPL enforcement.
33 33
 

	
34 34
 
The earliest of these efforts began soon after the GPL was written by
35 35
 
Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,
36 36
 
often in public Usenet discussions.\footnote{One example is the public
37 37
 
  outcry over NeXT's attempt to make the Objective-C front-end to GCC
38 38
 
  proprietary.  RMS, in fact, handled this enforcement action personally and
39 39
 
  the Objective-C front-end is still part of upstream GCC today.}  Over the next decade, the Free Software Foundation (FSF),
40 40
 
which holds copyrights in many GNU programs, was the only visible entity
41 41
 
actively enforcing its GPL'd copyrights on behalf of the software freedom
42 42
 
community.
43 43
 
FSF's enforcement
44 44
 
was generally a private process; the FSF contacted violators
45 45
 
confidentially and helped them to comply with the license.  Most
46 46
 
violations were pursued this way until the early 2000's.
47 47
 

	
48 48
 
By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in
49 49
 
embedded devices such as wireless routers.  During this period, public
50 50
 
ridicule of violators in the press and on Internet fora supplemented
51 51
 
ongoing private enforcement and increased pressure on businesses to
52 52
 
comply.  In 2003, the FSF formalized its efforts into the GPL Compliance
53 53
 
Lab, increased the volume of enforcement, and built community coalitions
54 54
 
to encourage copyright holders to together settle amicably with violators.
55 55
 
Beginning in 2004, Harald Welte took a more organized public enforcement
56 56
 
approach and launched \href{http://gpl-violations.org/}{gpl-violations.org}, a website and mailing
57 57
 
list for collecting reports of GPL violations.  On the basis of these
58 58
 
reports, Welte successfully pursued many enforcement actions in Europe, including
59 59
 
formal legal action.  Harald earns the permanent fame as the first copyright
60 60
 
holder to bring legal action in a court regarding GPL compliance.
61 61
 

	
62 62
 
In 2007, two copyright holders in BusyBox, in conjunction with the
63 63
 
Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit
64 64
 
based on a violation of the GPL\@ in the USA. While  lawsuits are of course
65 65
 
quite public, the vast majority of Conservancy's enforcement actions 
66 66
 
are resolved privately via
67 67
 
cooperative communications with violators.  As both FSF and Conservancy have worked to bring
68 68
 
individual companies into compliance, both organizations have encountered numerous
69 69
 
violations resulting from preventable problems such as inadequate
70 70
 
attention to licensing of upstream software, misconceptions about the
71 71
 
GPL's terms, and poor communication between software developers and their
72 72
 
management.  This document highlights these problems and describe
73 73
 
best practices to encourage corporate Free Software users to reevaluate their
74 74
 
approach to GPL'd software and avoid future violations.
75 75
 

	
76 76
 
Both FSF and Conservancy continue GPL enforcement and compliance efforts
77 77
 
for software under the GPL, the GNU Lesser
78 78
 
Public License (LGPL) and other copyleft licenses.  In doing so, both organizations have
79 79
 
found that most violations stem from a few common, avoidable mistakes.  All copyleft advocates  hope to educate the community of
80 80
 
commercial distributors, redistributors, and resellers on how to avoid
81 81
 
violations in the first place, and to respond adequately and appropriately
82 82
 
when a violation occurs.
83 83
 

	
84 84
 
\section{Who Has Compliance Obligations?}
85 85
 

	
86 86
 
All distributors of modified or unmodified versions of copylefted works
87 87
 
unmodified versions of the works have compliance obligations.  Common methods
88 88
 
of modifying the works include innumerable common acts, such as:
89 89
 

	
90 90
 
\begin{itemize}
91 91
 

	
92 92
 
  \item embedding those works as executable copies
93 93
 
    into a device,
94 94
 

	
95 95
 
  \item transferring a digital copy of executable copies to someone else,
96 96
 

	
97 97
 
  \item posting a patch to the copylefted software to a public mailing list.
98 98
 

	
99 99
 
\end{itemize}
100 100
 

	
101 101
 
Such distributors have obligations to (at least) the users to whom they (or
102 102
 
intermediary parties) distribute those copies.  In some cases, distributors
103 103
 
have obligations to third parties not directly receiving their distribution
104 104
 
of the works (depending on the distributors chosen licensing options, as
105 105
 
described later in \S~\ref{binary-distribution-permission}).  In addition,
106 106
 
distributors have compliance obligations to upstream parties, such as
107 107
 
preservation of reasonable legal notices embedded in the code, and
108 108
 
appropriate labeling of modified versions.
109 109
 

	
110 110
 
Online service providers and distributors alike have other compliance
111 111
 
obligations.  In general, they must refrain from imposing any additional
112 112
 
restrictions on downstream parties. Most typically, such compliance problems
113 113
 
arise from ``umbrella licenses:'' EULAs, or sublicenses that restrict
114 114
 
downstream users' rights under copyleft. (See \S~\ref{GPLv2s6} and
115 115
 
\S~\ref{GPLv3s10}).
116 116
 

	
117 117
 
Patent holders having claims reading on GPL'd works they distribute must
118 118
 
refrain from enforcing those claims against parties to whom they distribute.
119 119
 
Furthermore, patent holders holding copyrights on GPLv3'd works must further
120 120
 
grant an explicit patent license for any patent claims reading on the version
121 121
 
they distributed, and therefore cannot enforce those specific patent claims
122 122
 
against anyone making, using or selling a work based on their distributed
123 123
 
version.  All parties must refrain from acting as a provider of services or
124 124
 
distributor of licensed works if they have accepted, or had imposed on them
125 125
 
by judicial action, any legal conditions that would prevent them from meeting
126 126
 
any obligation under GPL\@.  (See \S~\ref{GPLv2s7}, \S~\ref{GPLv3s11} and
127 127
 
\S~\ref{GPLv3s12}.
128 128
 

	
129 129
 
\section{What Are The Risks of Non-Compliance?}
130 130
 

	
131 131
 
Copyleft experts have for decades observed a significant mismatch between the
132 132
 
assumptions most businesses make about copyleft compliance and the realities.
133 133
 
Possibly due to excessive marketing of proprietary tools and services from
134 134
 
the for-profit compliance industry, businesses perennially focus on the wrong
135 135
 
concerns.  This tutorial seeks to educate those businesses about what
136 136
 
actually goes wrong, what causes disputes, and how to resolve those disputes.
137 137
 

	
138 138
 
Many businesses currently invest undue resources to avoid unlikely risks that
139 139
 
have low historical incidence of occurrence and low cost of remediation,
140 140
 
while leaving unmanaged the risks that have historically resulted in all the
141 141
 
litigation and other adverse outcomes.  For example, some ``compliance
142 142
 
industry''\footnote{``Compliance industry'' refers to third-party for-profit
143 143
 
  companies that market proprietary software tools and/or consulting services
144 144
 
  that purport to aid businesses with their Free Software license compliance
145 145
 
  obligations, such as those found in GPL and other copyleft licenses.  This
146 146
 
  tutorial leaves the term in quotes throughout, primarily to communicate the
147 147
 
  skepticism most of this tutorial's authors feel regarding the mere
148 148
 
  existence of this industry.  Not only do copyleft advocates object on
149 149
 
  principle to proprietary software tools in general, and to their ironic use
150 150
 
  specifically to comply with copyleft, but also to the ``compliance
151 151
 
  industry'' vendors' marketing messaging, which some copyleft advocates
152 152
 
  claim as a cause in the risk misassessments discussed herein.  Bradley
153 153
 
  M.~Kuhn, specifically, regularly uses the term ``compliance industrial
154 154
 
  complex''
155 155
 
  \href{http://en.wikipedia.org/wiki/Military-industrial_complex}{to
156 156
 
    analogize the types of problems in this industry to those warned against
157 157
 
    in the phrase of origin}.} vendors insist that great effort must be
158 158
 
expended to carefully list, in the menus or manuals of embedded electronics
159 159
 
products, copyright notices for every last copyright holder that contributed
160 160
 
to the Free Software included in the product.  While nearly all Free Software
161 161
 
licenses, including copylefts like GPL, require preservation and display of
162 162
 
copyright notices, failure to meet this specific requirement is trivially
163 163
 
remedied.  Therefore, businesses should spend just reasonable efforts to
164 164
 
properly display copyright notices, and note that failure to do so is simply
165 165
 
remedied: add the missing copyright notice!
166 166
 

	
167 167
 
\section{Understanding Who's Enforcing}
168 168
 
\label{compliance-understanding-whos-enforcing}
169 169
 

	
170 170
 
The mismatch between actual compliance risk and compliance risk management
171 171
 
typically results from a misunderstanding of licensor intentions.  For-profit
172 172
 
businesses often err by assuming other actors have kindred motivations.  The
173 173
 
primary enforcers of the GPL, however, have goals that for-profit businesses
174 174
 
will find strange and perhaps downright alien.
175 175
 

	
176 176
 
Specifically, community-oriented GPL enforcement organizations (called
177 177
 
``COGEOs'' throughout the remainder of this tutorial) are typically
178 178
 
non-profit charities (such as the FSF and Software Freedom Conservancy) who
179 179
 
declare, as part of their charitable mission, advancement of software freedom
180 180
 
for all users.  In the USA, these COGEOs are all classified as charitable
181 181
 
under the IRS's 501(c)(3) designation, which is reserved for organizations
182 182
 
that have a mission to enhance the public good.
183 183
 

	
184 184
 
As such, these COGEOs enforce GPL primarily to pursue the policy goals and
185 185
 
motivations discussed throughout this tutorial: to spread software freedom
186 186
 
further.  As such, COGEOs are unified in their primary goal to bring the
187 187
 
violator back into compliance as quickly as possible, and redress the damage
188 188
 
caused by the violation.  COGEOs are steadfast in their position in a
189 189
 
violation negotiation: comply with the license and respect freedom.
190 190
 

	
191 191
 
Certainly, other entities do not share the full ethos of software freedom as
192 192
 
institutionalized by COGEOs, and those entities pursue GPL violations
193 193
 
differently.  Oracle, a company that produces the GPL'd MySQL database, upon
194 194
 
discovering GPL violations typically negotiates a proprietary software
195 195
 
license separately for a fee.  While this practice is not one a COGEO would
196 196
 
undertake nor endorse, a copyleft license technically permits this
197 197
 
behavior.  To put a finer point on this practice already discussed
198 198
 
in~\S~\ref{Proprietary Relicensing}, copyleft advocates usually find copyleft
199 199
 
enforcement efforts focused on extract alternative proprietary licenses
200 200
 
distasteful at best, and a corrupt manipulation of copyleft at worst.  Much
201 201
 
to the advocates' chagrin, such for-profit enforcement efforts seem to
202 202
 
increase rather than decrease.
203 203
 

	
204 204
 
Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly
205 205
 
assume that all copyright holders seek royalties.  Businesses therefore focus
206 206
 
on the risk of so-called ``accidental'' (typically as the result of
207 207
 
unsupervised activity by individual programmers) infringe copyright by
208 208
 
incorporating ``snippets'' of copylefted code into their own proprietary
209 209
 
computer program.  ``Compliance industry'' flagship products, therefore,
210 210
 
focus on ``code scanning'' services that purport to detect accidental
211 211
 
inclusions.  Such effort focuses on proprietary software development and view
212 212
 
Free Software as a foreign interloper.  Such approach not only ignores
213 213
 
current reality that many companies build their products directly on major
214 214
 
copylefted projects (e.g., Android vendor's use of the kernel named Linux),
215 215
 
but also creates a culture of fear among developers, leading them into a
216 216
 
downward spiral of further hiding their necessary reliance on copylefted
217 217
 
software in the company's products.
218 218
 

	
219 219
 
Fortunately, COGEOs regard GPL compliance failures as an opportunity to
220 220
 
improve compliance.  Every compliance failure downstream represents a loss of
221 221
 
rights by their users. The COGEOs are the guardian of its users' and
222 222
 
developers' rights.  Their activity seeks to restore those rights, and
223 223
 
to protect the project's contributors' intentions in the making of their
224 224
 
software. 
225 225
 

	
226 226
 
\chapter{Best Practices to Avoid Common Violations}
227 227
 
\label{best-practices}
228 228
 

	
229 229
 
Unlike highly permissive licenses (such as the ISC license), which
230 230
 
typically only require preservation of copyright notices, licensees face many
231 231
 
important requirements from the GPL.  These requirements are
232 232
 
carefully designed to uphold certain values and standards of the software
233 233
 
freedom community.  While the GPL's requirements may initially appear
234 234
 
counter-intuitive to those more familiar with proprietary software
235 235
 
licenses, by comparison, its terms are in fact clear and quite favorable to
236 236
 
licensees.  Indeed, the GPL's terms actually simplify compliance when
237 237
 
violations occur.
238 238
 

	
239 239
 
GPL violations occur (or, are compounded) most often when companies lack sound
240 240
 
practices for the incorporation of GPL'd components into their
241 241
 
internal development environment.  This section introduces some best
242 242
 
practices for software tool selection, integration and distribution,
243 243
 
inspired by and congruent with software freedom methodologies.  Companies should
244 244
 
establish such practices before building a product based on GPL'd
245 245
 
software.\footnote{This document addresses compliance with GPLv2,
246 246
 
  GPLv3, LGPLv2, and LGPLv3.  Advice on avoiding the most common
247 247
 
  errors differs little for compliance with these four licenses.
248 248
 
  \S~\ref{lgpl} discusses the key differences between GPL and LGPL
249 249
 
  compliance.}
250 250
 

	
251 251
 
\section{Evaluate License Applicability}
252 252
 
\label{derivative-works}
253 253
 
Political discussion about the GPL often centers around determining the
254 254
 
``work'' that must be licensed under GPL, or in other words, ``what is the
255 255
 
derivative and/or combined work that was created''.  Nearly ever esoteric
256 256
 
question asked by lawyers seek to consider that question
257 257
 
\footnote{\tutorialpartsplit{In fact, a companion work, \textit{Detailed Analysis of the GNU GPL and Related
258 258
 
      Licenses} contains an entire section discussing derivative works}{This tutorial in fact
259 259
 
  also addresses the issue at length in~\S~\ref{derivative-works}}.} (perhaps because
260 260
 
that question explores exciting legal issues while the majority of the GPL
261 261
 
deals with much more mundane ones).
262 262
 
Of course, GPL was designed
263 263
 
primarily to embody the licensing feature of copyleft.
264 264
 

	
265 265
 
However, most companies who add
266 266
 
complex features to and make combinations with GPL'd software
267 267
 
are already well aware of their
268 268
 
more complex obligations under the license that require complex legal
269 269
 
analysis.  And, there are few companies overall that engage in such
270 270
 
activities. Thus,  in practical reality, this issue is not relevant to the vast
271 271
 
majority of companies distributing GPL'd software.
272 272
 

	
273 273
 
Thus, experienced  GPL enforcers find that few redistributors'
274 274
 
compliance challenges relate directly to combined work issues in copyleft.
275 275
 
Instead, the distributions of GPL'd
276 276
 
systems most often encountered typically consist of a full operating system
277 277
 
including components under the GPL (e.g., Linux, BusyBox) and components
278 278
 
under the LGPL (e.g., the GNU C Library).  Sometimes, these programs have
279 279
 
been patched or slightly improved by direct modification of their sources,
280 280
 
and thus the result is unequivocally a modified version.  Alongside these programs,
281 281
 
companies often distribute fully independent, proprietary programs,
282 282
 
developed from scratch, which are designed to run on the Free Software operating
283 283
 
system but do not combine with, link to, modify, derive from, or otherwise
284 284
 
create a combined work with
285 285
 
the GPL'd components.\footnote{However, these programs do often combine
286 286
 
  with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}
287 287
 
In the latter case, where the work is unquestionably a separate work of
288 288
 
creative expression, no copyleft provisions are invoked.
289 289
 
The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a
290 290
 
combined, derivative, and/or modified version of the work, but rather, issues related to distribution and
291 291
 
conveyance of binary works based on GPL'd source, but without Complete,
292 292
 
Corresponding Source.
293 293
 

	
294 294
 
As such, issues of software delivery are the primary frustration for GPL
295 295
 
enforcers. In particular, the following short list accounts for at least 95\%
296 296
 
of the GPL violations ever encountered:
297 297
 

	
298 298
 
\begin{itemize}
299 299
 

	
300 300
 
\item The violator fails to provide required information about the presence
301 301
 
  of copylefted programs and their applicable license terms in the product
302 302
 
  they have purchased.
303 303
 

	
304 304
 
\item The violator fails to reliably deliver \hyperref[CCS
305 305
 
  Definition]{complete, corresponding source} (CCS) for copylefted programs
306 306
 
  the violator knew were included (i.e., the CCS is either delivered but
307 307
 
  incomplete, or is not delivered at all).
308 308
 

	
309 309
 
\item Requestors are ignored when they communicate with violator's published
310 310
 
  addresses requesting fulfillment of businesses' obligations.
311 311
 
\end{itemize}
312 312
 

	
313 313
 
This tutorial therefore focuses primarily on these issue.
314 314
 
Admittedly, a tiny
315 315
 
minority of compliance situations relate to question of derivative,
316 316
 
combined, or modified versions of the work.  Those
317 317
 
situations are so rare, and the details from situation to situation differ
318 318
 
greatly.  Thus, such situations require a highly
319 319
 
fact-dependent analysis and cannot be addressed in a general-purpose
320 320
 
document such as this one.
321 321
 

	
322 322
 
\medskip
323 323
 

	
324 324
 
Most companies accused of violations lack a basic understanding
325 325
 
of how to comply even in the straightforward scenario.  This document
326 326
 
provides those companies with the fundamental and generally applicable prerequisite knowledge.
327 327
 
For answers to rarer and more complicated legal questions, such as whether
328 328
 
your software is a derivative or combined work of some copylefted software, consult
329 329
 
with an attorney.\footnote{If you would like more information on the
330 330
 
  application of derivative works doctrine to software, a detailed legal
331 331
 
  discussion is presented in our colleague Dan Ravicher's article,
332 332
 
  \textit{Software Derivative Work: A Circuit Dependent Determination} and in
333 333
 
  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
334 334
 
      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
335 335
 
    this tutorial}.}
336 336
 

	
337 337
 
This discussion thus assumes that you have already identified the
338 338
 
``work'' covered by the license, and that any components not under the GPL
339 339
 
(e.g., applications written entirely by your developers that merely happen
340 340
 
to run on a Linux-based operating system) distributed in conjunction with
341 341
 
those works are separate works within the meaning of copyright law and the GPL\@.  In
342 342
 
such a case, the GPL requires you to provide complete corresponding
343 343
 
source (CCS)\footnote{For more on CCS,  see
344 344
 
\tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
345 345
 
      Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of
346 346
 
    this tutorial}.}
347 347
 
for the GPL'd components and your modifications thereto, but not
348 348
 
for independent proprietary applications.  The procedures described in
349 349
 
this document address this typical scenario.
350 350
 

	
351 351
 

	
352 352
 
\section{Monitor Software Acquisition}
353 353
 

	
354 354
 
Software engineers deserve the freedom to innovate and import useful
355 355
 
software components to improve products.  However, along with that
356 356
 
freedom should come rules and reporting procedures to make sure that you
357 357
 
are aware of what software that you include with your product.
358 358
 

	
359 359
 
The most typical response to an initial enforcement action is: ``We
360 360
 
didn't know there was GPL'd stuff in there''.  This answer indicates
361 361
 
failure in the software acquisition and procurement process.  Integration
362 362
 
of third-party proprietary software typically requires a formal
363 363
 
arrangement and management/legal oversight before the developers
364 364
 
incorporate the software.  By contrast, developers often obtain and
365 365
 
integrate Free Software without intervention nor oversight. That ease of acquisition, however,
366 366
 
does not mean the oversight is any less necessary.  Just as your legal
367 367
 
and/or management team negotiates terms for inclusion of any proprietary
368 368
 
software, they should gently facilitate all decisions to bring Free Software into your
369 369
 
product.
370 370
 

	
371 371
 
Simple, engineering-oriented rules help provide a stable foundation for
372 372
 
Free Software integration.  For example, simply ask your software developers to send an email to a
373 373
 
standard place describing each new Free Software component they add to the system,
374 374
 
and have them include a brief description of how they will incorporate it
375 375
 
into the product.  Further, make sure developers use a revision control
376 376
 
system (such as Git or Mercurial), and
377 377
 
store the upstream versions of all software in a ``vendor branch'' or
378 378
 
similar mechanism, whereby they can easily track and find the main version
379 379
 
of the software and, separately, any local changes.
380 380
 

	
381 381
 
Such procedures are best instituted at your project's launch.  Once 
382 382
 
chaotic and poorly-sourced development processes begin, cataloging the
383 383
 
presence of GPL'd components  becomes challenging.
384 384
 

	
385 385
 
Such a situation often requires use of a tool to ``catch up'' your knowledge
386 386
 
about what software your product includes.  Most commonly, companies choose
387 387
 
some software licensing scanning tool to inspect the codebase.  However,
388 388
 
there are few tools that are themselves Free Software.  Thus, GPL enforcers
389 389
 
usually recommend the GPL'd
390 390
 
\href{http://fossology.org/}{FOSSology system}, which analyzes a
391 391
 
source code base and produces a list of Free Software licenses that may apply to
392 392
 
the code.  FOSSology can help you build a catalog of the sources you have
393 393
 
already used to build your product.  You can then expand that into a more
394 394
 
structured inventory and process.
395 395
 

	
396 396
 
\section{Track Your Changes and Releases}
397 397
 

	
398 398
 
As explained in further detail below, the most important component of GPL
399 399
 
compliance is the one most often ignored: proper inclusion of CCS in all
400 400
 
distributions  of GPL'd
401 401
 
software.  To comply with GPL's CCS requirements, the distributor
402 402
 
\textit{must} always know precisely what sources generated a given binary
403 403
 
distribution.
404 404
 

	
405 405
 
In an unfortunately large number of our enforcement cases, the violating
406 406
 
company's engineering team had difficulty reconstructing the CCS
407 407
 
for binaries distributed by the company.  Here are three simple rules to
408 408
 
follow to decrease the likelihood of this occurrence:
409 409
 

	
410 410
 
\begin{itemize}
411 411
 

	
412 412
 
\item Ensure that your
413 413
 
developers are using revision control systems properly.
414 414
 

	
415 415
 
\item Have developers mark or ``tag'' the full source tree corresponding to
416 416
 
  builds distributed to customers.
417 417
 

	
418 418
 
\item Check that your developers store all parts of the software
419 419
 
development in the revision control system, including {\sc readme}s, build
420 420
 
scripts, engineers' notes, and documentation.
421 421
 
\end{itemize}
422 422
 

	
423 423
 
Your developers will benefit anyway from these rules.  Developers will be
424 424
 
happier in their jobs if their tools already track the precise version of
425 425
 
source that corresponds to any deployed binary.
426 426
 

	
427 427
 
\section{Avoid the ``Build Guru''}
428 428
 

	
429 429
 
Too many software projects rely on only one or a very few team members who
430 430
 
know how to build and assemble the final released product.  Such knowledge
431 431
 
centralization not only creates engineering redundancy issues, but also
432 432
 
thwarts GPL compliance.  Specifically, CCS does not just require source code,
433 433
 
but scripts and other material that explain how to control compilation and
434 434
 
installation of the executable and object code.
435 435
 

	
436 436
 
Thus, avoid relying on a ``build guru'', a single developer who is the only one
437 437
 
who knows how to produce your final product. Make sure the build process
438 438
 
is well defined.  Train every developer on the build process for the final
439 439
 
binary distribution, including (in the case of embedded software)
440 440
 
generating a final firmware image suitable for distribution to the
441 441
 
customer.  Require developers to use revision control for build processes.
442 442
 
Make a rule that adding new components to the system without adequate
443 443
 
build instructions (or better yet, scripts) is unacceptable engineering
444 444
 
practice.
445 445
 

	
446 446
 
\chapter{Details of Compliant Distribution}
447 447
 

	
448 448
 
Distribution of GPL'd works has requirements; copyleft will not function
449 449
 
without placing requirements on redistribution.  However, some requirements
450 450
 
are more likely to cause compliance difficult than others.  This
451 451
 
chapter\footnote{Note that this chapter refers heavily to specific provisions
452 452
 
  and language in
453 453
 
  \hyperref[GPLv2s3-full-text]{GPLv2\S3}
454 454
 
  and \hyperref[GPLv3s6-full-text]{GPLv3\S6}.
455 455
 
  It may be helpful  to review \S~\ref{GPLv2s3} and \S~\ref{GPLv3s6} first,
456 456
 
  and then have a copy of each license open while reading this
457 457
 
  section.}  explains some the specific requirements placed upon
458 458
 
distributors of GPL'd software that redistributors are most likely to
459 459
 
overlook, yielding compliance problems.
460 460
 

	
461 461
 
First, \hyperref[GPLv2s1]{GPLv2\S1} and \hyperref[GPLv2s4]{GPLv2\S4} require
462 462
 
that the full license text must accompany every distribution (either in
463 463
 
source or binary form) of each licensed work.  Strangely, this requirement is
464 464
 
responsible for a surprisingly significant fraction of compliance errors; too
465 465
 
often, physical products lack required information about the presence of
466 466
 
GPL'd programs and the applicable license terms.  Automated build processes
467 467
 
can and should carry a copy of the license from the the source distribution
468 468
 
into the final binary firmware package for embedded products.  Such
469 469
 
automation usually achieves compliance regarding license inclusion
470 470
 
requirements\footnote{At least one COGEO recommends the
471 471
 
  \href{https://www.yoctoproject.org/}{Yocto Project}, since its engineers
472 472
 
  have designed such features into it build process.}
473 473
 

	
474 474
 
\section{Binary Distribution Permission}
475 475
 
\label{binary-distribution-permission}
476 476
 

	
477 477
 
% be careful below, you cannot refill the \if section, so don't refill
478 478
 
% this paragraph without care.
479 479
 

	
480 480
 
The various versions of the GPL are copyright licenses that grant
481 481
 
permission to make certain uses of software that are otherwise restricted
482 482
 
by copyright law.  This permission is conditioned upon compliance with the
483 483
 
GPL's requirements.
484 484
 

	
485 485
 
This section walks through the requirements (of both GPLv2 and GPLv3) that
486 486
 
apply when you distribute GPL'd programs in binary (i.e., executable or
487 487
 
object code) form, which is typical for embedded applications.  Because a
488 488
 
binary application derives from a program's original sources, you need
489 489
 
permission from the copyright holder to distribute it.  \S~3 of GPLv2 and
490 490
 
\S~6 of GPLv3 contain the permissions and conditions related to binary
491 491
 
distributions of GPL'd programs.\footnote{These sections cannot be fully
492 492
 
  understood in isolation; read the entire license thoroughly before
493 493
 
  focusing on any particular provision.  However, once you have read and
494 494
 
  understood the entire license, look to these sections to guide
495 495
 
  compliance for binary distributions.}  Failure to provide or offer CCS is the
496 496
 
single largest failure mode leading to compliance disputes.
497 497
 

	
498 498
 

	
499 499
 

	
500 500
 
GPL's binary distribution sections offer a choice of compliance methods,
501 501
 
each of which we consider in turn.  Each option refers to the
502 502
 
``Corresponding Source'' code for the binary distribution, which includes
503 503
 
the source code from which the binary was produced.  This abbreviated and
504 504
 
simplified definition is sufficient for the binary distribution discussion
505 505
 
in this section, but you may wish to refer back to this section after
506 506
 
reading the thorough discussion of ``Corresponding Source'' that appears
507 507
 
in \S~\ref{corresponding-source}.
508 508
 

	
509 509
 
\subsection{Option (a): Source Alongside Binary}
510 510
 

	
511 511
 
GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing
512 512
 
source code: including Corresponding Source with every binary
513 513
 
distribution.  While other options appear initially less onerous, this
514 514
 
option invariably minimizes potential compliance problems, because when
515 515
 
you distribute Corresponding Source with the binary, \emph{your GPL
516 516
 
  obligations are satisfied at the time of distribution}.  This is not
517 517
 
true of other options, and for this reason, we urge you to seriously
518 518
 
consider this option.  If you do not, you may extend the duration of your
519 519
 
obligations far beyond your last binary distribution.
520 520
 

	
521 521
 
Compliance under this option is straightforward.  If you ship a product
522 522
 
that includes binary copies of GPL'd software (e.g., in firmware, or on a
523 523
 
hard drive, CD, or other permanent storage medium), you can store the
524 524
 
Corresponding Source alongside the binaries.  Alternatively, you can
525 525
 
include the source on a CD or other removable storage medium in the box
526 526
 
containing the product.
527 527
 

	
528 528
 
GPLv2 refers to the various storage mechanisms as ``medi[a] customarily
529 529
 
used for software interchange''.  While the Internet has attained primacy
530 530
 
as a means of software distribution where super-fast Internet connections
531 531
 
are available, GPLv2 was written at a time when downloading software was
532 532
 
not practical (and was often impossible).  For much of the world, this
533 533
 
condition has not changed since GPLv2's publication, and the Internet
534 534
 
still cannot be considered ``a medium customary for software
535 535
 
interchange''.  GPLv3 clarifies this matter, requiring that source be
536 536
 
``fixed on a durable physical medium customarily used for software
537 537
 
interchange''.  This language affirms that option (a) requires binary
538 538
 
redistributors to provide source on a physical medium.
539 539
 

	
540 540
 
Please note that while selection of option (a) requires distribution on a
541 541
 
physical medium, voluntary distribution via the Internet is very useful.  This
542 542
 
is discussed in detail in \S~\ref{offer-with-internet}.
543 543
 

	
544 544
 
\subsection{Option (b): The Offer}
545 545
 
\label{offer-for-source}
546 546
 

	
547 547
 
Many distributors prefer to ship only an offer for source with the binary
548 548
 
distribution, rather than the complete source package.  This
549 549
 
option has value when the cost of source distribution is a true
550 550
 
per-unit cost.  For example, this option might be a good choice for
551 551
 
embedded products with permanent storage too small to fit the source, and
552 552
 
which are not otherwise shipped with a CD but \emph{are} shipped with a
553 553
 
manual or other printed material.
554 554
 

	
555 555
 
However, this option increases the duration of your obligations
556 556
 
dramatically.  An offer for source must be good for three full years from
557 557
 
your last binary distribution (under GPLv2), or your last binary or spare
558 558
 
part distribution (under GPLv3).  Your source code request and
559 559
 
provisioning system must be designed to last much longer than your product
560 560
 
life cycle. Thus, it also increases your compliance costs in the long
561 561
 
run.
562 562
 

	
563 563
 
In addition, if you are required to comply with the terms of GPLv2, you
564 564
 
{\bf cannot} use a network service to provide the source code.  For GPLv2,
565 565
 
the source code offer is fulfilled only with physical media.  This usually
566 566
 
means that you must continue to produce an up-to-date ``source code CD''
567 567
 
for years after the product's end-of-life.
568 568
 

	
569 569
 
\label{offer-with-internet}
570 570
 

	
571 571
 
Under GPLv2, it is acceptable and advisable for your offer for source code
572 572
 
to include an Internet link for downloadable source \emph{in addition} to
573 573
 
offering source on a physical medium.  This practice enables those with
574 574
 
fast network connections to get the source more quickly, and typically
575 575
 
decreases the number of physical media fulfillment requests.
576 576
 
(GPLv3~\S~6(b) permits provision of source with a public
577 577
 
network-accessible distribution only and no physical media.  We discuss
578 578
 
this in detail at the end of this section.)
579 579
 

	
580 580
 
The following is a suggested compliant offer for source under GPLv2 (and
581 581
 
is also acceptable for GPLv3) that you would include in your printed
582 582
 
materials accompanying each binary distribution:
583 583
 

	
584 584
 
\begin{quote}
585 585
 
The software included in this product contains copyrighted software that
586 586
 
is licensed under the GPL\@.  A copy of that license is included in this
587 587
 
document on page $X$\@.  You may obtain the complete Corresponding Source
588 588
 
code from us for a period of three years after our last shipment of this
589 589
 
product, which will be no earlier than 2011-08-01, by sending a money
590 590
 
order or check for \$5 to: \\
591 591
 
GPL Compliance Division \\
592 592
 
Our Company \\
593 593
 
Any Town, US 99999 \\
594 594
 
\\
595 595
 
Please write ``source for product $Y$'' in the memo line of your
596 596
 
payment.
597 597
 

	
598 598
 
You may also find a copy of the source at
599 599
 
\url{http://www.example.com/sources/Y/}.
600 600
 

	
601 601
 
This offer is valid to anyone in receipt of this information.
602 602
 
\end{quote}
603 603
 

	
604 604
 
There are a few important details about this offer.  First, it requires a
605 605
 
copying fee.  GPLv2 permits ``a charge no more than your cost of
606 606
 
physically performing source distribution''.  This fee must be reasonable.
607 607
 
If your cost of copying and mailing a CD is more than around \$10, you
608 608
 
should perhaps find a cheaper CD stock and shipment method.  It is simply
609 609
 
not in your interest to try to overcharge the community.  Abuse of this
610 610
 
provision in order to make a for-profit enterprise of source code
611 611
 
provision will likely trigger enforcement action.
612 612
 

	
613 613
 
Second, note that the last line makes the offer valid to anyone who
614 614
 
requests the source.  This is because v2~\S~3(b) requires that offers be
615 615
 
``to give any third party'' a copy of the Corresponding Source.  GPLv3 has
616 616
 
a similar requirement, stating that an offer must be valid for ``anyone
617 617
 
who possesses the object code''.  These requirements indicated in
618 618
 
v2~\S~3(c) and v3~\S~6(c) are so that noncommercial redistributors may
619 619
 
pass these offers along with their distributions.  Therefore, the offers
620 620
 
must be valid not only to your customers, but also to anyone who received
621 621
 
a copy of the binaries from them.  Many distributors overlook this
622 622
 
requirement and assume that they are only required to fulfill a request
623 623
 
from their direct customers.
624 624
 

	
625 625
 
The option to provide an offer for source rather than direct source
626 626
 
distribution is a special benefit to companies equipped to handle a
627 627
 
fulfillment process.  GPLv2~\S~3(c) and GPLv3~\S~6(c) avoid burdening
628 628
 
noncommercial, occasional redistributors with fulfillment request
629 629
 
obligations by allowing them to pass along the offer for source as they
630 630
 
received it.
631 631
 

	
632 632
 
Note that commercial redistributors cannot avail themselves of the option
633 633
 
(c) exception, and so while your offer for source must be good to anyone
634 634
 
who receives the offer (under v2) or the object code (under v3), it
635 635
 
\emph{cannot} extinguish the obligations of anyone who commercially
636 636
 
redistributes your product.  The license terms apply to anyone who
637 637
 
distributes GPL'd software, regardless of whether they are the original
638 638
 
distributor.  Take the example of Vendor $V$, who develops a software
639 639
 
platform from GPL'd sources for use in embedded devices.  Manufacturer $M$
640 640
 
contracts with $V$ to install the software as firmware in $M$'s device.
641 641
 
$V$ provides the software to $M$, along with a compliant offer for source.
642 642
 
In this situation, $M$ cannot simply pass $V$'s offer for source along to
643 643
 
its customers.  $M$ also distributes the GPL'd software commercially, so
644 644
 
$M$ too must comply with the GPL and provide source (or $M$'s \emph{own}
645 645
 
offer for source) to $M$'s customers.
646 646
 

	
647 647
 
This situation illustrates that the offer for source is often a poor
648 648
 
choice for products that your customers will likely redistribute.  If you
649 649
 
include the source itself with the products, then your distribution to
650 650
 
your customers is compliant, and their (unmodified) distribution to their
651 651
 
customers is likewise compliant, because both include source.  If you
652 652
 
include only an offer for source, your distribution is compliant but your
653 653
 
customer's distribution does not ``inherit'' that compliance, because they
654 654
 
have not made their own offer to accompany their distribution.
655 655
 

	
656 656
 
The terms related to the offer for source are quite different if you
657 657
 
distribute under GPLv3.  Under v3, you may make source available only over
658 658
 
a network server, as long as it is available to the general public and
659 659
 
remains active for three years from the last distribution of your product
660 660
 
or related spare part.  Accordingly, you may satisfy your fulfillment
661 661
 
obligations via Internet-only distribution.  This makes the ``offer for
662 662
 
source'' option less troublesome for v3-only distributions, easing
663 663
 
compliance for commercial redistributors.  However, before you switch to a
664 664
 
purely Internet-based fulfillment process, you must first confirm that you
665 665
 
can actually distribute \emph{all} of the software under GPLv3.  Some
666 666
 
programs are indeed licensed under ``GPLv2, \emph{or any later version}''
667 667
 
(often abbreviated ``GPLv2-or-later'').  Such licensing gives you the
668 668
 
option to redistribute under GPLv3.  However, a few popular programs are
669 669
 
only licensed under GPLv2 and not ``or any later version''
670 670
 
(``GPLv2-only'').  You cannot provide only Internet-based source request
671 671
 
fulfillment for the latter programs.
672 672
 

	
673 673
 
If you determine that all GPL'd works in your whole product allow upgrade
674 674
 
to GPLv3 (or were already GPLv3'd to start), your offer for source may be
675 675
 
as simple as this:
676 676
 

	
677 677
 
\begin{quote}
678 678
 
The software included in this product contains copyrighted software that
679 679
 
is licensed under the GPLv3\@.  A copy of that license is included in this
680 680
 
document on page $X$\@.  You may obtain the complete Corresponding Source
681 681
 
code from us for a period of three years after our last shipment of this
682 682
 
product and/or spare parts therefor, which will be no earlier than
683 683
 
2011-08-01, on our website at
684 684
 
\url{http://www.example.com/sources/productnum/}.
685 685
 
\end{quote}
686 686
 

	
687 687
 
\medskip
688 688
 

	
689 689
 
Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of
690 690
 
the license itself, either electronically or in print, with every
691 691
 
distribution.
692 692
 
 
693 693
 
Finally, it is unacceptable to use option (b) merely because you do not have
694 694
 
Corresponding Source ready.  We find that some companies choose this option
695 695
 
because writing an offer is easy, but producing a source distribution as
696 696
 
an afterthought to a hasty development process is difficult.  The offer
697 697
 
for source does not exist as a stop-gap solution for companies rushing to
698 698
 
market with an out-of-compliance product.  If you ship an offer for source
699 699
 
with your product but cannot actually deliver \emph{immediately} on that
700 700
 
offer when your customers request it, you should expect an enforcement
701 701
 
action.
702 702
 

	
703 703
 
\subsection{Option (c): Noncommercial Offers}
704 704
 

	
705 705
 
As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply
706 706
 
only to noncommercial use.  These options are not available to businesses
707 707
 
distributing GPL'd software.  Consequently, companies that redistribute
708 708
 
software packaged for them by an upstream vendor cannot merely pass along
709 709
 
the offer they received from the vendor; they must provide their own offer
710 710
 
or corresponding source to their distributees.  We talk in detail about
711 711
 
upstream software providers in \S~\ref{upstream}.
712 712
 

	
713 713
 
\subsection{Option 6(d) in GPLv3: Internet Distribution}
714 714
 

	
715 715
 
Under GPLv2, your formal provisioning options for Corresponding Source
716 716
 
ended with \S~3(c).  But even under GPLv2, pure Internet source
717 717
 
distribution was a common practice and generally considered to be
718 718
 
compliant.  GPLv2 mentions Internet-only distribution almost as aside in
719 719
 
the language, in text at the end of the section after the three
720 720
 
provisioning options are listed.  To quote that part of GPLv2~\S~3:
721 721
 
\begin{quote}
722 722
 
If distribution of executable or object code is made by offering access to
723 723
 
copy from a designated place, then offering equivalent access to copy the
724 724
 
source code from the same place counts as distribution of the source code,
725 725
 
even though third parties are not compelled to copy the source along with
726 726
 
the object code.
727 727
 
\end{quote}
728 728
 

	
729 729
 
When that was written in 1991, Internet distribution of software was the
730 730
 
exception, not the rule.  Some FTP sites existed, but generally software
731 731
 
was sent on magnetic tape or CDs.  GPLv2 therefore mostly assumed that
732 732
 
binary distribution happened on some physical media.  By contrast,
733 733
 
GPLv3~\S~6(d) explicitly gives an option for this practice that the
734 734
 
community has historically considered GPLv2-compliant.
735 735
 

	
736 736
 
Thus, you may fulfill your source-provision obligations by providing the
737 737
 
source code in the same way and from the same location.  When exercising
738 738
 
this option, you are not obligated to ensure that users download the
739 739
 
source when they download the binary, and you may use separate servers as
740 740
 
needed to fulfill the requests as long as you make the source as
741 741
 
accessible as the binary.  However, you must ensure that users can easily
742 742
 
find the source code at the time they download the binary. GPLv3~\S~6(d)
743 743
 
thus clarifies a point that has caused confusion about source provision in
744 744
 
v2.  Indeed, many such important clarifications are included in v3 which
745 745
 
together provide a compelling reason for authors and redistributors alike
746 746
 
to adopt GPLv3.
747 747
 

	
748 748
 
\subsection{Option 6(e) in GPLv3: Software Torrents}
749 749
 

	
750 750
 
Peer-to-peer file sharing arose well after GPLv2 was written, and does not
751 751
 
easily fit any of the v2 source provision options.  GPLv3~\S~6(e)
752 752
 
addresses this issue, explicitly allowing for distribution of source and
753 753
 
binary together on a peer-to-peer file sharing network.  If you distribute
754 754
 
solely via peer-to-peer networks, you can exercise this option.  However,
755 755
 
peer-to-peer source distribution \emph{cannot} fulfill your source
756 756
 
provision obligations for non-peer-to-peer binary distributions.  Finally,
757 757
 
you should ensure that binaries and source are equally seeded upon initial
758 758
 
peer-to-peer distribution.
759 759
 

	
760 760
 
\section{Preparing Corresponding Source}
761 761
 
\label{corresponding-source}
762 762
 

	
763 763
 
Most enforcement cases involve companies that have unfortunately not
764 764
 
implemented procedures like our \S~\ref{best-practices} recommendations
765 765
 
and have no source distribution arranged at all.  These companies must
766 766
 
work backwards from a binary distribution to come into compliance.  Our
767 767
 
recommendations in \S~\ref{best-practices} are designed to make it easy to
768 768
 
construct a complete and Corresponding Source release from the outset.  If
769 769
 
you have followed those principles in your development, you can meet the
770 770
 
following requirements with ease.  If you have not, you may have
771 771
 
substantial reconstruction work to do.
772 772
 

	
773 773
 
\subsection{Assemble the Sources}
774 774
 

	
775 775
 
For every binary that you produce, you should collect and maintain a copy
776 776
 
of the sources from which it was built.  A large system, such as an
777 777
 
embedded firmware, will probably contain many GPL'd and LGPL'd components
778 778
 
for which you will have to provide source.  The binary distribution may
779 779
 
also contain proprietary components which are separate and independent
780 780
 
works that are covered by neither the GPL nor LGPL\@.
781 781
 

	
782 782
 
The best way to separate out your sources is to have a subdirectory for
783 783
 
each component in your system.  You can then easily mark some of them as
784 784
 
required for your Corresponding Source releases.  Collecting
785 785
 
subdirectories of GPL'd and LGPL'd components is the first step toward
786 786
 
preparing your release.
787 787
 

	
788 788
 
\subsection{Building the Sources}
789 789
 

	
790 790
 
Few distributors, particularly of embedded systems, take care to read the
791 791
 
actual definition of Corresponding Source in the GPL\@.  Consider
792 792
 
carefully the definition, from GPLv3:
793 793
 
\begin{quote}
794 794
 
  The ``Corresponding Source'' for a work in object code form means all
795 795
 
  the source code needed to generate, install, and (for an executable
796 796
 
  work) run the object code and to modify the work, including scripts to
797 797
 
  control those activities.
798 798
 
\end{quote}
799 799
 

	
800 800
 
and the definition from GPLv2:
801 801
 
\begin{quote}
802 802
 
The source code for a work means the preferred form of the work for making
803 803
 
modifications to it.  For an executable work, complete source code means
804 804
 
all the source code for all modules it contains, plus any associated
805 805
 
interface definition files, plus the scripts used to control compilation
806 806
 
and installation of the executable.
807 807
 
\end{quote}
808 808
 

	
809 809
 
Note that you must include ``scripts used to control compilation and
810 810
 
installation of the executable'' and/or anything ``needed to generate,
811 811
 
install, and (for an executable work) run the object code and to modify
812 812
 
the work, including scripts to control those activities''.  These phrases
813 813
 
are written to cover different types of build environments and systems.
814 814
 
Therefore, the details of what you need to provide with regard to scripts
815 815
 
and installation instructions vary depending on the software details.  You
816 816
 
must provide all information necessary such that someone generally skilled
817 817
 
with computer systems could produce a binary similar to the one provided.
818 818
 

	
819 819
 
Take as an example an embedded wireless device.  Usually, a company
820 820
 
distributes a firmware, which includes a binary copy of
821 821
 
Linux\footnote{``Linux'' refers only to the kernel, not the larger system
822 822
 
  as a whole.} and a filesystem.  That filesystem contains various binary
823 823
 
programs, including some GPL'd binaries, alongside some proprietary
824 824
 
binaries that are separate works (i.e., not derived from, nor based on
825 825
 
freely-licensed sources).  Consider what, in this case, constitutes adequate
826 826
 
``scripts to control compilation and installation'' or items ``needed to
827 827
 
generate, install and run'' the GPL'd programs.
828 828
 

	
829 829
 
Most importantly, you must provide some sort of roadmap that allows
830 830
 
technically sophisticated users to build your software.  This can be
831 831
 
complicated in an embedded environment.  If your developers use scripts to
832 832
 
control the entire compilation and installation procedure, then you can
833 833
 
simply provide those scripts to users along with the sources they act
834 834
 
upon.  Sometimes, however, scripts were never written (e.g., the
835 835
 
information on how to build the binaries is locked up in the mind of your
836 836
 
``build guru'').  In that case, we recommend that you write out build
837 837
 
instructions in a natural language as a detailed, step-by-step {\sc
838 838
 
  readme}.
839 839
 

	
840 840
 
No matter what you offer, you need to give those who receive source a
841 841
 
clear path from your sources to binaries similar to the ones you ship.  If
842 842
 
you ship a firmware (kernel plus filesystem), and the filesystem contains
843 843
 
binaries of GPL'd programs, then you should provide whatever is necessary
844 844
 
to enable a reasonably skilled user to build any given GPL'd source
845 845
 
program (and modified versions thereof), and replace the given binary in
846 846
 
your filesystem.  If the kernel is Linux, then the users must have the
847 847
 
instructions to do the same with the kernel.  The best way to achieve this
848 848
 
is to make available to your users whatever scripts or process your
849 849
 
engineers would use to do the same.
850 850
 

	
851 851
 
These are the general details for how installation instructions work.
852 852
 
Details about what differs when the work is licensed under LGPL is
853 853
 
discussed in \S~\ref{lgpl}, and specific details that are unique to
854 854
 
GPLv3's installation instructions are in \S~\ref{user-products}.
855 855
 

	
856 856
 
\subsection{What About the Compiler?}
857 857
 

	
858 858
 
The GPL contains no provision that requires distribution of the compiler
859 859
 
used to build the software.  While companies are encouraged to make it as
860 860
 
easy as possible for their users to build the sources, inclusion of the
861 861
 
compiler itself is not normally considered mandatory.  The Corresponding
862 862
 
Source definition -- both in GPLv2 and GPLv3 -- has not been typically
863 863
 
read to include the compiler itself, but rather things like makefiles,
864 864
 
build scripts, and packaging scripts.
865 865
 

	
866 866
 
Nonetheless, in the interest of goodwill and the spirit of the GPL, most
867 867
 
companies do provide the compiler itself when they are able, particularly
868 868
 
when the compiler is based on GCC\@ or another copylefted compiler.  If you have
869 869
 
a GCC-based system, it is your prerogative to redistribute that GCC
870 870
 
version (binaries plus sources) to your customers.  We in the software freedom
871 871
 
community encourage you to do this, since it often makes it easier for
872 872
 
users to exercise their software freedom.  However, if you chose to take
873 873
 
this recommendation, ensure that your GCC distribution is itself
874 874
 
compliant.
875 875
 

	
876 876
 
If you have used a proprietary, third-party compiler to build the
877 877
 
software, then you probably cannot ship it to your customers.  We consider
878 878
 
the name of the compiler, its exact version number, and where it can be
879 879
 
acquired as information that \emph{must} be provided as part of the
880 880
 
Corresponding Source.  This information is essential to anyone who wishes
881 881
 
to produce a binary.  It is not the intent of the GPL to require you to
882 882
 
distribute third-party software tools to your customer (provided the tools
883 883
 
themselves are not based on the GPL'd software shipped), but we do believe
884 884
 
it requires that you give the user all the essential non-proprietary facts
885 885
 
that you had at your disposal to build the software.  Therefore, if you
886 886
 
choose not to distribute the compiler, you should include a {\sc readme}
887 887
 
about where you got it, what version it was, and who to contact to acquire
888 888
 
it, regardless of whether your compiler is Free Software, proprietary, or
889 889
 
internally developed.
890 890
 

	
891 891
 
\section{Best Practices and Corresponding Source}
892 892
 

	
893 893
 
\S~\ref{best-practices} and \S~\ref{corresponding-source} above are
894 894
 
closely related.  If you follow the best practices outlined above, you
895 895
 
will find that preparing your Corresponding Source release is an easier
896 896
 
task, perhaps even a trivial one.
897 897
 

	
898 898
 
Indeed, the enforcement process itself has historically been useful to
899 899
 
software development teams.  Development on a deadline can lead
900 900
 
organizations to cut corners in a way that negatively impacts its
901 901
 
development processes.  We have frequently been told by violators that
902 902
 
they experience difficulty when determining the exact source for a binary
903 903
 
in production (in some cases because their ``build guru'' quit during the
904 904
 
release cycle).  When management rushes a development team to ship a
905 905
 
release, they are less likely to keep release sources tagged and build
906 906
 
systems well documented.
907 907
 

	
908 908
 
We suggest that, if contacted about a violation, product builders use GPL
909 909
 
enforcement as an opportunity to improve their development practices.  No
910 910
 
developer would argue that their system is better for having a mysterious
911 911
 
build system and no source tracking.  Address these issues by installing a
912 912
 
revision system, telling your developers to use it, and requiring your
913 913
 
build guru to document his or her work!
914 914
 

	
915 915
 

	
916 916
 
\section{Non-Technical Compliance Issues}
917 917
 

	
918 918
 
Certainly, the overwhelming majority of compliance issues are, in fact,
919 919
 
either procedural or technical.  Thus, the primary material in this chapter
920 920
 
so far has covered those issues.  However, a few compliance issues do require
921 921
 
more direct consideration of a legal situation.  This portion guide does not
922 922
 
consider those in detail, as a careful reading of the earlier chapters of
923 923
 
Part~\ref{gpl-lgpl-part} shows various places where legal considerations are
924 924
 
necessary for considering compliance activity.
925 925
 

	
926 926
 
For example, specific compliance issues related to
927 927
 
\hyperref[GPLv2s7]{GPLv2\S7}, \hyperref[GPLv3s7]{GPLv3\S7}, and
928 928
 
\hyperref[GPLv3s7]{GPLv3\S11} demand a more traditional approach to legal
929 929
 
license compliance.  Of course, such analysis and consideration can be
930 930
 
complicated, and some are considered in the enforcement case studies that
931 931
 
follow in the next part.  However, compliance issues related to such sections
932 932
 
are not rare, and, as is typical, no specific training is available for
933 933
 
dealing with extremely rare occurrences.
934 934
 

	
935 935
 
\section{Self-Assessment of Compliance}
936 936
 

	
937 937
 
Most companies that adopt copylefted software believe they have complied.
938 938
 
Humans usually have difficult admitting their own mistakes, particularly
939 939
 
systematic ones.  Therefore, perhaps the most important necessary step to
940 940
 
stay in compliance is a company's regular evaluation of their own compliance.
941 941
 

	
942 942
 
First, exercise a request CCS for all copylefted works from all your upstream
943 943
 
providers of software and of components embedding software.  Then, perform
944 944
 
your own CCS check on this material first, and verify that it meets the
945 945
 
requirements.  This tutorial presents later a case study of a COGEO's CCS
946 946
 
check in \S~\ref{pristine-example}, which you can emulate when examining
947 947
 
their own CCS\@.
948 948
 

	
949 949
 
Second, measure all copyleft compliance from the position of the
950 950
 
users\footnote{Realizing of course that user very well may not be your own
951 951
 
  customer.} downstream from you exercising their rights under GPL\@.  Have
952 952
 
those users received notice of the copylefted software included in your
953 953
 
product?  Is CCS available to the users easily (preferably by automated
954 954
 
means)?  Ask yourself these questions frequently.  If you cannot answer these
955 955
 
questions with certainty in the positive, dig deeper and modify your process.
956 956
 

	
957 957
 
Avoid ``compliance industry'' marketing distractions and concentrate on the
958 958
 
copylefted software you already know is in your product.  Historically, the
959 959
 
risk from a copylefted code snippet that some programmer dropped in your
960 960
 
proprietary product careless of the consequences is a problem far more
961 961
 
infrequent and less difficult to resolve.  Efficient management of the risks
962 962
 
of higher concern lies in making sure you can provide, for example, precisely
963 963
 
CCS for a copy of Coreboot, the kernel named Linux, BusyBox, or GNU tar that
964 964
 
you included in a product your company shipped two years ago than in the risk
965 965
 
of 10 lines of GPL'd Java code an engineer accidentally pasted into the
966 966
 
source of your ERP system.
967 967
 

	
968 968
 
Thus, reject the ``compliance industry'' suggestions that code scanners find
969 969
 
and help solve fundamental compliance problems.  Consider how COGEO's tend to
970 970
 
use code scanners.  FOSSology is indeed an important part of a violation
971 971
 
investigation, but such is the last step and catches only some (usually
972 972
 
minor) licensing notice problems.  Thus, code scanners can help solve minor
973 973
 
compliance problems once you have resolved the major ones.  Code scanners
974 974
 
do not manage risk.
975 975
 

	
976 976
 
\chapter{When The Letter Comes}
977 977
 

	
978 978
 
Unfortunately, many GPL violators ignore their obligations until they are
979 979
 
contacted by a copyright holder or the lawyer of a copyright holder.  You
980 980
 
should certainly contact your own lawyer if you have received a letter
981 981
 
alleging that you have infringed copyrights that were licensed to you
982 982
 
under the GPL\@.  This section outlines a typical enforcement case and
983 983
 
provides some guidelines for response.  These discussions are
984 984
 
generalizations and do not all apply to every alleged violation.  However,
985 985
 
COGEO's in particular universally follow the processes described herein.
986 986
 

	
987 987
 
\section{Communication Is Key}
988 988
 

	
989 989
 
GPL violations are typically only escalated when a company ignores the
990 990
 
copyright holder's initial communication or fails to work toward timely
991 991
 
compliance.  Accused violators should respond very promptly to the
992 992
 
initial request.  As the process continues, violators should follow up weekly with the
993 993
 
copyright holders to make sure everyone agrees on targets and deadlines
994 994
 
for resolving the situation.
995 995
 

	
996 996
 
Ensure that any staff who might receive communications regarding alleged
997 997
 
GPL violations understands how to channel the communication appropriately
998 998
 
within your organization.  Often, initial contact is addressed for general
999 999
 
correspondence (e.g., by mail to corporate headquarters or by e-mail to
1000 1000
 
general informational or support-related addresses).  Train the staff that
1001 1001
 
processes such communications to escalate them to someone with authority
1002 1002
 
to take action.  An uninformed response to such an inquiry (e.g., from
1003 1003
 
a first-level technical support person) can cause negotiations to fail
1004 1004
 
prematurely.
1005 1005
 

	
1006 1006
 
Answer promptly by multiple means (paper letter, telephone call, and
1007 1007
 
email), even if your response merely notifies the sender that you are
1008 1008
 
investigating the situation and will respond by a certain date.  Do not
1009 1009
 
let the conversation lapse until the situation is fully resolved.
1010 1010
 
Proactively follow up with synchronous communication means to be sure
1011 1011
 
communications sent by non-reliable means (such as email) were received.
1012 1012
 

	
1013 1013
 
Remember that the software freedom community generally values open communication and
1014 1014
 
cooperation, and these values extend to GPL enforcement.  You will
1015 1015
 
generally find that software freedom developers and their lawyers are willing to
1016 1016
 
have a reasonable dialogue and will work with you to resolve a violation
1017 1017
 
once you open the channels of communication in a friendly way.
1018 1018
 

	
1019 1019
 
Furthermore, if the complaint comes from a COGEO, assume they are
1020 1020
 
well-prepared.  COGEO's fully investigate compliance issues before raising
1021 1021
 
the issue.  The claims and concerns will be substantiated, and immediate
1022 1022
 
denials will likely lead the COGEO to suspect malice rather than honest
1023 1023
 
mistake.
1024 1024
 

	
1025 1025
 
However, the biggest and most perennial mistake that all COGEOs see during
1026 1026
 
enforcement is this: failure to include the violators' software development
1027 1027
 
teams in the enforcement discussions and negotiations.  As described above,
1028 1028
 
CCS verification and approval is the most time-consuming and difficult part
1029 1029
 
of resolving most compliance matters.  Without direct contact between
1030 1030
 
software developers on both sides, the resolution of the technical issues
1031 1031
 
involved in demonstrating that the binary distributed was built from the
1032 1032
 
source provided is likely to be tortuous, expensive, and tense. Your lawyers
1033 1033
 
will certainly be understandably reluctant to expose your employees to direct
1034 1034
 
inquiry from potentially adverse parties.  However, facilitated exchanges of
1035 1035
 
information among software engineers communicating on technical subjects
1036 1036
 
shortens the time to resolution, substantially reduces the cost of reaching
1037 1037
 
resolution, and prevents unnecessary escalation due to mutual
1038 1038
 
misunderstanding.  Furthermore, such frank technical discussion will often be
1039 1039
 
the only way to avoid compliance litigation once a violation has occurred.
1040 1040
 

	
1041 1041
 
Fortunately, these frank discussions will improve your company's
1042 1042
 
relationships.  Free Software development communities improve software to
1043 1043
 
benefit everyone, which includes you and your company.  When you use
1044 1044
 
copylefted community software in your products, you are part of that
1045 1045
 
community.  Therefore, resolving a compliance matter is an occasion to
1046 1046
 
strengthen your relationship to the community, by increasing communication
1047 1047
 
between your developers and the project whose work you use for business
1048 1048
 
benefit.
1049 1049
 

	
1050 1050
 
\section{Termination}
1051 1051
 

	
1052 1052
 
Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and
1053 1053
 
GPLv3~\S~8).  Under v2, violators forfeit their rights to redistribute and
1054 1054
 
modify the GPL'd software until those rights are explicitly reinstated by
1055 1055
 
the copyright holder.  In contrast, v3 allows violators to rapidly resolve
1056 1056
 
some violations without consequence.
1057 1057
 

	
1058 1058
 
If you have redistributed an application under GPLv2\footnote{This applies
1059 1059
 
  to all programs licensed to you under only GPLv2 (``GPLv2-only'').
1060 1060
 
  However, most so-called GPLv2 programs are actually distributed with
1061 1061
 
  permission to redistribute under GPLv2 \emph{or any later version of the
1062 1062
 
    GPL} (``GPLv2-or-later'').  In the latter cases, the redistributor can
1063 1063
 
  choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even
1064 1064
 
  GPLv3-or-later.  Where the redistributor has chosen v2 explicitly, the
1065 1065
 
  v2 termination provision will always apply.  If the redistributor has
1066 1066
 
  chosen v3, the v3 termination provision will always apply.  If the
1067 1067
 
  redistributor has chosen GPLv2-or-later, then the redistributor may want
1068 1068
 
  to narrow to GPLv3-only upon violation, to take advantage of the
1069 1069
 
  termination provisions in v3.}, but have violated the terms of GPLv2,
1070 1070
 
you must request a reinstatement of rights from the copyright holders
1071 1071
 
before making further distributions, or else cease distribution and
1072 1072
 
modification of the software forever.  Different copyright holders
1073 1073
 
condition reinstatement upon different requirements, and these
1074 1074
 
requirements can be (and often are) wholly independent of the GPL\@.  The
1075 1075
 
terms of your reinstatement will depend upon what you negotiate with the
1076 1076
 
copyright holder of the GPL'd program.
1077 1077
 

	
1078 1078
 
Since your rights under GPLv2 terminate automatically upon your initial
1079 1079
 
violation, \emph{all your subsequent distributions} are violations and
1080 1080
 
infringements of copyright.  Therefore, even if you resolve a violation on
1081 1081
 
your own, you must still seek a reinstatement of rights from the copyright
1082 1082
 
holders whose licenses you violated, lest you remain liable for
1083 1083
 
infringement for even compliant distributions made subsequent to the
1084 1084
 
initial violation.
1085 1085
 

	
1086 1086
 
GPLv3 is more lenient.  If you have distributed only v3-licensed programs,
1087 1087
 
you may be eligible under v3~\S~8 for automatic reinstatement of rights.
1088 1088
 
You are eligible for automatic reinstatement when:
1089 1089
 
\begin{itemize}
1090 1090
 
\item you correct the violation and are not contacted by a copyright
1091 1091
 
  holder about the violation within sixty days after the correction, or
1092 1092
 

	
1093 1093
 
\item you receive, from a copyright holder, your first-ever contact
1094 1094
 
  regarding a GPL violation, and you correct that violation within thirty
1095 1095
 
  days of receipt of copyright holder's notice.
1096 1096
 
\end{itemize}
1097 1097
 

	
1098 1098
 
In addition to these permanent reinstatements provided under v3, violators
1099 1099
 
who voluntarily correct their violation also receive provisional
1100 1100
 
permission to continue distributing until they receive contact from the
1101 1101
 
copyright holder.  If sixty days pass without contact, that reinstatement
1102 1102
 
becomes permanent.  Nonetheless, you should be prepared to cease
1103 1103
 
distribution during those initial sixty days should you receive a
1104 1104
 
termination notice from the copyright holder.
1105 1105
 

	
1106 1106
 
Given that much discussion of v3 has focused on its so-called more
1107 1107
 
complicated requirements, it should be noted that v3 is, in this regard,
1108 1108
 
more favorable to violators than v2.
1109 1109
 

	
1110 1110
 
However, note that most Linux-based systems typically include some software
1111 1111
 
licensed under GPLv2-only, and thus the copyright holders have withheld
1112 1112
 
permission to redistribute under terms of GPLv3.  In larger aggregate
1113 1113
 
distributions which include GPLv2-only works (such as the kernel named
1114 1114
 
Linux), redistributors must operate as if termination is immediate and
1115 1115
 
permanent, since the technological remove of GPLv2-only works from the larger
1116 1116
 
distribution requires much more engineering work than the negotiation
1117 1117
 
required to seek restoration of rights for distribution under GPLv2-only
1118 1118
 
after permanent termination.
1119 1119
 

	
1120 1120
 
\chapter{Standard Requests}
1121 1121
 
\label{enforcement-standard-requests}
1122 1122
 

	
1123 1123
 
As we noted above, different copyright holders have different requirements
1124 1124
 
for reinstating a violator's distribution rights.  Upon violation, you no
1125 1125
 
longer have a license under the GPL\@.  Copyright holders can therefore
1126 1126
 
set their own requirements outside the license before reinstatement of
1127 1127
 
rights.  We have collected below a list of reinstatement demands that
1128 1128
 
copyright holders often require.
1129 1129
 

	
1130 1130
 
\begin{itemize}
1131 1131
 

	
1132 1132
 
\item {\bf Compliance on all Free Software copyrights}.  Copyright holders of Free Software
1133 1133
 
  often want a company to demonstrate compliance for all GPL'd software in
1134 1134
 
  a distribution, not just their own.  A copyright holder may refuse to
1135 1135
 
  reinstate your right to distribute one program unless and until you
1136 1136
 
  comply with the licenses of all Free Software in your distribution.
1137 1137
 
 
1138 1138
 
\item {\bf Notification to past recipients}.  Users to whom you previously
1139 1139
 
  distributed non-compliant software should receive a communication
1140 1140
 
  (email, letter, bill insert, etc.) indicating the violation, describing
1141 1141
 
  their rights under the GPL, and informing them how to obtain a gratis source
1142 1142
 
  distribution.  If a customer list does not exist (such as in reseller
1143 1143
 
  situations), an alternative form of notice may be required (such as a
1144 1144
 
  magazine advertisement).
1145 1145
 

	
1146 1146
 
\item {\bf Appointment of a GPL Compliance Officer.}  The software freedom community
1147 1147
 
  values personal accountability when things go wrong.  Copyright holders
1148 1148
 
  often require that you name someone within the violating company
1149 1149
 
  officially responsible for Free Software license compliance, and that this
1150 1150
 
  individual serve as the key public contact for the community when
1151 1151
 
  compliance concerns arise.
1152 1152
 

	
1153 1153
 
\item {\bf Periodic Compliance Reports.}  Many copyright holders wish to
1154 1154
 
  monitor future compliance for some period of time after the violation.
1155 1155
 
  For some period, your company may be required to send regular reports on
1156 1156
 
  how many distributions of binary and source have occurred.
1157 1157
 
\end{itemize}
1158 1158
 

	
1159 1159
 
These are just a few possible requirements for reinstatement.  In the
1160 1160
 
context of a GPL violation, and particularly under v2's termination
1161 1161
 
provision, the copyright holder may have a range of requests in exchange
1162 1162
 
for reinstatement of rights.  These software developers are talented
1163 1163
 
professionals from whose work your company has benefited.  Indeed, you are
1164 1164
 
unlikely to find a better value or more generous license terms for similar
1165 1165
 
software elsewhere.  Treat the copyright holders with the same respect you
1166 1166
 
treat your corporate partners and collaborators.
1167 1167
 

	
1168 1168
 
\chapter{Special Topics in Compliance}
1169 1169
 

	
1170 1170
 
There are several other issues that are less common, but also relevant in
1171 1171
 
a GPL compliance situation.  To those who face them, they tend to be of
1172 1172
 
particular interest.
1173 1173
 

	
1174 1174
 
\section{LGPL Compliance}
1175 1175
 
\label{lgpl}
1176 1176
 

	
1177 1177
 
GPL compliance and LGPL compliance mostly involve the same issues.  As we
1178 1178
 
discussed in \S~\ref{derivative-works}, questions of modified versions of
1179 1179
 
software are highly fact-dependent and cannot be easily addressed in any
1180 1180
 
overview document.  The LGPL adds some additional complexity to the
1181 1181
 
analysis.  Namely, the various LGPL versions permit proprietary licensing
1182 1182
 
of certain types of modified versions.  These issues are discussed in greater
1183 1183
 
detail in Chapter~\ref{LGPLv2} and~\ref{LGPLv3}.  However, as a rule of thumb, once you have determined
1184 1184
 
(in accordance with LGPLv3) what part of the work is the ``Application''
1185 1185
 
and what portions of the source are ``Minimal Corresponding Source'', then
1186 1186
 
you can usually proceed to follow the GPL compliance rules that
1187 1187
 
discussed above, replacing our discussion of ``Corresponding Source'' with
1188 1188
 
``Minimal Corresponding Source''.
1189 1189
 

	
1190 1190
 
LGPL also requires that you provide a mechanism to combine the Application
1191 1191
 
with a modified version of the library, and outlines some options for
1192 1192
 
this.  Also, the license of the whole work must permit ``reverse
1193 1193
 
engineering for debugging such modifications'' to the library.  Therefore,
1194 1194
 
you should take care that the EULA used for the Application does not
1195 1195
 
contradict this permission.
1196 1196
 

	
1197 1197
 
Thus, under the terms of LGPL, you must refrain from license terms on works
1198 1198
 
based on the licensed work that prohibit replacement of the licensed
1199 1199
 
components of the larger non-LGPL'd work, or prohibit decompilation or
1200 1200
 
reverse engineering in order to enhance or fix bugs in the LGPL'd components.
1201 1201
 

	
1202 1202
 
LGPLv3 is not surprisingly easier to understand and examine from a compliance
1203 1203
 
lens, since the FSF was influenced in LGPLv3's drafting by questions and
1204 1204
 
comments on LGPLv2.1 over a period of years.  Admittedly, LGPLv2.1 is still
1205 1205
 
in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you
1206 1206
 
may encounter.  The best advice there is careful study of
1207 1207
 
Chapter~\ref{LGPLv2}.
1208 1208
 

	
1209 1209
 
However, to repeat a key point here made within that chapter: Note though
1210 1210
 
that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the
1211 1211
 
worst case you simply need to comply as if the software was licensed under
1212 1212
 
GPLv2.  The only reason you must consider the question of whether you have a
1213 1213
 
``work that uses the library'' or a ``work based on the library'' is when you
1214 1214
 
wish to take advantage of the ``weak copyleft'' effect of the Lesser GPL\@.
1215 1215
 
If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the
1216 1216
 
entire work anyway), you may find this an easier option.
1217 1217
 

	
1218 1218
 
\section{Upstream Providers}
1219 1219
 
\label{upstream}
1220 1220
 

	
1221 1221
 
With ever-increasing frequency, software development (particularly for
1222 1222
 
embedded devices) is outsourced to third parties.  If you rely on an
1223 1223
 
upstream provider for your software, note that you \emph{cannot ignore
1224 1224
 
  your GPL compliance requirements} simply because someone else packaged
1225 1225
 
the software that you distribute.  If you redistribute GPL'd software
1226 1226
 
(which you do, whenever you ship a device with your upstream's software in
1227 1227
 
it), you are bound by the terms of the GPL\@.  No distribution (including
1228 1228
 
redistribution) is permissible absent adherence to the license terms.
1229 1229
 

	
1230 1230
 
Therefore, you should introduce a due diligence process into your software
1231 1231
 
acquisition plans.  This is much like the software-oriented
1232 1232
 
recommendations we make in \S~\ref{best-practices}.  Implementing
1233 1233
 
practices to ensure that you are aware of what software is in your devices
1234 1234
 
can only improve your general business processes.  You should ask a clear
1235 1235
 
list of questions of all your upstream providers and make sure the answers
1236 1236
 
are complete and accurate.  The following are examples of questions you
1237 1237
 
should ask:
1238 1238
 
\begin{itemize}
1239 1239
 

	
1240 1240
 
\item What are all the licenses that cover the software in this device?
1241 1241
 

	
1242 1242
 
\item From which upstream vendors, be they companies or individuals, did
1243 1243
 
  \emph{you} receive your software before distributing it to us?
1244 1244
 

	
1245 1245
 
\item What are your GPL compliance procedures?
1246 1246
 

	
1247 1247
 
\item If there is GPL'd software in your distribution, we will be
1248 1248
 
  redistributors of this GPL'd software.  What mechanisms do you have in
1249 1249
 
  place to aid us with compliance?
1250 1250
 

	
1251 1251
 
\item If we follow your recommended compliance procedures, will you
1252 1252
 
  formally indemnify us in case we are nonetheless found to be in
1253 1253
 
  violation of the GPL?
1254 1254
 

	
1255 1255
 
\end{itemize}
1256 1256
 

	
1257 1257
 
This last point is particularly important.  Many GPL enforcement actions are
1258 1258
 
escalated because of petty finger-pointing between the distributor and its
1259 1259
 
upstream.  In our experience, agreements regarding GPL compliance issues
1260 1260
 
and procedures are rarely negotiated up front.  However, when they are,
1261 1261
 
violations are resolved much more smoothly (at least from the point of
1262 1262
 
view of the redistributor).
1263 1263
 

	
1264 1264
 
Consider the cost of potential violations in your acquisition process.
1265 1265
 
Using Free Software allows software vendors to reduce costs significantly, but be
1266 1266
 
wary of vendors who have done so without regard for the licenses.  If your
1267 1267
 
vendor's costs seem ``too good to be true,'' you may ultimately bear the
1268 1268
 
burden of the vendor's inattention to GPL compliance.  Ask the right
1269 1269
 
questions, demand an account of your vendors' compliance procedures, and
1270 1270
 
seek indemnity from them.
1271 1271
 

	
1272 1272
 
In particular, any time your vendor incorporates copylefted software, you
1273 1273
 
\textit{must} exercise your own rights as a user to request CCS for all the
1274 1274
 
copylefted programs that your suppliers provided to you.  Furthermore, you
1275 1275
 
must ensure that CCS is correct and adequate yourself.  Good vendors should
1276 1276
 
help you do this, and make it easy.  If those vendors cannot, pick a
1277 1277
 
different vendor before proceeding with the product. 
1278 1278
 

	
1279 1279
 
\section{Mergers and Acquisitions}
1280 1280
 

	
1281 1281
 
Often, larger companies often encounter copyleft licensing during a Mergers
1282 1282
 
and Acquisitions (M\&A) process.  Ultimately, a merger or acquisition causes
1283 1283
 
all of the other company's problems to become yours.  Therefore, for most
1284 1284
 
concerns, the acquirer ``simply'' must apply the compliance analysis and
1285 1285
 
methodologies discussed earlier across the acquired company's entire product
1286 1286
 
line.  Of course, this is not so simple, as such effort may be substantial,
1287 1287
 
but a well-defined process for compliance investigation means the required
1288 1288
 
work, while voluminous, is likely rote.
1289 1289
 

	
1290 1290
 
A few sections of GPL require careful attention and legal analysis to
1291 1291
 
determine the risk of acquisitions.  Those handling M\&A issues should pay
1292 1292
 
particular attention to the requirements of GPLv2~\S7 and GPLv3~\S10--12 ---
1293 1293
 
focusing on how they relate to the acquired assets may be of particular
1294 1294
 
importance.
1295 1295
 

	
1296 1296
 
For example, GPLv3\S10 clarifies that in business acquisitions, whether by
1297 1297
 
sale of assets or transfers of control, the acquiring party is downstream
1298 1298
 
from the party acquired.  This results in new automatic downstream licenses
1299 1299
 
from upstream copyright holders, licenses to all modifications made by the
1300 1300
 
acquired business, and rights to source code provisioning for the
1301 1301
 
now-downstream purchaser.  However, despite this aid given by explicit
1302 1302
 
language in GPLv3, acquirers must still confirm compliance by the acquired
1303 1303
 
(even if GPLv3\S10 does assert the the acquirers rights under GPL, that does
1304 1304
 
not help if the acquired is out of compliance altogether).  Furthermore, for
1305 1305
 
fear of later reprisal by the acquirer if a GPL violation is later discovered
1306 1306
 
in the acquired's product line, the acquired may need to seek a waiver and
1307 1307
 
release of from additional damages beyond a requirement to comply fully (and
1308 1308
 
a promise of rights restoration) if a GPL violation by the acquired is later
1309 1309
 
uncovered during completion of the acquisition or thereafter.
1310 1310
 

	
1311 1311
 
Finally, other advice available regarding handling of GPL compliance in an
1312 1312
 
M\&A situation tends to ignore the most important issue: most essential
1313 1313
 
copylefted software is not wholly copyrighted by the entities involved in the
1314 1314
 
M\&A transaction.  Therefore, copyleft obligations likely reach out to the
1315 1315
 
customers of all entities involved, as well as to the original copyright
1316 1316
 
holders of the copylefted work.  As such, notwithstanding the two paragraphs
1317 1317
 
in GPLv3\S10, the entities involved in M\&A should read the copyleft licenses
1318 1318
 
through the lens of third parties whose software freedom rights under those
1319 1319
 
licenses are of equal importance to then entities inside the transaction.
1320 1320
 

	
1321 1321
 
\section{User Products and Installation Information}
1322 1322
 
\label{user-products}
1323 1323
 

	
1324 1324
 
GPLv3 requires you to provide ``Installation Information'' when v3
1325 1325
 
software is distributed in a ``User Product.''  During the drafting of v3,
1326 1326
 
the debate over this requirement was contentious.  However, the provision
1327 1327
 
as it appears in the final license is reasonable and easy to understand.
1328 1328
 

	
1329 1329
 
If you put GPLv3'd software into a User Product (as defined by the
1330 1330
 
license) and \emph{you} have the ability to install modified versions onto
1331 1331
 
that device, you must provide information that makes it possible for the
1332 1332
 
user to install functioning, modified versions of the software.  Note that
1333 1333
 
if no one, including you, can install a modified version, this provision
1334 1334
 
does not apply.  For example, if the software is burned onto an
1335 1335
 
non-field-upgradable ROM chip, and the only way that chip can be upgraded
1336 1336
 
is by producing a new one via a hardware factory process, then it is
1337 1337
 
acceptable that the users cannot electronically upgrade the software
1338 1338
 
themselves.
1339 1339
 

	
1340 1340
 
Furthermore, you are permitted to refuse support service, warranties, and
1341 1341
 
software updates to a user who has installed a modified version.  You may
1342 1342
 
even forbid network access to devices that behave out of specification due
1343 1343
 
to such modifications.  Indeed, this permission fits clearly with usual
1344 1344
 
industry practice.  While it is impossible to provide a device that is
1345 1345
 
completely unmodifiable\footnote{Consider that the iPhone, a device
1346 1346
 
  designed primarily to restrict users' freedom to modify it, was unlocked
1347 1347
 
  and modified within 48 hours of its release.}, users are generally on
1348 1348
 
notice that they risk voiding their warranties and losing their update and
1349 1349
 
support services when they make modifications.\footnote{A popular t-shirt
1350 1350
 
  in the software freedom community reads: ``I void warranties.''.  Our community is
1351 1351
 
  well-known for modifying products with full knowledge of the
1352 1352
 
  consequences.  GPLv3's ``Installation Instructions'' section merely
1353 1353
 
  confirms that reality, and makes sure GPL rights can be fully exercised,
1354 1354
 
  even if users exercise those rights at their own peril.}
1355 1355
 

	
1356 1356
 
GPLv3 is in many ways better for distributors who seek some degree of
1357 1357
 
device lock-down.  Technical processes are always found for subverting any
1358 1358
 
lock-down; pursuing it is a losing battle regardless.  With GPLv3, unlike
1359 1359
 
with GPLv2, the license gives you clear provisions that you can rely on
1360 1360
 
when you are forced to cut off support, service or warranty for a customer
1361 1361
 
who has chosen to modify.
1362 1362
 

	
1363 1363
 
% FIXME-soon: write a full section on Javascript compliance.  Here's a
1364 1364
 
%             potentially useful one-sentence introduction for such a
1365 1365
 
%             section.
1366 1366
 

	
1367 1367
 
% Non-compliance with GPLv3 in the
1368 1368
 
% distribution of Javascript on the Web is becoming more frequent
1369 1369
 
%FIXME-soon: END
1370 1370
 

	
1371 1371
 
\section{Beware The Consultant in Enforcers' Clothing}
1372 1372
 

	
1373 1373
 
There are admittedly portions of the GPL enforcement community that function
1374 1374
 
somewhat like the
1375 1375
 
\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Classifications}{computer
1376 1376
 
  security and network penetration testing hacker community}.  By analogy,
1377 1377
 
most COGEO's consider themselves
1378 1378
 
\href{http://en.wikipedia.org/wiki/White_hat_%28computer_security%29}{white hats},
1379 1379
 
while some might appropriately call
1380 1380
 
\hyperref[Proprietary Relicensing]{proprietary relicensing} by the name ``\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Black_hat}{black hats}''.
1381 1381
 
And, to finalize the analogy, there are indeed few
1382 1382
 
\href{http://en.wikipedia.org/wiki/Grey_hat}{grey hat} GPL enforcers.
1383 1383
 

	
1384 1384
 
Grey hat GPL enforcers usually have done some community-oriented GPL
1385 1385
 
enforcement themselves, typically working as a volunteer for a COGEO, but make
1386 1386
 
their living as a ``hired gun'' consultant to find GPL violations and offer
1387 1387
 
to ``fix them'' for companies.  Other such operators hold copyrights in some
1388 1388
 
key piece of copylefted software and enforce as a mechanism to find out who
1389 1389
 
is most likely to fund improvements on the software.
1390 1390
 

	
1391 1391
 
A few companies report that they have formed beneficial consulting or
1392 1392
 
employment relationships with developers they first encountered through
1393 1393
 
enforcement.  In some such cases, companies have worked with such consultants
1394 1394
 
to alter the mode of use of the project's code in the company's products.
1395 1395
 
More often in these cases, the communication channels opened in the course of
1396 1396
 
the inquiry served other consulting purposes later.
1397 1397
 

	
1398 1398
 
Feelings and opinions about this behavior are mixed within the larger
1399 1399
 
copyleft community.  Some see it as a reasonable business model and others
1400 1400
 
renounce it as corrupt behavior.  Regardless, a GPL
1401 1401
 
violator should always immediately determine the motivations of the
1402 1402
 
enforcer via documented, verifiable facts.  For example, COGEOs such as the FSF and Conservancy have made substantial
1403 1403
 
public commitments to enforce in a way that is uniform, transparent, and
1404 1404
 
publicly documented.  Furthermore, since these specific organizations are
1405 1405
 
public charities in the USA, they
1406 1406
 
are accountable to the IRS (and the public at large) in their annual Form 990
1407 1407
 
filings.   Everyone may examine their revenue models and scrutinize their
1408 1408
 
work.
1409 1409
 

	
1410 1410
 
However, entities and individuals who do GPL enforcement centered primarily
1411 1411
 
around a profit motive are likely the most dangerous enforcement entities for
1412 1412
 
one simple reason: an agreement to comply fully with the GPL for past and
1413 1413
 
future products --- always the paramount goal to COGEOs --- may not suffice as
1414 1414
 
adequate resolution for a proprietary relicensing company or grey hat GPL
1415 1415
 
enforcer.  Therefore, violators must consider carefully who has
1416 1416
 
made the enforcement inquiry and ask when and where the enforcer made public
1417 1417
 
commitments and reports regarding their enforcement work and perhaps even ask
1418 1418
 
the enforcer to directly mimic CEOGEO's detailed public disclosures and
1419 1419
 
follow the \hyperref[enforcement-standard-requests]{standard requests for
1420 1420
 
  resolution} found in this document.
1421 1421
 

	
1422
 
\section{Using the GPL with OpenSSL/BSD-4-clause}
1423
 
\label{bsd4clause-openssl}
1424
 
\input{bsd4clause-openssl}
1425
 

	
1426
 

	
1422 1427
 
\chapter{Conclusion}
1423 1428
 

	
1424 1429
 
GPL compliance need not be an onerous process.  Historically, struggles
1425 1430
 
have been the result of poor development methodologies and communications,
1426 1431
 
rather than any unexpected application of the GPL's source code disclosure
1427 1432
 
requirements.
1428 1433
 

	
1429 1434
 
Compliance is straightforward when the entirety of your enterprise is
1430 1435
 
well-informed and well-coordinated.  The receptionists should know how to
1431 1436
 
route a GPL source request or accusation of infringement.  The lawyers
1432 1437
 
should know the basic provisions of Free Software licenses and your source
1433 1438
 
disclosure requirements, and should explain those details to the software
1434 1439
 
developers.  The software developers should use a version control system
1435 1440
 
that allows them to associate versions of source with distributed
1436 1441
 
binaries, have a well-documented build process that anyone skilled in the
1437 1442
 
art can understand, and inform the lawyers when they bring in new
1438 1443
 
software.  Managers should build systems and procedures that keep everyone
1439 1444
 
on target.  With these practices in place, any organization can comply
1440 1445
 
with the GPL without serious effort, and receive the substantial benefits
1441 1446
 
of good citizenship in the software freedom community, and lots of great code
1442 1447
 
ready-made for their products.
1443 1448
 

	
1444 1449
 
\vfill
1445 1450
 

	
1446 1451
 
% LocalWords:  redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox
1447 1452
 
% LocalWords:  someone's downloadable subdirectory subdirectories filesystem
1448 1453
 
% LocalWords:  roadmap README upstream's Ravicher's FOSSology readme CDs iPhone
1449 1454
 
% LocalWords:  makefiles violator's Michlmayr Stallman RMS GPL'd Harald LGPL
1450 1455
 
%%  LocalWords:  GPL's resellers copylefted sublicenses GPLv unmanaged MySQL
1451 1456
 
%%  LocalWords:  misassessments licensor COGEOs COGEO LGPLv CCS Requestors
1452 1457
 
%%  LocalWords:  codebase Yocto distributees COGEO's Coreboot ERP reseller
1453 1458
 
%%  LocalWords:  redistributor reinstatements decompilation acquired's grey
1454 1459
 
%%  LocalWords:  upgradable unmodifiable Relicensing relicensing

Changeset was too big and was cut off... Show full diff anyway

bill auger (bill-auger)
2 years ago on pull request "bsd-4-clause-openssl section"

<-- syntax error

2 comments (1 inline, 1 general)
bill auger (bill-auger)
2 years ago on pull request "bsd-4-clause-openssl section"

Status change: Under review