Disputes over Derivative Works

I left for last the most difficult legal question facing the open source software industry: What is a "derivative work" of software?

If an open source license doesn't have a reciprocity condition, derivative works simply don't cause problems. You can safely ignore this topic entirely if you license software under an academic open source license.

Early in this book I explained the complex problem of separating expressions from ideas, art from science, and right brain from left brain creations. To determine whether a software program is a derivative work of another software program, the courts need to disentangle these abstractions. The procedure that many courts use, called the abstraction-filtration-comparison test, is described below.

I previously took the easy way out. I said that you should treat derivative works as subsequent versions of an earlier work. But that easy way out no long suffices; works resemble each other in many subtle ways. For example, Microsoft Excel 2002 is probably a derivative work of Microsoft Excel 2000, but is it a derivative work of Lotus 1-2-3? Of Visicalc? Is Linux a derivative work of UNIX? Is the implementation of software conforming to an industry standard a derivative work of that specification? How much copying of source code is required to create a derivative work? How much copying of source code may you legitimately do before you create an infringing derivative work? Does linking create a derivative work?

These questions are important to some licensees because they want to avoid the reciprocity conditions of open source licenses, and they are important to licensors because they want to enforce those reciprocity conditions. Disputes over whether particular software is a derivative work of licensed software, and thus subject to reciprocity, are inevitable.

A derivative work, you will recall, is a work based upon a preexisting work. The preexisting work is modified, translated, recast, transformed, or adapted so as to create an improved (or at least different) derivative work. (17 U.S.C. § 101.)

In theory, different copyrightable works, including software, can be compared to determine whether one is a derivative work of the other. This may involve a comparison of the source code or the object code, depending upon the facts of the specific case.

Expert assistance may be needed. We may have to perform reverse translation or automated source code comparisons to identify similarities between two programs for presentation to a court . If we only have object code, we may have to compare object code versions or reverse-compile the software to create easy-to-read versions. This first step is itself complicated, because the parties to the dispute have to reduce the software similarities to simple constructs that can be recognized by nontechnical judges and juries.

In the simple case, two programs can be set side by side and their source code compared. A program that is substantially similar to a preexisting program is likely to be a derivative work. That is because such similarities rarely occur by coincidence , at least for substantial portions of the source code. But substantial similarity (a term of art in copyright litigation) is not enough to identify a derivative work.

Some similarities relating to the basic functioning of computer systems (e.g., subroutine entry and exit code, external interfaces) can occur by coincidence or intentionally because "that's the way computers have to work." Some snippets of software may be too small and ordinary to be copyrightable. In other cases program functions are coded in a particular way because that is the only (or most effective, or the industry standard) way to implement that specific function on that particular computer architecture. Such source code must be excluded from the comparison because it is not entitled to copyright protection; instead, it is idea that has merged into expression, and is thereby rendered uncopyrightable.

In practice, comparing two works of software is not as simple as a byte-by-byte or line-by-line scan. Software is often extensively modified between versions. Entirely new coding techniques, programming languages, and interface designs can make software appear to be very different at the source code level even when it is derived from an earlier version. Higher levels of abstraction may be needed to identify the similarities.

At those higher levels of abstraction, copyright protection:

• DOES NOT extend to any ideas, procedures, processes, systems, methods of operation, concepts, principles, or discoveries contained in the original program.

• MAY extend beyond the literal code of a program to its nonliteral aspects, such as its architecture, structure, sequence, organization, operational modules, and computer user interface.

These more abstract similarities are not always obvious to the naked eye; identifying them often requires expert guidance. In any event, once the noncopyrightable similarities are filtered out, only the remaining copyrightable similarities are compared. Substantial similarity of the copyrightable elements is evidence of copyright infringement, but substantial similarity of the noncopyrightable elements means nothing at all.

In Chapter 6, in the context of the GPL, I described the arguments that have raged in the open source community about whether linking between programs creates a derivative work. Nothing in the law of copyright suggests that linking between programs is a determinative factor in derivative work analyses by courts ”except perhaps as evidence of one of the abstract, nonliteral, copyrightable aspects of the software, such as program architecture, structure, and organization.

In such cases, the burden usually rests on the licensor to explain to the court why the simple interaction of software modules ”black boxes merely plugged into other software ”creates a derivative work of the black boxes. Merely combining black boxes, I suggested earlier, creates collective works, not derivative works.

Substantial similarities, standing alone, are never enough to characterize a derivative work. An independent creation is not a derivative work no matter how much it resembles a preexisting work. Copyright only protects against copying, not against someone writing the same expression independently, by coincidence. So plaintiffs may still have to prove actual copying.

Evidence can sometimes be provided by a plaintiff to show that an alleged infringer had access to the preexisting work and an opportunity to copy it. For open source software, proving access and opportunity is relatively easy because the source code is published. The burden of proof then may shift to the defendant to show that the substantial similarities were an accidental byproduct of independent creation.

In practice, most infringing derivative works of software are blatant and not subtle because it usually takes more time to obscure an infringing work than to just write it anew from scratch. Nevertheless, when defendants intentionally set out to hide their copyright infringement, it can be difficult to prove.

Such extreme efforts to cheat open source software licensors by pretending not to have created derivative works is usually a waste of time. It is often less expensive just to write equivalent software from scratch. Why risk creating software with questionable provenance? It may result in an expensive infringement lawsuit ”which you may lose. If you try to sell such software, your customers may reject it as risky even though it is not actually proven to have infringed.

The better plan is not to tread too close to the line separating collective and derivative works. Companies that create software should make sure their employees don't have access to preexisting software, and they should train their employees not to copy other software.

Instead of accepting the risk that their software will be called a derivative work, companies sometimes prefer to refuse software under licenses containing reciprocity obligations. Such software may then be available under dual licensing options, such as the ones described in Chapter 11.

Instead of avoiding the creation of derivative works, there's a more principled argument to be made that it is a public benefit to create derivative works and to distribute them under reciprocal open source licenses. That way everyone can profit from improvements to software.

Contributions to the software commons are always welcomed. So I encourage you to take a very broad view of your reciprocity obligations; don't be stingy about them. Contribute as many of your derivative works as possible to the community.