compliance-guide.tex 79 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455
  1. % compliance-guide.tex -*- LaTeX -*-
  2. \part{A Practical Guide to GPL Compliance}
  3. \label{gpl-compliance-guide}
  4. \chapter*{Executive Summary}
  5. This is a guide to effective compliance with the GNU General Public
  6. License (GPL) and related licenses. Copyleft advocates
  7. usually seek to assist the community with
  8. GPL compliance cooperatively. This guide focuses on complying from the
  9. start, so that readers can learn to avoid enforcement actions entirely, or, at
  10. least, minimize the negative impact when enforcement actions occur.
  11. This guide introduces and explains basic legal concepts related to the GPL and its
  12. enforcement by copyright holders. It also outlines business practices and
  13. methods that lead to better GPL compliance. Finally, it recommends proper
  14. post-violation responses to the concerns of copyright holders.
  15. \chapter{Background}
  16. Copyright law grants exclusive rights to authors. Authors who chose copyleft
  17. seek to protect the freedom of users and developers to copy, share, modify
  18. and redistribute the software. However, copyleft is ultimately implemented
  19. through copyright, and the GPL is primarily and by default a copyright
  20. license. (See \S~\ref{explaining-copyright} for more about the interaction
  21. between copyright and copyleft.) Copyright law grants an unnatural exclusive
  22. control to copyright holders regarding copyright-controlled permissions
  23. related to the work. Therefore, copyright holders (or their agents) are the
  24. ultimately the sole authorities to enforce copyleft and protect the rights of
  25. users. Actions for copyright infringement are the ultimate legal mechanism
  26. for enforcement. Therefore, copyright holders, or collaborative groups of
  27. copyright holders, have historically been the actors in GPL enforcement.
  28. The earliest of these efforts began soon after the GPL was written by
  29. Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,
  30. often in public Usenet discussions.\footnote{One example is the public
  31. outcry over NeXT's attempt to make the Objective-C front-end to GCC
  32. proprietary. RMS, in fact, handled this enforcement action personally and
  33. the Objective-C front-end is still part of upstream GCC today.} Over the next decade, the Free Software Foundation (FSF),
  34. which holds copyrights in many GNU programs, was the only visible entity
  35. actively enforcing its GPL'd copyrights on behalf of the software freedom
  36. community.
  37. FSF's enforcement
  38. was generally a private process; the FSF contacted violators
  39. confidentially and helped them to comply with the license. Most
  40. violations were pursued this way until the early 2000's.
  41. By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in
  42. embedded devices such as wireless routers. During this period, public
  43. ridicule of violators in the press and on Internet fora supplemented
  44. ongoing private enforcement and increased pressure on businesses to
  45. comply. In 2003, the FSF formalized its efforts into the GPL Compliance
  46. Lab, increased the volume of enforcement, and built community coalitions
  47. to encourage copyright holders to together settle amicably with violators.
  48. Beginning in 2004, Harald Welte took a more organized public enforcement
  49. approach and launched \href{http://gpl-violations.org/}{gpl-violations.org}, a website and mailing
  50. list for collecting reports of GPL violations. On the basis of these
  51. reports, Welte successfully pursued many enforcement actions in Europe, including
  52. formal legal action. Harald earns the permanent fame as the first copyright
  53. holder to bring legal action in a court regarding GPL compliance.
  54. In 2007, two copyright holders in BusyBox, in conjunction with the
  55. Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit
  56. based on a violation of the GPL\@ in the USA. While lawsuits are of course
  57. quite public, the vast majority of Conservancy's enforcement actions
  58. are resolved privately via
  59. cooperative communications with violators. As both FSF and Conservancy have worked to bring
  60. individual companies into compliance, both organizations have encountered numerous
  61. violations resulting from preventable problems such as inadequate
  62. attention to licensing of upstream software, misconceptions about the
  63. GPL's terms, and poor communication between software developers and their
  64. management. This document highlights these problems and describe
  65. best practices to encourage corporate Free Software users to reevaluate their
  66. approach to GPL'd software and avoid future violations.
  67. Both FSF and Conservancy continue GPL enforcement and compliance efforts
  68. for software under the GPL, the GNU Lesser
  69. Public License (LGPL) and other copyleft licenses. In doing so, both organizations have
  70. found that most violations stem from a few common, avoidable mistakes. All copyleft advocates hope to educate the community of
  71. commercial distributors, redistributors, and resellers on how to avoid
  72. violations in the first place, and to respond adequately and appropriately
  73. when a violation occurs.
  74. \section{Who Has Compliance Obligations?}
  75. All distributors of modified or unmodified versions of copylefted works
  76. unmodified versions of the works have compliance obligations. Common methods
  77. of modifying the works include innumerable common acts, such as:
  78. \begin{itemize}
  79. \item embedding those works as executable copies
  80. into a device,
  81. \item transferring a digital copy of executable copies to someone else,
  82. \item posting a patch to the copylefted software to a public mailing list.
  83. \end{itemize}
  84. Such distributors have obligations to (at least) the users to whom they (or
  85. intermediary parties) distribute those copies. In some cases, distributors
  86. have obligations to third parties not directly receiving their distribution
  87. of the works (depending on the distributors chosen licensing options, as
  88. described later in \S~\ref{binary-distribution-permission}). In addition,
  89. distributors have compliance obligations to upstream parties, such as
  90. preservation of reasonable legal notices embedded in the code, and
  91. appropriate labeling of modified versions.
  92. Online service providers and distributors alike have other compliance
  93. obligations. In general, they must refrain from imposing any additional
  94. restrictions on downstream parties. Most typically, such compliance problems
  95. arise from ``umbrella licenses:'' EULAs, or sublicenses that restrict
  96. downstream users' rights under copyleft. (See \S~\ref{GPLv2s6} and
  97. \S~\ref{GPLv3s10}).
  98. Patent holders having claims reading on GPL'd works they distribute must
  99. refrain from enforcing those claims against parties to whom they distribute.
  100. Furthermore, patent holders holding copyrights on GPLv3'd works must further
  101. grant an explicit patent license for any patent claims reading on the version
  102. they distributed, and therefore cannot enforce those specific patent claims
  103. against anyone making, using or selling a work based on their distributed
  104. version. All parties must refrain from acting as a provider of services or
  105. distributor of licensed works if they have accepted, or had imposed on them
  106. by judicial action, any legal conditions that would prevent them from meeting
  107. any obligation under GPL\@. (See \S~\ref{GPLv2s7}, \S~\ref{GPLv3s11} and
  108. \S~\ref{GPLv3s12}.
  109. \section{What Are The Risks of Non-Compliance?}
  110. Copyleft experts have for decades observed a significant mismatch between the
  111. assumptions most businesses make about copyleft compliance and the realities.
  112. Possibly due to excessive marketing of proprietary tools and services from
  113. the for-profit compliance industry, businesses perennially focus on the wrong
  114. concerns. This tutorial seeks to educate those businesses about what
  115. actually goes wrong, what causes disputes, and how to resolve those disputes.
  116. Many businesses currently invest undue resources to avoid unlikely risks that
  117. have low historical incidence of occurrence and low cost of remediation,
  118. while leaving unmanaged the risks that have historically resulted in all the
  119. litigation and other adverse outcomes. For example, some ``compliance
  120. industry''\footnote{``Compliance industry'' refers to third-party for-profit
  121. companies that market proprietary software tools and/or consulting services
  122. that purport to aid businesses with their Free Software license compliance
  123. obligations, such as those found in GPL and other copyleft licenses. This
  124. tutorial leaves the term in quotes throughout, primarily to communicate the
  125. skepticism most of this tutorial's authors feel regarding the mere
  126. existence of this industry. Not only do copyleft advocates object on
  127. principle to proprietary software tools in general, and to their ironic use
  128. specifically to comply with copyleft, but also to the ``compliance
  129. industry'' vendors' marketing messaging, which some copyleft advocates
  130. claim as a cause in the risk misassessments discussed herein. Bradley
  131. M.~Kuhn, specifically, regularly uses the term ``compliance industrial
  132. complex''
  133. \href{http://en.wikipedia.org/wiki/Military-industrial_complex}{to
  134. analogize the types of problems in this industry to those warned against
  135. in the phrase of origin}.} vendors insist that great effort must be
  136. expended to carefully list, in the menus or manuals of embedded electronics
  137. products, copyright notices for every last copyright holder that contributed
  138. to the Free Software included in the product. While nearly all Free Software
  139. licenses, including copylefts like GPL, require preservation and display of
  140. copyright notices, failure to meet this specific requirement is trivially
  141. remedied. Therefore, businesses should spend just reasonable efforts to
  142. properly display copyright notices, and note that failure to do so is simply
  143. remedied: add the missing copyright notice!
  144. \section{Understanding Who's Enforcing}
  145. \label{compliance-understanding-whos-enforcing}
  146. The mismatch between actual compliance risk and compliance risk management
  147. typically results from a misunderstanding of licensor intentions. For-profit
  148. businesses often err by assuming other actors have kindred motivations. The
  149. primary enforcers of the GPL, however, have goals that for-profit businesses
  150. will find strange and perhaps downright alien.
  151. Specifically, community-oriented GPL enforcement organizations (called
  152. ``COGEOs'' throughout the remainder of this tutorial) are typically
  153. non-profit charities (such as the FSF and Software Freedom Conservancy) who
  154. declare, as part of their charitable mission, advancement of software freedom
  155. for all users. In the USA, these COGEOs are all classified as charitable
  156. under the IRS's 501(c)(3) designation, which is reserved for organizations
  157. that have a mission to enhance the public good.
  158. As such, these COGEOs enforce GPL primarily to pursue the policy goals and
  159. motivations discussed throughout this tutorial: to spread software freedom
  160. further. As such, COGEOs are unified in their primary goal to bring the
  161. violator back into compliance as quickly as possible, and redress the damage
  162. caused by the violation. COGEOs are steadfast in their position in a
  163. violation negotiation: comply with the license and respect freedom.
  164. Certainly, other entities do not share the full ethos of software freedom as
  165. institutionalized by COGEOs, and those entities pursue GPL violations
  166. differently. Oracle, a company that produces the GPL'd MySQL database, upon
  167. discovering GPL violations typically negotiates a proprietary software
  168. license separately for a fee. While this practice is not one a COGEO would
  169. undertake nor endorse, a copyleft license technically permits this
  170. behavior. To put a finer point on this practice already discussed
  171. in~\S~\ref{Proprietary Relicensing}, copyleft advocates usually find copyleft
  172. enforcement efforts focused on extract alternative proprietary licenses
  173. distasteful at best, and a corrupt manipulation of copyleft at worst. Much
  174. to the advocates' chagrin, such for-profit enforcement efforts seem to
  175. increase rather than decrease.
  176. Thus, unsurprisingly, for-profit adopters of GPL'd software often incorrectly
  177. assume that all copyright holders seek royalties. Businesses therefore focus
  178. on the risk of so-called ``accidental'' (typically as the result of
  179. unsupervised activity by individual programmers) infringe copyright by
  180. incorporating ``snippets'' of copylefted code into their own proprietary
  181. computer program. ``Compliance industry'' flagship products, therefore,
  182. focus on ``code scanning'' services that purport to detect accidental
  183. inclusions. Such effort focuses on proprietary software development and view
  184. Free Software as a foreign interloper. Such approach not only ignores
  185. current reality that many companies build their products directly on major
  186. copylefted projects (e.g., Android vendor's use of the kernel named Linux),
  187. but also creates a culture of fear among developers, leading them into a
  188. downward spiral of further hiding their necessary reliance on copylefted
  189. software in the company's products.
  190. Fortunately, COGEOs regard GPL compliance failures as an opportunity to
  191. improve compliance. Every compliance failure downstream represents a loss of
  192. rights by their users. The COGEOs are the guardian of its users' and
  193. developers' rights. Their activity seeks to restore those rights, and
  194. to protect the project's contributors' intentions in the making of their
  195. software.
  196. \chapter{Best Practices to Avoid Common Violations}
  197. \label{best-practices}
  198. Unlike highly permissive licenses (such as the ISC license), which
  199. typically only require preservation of copyright notices, licensees face many
  200. important requirements from the GPL. These requirements are
  201. carefully designed to uphold certain values and standards of the software
  202. freedom community. While the GPL's requirements may initially appear
  203. counter-intuitive to those more familiar with proprietary software
  204. licenses, by comparison, its terms are in fact clear and quite favorable to
  205. licensees. Indeed, the GPL's terms actually simplify compliance when
  206. violations occur.
  207. GPL violations occur (or, are compounded) most often when companies lack sound
  208. practices for the incorporation of GPL'd components into their
  209. internal development environment. This section introduces some best
  210. practices for software tool selection, integration and distribution,
  211. inspired by and congruent with software freedom methodologies. Companies should
  212. establish such practices before building a product based on GPL'd
  213. software.\footnote{This document addresses compliance with GPLv2,
  214. GPLv3, LGPLv2, and LGPLv3. Advice on avoiding the most common
  215. errors differs little for compliance with these four licenses.
  216. \S~\ref{lgpl} discusses the key differences between GPL and LGPL
  217. compliance.}
  218. \section{Evaluate License Applicability}
  219. \label{derivative-works}
  220. Political discussion about the GPL often centers around determining the
  221. ``work'' that must be licensed under GPL, or in other words, ``what is the
  222. derivative and/or combined work that was created''. Nearly ever esoteric
  223. question asked by lawyers seek to consider that question
  224. \footnote{\tutorialpartsplit{In fact, a companion work, \textit{Detailed Analysis of the GNU GPL and Related
  225. Licenses} contains an entire section discussing derivative works}{This tutorial in fact
  226. also addresses the issue at length in~\S~\ref{derivative-works}}.} (perhaps because
  227. that question explores exciting legal issues while the majority of the GPL
  228. deals with much more mundane ones).
  229. Of course, GPL was designed
  230. primarily to embody the licensing feature of copyleft.
  231. However, most companies who add
  232. complex features to and make combinations with GPL'd software
  233. are already well aware of their
  234. more complex obligations under the license that require complex legal
  235. analysis. And, there are few companies overall that engage in such
  236. activities. Thus, in practical reality, this issue is not relevant to the vast
  237. majority of companies distributing GPL'd software.
  238. Thus, experienced GPL enforcers find that few redistributors'
  239. compliance challenges relate directly to combined work issues in copyleft.
  240. Instead, the distributions of GPL'd
  241. systems most often encountered typically consist of a full operating system
  242. including components under the GPL (e.g., Linux, BusyBox) and components
  243. under the LGPL (e.g., the GNU C Library). Sometimes, these programs have
  244. been patched or slightly improved by direct modification of their sources,
  245. and thus the result is unequivocally a modified version. Alongside these programs,
  246. companies often distribute fully independent, proprietary programs,
  247. developed from scratch, which are designed to run on the Free Software operating
  248. system but do not combine with, link to, modify, derive from, or otherwise
  249. create a combined work with
  250. the GPL'd components.\footnote{However, these programs do often combine
  251. with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}
  252. In the latter case, where the work is unquestionably a separate work of
  253. creative expression, no copyleft provisions are invoked.
  254. The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a
  255. combined, derivative, and/or modified version of the work, but rather, issues related to distribution and
  256. conveyance of binary works based on GPL'd source, but without Complete,
  257. Corresponding Source.
  258. As such, issues of software delivery are the primary frustration for GPL
  259. enforcers. In particular, the following short list accounts for at least 95\%
  260. of the GPL violations ever encountered:
  261. \begin{itemize}
  262. \item The violator fails to provide required information about the presence
  263. of copylefted programs and their applicable license terms in the product
  264. they have purchased.
  265. \item The violator fails to reliably deliver \hyperref[CCS
  266. Definition]{complete, corresponding source} (CCS) for copylefted programs
  267. the violator knew were included (i.e., the CCS is either delivered but
  268. incomplete, or is not delivered at all).
  269. \item Requestors are ignored when they communicate with violator's published
  270. addresses requesting fulfillment of businesses' obligations.
  271. \end{itemize}
  272. This tutorial therefore focuses primarily on these issue.
  273. Admittedly, a tiny
  274. minority of compliance situations relate to question of derivative,
  275. combined, or modified versions of the work. Those
  276. situations are so rare, and the details from situation to situation differ
  277. greatly. Thus, such situations require a highly
  278. fact-dependent analysis and cannot be addressed in a general-purpose
  279. document such as this one.
  280. \medskip
  281. Most companies accused of violations lack a basic understanding
  282. of how to comply even in the straightforward scenario. This document
  283. provides those companies with the fundamental and generally applicable prerequisite knowledge.
  284. For answers to rarer and more complicated legal questions, such as whether
  285. your software is a derivative or combined work of some copylefted software, consult
  286. with an attorney.\footnote{If you would like more information on the
  287. application of derivative works doctrine to software, a detailed legal
  288. discussion is presented in our colleague Dan Ravicher's article,
  289. \textit{Software Derivative Work: A Circuit Dependent Determination} and in
  290. \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
  291. Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
  292. this tutorial}.}
  293. This discussion thus assumes that you have already identified the
  294. ``work'' covered by the license, and that any components not under the GPL
  295. (e.g., applications written entirely by your developers that merely happen
  296. to run on a Linux-based operating system) distributed in conjunction with
  297. those works are separate works within the meaning of copyright law and the GPL\@. In
  298. such a case, the GPL requires you to provide complete corresponding
  299. source (CCS)\footnote{For more on CCS, see
  300. \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
  301. Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of
  302. this tutorial}.}
  303. for the GPL'd components and your modifications thereto, but not
  304. for independent proprietary applications. The procedures described in
  305. this document address this typical scenario.
  306. \section{Monitor Software Acquisition}
  307. Software engineers deserve the freedom to innovate and import useful
  308. software components to improve products. However, along with that
  309. freedom should come rules and reporting procedures to make sure that you
  310. are aware of what software that you include with your product.
  311. The most typical response to an initial enforcement action is: ``We
  312. didn't know there was GPL'd stuff in there''. This answer indicates
  313. failure in the software acquisition and procurement process. Integration
  314. of third-party proprietary software typically requires a formal
  315. arrangement and management/legal oversight before the developers
  316. incorporate the software. By contrast, developers often obtain and
  317. integrate Free Software without intervention nor oversight. That ease of acquisition, however,
  318. does not mean the oversight is any less necessary. Just as your legal
  319. and/or management team negotiates terms for inclusion of any proprietary
  320. software, they should gently facilitate all decisions to bring Free Software into your
  321. product.
  322. Simple, engineering-oriented rules help provide a stable foundation for
  323. Free Software integration. For example, simply ask your software developers to send an email to a
  324. standard place describing each new Free Software component they add to the system,
  325. and have them include a brief description of how they will incorporate it
  326. into the product. Further, make sure developers use a revision control
  327. system (such as Git or Mercurial), and
  328. store the upstream versions of all software in a ``vendor branch'' or
  329. similar mechanism, whereby they can easily track and find the main version
  330. of the software and, separately, any local changes.
  331. Such procedures are best instituted at your project's launch. Once
  332. chaotic and poorly-sourced development processes begin, cataloging the
  333. presence of GPL'd components becomes challenging.
  334. Such a situation often requires use of a tool to ``catch up'' your knowledge
  335. about what software your product includes. Most commonly, companies choose
  336. some software licensing scanning tool to inspect the codebase. However,
  337. there are few tools that are themselves Free Software. Thus, GPL enforcers
  338. usually recommend the GPL'd
  339. \href{http://fossology.org/}{FOSSology system}, which analyzes a
  340. source code base and produces a list of Free Software licenses that may apply to
  341. the code. FOSSology can help you build a catalog of the sources you have
  342. already used to build your product. You can then expand that into a more
  343. structured inventory and process.
  344. \section{Track Your Changes and Releases}
  345. As explained in further detail below, the most important component of GPL
  346. compliance is the one most often ignored: proper inclusion of CCS in all
  347. distributions of GPL'd
  348. software. To comply with GPL's CCS requirements, the distributor
  349. \textit{must} always know precisely what sources generated a given binary
  350. distribution.
  351. In an unfortunately large number of our enforcement cases, the violating
  352. company's engineering team had difficulty reconstructing the CCS
  353. for binaries distributed by the company. Here are three simple rules to
  354. follow to decrease the likelihood of this occurrence:
  355. \begin{itemize}
  356. \item Ensure that your
  357. developers are using revision control systems properly.
  358. \item Have developers mark or ``tag'' the full source tree corresponding to
  359. builds distributed to customers.
  360. \item Check that your developers store all parts of the software
  361. development in the revision control system, including {\sc readme}s, build
  362. scripts, engineers' notes, and documentation.
  363. \end{itemize}
  364. Your developers will benefit anyway from these rules. Developers will be
  365. happier in their jobs if their tools already track the precise version of
  366. source that corresponds to any deployed binary.
  367. \section{Avoid the ``Build Guru''}
  368. Too many software projects rely on only one or a very few team members who
  369. know how to build and assemble the final released product. Such knowledge
  370. centralization not only creates engineering redundancy issues, but also
  371. thwarts GPL compliance. Specifically, CCS does not just require source code,
  372. but scripts and other material that explain how to control compilation and
  373. installation of the executable and object code.
  374. Thus, avoid relying on a ``build guru'', a single developer who is the only one
  375. who knows how to produce your final product. Make sure the build process
  376. is well defined. Train every developer on the build process for the final
  377. binary distribution, including (in the case of embedded software)
  378. generating a final firmware image suitable for distribution to the
  379. customer. Require developers to use revision control for build processes.
  380. Make a rule that adding new components to the system without adequate
  381. build instructions (or better yet, scripts) is unacceptable engineering
  382. practice.
  383. \chapter{Details of Compliant Distribution}
  384. Distribution of GPL'd works has requirements; copyleft will not function
  385. without placing requirements on redistribution. However, some requirements
  386. are more likely to cause compliance difficult than others. This
  387. chapter\footnote{Note that this chapter refers heavily to specific provisions
  388. and language in
  389. \hyperref[GPLv2s3-full-text]{GPLv2\S3}
  390. and \hyperref[GPLv3s6-full-text]{GPLv3\S6}.
  391. It may be helpful to review \S~\ref{GPLv2s3} and \S~\ref{GPLv3s6} first,
  392. and then have a copy of each license open while reading this
  393. section.} explains some the specific requirements placed upon
  394. distributors of GPL'd software that redistributors are most likely to
  395. overlook, yielding compliance problems.
  396. First, \hyperref[GPLv2s1]{GPLv2\S1} and \hyperref[GPLv2s4]{GPLv2\S4} require
  397. that the full license text must accompany every distribution (either in
  398. source or binary form) of each licensed work. Strangely, this requirement is
  399. responsible for a surprisingly significant fraction of compliance errors; too
  400. often, physical products lack required information about the presence of
  401. GPL'd programs and the applicable license terms. Automated build processes
  402. can and should carry a copy of the license from the the source distribution
  403. into the final binary firmware package for embedded products. Such
  404. automation usually achieves compliance regarding license inclusion
  405. requirements\footnote{At least one COGEO recommends the
  406. \href{https://www.yoctoproject.org/}{Yocto Project}, since its engineers
  407. have designed such features into it build process.}
  408. \section{Binary Distribution Permission}
  409. \label{binary-distribution-permission}
  410. % be careful below, you cannot refill the \if section, so don't refill
  411. % this paragraph without care.
  412. The various versions of the GPL are copyright licenses that grant
  413. permission to make certain uses of software that are otherwise restricted
  414. by copyright law. This permission is conditioned upon compliance with the
  415. GPL's requirements.
  416. This section walks through the requirements (of both GPLv2 and GPLv3) that
  417. apply when you distribute GPL'd programs in binary (i.e., executable or
  418. object code) form, which is typical for embedded applications. Because a
  419. binary application derives from a program's original sources, you need
  420. permission from the copyright holder to distribute it. \S~3 of GPLv2 and
  421. \S~6 of GPLv3 contain the permissions and conditions related to binary
  422. distributions of GPL'd programs.\footnote{These sections cannot be fully
  423. understood in isolation; read the entire license thoroughly before
  424. focusing on any particular provision. However, once you have read and
  425. understood the entire license, look to these sections to guide
  426. compliance for binary distributions.} Failure to provide or offer CCS is the
  427. single largest failure mode leading to compliance disputes.
  428. GPL's binary distribution sections offer a choice of compliance methods,
  429. each of which we consider in turn. Each option refers to the
  430. ``Corresponding Source'' code for the binary distribution, which includes
  431. the source code from which the binary was produced. This abbreviated and
  432. simplified definition is sufficient for the binary distribution discussion
  433. in this section, but you may wish to refer back to this section after
  434. reading the thorough discussion of ``Corresponding Source'' that appears
  435. in \S~\ref{corresponding-source}.
  436. \subsection{Option (a): Source Alongside Binary}
  437. GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing
  438. source code: including Corresponding Source with every binary
  439. distribution. While other options appear initially less onerous, this
  440. option invariably minimizes potential compliance problems, because when
  441. you distribute Corresponding Source with the binary, \emph{your GPL
  442. obligations are satisfied at the time of distribution}. This is not
  443. true of other options, and for this reason, we urge you to seriously
  444. consider this option. If you do not, you may extend the duration of your
  445. obligations far beyond your last binary distribution.
  446. Compliance under this option is straightforward. If you ship a product
  447. that includes binary copies of GPL'd software (e.g., in firmware, or on a
  448. hard drive, CD, or other permanent storage medium), you can store the
  449. Corresponding Source alongside the binaries. Alternatively, you can
  450. include the source on a CD or other removable storage medium in the box
  451. containing the product.
  452. GPLv2 refers to the various storage mechanisms as ``medi[a] customarily
  453. used for software interchange''. While the Internet has attained primacy
  454. as a means of software distribution where super-fast Internet connections
  455. are available, GPLv2 was written at a time when downloading software was
  456. not practical (and was often impossible). For much of the world, this
  457. condition has not changed since GPLv2's publication, and the Internet
  458. still cannot be considered ``a medium customary for software
  459. interchange''. GPLv3 clarifies this matter, requiring that source be
  460. ``fixed on a durable physical medium customarily used for software
  461. interchange''. This language affirms that option (a) requires binary
  462. redistributors to provide source on a physical medium.
  463. Please note that while selection of option (a) requires distribution on a
  464. physical medium, voluntary distribution via the Internet is very useful. This
  465. is discussed in detail in \S~\ref{offer-with-internet}.
  466. \subsection{Option (b): The Offer}
  467. \label{offer-for-source}
  468. Many distributors prefer to ship only an offer for source with the binary
  469. distribution, rather than the complete source package. This
  470. option has value when the cost of source distribution is a true
  471. per-unit cost. For example, this option might be a good choice for
  472. embedded products with permanent storage too small to fit the source, and
  473. which are not otherwise shipped with a CD but \emph{are} shipped with a
  474. manual or other printed material.
  475. However, this option increases the duration of your obligations
  476. dramatically. An offer for source must be good for three full years from
  477. your last binary distribution (under GPLv2), or your last binary or spare
  478. part distribution (under GPLv3). Your source code request and
  479. provisioning system must be designed to last much longer than your product
  480. life cycle. Thus, it also increases your compliance costs in the long
  481. run.
  482. In addition, if you are required to comply with the terms of GPLv2, you
  483. {\bf cannot} use a network service to provide the source code. For GPLv2,
  484. the source code offer is fulfilled only with physical media. This usually
  485. means that you must continue to produce an up-to-date ``source code CD''
  486. for years after the product's end-of-life.
  487. \label{offer-with-internet}
  488. Under GPLv2, it is acceptable and advisable for your offer for source code
  489. to include an Internet link for downloadable source \emph{in addition} to
  490. offering source on a physical medium. This practice enables those with
  491. fast network connections to get the source more quickly, and typically
  492. decreases the number of physical media fulfillment requests.
  493. (GPLv3~\S~6(b) permits provision of source with a public
  494. network-accessible distribution only and no physical media. We discuss
  495. this in detail at the end of this section.)
  496. The following is a suggested compliant offer for source under GPLv2 (and
  497. is also acceptable for GPLv3) that you would include in your printed
  498. materials accompanying each binary distribution:
  499. \begin{quote}
  500. The software included in this product contains copyrighted software that
  501. is licensed under the GPL\@. A copy of that license is included in this
  502. document on page $X$\@. You may obtain the complete Corresponding Source
  503. code from us for a period of three years after our last shipment of this
  504. product, which will be no earlier than 2011-08-01, by sending a money
  505. order or check for \$5 to: \\
  506. GPL Compliance Division \\
  507. Our Company \\
  508. Any Town, US 99999 \\
  509. \\
  510. Please write ``source for product $Y$'' in the memo line of your
  511. payment.
  512. You may also find a copy of the source at
  513. \url{http://www.example.com/sources/Y/}.
  514. This offer is valid to anyone in receipt of this information.
  515. \end{quote}
  516. There are a few important details about this offer. First, it requires a
  517. copying fee. GPLv2 permits ``a charge no more than your cost of
  518. physically performing source distribution''. This fee must be reasonable.
  519. If your cost of copying and mailing a CD is more than around \$10, you
  520. should perhaps find a cheaper CD stock and shipment method. It is simply
  521. not in your interest to try to overcharge the community. Abuse of this
  522. provision in order to make a for-profit enterprise of source code
  523. provision will likely trigger enforcement action.
  524. Second, note that the last line makes the offer valid to anyone who
  525. requests the source. This is because v2~\S~3(b) requires that offers be
  526. ``to give any third party'' a copy of the Corresponding Source. GPLv3 has
  527. a similar requirement, stating that an offer must be valid for ``anyone
  528. who possesses the object code''. These requirements indicated in
  529. v2~\S~3(c) and v3~\S~6(c) are so that noncommercial redistributors may
  530. pass these offers along with their distributions. Therefore, the offers
  531. must be valid not only to your customers, but also to anyone who received
  532. a copy of the binaries from them. Many distributors overlook this
  533. requirement and assume that they are only required to fulfill a request
  534. from their direct customers.
  535. The option to provide an offer for source rather than direct source
  536. distribution is a special benefit to companies equipped to handle a
  537. fulfillment process. GPLv2~\S~3(c) and GPLv3~\S~6(c) avoid burdening
  538. noncommercial, occasional redistributors with fulfillment request
  539. obligations by allowing them to pass along the offer for source as they
  540. received it.
  541. Note that commercial redistributors cannot avail themselves of the option
  542. (c) exception, and so while your offer for source must be good to anyone
  543. who receives the offer (under v2) or the object code (under v3), it
  544. \emph{cannot} extinguish the obligations of anyone who commercially
  545. redistributes your product. The license terms apply to anyone who
  546. distributes GPL'd software, regardless of whether they are the original
  547. distributor. Take the example of Vendor $V$, who develops a software
  548. platform from GPL'd sources for use in embedded devices. Manufacturer $M$
  549. contracts with $V$ to install the software as firmware in $M$'s device.
  550. $V$ provides the software to $M$, along with a compliant offer for source.
  551. In this situation, $M$ cannot simply pass $V$'s offer for source along to
  552. its customers. $M$ also distributes the GPL'd software commercially, so
  553. $M$ too must comply with the GPL and provide source (or $M$'s \emph{own}
  554. offer for source) to $M$'s customers.
  555. This situation illustrates that the offer for source is often a poor
  556. choice for products that your customers will likely redistribute. If you
  557. include the source itself with the products, then your distribution to
  558. your customers is compliant, and their (unmodified) distribution to their
  559. customers is likewise compliant, because both include source. If you
  560. include only an offer for source, your distribution is compliant but your
  561. customer's distribution does not ``inherit'' that compliance, because they
  562. have not made their own offer to accompany their distribution.
  563. The terms related to the offer for source are quite different if you
  564. distribute under GPLv3. Under v3, you may make source available only over
  565. a network server, as long as it is available to the general public and
  566. remains active for three years from the last distribution of your product
  567. or related spare part. Accordingly, you may satisfy your fulfillment
  568. obligations via Internet-only distribution. This makes the ``offer for
  569. source'' option less troublesome for v3-only distributions, easing
  570. compliance for commercial redistributors. However, before you switch to a
  571. purely Internet-based fulfillment process, you must first confirm that you
  572. can actually distribute \emph{all} of the software under GPLv3. Some
  573. programs are indeed licensed under ``GPLv2, \emph{or any later version}''
  574. (often abbreviated ``GPLv2-or-later''). Such licensing gives you the
  575. option to redistribute under GPLv3. However, a few popular programs are
  576. only licensed under GPLv2 and not ``or any later version''
  577. (``GPLv2-only''). You cannot provide only Internet-based source request
  578. fulfillment for the latter programs.
  579. If you determine that all GPL'd works in your whole product allow upgrade
  580. to GPLv3 (or were already GPLv3'd to start), your offer for source may be
  581. as simple as this:
  582. \begin{quote}
  583. The software included in this product contains copyrighted software that
  584. is licensed under the GPLv3\@. A copy of that license is included in this
  585. document on page $X$\@. You may obtain the complete Corresponding Source
  586. code from us for a period of three years after our last shipment of this
  587. product and/or spare parts therefor, which will be no earlier than
  588. 2011-08-01, on our website at
  589. \url{http://www.example.com/sources/productnum/}.
  590. \end{quote}
  591. \medskip
  592. Under both GPLv2 and GPLv3, source offers must be accompanied by a copy of
  593. the license itself, either electronically or in print, with every
  594. distribution.
  595. Finally, it is unacceptable to use option (b) merely because you do not have
  596. Corresponding Source ready. We find that some companies choose this option
  597. because writing an offer is easy, but producing a source distribution as
  598. an afterthought to a hasty development process is difficult. The offer
  599. for source does not exist as a stop-gap solution for companies rushing to
  600. market with an out-of-compliance product. If you ship an offer for source
  601. with your product but cannot actually deliver \emph{immediately} on that
  602. offer when your customers request it, you should expect an enforcement
  603. action.
  604. \subsection{Option (c): Noncommercial Offers}
  605. As discussed in the last section, GPLv2~\S~3(c) and GPLv3~\S~6(c) apply
  606. only to noncommercial use. These options are not available to businesses
  607. distributing GPL'd software. Consequently, companies that redistribute
  608. software packaged for them by an upstream vendor cannot merely pass along
  609. the offer they received from the vendor; they must provide their own offer
  610. or corresponding source to their distributees. We talk in detail about
  611. upstream software providers in \S~\ref{upstream}.
  612. \subsection{Option 6(d) in GPLv3: Internet Distribution}
  613. Under GPLv2, your formal provisioning options for Corresponding Source
  614. ended with \S~3(c). But even under GPLv2, pure Internet source
  615. distribution was a common practice and generally considered to be
  616. compliant. GPLv2 mentions Internet-only distribution almost as aside in
  617. the language, in text at the end of the section after the three
  618. provisioning options are listed. To quote that part of GPLv2~\S~3:
  619. \begin{quote}
  620. If distribution of executable or object code is made by offering access to
  621. copy from a designated place, then offering equivalent access to copy the
  622. source code from the same place counts as distribution of the source code,
  623. even though third parties are not compelled to copy the source along with
  624. the object code.
  625. \end{quote}
  626. When that was written in 1991, Internet distribution of software was the
  627. exception, not the rule. Some FTP sites existed, but generally software
  628. was sent on magnetic tape or CDs. GPLv2 therefore mostly assumed that
  629. binary distribution happened on some physical media. By contrast,
  630. GPLv3~\S~6(d) explicitly gives an option for this practice that the
  631. community has historically considered GPLv2-compliant.
  632. Thus, you may fulfill your source-provision obligations by providing the
  633. source code in the same way and from the same location. When exercising
  634. this option, you are not obligated to ensure that users download the
  635. source when they download the binary, and you may use separate servers as
  636. needed to fulfill the requests as long as you make the source as
  637. accessible as the binary. However, you must ensure that users can easily
  638. find the source code at the time they download the binary. GPLv3~\S~6(d)
  639. thus clarifies a point that has caused confusion about source provision in
  640. v2. Indeed, many such important clarifications are included in v3 which
  641. together provide a compelling reason for authors and redistributors alike
  642. to adopt GPLv3.
  643. \subsection{Option 6(e) in GPLv3: Software Torrents}
  644. Peer-to-peer file sharing arose well after GPLv2 was written, and does not
  645. easily fit any of the v2 source provision options. GPLv3~\S~6(e)
  646. addresses this issue, explicitly allowing for distribution of source and
  647. binary together on a peer-to-peer file sharing network. If you distribute
  648. solely via peer-to-peer networks, you can exercise this option. However,
  649. peer-to-peer source distribution \emph{cannot} fulfill your source
  650. provision obligations for non-peer-to-peer binary distributions. Finally,
  651. you should ensure that binaries and source are equally seeded upon initial
  652. peer-to-peer distribution.
  653. \section{Preparing Corresponding Source}
  654. \label{corresponding-source}
  655. Most enforcement cases involve companies that have unfortunately not
  656. implemented procedures like our \S~\ref{best-practices} recommendations
  657. and have no source distribution arranged at all. These companies must
  658. work backwards from a binary distribution to come into compliance. Our
  659. recommendations in \S~\ref{best-practices} are designed to make it easy to
  660. construct a complete and Corresponding Source release from the outset. If
  661. you have followed those principles in your development, you can meet the
  662. following requirements with ease. If you have not, you may have
  663. substantial reconstruction work to do.
  664. \subsection{Assemble the Sources}
  665. For every binary that you produce, you should collect and maintain a copy
  666. of the sources from which it was built. A large system, such as an
  667. embedded firmware, will probably contain many GPL'd and LGPL'd components
  668. for which you will have to provide source. The binary distribution may
  669. also contain proprietary components which are separate and independent
  670. works that are covered by neither the GPL nor LGPL\@.
  671. The best way to separate out your sources is to have a subdirectory for
  672. each component in your system. You can then easily mark some of them as
  673. required for your Corresponding Source releases. Collecting
  674. subdirectories of GPL'd and LGPL'd components is the first step toward
  675. preparing your release.
  676. \subsection{Building the Sources}
  677. Few distributors, particularly of embedded systems, take care to read the
  678. actual definition of Corresponding Source in the GPL\@. Consider
  679. carefully the definition, from GPLv3:
  680. \begin{quote}
  681. The ``Corresponding Source'' for a work in object code form means all
  682. the source code needed to generate, install, and (for an executable
  683. work) run the object code and to modify the work, including scripts to
  684. control those activities.
  685. \end{quote}
  686. and the definition from GPLv2:
  687. \begin{quote}
  688. The source code for a work means the preferred form of the work for making
  689. modifications to it. For an executable work, complete source code means
  690. all the source code for all modules it contains, plus any associated
  691. interface definition files, plus the scripts used to control compilation
  692. and installation of the executable.
  693. \end{quote}
  694. Note that you must include ``scripts used to control compilation and
  695. installation of the executable'' and/or anything ``needed to generate,
  696. install, and (for an executable work) run the object code and to modify
  697. the work, including scripts to control those activities''. These phrases
  698. are written to cover different types of build environments and systems.
  699. Therefore, the details of what you need to provide with regard to scripts
  700. and installation instructions vary depending on the software details. You
  701. must provide all information necessary such that someone generally skilled
  702. with computer systems could produce a binary similar to the one provided.
  703. Take as an example an embedded wireless device. Usually, a company
  704. distributes a firmware, which includes a binary copy of
  705. Linux\footnote{``Linux'' refers only to the kernel, not the larger system
  706. as a whole.} and a filesystem. That filesystem contains various binary
  707. programs, including some GPL'd binaries, alongside some proprietary
  708. binaries that are separate works (i.e., not derived from, nor based on
  709. freely-licensed sources). Consider what, in this case, constitutes adequate
  710. ``scripts to control compilation and installation'' or items ``needed to
  711. generate, install and run'' the GPL'd programs.
  712. Most importantly, you must provide some sort of roadmap that allows
  713. technically sophisticated users to build your software. This can be
  714. complicated in an embedded environment. If your developers use scripts to
  715. control the entire compilation and installation procedure, then you can
  716. simply provide those scripts to users along with the sources they act
  717. upon. Sometimes, however, scripts were never written (e.g., the
  718. information on how to build the binaries is locked up in the mind of your
  719. ``build guru''). In that case, we recommend that you write out build
  720. instructions in a natural language as a detailed, step-by-step {\sc
  721. readme}.
  722. No matter what you offer, you need to give those who receive source a
  723. clear path from your sources to binaries similar to the ones you ship. If
  724. you ship a firmware (kernel plus filesystem), and the filesystem contains
  725. binaries of GPL'd programs, then you should provide whatever is necessary
  726. to enable a reasonably skilled user to build any given GPL'd source
  727. program (and modified versions thereof), and replace the given binary in
  728. your filesystem. If the kernel is Linux, then the users must have the
  729. instructions to do the same with the kernel. The best way to achieve this
  730. is to make available to your users whatever scripts or process your
  731. engineers would use to do the same.
  732. These are the general details for how installation instructions work.
  733. Details about what differs when the work is licensed under LGPL is
  734. discussed in \S~\ref{lgpl}, and specific details that are unique to
  735. GPLv3's installation instructions are in \S~\ref{user-products}.
  736. \subsection{What About the Compiler?}
  737. The GPL contains no provision that requires distribution of the compiler
  738. used to build the software. While companies are encouraged to make it as
  739. easy as possible for their users to build the sources, inclusion of the
  740. compiler itself is not normally considered mandatory. The Corresponding
  741. Source definition -- both in GPLv2 and GPLv3 -- has not been typically
  742. read to include the compiler itself, but rather things like makefiles,
  743. build scripts, and packaging scripts.
  744. Nonetheless, in the interest of goodwill and the spirit of the GPL, most
  745. companies do provide the compiler itself when they are able, particularly
  746. when the compiler is based on GCC\@ or another copylefted compiler. If you have
  747. a GCC-based system, it is your prerogative to redistribute that GCC
  748. version (binaries plus sources) to your customers. We in the software freedom
  749. community encourage you to do this, since it often makes it easier for
  750. users to exercise their software freedom. However, if you chose to take
  751. this recommendation, ensure that your GCC distribution is itself
  752. compliant.
  753. If you have used a proprietary, third-party compiler to build the
  754. software, then you probably cannot ship it to your customers. We consider
  755. the name of the compiler, its exact version number, and where it can be
  756. acquired as information that \emph{must} be provided as part of the
  757. Corresponding Source. This information is essential to anyone who wishes
  758. to produce a binary. It is not the intent of the GPL to require you to
  759. distribute third-party software tools to your customer (provided the tools
  760. themselves are not based on the GPL'd software shipped), but we do believe
  761. it requires that you give the user all the essential non-proprietary facts
  762. that you had at your disposal to build the software. Therefore, if you
  763. choose not to distribute the compiler, you should include a {\sc readme}
  764. about where you got it, what version it was, and who to contact to acquire
  765. it, regardless of whether your compiler is Free Software, proprietary, or
  766. internally developed.
  767. \section{Best Practices and Corresponding Source}
  768. \S~\ref{best-practices} and \S~\ref{corresponding-source} above are
  769. closely related. If you follow the best practices outlined above, you
  770. will find that preparing your Corresponding Source release is an easier
  771. task, perhaps even a trivial one.
  772. Indeed, the enforcement process itself has historically been useful to
  773. software development teams. Development on a deadline can lead
  774. organizations to cut corners in a way that negatively impacts its
  775. development processes. We have frequently been told by violators that
  776. they experience difficulty when determining the exact source for a binary
  777. in production (in some cases because their ``build guru'' quit during the
  778. release cycle). When management rushes a development team to ship a
  779. release, they are less likely to keep release sources tagged and build
  780. systems well documented.
  781. We suggest that, if contacted about a violation, product builders use GPL
  782. enforcement as an opportunity to improve their development practices. No
  783. developer would argue that their system is better for having a mysterious
  784. build system and no source tracking. Address these issues by installing a
  785. revision system, telling your developers to use it, and requiring your
  786. build guru to document his or her work!
  787. \section{Non-Technical Compliance Issues}
  788. Certainly, the overwhelming majority of compliance issues are, in fact,
  789. either procedural or technical. Thus, the primary material in this chapter
  790. so far has covered those issues. However, a few compliance issues do require
  791. more direct consideration of a legal situation. This portion guide does not
  792. consider those in detail, as a careful reading of the earlier chapters of
  793. Part~\ref{gpl-lgpl-part} shows various places where legal considerations are
  794. necessary for considering compliance activity.
  795. For example, specific compliance issues related to
  796. \hyperref[GPLv2s7]{GPLv2\S7}, \hyperref[GPLv3s7]{GPLv3\S7}, and
  797. \hyperref[GPLv3s7]{GPLv3\S11} demand a more traditional approach to legal
  798. license compliance. Of course, such analysis and consideration can be
  799. complicated, and some are considered in the enforcement case studies that
  800. follow in the next part. However, compliance issues related to such sections
  801. are not rare, and, as is typical, no specific training is available for
  802. dealing with extremely rare occurrences.
  803. \section{Self-Assessment of Compliance}
  804. Most companies that adopt copylefted software believe they have complied.
  805. Humans usually have difficult admitting their own mistakes, particularly
  806. systematic ones. Therefore, perhaps the most important necessary step to
  807. stay in compliance is a company's regular evaluation of their own compliance.
  808. First, exercise a request CCS for all copylefted works from all your upstream
  809. providers of software and of components embedding software. Then, perform
  810. your own CCS check on this material first, and verify that it meets the
  811. requirements. This tutorial presents later a case study of a COGEO's CCS
  812. check in \S~\ref{pristine-example}, which you can emulate when examining
  813. their own CCS\@.
  814. Second, measure all copyleft compliance from the position of the
  815. users\footnote{Realizing of course that user very well may not be your own
  816. customer.} downstream from you exercising their rights under GPL\@. Have
  817. those users received notice of the copylefted software included in your
  818. product? Is CCS available to the users easily (preferably by automated
  819. means)? Ask yourself these questions frequently. If you cannot answer these
  820. questions with certainty in the positive, dig deeper and modify your process.
  821. Avoid ``compliance industry'' marketing distractions and concentrate on the
  822. copylefted software you already know is in your product. Historically, the
  823. risk from a copylefted code snippet that some programmer dropped in your
  824. proprietary product careless of the consequences is a problem far more
  825. infrequent and less difficult to resolve. Efficient management of the risks
  826. of higher concern lies in making sure you can provide, for example, precisely
  827. CCS for a copy of Coreboot, the kernel named Linux, BusyBox, or GNU tar that
  828. you included in a product your company shipped two years ago than in the risk
  829. of 10 lines of GPL'd Java code an engineer accidentally pasted into the
  830. source of your ERP system.
  831. Thus, reject the ``compliance industry'' suggestions that code scanners find
  832. and help solve fundamental compliance problems. Consider how COGEO's tend to
  833. use code scanners. FOSSology is indeed an important part of a violation
  834. investigation, but such is the last step and catches only some (usually
  835. minor) licensing notice problems. Thus, code scanners can help solve minor
  836. compliance problems once you have resolved the major ones. Code scanners
  837. do not manage risk.
  838. \chapter{When The Letter Comes}
  839. Unfortunately, many GPL violators ignore their obligations until they are
  840. contacted by a copyright holder or the lawyer of a copyright holder. You
  841. should certainly contact your own lawyer if you have received a letter
  842. alleging that you have infringed copyrights that were licensed to you
  843. under the GPL\@. This section outlines a typical enforcement case and
  844. provides some guidelines for response. These discussions are
  845. generalizations and do not all apply to every alleged violation. However,
  846. COGEO's in particular universally follow the processes described herein.
  847. \section{Communication Is Key}
  848. GPL violations are typically only escalated when a company ignores the
  849. copyright holder's initial communication or fails to work toward timely
  850. compliance. Accused violators should respond very promptly to the
  851. initial request. As the process continues, violators should follow up weekly with the
  852. copyright holders to make sure everyone agrees on targets and deadlines
  853. for resolving the situation.
  854. Ensure that any staff who might receive communications regarding alleged
  855. GPL violations understands how to channel the communication appropriately
  856. within your organization. Often, initial contact is addressed for general
  857. correspondence (e.g., by mail to corporate headquarters or by e-mail to
  858. general informational or support-related addresses). Train the staff that
  859. processes such communications to escalate them to someone with authority
  860. to take action. An uninformed response to such an inquiry (e.g., from
  861. a first-level technical support person) can cause negotiations to fail
  862. prematurely.
  863. Answer promptly by multiple means (paper letter, telephone call, and
  864. email), even if your response merely notifies the sender that you are
  865. investigating the situation and will respond by a certain date. Do not
  866. let the conversation lapse until the situation is fully resolved.
  867. Proactively follow up with synchronous communication means to be sure
  868. communications sent by non-reliable means (such as email) were received.
  869. Remember that the software freedom community generally values open communication and
  870. cooperation, and these values extend to GPL enforcement. You will
  871. generally find that software freedom developers and their lawyers are willing to
  872. have a reasonable dialogue and will work with you to resolve a violation
  873. once you open the channels of communication in a friendly way.
  874. Furthermore, if the complaint comes from a COGEO, assume they are
  875. well-prepared. COGEO's fully investigate compliance issues before raising
  876. the issue. The claims and concerns will be substantiated, and immediate
  877. denials will likely lead the COGEO to suspect malice rather than honest
  878. mistake.
  879. However, the biggest and most perennial mistake that all COGEOs see during
  880. enforcement is this: failure to include the violators' software development
  881. teams in the enforcement discussions and negotiations. As described above,
  882. CCS verification and approval is the most time-consuming and difficult part
  883. of resolving most compliance matters. Without direct contact between
  884. software developers on both sides, the resolution of the technical issues
  885. involved in demonstrating that the binary distributed was built from the
  886. source provided is likely to be tortuous, expensive, and tense. Your lawyers
  887. will certainly be understandably reluctant to expose your employees to direct
  888. inquiry from potentially adverse parties. However, facilitated exchanges of
  889. information among software engineers communicating on technical subjects
  890. shortens the time to resolution, substantially reduces the cost of reaching
  891. resolution, and prevents unnecessary escalation due to mutual
  892. misunderstanding. Furthermore, such frank technical discussion will often be
  893. the only way to avoid compliance litigation once a violation has occurred.
  894. Fortunately, these frank discussions will improve your company's
  895. relationships. Free Software development communities improve software to
  896. benefit everyone, which includes you and your company. When you use
  897. copylefted community software in your products, you are part of that
  898. community. Therefore, resolving a compliance matter is an occasion to
  899. strengthen your relationship to the community, by increasing communication
  900. between your developers and the project whose work you use for business
  901. benefit.
  902. \section{Termination}
  903. Many redistributors overlook the GPL's termination provision (GPLv2~\S~4 and
  904. GPLv3~\S~8). Under v2, violators forfeit their rights to redistribute and
  905. modify the GPL'd software until those rights are explicitly reinstated by
  906. the copyright holder. In contrast, v3 allows violators to rapidly resolve
  907. some violations without consequence.
  908. If you have redistributed an application under GPLv2\footnote{This applies
  909. to all programs licensed to you under only GPLv2 (``GPLv2-only'').
  910. However, most so-called GPLv2 programs are actually distributed with
  911. permission to redistribute under GPLv2 \emph{or any later version of the
  912. GPL} (``GPLv2-or-later''). In the latter cases, the redistributor can
  913. choose to redistribute under GPLv2, GPLv3, GPLv2-or-later or even
  914. GPLv3-or-later. Where the redistributor has chosen v2 explicitly, the
  915. v2 termination provision will always apply. If the redistributor has
  916. chosen v3, the v3 termination provision will always apply. If the
  917. redistributor has chosen GPLv2-or-later, then the redistributor may want
  918. to narrow to GPLv3-only upon violation, to take advantage of the
  919. termination provisions in v3.}, but have violated the terms of GPLv2,
  920. you must request a reinstatement of rights from the copyright holders
  921. before making further distributions, or else cease distribution and
  922. modification of the software forever. Different copyright holders
  923. condition reinstatement upon different requirements, and these
  924. requirements can be (and often are) wholly independent of the GPL\@. The
  925. terms of your reinstatement will depend upon what you negotiate with the
  926. copyright holder of the GPL'd program.
  927. Since your rights under GPLv2 terminate automatically upon your initial
  928. violation, \emph{all your subsequent distributions} are violations and
  929. infringements of copyright. Therefore, even if you resolve a violation on
  930. your own, you must still seek a reinstatement of rights from the copyright
  931. holders whose licenses you violated, lest you remain liable for
  932. infringement for even compliant distributions made subsequent to the
  933. initial violation.
  934. GPLv3 is more lenient. If you have distributed only v3-licensed programs,
  935. you may be eligible under v3~\S~8 for automatic reinstatement of rights.
  936. You are eligible for automatic reinstatement when:
  937. \begin{itemize}
  938. \item you correct the violation and are not contacted by a copyright
  939. holder about the violation within sixty days after the correction, or
  940. \item you receive, from a copyright holder, your first-ever contact
  941. regarding a GPL violation, and you correct that violation within thirty
  942. days of receipt of copyright holder's notice.
  943. \end{itemize}
  944. In addition to these permanent reinstatements provided under v3, violators
  945. who voluntarily correct their violation also receive provisional
  946. permission to continue distributing until they receive contact from the
  947. copyright holder. If sixty days pass without contact, that reinstatement
  948. becomes permanent. Nonetheless, you should be prepared to cease
  949. distribution during those initial sixty days should you receive a
  950. termination notice from the copyright holder.
  951. Given that much discussion of v3 has focused on its so-called more
  952. complicated requirements, it should be noted that v3 is, in this regard,
  953. more favorable to violators than v2.
  954. However, note that most Linux-based systems typically include some software
  955. licensed under GPLv2-only, and thus the copyright holders have withheld
  956. permission to redistribute under terms of GPLv3. In larger aggregate
  957. distributions which include GPLv2-only works (such as the kernel named
  958. Linux), redistributors must operate as if termination is immediate and
  959. permanent, since the technological remove of GPLv2-only works from the larger
  960. distribution requires much more engineering work than the negotiation
  961. required to seek restoration of rights for distribution under GPLv2-only
  962. after permanent termination.
  963. \chapter{Standard Requests}
  964. \label{enforcement-standard-requests}
  965. As we noted above, different copyright holders have different requirements
  966. for reinstating a violator's distribution rights. Upon violation, you no
  967. longer have a license under the GPL\@. Copyright holders can therefore
  968. set their own requirements outside the license before reinstatement of
  969. rights. We have collected below a list of reinstatement demands that
  970. copyright holders often require.
  971. \begin{itemize}
  972. \item {\bf Compliance on all Free Software copyrights}. Copyright holders of Free Software
  973. often want a company to demonstrate compliance for all GPL'd software in
  974. a distribution, not just their own. A copyright holder may refuse to
  975. reinstate your right to distribute one program unless and until you
  976. comply with the licenses of all Free Software in your distribution.
  977. \item {\bf Notification to past recipients}. Users to whom you previously
  978. distributed non-compliant software should receive a communication
  979. (email, letter, bill insert, etc.) indicating the violation, describing
  980. their rights under the GPL, and informing them how to obtain a gratis source
  981. distribution. If a customer list does not exist (such as in reseller
  982. situations), an alternative form of notice may be required (such as a
  983. magazine advertisement).
  984. \item {\bf Appointment of a GPL Compliance Officer.} The software freedom community
  985. values personal accountability when things go wrong. Copyright holders
  986. often require that you name someone within the violating company
  987. officially responsible for Free Software license compliance, and that this
  988. individual serve as the key public contact for the community when
  989. compliance concerns arise.
  990. \item {\bf Periodic Compliance Reports.} Many copyright holders wish to
  991. monitor future compliance for some period of time after the violation.
  992. For some period, your company may be required to send regular reports on
  993. how many distributions of binary and source have occurred.
  994. \end{itemize}
  995. These are just a few possible requirements for reinstatement. In the
  996. context of a GPL violation, and particularly under v2's termination
  997. provision, the copyright holder may have a range of requests in exchange
  998. for reinstatement of rights. These software developers are talented
  999. professionals from whose work your company has benefited. Indeed, you are
  1000. unlikely to find a better value or more generous license terms for similar
  1001. software elsewhere. Treat the copyright holders with the same respect you
  1002. treat your corporate partners and collaborators.
  1003. \chapter{Special Topics in Compliance}
  1004. There are several other issues that are less common, but also relevant in
  1005. a GPL compliance situation. To those who face them, they tend to be of
  1006. particular interest.
  1007. \section{LGPL Compliance}
  1008. \label{lgpl}
  1009. GPL compliance and LGPL compliance mostly involve the same issues. As we
  1010. discussed in \S~\ref{derivative-works}, questions of modified versions of
  1011. software are highly fact-dependent and cannot be easily addressed in any
  1012. overview document. The LGPL adds some additional complexity to the
  1013. analysis. Namely, the various LGPL versions permit proprietary licensing
  1014. of certain types of modified versions. These issues are discussed in greater
  1015. detail in Chapter~\ref{LGPLv2} and~\ref{LGPLv3}. However, as a rule of thumb, once you have determined
  1016. (in accordance with LGPLv3) what part of the work is the ``Application''
  1017. and what portions of the source are ``Minimal Corresponding Source'', then
  1018. you can usually proceed to follow the GPL compliance rules that
  1019. discussed above, replacing our discussion of ``Corresponding Source'' with
  1020. ``Minimal Corresponding Source''.
  1021. LGPL also requires that you provide a mechanism to combine the Application
  1022. with a modified version of the library, and outlines some options for
  1023. this. Also, the license of the whole work must permit ``reverse
  1024. engineering for debugging such modifications'' to the library. Therefore,
  1025. you should take care that the EULA used for the Application does not
  1026. contradict this permission.
  1027. Thus, under the terms of LGPL, you must refrain from license terms on works
  1028. based on the licensed work that prohibit replacement of the licensed
  1029. components of the larger non-LGPL'd work, or prohibit decompilation or
  1030. reverse engineering in order to enhance or fix bugs in the LGPL'd components.
  1031. LGPLv3 is not surprisingly easier to understand and examine from a compliance
  1032. lens, since the FSF was influenced in LGPLv3's drafting by questions and
  1033. comments on LGPLv2.1 over a period of years. Admittedly, LGPLv2.1 is still
  1034. in wide use, and thus compliance with LGPLv2.1 remains a frequent topic you
  1035. may encounter. The best advice there is careful study of
  1036. Chapter~\ref{LGPLv2}.
  1037. However, to repeat a key point here made within that chapter: Note though
  1038. that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the
  1039. worst case you simply need to comply as if the software was licensed under
  1040. GPLv2. The only reason you must consider the question of whether you have a
  1041. ``work that uses the library'' or a ``work based on the library'' is when you
  1042. wish to take advantage of the ``weak copyleft'' effect of the Lesser GPL\@.
  1043. If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the
  1044. entire work anyway), you may find this an easier option.
  1045. \section{Upstream Providers}
  1046. \label{upstream}
  1047. With ever-increasing frequency, software development (particularly for
  1048. embedded devices) is outsourced to third parties. If you rely on an
  1049. upstream provider for your software, note that you \emph{cannot ignore
  1050. your GPL compliance requirements} simply because someone else packaged
  1051. the software that you distribute. If you redistribute GPL'd software
  1052. (which you do, whenever you ship a device with your upstream's software in
  1053. it), you are bound by the terms of the GPL\@. No distribution (including
  1054. redistribution) is permissible absent adherence to the license terms.
  1055. Therefore, you should introduce a due diligence process into your software
  1056. acquisition plans. This is much like the software-oriented
  1057. recommendations we make in \S~\ref{best-practices}. Implementing
  1058. practices to ensure that you are aware of what software is in your devices
  1059. can only improve your general business processes. You should ask a clear
  1060. list of questions of all your upstream providers and make sure the answers
  1061. are complete and accurate. The following are examples of questions you
  1062. should ask:
  1063. \begin{itemize}
  1064. \item What are all the licenses that cover the software in this device?
  1065. \item From which upstream vendors, be they companies or individuals, did
  1066. \emph{you} receive your software before distributing it to us?
  1067. \item What are your GPL compliance procedures?
  1068. \item If there is GPL'd software in your distribution, we will be
  1069. redistributors of this GPL'd software. What mechanisms do you have in
  1070. place to aid us with compliance?
  1071. \item If we follow your recommended compliance procedures, will you
  1072. formally indemnify us in case we are nonetheless found to be in
  1073. violation of the GPL?
  1074. \end{itemize}
  1075. This last point is particularly important. Many GPL enforcement actions are
  1076. escalated because of petty finger-pointing between the distributor and its
  1077. upstream. In our experience, agreements regarding GPL compliance issues
  1078. and procedures are rarely negotiated up front. However, when they are,
  1079. violations are resolved much more smoothly (at least from the point of
  1080. view of the redistributor).
  1081. Consider the cost of potential violations in your acquisition process.
  1082. Using Free Software allows software vendors to reduce costs significantly, but be
  1083. wary of vendors who have done so without regard for the licenses. If your
  1084. vendor's costs seem ``too good to be true,'' you may ultimately bear the
  1085. burden of the vendor's inattention to GPL compliance. Ask the right
  1086. questions, demand an account of your vendors' compliance procedures, and
  1087. seek indemnity from them.
  1088. In particular, any time your vendor incorporates copylefted software, you
  1089. \textit{must} exercise your own rights as a user to request CCS for all the
  1090. copylefted programs that your suppliers provided to you. Furthermore, you
  1091. must ensure that CCS is correct and adequate yourself. Good vendors should
  1092. help you do this, and make it easy. If those vendors cannot, pick a
  1093. different vendor before proceeding with the product.
  1094. \section{Mergers and Acquisitions}
  1095. Often, larger companies often encounter copyleft licensing during a Mergers
  1096. and Acquisitions (M\&A) process. Ultimately, a merger or acquisition causes
  1097. all of the other company's problems to become yours. Therefore, for most
  1098. concerns, the acquirer ``simply'' must apply the compliance analysis and
  1099. methodologies discussed earlier across the acquired company's entire product
  1100. line. Of course, this is not so simple, as such effort may be substantial,
  1101. but a well-defined process for compliance investigation means the required
  1102. work, while voluminous, is likely rote.
  1103. A few sections of GPL require careful attention and legal analysis to
  1104. determine the risk of acquisitions. Those handling M\&A issues should pay
  1105. particular attention to the requirements of GPLv2~\S7 and GPLv3~\S10--12 ---
  1106. focusing on how they relate to the acquired assets may be of particular
  1107. importance.
  1108. For example, GPLv3\S10 clarifies that in business acquisitions, whether by
  1109. sale of assets or transfers of control, the acquiring party is downstream
  1110. from the party acquired. This results in new automatic downstream licenses
  1111. from upstream copyright holders, licenses to all modifications made by the
  1112. acquired business, and rights to source code provisioning for the
  1113. now-downstream purchaser. However, despite this aid given by explicit
  1114. language in GPLv3, acquirers must still confirm compliance by the acquired
  1115. (even if GPLv3\S10 does assert the the acquirers rights under GPL, that does
  1116. not help if the acquired is out of compliance altogether). Furthermore, for
  1117. fear of later reprisal by the acquirer if a GPL violation is later discovered
  1118. in the acquired's product line, the acquired may need to seek a waiver and
  1119. release of from additional damages beyond a requirement to comply fully (and
  1120. a promise of rights restoration) if a GPL violation by the acquired is later
  1121. uncovered during completion of the acquisition or thereafter.
  1122. Finally, other advice available regarding handling of GPL compliance in an
  1123. M\&A situation tends to ignore the most important issue: most essential
  1124. copylefted software is not wholly copyrighted by the entities involved in the
  1125. M\&A transaction. Therefore, copyleft obligations likely reach out to the
  1126. customers of all entities involved, as well as to the original copyright
  1127. holders of the copylefted work. As such, notwithstanding the two paragraphs
  1128. in GPLv3\S10, the entities involved in M\&A should read the copyleft licenses
  1129. through the lens of third parties whose software freedom rights under those
  1130. licenses are of equal importance to then entities inside the transaction.
  1131. \section{User Products and Installation Information}
  1132. \label{user-products}
  1133. GPLv3 requires you to provide ``Installation Information'' when v3
  1134. software is distributed in a ``User Product.'' During the drafting of v3,
  1135. the debate over this requirement was contentious. However, the provision
  1136. as it appears in the final license is reasonable and easy to understand.
  1137. If you put GPLv3'd software into a User Product (as defined by the
  1138. license) and \emph{you} have the ability to install modified versions onto
  1139. that device, you must provide information that makes it possible for the
  1140. user to install functioning, modified versions of the software. Note that
  1141. if no one, including you, can install a modified version, this provision
  1142. does not apply. For example, if the software is burned onto an
  1143. non-field-upgradable ROM chip, and the only way that chip can be upgraded
  1144. is by producing a new one via a hardware factory process, then it is
  1145. acceptable that the users cannot electronically upgrade the software
  1146. themselves.
  1147. Furthermore, you are permitted to refuse support service, warranties, and
  1148. software updates to a user who has installed a modified version. You may
  1149. even forbid network access to devices that behave out of specification due
  1150. to such modifications. Indeed, this permission fits clearly with usual
  1151. industry practice. While it is impossible to provide a device that is
  1152. completely unmodifiable\footnote{Consider that the iPhone, a device
  1153. designed primarily to restrict users' freedom to modify it, was unlocked
  1154. and modified within 48 hours of its release.}, users are generally on
  1155. notice that they risk voiding their warranties and losing their update and
  1156. support services when they make modifications.\footnote{A popular t-shirt
  1157. in the software freedom community reads: ``I void warranties.''. Our community is
  1158. well-known for modifying products with full knowledge of the
  1159. consequences. GPLv3's ``Installation Instructions'' section merely
  1160. confirms that reality, and makes sure GPL rights can be fully exercised,
  1161. even if users exercise those rights at their own peril.}
  1162. GPLv3 is in many ways better for distributors who seek some degree of
  1163. device lock-down. Technical processes are always found for subverting any
  1164. lock-down; pursuing it is a losing battle regardless. With GPLv3, unlike
  1165. with GPLv2, the license gives you clear provisions that you can rely on
  1166. when you are forced to cut off support, service or warranty for a customer
  1167. who has chosen to modify.
  1168. % FIXME-soon: write a full section on Javascript compliance. Here's a
  1169. % potentially useful one-sentence introduction for such a
  1170. % section.
  1171. % Non-compliance with GPLv3 in the
  1172. % distribution of Javascript on the Web is becoming more frequent
  1173. %FIXME-soon: END
  1174. \section{Beware The Consultant in Enforcers' Clothing}
  1175. There are admittedly portions of the GPL enforcement community that function
  1176. somewhat like the
  1177. \href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Classifications}{computer
  1178. security and network penetration testing hacker community}. By analogy,
  1179. most COGEO's consider themselves
  1180. \href{http://en.wikipedia.org/wiki/White_hat_%28computer_security%29}{white hats},
  1181. while some might appropriately call
  1182. \hyperref[Proprietary Relicensing]{proprietary relicensing} by the name ``\href{http://en.wikipedia.org/wiki/Hacker_%28computer_security%29#Black_hat}{black hats}''.
  1183. And, to finalize the analogy, there are indeed few
  1184. \href{http://en.wikipedia.org/wiki/Grey_hat}{grey hat} GPL enforcers.
  1185. Grey hat GPL enforcers usually have done some community-oriented GPL
  1186. enforcement themselves, typically working as a volunteer for a COGEO, but make
  1187. their living as a ``hired gun'' consultant to find GPL violations and offer
  1188. to ``fix them'' for companies. Other such operators hold copyrights in some
  1189. key piece of copylefted software and enforce as a mechanism to find out who
  1190. is most likely to fund improvements on the software.
  1191. A few companies report that they have formed beneficial consulting or
  1192. employment relationships with developers they first encountered through
  1193. enforcement. In some such cases, companies have worked with such consultants
  1194. to alter the mode of use of the project's code in the company's products.
  1195. More often in these cases, the communication channels opened in the course of
  1196. the inquiry served other consulting purposes later.
  1197. Feelings and opinions about this behavior are mixed within the larger
  1198. copyleft community. Some see it as a reasonable business model and others
  1199. renounce it as corrupt behavior. Regardless, a GPL
  1200. violator should always immediately determine the motivations of the
  1201. enforcer via documented, verifiable facts. For example, COGEOs such as the FSF and Conservancy have made substantial
  1202. public commitments to enforce in a way that is uniform, transparent, and
  1203. publicly documented. Furthermore, since these specific organizations are
  1204. public charities in the USA, they
  1205. are accountable to the IRS (and the public at large) in their annual Form 990
  1206. filings. Everyone may examine their revenue models and scrutinize their
  1207. work.
  1208. However, entities and individuals who do GPL enforcement centered primarily
  1209. around a profit motive are likely the most dangerous enforcement entities for
  1210. one simple reason: an agreement to comply fully with the GPL for past and
  1211. future products --- always the paramount goal to COGEOs --- may not suffice as
  1212. adequate resolution for a proprietary relicensing company or grey hat GPL
  1213. enforcer. Therefore, violators must consider carefully who has
  1214. made the enforcement inquiry and ask when and where the enforcer made public
  1215. commitments and reports regarding their enforcement work and perhaps even ask
  1216. the enforcer to directly mimic CEOGEO's detailed public disclosures and
  1217. follow the \hyperref[enforcement-standard-requests]{standard requests for
  1218. resolution} found in this document.
  1219. \chapter{Conclusion}
  1220. GPL compliance need not be an onerous process. Historically, struggles
  1221. have been the result of poor development methodologies and communications,
  1222. rather than any unexpected application of the GPL's source code disclosure
  1223. requirements.
  1224. Compliance is straightforward when the entirety of your enterprise is
  1225. well-informed and well-coordinated. The receptionists should know how to
  1226. route a GPL source request or accusation of infringement. The lawyers
  1227. should know the basic provisions of Free Software licenses and your source
  1228. disclosure requirements, and should explain those details to the software
  1229. developers. The software developers should use a version control system
  1230. that allows them to associate versions of source with distributed
  1231. binaries, have a well-documented build process that anyone skilled in the
  1232. art can understand, and inform the lawyers when they bring in new
  1233. software. Managers should build systems and procedures that keep everyone
  1234. on target. With these practices in place, any organization can comply
  1235. with the GPL without serious effort, and receive the substantial benefits
  1236. of good citizenship in the software freedom community, and lots of great code
  1237. ready-made for their products.
  1238. \vfill
  1239. % LocalWords: redistributors NeXT's Slashdot Welte gpl ISC embedders BusyBox
  1240. % LocalWords: someone's downloadable subdirectory subdirectories filesystem
  1241. % LocalWords: roadmap README upstream's Ravicher's FOSSology readme CDs iPhone
  1242. % LocalWords: makefiles violator's Michlmayr Stallman RMS GPL'd Harald LGPL
  1243. %% LocalWords: GPL's resellers copylefted sublicenses GPLv unmanaged MySQL
  1244. %% LocalWords: misassessments licensor COGEOs COGEO LGPLv CCS Requestors
  1245. %% LocalWords: codebase Yocto distributees COGEO's Coreboot ERP reseller
  1246. %% LocalWords: redistributor reinstatements decompilation acquired's grey
  1247. %% LocalWords: upgradable unmodifiable Relicensing relicensing