% compliance-guide.tex                            -*- LaTeX -*-

\part{A Practical Guide to GPL Compliance}

\begin{center}

{\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}

Authors of this part are: \\

Bradley M. Kuhn \\

Aaron Williamson \\

Karen M. Sandler \\

\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. In accordance with the Software

Freedom Law Center's (SFLC's) philosophy of assisting the community with

GPL compliance cooperatively, this guide focuses on avoiding compliance

actions and minimizing the negative impact when enforcement actions occur.

It 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 Stallman 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.}  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 community of

Free/Libre and Open Source Software (FOSS) developers.  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 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.

In 2007, the SFLC filed the first U.S.~copyright infringement lawsuit

based on a violation of the GPL\@. While the lawsuits filed by SFLC on

behalf of its clients have been quite public, SFLC resolves the vast

majority of enforcement actions privately via

cooperative communications with violators.  As we have worked to bring

individual companies into compliance, we 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.  In this document, we highlight these problems and describe

best practices to encourage corporate users of FOSS to reevaluate their

approach to GPL'd software and avoid future violations.

SFLC continues to conduct GPL enforcement and compliance efforts for many

of its clients who release their software under the GPL, the GNU Lesser

Public License (LGPL) and other copyleft licenses.  In doing so, we have

found that most violations stem from a few common mistakes that can be,

for the most part, easily avoided.  We 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 FOSS licenses (such as the ISC license), which

typically only require preservation of copyright notices, the GPL places a

number of important requirements upon licensees.  These requirements are

carefully designed to uphold certain values and standards of the software

freedom community.  While the GPL's requirements may appear initially

counter-intuitive to those more familiar with proprietary software

licenses, by comparison its terms are in fact clear and favorable to

licensees.  The terms of the GPL actually simplify compliance when

violations occur.

GPL violations are often caused or compounded by a failure to adopt sound

practices for the incorporation of GPL'd components into a company's

internal development environment.  In this section, we introduce some best

practices for software tool selection, integration and distribution,

inspired by and congruent with FOSS methodologies.  We suggest companies

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 implicating 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.}

However, in our experience with GPL enforcement, few redistributors'

compliance challenges relate directly to the copyleft provisions; this is

doubly true for most embedders.  Instead, the distributions of GPL'd

systems that we encounter 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,

resulting unequivocally in a derivative work.  Alongside these programs,

companies often distribute fully independent, proprietary programs,

developed from scratch, which are designed to run on the FOSS operating

system but do not combine with, link to, modify, or otherwise derive from

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 derivative work has been created.  The tiny

minority of situations which lie outside these two categories, and thus

involve close questions about derivative works, require a highly

fact-dependent analysis and cannot be addressed in a general-purpose

document.

Most companies accused of violations, however, lack a basic understanding

of how to comply even in the straightforward scenario.  This document

provides that fundamental and generally applicable prerequisite knowledge.

For answers to rarer and more complicated legal questions, such as whether

your software is a derivative 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}.}

For this discussion, we will assume 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.  In

such a case, the GPL requires you to provide complete and corresponding

source 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 should have the freedom to innovate and import useful

software components to improve your product.  However, along with that

freedom should come rules and reporting procedures to make sure that you

are aware of what software is being tested or included with your product.

The companies we contact about GPL violations often respond with: ``We

didn't know there was GPL'd stuff in there''.  This answer indicates a

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, your developers often obtain and

integrate FOSS without intervention. The 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 be involved in all decisions to bring FOSS into your

product.

Simple, engineering-oriented rules help provide a stable foundation for

FOSS integration.  Ask your software developers to send an email to a

standard place describing each new FOSS component they add to the system,

and have them include a brief description of how they will incorporate it

into the product.  Make sure they use a revision control system, and have

No party is a threat to another in the GPL software scenario because

everyone is on equal ground.  The GPL protects rights of the commercial

and noncommercial contributors and users equally. The GPL creates trust,

because it is a level playing field for all.

\subsection{Law Analogy}

In his introduction to Stallman's \emph{Free Software, Free Society},

Lawrence Lessig draws an interesting analogy between the law and Free

Software. He argues that the laws of a free society must be protected

much like the GPL protects software.  So that I might do true justice to

Lessig's argument, I quote it verbatim:

\begin{quotation}

A ``free society'' is regulated by law. But there are limits that any free

society places on this regulation through law: No society that kept its

laws secret could ever be called free.  No government that hid its

regulations from the regulated could ever stand in our tradition. Law

controls.  But it does so justly only when visibly.  And law is visible

only when its terms are knowable and controllable by those it regulates,

or by the agents of those it regulates (lawyers, legislatures).

This condition on law extends beyond the work of a legislature.  Think

about the practice of law in American courts.  Lawyers are hired by their

clients to advance their clients' interests.  Sometimes that interest is

advanced through litigation. In the course of this litigation, lawyers

write briefs. These briefs in turn affect opinions written by judges.

These opinions decide who wins a particular case, or whether a certain law

can stand consistently with a constitution.

All the material in this process is free in the sense that Stallman means.

Legal briefs are open and free for others to use.  The arguments are

transparent (which is different from saying they are good), and the

reasoning can be taken without the permission of the original lawyers.

The opinions they produce can be quoted in later briefs.  They can be

copied and integrated into another brief or opinion.  The ``source code''

for American law is by design, and by principle, open and free for anyone

to take. And take lawyers do---for it is a measure of a great brief that

it achieves its creativity through the reuse of what happened before.  The

source is free; creativity and an economy is built upon it.

This economy of free code (and here I mean free legal code) doesn't starve

lawyers.  Law firms have enough incentive to produce great briefs even

though the stuff they build can be taken and copied by anyone else.  The

lawyer is a craftsman; his or her product is public.  Yet the crafting is

not charity. Lawyers get paid; the public doesn't demand such work

without price.  Instead this economy flourishes, with later work added to

the earlier.

We could imagine a legal practice that was different --- briefs and

arguments that were kept secret; rulings that announced a result but not

the reasoning. Laws that were kept by the police but published to no one

else. Regulation that operated without explaining its rule.

We could imagine this society, but we could not imagine calling it

``free.''  Whether or not the incentives in such a society would be better

or more efficiently allocated, such a society could not be known as free.

The ideals of freedom, of life within a free society, demand more than

efficient application.  Instead, openness and transparency are the

constraints within which a legal system gets built, not options to be

added if convenient to the leaders.  Life governed by software code should

be no less.

Code writing is not litigation.  It is better, richer, more

productive.  But the law is an obvious instance of how creativity and

incentives do not depend upon perfect control over the products

created.  Like jazz, or novels, or architecture, the law gets built

upon the work that went before. This adding and changing is what

creativity always is.  And a free society is one that assures that its

most important resources remain free in just this sense.\footnote{This

quotation is Copyright \copyright{} 2002, Lawrence Lessig. It is

licensed under the terms of

\href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution

License'' version 1.0} or any later version as published by Creative

Commons.}

\end{quotation}

In essence, lawyers are paid to service the shared commons of legal

infrastructure.  Few citizens defend themselves in court or write their

own briefs (even though they are legally permitted to do so) because

everyone would prefer to have an expert do that job.

The Free Software economy is a market ripe for experts.  It

functions similarly to other well established professional fields like the

law. The GPL, in turn, serves as the legal scaffolding that permits the

creation of this vibrant commercial and noncommercial Free Software

economy.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{A Tale of Two Copyleft Licenses}

While determining the proper methodology and criteria to yield an accurate

count remains difficult, the GPL is generally considered one of the most

widely used Free Software licenses.  For most of its history --- for 16 years

from June 1991 to June 2007 --- there was really only one version of the GPL,

version 2.

However, the GPL had both earlier versions before version 2, and, more well

known, a revision to version 3. 

\section{Historical Motivations for the General Public License}

The earliest license to grant software freedom was likely the Berkeley

Software Distribution (``BSD'') license.  This license is typical of what are

often called lax, highly permissive licenses.  Not unlike software in the

public domain, these non-copyleft licenses (usually) grant software freedom

to users, but they do not go to any effort to uphold that software freedom

for users.  The so-called ``downstream'' (those who receive the software and

then build new things based on that software) can restrict the software and

distribute further.

The GNU's Not Unix (``GNU'') project, which Richard M.~Stallman (``RMS'')

founded in 1984 to make a complete Unix-compatible operating system

implementation that assured software freedom for all.  However, RMS saw that

using a license that gave but did not assure software freedom would be

counter to the goals of the GNU project.  RMS invented ``copyleft'' as an

answer to that problem, and began using various copyleft licenses for the

early GNU project programs\footnote{RMS writes more fully about this topic in

  his essay entitled simply

  \href{http://www.gnu.org/gnu/thegnuproject.html}{\textit{The GNU Project}}.

    For those who want to hear the story in his own voice,

    \href{http://audio-video.gnu.org/audio/}{speech recordings} of his talk,

    \textit{The Free Software Movement and the GNU/Linux Operating System}

    are also widely available}.

\section{Proto-GPLs And Their Impact}

The earliest copyleft licenses were specific to various GNU programs.  For

example, \href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs

  General Public License} was likely the first copyleft license ever

published.  Interesting to note that even this earliest copyleft license

contains a version of the well-known GPL copyleft clause:

\begin{quotation}

You may modify your copy or copies of GNU Emacs \ldots provided that you also

\ldots cause the whole of any work that you distribute or publish, that in

whole or in part contains or is a derivative of GNU Emacs or any part

thereof, to be licensed at no charge to all third parties on terms identical

to those contained in this License Agreement.

\end{quotation}

This simply stated clause is the fundamental innovation of copyleft.

Specifically, copyleft \textit{uses} the copyright holders' controls on

permission to modify the work to add a conditional requirement.  Namely,

downstream users may only have permission to modify  the work if they pass

along the same permissions on the modified version that came originally to

them.

These original program-specific proto-GPLs give an interesting window into

the central ideas and development of copyleft.  In particular, reviewing them

shows how the text of the GPL we know has evolved to address more of the

issues discussed earlier in \S~\ref{software-and-non-copyright}.

\section{The GNU General Public License, Version 1}

In January 1989, the FSF announced that the GPL had been converted into a

``subroutine'' that could be reused not just for all FSF-copyrighted

programs, but also by anyone else.  As the FSF claimed in its announcement of

the GPLv1\footnote{The announcement of GPLv1 was published in the

  \href{http://www.gnu.org/bulletins/bull6.html\#SEC8}{GNU'S Bulletin, vol 1,

    number 6 dated January 1989}.  (Thanks very much to Andy Tai for his

  \href{http://www.free-soft.org/gpl_history/}{consolidation of research on

    the history of the pre-v1 GPL's}.)}:

\begin{quotation}

To make it easier to copyleft programs, we have been improving on the

legalbol architecture of the General Public License to produce a new version

that serves as a general-purpose subroutine: it can apply to any program

without modification, no matter who is publishing it.

\end{quotation}

This, like many inventive ideas, seems somewhat obvious in retrospect.  But,

the FSF had some bright people and access to good lawyers when it started.

It took almost five years from the first copyleft licenses to get to a

generalized, reusable GPLv1.  In the context and mindset of the 1980s, this

is not surprising.  The idea of reusable licensing infrastructure was not

only uncommon, it was virtually nonexistent!  Even the early BSD licenses

were simply copied and rewritten slightly for each new use\footnote{It

  remains an interesting accident of history that the early BSD problematic

  ``advertising clause'' (discussion of which is somewhat beyond the scope of

  this tutorial) lives on into current day, simply because while the

  University of California at Berkeley gave unilateral permission to remove

  the clause from \textit{its} copyrighted works, others who adapted the BSD

  license with their own names in place of UC-Berkeley's never have.}.  The

GPLv1's innovation of reuable licensing infrastructure, an obvious fact

today, was indeed a novel invention for its day\footnote{We're all just

  grateful that the FSF also opposes business method patents, since the FSF's

  patent on a ``method for reusable licensing infrastructure'' would have

  not expired until 2006!}.

\section{The GNU General Public License, Version 2}

\section{The GNU General Public License, Version 3}

\section{The Innovation of Optional ``Or Any Later'' Version}

\section{Complexities of Two Simultaneously Popular Copylefts}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{GPLv2: 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

0--2. These are the straightforward sections of the GPL that define the

simplest rights that the user receives.

\section{GPLv2 \S 0: Freedom to Run}

\label{GPLs0}

\S 0, the opening section of GPLv2, sets forth that the work is governed by

copyright law. 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, \S 0 makes an inference that copyright law is the only

system under which it is governed. 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{GPLs6} and~\ref{GPLs7}). 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 of copyrighted material is an established legal doctrine that

permits certain 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 a very few lines

(less than seven or so) and reuse them as you would with or without

licensing restrictions.

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.

\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 \S 0.

\medskip

The bulk of \S 0 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, not the licenses that utilize it.

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.

\section{GPLv2 \S 1: Verbatim Copying}

\label{GPLs1}

GPLv2 \S 1 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 \S 1. These are in some ways the most important part of

the redistribution, which is why they are mentioned by name. The 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 someone would be

surprised the software she got was licensed under GPL\@. 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

proposed state-level UCITA bills (which have never obtained widespread

adoption), 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 redistributors to keep the disclaimer very visible. (See

Sections~\ref{GPLs11} and~\ref{GPLs12} of this tutorial for more on GPL's

warranty disclaimers.)

Note finally that \S 1 begins to set forth the important defense of

commercial freedom. \S 1 clearly states that in the case of verbatim

copies, one may make money. Redistributors are fully permitted to charge

for the redistribution 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}

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 \S\S 2--3 of GPLv2\@. 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 \S 0 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}