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).
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- The Humble Hacker?
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Death of RoboVM
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The US Government and Open-Source Software
- ACI Worldwide's UP Retail Payments
- Open-Source Project Secretly Funded by CIA
- Varnish Software's Hitch
- New Container Image Standard Promises More Portable Apps
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide