Derivative Works

When is one program a “derivative work” of another?

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.

email: lrosen@rosenlaw.com

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).

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What about Source vs Binary?

Anonymous's picture

What if I download a source only version of a GPL work?

Is the compiled binary a derived work (a translation?) or is it simply "fair use" of the GPL work?

If it is not "fair use", what else are you supposed to do with source code? Just read it?

If it is "fair use", are source only packages shooting themselves in the foot?

U R Confused--Linked in what way!!

Anonymous's picture

Only dynamic linking is legal to GPL'd libraries because that does not include the source code in the work. Static linking is not allowed by the GPL because that does include the source code in the resulting work. LGPL is meant to allow static linking into new works. Stallman allows this sometimes for different reasons--for example, when alternative proprietary libraries are all ready freely available and already allow this... such as with flex and bison.

Re: Derivative Works

Anonymous's picture

While the FSF's disagreement might indicate at what point the FSF, in enforcing it's own copyrights, might decide that filing a suit is necessary, it is not necessarially the interpretation which a court, applying the pronciples of Copyright law, might give to the same provision.

The great strength of the GPL is also the great weakness of the GPL. The GPL utilizes the exclusive rights granted by copyright law to the author of a piece of software to perform a kind of legal jiu jitsu. The strength of copyright law is used to subvert copyright law.

On the other hand, where copyright law is weak, the GPL is also weak. And Copyright law is weak in the area of derived works when it comes to software. That's because a "method of operation" is not copyrightable.

Recently there was a discussion on the Linux Kernel Mailing List about the NVidia graphics drivers for Linux. These drivers are distributed as a closed source binary object and a GPLed interface module which intergaces between the (GPLed) kernel and the closed source binary object. The question raised was is NVidia in violation of the GPL by distributing such a work. The correct answer is remarkably complex but it revolves around what constitutes a derivative work.

Is a driver a derivative work of the kernel? That depends. It may very well incorporate an include file or two and perhaps even some inline functions which are required to interface with the Kernel. The FSF position is that linking is determinative. But here's an example which might convince you otherwise.

What if the binary object was written for a completely different OS? It's a object file with functions and metadata so that it can be loaded and relocated. Is it a dervied work of the Linux kernel? Does writing an interface, using the generally accepted "methods of operation" for modules make it a derived work of the Kernel?

These legal questions are difficult. We also have to be careful not to overspecify when software becomes a derivative work of the OS it runs under or else we give Microsoft too much control over what software can me written and used on MS operating systems.

I think that the answer is clear, if you use published (or even undocumented) interfaces to an Operating SYstem, you are utilizing uncopyrightable "methos of operation" and are not creating derived works.

What does this say about incorporating GNU Readline? It tells you when the FSF is likely to sue you for doing so, not whether doing so makes you liable for creating a derived work.

Re: Derivative Works

Anonymous's picture

Even linking dynamically to a library requires using an include file of function prototypes in the C and C++ languages and that include file, being part of the GPL protected work, is now part of your source code, and thus, your work is now GPL.

So, in practical terms, there is no way to "link" to a GPL library without transferring the terms of the GPL to your own work.

I have never seen any C or C++ program that did not include some of the standard headers like stdio.h etc.

QED

No. The #include is

Anonymous's picture

No.

The #include is incorporated within an image in RAM when I compile, and there's explicit permission in the copyright law to make such copies if it's a necessary step in running the program.

Re: Derivative Works

Anonymous's picture

You really don't "need" header files with function prototypes to link c code. It's foolish not to use them, but they are not mandatory

Re: Derivative Works

Anonymous's picture

But it goes to the intent. Clearly the FSF has spelled out the intent of the GPL by creating the LGPL to address such circumstances as proprietary linking (with supporting documents that spell out their intent). Version 2 of the GPL was specifically written to deal with linking. There are stronger copyrights such as the Affero GPL which close the loophole for web services. Any other loopholes would be cleared up in version 3 of the GPL. It comes down to what the author of the library or program intended. If they wish proprietary programs to be able to link to their program then they would put it under the LGPL or a number of other OSI liscences. If however they intend any program linking or using their code to recontribute then there is the GPL.

Re: Derivative Works

Anonymous's picture

Sure it goes to the intent of what the author intended to accomplish with the license, but that does not address whether the author has the right to make that kind of restriction.

If I try to use a license which attempts to take away your right to make Fair Uses of my copyrighted work, I should expect such an attempt to fail because I'm not granted the right to restrict Fair Uses by copyright law. Sure my intent is clear, but unless I'm exercising an exclusive right guaranteed by Copyright Law, then I don't have the right to do that which I intend.

Consider this scenario.

Anonymous's picture

Suppose someone writes a library that implements a standard API - for which commercial versions already exist - and he GPL's it. Both libraries are dynamically linkable.

Now, I write an application that uses that standard API. Are you telling me

that if I link my binary against the GPL'ed library - then my application must be GPL'ed - but if I link it against the commercial version, it doesn't?

Bear in mind that the resulting binary will be bit-for-bit identical in those two cases.

Suppose - you are right - and I link against the commercial one - and distribute my application (without the library code). Now someone runs my application (without my knowledge) against the GPL'ed code. Is my application *now* caught in the GPL trap? What if I didn't even know the GPL'ed version of the library existed? What if it didn't even exist when I wrote my application?

If dynamic linking fell legally under the GPL, we could force Microsoft to release the entire source code to WORD - by simply writing a GPL'ed plug-compatible DLL that matched one of the DLL's that WORD links to!

That's just silly.

Hence, one absolutely MUST distinguish the dynamically linked case from the static case.

The difference between the intent of LGPL and GPL is mainly to cover that statically linked case. LGPL provides the application author with an alternative to releasing his source code when statically linking to the library.

Instead of GPL'ing the entire application source code, he may provide some means to re-link the application against alternative versions of the library. This could include shipping source code under some non-GPL license - or it could mean shipping partially compiled ".o" files with instructions on how to statically link against new versions of the library.

This provision allows library authors to provide statically linkable versions of their libraries that can still be used by closed source commercial applications - albeit with some difficulty. ..yet it still gives the end user most of the benefits of full GPL for the library code.

Without these provisions, there would also be terrible difficulties with linking applications to multiple libraries - some under GPL, others under some commercial license.

Re: Consider this scenario.

Anonymous's picture

but maybe the only problem is that you can't distribute it..

e[at]videocatwalk.com

NOT TRUE

Anonymous's picture

Dynamic linking, as Stallman himself puts it, "unfortunately cannot force the GPL upon the derrivative work".

Only static linking applies to what you are saying because only static linking includes parts of the library in the resulting work. As for dynamic linking, it could link to any compatible library. It doesn't necessarilly have to be the GPL'd one. The GPL'd one is separate and therefore cannot possibly have any legal rights over anything that links to it.

If you write a letter and save it in a format compatible with Microsoft Word, does that mean Microsoft can put a copyright on your letter?

Well...

Counsel's picture

I am not familiar with Word's license so, a hypothetical might be best...
If (1) the license under which "WordProcessingSoftware" (WPS) is released states that anything you write with the software is in the public domain; and (2) you agree to the license, use the software, and write a novel, is the novel in the public domain?

Is the "Novel" copyrighted by you? Is the copyright limited by the license under which you wrote the "Novel?"

Licenses may be binding, and I think good lawyers should work to make the license clear. The problem is that some companies can "make money" by having "unclear" licenses. I advice everyone to read the license(s) they agree to be bound by and attempt to understand their reach...

not quite

Anonymous's picture

If a license is on its face illegal under copyright law (e.g. does not allow fair use), then even if you agree to the license you are not bound by it. In much the same way that a contract that violates existing law is not binding (i.e. even if you sign a contract to become someone's slave, you obviously are not bound by it).

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState