Interview: Dan Ravicher on derived works

December 10, 2003

By Pamela Jones, Editor of Groklaw

What is a derivative work when it comes to software? Between SCO's attempts to define it as "anything that ever breathed the same air as Unix" and the recent discussions on linux-kernel about the status of closed-source modules (see this week's Kernel Page), it is only natural to wonder if there is any way, short of going before a judge, to know. Is there a standard rule a programmer can measure his work by and know whether he has produced a derived work or not?

Dan Ravicher, Esq., Senior Counsel, Free Software Foundation, and Executive Director, Public Patent Foundation, was kind enough to grant me an interview and explain. Note that he is discussing the situation in the US, because that is where he practices. However, his ultimate advice applies to international copyright issues as well, namely: ask a lawyer who practices where you live for an opinion. Get it in writing.

PJ: Is there one definition, The Definition, as it were, of derivative works that applies to everyone?

The definition of derivative work is an issue under copyright law, which is exclusively a federal question (state courts are forbidden from addressing the issue). Therefore, there could conceivably be 94 different "derivative work" definitions, as there are 94 different federal district courts (the trial level of the federal court system). [Note: There could be even more, as there are several judges within each district, who could each have different opinions on the law.]

Although district court judges are supposed to give deference to one another's opinions, they often do not. As such, above those 94 district courts, there are 13 circuit courts of appeals, which each attempt to unify the law as between all the district courts within their jurisdiction. Here's a map showing which districts fall into which circuits. Again, like the district court judges, the circuit court judges are supposed to give deference to one another's opinions, but they often do not. So, above the 13 circuits, is the Supreme Court, which is supposed to unify law amongst the circuits.

Every case has a right to appeal to the Circuit Court, but appeal to the Supreme Court is only by discretion. As of yet, despite the difference in opinions between the circuits regarding the question of what constitutes a derivative work of software, the Supreme Court has not taken any such case. One can speculate why this is so, including that many of the circuits, including two of the most influential to the conservative Supreme Court, the 7th and the 4th, have yet to take an opinion on the issue. Further, the 9th and 2nd Circuits, routinely the most important for copyright law (because NY and CA are home to media companies and Hollywood), are pretty much in agreement on the issue, and several circuits have followed their lead.

If it is circuit by circuit, how does Utah's circuit, where the SCO v. IBM case will be decided, define it?

Utah's District Court is within the 10th Circuit, which has adopted the Abstraction, Filtration, and Comparison test of the 2nd Circuit. For a discussion of how that test defines derivative work, you can read a paper I have written on that subject here [PDF format].

[Editor's note: the above paper actually covers a few different tests used by the circuit courts to determine whether one program is a derived product of another. It is recommended reading for anyone who would like a better understanding of the different ways of approaching this problem.]

Please bear with me. This is a long question, but I want to be sure you cover the complete question, and I know you are a programmer as well as an attorney: The Linux kernel is, of course, licensed under the GPL. There is a continuing controversy over the legal status of closed-source kernel modules. Nobody really likes them, but they have been tolerated so far. There are kernel hackers who have threatened to eventually take a binary module vendor to court for infringing their copyrights, however.

Is a kernel module a derived product or not? Some people claim that there are precedents saying that anything which can be unplugged and replaced falls on the other side of the boundary and cannot be considered a derived product. Others point out the substantial amount of inline function code used by Linux modules, along with the deep knowledge of kernel internals required, and say that modules are necessarily derived products.

One can point to a continuum of modules to see that the situation is not simple. LSM security modules can hook into almost every part of the kernel and fundamentally change its operation; almost everybody agrees that they are derived products. On the other hand, modules exist which allow the loading of Windows NDIS drivers into a Linux kernel; few people would claim that the Windows driver has become a derived product.

Is there any way to figure out where the boundary really is short of asking a judge?

The intuition that there is no bright line answer regarding modules is correct. The test of derivative work is a very fact-specific one; meaning that minor differences can substantially impact the result. In practice, highly factual issues are typically resolved by both sides in litigation having representative experts testify that the facts lead to one conclusion or the other.

However, this doesn't mean one needs to necessarily wait for a judge to decide the issue in order to have some guidance. In order to better manage and calculate legal uncertainty, clients often ask their attorneys for a legal opinion regarding a certain situation. In what are called "Opinion Letters", attorneys opine as to the conclusion they think would be reached if a judge addressed at the issue. For instance, a few years back the W3C sought the opinion of its attorneys regarding whether or not one of its standards infringed a patent, which you can read here.

Although such letters are not a guarantee that the issue, if ever presented to a court, would be resolved in that way, they do allow the client or other recipient of the letter to rely on the attorney's opinion in making decisions. That reliance, if reasonable and based on a "competent opinion", may go a long way to help the client prove they did not act in bad faith, which is very important under the law because penalties for copyright infringement can be drastically increased if the infringer is found to have acted in bad faith.

Coming soon: the second half of this interview, which covers free software and patents, especially Microsoft's claimed FAT filesystem patent.

Index entries for this article
GuestArticles	Jones, Pamela

derived work vs mere aggregation

Posted Dec 11, 2003 7:22 UTC (Thu) by pjm (guest, #2080) [Link] (3 responses)

The linked-to paper is very helpful for knowing how much must be rewritten to avoid copyright claims, but it doesn't help distinguishing a derivative work from "mere aggregation". A Linux/Gnu system including the Linux kernel and acroread (and bash etc.) would seem to be considered a derivative work of each of its constituent parts according to the paper, yet I gather it isn't usually considered a derivative work of either. (Similarly, the combination of the Linux kernel with a windows driver would be considered a derived work; of each; though that's not to say that the constituent parts are derived works of each other.) The Gnu GPL's explicit exclusion of "mere aggregation" may be relevant; perhaps what is at issue is not merely what is a derived work, but what is "mere aggregation"?

derived work vs mere aggregation

Posted Dec 11, 2003 7:50 UTC (Thu) by pjm (guest, #2080) [Link] (2 responses)

I retract the claim "yet I gather it isn't usually considered a derivative work of either". This perception may well be merely due to the "mere aggregation" exception in the GNU GPL.

derived work vs mere aggregation

Posted Dec 11, 2003 17:30 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (1 responses)

This brings up a point I haven't seen addressed: Larry Rosen of the OSI wrote a new license, the Open Software License, that claims to be a copyleft license that addresses perceived flaws in the GPL. Like the GPL, it requires derivative works to be licensed under the same terms. Unlike the GPL, it has no "mere aggregation" exception. It would appear that if the Linux kernel were licensed under the GPL, all programs distributed on a CD-ROM along with the Linux kernel would need to be either under the OSL or a compatible but more permissive license, since the CD-ROM is a derivative work of the Linux kernel. That makes the OSL much more "viral" than the GPL.

derived work vs mere aggregation

Posted Dec 12, 2003 10:09 UTC (Fri) by piman (guest, #8957) [Link]

At the moment, the OSL is considered nonfree by at least Debian (I don't know if the FSF has an opinion on it). Clause 5 is the sticking point, but clause 9 isn't too popular either.

Interview: Dan Ravicher on derived works

Posted Dec 11, 2003 11:04 UTC (Thu) by ekj (guest, #1524) [Link]

PJ in Lwn. Woohoo ! Well, she migth have contributed articles earlier, but escaped my attention.

Anyways, I hope Lwn will consider asking PJ to contribute also in the future when legal issues come up. She writes clearly, understandably even to people with no legal background, and never falls for the temptation to simplify too much. When reading her writing, you always get the impression that you're getting the straigth dope.

And PJ ? Welcome to Lwn. Stick around. We have need for people like you around here.

Interview: Dan Ravicher on derived works

Posted Dec 13, 2003 18:29 UTC (Sat) by giraffedata (guest, #1954) [Link]

I was rather disappointed by the article. It's a great interview about the legal process, but I was expecting to read information about what constitutes a derived work.

The referenced paper doesn't have the information either. It describes derived work tests at an abstract level, and the only substantial information I found in it is that copying the value of a constant does not create a derived work (in certain jurisdictions).

As with most legal matters, it would have been really nice to see a few concrete examples of works that have been found to be derived and works that have been found not to be.

Interview: Dan Ravicher on derived works

Posted Dec 13, 2003 19:47 UTC (Sat) by torsten (guest, #4137) [Link]

I'd like to see a defined set of rules which allow distribution of binary modules, bring some concensus to this issue, and still abide the GPL.

Here's my suggestions.

1. #include'ing headers does not affect the licensing of a module.
2. Non-GPL modules must use only exported kernel headers.
3. Non-GPL modules may never be distributed with a Linux kernel.
4. Non-GPL modules distributed separate from the Linux kernel have no specific license requirement, subject to (2).
5. Non-GPL modules may not require a vendor-supplied or otherwise modified kernel - they must use standard interface from standard kernels.

Any non-GPL/binary modules must be written from scratch - no copying kernel or other GPL driver software. They can be developed in-house, but the compiled code actually distributed without a Linux kernel, and must not require a vendor-supplied or vendor-modified kernel.