Copyleft/guide Changeset - 2f2e5f9e4c32

Changeset - 2f2e5f9e4c32

Parent rev.

Child rev.

[Not reviewed]

0 3 0

Bradley Kuhn (bkuhn) - 10 years ago 2014-10-16 02:14:45
bkuhn@ebb.org

Rework over-abundant use of term "derivative work"

The older portions of this tutorial tended to favor the term "derivative
work", since that was the popular catch-all term used at the time the
text was written.

However, as the newer text regarding GPLv3 now states, FSF abandoned the
use of the term "derivative work" in the text of GPLv3 itself, for
various reasons we already discuss in the tutorial.

Therefore, the tutorial text itself should likely not rely so heavily on
the phrase "derivative work" throughout. This change herein reworks a
number of places where "derivative work" was used in the tutorial and
replaced it with other terms.

Ultimately, some word-smithing happened as part of the process of doing
this patch.

3 files changed with 91 insertions and 89 deletions:

compliance-guide.tex

enforcement-case-studies.tex

gpl-lgpl.tex

0 comments (0 inline, 0 general)

compliance-guide.tex

➞

Show inline comments

 % compliance-guide.tex                            -*- LaTeX -*-
 \part{A Practical Guide to GPL Compliance}
 \label{gpl-compliance-guide}
 {\parindent 0in
 This part is: \\
 \begin{tabbing}
 Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn. \\
 Copyright \> \copyright{} 2008 \> \hspace{.2in} Software Freedom Law Center. \\
 \end{tabbing}
 \vspace{1in}
 \begin{center}
 Authors of this part are: \\
 Bradley M. Kuhn \\
 Aaron Williamson \\
 Karen M. Sandler \\
 \vspace{1in}
 Copy editors of this part include: \\
 Martin Michlmayr
 \vspace{3in}
 The copyright holders of this part hereby grant the freedom to copy, modify,
 convey, Adapt, and/or redistribute this work under the terms of the Creative
 Commons Attribution Share Alike 4.0 International License.  A copy of that
 license is available at
 \verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.
 \end{center}
+}
 \bigskip
 \chapter*{Executive Summary}
 This is a guide to effective compliance with the GNU General Public
 License (GPL) and related licenses.  Copyleft advocates
 usually seek to assist the community with
 GPL compliance cooperatively.   This guide focuses on complying from the
 start, so that readers can learn to avoid enforcement actions entirely, or, at
 least, minimize  the negative impact when enforcement actions occur.
 This guide  introduces and explains basic legal concepts related to the GPL and its
 enforcement by copyright holders. It also outlines business practices and
 methods that lead to better GPL compliance.  Finally, it recommends proper
 post-violation responses to the concerns of copyright holders.
 \chapter{Background}
 Early GPL enforcement efforts began soon after the GPL was written by
 Richard M.~Stallman (RMS) in 1989, and consisted of informal community efforts,
 often in public Usenet discussions.\footnote{One example is the public
   outcry over NeXT's attempt to make the Objective-C front-end to GCC
   proprietary.  RMS, in fact, handled this enforcement action personally and
   the Objective-C front-end is still part of upstream GCC today.}  Over the next decade, the Free Software Foundation (FSF),
 which holds copyrights in many GNU programs, was the only visible entity
 actively enforcing its GPL'd copyrights on behalf of the software freedom
 community.
 FSF's enforcement
 was generally a private process; the FSF contacted violators
 confidentially and helped them to comply with the license.  Most
 violations were pursued this way until the early 2000's.
 By that time, Linux-based systems such as GNU/Linux and BusyBox/Linux had become very common, particularly in
 embedded devices such as wireless routers.  During this period, public
 ridicule of violators in the press and on Internet fora supplemented
 ongoing private enforcement and increased pressure on businesses to
 comply.  In 2003, the FSF formalized its efforts into the GPL Compliance
 Lab, increased the volume of enforcement, and built community coalitions
 to encourage copyright holders to together settle amicably with violators.
 Beginning in 2004, Harald Welte took a more organized public enforcement
 approach and launched \verb0gpl-violations.org0, a website and mailing
 list for collecting reports of GPL violations.  On the basis of these
 reports, Welte successfully pursued many enforcements in Europe, including
 formal legal action.  Harald earns the permanent fame as the first copyright
 holder to bring legal action in a court regarding GPL compliance.
 In 2007, two copyright holders in BusyBox, in conjunction with the
 Software Freedom Conservancy (``Conservancy''), filed the first copyright infringement lawsuit
 based on a violation of the GPL\@ in the USA. While  lawsuits are of course
 quite public, the vast majority of Conservancy's enforcement actions
 are resolved privately via
 cooperative communications with violators.  As both FSF and Conservancy have worked to bring
 individual companies into compliance, both organizations have encountered numerous
 violations resulting from preventable problems such as inadequate
 attention to licensing of upstream software, misconceptions about the
 GPL's terms, and poor communication between software developers and their
 management.  This document highlights these problems and describe
 best practices to encourage corporate Free Software users to reevaluate their
 approach to GPL'd software and avoid future violations.
 Both FSF and Conservancy continue GPL enforcement and compliance efforts
 for software under the GPL, the GNU Lesser
 Public License (LGPL) and other copyleft licenses.  In doing so, both organizations have
 found that most violations stem from a few common, avoidable mistakes.  All copyleft advocates  hope to educate the community of
 commercial distributors, redistributors, and resellers on how to avoid
 violations in the first place, and to respond adequately and appropriately
 when a violation occurs.
 \chapter{Best Practices to Avoid Common Violations}
 \label{best-practices}
 Unlike highly permissive licenses (such as the ISC license), which
 typically only require preservation of copyright notices, licensees face many
 important requirements from the GPL.  These requirements are
 carefully designed to uphold certain values and standards of the software
 freedom community.  While the GPL's requirements may initially appear
 counter-intuitive to those more familiar with proprietary software
 licenses, by comparison, its terms are in fact clear and quite favorable to
 licensees.  Indeed, the GPL's terms actually simplify compliance when
 violations occur.
 GPL violations occur (or, are compounded) most often when companies lack sound
 practices for the incorporation of GPL'd components into their
 internal development environment.  This section introduces some best
 practices for software tool selection, integration and distribution,
 inspired by and congruent with software freedom methodologies.  Companies should
 establish such practices before building a product based on GPL'd
 software.\footnote{This document addresses compliance with GPLv2,
   GPLv3, LGPLv2, and LGPLv3.  Advice on avoiding the most common
   errors differs little for compliance with these four licenses.
   \S~\ref{lgpl} discusses the key differences between GPL and LGPL
   compliance.}
 \section{Evaluate License Applicability}
 \label{derivative-works}
 Political discussion about the GPL often centers around the ``copyleft''
 requirements of the license.  Indeed, the license was designed primarily
 to embody this licensing feature.  Most companies adding non-trivial
 features (beyond mere porting and bug-fixing) to GPL'd software (and
 thereby invoking these requirements) are already well aware of their
 more complex obligations under the license.\footnote{There has been much legal
   discussion regarding copyleft and derivative works.  In practical
   reality, this issue is not relevant to the vast majority of companies
   distributing GPL'd software.  Those interested in this issue should study
   \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
       Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
     this tutorial}.}
 However, experienced  GPL enforcers find that few redistributors'
 compliance challenges relate directly to combined work issues in copyleft.
 Instead, the distributions of GPL'd
 systems most often encountered typically consist of a full operating system
 including components under the GPL (e.g., Linux, BusyBox) and components
 under the LGPL (e.g., the GNU C Library).  Sometimes, these programs have
 been patched or slightly improved by direct modification of their sources,
-and thus the result is unequivocally a derivative work.  Alongside these programs,
+and thus the result is unequivocally a modified version.  Alongside these programs,
 companies often distribute fully independent, proprietary programs,
 developed from scratch, which are designed to run on the Free Software operating
 system but do not combine with, link to, modify, derive from, or otherwise
 create a combined work with
 the GPL'd components.\footnote{However, these programs do often combine
   with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}
 In the latter case, where the work is unquestionably a separate work of
 creative expression, no copyleft provisions are invoked.
 The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a
-combined or derivative work, but rather, issues related to distribution and
+combined, derivative, and/or modified version of the work, but rather, issues related to distribution and
 conveyance of binary works based on GPL'd source, but without Complete,
 Corresponding Source.  This tutorial therefore focuses primarily on that issue.
 Admittedly, a tiny
 minority of compliance situations relate to question of derivative and
 combined words.  Those
 minority of compliance situations relate to question of derivative,
 combined, or modified versions of the work.  Those
 situations are so rare, and the details from situation to situation differ
 greatly.  Thus, such situations require a highly
 fact-dependent analysis and cannot be addressed in a general-purpose
 document such as this one.
 \medskip
 Most companies accused of violations lack a basic understanding
 of how to comply even in the straightforward scenario.  This document
 provides those companies with the fundamental and generally applicable prerequisite knowledge.
 For answers to rarer and more complicated legal questions, such as whether
 your software is a derivative or combined work of some copylefted software, consult
 with an attorney.\footnote{If you would like more information on the
   application of derivative works doctrine to software, a detailed legal
   discussion is presented in our colleague Dan Ravicher's article,
   \textit{Software Derivative Work: A Circuit Dependent Determination} and in
   \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
       Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of
     this tutorial}.}
 This discussion thus assumes that you have already identified the
 ``work'' covered by the license, and that any components not under the GPL
 (e.g., applications written entirely by your developers that merely happen
 to run on a Linux-based operating system) distributed in conjunction with
 those works are separate works within the meaning of copyright law and the GPL\@.  In
 such a case, the GPL requires you to provide complete corresponding
 source (CCS)\footnote{For more on CCS,  see
 \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related
       Licenses}'s Section on GPLv2~\S2 and GPLv3~\S1.}{\S~\ref{GPLv2s2} and \S~\ref{GPLv3s1} of
     this tutorial}.}
 for the GPL'd components and your modifications thereto, but not
 for independent proprietary applications.  The procedures described in
 this document address this typical scenario.
 \section{Monitor Software Acquisition}
 Software engineers deserve the freedom to innovate and import useful
 software components to improve products.  However, along with that
 freedom should come rules and reporting procedures to make sure that you
 are aware of what software that you include with your product.
 The most typical response to an initial enforcement action is: ``We
 didn't know there was GPL'd stuff in there''.  This answer indicates
 failure in the software acquisition and procurement process.  Integration
 of third-party proprietary software typically requires a formal
 arrangement and management/legal oversight before the developers
 incorporate the software.  By contrast, developers often obtain and
 integrate Free Software without intervention nor oversight. That ease of acquisition, however,
 does not mean the oversight is any less necessary.  Just as your legal
 and/or management team negotiates terms for inclusion of any proprietary
 software, they should gently facilitate all decisions to bring Free Software into your
 product.
 Simple, engineering-oriented rules help provide a stable foundation for
 Free Software integration.  For example, simply ask your software developers to send an email to a
 standard place describing each new Free Software component they add to the system,
 and have them include a brief description of how they will incorporate it
 into the product.  Further, make sure developers use a revision control
 system (such as Git or Mercurial), and
 store the upstream versions of all software in a ``vendor branch'' or
 similar mechanism, whereby they can easily track and find the main version
 of the software and, separately, any local changes.
 Such procedures are best instituted at your project's launch.  Once
 chaotic and poorly-sourced development processes begin, cataloging the
 presence of GPL'd components  becomes challenging.
 Such a situation often requires use of a tool to ``catch up'' your knowledge
 about what software your product includes.  Most commonly, companies choose
 some software licensing scanning tool to inspect the codebase.  However,
 there are few tools that are themselves Free Software.  Thus, GPL enforcers
 usually recommend the GPL'd
 \href{http://fossology.org/}{FOSSology system}, which analyzes a
 source code base and produces a list of Free Software licenses that may apply to
 the code.  FOSSology can help you build a catalog of the sources you have
 already used to build your product.  You can then expand that into a more
 structured inventory and process.
 \section{Track Your Changes and Releases}
 As explained in further detail below, the most important component of GPL
 compliance is the one most often ignored: proper inclusion of CCS in all
 distributions  of GPL'd
 software.  To comply with GPL's CCS requirements, the distributor
 \textit{must} always know precisely what sources generated a given binary
 distribution.
 In an unfortunately large number of our enforcement cases, the violating
 company's engineering team had difficulty reconstructing the CCS
 for binaries distributed by the company.  Here are three simple rules to
 follow to decrease the likelihood of this occurrence:
 \begin{itemize}
 \item Ensure that your
 developers are using revision control systems properly.
 \item Have developers mark or ``tag'' the full source tree corresponding to
   builds distributed to customers.
 \item Check that your developers store all parts of the software
 development in the revision control system, including {\sc readme}s, build
 scripts, engineers' notes, and documentation.
 \end{itemize}
 Your developers will benefit anyway from these rules.  Developers will be
 happier in their jobs if their tools already track the precise version of
 source that corresponds to any deployed binary.
 \section{Avoid the ``Build Guru''}
 Too many software projects rely on only one or a very few team members who
 know how to build and assemble the final released product.  Such knowledge
 centralization not only creates engineering redundancy issues, but also
 thwarts GPL compliance.  Specifically, CCS does not just require source code,
 but scripts and other material that explain how to control compilation and
 installation of the executable and object code.
 Thus, avoid relying on a ``build guru'', a single developer who is the only one
 who knows how to produce your final product. Make sure the build process
 is well defined.  Train every developer on the build process for the final
 binary distribution, including (in the case of embedded software)
 generating a final firmware image suitable for distribution to the
 customer.  Require developers to use revision control for build processes.
 Make a rule that adding new components to the system without adequate
 build instructions (or better yet, scripts) is unacceptable engineering
 practice.
 \chapter{Details of Compliant Distribution}
 This section explains the specific requirements placed upon
 distributors of GPL'd software.  Note that this section refers heavily to
 specific provisions and language in
 \href{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html#section3}{GPLv2}
 and \href{http://www.fsf.org/licensing/licenses/gpl.html#section6}{GPLv3}.
 It may be helpful to have a copy of each license open while reading this
 section.
 \section{Binary Distribution Permission}
 \label{binary-distribution-permission}
 % be careful below, you cannot refill the \if section, so don't refill
 % this paragraph without care.
 The various versions of the GPL are copyright licenses that grant
 permission to make certain uses of software that are otherwise restricted
 by copyright law.  This permission is conditioned upon compliance with the
 GPL's requirements.
 This section walks through the requirements (of both GPLv2 and GPLv3) that
 apply when you distribute GPL'd programs in binary (i.e., executable or
 object code) form, which is typical for embedded applications.  Because a
 binary application derives from a program's original sources, you need
 permission from the copyright holder to distribute it.  \S~3 of GPLv2 and
 \S~6 of GPLv3 contain the permissions and conditions related to binary
 distributions of GPL'd programs.\footnote{These sections cannot be fully
   understood in isolation; read the entire license thoroughly before
   focusing on any particular provision.  However, once you have read and
   understood the entire license, look to these sections to guide
   compliance for binary distributions.}
 GPL's binary distribution sections offer a choice of compliance methods,
 each of which we consider in turn.  Each option refers to the
 ``Corresponding Source'' code for the binary distribution, which includes
 the source code from which the binary was produced.  This abbreviated and
 simplified definition is sufficient for the binary distribution discussion
 in this section, but you may wish to refer back to this section after
 reading the thorough discussion of ``Corresponding Source'' that appears
 in \S~\ref{corresponding-source}.
 \subsection{Option (a): Source Alongside Binary}
 GPLv2~\S~3(a) and v3~\S~6(a) embody the easiest option for providing
 source code: including Corresponding Source with every binary
 distribution.  While other options appear initially less onerous, this
 option invariably minimizes potential compliance problems, because when
 you distribute Corresponding Source with the binary, \emph{your GPL
   obligations are satisfied at the time of distribution}.  This is not
 true of other options, and for this reason, we urge you to seriously
 consider this option.  If you do not, you may extend the duration of your
 obligations far beyond your last binary distribution.
 Compliance under this option is straightforward.  If you ship a product
 that includes binary copies of GPL'd software (e.g., in firmware, or on a
 hard drive, CD, or other permanent storage medium), you can store the
 Corresponding Source alongside the binaries.  Alternatively, you can
 include the source on a CD or other removable storage medium in the box
 containing the product.
 GPLv2 refers to the various storage mechanisms as ``medi[a] customarily
 used for software interchange''.  While the Internet has attained primacy
 as a means of software distribution where super-fast Internet connections

enforcement-case-studies.tex

➞

Show inline comments

@@ ... / @@ -79,775 +79,775 @@ not equivalent to attending the course. @@
 %\chapter{Not All GPL Enforcement is Created Equal}
 %\section{For-Profit Enforcement}
 %\section{Community and Non-Profit Enforcement}
 \chapter{Overview of Community Enforcement}
 The GPL is a Free Software license with legal teeth. Unlike licenses like
 the X11-style or various BSD licenses, the GPL (and by extension, the LGPL) is
 designed to defend as well as grant freedom. We saw in the last course
 that the GPL uses copyright law as a mechanism to grant all the key freedoms
 essential in Free Software, but also to ensure that those freedoms
 propagate throughout the distribution chain of the software.
 \section{Termination Begins Enforcement}
 As we have learned, the assurance that Free Software under the GPL remains
 Free Software is accomplished through various terms of the GPL: \S 3 ensures
 that binaries are always accompanied with source; \S 2 ensures that the
 sources are adequate, complete and usable; \S 6 and \S 7 ensure that the
 license of the software is always the GPL for everyone, and that no other
 legal agreements or licenses trump the GPL. It is \S 4, however, that ensures
 that the GPL can be enforced.
 Thus, \S 4 is where we begin our discussion of GPL enforcement. This
 clause is where the legal teeth of the license are rooted. As a copyright
 license, the GPL governs only the activities governed by copyright law ---
 copying, modifying and redistributing computer software. Unlike most
 copyright licenses, the GPL gives wide grants of permission for engaging with
 these activities. Such permissions continue, and all parties may exercise
 them until such time as one party violates the terms of the GPL\@. At the
 moment of such a violation (i.e., the engaging of copying, modifying or
 redistributing in ways not permitted by the GPL) \S 4 is invoked. While other
 parties may continue to operate under the GPL, the violating party loses their
 rights.
 Specifically, \S 4 terminates the violators' rights to continue
 engaging in the permissions that are otherwise granted by the GPL\@.
 Effectively, their rights revert to the copyright defaults ---
 no permission is granted to copy, modify, nor redistribute the work.
 Meanwhile, \S 5 points out that if the violator has no rights under
 the GPL, they are prohibited by copyright law from engaging in the
 activities of copying, modifying and distributing. They have lost
 these rights because they have violated the GPL, and no other license
 gives them permission to engage in these activities governed by copyright law.
 \section{Ongoing Violations}
 In conjunction with \S 4's termination of violators' rights, there is
 one final industry fact added to the mix: rarely does one engage in a
 single, solitary act of copying, distributing or modifying software.
 Almost always, a violator will have legitimately acquired a copy of a
 GPL'd program, either making modifications or not, and then begun
 distributing that work. For example, the violator may have put the
 software in boxes and sold them at stores. Or perhaps the software
 was put up for download on the Internet. Regardless of the delivery
 mechanism, violators almost always are engaged in {\em ongoing\/}
 violation of the GPL\@.
 In fact, when we discover a GPL violation that occurred only once --- for
 example, a user group who distributed copies of a GNU/Linux system without
 source at one meeting --- we rarely pursue it with a high degree of
 tenacity. In our minds, such a violation is an educational problem, and
 unless the user group becomes a repeat offender (as it turns out, they
 never do), we simply forward along a FAQ entry that best explains how user
 groups can most easily comply with the GPL, and send them on their merry way.
 It is only the cases of {\em ongoing\/} GPL violation that warrant our
 active attention. We vehemently pursue those cases where dozens, hundreds
 or thousands of customers are receiving software that is out of
 compliance, and where the company continually offers for sale (or
 distributes gratis as a demo) software distributions that include GPL'd
 components out of compliance. Our goal is to maximize the impact of
 enforcement and educate industries who are making such a mistake on a
 large scale.
 In addition, such ongoing violation shows that a particular company is
 committed to a GPL'd product line. We are thrilled to learn that someone
 is benefiting from Free Software, and we understand that sometimes they
 become confused about the rules of the road. Rather than merely
 giving us a postmortem to perform on a past mistake, an ongoing violation
 gives us an active opportunity to educate a new contributor to the GPL'd
 commons about proper procedures to contribute to the community.
 Our central goal is not, in fact, to merely clear up a particular violation.
 In fact, over time, we hope that our compliance lab will be out of
 business. We seek to educate the businesses that engage in commerce
 related to GPL'd software to obey the rules of the road and allow them to
 operate freely under them. Just as a traffic officer would not revel in
 reminding people which side of the road to drive on, so we do not revel in
 violations. By contrast, we revel in the successes of educating an
 ongoing violator about the GPL so that GPL compliance becomes a second-nature
 matter, allowing that company to join the GPL ecosystem as a contributor.
 \section{How are Violations Discovered?}
 Our enforcement of the GPL is not a fund-raising effort; in fact, FSF's GPL
 Compliance Lab runs at a loss (in other words, it is subsided by our
 donors). Our violation reports come from volunteers, who have encountered,
 in their business or personal life, a device or software product that
 appears to contain GPL'd software. These reports are almost always sent
 via email to $<$license-violation@fsf.org$>$.
 Our first order of business, upon receiving such a report, is to seek
 independent confirmation. When possible, we get a copy of the software
 product. For example, if it is an offering that is downloadable from a
 Web site, we download it and investigate ourselves. When it is not
 possible for us to actually get a copy of the software, we ask the
 reporter to go through the same process we would use in examining the
 software.
 By rough estimation, about 95\% of violations at this stage can be
 confirmed by simple commands. Almost all violators have merely made an
 error and have no nefarious intentions. They have made no attempt to
 remove our copyright notices from the software. Thus, given the
 third-party binary, {\tt tpb}, usually, a simple command (on a GNU/Linux
 system) such as the following will find a Free Software copyright notice
 and GPL reference:
 \begin{quotation}
 {\tt strings tpb | grep Copyright}
 \end{quotation}
 In other words, it is usually more than trivial to confirm that GPL'd
 software is included.
 Once we have confirmed that a violation has indeed occurred, we must then
 determine whose copyright has been violated. Contrary to popular belief,
 FSF does not have the power to enforce the GPL in all cases. Since the GPL
 operates under copyright law, the powers of enforcement --- to seek
 redress once \S 4 has been invoked --- lie with the copyright holder of
 the software. FSF is one of the largest copyright holders in the world of
 GPL'd software, but we are by no means the only one. Thus, we sometimes
 discover that while GPL'd code is present in the software, there is no
 software copyrighted by FSF present.
 In cases where FSF does not hold copyright interest in the software, but
 we have confirmed a violation, we contact the copyright holders of the
 software, and encourage them to enforce the GPL\@. We offer our good offices
 to help negotiate compliance on their behalf, and many times, we help as a
 third party to settle such GPL violations. However, what we will describe
 primarily in this course is FSF's first-hand experience enforcing its own
 copyrights and the GPL\@.
 \section{First Contact}
 The Free Software community is built on a structure of voluntary
 cooperation and mutual help. Our community has learned that cooperation
 works best when you assume the best of others, and only change policy,
 procedures and attitudes when some specific event or occurrence indicates
 that a change is necessary. We treat the process of GPL enforcement in
 the same way. Our goal is to encourage violators to join the cooperative
 community of software sharing, so we want to open our hand in friendship.
 Therefore, once we have confirmed a violation, our first assumption is
 that the violation is an oversight or otherwise a mistake due to confusion
 about the terms of the license. We reach out to the violator and ask them
 to work with us in a collaborative way to bring the product into
 compliance. We have received the gamut of possible reactions to such
 requests, and in this course, we examine four specific examples of such
 compliance work.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Bortez: Modified GCC SDK}
 In our first case study, we will consider Bortez, a company that
 produces software and hardware toolkits to assist OEM vendors, makers
 of consumer electronic devices.
 \section{Facts}
 One of Bortez's key products is a Software Development Kit (``SDK'')
 designed to assist developers building software for a specific class of
 consumer electronics devices.
 FSF received a report that the SDK may be based on the GNU Compiler
 Collection (which is an FSF-copyrighted collection of tools for software
 development in C, C++ and other popular languages). FSF investigated the
 claim, but was unable to confirm the violation. The violation reporter
 was unresponsive to follow-up requests for more information.
 Since FSF was unable to confirm the violation, we did not pursue it any
 further. Bogus reports do happen, and we do not want to burden companies
 with specious GPL violation complaints. FSF shelved the matter until
 more evidence was discovered.
 FSF was later able to confirm the violation when two additional reports
 surfaced from other violation reporters, both of whom had used the SDK
 professionally and noticed clear similarities to FSF's GNU GCC\@. FSF's
 Compliance Engineer asked the reporters to run standard tests to confirm
 the violation, and it was confirmed that Bortez's SDK was indeed a
-derivative work of GCC\@. Bortez had ported to Windows and added a number
+modified version of GCC\@. Bortez had ported to Windows and added a number
 of features, including support for a specific consumer device chipset and
 additional features to aid in the linking process (``LP'') for those
 specific devices. FSF explained the rights that the GPL afforded these
 customers and pointed out, for example, that Bortez only needed to provide
 source to those in possession of the binaries, and that the users may need
 to request that source (if \S 3(b) was exercised). The violators
 confirmed that such requests were not answered.
 FSF brought the matter to the attention of Bortez, who immediately
 escalated the matter to their attorneys. After a long negotiation,
-Bortez acknowledged that their SDK was indeed a derivative work of
+Bortez acknowledged that their SDK was indeed a modified version of
 GCC\@. Bortez released most of the source, but some disagreement
-occurred over whether LP was a derivative work of GCC\@. After repeated
+occurred over whether LP was also derivative of GCC\@. After repeated
 FSF inquiries, Bortez reaudited the source to discover that FSF's
 analysis was correct. Bortez determined that LP included a number of
 source files copied from the GCC code-base.
 \label{davrik-build-problems}
 Once the full software release was made available, FSF asked the violation
 reporters if it addressed the problem. Reports came back that the source
 did not properly build. FSF asked Bortez to provide better build
 instructions with the software, and such build instructions were
 incorporated into the next software release.
 At FSF's request as well, Bortez informed customers who had previously
 purchased the product that the source was now available by announcing
 the availability on its Web site and via a customer newsletter.
 Bortez did have some concerns regarding patents. They wished to include a
 statement with the software release that made sure they were not granting
 any patent permission other than what was absolutely required by the GPL\@.
 They understood that their patent assertions could not trump any rights
 granted by the GPL\@. The following language was negotiated into the release:
 \begin{quotation}
 Subject to the qualifications stated below, Bortez, on behalf of itself
 and its Subsidiaries, agrees not to assert the Claims against you for your
 making, use, offer for sale, sale, or importation of the Bortez's GNU
 Utilities or derivative works of the Bortez's GNU Utilities
 (``Derivatives''), but only to the extent that any such Derivatives are
 licensed by you under the terms of the GNU General Public License. The
 Claims are the claims of patents that Bortez or its Subsidiaries have
 standing to enforce that are directly infringed by the making, use, or
 sale of an Bortez Distributed GNU Utilities in the form it was distributed
 by Bortez and that do not include any limitation that reads on hardware;
 the Claims do not include any additional patent claims held by Bortez that
 cover any modifications of, derivative works based on or combinations with
 the Bortez's GNU Utilities, even if such a claim is disclosed in the same
 patent as a Claim. Subsidiaries are entities that are wholly owned by
 Bortez.
 This statement does not negate, limit or restrict any rights you already
 have under the GNU General Public License version 2.
 \end{quotation}
 This quelled Bortez's concerns about other patent licensing they sought to
 do outside of the GPL'd software, and satisfied FSF's concerns that Bortez
 give proper permissions to exercise teachings of patents that were
 exercised in their GPL'd software release.
 Finally, a GPL Compliance Officer inside Bortez was appointed to take
 responsibility for all matters of GPL compliance inside the company.
 Bortez is responsible for informing FSF if the position is given to
 someone else inside the company, and making sure that FSF has direct
 contact with Bortez's Compliance Officer.
 \section{Lessons}
 This case introduces a number of concepts regarding GPL enforcement.
 \begin{enumerate}
 \item {\bf Enforcement should not begin until the evidence is confirmed.}
   Most companies that distribute GPL'd software do so in compliance, and at
   times, violation reports are mistaken. Even with extensive efforts in
   GPL education, many users do not fully understand their rights and the
   obligations that companies have. By working through the investigation
   with reporters, the violation can be properly confirmed, and {\bf the
     user of the software can be educated about what to expect with GPL'd
     software}. When users and customers of GPL'd products know their
   rights, what to expect, and how to properly exercise their rights
   (particularly under \S 3(b)), it reduces the chances for user
   frustration and inappropriate community outcry about an alleged GPL
   violation.
 \item {\bf GPL compliance requires friendly negotiation and cooperation.}
   Often, attorneys and managers are legitimately surprised to find out
   GPL'd software is included in their company's products. Engineers
   sometimes include GPL'd software without understanding the requirements.
   This does not excuse companies from their obligations under the license,
   but it does mean that care and patience are essential for reaching GPL
   compliance. We want companies to understand that participating and
   benefiting from a collaborative Free Software community is not a burden,
   so we strive to make the process of coming into compliance as smooth as
   possible.
 \item {\bf Confirming compliance is a community effort.}  The whole point
   of making sure that software distributors respect the terms of the GPL is to
   allow a thriving software sharing community to benefit and improve the
   work. FSF is not the expert on how a compiler for consumer electronic
   devices should work. We therefore inform the community who originally
   brought the violation to our attention and ask them to assist in
   evaluation and confirmation of the product's compliance. Of course, FSF
   coordinates and oversees the process, but we do not want compliance for
   compliance's sake; rather, we wish to foster a cooperating community of
   development around the Free Software in question, and encourage the
   once-violator to begin participating in that community.
 \item {\bf Informing the harmed community is part of compliance.} FSF asks
   violators to make some attempt --- such as via newsletters and the
   company's Web site --- to inform those who already have the products as
   to their rights under the GPL\@. One of the key thrusts of the GPL's \S 1 and
   \S 3 is to {\em make sure the user knows she has these rights\/}. If a
   product was received out of compliance by a customer, she may never
   actually discover that she has such rights. Informing customers, in a
   way that is not burdensome but has a high probability of successfully
   reaching those who would seek to exercise their freedoms, is essential
   to properly remedy the mistake.
 \item {\bf Lines between various copyright, patent, and other legal
   mechanisms must be precisely defined and considered.}  The most
   difficult negotiation point of the Bortez case was drafting language
   that simultaneously protected Bortez's patent rights outside of the
   GPL'd source, but was consistent with the implicit patent grant in
   the GPL\@. As we discussed in the first course of this series, there is
   indeed an implicit patent grant with the GPL, thanks to \S 6 and \S 7.
   However, many companies become nervous and wish to make the grant
   explicit to assure themselves that the grant is sufficiently narrow for
   their needs. We understand that there is no reasonable way to determine
   what patent claims read on a company's GPL holdings and which do not, so
   we do not object to general language that explicitly narrows the patent
   grant to only those patents that were, in fact, exercised by the GPL'd
   software as released by the company.
 \end{enumerate}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Bracken: a Minor Violation in a GNU/Linux Distribution}
 In this case study, we consider a minor violation made by a company whose
 knowledge of the Free Software community and its functions is deep.
 \section{The Facts}
 Bracken produces a GNU/Linux operating system product that is sold
 primarily to OEM vendors to be placed in appliance devices used for a
 single purpose, such as an Internet-browsing-only device. The product
 is almost 100\% Free Software, mostly licensed under the GPL and related
 Free Software licenses.
 FSF found out about this violation through a report first posted on a
   Slashdot\footnote{Slashdot is a popular news and discussion site for
   technical readers.} comment, and then it was brought to our attention again
   by another Free Software copyright holder who had discovered the
   same violation.
 Bracken's GNU/Linux product is delivered directly from their Web site.
 This allowed FSF engineers to directly download and confirm the
 violation quickly. Two primary problems were discovered with the
 online distribution:
 \begin{itemize}
 \item No source code nor offer for source code was provided for a number
   of components for the distributed GNU/Linux system; only binaries were
   available
 \item An End User License Agreement (``EULA'') was included that
   contradicted the permissions granted by the GPL\@
 \end{itemize}
 FSF contacted Bracken and gave them the details of the violation. Bracken
 immediately ceased distribution of the product temporarily and set forth
 a plan to bring themselves back into compliance. This plan included the
 following steps:
 \begin{itemize}
 \item Bracken attorneys would rewrite the EULA to comply with the GPL and
   would vet the new EULA through FSF before use
 \item Bracken engineers would provide source side-by-side with the
   binaries for the GNU/Linux distribution on the site (and on CD's, if
   ever they distributed that way)
 \item Bracken attorneys would run an internal seminar for its engineers
   regarding proper GPL compliance to help ensure that such oversights
   regarding source releases would not occur in the future
 \item Bracken would resume distribution of the product only after FSF
   formally restored Bracken's distribution rights
 \end{itemize}
 This case was completed in about a month. FSF approved the new EULA
 text. The key portion in the EULA relating to the GPL read as follows:
 \begin{quotation}
 Many of the Software Programs included in Bracken Software are distributed
 under the terms of agreements with Third Parties (``Third Party
 Agreements'') which may expand or limit the Licensee's rights to use
 certain Software Programs as set forth in [this EULA]. Certain Software
 Programs may be licensed (or sublicensed) to Licensee under the GNU
 General Public License and other similar license agreements listed in part
 in this section which, among other rights, permit the Licensee to copy,
 modify and redistribute certain Software Programs, or portions thereof,
 and have access to the source code of certain Software Programs, or
 portions thereof. In addition, certain Software Programs, or portions
 thereof, may be licensed (or sublicensed) to Licensee under terms stricter
 than those set forth in [this EULA]. The Licensee must review the
 electronic documentation that accompanies certain Software Programs, or
 portions thereof, for the applicable Third Party Agreements. To the
 extent any Third Party Agreements require that Bracken provide rights to
 use, copy or modify a Software Program that are broader than the rights
 granted to the Licensee in [this EULA], then such rights shall take
 precedence over the rights and restrictions granted in this Agreement
 solely for such Software Programs.
 \end{quotation}
 FSF restored Bracken's distribution rights shortly after the work was
 completed as described.
 \section{Lessons Learned}
 This case was probably the most quickly and easily resolved of all GPL
 violations in the history of FSF's Compliance Lab. The ease with which
 the problem was resolved shows a number of cultural factors that play a
 role in GPL compliance.
 \begin{enumerate}
 \item {\bf Companies that understand Free Software culture better have an
   easier time with compliance.}  Bracken's products were designed and
   built around the GNU/Linux system and Free Software components. Their
   engineers were deeply familiar with the Free Software ecosystem, and
   their lawyers had seen and reviewed the GPL before. The violation was
   completely an honest mistake. Since the culture inside the company had
   already adapted to the cooperative style of resolution in the Free
   Software world, there was very little work for either party to bring the
   product into compliance.
 \item {\bf When people in key positions understand the Free Software
   nature of their software products, compliance concerns are as
   mundane as minor software bugs.}  Even the most functional system or
   structure has its problems, and successful business often depends on
   agile response to the problems that do come up; avoiding problems
   altogether is a pipe dream. Minor GPL violations can and do happen
   even with well-informed redistributors. However, resolution is
   reached quickly when the company --- and in particular, the lawyers,
   managers, and engineers working on the Free Software product lines
   --- have adapted to Free Software culture that the lower-level
   engineer already understood
 \item {\bf Legally, distribution must stop when a violation is
   identified.}  In our opinion, Bracken went above and beyond the call of
   duty by ceasing distribution while the violation was being resolved.
   Under GPL \S 4, the redistributor loses the right to distribute the
   software, and thus they are in ongoing violation of copyright law if
   they distribute before rights are restored. It is FSF's policy to
   temporarily allow distribution while compliance negotiations are ongoing
   and only in the most extreme cases (where the other party appears to be
   negotiating in bad faith) does FSF even threaten an injunction on
   copyright grounds. However, Bracken --- as a good Free Software citizen
   --- chose to be on the safe side and do the legally correct thing while
   the violation case was pending. From start to finish, it took less
   than a month to resolve. This lapse in distribution did not, to FSF's
   knowledge, impact Bracken's business in any way.
 \item {\bf EULAs are a common area for GPL problems.}  Often, EULAs
   are drafted from boilerplate text that a company uses for all its
   products. Even the most diligent attorneys forget or simply do not
   know that a product contains software licensed under the GPL and other
   Free Software licenses. Drafting a EULA that accounts for such
   licenses is straightforward; the text quoted above works just fine.
   The EULA must be designed so that it does not trump rights and
   permissions already granted by the GPL\@. The EULA must clearly state
   that if there is a conflict between it and the GPL, with regard to GPL'd
   code, the GPL is the overriding license.
 \item {\bf Compliance Officers are rarely necessary when companies are
   educated about GPL compliance.}  As we saw in the Bortez case, FSF asks
   that a formal ``GPL Compliance Officer'' be appointed inside a
   previously violating organization to shepherd the organization to a
   cooperative approach to GPL compliance. However, when FSF
   sees that an organization already has such an approach, there is no
   need to request that such an officer be appointed.
 \end{enumerate}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Vigorien: Security, Export Controls, and GPL Compliance}
 This case study introduces how concerns of ``security through obscurity''
 and regulatory problems can impact GPL compliance matters.
 \section{The Facts}
 Vigorien distributes a back-up solution product that allows system
 administrators to create encrypted backups of file-systems on
 Unix-like computers. The product is based on GNU tar, a backup utility
 that replaces the standard Unix utility simply called tar, but has
 additional features.
 Vigorien's backup solution added cryptographic features to GNU tar, and
 included a suite of utilities and graphical user interfaces surrounding
 GNU tar to make backups convenient.
 FSF discovered the violation from a user report, and determined that the
 cryptographic features were the only part of the product that constituted
 a derivative work of GNU tar; the extraneous utilities merely made
 shell calls out to GNU tar. FSF requested that Vigorien come into
 compliance with the GPL by releasing the source of GNU tar, with the
 cryptographic modifications, to its customers.
 Vigorien released the original GNU tar sources, but kept the cryptographic
 modifications proprietary. They argued that the security of their system
 depending on keeping the software proprietary and that regardless, USA
 export restrictions on cryptographic software prohibited such a release.
 FSF disputed the first claim, pointing out that Vigorien had only one
 option if they did not want to release the source: they would have to
 remove GNU tar from the software and not distribute it further. Vigorien
 rejected this suggestion, since GNU tar was an integral part of the
 product, and the security changes were useless without GNU tar.
 Regarding the export control claims, FSF proposed a number of options,
 including release of the source from one of Vigorien's divisions overseas
 where no such restrictions occurred, but Vigorien argued that the problem
 was insoluble because they operated primarily in the USA\@.
 The deadlock on the second issue was resolved when those cryptographic
 export restrictions were lifted shortly thereafter, and FSF again raised
 the matter with Vigorien. At that point, they dropped the first claim and
 agreed to release the remaining source module to their customers. They
 did so, and the violation was resolved.
 \section{Lessons Learned}
 \begin{enumerate}
 \item {\bf Removing the GPL'd portion of the product is always an
   option.}  Many violators' first response is to simply refuse to
   release the source code as the GPL requires. FSF offers the option to
   simply remove the GPL'd portions from the product and continue along
   without them. Every case where this has been suggested has led to
   the same conclusion. Like Vigorien, the violator argues that the
   product cannot function without the GPL'd components, and they
   cannot effectively replace them.
   Such an outcome is simply further evidence that the combined work in
-  question is indeed a derivative work of the original GPL'd component.
+  question is indeed a modified version of the original GPL'd component.
   If the other components cannot stand on their own and be useful without
   the GPL'd portions, then one cannot effectively argue that the work as a
-  whole is not a derivative of the GPL'd portions.
+  whole is not a based on the GPL'd portions.
 \item {\bf The whole product is not always covered.}  In this case,
   Vigorien had additional works aggregated. The backup system was a suite
   of utilities, some of which were the GPL and some of which were not. While
   the cryptographic routines were tightly coupled with GNU tar and clearly
-  derivative works, the various GUI utilities were separate and
+  made a whole new combined work of both components, the various GUI utilities were separate and
   independent works merely aggregated with the distribution of the
   GNU-tar-based product.
 \item {\bf ``Security'' concerns do not exonerate a distributor from GPL
   obligations, and ``security through obscurity'' does not work anyway.}
   The argument that ``this is security software, so it cannot be released
   in source form'' is not a valid defense for explaining why the terms of
   the GPL are ignored. If companies do not want to release source code
   for some reason, then they should not base the work on GPL'd software.
   No external argument for noncompliance can hold weight if the work as
-  a whole is indeed a derivative work of a GPL'd program.
+  a whole is indeed a modified version of a GPL'd program.
   The ``security concerns'' argument is often floated as a reason to keep
   software proprietary, but the computer security community has on
   numerous occasions confirmed that such arguments are entirely specious.
   Security experts have found --- since the beginnings of the field of
   cryptography in the ancient world --- that sharing results about systems
   and having such systems withstand peer review and scrutiny builds the
   most secure systems. While full disclosure may help some who wish to
   compromise security, it helps those who want to fix problems even more
   by identifying them early.
 \item {\bf External regulatory problems can be difficult to resolve.}
   The GPL, though grounded in copyright law, does not have the power to trump
   regulations like export controls. While Vigorien's ``security
   concerns'' were specious, their export control concerns were not. It is
   indeed a difficult problem that FSF acknowledges. We want compliance
   with the GPL and respect for users' freedoms, but we certainly do not expect
   companies to commit criminal offenses for the sake of compliance. We
   will see more about this issue in our next case study.
 \end{enumerate}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Haxil, Polgara, and Thesulac: Mergers, Upstream Providers and Radio Devices}
 This case study considers an ongoing (at the time of writing) violation
 that has occurred. By the end of the investigation period, three
 companies were involved and many complex issues arose.
 \section{The Facts}
 Haxil produced a consumer electronics device which included a mini
 GNU/Linux distribution to control the device. The device was of interest
 to many technically-minded consumers, who purchased the device and very
 quickly discovered that Free Software was included without source.
 Mailing lists throughout the Free Software community erupted with
 complaints about the problem, and FSF quickly investigated.
 FSF confirmed that FSF-copyrighted GPL'd software was included. In
 addition, the whole distribution included GPL'd works from hundreds of
 individual copyright holders, many of whom were, at this point, up in
 arms about the violation.
 Meanwhile, Haxil was in the midst of being acquired by Polgara. Polgara
 was as surprised as everyone else to discover the product was based on
 GPL'd software; this fact had not been part of the disclosures made during
 acquisition. FSF contacted Haxil, Polgara, and the product managers
 who had transitioned into the ``Haxil division'' of the newly-merged
 Polgara company. Polgara's General Counsel's office worked with FSF on
 the matter.
 FSF formed a coalition with the other primary copyright holders
 to pursue the enforcement effort on their behalf. FSF communicated
 directly with Polgara's representatives to begin working through the
 issues on behalf of itself and the Free Software community at large.
 Polgara pointed out that the software distribution they used was mostly
 contributed by an upstream provider, Thesulac, and Haxil's changes to that
 code base were minimal. Polgara negotiated with Thesulac to obtain the
 source, although the issue moved very slowly in the channels between
 Polgara and Thesulac.
 FSF encouraged a round-table meeting so that high bandwidth communication
 could occur between FSF, Polgara and Thesulac. Polgara and Thesulac
 agreed, and that discussion began. Thesulac provided nearly complete
 sources to Polgara, and Polgara made a full software release on their
 Web site. At the time of writing, that software still has some build
 problems (similar to those that occurred with Bortez, as described in
 Section~\ref{davrik-build-problems}). FSF continues to negotiate with
 Polgara and Thesulac to resolve these problems, which have a clear path to
 a solution and are expected to resolve.
 Similar to the Vigorien case, Thesulac has regulatory concerns. In this
 case, it is not export controls --- an issue that has since been resolved
 --- but radio spectrum regulation. Since this consumer electronic device
 contains a software-programmable radio transmitter, regulations in (at
 least) the USA and Japan prohibit release of those portions of the code
 that operate the device. Since this is a low-level programming issue, the
-changes to operate the device are a derivative work of the kernel named
+changes to operate the device form a single combined work with the kernel named
 Linux.  A decade later, this situation remains largely unresolved.
 \section{Lessons Learned}
 \begin{enumerate}
 \item {\bf Community outrage, while justified, can often make negotiation
   more difficult.}  FSF has a strong policy never to publicize names of
   GPL violators if they are negotiating in a friendly way and operating in
   good faith toward compliance. Most violations are honest mistakes, and
   FSF sees no reason to publicly admonish violators who genuinely want to
   come into compliance with the GPL and to work hard staying in compliance.
   This case was so public in the Free Software community that both Haxil's
   and Polgara's representatives were nearly shell-shocked by the time FSF
   began negotiations. There was much work required to diffuse the
   situation. We empathize with our community and their outrage about GPL
   violations, but we also want to follow a path that leads expediently
   to compliance. In our experience, public outcry works best as a last
   resort, not the first.
 \item {\bf For software companies, GPL compliance belongs on a corporate
   acquisition checklist. }  Polgara was truly amazed that Haxil had used
   GPL'd software in a major new product line but never informed Polgara
   during the acquisition process. While GPL compliance is not a
   particularly difficult matter, it is an additional obligation that comes
   along with the product line. When planning mergers and joint ventures,
   one should include lists of GPL'd components contained in the products
   discussed.
 \item {\bf Compliance problems of upstream providers do not excuse a
   violation for the downstream distributor.}  To paraphrase \S 6, upstream
   providers are not responsible for enforcing compliance of their
   downstream, nor are downstream distributors responsible for compliance
   problems of upstream providers. However, engaging in distribution of
   GPL'd works out of compliance is still just that: a compliance problem.
   When FSF carries out enforcement, we are patient and sympathetic when
   the problem appears to be upstream. In fact, we urge the violator to
   point us to the upstream provider so we may talk to them directly. In
   this case, we were happy to begin negotiations with Thesulac. However,
   Polgara still has an obligation to bring their product into compliance,
   regardless of Thesulac's response.
 \item {\bf It behooves upstream providers to advise downstream
   distributors about compliance matters.}  FSF has encouraged Thesulac to
   distribute a ``good practices for GPL compliance'' document with their
   product. Polgara added various software components to Thesulac's
   product, and it is conceivable that such additions can introduce
   compliance. In FSF's opinion, Thesulac is in no way legally responsible
   for such a violation introduced by their customer, but it behooves them
   from a marketing standpoint to educate their customers about using the
   product. We can argue whether or not it is your coffee vendor's fault
   if you burn yourself with their product, but (likely) no one on either
   side would dispute the prudence of placing a ``caution: hot'' label on
   the cup.
 \item {\bf FSF enforcement often avoids redundant enforcement cases from
   many parties.}  Most Free Software systems have hundreds of copyright
   holders. Some have thousands. FSF is in a unique position as one of
   the largest single copyright holders on GPL'd software and as a
   respected umpire in the community, neutrally enforcing the rules of the
   GPL road. FSF works hard in the community to convince copyright
   holders that consolidating GPL claims through FSF is better for them,
   and more likely to yield positive compliance results.
   A few copyright holders engage in the ``proprietary relicensing''
   business, so they use GPL enforcement as a sales channel for that
   business. FSF, as a community-oriented, not-for-profit organization,
   seeks only to preserve the freedom of Free Software in its enforcement
   efforts. As it turns out, most of the community of copyright holders
   of Free Software want the same thing. Share and share alike is a
   simple rule to follow, and following that rule to FSF's satisfaction
   usually means you are following it to the satisfaction of the entire
   Free Software community.
 \end{enumerate}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % COMMENT OUT THIS CHAPTER.
 % FIXME: is this material moot now that we include the compliance guide?
 % Either way, it should be merged into compliance guide.
 %\chapter{Good Practices for Compliance}
 Generally, from the experience of GPL enforcement, we glean the following
 general practices that can help in GPL compliance for organizations that
 distribute products based on GPL'd software:
 \begin{itemize}
 \item Talk to your software engineers and ask them where they got the
   components they use in the products they build. Find out if GPL'd
   components are present.
 \item Teach your engineering staff to pay attention to license documents.
   Give them easy-to-follow policies to get approval for using a Free
   Software component.
 \item Build a ``Free Software Licensing'' committee that handles requests
   and questions about the GPL and other Free Software licenses.
 \item Add ``What parts of your products are under the GPL or other Free
   Software licenses?'' to your checklist of questions to ask when you
   consider mergers, acquisitions, or joint ventures.
 \item Encourage your engineers to participate collaboratively with GPL'd
   software development. The more knowledge about the Free Software world
   your organization has, the better equipped it is to deal with this
   rapidly changing field.
 \item When someone points out a potential GPL violation in one of your
   products, do not assume the product line is doomed. The GPL is not a virus;
   merely having GPL'd code in one part of a product does not necessarily
   mean that every related product must also be GPL'd. And, even if some
   software needs to be released that was not before, the product will
   surely survive. In FSF's enforcement efforts, we have not yet
   seen a product line die because source was released to customers in
   compliance with the GPL.
 \end{itemize}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % LocalWords:  proprietarize redistributors sublicense yyyy Gnomovision EULAs
 % LocalWords:  Yoyodyne FrontPage improvers Berne copyrightable Stallman's GPLs
 % LocalWords:  Lessig Lessig's UCITA pre PDAs CDs reshifts GPL's Gentoo glibc
 % LocalWords:  TrollTech administrivia LGPL's MontaVista OpenTV Mitek Arce DVD
 % LocalWords:  unprotectable protectable Unfreedonia chipset CodeSourcery Iqtel
 % LocalWords:  impermissibly Bateman faire minimis Borland uncopyrightable Mgmt
 % LocalWords:  franca downloadable Bortez Bortez's
 % LocalWords:  Slashdot sublicensed Vigorien Vigorien's Haxil Polgara
 % LocalWords:  Thesulac Polgara's Haxil's Thesulac's SDK CD's

gpl-lgpl.tex

➞

Show inline comments

@@ ... @@
 greatly with the creation of GPLv3.
 \section{The GNU General Public License, Version 3}
 RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups
 during that era about new text of that license.  However, rampant violations
 of the GPL required more immediate attention of FSF's licensing staff, and as
 such, much of the early 2000's was spent doing GPL enforcement
 work\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a
     companion tutorial, \textit{A Practical Guide to GPL
       Compliance}}{Part~\ref{gpl-compliance-guide} of this tutorial}.}.  In
 , FSF began in earnest drafting work for GPLv3.
 The GPLv3 process began in earnest in January 2006.  It became clear that
 many provisions of the GPL could benefit from modification to fit new
 circumstances and to reflect what the entire community learned from
 experience with version 2.  Given the scale of revision it seems proper to
 approach the work through public discussion in a transparent and accessible
 manner.
 The GPLv3 process continued through June 2007, culminating in publication of
 GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC
 Runtime Library Exception on 27 January 2009.
 All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3
 and two discussion drafts of AGPLv3 were published and discussed.
 Ultimately, FSF remained the final arbiter and publisher of the licenses, and
 RMS himself their primary author, but input was sought from many parties, and
 these licenses do admittedly look and read more like legislation as a result.
 Nevertheless, all of the ``v3'' group are substantially better and improved
 licenses.
 GPLv3 and its terms are discussed in detail in Chapter~\ref{GPLv3}.
 \section{The Innovation of Optional ``Or Any Later'' Version}
 An interesting fact of all GPL licenses is that there are ultimately multiple
 choices for use of the license.  The FSF is the primary steward of GPL (as
 discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv3s14}).  However, those
 who wish to license works under GPL are not required to automatically accept
 changes made by the FSF for their own copyrighted works.
 Each licensor may chose three different methods of licensing, as follows:
 \begin{itemize}
 \item explicitly name a single version of GPL for their work (usually
   indicated in shorthand by saying the license is ``GPLv$X$-only''), or
 \item name no version of the GPL, thus they allow their downstream recipients
   to select any version of the GPL they choose (usually indicated in shorthand
   by saying the license is simply ``GPL''), or
 \item name a specific version of GPL and give downstream recipients the
   option to choose that version ``or any later version as published by the
   FSF'' (usually indicated by saying the license is
   ``GPLv$X$-or-later'')\footnote{The shorthand of ``GPL$X+$'' is also popular
     for this situation.  The authors of this tutorial prefer ``-or-later''
     syntax, because it (a) mirrors the words ``or'' and ``later from the
     licensing statement, (b) the $X+$ doesn't make it abundantly clear that
     $X$ is clearly included as a license option and (c) the $+$ symbol has
     other uses in computing (such as with regular expressions) that mean
     something different.}
 \end{itemize}
 \label{license-compatibility-first-mentioned}
 Oddly, this flexibility has received (in the opinion of the authors, undue)
 criticism, primarily because of the complex and oft-debated notion of
 ``license compatibility'' (which is explained in detail in
 \S~\ref{license-compatibility}).  Copyleft licenses are generally
 incompatible with each other, because the details of how they implement
 copyleft differs.  Specifically, copyleft works only because of its
 requirement that downstream licensors use the \textit{same} license for
 combined and modified works.  As such, software licensed under the terms of
 ``GPLv2-only'' cannot be combined with works licensed ``GPLv3-or-later''.
 This is admittedly a frustrating outcome.
 Other copyleft licenses that appeared after GPL, such
 as the Creative Commons ``Share Alike'' licenses, the Eclipse Public License
 and the Mozilla Public License \textbf{require} all copyright holders choosing
 to use any version of those licenses to automatically accept and relicense
 their copyrighted works under new versions.  Of course, Creative Commons, the
 Eclipse Foundation, and the Mozilla Foundation (like the FSF) have generally
 served as excellent stewards of their licenses.  Copyright holders using
 those licenses seems to find it acceptable to fully delegate all future
 licensing decisions for their copyrights to these organizations without a
 second thought.
 However, note that FSF gives herein the control of copyright holders to
 decide whether or not to implicitly trust the FSF in its work of drafting
 future GPL versions.  The FSF, for its part, does encourage copyright holders
 to chose by default ``GPLv$X$-or-later'' (where $X$ is the most recent
 version of the GPL published by the FSF).  However, the FSF \textbf{does not
   mandate} that a choice to use any GPL requires a copyright holder ceding
 its authority for future licensing decisions to the FSF.  In fact, the FSF
 considered this possibility for GPLv3 and chose not to do so, instead opting
 for the third-party steward designation clause discussed in
 Section~\ref{GPLv3s14}.
 \section{Complexities of Two Simultaneously Popular Copylefts}
 Obviously most GPL advocates would prefer widespread migration to GPLv3, and
 many newly formed projects who seek a copyleft license tend to choose a
 GPLv3-based license.  However, many existing copylefted projects continue
 with GPLv2-only or GPLv2-or-later as their default license.
 While GPLv3 introduces many improvements --- many of which were designed to
 increase adoption by for-profit companies --- GPLv2 remains a widely used and
 extremely popular license.  The GPLv2 is, no doubt, a good and useful
 license.
 However, unlike GPLv1 before it,
 GPLv2 remains an integral part of the copyleft licensing infrastructure.  As such, those who seek to have expertise in current
 topics of copyleft licensing need to study both the GPLv2 and GPLv3 family of
 licenses.
 Furthermore, GPLv3 is more easily understood by first studying GPLv2.
 This is not only because of their chronological order, but also because much
 of the discussion material available for GPLv3 tends to talk about GPLv3 in
 contrast to GPLv2.  As such, a strong understanding of GPLv2 helps in
 understanding most of the third-party material found regarding GPLv3.  Thus,
 the following chapter begins a deep discussion of GPLv2.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Running Software and Verbatim Copying}
 \label{run-and-verbatim}
 This chapter begins the deep discussion of the details of the terms of
 GPLv2\@. In this chapter, we consider the first two sections: GPLv2 \S\S
 --2. These are the straightforward sections of the GPL that define the
 simplest rights that the user receives.
 \section{GPLv2~\S0: Freedom to Run}
 \label{GPLv2s0}
 GPLv2~\S0, the opening section of GPLv2, sets forth that copyright law governs
 the work.  It specifically points out that it is the ``copyright
 holder'' who decides if a work is licensed under its terms and explains
 how the copyright holder might indicate this fact.
 A bit more subtly, GPLv2~\S0 makes an inference that copyright law is the only
 system that can restrict the software.  Specifically, it states:
 \begin{quote}
 Activities other than copying, distribution and modification are not
 covered by this License; they are outside its scope.
 \end{quote}
 In essence, the license governs \emph{only} those activities, and all other
 activities are unrestricted, provided that no other agreements trump GPLv2
 (which they cannot; see Sections~\ref{GPLv2s6} and~\ref{GPLv2s7}).  This is
 very important, because the Free Software community heavily supports
 users' rights to ``fair use'' and ``unregulated use'' of copyrighted
 material.  GPLv2 asserts through this clause that it supports users' rights
 to fair and unregulated uses.
 Fair use (called ``fair dealing'' in some jurisdictions) of copyrighted
 material is an established legal doctrine that permits certain activities
 regardless of whether copyright law would otherwise restrict those activities.
 Discussion of the various types of fair use activity are beyond the scope of
 this tutorial.  However, one important example of fair use is the right to
 quote portions of the text in a larger work so as to criticize or suggest
 changes.  This fair use right is commonly used on mailing lists when
 discussing potential improvements or changes to Free Software.
 Fair use is a doctrine established by the courts or by statute.  By
 contrast, unregulated uses are those that are not covered by the statue
 nor determined by a court to be covered, but are common and enjoyed by
 many users.  An example of unregulated use is reading a printout of the
 program's source code like an instruction book for the purpose of learning
 how to be a better programmer.  The right to read something that you have
 access to is and should remain unregulated and unrestricted.
 \medskip
 Thus, the GPLv2 protects users' fair and unregulated use rights precisely by
 not attempting to cover them.  Furthermore, the GPLv2 ensures the freedom
 to run specifically by stating the following:
 \begin{quote}
 ''The act of running the Program is not restricted.''
 \end{quote}
 Thus, users are explicitly given the freedom to run by GPLv2~\S0.
 \medskip
 The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used
 throughout.  The only one worth discussing in detail is ``work based on
 the Program''.  The reason this definition is particularly interesting is
 not for the definition itself, which is rather straightforward, but
 because it clears up a common misconception about the GPL\@.
 The GPL is often mistakenly criticized because it fails to give a
 definition of ``derivative work''.  In fact, it would be incorrect and
 problematic if the GPL attempted to define this.  A copyright license, in
 fact, has no control over what may or may not be a derivative work.  This
 matter is left up to copyright law and the courts --- not the licenses that utilize it.
 definition of ``derivative work'' or ``combined work''.  In fact, it would be incorrect and
 problematic if the GPL attempted to define these terms.  A copyright license, in
 fact, has no control over the rules of copyright themselves.  Such rules are
 the domain of copyright law and the courts --- not the licenses that utilize
 those systems.
 It is certainly true that copyright law as a whole does not propose clear
 and straightforward guidelines for what is and is not a derivative
 software work under copyright law.  However, no copyright license --- not
 even the GNU GPL --- can be blamed for this.  Legislators and court
 opinions must give us guidance to decide the border cases.
 Copyright law as a whole doesn't propose clear and straightforward guidelines
 for identifying the derivative and/or combined works of software.  However,
 no copyright license --- not even the GNU GPL --- can be blamed for this.
 Legislators and court opinions must give us guidance in borderline cases.
 \section{GPLv2~\S1: Verbatim Copying}
 \label{GPLv2s1}
 GPLv2~\S1 covers the matter of redistributing the source code of a program
 exactly as it was received. This section is quite straightforward.
 However, there are a few details worth noting here.
 The phrase ``in any medium'' is important.  This, for example, gives the
 freedom to publish a book that is the printed copy of the program's source
 code.  It also allows for changes in the medium of distribution.  Some
 vendors may ship Free Software on a CD, but others may place it right on
 the hard drive of a pre-installed computer.  Any such redistribution media
 is allowed.
 Preservation of copyright notice and license notifications are mentioned
 specifically in GPLv2~\S1.  These are in some ways the most important part of
 the redistribution, which is why they are mentioned by name.  GPL
 always strives to make it abundantly clear to anyone who receives the
 software what its license is.  The goal is to make sure users know their
 rights and freedoms under GPL, and to leave no reason that users might be
 surprised the software is GPL'd. Thus
 throughout the GPL, there are specific references to the importance of
 notifying others down the distribution chain that they have rights under
 GPL.
 Also mentioned by name is the warranty disclaimer. Most people today do
 not believe that software comes with any warranty.  Notwithstanding the
 \href{http://mlis.state.md.us/2000rs/billfile/hb0019.htm}{Maryland's} and \href{http://leg1.state.va.us/cgi-bin/legp504.exe?001+ful+SB372ER}{Virginia's} UCITA bills, there are few or no implied warranties with software.
 However, just to be on the safe side, GPL clearly disclaims them, and the
 GPL requires re-distributors to keep the disclaimer very visible. (See
 Sections~\ref{GPLv2s11} and~\ref{GPLv2s12} of this tutorial for more on GPL's
 warranty disclaimers.)
 Note finally that GPLv2~\S1 creates groundwork for the important defense of
 commercial freedom.  GPLv2~\S1 clearly states that in the case of verbatim
 copies, one may make money.  Re-distributors are fully permitted to charge
 for the re-distribution of copies of Free Software. In addition, they may
 provide the warranty protection that the GPL disclaims as an additional
 service for a fee. (See Section~\ref{Business Models} for more discussion
 on making a profit from Free Software redistribution.)
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Derivative Works: Statute and Case Law}
 \label{derivative-works}
 We digress for this chapter from our discussion of GPL's exact text to
 consider the matter of derivative works --- a concept that we must
 understand fully before considering GPLv2~\S\S2--3\@. The GPL, and Free
 Software licensing in general, relies critically on the concept of
 ``derivative work'' since software that is ``independent,'' (i.e., not
 ``derivative'') of Free Software need not abide by the terms of the
 applicable Free Software license. As much is required by \S~106 of the
 Copyright Act, 17 U.S.C. \S~106 (2002), and admitted by Free Software
 licenses, such as the GPL, which (as we have seen) states in GPLv2~\S0 that ``a
 `work based on the Program' means either the Program or any derivative
 work under copyright law.'' It is being a derivative work of Free Software
 that triggers the necessity to comply with the terms of the Free Software
 license under which the original work is distributed. Therefore, one is
 left to ask, just what is a ``derivative work''? The answer to that
 question differs depending on which court is being asked.
 The analysis in this chapter sets forth the differing definitions of
 derivative work by the circuit courts. The broadest and most
 established definition of derivative work for software is the
 abstraction, filtration, and comparison test (``the AFC test'') as
 created and developed by the Second Circuit. Some circuits, including
 the Ninth Circuit and the First Circuit, have either adopted narrower
 versions of the AFC test or have expressly rejected the AFC test in
 favor of a narrower standard. Further, several other circuits have yet
 to adopt any definition of derivative work for software.
 As an introductory matter, it is important to note that literal copying of
 a significant portion of source code is not always sufficient to establish
 that a second work is a derivative work of an original
 program. Conversely, a second work can be a derivative work of an original
 program even though absolutely no copying of the literal source code of
 the original program has been made. This is the case because copyright
 protection does not always extend to all portions of a program's code,
 while, at the same time, it can extend beyond the literal code of a
 program to its non-literal aspects, such as its architecture, structure,
 sequence, organization, operational modules, and computer-user interface.
 \section{The Copyright Act}
 The copyright act is of little, if any, help in determining the definition
 of a derivative work of software. However, the applicable provisions do
 provide some, albeit quite cursory, guidance. Section 101 of the Copyright
 Act sets forth the following definitions:
 \begin{quotation}
 A ``computer program'' is a set of statements or instructions to be used
 directly or indirectly in a computer in order to bring about a certain
 result.
 A ``derivative work'' is a work based upon one or more preexisting works,
 such as a translation, musical arrangement, dramatization,
 fictionalization, motion picture version, sound recording, art
 reproduction, abridgment, condensation, or any other form in which a work
 may be recast, transformed, or adapted. A work consisting of editorial
 revisions, annotations, elaborations, or other modifications which, as a
 whole, represent an original work of authorship, is a ``derivative work.''
 \end{quotation}
 These are the only provisions in the Copyright Act relevant to the
 determination of what constitutes a derivative work of a computer
 program. Another provision of the Copyright Act that is also relevant to
 the definition of derivative work is \S~102(b), which reads as follows:
 \begin{quotation}
 In no case does copyright protection for an original work of authorship
 extend to any idea, procedure, process, system, method of operation,
 concept, principle, or discovery, regardless of the form in which it is
 described, explained, illustrated, or embodied in such work.
 \end{quotation}
 Therefore, before a court can ask whether one program is a derivative work
 of another program, it must be careful not to extend copyright protection
 to any ideas, procedures, processes, systems, methods of operation,
 concepts, principles, or discoveries contained in the original program. It
 is the implementation of this requirement to ``strip out'' unprotectable
 elements that serves as the most frequent issue over which courts
 disagree.
 \section{Abstraction, Filtration, Comparison Test}
 As mentioned above, the AFC test for determining whether a computer
 program is a derivative work of an earlier program was created by the
 Second Circuit and has since been adopted in the Fifth, Tenth, and
 Eleventh Circuits. Computer Associates Intl., Inc. v. Altai, Inc., 982
 F.2d 693 (2nd Cir. 1992); Engineering Dynamics, Inc. v. Structural
 Software, Inc., 26 F.3d 1335 (5th Cir. 1994); Kepner-Tregoe,
 Inc. v. Leadership Software, Inc., 12 F.3d 527 (5th Cir. 1994); Gates
 Rubber Co. v. Bando Chem. Indust., Ltd., 9 F.3d 823 (10th Cir. 1993);
 Mitel, Inc. v. Iqtel, Inc., 124 F.3d 1366 (10th Cir. 1997); Bateman
 v. Mnemonics, Inc., 79 F.3d 1532 (11th Cir. 1996); and, Mitek Holdings,
 Inc. v. Arce Engineering Co., Inc., 89 F.3d 1548 (11th Cir. 1996).
 Under the AFC test, a court first abstracts from the original program its
 constituent structural parts. Then, the court filters from those
 structural parts all unprotectable portions, including incorporated ideas,
 expression that is necessarily incidental to those ideas, and elements
 that are taken from the public domain. Finally, the court compares any and
 all remaining kernels of creative expression to the structure of the
 second program to determine whether the software programs at issue are
 substantially similar so as to warrant a finding that one is the
 derivative work of the other.
 Often, the courts that apply the AFC test will perform a quick initial
 comparison between the entirety of the two programs at issue in order to
 help determine whether one is a derivative work of the other. Such a
 holistic comparison, although not a substitute for the full application of
 the AFC test, sometimes reveals a pattern of copying that is not otherwise
 obvious from the application of the AFC test when, as discussed below,
 only certain components of the original program are compared to the second
 program. If such a pattern is revealed by the quick initial comparison,
 the court is more likely to conclude that the second work is indeed a
 derivative of the original.
 \subsection{Abstraction}
 The first step courts perform under the AFC test is separation of the
 work's ideas from its expression. In a process akin to reverse
 engineering, the courts dissect the original program to isolate each level
 of abstraction contained within it. Courts have stated that the
 abstractions step is particularly well suited for computer programs
 because it breaks down software in a way that mirrors the way it is
 typically created. However, the courts have also indicated that this step
 of the AFC test requires substantial guidance from experts, because it is
 extremely fact and situation specific.
 By way of example, one set of abstraction levels is, in descending order
 of generality, as follows: the main purpose, system architecture, abstract
 data types, algorithms and data structures, source code, and object
 code. As this set of abstraction levels shows, during the abstraction step
 of the AFC test, the literal elements of the computer program, namely the
 source and object code, are defined as particular levels of
 abstraction. Further, the source and object code elements of a program are
 not the only elements capable of forming the basis for a finding that a
 second work is a derivative of the program. In some cases, in order to
 avoid a lengthy factual inquiry by the court, the owner of the copyright in
 the original work will submit its own list of what it believes to be the
 protected elements of the original program. In those situations, the court
 will forgo performing its own abstraction, and proceed to the second step of
 the AFC test.
 \subsection{Filtration}
 The most difficult and controversial part of the AFC test is the second
 step, which entails the filtration of protectable expression contained in
 the original program from any unprotectable elements nestled therein. In
@@ ... @@
 so, then the second work is a derivative work of the first. If, however,
 the amount of protectable elements copied in the second work are so small
 as to be de minimis, then the second work is not a derivative work of the
 original.
 \section{Analytic Dissection Test}
 The Ninth Circuit has adopted the analytic dissection test to determine
 whether one program is a derivative work of another. Apple Computer,
 Inc. v. Microsoft Corp., 35 F.3d 1435 (9th Cir. 1994). The analytic
 dissection test first considers whether there are substantial similarities
 in both the ideas and expressions of the two works at issue. Once the
 similar features are identified, analytic dissection is used to determine
 whether any of those similar features are protected by copyright. This
 step is the same as the filtration step in the AFC test. After identifying
 the copyrightable similar features of the works, the court then decides
 whether those features are entitled to ``broad'' or ``thin''
 protection. ``Thin'' protection is given to non-copyrightable facts or
 ideas that are combined in a way that affords copyright protection only
 from their alignment and presentation, while ``broad'' protection is given
 to copyrightable expression itself. Depending on the degree of protection
 afforded, the court then sets the appropriate standard for a subjective
 comparison of the works to determine whether, as a whole, they are
 sufficiently similar to support a finding that one is a derivative work of
 the other. ``Thin'' protection requires the second work be virtually
 identical in order to be held a derivative work of an original, while
 ``broad'' protection requires only a ``substantial similarity.''
 \section{No Protection for ``Methods of Operation''}
 The First Circuit has taken the position that the AFC test is inapplicable
 when the works in question relate to unprotectable elements set forth in
 \S~102(b).  Their approach results in a much narrower definition
 of derivative work for software in comparison to other circuits. Specifically,
 the
 First Circuit holds that ``method of operation,'' as used in \S~102(b) of
 the Copyright Act, refers to the means by which users operate
 computers. Lotus Development Corp. v. Borland Int'l., Inc., 49 F.3d 807
 (1st Cir. 1995).  In Lotus, the court held that a menu command
 hierarchy for a computer program was uncopyrightable because it did not
 merely explain and present the program's functional capabilities to the
 user, but also served as a method by which the program was operated and
 controlled. As a result, under the First Circuit's test, literal copying
 of a menu command hierarchy, or any other ``method of operation,'' cannot
 form the basis for a determination that one work is a derivative of
 another.  As a result, courts in the First Circuit that apply the AFC test
 do so only after applying a broad interpretation of \S~102(b) to filter out
 unprotected elements. E.g., Real View, LLC v. 20-20 Technologies, Inc.,
 F. Supp.2d 147, 154 (D. Mass. 2010).
 \section{No Test Yet Adopted}
 Several circuits, most notably the Fourth and Seventh, have yet to
 declare their definition of derivative work and whether or not the
 AFC, Analytic Dissection, or some other test best fits their
 interpretation of copyright law. Therefore, uncertainty exists with
 respect to determining the extent to which a software program is a
 derivative work of another in those circuits. However, one may presume
 that they would give deference to the AFC test since it is by far the
 majority rule among those circuits that have a standard for defining
 a software derivative work.
 \section{Cases Applying Software Derivative Work Analysis}
 In the preeminent case regarding the definition of a derivative work for
 software, Computer Associates v. Altai, the plaintiff alleged that its
 program, Adapter, which was used to handle the differences in operating
 system calls and services, was infringed by the defendant's competitive
 program, Oscar. About 30\% of Oscar was literally the same code as
 that in Adapter. After the suit began, the defendant rewrote those
 portions of Oscar that contained Adapter code in order to produce a new
 version of Oscar that was functionally competitive with Adapter, without
 having any literal copies of its code. Feeling slighted still, the
 plaintiff alleged that even the second version of Oscar, despite having no
 literally copied code, also infringed its copyrights. In addressing that
 question, the Second Circuit promulgated the AFC test.
 In abstracting the various levels of the program, the court noted a
 similarity between the two programs' parameter lists and macros. However,
 following the filtration step of the AFC test, only a handful of the lists
 and macros were protectable under copyright law because they were either
 in the public domain or required by functional demands on the
 program. With respect to the handful of parameter lists and macros that
 did qualify for copyright protection, after performing the comparison step
 of the AFC test, it was reasonable for the district court to conclude that
 they did not warrant a finding of infringement given their relatively minor
 contribution to the program as a whole. Likewise, the similarity between
 the organizational charts of the two programs was not substantial enough
 to support a finding of infringement because they were too simple and
 obvious to contain any original expression.
 In the case of Oracle America v. Google, 872 F. Supp.2d 974 (N.D. Cal. 2012),
 the Northern District of California District Court examined the question of
 whether the application program interfaces (APIs) associated with the Java
 programming language are entitled to copyright protection.  While the
 court expressly declined to rule whether all APIs are free to use without
 license (872 F. Supp.2d 974 at 1002), the court held that the command
 structure and taxonomy of the APIs were not protectable under copyright law.
 Specifically, the court characterized the command structure and taxonomy as
 both a ``method of operation'' (using an approach not dissimilar to the
 First Circuit's analysis in Lotus) and a ``functional requirement for
 compatibility'' (using Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992) and
 Sony Computer Ent. v. Connectix, 203 F.3d 596 (9th Cir. 2000) as analogies),
 and thus unprotectable subject matter under \S~102(b).
 Perhaps not surprisingly, there have been few other cases involving a highly
 detailed software derivative work analysis. Most often, cases involve
 clearer basis for decision, including frequent bad faith on the part of
 the defendant or over-aggressiveness on the part of the plaintiff.
 \section{How Much Do Derivative Works Matter?}
 It is certainly true that GPL intends for any work that is determined a
 ``derivative work'' under copyright law must be licensed as a whole under
 GPL\@, as will be discussed in the following chapter.  However, as we finish
 up our discussion derivative works, we must note that preparation of a
 derivative work is by far not the only way to create a new work covered by
 GPL\@.
 In fact, while derivative work preparation is perhaps the most exciting area
 of legal issues to consider, the more mundane ways to create a new work
 covered by GPL are much more common.  For example, copyright statutes
 generally require permission from the copyright holder to grant explicit
 permission to modify a work in any manner.  As discussed in the next chapter,
 the GPL {\em does} grants such permission, but requires the modify work must
 also be licensed under the terms of the GPL (and only GPL:
 see\S~\label{GPLv2s6} in this tutorial).  Determining whether software was
 modified is a substantially easier analysis than the derivative work
 discussions and considerations in this chapter.
 The question of derivative works, when and how they are made, is undoubtedly
 an essential discussion in the interpretation and consideration of copyleft.
 That is why this chapter was included in this tutorial.  However, as we
 return from this digression and resume discussion of the detailed text of the
 GPLv2, we must gain a sense of perspective: most GPL questions center around
 questions of modification and distribution, not preparation of derivative
 works.  Derivative work preparation is ultimately a small subset of the types
 of modified versions of the software a developer might create, thus, while an
 excessive focus on derivative works indulges us in the more exciting areas of
 copyleft, we must keep a sense of perspective regarding their relative
 importance.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Modified Source and Binary Distribution}
 \label{source-and-binary}
 In this chapter, we discuss the two core sections that define the rights
 and obligations for those who modify, improve, and/or redistribute GPL'd
 software. These sections, GPLv2~\S\S2--3, define the central core rights and
 requirements of GPLv2\@.
 \section{GPLv2~\S2: Share and Share Alike}
 \label{GPLv2s2}
 For many, this is where the ``magic'' happens that defends software
 freedom upon redistribution.  GPLv2~\S2 is the only place in GPLv2
 that governs the modification controls of copyright law.  If users
 distribute modified versions a GPLv2'd program, they must follow the terms of GPLv2~\S2 in making
 those changes.  Thus, this sections ensures that the body of GPL'd software, as it
 continues and develops, remains Free as in freedom.
 To achieve that goal, GPLv2~\S2 first sets forth that the rights of
 redistribution of modified versions are the same as those for verbatim
 copying, as presented in GPLv2~\S1.  Therefore, the details of charging money,
 keeping copyright notices intact, and other GPLv2~\S1 provisions are intact
 here as well.  However, there are three additional requirements.
 The first (GPLv2~\S2(a)) requires that modified files carry ``prominent
 notices'' explaining what changes were made and the date of such
 changes. This section does not prescribe some specific way of
 marking changes nor does it control the process of how changes are made.
 Primarily, GPLv2~\S2(a) seeks to ensure that those receiving modified
 versions know the history of changes to the software.  For some users,
 it is important to know that they are using the standard version of
 program, because while there are many advantages to using a fork,
 there are a few disadvantages.  Users should be informed about the
 historical context of the software version they use, so that they can
 make proper support choices.  Finally, GPLv2~\S2(a) serves an academic
 purpose --- ensuring that future developers can use a diachronic
 approach to understand the software.
 \medskip
 The second requirement (GPLv2~\S2(b)) contains the four short lines that embody
 the legal details of ``share and share alike''.  These 46 words are
 considered by some to be the most worthy of careful scrutiny because
 GPLv2~\S2(b), and they
 can be a source of great confusion when not properly understood.
 In considering GPLv2~\S2(b), first note the qualifier: it \textit{only} applies to
 derivative works that ``you distribute or publish''.  Despite years of
+derivative, combined and/or modified works that ``you distribute or publish''.  Despite years of
 education efforts on this matter, many still believe that modifiers
 of GPL'd software \textit{must} publish or otherwise
 share their changes.  On the contrary, GPLv2~\S2(b) {\bf does not apply if} the
 changes are never distributed.  Indeed, the freedom to make private,
 personal, unshared changes to software for personal use only should be
 protected and defended.\footnote{Most Free Software enthusiasts believe there is a {\bf
     moral} obligation to redistribute changes that are generally useful,
   and they often encourage companies and individuals to do so.  However, there
   is a clear distinction between what one {\bf ought} to do and what one
   {\bf must} do.}
 Next, we again encounter the same matter that appears in GPLv2~\S0, in the
 following text:
 \begin{quote}
 ``...that in whole or part contains or is derived from the Program or any part thereof.''
 \end{quote}
 Again, the GPL relies here on what the copyright law says is a derivative
 work.  If, under copyright law, the modified version ``contains or is
 Again, the GPL relies here on copyright law.
 If, under copyright law, the modified version ``contains or is
 derived from'' the GPL'd software, then the requirements of GPLv2~\S2(b)
 apply.  The GPL invokes its control as a copyright license over the
 modification of the work in combination with its control over distribution
 of the work.
 The final clause of GPLv2~\S2(b) describes what the licensee must do if she is
 distributing or publishing a work that is deemed a derivative work under
 copyright law --- namely, the following:
 The final clause of GPLv2~\S2(b) describes what the licensee must do if she
 distributes or publishes a modified version of the work --- namely, the following:
 \begin{quote}
 [The work must] be licensed as a whole at no charge to all third parties
 under the terms of this License.
 \end{quote}
 That is probably the most tightly-packed phrase in all of the GPL\@.
 Consider each subpart carefully.
 The work ``as a whole'' is what is to be licensed. This is an important
 point that GPLv2~\S2 spends an entire paragraph explaining; thus this phrase is
 worthy of a lengthy discussion here.  As a programmer modifies a software
 program, she generates new copyrighted material --- fixing expressions of
 ideas into the tangible medium of electronic file storage.  That
 programmer is indeed the copyright holder of those new changes.  However,
 those changes are part and parcel to the original work distributed to
 the programmer under GPL\@. Thus, the license of the original work
 affects the license of the new whole derivative work.
+affects the license of the new whole combined and/or derivative work.
 % {\cal I}
 \newcommand{\gplusi}{$\mathcal{G\!\!+\!\!I}$}
 \newcommand{\worki}{$\mathcal{I}$}
 \newcommand{\workg}{$\mathcal{G}$}
 \label{separate-and-independent}
 It is certainly possible to take an existing independent work (called
 \worki{}) and combine it with a GPL'd program (called \workg{}).  The
 license of \worki{}, when it is distributed as a separate and independent
 work, remains the prerogative of the copyright holder of \worki{}.
 However, when \worki{} is combined with \workg{}, it produces a new work
 that is the combination of the two (called \gplusi{}). The copyright of
 this combined work, \gplusi{}, is held by the original copyright
 holder of each of the two works.
 In this case, GPLv2~\S2 lays out the terms by which \gplusi{} may be
 distributed and copied.  By default, under copyright law, the copyright
 holder of \worki{} would not have been permitted to distribute \gplusi{};
 copyright law forbids it without the expressed permission of the copyright
 holder of \workg{}. (Imagine, for a moment, if \workg{} were a proprietary
 product --- would its copyright holders  give you permission to create and distribute
 \gplusi{} without paying them a hefty sum?)  The license of \workg{}, the
 GPL, states the  options for the copyright holder of \worki{}
 who may want to create and distribute \gplusi{}. The  GPL's pre-granted
 permission to create and distribute derivative works, provided the terms
+permission to create and distribute combined and/or derivative works, provided the terms
 of the GPL are upheld, goes far above and beyond the permissions that one
 would get with a typical work not covered by a copyleft license.  (Thus, to
 say that this condition is any way unreasonable is simply ludicrous.)
 \medskip
 \label{GPLv2s2-at-no-charge}
 The next phrase of note in GPLv2~\S2(b) is ``licensed \ldots at no charge.''
 This phrase  confuses many.  The sloppy reader points out this as ``a
 contradiction in GPL'' because (in their confused view) that clause of GPLv2~\S2 says that re-distributors cannot
 charge for modified versions of GPL'd software, but GPLv2~\S1 says that
 they can.  Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit re-distributors from
 charging when performing the acts governed by copyright
 law,\footnote{Recall that you could by default charge for any acts not
 governed by copyright law, because the license controls are confined
 by copyright.} but rather that they cannot charge a fee for the
 \emph{license itself}.  In other words, redistributors of (modified
 and unmodified) GPL'd works may charge any amount they choose for
 performing the modifications on contract or the act of transferring
 the copy to the customer, but they may not charge a separate licensing
 fee for the software.
 GPLv2~\S2(b) further states that the software must ``be licensed \ldots to all
 third parties.''  This too yields some confusion, and feeds the
 misconception mentioned earlier --- that all modified versions must be made
 available to the public at large.  However, the text here does not say
 that.  Instead, it says that the licensing under terms of the GPL must
 extend to anyone who might, through the distribution chain, receive a copy
 of the software.  Distribution to all third parties is not mandated here,
-but GPLv2~\S2(b) does require re-distributors to license the derivative works in
+but GPLv2~\S2(b) does require re-distributors to license the whole work in
 a way that extends to all third parties who may ultimately receive a
 copy of the software.
 In summary, GPLv2\ 2(b) says what terms under which the third parties must
 receive this no-charge license.  Namely, they receive it ``under the terms
 of this License'', the GPLv2.  When an entity \emph{chooses} to redistribute
-a derivative work of GPL'd software, the license of that whole
+a work based on GPL'd software, the license of that whole
 work must be GPL and only GPL\@.  In this manner, GPLv2~\S2(b) dovetails nicely
 with GPLv2~\S6 (as discussed in Section~\ref{GPLv2s6} of this tutorial).
 \medskip
 The final paragraph of GPLv2~\S2 is worth special mention.  It is possible and
 quite common to aggregate various software programs together on one
 distribution medium.  Computer manufacturers do this when they ship a
 pre-installed hard drive, and GNU/Linux distribution vendors do this to
 give a one-stop CD or URL for a complete operating system with necessary
 applications.  The GPL very clearly permits such ``mere aggregation'' with
 programs under any license.  Despite what you hear from its critics, the
 GPL is nothing like a virus, not only because the GPL is good for you and
 a virus is bad for you, but also because simple contact with a GPL'd
 code-base does not impact the license of other programs.  A programmer must
 expend actual effort  to cause a work to fall under the terms
 of the GPL.  Redistributors are always welcome to simply ship GPL'd
 software alongside proprietary software or other unrelated Free Software,
 as long as the terms of GPL are adhered to for those packages that are
 truly GPL'd.
 \subsection{Right to Private Modification}
 \label{gplv2-private-modification}
 The issue of private modifications of GPLv2'd works deserves special
 attention.  While these rights are clearly explicit in GPLv3~\S2\P2 (see
 \S~\ref{GPLv3S2} of this tutorial for details), the permission to create
 private modifications is mostly implicit in GPLv2.  Most notably, the
 requirements of GPLv2~\S2 (and GPLv2~\S3, which will be discussed next) are
 centered around two different copyright controls: both modification
 \emph{and} distribution.  As such, GPLv2~\S2's requirements need only be met
 when a modified version is distributed; one need not follow them for modified
 versions that are not distributed\footnote{As a matter of best practice, it's
   useful to assume that all software may eventually be distributed later,
   even if there no plans for distribution at this time.  Too often, GPL
   violations occur because of a late distribution decision of software that
   was otherwise never intended for distribution.}.
 However, the careful reader of GPLv2 will notice that, unlike GPLv3, no other
 clauses of the license actually give explicit permission to make private
 modifications.  Since modification of software is a control governed by
 copyright, a modifier needs permission from the copyright holder to engage in
 that activity.
 In practice, however, traditional GPLv2 interpretation has always assumed
 that blanket permission to create non-distributed modified versions was
 available, and the
 \href{http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic}{FSF
   has long opined that distribution of modified versions is never mandatory}.
 This issue is one of many where GPLv3 clarifies in explicit text the implicit
 policy and intent that was solidified via long-standing interpretation of
 GPLv2.
 \section{GPLv2~\S3: Producing Binaries}
 \label{GPLv2s3}
 Software is a strange beast when compared to other copyrightable works.
 It is currently impossible to make a film or a book that can be truly
 obscured.  Ultimately, the full text of a novel, even one written by
 William Faulkner, must be presented to the reader as words in some
 human-readable language so that they can enjoy the work.  A film, even one
 directed by David Lynch, must be perceptible by human eyes and ears to
 have any value.
 Software is not so.  While the source code --- the human-readable
 representation of software --- is of keen interest to programmers, users and
 programmers alike cannot make the proper use of software in that
 human-readable form.  Binary code --- the ones and zeros that the computer
 can understand --- must be predicable and attainable for the software to
 be fully useful.  Without the binaries, be they in object or executable
 form, the software serves only the didactic purposes of computer science.
 Under copyright law, binary representations of the software are simply
 derivative works of the source code.  Applying a systematic process (i.e.,
+modified versions (and/or derivative works) of the source code.  Applying a systematic process (i.e.,
 ``compilation''\footnote{``Compilation'' in this context refers to the
   automated computing process of converting source code into binaries.  It
   has absolutely nothing to do with the term ``compilation'' in copyright statues.}) to a work of source code yields binary code. The binary
 code is now a new work of expression fixed in the tangible medium of
 electronic file storage.
 Therefore, for GPL'd software to be useful, the GPL, since it governs the
-rules for creation of derivative works, must grant permission for the
+rules for creation of modified works, must grant permission for the
 generation of binaries.  Furthermore, notwithstanding the relative
 popularity of source-based GNU/Linux distributions like Gentoo, users find
 it extremely convenient to receive distribution of binary software.  Such
-distribution is the redistribution of derivative works of the software's
+distribution is the redistribution of modified works of the software's
 source code.  GPLv2~\S3 addresses the matter of creation and distribution of
 binary versions.
 Under GPLv2~\S3, binary versions may be created and distributed under the
 terms of GPLv2~\S1--2, so all the material previously discussed applies
 here.  However, GPLv2~\S3 must go a bit further.  Access to the software's
 source code is an incontestable prerequisite for the exercise of the
 fundamental freedoms to modify and improve the software.  Making even
 the most trivial changes to a software program at the binary level is
 effectively impossible.  GPLv2~\S3 must ensure that the binaries are never
 distributed without the source code, so that these freedoms are passed
 through the distribution chain.
 GPLv2~\S3 permits distribution of binaries, and then offers three options for
 distribution of source code along with binaries. The most common and the
 least complicated is the option given under GPLv2~\S3(a).
 GPLv2~\S3(a) offers the option to directly accompany the source code alongside
 the distribution of the binaries.  This is by far the most convenient
 option for most distributors, because it means that the source-code
 provision obligations are fully completed at the time of binary
 distribution (more on that later).
 Under GPLv2~\S3(a), the source code provided must be the ``corresponding source
 code.''  Here ``corresponding'' primarily means that the source code
 provided must be that code used to produce the binaries being distributed.
 That source code must also be ``complete''.   GPLv2~\S3's penultimate paragraph
 explains in detail what is meant by ``complete''.  In essence, it is all
 the material that a programmer of average skill would need to actually use
 the source code to produce the binaries she has received.  Complete source
 is required so that, if the licensee chooses, she should be able to
 exercise her freedoms to modify and redistribute changes.  Without the
 complete source, it would not be possible to make changes that were
 actually directly derived from the version received.
 Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been
 seen in GPL enforcement.  Under GPL, if you pay a high price for
 a copy of GPL'd binaries (which comes with corresponding source, of
 course), you have the freedom to redistribute that work at any fee you
 choose, or not at all.  Sometimes, companies attempt a GPL-violating
 cozenage whereby they produce very specialized binaries (perhaps for
 an obscure architecture).  They then give source code that does
 correspond, but withhold the ``incantations'' and build plans they
 used to make that source compile into the specialized binaries.
 Therefore, GPLv2~\S3 requires that the source code include ``meta-material'' like
 scripts, interface definitions, and other material that is used to
 ``control compilation and installation'' of the binaries.  In this
 manner, those further down the distribution chain are assured that
-they have the unabated freedom to build their own derivative works
+they have the unabated freedom to build their own modified works
 from the sources provided.
 Software distribution comes in many
 forms.  Embedded manufacturers, for example, have the freedom to put
 GPL'd software into mobile devices with very tight memory and space
 constraints.  In such cases, putting the source right alongside the
 binaries on the machine itself might not be an option.  While it is
 recommended that this be the default way that people comply with GPL, the
 GPL does provide options when such distribution is unfeasible.
 \label{GPLv2s3-medium-customarily}
 GPLv2~\S3, therefore, allows source code to be provided on any physical
 ``medium customarily used for software interchange.''  By design, this
 phrase covers a broad spectrum --- the phrase seeks to pre-adapt to
 changes in  technology.  When GPLv2 was first published in June
 , distribution on magnetic tape was still common, and CD was
 relatively new.  By 2002, CD was the default.  By 2007, DVD's were the
 default.  Now, it's common to give software on USB drives and SD cards.  This
 language in the license must adapt with changing technology.
 Meanwhile, the binding created by the word ``customarily'' is key.  Many
 incorrectly believe that distributing binary on CD and source on the
 Internet is acceptable.  In the corporate world in industrialized countries, it is indeed customary to
 simply download a CDs' worth of data quickly.  However, even today in the USA, many computer users are not connected to the Internet, and most people connected
 to the Internet still have limited download speeds.  Downloading
 CDs full of data is not customary for them in the least.  In some cities
 in Africa, computers are becoming more common, but Internet connectivity
 is still available only at a few centralized locations.  Thus, the
 ``customs'' here are normalized for a worldwide userbase.  Simply
 providing source on the Internet --- while it is a kind, friendly and
 useful thing to do --- is not usually sufficient.
 Note, however, a major exception to this rule, given by the last paragraph
 of GPLv2~\S3. \emph{If} distribution of the binary files is made only on the
 Internet (i.e., ``from a designated place''), \emph{then} simply providing
 the source code right alongside the binaries in the same place is
 sufficient to comply with GPLv2~\S3.
 \medskip
 As is shown above, under GPLv2~\S3(a), embedded manufacturers can put the
 binaries on the device and ship the source code along on a CD\@.  However,
 sometimes this turns out to be too costly.  Including a CD with every
 device could prove too costly, and may practically (although not legally)
 prohibit using GPL'd software. For this situation and others like it, GPLv2\S~3(b) is available.
 GPLv2~\S3(b) allows a distributor of binaries to instead provide a written
 offer for source code alongside those binaries.  This is useful in two
 specific ways.  First, it may turn out that most users do not request the
 source, and thus the cost of producing the CDs is saved --- a financial
 and environmental windfall.  In addition, along with a GPLv2~\S3(b) compliant
 offer for source, a binary distributor might choose to \emph{also} give a
 URL for source code.  Many who would otherwise need a CD with source might
 turn out to have those coveted high bandwidth connections, and are able to
 download the source instead --- again yielding environmental and financial
 windfalls.
 However, note that regardless of how many users prefer to get the
 source online, GPLv2~\S3(b) does place lasting long-term obligations on the
 binary distributor.  The binary distributor must be prepared to honor
 that offer for source for three years and ship it out (just as they
 would have had to do under GPLv2~\S3(a)) at a moment's notice when they
 receive such a request.  There is real organizational cost here:
 support engineers must be trained how to route source requests, and
 source CD images for every release version for the last three years
 must be kept on hand to burn such CDs quickly. The requests might not
 even come from actual customers; the offer for source must be valid
 for ``any third party''.
 That phrase is another place where some get confused --- thinking again
 that full public distribution of source is required.  The offer for source
 must be valid for ``any third party'' because of the freedoms of
 redistribution granted by GPLv2~\S\S1--2.  A company may ship a binary image
 and an offer for source to only one customer.  However, under GPL, that
 customer has the right to redistribute that software to the world if she
 likes.  When she does, that customer has an obligation to make sure that
 those who receive the software from her can exercise their freedoms under
 GPL --- including the freedom to modify, rebuild, and redistribute the
 source code.
 GPLv2~\S3(c) is created to save her some trouble, because by itself GPLv2~\S3(b)
 would unfairly favor large companies.  GPLv2~\S3(b) allows the
 separation of the binary software from the key tool that people can use
 to exercise their freedom. The GPL permits this separation because it is
 good for re-distributors, and those users who turn out not to need the
 source.  However, to ensure equal rights for all software users, anyone
 along the distribution chain must have the right to get the source and
 exercise those freedoms that require it.
 Meanwhile, GPLv2~\S3(b)'s compromise primarily benefits companies that
 distribute binary software commercially.  Without GPLv2~\S3(c), that benefit
 would be at the detriment of the companies' customers; the burden of
 source code provision would be unfairly shifted to the companies'
 customers.  A customer, who had received binaries with a GPLv2~\S3(b)-compliant
 offer, would be required under GPLv2 (sans GPLv2~\S3(c)) to acquire the source,
 merely to give a copy of the software to a friend who needed it.  GPLv2~\S3(c)
 reshifts this burden to entity who benefits from GPLv2~\S3(b).
 GPLv2~\S3(c) allows those who undertake \emph{noncommercial} distribution to
 simply pass along a GPLv2~\S3(b)-compliant source code offer.  The customer who
 wishes to give a copy to her friend can now do so without provisioning the
 source, as long as she gives that offer to her friend.  By contrast, if
 she wanted to go into business for herself selling CDs of that software,
 she would have to acquire the source and either comply via GPLv2~\S3(a), or
 write her own GPLv2~\S3(b)-compliant source offer.
 This process is precisely the reason why a GPLv2~\S3(b) source offer must be
 valid for all third parties.  At the time the offer is made, there is no
 way of knowing who might end up noncommercially receiving a copy of the
 software.  Companies who choose to comply via GPLv2~\S3(b) must thus be
 prepared to honor all incoming source code requests.  For this and the
 many other additional necessary complications under GPLv2~\S\S3(b--c), it is
 only rarely a better option than complying via GPLv2~\S3(a).
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{GPL's Implied Patent Grant}
 \label{gpl-implied-patent-grant}
 We digress again briefly from our section-by-section consideration of GPLv2
 to consider the interaction between the terms of GPL and patent law. The
 GPLv2, despite being silent with respect to patents, actually confers on its
 licensees more rights to a licensor's patents than those licenses that
 purport to address the issue. This is the case because patent law, under
 the doctrine of implied license, gives to each distributee of a patented
 article a license from the distributor to practice any patent claims owned
 or held by the distributor that cover the distributed article. The
 implied license also extends to any patent claims owned or held by the
 distributor that cover ``reasonably contemplated uses'' of the patented
 article. To quote the Federal Circuit Court of Appeals, the highest court
 for patent cases other than the Supreme Court:
 \begin{quotation}
 Generally, when a seller sells a product without restriction, it in
 effect promises the purchaser that in exchange for the price paid, it will
 not interfere with the purchaser's full enjoyment of the product
 purchased. The buyer has an implied license under any patents of the
 seller that dominate the product or any uses of the product to which the
 parties might reasonably contemplate the product will be put.
 \end{quotation}
 Hewlett-Packard Co. v. Repeat-O-Type Stencil Mfg. Corp., Inc., 123 F.3d
 , 1451 (Fed. Cir. 1997).
 Of course, Free Software is licensed, not sold, and there are indeed
 restrictions placed on the licensee, but those differences are not likely
 to prevent the application of the implied license doctrine to Free
 Software, because software licensed under the GPL grants the licensee the
 right to make, use, and sell the software, each of which are exclusive
 rights of a patent holder. Therefore, although the GPLv2 does not expressly
 grant the licensee the right to do those things under any patents the
 licensor may have that cover the software or its reasonably contemplated
 uses, by licensing the software under the GPLv2, the distributor impliedly
 licenses those patents to the GPLv2 licensee with respect to the GPLv2'd
 software.
 An interesting issue regarding this implied patent license of GPLv2'd
 software is what would be considered ``uses of the [software] to which
 the parties might reasonably contemplate the product will be put.'' A
 clever advocate may argue that the implied license granted by GPLv2 is
 larger in scope than the express license in other Free Software
 licenses with express patent grants, in that the patent license
 clause of many of those other Free  Software licenses are specifically
 limited to the patent claims covered by the code as licensed by the patentee.
 In contrast, a GPLv2 licensee, under the doctrine of implied patent license,
 is free to practice any patent claims held by the licensor that cover
 ``reasonably contemplated uses'' of the GPL'd code, which may very well
-include creation and distribution of derivative works since the GPL's terms,
+include creation and distribution of modified works since the GPL's terms,
 under which the patented code is distributed, expressly permits such activity.
 Further supporting this result is the Federal Circuit's pronouncement that
 the recipient of a patented article has, not only an implied license to
 make, use, and sell the article, but also an implied patent license to
 repair the article to enable it to function properly, Bottom Line Mgmt.,
 Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the
 Federal Circuit extended that rule to include any future recipients of the
 patented article, not just the direct recipient from the distributor.
 This theory comports well with the idea of Free Software, whereby software
 is distributed among many entities within the community for the purpose
 of constant evolution and improvement. In this way, the law of implied
 patent license used by the GPLv2 ensures that the community mutually
 benefits from the licensing of patents to any single community member.
 Note that simply because GPLv2'd software has an implied patent license does
 not mean that any patents held by a distributor of GPLv2'd code become
 worthless. To the contrary, the patents are still valid and enforceable
 against either:
 \begin{enumerate}
  \renewcommand{\theenumi}{\alph{enumi}}
  \renewcommand{\labelenumi}{\textup{(\theenumi)}}
 \item any software other than that licensed under the GPLv2 by the patent
   holder, and
 \item any party that does not comply with the GPLv2
 with respect to the licensed software.
 \end{enumerate}
 \newcommand{\compB}{$\mathcal{B}$}
 \newcommand{\compA}{$\mathcal{A}$}
 For example, if Company \compA{} has a patent on advanced Web browsing, but
 also licenses a Web browsing program under the GPLv2, then it
 cannot assert the patent against any party based on that party's use of
 Company \compA{}'s GPL'ed Web browsing software program, or on that party's
-creation and use of derivative works of that GPL'ed program.  However, if a
+creation and use of modified versions of that GPL'ed program.  However, if a
 party uses that program without
 complying with the GPLv2, then Company \compA{} can assert both copyright
 infringement claims against the non-GPLv2-compliant party and
 infringement of the patent, because the implied patent license only
 extends to use of the software in accordance with the GPLv2. Further, if
 Company \compB{} distributes a competitive advanced Web browsing program
-that is not a derivative work of Company \compA{}'s GPL'd Web browsing software
+that is not a modified version of Company \compA{}'s GPL'd Web browsing software
 program, Company \compA{} is free to assert its patent against any user or
 distributor of that product. It is irrelevant whether Company \compB's
 program is also distributed under the GPLv2, as Company \compB{} can not grant
 implied licenses to Company \compA's patent.
 This result also reassures companies that they need not fear losing their
 proprietary value in patents to competitors through the GPLv2 implied patent
 license, as only those competitors who adopt and comply with the GPLv2's
 terms can benefit from the implied patent license. To continue the
 example above, Company \compB{} does not receive a free ride on Company
 \compA's patent, as Company \compB{} has not licensed-in and then
 redistributed Company A's advanced Web browser under the GPLv2. If Company
 \compB{} does do that, however, Company \compA{} still has not lost
 competitive advantage against Company \compB{}, as Company \compB{} must then,
 when it re-distributes Company \compA's program, grant an implied license
 to any of its patents that cover the program. Further, if Company \compB{}
 relicenses an improved version of Company A's program, it must do so under
 the GPLv2, meaning that any patents it holds that cover the improved version
 are impliedly licensed to any licensee. As such, the only way Company
 \compB{} can benefit from Company \compA's implied patent license, is if it,
 itself, distributes Company \compA's software program and grants an
 implied patent license to any of its patents that cover that program.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Defending Freedom on Many Fronts}
 Chapters~\ref{run-and-verbatim} and~\ref{source-and-binary} presented the
 core freedom-defending provisions of GPLv2\@, which are in GPLv2~\S\S0--3.
 GPLv2\S\S~4--7 of the GPLv2 are designed to ensure that GPLv2~\S\S0--3 are
 not infringed, are enforceable, are kept to the confines of copyright law but
 also  not trumped by other copyright agreements or components of other
 entirely separate legal systems.  In short, while GPLv2~\S\S0--3 are the parts
 of the license that defend the freedoms of users and programmers,
 GPLv2~\S\S4--7 are the parts of the license that keep the playing field clear
 so that \S\S~0--3 can do their jobs.
 \section{GPLv2~\S4: Termination on Violation}
 \label{GPLv2s4}
 GPLv2~\S4 is GPLv2's termination clause.  Upon first examination, it seems
 strange that a license with the goal of defending users' and programmers'
 freedoms for perpetuity in an irrevocable way would have such a clause.
 However, upon further examination, the difference between irrevocability
 and this termination clause becomes clear.
 The GPL is irrevocable in the sense that once a copyright holder grants
 rights for someone to copy, modify and redistribute the software under terms
 of the GPL, they cannot later revoke that grant.  Since the GPL has no
 provision allowing the copyright holder to take such a prerogative, the
 license is granted as long as the copyright remains in effect.\footnote{In
   the USA, due to unfortunate legislation, the length of copyright is nearly
   perpetual, even though the Constitution forbids perpetual copyright.} The
 copyright holders have the right to relicense the same work under different
 licenses (see Section~\ref{Proprietary Relicensing} of this tutorial), or to
 stop distributing the GPLv2'd version (assuming GPLv2~\S3(b) was never used),
 but they may not revoke the rights under GPLv2 already granted.
 In fact, when an entity loses their right to copy, modify and distribute
 GPL'd software, it is because of their \emph{own actions}, not that of the
 copyright holder.  The copyright holder does not decide when GPLv2~\S4
 termination occurs (if ever); rather, the actions of the licensee determine
 that.
 Under copyright law, the GPL has granted various rights and freedoms to
 the licensee to perform specific types of copying, modification, and
 redistribution.  By default, all other types of copying, modification, and
 redistribution are prohibited.  GPLv2~\S4 says that if you undertake any of
 those other types (e.g., redistributing binary-only in violation of GPLv2~\S3),
 then all rights under the license --- even those otherwise permitted for
 those who have not violated --- terminate automatically.
 GPLv2~\S4 makes GPLv2 enforceable.  If licensees fail to adhere to the
 license, then they are stuck without any permission under to engage in
 activities covered by copyright law.  They must completely cease and desist
 from all copying, modification and distribution of the GPL'd software.
 At that point, violating licensees must gain the forgiveness of the copyright
 holders to have their rights restored.  Alternatively, the violators could
 negotiate another agreement, separate from GPL, with the copyright
 holder.  Both are common practice, although
 \tutorialpartsplit{as discussed in \textit{A Practical Guide to GPL
     Compliance}, there are }{Chapter~\ref{compliance-understanding-whos-enforcing}
   explains further} key differences between these two very different uses of GPL.
 \section{GPLv2~\S5: Acceptance, Copyright Style}
 \label{GPLv2s5}
 GPLv2~\S5 brings us to perhaps the most fundamental misconception and common
 confusion about GPLv2\@. Because of the prevalence of proprietary software,
 most users, programmers, and lawyers alike tend to be more familiar with
 EULAs. EULAs are believed by their authors to be contracts, requiring
 formal agreement between the licensee and the software distributor to be
 valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap''
 as mechanisms to perform acceptance ceremonies with EULAs.
 The GPL does not need contract law to ``transfer rights.''  Usually, no rights
 are transferred between parties.  By contrast, the GPL is primarily a permission
 slip to undertake activities that would otherwise have been prohibited
 by copyright law.  As such, GPL needs no acceptance ceremony; the
 licensee is not even required to accept the license.
 However, without the GPL, the activities of copying, modifying and
 distributing the software would have otherwise been prohibited.  So, the
 GPL says that you only accepted the license by undertaking activities that
 you would have otherwise been prohibited without your license under GPL\@.
 This is a certainly subtle point, and requires a mindset quite different
 from the contractual approach taken by EULA authors.
 An interesting side benefit to GPLv2~\S5 is that the bulk of users of Free
 Software are not required to accept the license.  Undertaking fair and
 unregulated use of the work, for example, does not bind you to the GPL,
 since you are not engaging in activity that is otherwise controlled by
 copyright law.  Only when you engage in those activities that might have an
 impact on the freedom of others does license acceptance occur, and the
 terms begin to bind you to fair and equitable sharing of the software.  In
 other words, the GPL only kicks in when it needs to for the sake of
 freedom.
 While GPL is by default a copyright license, it is certainly still possible
 to consider GPL as a contract as well.  For example, some distributors chose
 to ``wrap'' their software in an acceptance ceremony to the GPL, and nothing in
 the GPL prohibits that use.  Furthermore, the ruling in \textit{Jacobsen
   v. Katzer, 535 F.3d 1373, 1380 (Fed.Cir.2008)} indicates that \textbf{both}
 copyright and contractual remedies may be sought by a copyright holder
 seeking to enforce a license designed to uphold software freedom.
 % FIXME-LATER: Write this
 %\section{Using GPL Both as a Contract and Copyright License}
 \section{GPLv2~\S6: GPL, My One and Only}
 \label{GPLv2s6}
 A point that was glossed over in Section~\ref{GPLv2s4}'s discussion of GPLv2~\S4
 was the irrevocable nature of the GPL\@. The GPLv2 is indeed irrevocable,
 and it is made so formally by GPLv2~\S6.
 The first sentence in GPLv2~\S6 ensures that as software propagates down the
 distribution chain, that each licensor can pass along the license to each
 new licensee.  Under GPLv2~\S6, the act of distributing automatically grants a
 license from the original licensor to the next recipient.  This creates a
 chain of grants that ensure that everyone in the distribution has rights
 under the GPLv2\@.  In a mathematical sense, this bounds the bottom ---
 making sure that future licensees get no fewer rights than the licensee before.
 The second sentence of GPLv2~\S6 does the opposite; it bounds from the top.  It
 prohibits any licensor along the distribution chain from placing
 additional restrictions on the user.  In other words, no additional
 requirements may trump the rights and freedoms given by GPLv2\@.
 The final sentence of GPLv2~\S6 makes it abundantly clear that no individual
 entity in the distribution chain is responsible for the compliance of any
 other.  This is particularly important for noncommercial users who have
 passed along a source offer under GPLv2~\S3(c), as they cannot be assured that
 the issuer of the offer will honor their GPLv2~\S3 obligations.
 In short, GPLv2~\S6 says that your license for the software is your one and
 only copyright license allowing you to copy, modify and distribute the
 software.
 \section{GPLv2~\S7: ``Give Software Liberty or Give It Death!''}
 \label{GPLv2s7}
 In essence, GPLv2~\S7 is a verbosely worded way of saying for non-copyright
 systems what GPLv2~\S6 says for copyright.  If there exists any reason that a
 distributor knows of that would prohibit later licensees from exercising
 their full rights under GPL, then distribution is prohibited.
 Originally, this was designed as the title of this section suggests --- as
 a last ditch effort to make sure that freedom was upheld.  However, in
 modern times, it has come to give much more.  Now that the body of GPL'd
 software is so large, patent holders who would want to be distributors of
 GPL'd software have a tough choice.  They must choose between avoiding
 distribution of GPL'd software that exercises the teachings of their
 patents, or grant a royalty-free, irrevocable, non-exclusive license to
 those patents.  Many companies have chosen the latter.
 Thus, GPLv2~\S7 rarely gives software death by stopping its distribution.
 Instead, it is inspiring patent holders to share their patents in the same
 freedom-defending way that they share their copyrighted works.
 \section{GPLv2~\S8: Excluding Problematic Jurisdictions}
 \label{GPLv2s8}
 GPLv2~\S8 is rarely used by copyright holders.  Its intention is that if a
 particular country, say Unfreedonia, grants particular patents or allows
 copyrighted interfaces (no country to our knowledge even permits those
 yet), that the GPLv2'd software can continue in free and unabated
 distribution in the countries where such controls do not exist.
 As far as is currently known, GPLv2~\S8 has very rarely been formally used by
 copyright holders.  Admittedly, some have used GPLv2~\S8 to explain various
@@ ... @@
 the GPLv3 drafting process.  This issue was hotly debated during the drafting of
 GPLv3, but ultimately one specific deal of this type --- a deal between Microsoft
 and Novell for Microsoft to provide so-called ``coupons'' to Microsoft customers to redeem
 for copies of Novell's GNU/Linux distribution with a Microsoft patent license -- was
 designed to be excluded.
 The main reason for this was a tactical decision by the FSF.  FSF believed they can do more to
 protect the community by allowing Novell to use software under GPLv3
 than by forbidding it to do so.  This is because of
 paragraph 6 of section 11 (corresponding to paragraph 4 in Draft 3).
 It will apply, under the Microsoft/Novell deal, because of the coupons
 that Microsoft has acquired that essentially commit it to participate
 in the distribution of the Novell SLES GNU/Linux system.
 The FSF also gave a secondary reason:  to avoid affecting other kinds of agreements for
 other kinds of activities.  While GPLv3 sought to
 distinguish pernicious deals of the Microsoft/Novell type from
 business conduct that is not particularly harmful, the FSF also did not
 assume success in that drafting, and thus there remained some risk that other
 unchangeable past agreements could fall within the  scope of GPLv3~\S11\P7.
 In future deals, distributors engaging in ordinary business practices
 can structure the agreements so that they do not fall under GPLv3~\S11\P7.
 \section{GPLv3~\S12: Familiar as GPLv2~\S7}
 GPLv2~\S12 remains almost completely unchanged from the text that appears in
 GPLv2~\S7.  This is an important provision that ensures a catch-all to ensure
 that nothing ``surprising'' interferes with the continued conveyance safely
 under copyleft.
 The wording in the first sentence of GPLv3~\S12 has been revised slightly to
 clarify that an agreement -- such as a litigation settlement agreement or a
 patent license agreement -- is one of the ways in which conditions may be
 ``imposed'' on a GPL licensee that may contradict the conditions of the GPL,
 but which do not excuse the licensee from compliance with those conditions.
 This change codifies the historical interpretation of GPLv2.
 GPLv3 removed the limited severability clause of GPLv2~\S7 as a
 matter of tactical judgment, believing that this is the best way to ensure
 that all provisions of the GPL will be upheld in court. GPLv3 also removed
 the final sentence of GPLv2 section 7, which the FSF consider to be unnecessary.
 \section{GPLv3~\S13: The Great Affero Compromise}
 The Affero GPL was written with the expectation that its
 additional requirement would be incorporated into the terms of GPLv3
 itself.  Many software freedom advocates, including some authors of this
 tutorial, advocated heavily for that, and fully expected it to happen.
 The FSF, however, chose not to include the Affero clause in GPLv3, due to
 what it called  ``irreconcilable views from
 different parts of the community''.  Many
 commercial users of Free Software were opposed to the inclusion of a
 mandatory Affero-like requirement in the body of GPLv3 itself.  In fact, some
 wealthier companies even threatened to permanently fund forks of many FSF
 copyrighted-programs under GPLv2 if the Affero clause appeared in GPLv3.
 Meanwhile, there was disagreement even among copyleft enthusiasts about the
 importance of the provision.  A coalition never formed, and ultimately the
 more powerful interest implicitly allied with the companies who deeply opposed
 the Affero clause such that the FSF felt the Affero clause would need its own
 license, but one compatible with GPLv3.
 GPLv3~\S13 makes GPLv3 compatible with the AGPLv3, so that at least code can
 be shared between AGPLv3'd and GPLv3'd projects, even if the Affero clause
 does not automatically apply to all GPLv3'd works.
 %FIXME-LATER:  no time to do this justice, will come back later, instead the
 %above.
 %% Some of this hostility seemed to be based on a misapprehension that
 %% Affero-like terms placed on part of a covered work would somehow extend
 %% to the whole of the work.\footnote{It is possible that the presence of
 %% the GPLv2-derived copyleft clause in the existing Affero GPL contributed
 %% to this misunderstanding.}  Our explanations to the contrary did little
 %% to satisfy these critics; their objections to 7b4 instead evolved into a
 %% broader indictment of the additional requirements scheme of section 7.
 %% It was clear, however, that much of the concern about 7b4 stemmed from
 %% its general formulation.  Many were alarmed at the prospect of GPLv3
 %% compatibility for numerous Affero-like licensing conditions,
 %% unpredictable in their details but potentially having significant
 %% commercial consequences.
 %% On the other hand, many developers, otherwise sympathetic to the policy
 %% goals of the Affero GPL, have objected to the form of the additional
 %% requirement in that license.  These developers were generally
 %% disappointed with our decision to allow Affero-like terms through
 %% section 7, rather than adopt a condition for GPLv3.  Echoing their
 %% concerns about the Affero GPL itself, they found fault with the wording
 %% of the section 7 clause in both of the earlier drafts.  We drafted 7b4
 %% at a higher level than its Draft 1 counterpart based in part on comments
 %% from these developers. They considered the Draft 1 clause too closely
 %% tied to the Affero mechanism of preserving functioning facilities for
 %% downloading source, which they found too restrictive of the right of
 %% modification.  The 7b4 rewording did not satisfy them, however. They
 %% objected to its limitation to terms requiring compliance by network
 %% transmission of source, and to the technically imprecise or inaccurate
 %% use of the phrase ``same network session.''
 %% We have concluded that any redrafting of the 7b4 clause would fail to
 %% satisfy the concerns of both sets of its critics.  The first group
 %% maintains that GPLv3 should do nothing about the problem of public
 %% use. The second group would prefer for GPLv3 itself to have an
 %% Affero-like condition, but that seems to us too drastic. By permitting
 %% GPLv3-covered code to be linked with code covered by version 2 of the
 %% Affero GPL, the new section 13 honors our original commitment to
 %% achieving GPL compatibility for the Affero license.
 %% Version 2 of the Affero GPL is not yet published.  We will work with
 %% Affero, Inc., and with all other interested members of our community, to
 %% complete the drafting of this license following the release of Draft 3,
 %% with a goal of having a final version available by the time of our
 %% adoption of the final version of GPLv3.  We hope the new Affero license
 %% will satisfy those developers who are concerned about the issue of
 %% public use of unconveyed versions but who have concerns about the
 %% narrowness of the condition in the existing Affero license.
 %% As the second sentence in section 13 indicates, when a combined work is
 %% made by linking GPLv3-covered code with Affero-covered code, the
 %% copyleft on one part will not extend to the other part.\footnote{The
 %% plan is that the additional requirement of the new Affero license will
 %% state a reciprocal limitation.} That is to say, in such combinations,
 %% the Affero requirement will apply only to the part that was brought into
 %% the combination under the Affero license.  Those who receive such a
 %% combination and do not wish to use code under the Affero requirement may
 %% remove the Affero-covered portion of the combination.
 Meanwhile, those who criticize the permission to link with code under the Affero
 GPL should recognize that most other free software licenses also permit
 such linking.
 \section{GPLv3~\S14: So, When's GPLv4?}
 \label{GPLv3s14}
 No substantive change has been made in section 14. The wording of the section
 has been revised slightly to make it clearer.
 It's unclear when the FSF might consider publishing GPLv4.  However, this
 section makes it clear that the FSF is the sole authority who can decide
 such.
 The main addition to this section allows a third-party proxy to be appointed
 by contributors who wish someone else to make relicensing to new versions of
 GPL when they are released.  This is a ``halfway'' point between using ``-only''
 or ``-or-later'' by consolidating the decision-making on that issue to a
 single authority.
 % FIXME-LATER: better proxy description
 \section{GPLv3~\S15--17: Warranty Disclaimers and Liability Limitation}
 No substantive changes have been made in sections 15 and 16.
 % FIXME-LATER: more, plus 17
 % FIXME-LATER: Section header needed here about choice of law.
 % FIXME-LATER: reword into tutorial
 %% Some have asked us to address the difficulties of internationalization
 %% by including, or permitting the inclusion of, a choice of law
 %% provision.  We maintain that this is the wrong approach.  Free
 %% software licenses should not contain choice of law clauses, for both
 %% legal and pragmatic reasons.  Choice of law clauses are creatures of
 %% contract, but the substantive rights granted by the GPL are defined
 %% under applicable local copyright law. Contractual free software
 %% licenses can operate only to diminish these rights.  Choice of law
 %% clauses also raise complex questions of interpretation when works of
 %% software are created by combination and extension.  There is also the
 %% real danger that a choice of law clause will specify a jurisdiction
 %% that is hostile to free software principles.
 %% % FIXME-LATER: reword into tutorial, \ref to section 7.
 %% Our revised version of section 7 makes explicit our view that the
 %% inclusion of a choice of law clause by a licensee is the imposition of
 %% an additional requirement in violation of the GPL.  Moreover, if a
 %% program author or copyright holder purports to supplement the GPL with
 %% a choice of law clause, section 7 now permits any licensee to remove
 %% that clause.
 % FIXME-LATER: does this need to be a section, describing how it was out then in
 % then out then in? :)
 Finally, the FSF shortened the section on ``How to Apply These
 Terms to Your New Programs'' to just the bare essentials.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{The Lesser GPL}
 As we have seen in our consideration of the GPL, its text is specifically
 designed to cover all possible derivative works under copyright law. Our
 goal in designing the GPL was to make sure that any derivative work of GPL'd
 software was itself released under the GPL when distributed. Reaching as far
 as copyright law will allow is the most direct way to reach that goal.
 designed to cover all possible derivative, modified and/or combined works under copyright law. Our
 goal in designing the GPL was to maximize its use of the controls of
 copyright law to maximize the number of works that were covered by GPL.
 However, while the strategic goal is to bring as much Free Software
+However, while the strategic goal of software freedom is to bring as much Free Software
 into the world as possible, particular tactical considerations
 regarding software freedom dictate different means. Extending the
 copyleft effect as far as copyright law allows is not always the most
 prudent course in reaching the goal. In particular situations, even
 those of us with the goal of building a world where all published
 software is Free Software realize that full copyleft does not best
 serve us. The GNU Lesser General Public License (``GNU LGPL'') was
 designed as a solution for such situations.
 \section{The First LGPL'd Program}
 The first example that FSF encountered where such altered tactics were
 needed was when work began on the GNU C Library. The GNU C Library would
 become (and today, now is) a drop-in replacement for existing C libraries.
 On a Unix-like operating system, C is the lingua franca and the C library
 is an essential component for all programs. It is extremely difficult to
 construct a program that will run with ease on a Unix-like operating
 system without making use of services provided by the C library --- even
 if the program is written in a language other than C\@. Effectively, all
 user application programs that run on any modern Unix-like system must
 make use of the C library.
 By the time work began on the GNU implementation of the C libraries, there
 were already many C libraries in existence from a variety of vendors.
 Every proprietary Unix vendor had one, and many third parties produced
 smaller versions for special purpose use. However, our goal was to create
 a C library that would provide equivalent functionality to these other C
 libraries on a Free Software operating system (which in fact happens today
 on modern GNU/Linux systems, which all use the GNU C Library).
 Unlike existing GNU application software, however, the licensing
 implications of releasing the GNU C Library (``glibc'') under the GPL were
 somewhat different. Applications released under the GPL would never
 themselves become part of proprietary software. However, if glibc were
 released under the GPL, it would require that any application distributed for
 the GNU/Linux platform be released under the GPL\@.
 Since all applications on a Unix-like system depend on the C library, it
 means that they must link with that library to function on the system. In
 other words, all applications running on a Unix-like system must be
-combined with the C library to form a new whole derivative work that is
 combined with the C library to form a new whole work that is
 composed of the original application and the C library. Thus, if glibc
 were GPL'd, each and every application distributed for use on GNU/Linux
 would also need to be GPL'd, since to even function, such applications
-would need to be combined into larger derivative works by linking with
 would need to be combined into larger works by linking with
 glibc.
 At first glance, such an outcome seems like a windfall for Free Software
 advocates, since it stops all proprietary software development on
 GNU/Linux systems. However, the outcome is a bit more subtle. In a world
 where many C libraries already exist, many of which could easily be ported
 to GNU/Linux, a GPL'd glibc would be unlikely to succeed. Proprietary
 vendors would see the excellent opportunity to license their C libraries
 to anyone who wished to write proprietary software for GNU/Linux systems.
 The de-facto standard for the C library on GNU/Linux would likely be not
 glibc, but the most popular proprietary one.
 Meanwhile, the actual goal of releasing glibc under the GPL --- to ensure no
 proprietary applications on GNU/Linux --- would be unattainable in this
 scenario. Furthermore, users of those proprietary applications would also
 be users of a proprietary C library, not the Free glibc.
 The Lesser GPL was initially conceived to handle this scenario. It was
 clear that the existence of proprietary applications for GNU/Linux was
 inevitable. Since there were so many C libraries already in existence, a
 new one under the GPL would not stop that tide. However, if the new C library
 were released under a license that permitted proprietary applications
 to link with it, but made sure that the library itself remained Free,
 an ancillary goal could be met. Users of proprietary applications, while
 they would not have the freedom to copy, share, modify and redistribute
 the application itself, would have the freedom to do so with respect to
 the C library.
 There was no way the license of glibc could stop or even slow the creation
 of proprietary applications on GNU/Linux. However, loosening the
 restrictions on the licensing of glibc ensured that nearly all proprietary
 applications at least used a Free C library rather than a proprietary one.
 This trade-off is central to the reasoning behind the LGPL\@.
 Of course, many people who use the LGPL today are not thinking in these
 terms. In fact, they are often choosing the LGPL because they are looking
 for a ``compromise'' between the GPL and the X11-style liberal licensing.
 However, understanding FSF's reasoning behind the creation of the LGPL is
 helpful when studying the license.
 \section{What's the Same?}
 Much of the text of the LGPL is identical to the GPL\@. As we begin our
 discussion of the LGPL, we will first eliminate the sections that are
 identical, or that have the minor modification changing the word
 ``Program'' to ``Library.''
 First, LGPLv2.1~\S1, the rules for verbatim copying of source, are
 equivalent to those in GPLv2~\S1.
 Second, LGPLv2.1~\S8 is equivalent GPLv2~\S4\@. In both licenses, this
 section handles termination in precisely the same manner.
 LGPLv2.1~\S9 is equivalent to GPLv2~\S5\@. Both sections assert that
 the license is a copyright license, and handle the acceptance of those
 copyright terms.
 LGPLv2.1~\S10 is equivalent to GPLv2~\S6. They both protect the
 distribution system of Free Software under these licenses, to ensure that
 up, down, and throughout the distribution chain, each recipient of the
 software receives identical rights under the license and no other
 restrictions are imposed.
 LGPLv2.1~\S11 is GPLv2~\S7. As discussed, it is used to ensure that
 other claims and legal realities, such as patent licenses and court
 judgments, do not trump the rights and permissions granted by these
 licenses, and requires that distribution be halted if such a trump is
 known to exist.
 LGPLv2.1~\S12 adds the same features as GPLv2~\S8. These sections are
 used to allow original copyright holders to forbid distribution in
 countries with draconian laws that would otherwise contradict these
 licenses.
 LGPLv2.1~\S13 sets up the FSF as the steward of the LGPL, just as GPLv2~\S9
 does for GPL. Meanwhile, LGPLv2.1~\S14 reminds licensees that copyright
 holders can grant exceptions to the terms of LGPL, just as GPLv2~\S10
 reminds licensees of the same thing.
 Finally, the assertions of no warranty and limitations of liability are
 identical; thus LGPLv2.1~\S15 and LGPLv2.1~\S16 are the same as GPLv2~\S11 and \S
 .
 As we see, the entire latter half of the license is identical.
 The parts which set up the legal boundaries and meta-rules for the license
 are the same. It is our intent that the two licenses operate under the
 same legal mechanisms and are enforced precisely the same way.
 We strike a difference only in the early portions of the license.
 Namely, in the LGPL we go into deeper detail of granting various permissions to
 create derivative works, so the re-distributors can make
 some proprietary derivatives. Since we simply do not allow the
 license to stretch as far as copyright law does regarding what
 derivative works must be relicensed under the same terms, we must go
 further to explain which derivative works we will allow to be
 proprietary. Thus, we'll see that the front matter of the LGPL is a
 create certain types of combinations, modifications and derivations.
 The LGPL does not stretch the requirements as far as copyright law does regarding what
 works must be relicensed under the same terms.  Therefore, LGPL must
 in detail explain which works can be proprietary.  Thus, we'll see that the front matter of the LGPL is a
 bit more wordy and detailed with regards to the permissions granted to
 those who modify or redistribute the software.
 \section{Additions to the Preamble}
 Most of the LGPL's Preamble is identical, but the last seven paragraphs
 introduce the concepts and reasoning behind creation of the license,
 presenting a more generalized and briefer version of the story with which
 we began our consideration of the LGPL\@.
 In short, FSF designed the LGPL for those edge cases where the freedom of the
 public can better be served by a more lax licensing system. FSF doesn't
 encourage use of the LGPL automatically for any software that happens to be a
 library; rather, FSF suggests that it only be used in specific cases, such
 as the following:
 \begin{itemize}
 \item To encourage the widest possible use of a Free Software library, so
   it becomes a de-facto standard over similar, although not
   interface-identical, proprietary alternatives
 \item To encourage use of a Free Software library that already has
   interface-identical proprietary competitors that are more developed
 \item To allow a greater number of users to get freedom, by encouraging
   proprietary companies to pick a Free alternative for its otherwise
   proprietary products
 \end{itemize}
 The LGPL's preamble sets forth the limits to which the license seeks to go in
 chasing these goals. The LGPL is designed to ensure that users who happen to
 acquire software linked with such libraries have full freedoms with
 respect to that library. They should have the ability to upgrade to a newer
 or modified Free version or to make their own modifications, even if they
 cannot modify the primary software program that links to that library.
 Finally, the preamble introduces two terms used throughout the license to
-clarify between the different types of derivative works: ``works that use
+clarify between the different types of combined works: ``works that use
 the library,'' and ``works based on the library.''  Unlike the GPL, the LGPL must
-draw some lines regarding derivative works. We do this here in this
+draw some lines regarding permissibly proprietary combined works.  We do this here in this
 license because we specifically seek to liberalize the rights afforded to
-those who make derivative works. In the GPL, we reach as far as copyright law
+those who make combined works. In the GPL, we reach as far as copyright law
 allows. In the LGPL, we want to draw a line that allows some derivative works
 copyright law would otherwise prohibit if the copyright holder exercised
 his full permitted controls over the work.
 \section{An Application: A Work that Uses the Library}
 In the effort to allow certain proprietary derivative works and prohibit
 others, the LGPL distinguishes between two classes of derivative works:
 In the effort to allow certain proprietary works and prohibit
 others, the LGPL distinguishes between two classes of works:
 ``works based on the library,'' and ``works that use the library.''  The
 distinction is drawn on the bright line of binary (or runtime) derivative
 works and source code derivatives. We will first consider the definition
 distinction is drawn on the bright line of binary (or runtime) combined
 works and modified versions of source code. We will first consider the definition
 of a ``work that uses the library,'' which is set forth in LGPLv2.1~\S5.
 We noted in our discussion of GPLv2~\S3 (discussed in
 Section~\ref{GPLv2s3} of this document) that binary programs when
 compiled and linked with GPL'd software are derivative works of that GPL'd
 software. This includes both linking that happens at compile-time (when
 compiled and linked with GPL'd software are covered as a whole by GPL\@.
 This includes both linking that happens at compile-time (when
 the binary is created) or at runtime (when the binary -- including library
 and main program both -- is loaded into memory by the user). In GPL,
 binary derivative works are controlled by the terms of the license (in GPLv2~\S3),
 and distributors of such binary derivatives must release full
 binary works are controlled by the terms of the license (in GPLv2~\S3),
 and distributors of such binary works must release full
 corresponding source\@.
 In the case of LGPL, these are precisely the types of derivative works
 we wish to permit. This scenario, defined in LGPL as ``a work that uses
 the library,'' works as follows:
 The LGPL, by contrast, allows partial proprietarization of such binary works.
 This scenario, defined in LGPL as ``a work that uses the library,'' works as
 follows:
 \newcommand{\workl}{$\mathcal{L}$}
 \newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$}
 \begin{itemize}
 \item A new copyright holder creates a separate and independent work,
   \worki{}, that makes interface calls (e.g., function calls) to the
   LGPL'd work, called \workl{}, whose copyright is held by some other
   party. Note that since \worki{} and \workl{} are separate and
   independent works, there is no copyright obligation on this new copyright
   holder with regard to the licensing of \worki{}, at least with regard to
   the source code.
 \item The new copyright holder, for her software to be useful, realizes
   that it cannot run without combining \worki{} and \workl{}.
   Specifically, when she creates a running binary program, that running
-  binary must be a derivative work, called \lplusi{}, that the user can
+  binary must be a combined work, called \lplusi{}, that the user can
   run.
-\item Since \lplusi{} is a derivative work of both \worki{} and \workl{},
+\item Since \lplusi{} is a based on both \worki{} and \workl{},
   the license of \workl{} (the LGPL) can put restrictions on the license
   of \lplusi{}. In fact, this is what the LGPL does.
 \end{itemize}
 We will talk about the specific restrictions LGPLv2.1 places on ``works
 that use the library'' in detail in Section~\ref{lgpl-section-6}. For
 now, focus on the logic related to how the LGPLv2.1 places requirements on
 the license of \lplusi{}. Note, first of all, the similarity between
 this explanation and that in Section~\ref{separate-and-independent},
 which discussed the combination of otherwise separate and independent
 works with GPL'd code. Effectively, what LGPLv2.1 does is say that when a
 new work is otherwise separate and independent, but has interface
 calls out to an LGPL'd library, then it is considered a ``work that
 uses the library.''
 In addition, the only reason that LGPLv2.1 has any control over the licensing
 of a ``work that uses the library'' is for the same reason that GPL has
 some say over separate and independent works. Namely, such controls exist
 because the {\em binary combination\/} (\lplusi{}) that must be created to
-make the separate work (\worki{}) at all useful is a derivative work of
+make the separate work (\worki{}) at all useful is a  work based on
 the LGPLv2.1'd software (\workl{}).
 Thus, a two-question test that will help indicate if a particular work is
 a ``work that uses the library'' under LGPLv2.1 is as follows:
 \begin{enumerate}
 \item Is the source code of the new copyrighted work, \worki{}, a
   completely independent work that stands by itself, and includes no
   source code from \workl{}?
 \item When the source code is compiled, does it create a derivative work
   by combining with \workl{}, either by static (compile-time) or dynamic
 \item When the source code is compiled, does it combine into a single work
   with \workl{}, either by static (compile-time) or dynamic
   (runtime) linking, to create a new binary work, \lplusi{}?
 \end{enumerate}
 If the answers to both questions are ``yes,'' then \worki{} is most likely
 a ``work that uses the library.''  If the answer to the first question
 ``yes,'' but the answer to the second question is ``no,'' then most likely
 \worki{} is neither a ``work that uses the library'' nor a ``work based on
 the library.''  If the answer to the first question is ``no,'' but the
 answer to the second question is ``yes,'' then an investigation into
 whether or not \worki{} is in fact a ``work based on the library'' is
 warranted.
 \section{The Library, and Works Based On It}
 In short, a ``work based on the library'' could be defined as any
-derivative work of LGPL'd software that cannot otherwise fit the
+work based on the LGPL'd software that cannot otherwise fit the
 definition of a ``work that uses the library.''  A ``work based on the
 library'' extends the full width and depth of copyright derivative works,
 in the same sense that the GPL does.
 library'' extends the full width and depth of derivative, combined and/or
 modified works under copyright law, in the same sense that the GPL does.
 Most typically, one creates a ``work based on the library'' by directly
 modifying the source of the library. Such a work could also be created by
 tightly integrating new software with the library. The lines are no doubt
 fuzzy, just as they are with GPL'd works, since copyright law gives us no
 litmus test for derivative works of a software program.
 litmus test for determining if a given work is a derivative or otherwise a
 modified version of another software program.
 Thus, the test to use when considering whether something is a ``work
 based on the library'' is as follows:
 \begin{enumerate}
 \item Is the new work, when in source form, a derivative work under
   copyright law of the LGPL'd work?
 \item Is the new work, when in source form, a derivative and/or modified
   work of, and/or a combined work with the LGPL'd work under
   copyright law?
 \item Is there no way in which the new work fits the definition of a
   ``work that uses the library''?
 \end{enumerate}
 If the answer is ``yes'' to both these questions, then you most likely
 have a ``work based on the library.''  If the answer is ``no'' to the
 first but ``yes'' to the second, you are in a gray area between ``work
 based on the library'' and a ``work that uses the library.''
 In our years of work with the LGPLv2.1, however, we have never seen a work
 of software that was not clearly one or the other; the line is quite
 bright. At times, though, we have seen cases where a derivative work
 appeared in some ways to be a work that used the library and in other
 ways a work based on the library. We overcame this problem by
 bright. At times, though, we have seen cases where a particularly  large work
 in some ways seemed to be both to both a work that used the library and
 a work based on the library. We overcame this problem by
 dividing the work into smaller subunits. It was soon discovered that
 what we actually had were three distinct components: the original
 LGPL'd work, a specific set of works that used that library, and a
 specific set of works that were based on the library. Once such
 distinctions are established, the licensing for each component can be
 considered independently and the LGPLv2.1 applied to each work as
 prescribed.
 \section{Subtleties in Defining the Application}
 In our discussion of the definition of ``works that use the library,'' we
 left out a few more complex details that relate to lower-level programming
 details. The fourth paragraph of LGPLv2.1~\S5 covers these complexities,
 and it has been a source of great confusion. Part of the confusion comes
 because a deep understanding of how compiler programs work is nearly
 mandatory to grasp the subtle nature of what LGPLv2.1~\S5, \P 4 seeks to
 cover. It helps some to note that this is a border case that we cover in
 the license only so that when such a border case is hit, the implications
 of using the LGPL continue in the expected way.
 To understand this subtle point, we must recall the way that a compiler
 operates. The compiler first generates object code, which are the binary
 representations of various programming modules. Each of those modules is
 usually not useful by itself; it becomes useful to a user of a full program
 when those modules are {\em linked\/} into a full binary executable.
 As we have discussed, the assembly of modules can happen at compile-time
 or at runtime. Legally, there is no distinction between the two --- both
-create a derivative work by copying and combining portions of one work and
+create a modified version of the work by copying and combining portions of one work and
 mixing them with another. However, under LGPL, there is a case in the
 compilation process where the legal implications are different.
 Specifically, while we know that a ``work that uses the library'' is one
 whose final binary is a derivative work, but whose source is not, there
 To understand this phenomenon, we consider that a ``work that uses the
 library'' is typically one whose final binary is a work based on the Program,
 but whose source is not.  However, sometimes, there
 are cases where the object code --- that intermediate step between source
-and final binary --- is a derivative work created by copying verbatim code
+and final binary --- is a work created by copying and modifying code
 from the LGPL'd software.
 For efficiency, when a compiler turns source code into object code, it
 sometimes places literal portions of the copyrighted library code into the
 object code for an otherwise separate independent work. In the normal
-scenario, the derivative would not be created until final assembly and
+scenario, the final combined work would not be created until final assembly and
 linking of the executable occurred. However, when the compiler does this
 efficiency optimization, at the intermediate object code step, a
-derivative work is created.
+combined work is created.
 LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of
 the license is clearly that simply compiling software to ``make use'' of
 the library does not in itself cause the compiled work to be a ``work
 based on the library.''  However, since the compiler copies verbatim,
 copyrighted portions of the library into the object code for the otherwise
 separate and independent work, it would actually cause that object file to be a
 ``work based on the library.''  It is not FSF's intent that a mere
 compilation idiosyncrasy would change the requirements on the users of the
 LGPLv2.1'd software. This paragraph removes that restriction, allowing the
 implications of the license to be the same regardless of the specific
 mechanisms the compiler uses underneath to create the ``work that uses the
 library.''
 As it turns out, we have only once had anyone worry about this specific
 idiosyncrasy, because that particular vendor wanted to ship object code
 (rather than final binaries) to their customers and was worried about
 this edge condition. The intent of clarifying this edge condition is
 primarily to quell the worries of software engineers who understand the
 level of verbatim code copying that a compiler often does, and to help
 them understand that the full implications of LGPLv2.1 are the same regardless
 of the details of the compilation progress.
 \section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}
 \label{lgpl-section-6}
 Now that we have established a good working definition of works that
 ``use'' and works that ``are based on'' the library, we will consider the
 rules for distributing these two different works.
 The rules for distributing ``works that use the library'' are covered in
 LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, as it requires the release
 of source when a binary version of the LGPL'd software is released. Of
 course, it only requires that source code for the library itself be made
 available. The work that ``uses'' the library need not be provided in
 source form. However, there are also conditions in LGPLv2.1~\S6 to make sure
 that a user who wishes to modify or update the library can do so.
 LGPLv2.1~\S6 lists five choices with regard to supplying library source
 and granting the freedom to modify that library source to users. We
 will first consider the option given by \S~6(b), which describes the
 most common way currently used for LGPLv2.1 compliance on a ``work that
 uses the library.''
 LGPLv2.1~\S6(b) allows the distributor of a ``work that uses the library'' to
 simply use a dynamically linked, shared library mechanism to link with the
 library. This is by far the easiest and most straightforward option for
 distribution. In this case, the executable of the work that uses the
 library will contain only the ``stub code'' that is put in place by the
 shared library mechanism, and at runtime the executable will combine with
 the shared version of the library already resident on the user's computer.
 If such a mechanism is used, it must allow the user to upgrade and
 replace the library with interface-compatible versions and still be able
 to use the ``work that uses the library.''  However, all modern shared
 library mechanisms function as such, and thus LGPLv2.1~\S6(b) is the simplest
 option, since it does not even require that the distributor of the ``work
 based on the library'' ship copies of the library itself.
 LGPLv2.1~\S6(a) is the option to use when, for some reason, a shared library
 mechanism cannot be used. It requires that the source for the library be
 included, in the typical GPL fashion, but it also has a requirement beyond
 that. The user must be able to exercise her freedom to modify the library
 to its fullest extent, and that means recombining it with the ``work based
 on the library.''  If the full binary is linked without a shared library
 mechanism, the user must have available the object code for the ``work
 based on the library,'' so that the user can relink the application and
 build a new binary.
 The remaining options in LGPLv2.1~\S6 are very similar to the other choices
 provided by GPLv2~\S3. There are some additional options, but time does
 not permit us in this course to go into those additional options. In
 almost all cases of distribution under LGPL, either LGPLv2.1~\S6(a) or LGPLv2.1~\S6(b) are
 exercised.
 \section{Distribution of the Combined Works}
 Essentially, ``works based on the library'' must be distributed under the
 same conditions as works under full GPL\@. In fact, we note that
 LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.
 There are again subtle differences and additions, which time does not
 permit us to cover in this course.
 \section{And the Rest}
 The remaining variations between the LGPL and the GPL cover the following
 conditions:
 \begin{itemize}
 \item Allowing a licensing ``upgrade'' from the LGPL to the GPL\@ (in LGPLv2.1~\S3)
 \item Binary distribution of the library only, covered in LGPLv2.1~\S4,
   which is effectively equivalent to LGPLv2.1~\S3
-\item Creating aggregates of libraries that are not derivative works of
+\item Creating aggregates of libraries that are separate and independent works from
   each other, and distributing them as a unit (in LGPLv2.1~\S7)
 \end{itemize}
 Due to time constraints, we cannot cover these additional terms in detail,
 but they are mostly straightforward. The key to understanding LGPLv2.1 is
 understanding the difference between a ``work based on the library'' and a
 ``work that uses the library.''  Once that distinction is clear, the
 remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in
 our more extensive GPL unit can be directly applied.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Integrating the GPL into Business Practices}
 Since GPL'd software is now extremely prevalent through the industry, it
 is useful to have some basic knowledge about using GPL'd software in
 business and how to build business models around GPL'd software.
 \section{Using GPL'd Software In-House}
 As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial,
 the GPL only governs the activities of copying, modifying and
 distributing software programs that are not governed by the license.
 Thus, in FSF's view, simply installing the software on a machine and
 using it is not controlled or limited in any way by the GPL\@. Using Free
 Software in general requires substantially fewer agreements and less
 license compliance activity than any known proprietary software.
 Even if a company engages heavily in copying the software throughout the
 enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is
 encouraged!  If the company simply deploys unmodified (or even modified)
 Free Software throughout the organization for its employees to use, the
 obligations under the license are very minimal. Using Free Software has a
 substantially lower cost of ownership --- both in licensing fees and in
 licensing checking and handling -- than the proprietary software
 equivalents.
 \section{Business Models}
 \label{Business Models}
 Using Free Software in house is certainly helpful, but a thriving
 market for Free Software-oriented business models also exists. There is the
 traditional model of selling copies of Free Software distributions.
 Many companies make substantial revenue
 from this model. Some choose this model because they have
 found that for higher-end hardware, the profit made from proprietary
 software licensing fees is negligible. The real profit is in the hardware,
 but it is essential that software be stable, reliable and dependable, and
 the users be allowed to have unfettered access to it. Free Software, and
 GPL'd software in particular (because IBM can be assured that proprietary
 versions of the same software will not exist to compete on their hardware)
 is the right choice.
 For example, charging a ``convenience fee'' for Free Software,
 when set at a reasonable price (around \$60 or so), can produce some
 profit. Even though Red Hat's system is fully downloadable on their
 Web site, people still go to local computer stores and buy copies of their
 box set, which is simply a printed version of the manual (available under
 a Free license as well) and the Free Software system it documents.
 \medskip
 However, custom support, service, and software improvement contracts
 are the most widely used models for GPL'd software. The GPL is
 central to their success, because it ensures that the code base
 remains common, and that large and small companies are on equal
 footing for access to the technology. Consider, for example, the GNU
 Compiler Collection (GCC). Cygnus Solutions, a company started in the
 early 1990s, was able to grow steadily simply by providing services
 for GCC --- mostly consisting of new ports of GCC to different or new,
 embedded targets. Eventually, Cygnus was so successful that
 it was purchased by Red Hat where it remains a profitable division.
 However, there are very small companies that compete in
 this space. Because the code-base is protected by the GPL, it creates and
 demands industry trust. Companies can cooperate on the software and
 improve it for everyone. Meanwhile, companies who rely on GCC for their
 work are happy to pay for improvements, and for ports to new target
 platforms. Nearly all the changes fold back into the standard
 versions, and those forks that exist remain freely available.
 \medskip
 \label{Proprietary Relicensing}
 A final common business model that is perhaps the most controversial is
 proprietary relicensing of a GPL'd code base. This is only an option for
 software in which a particular entity holds exclusive rights to
 relicense\footnote{Entities typically hold exclusive relicensing rights
   either by writing all the software under their own copyrights, collecting
   copyright assignments from all contributors, or by otherwise demanding
   unconditional relicensing permissions from all contributors via some legal
   agreement}. As discussed earlier in this tutorial, a copyright holder is
 permitted under copyright law to license a software system under her
 copyright as many different ways as she likes to as many different parties as
 she wishes.
 Some companies use this to their
 financial advantage with regard to a GPL'd code base. The standard
 version is available from the company under the terms of the GPL\@.
 However, parties can purchase separate proprietary software licensing for
 a fee.
 This business model is at best problematic and at worst predatory because it means that the GPL'd code
 base must be developed in a somewhat monolithic way, because volunteer
 Free Software developers may be reluctant to assign their copyrights to
 the company because it will not promise to always and forever license the
 software as Free Software. Indeed, the company will surely use such code
 contributions in proprietary versions licensed for fees.
 \section{Ongoing Compliance}
 GPL compliance is in fact a very simple matter --- much simpler than
 typical proprietary software agreements and EULAs. Usually, the most
 difficult hurdle is changing from a proprietary software mindset to one
 that seeks to foster a community of sharing and mutual support. Certainly
 complying with the GPL from a users' perspective gives substantially fewer
 headaches than proprietary license compliance.
 For those who go into the business of distributing {\em modified}
 versions of GPL'd software, the burden is a bit higher, but not by
 much. The glib answer is that by releasing the whole product as Free
 Software, it is always easy to comply with the GPL. However,
 admittedly to the dismay of FSF, many modern and complex software
 systems are built using both proprietary and GPL'd components that are
 not legally derivative works of each other. Sometimes, it is easier simply to
 improve existing GPL'd application than to start from scratch. In
 exchange for that benefit, the license requires that the modifier gives
 clearly and legally separate and independent works, merely aggregated
 together on the same device.
 However, it's sometimes is easier, quicker, and cheaper to simply to
 improve existing GPL'd application than to start from scratch.  In
 exchange for this amazing benefit, the license requires that the modifier gives
 back to the commons that made the work easier in the first place. It is a
 reasonable trade-off and a way to help build a better world while also
 making a profit.
 Note that FSF does provide services to assist companies who need
 assistance in complying with the GPL. You can contact FSF's GPL
 Compliance Labs at $<$licensing@fsf.org$>$.
 %FIXME-LATER: should have \tutorialpart
 If you are particularly interested in matters of GPL compliance, we
 recommend the next two parts, which include both recommendations on good
 compliance and compliance case studies.
 % =====================================================================
 % END OF FIRST DAY SEMINAR SECTION
 % =====================================================================
 %%  LocalWords:  Sebro Novalis Ravicher GPLv GPL'd copylefted LGPLv OSI USC
 %%  LocalWords:  noncommercially counterintuitive Berne copyrightable DRM UC
 %%  LocalWords:  proprietarize proprietarization Stallman's Tridgell's RMS
 %%  LocalWords:  Lessig Lessig's Stallman Proto GPLs proto Tai pre GPL's ful
 %%  LocalWords:  legalbol AGPLv Runtime licensor licensors relicense UCITA
 %%  LocalWords:  unprotectable Intl nd th Kepner Tregoe Bando Indust Mitel
 %%  LocalWords:  Iqtel Bateman Mitek Arce protectable hoc faire de minimis
 %%  LocalWords:  Borland Int'l uncopyrightable LLC APIs Ent Connectix DVD's
 %%  LocalWords:  redistributor diachronic unshared subpart redistributors
 %%  LocalWords:  CDs userbase reshifts licensor's distributee impliedly Mgmt
 %%  LocalWords:  patentee  relicenses irrevocability Jacobsen Katzer TRW CCS
 %%  LocalWords:  Unfreedonia administrivia Relicensing impermissibly centric
 %%  LocalWords:  permissibility firehose bytecode minified Javascript DLLs
 %%  LocalWords:  preprocessors functionalities offsite sublicensing DMCA CFR
 %%  LocalWords:  anticircumvention WIPO BitTorrent multidirectional Magnuson
 %%  LocalWords:  subdefinition Dryvit Stroebner Tandy TRS superset LGPL SLES
 %%  LocalWords:  cryptographic relicensing removability sublicensed Novell
 %%  LocalWords:  anticompetitive administrability sublicensable licensable
 %%  LocalWords:  sublicense sublicensees sublicenses affixation Novell's
 %%  LocalWords:  severability Affero LGPL'd lingua franca glibc facto LGPL's
 %%  LocalWords:  relicensed runtime subunits relink downloadable MontaVista
 %%  LocalWords:  CodeSourcery OpenTV MySQL TrollTech

0 comments (0 inline, 0 general)