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.