Search

Derivative Works

Many users of open-source software are
frightened by the term “derivative works”. They worry they might
accidentally create derivative works and put their own proprietary
software under an open-source license. This is a complex topic that
courts and lawyers disagree on, but I think we find definitions to
ease people's concerns.

First, a brief reminder of why the term derivative work is so
important. Here's what a typical license might say: “Licensor
hereby grants you a license...to prepare derivative works based
upon the original work and to distribute those derivative works
with the proviso that copies of those derivative works
that you distribute shall be licensed under this
License.” See, for example, the GNU General Public
License at
www.gnu.org/licenses/gpl.html
or the new Open Software License at
www.opensource.org/licenses/osl.php.

How can you tell when you've created a derivative work? The
Copyright Act, at 17 U.S.C. §101, is a little vague and
doesn't say anything at all about software:

A “derivative work” is a work based upon one or
more pre-existing 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”.

Almost everyone agrees that if you take the copyrighted
source code of any program and physically modify it—actually
revise the program or translate it into another computer
language—you have created a derivative work of that program.
That's the simple case. If you do such a thing with a program
licensed under the GPL or the OSL, you must honor the reciprocity
provision and publish the source code of the derivative works you
distribute.

But what happens if you merely copy an original program as a
component in your own, perhaps larger, work? Does it make a
difference that you didn't actually modify the source code to
combine the original program into your larger work?

Does merely linking to a program without any change to the
original source code create a derivative work of that program?
Almost every program links to library routines. Surely, one doesn't
create a derivative work of a library simply by calling a sqrt
function in the library. Why should it be any different when you
link to something as complex as an enterprise server or database
engine? What about linking from a software program, such as when
linking your device driver into a GPL- or OSL-licensed program like
Linux?

Does it matter what technical form of linking you use? Or is
that analysis (e.g., static linking, dynamic linking, passing data
through an API, as an object contained within a larger object,
etc.) a technical morass that obscures the fundamental issue? How
can the law of derivative works keep up with technological change
in the world of software engineering?

These questions are important because some licenses require
you to publish the source code of your portion of the resulting
derivative work program, a burden you may not want to accept.
Here's how I would decide in the cases described above.

1) The primary indication of whether a new program is a
derivative work is whether the source code of the original program
was used, modified, translated or otherwise changed in any way to
create the new program. If not, then I would argue that it is not a
derivative work.

2) The meaning of derivative work will not be broadened to
include software created by linking to library programs that were
designed and intended to be used as library programs. When a
company releases a scientific subroutine library, or a library of
objects, for example, people who merely use the library,
unmodified, perhaps without even looking at the source code, are
not thereby creating derivative works of the library.

3) Derivative works are not going to encompass plugins and
device drivers that are designed to be linked from off-the-shelf,
unmodified, programs. If a GPL-covered program is designed to
accept separately designed plugin programs, you don't create a
derivative work by merely running such a plugin under it, even if
you have to look at the source code to learn how.

4) In most cases we shouldn't care how the linkage between
separate programs was technically done, unless that fact helps
determine whether the creators of the programs designed them with
some apparent common understanding of what a derivative work would
look like. We should consider subtle market-based factors as
indicators of intent, such as whether the resulting program is
being sold as an “enhanced” version of the original, or whether
the original was designed and advertised to be improvable “like a
library”.

You should care about this issue to encourage that free and
open-source software be created without scaring proprietary
software users away. We need to make sure that companies know, with
some degree of certainty, when they've created a derivative work
and when they haven't.

Legal advice must be provided in the course of an
attorney-client relationship specifically with reference to all the
facts of a particular situation and the law of your jurisdiction.
Even though an attorney wrote this article, the information in this
article must not be relied upon as a substitute for obtaining
specific legal advice from a licensed attorney.

Lawrence Rosen
is an attorney in private practice, with offices in Los Altos and
Ukiah, California
(www.rosenlaw.com). He
is also corporate secretary and general counsel for the Open Source
Initiative, which manages and promotes the Open Source Definition
(www.opensource.org).