A new opinion from the 9th Circuit, filed December 16, 2024, may change the way we think about copyleft licensing. It’s rare for the courts to opine on what constitutes a derivative work under copyright law, even less so for software. The interpretation of copyleft licenses–GPL and AGPL in particular–turn heavily on the notion that integrating code creates a derivative work. This idea is particularly bound up in the text of GPL version 2, which uses the term derivative work liberally (albeit inconsistently) as a basis for exerting control over licensing of integrated libraries.
Two Software Giants
Remini Street and Oracle are direct competitors engaged in a long and expensive legal war. Remini Street offers support services for various Oracle software, notably PeopleSoft software (which handles HR and similar tasks). Oracle wants to stop them.
Oracle first sued Rimini for copyright infringement in 2010. In a prior leg of this legal journey, the trial court found that Rimini infringed on Oracle’s copyrights by engaging in “cross use.” (This term is not common, but it apparently means applying software updates to multiple users.) Rimini then updated its business practices and sought a declaratory judgment that its revised “Process 2.0” did not infringe Oracle’s copyrights. Oracle counterclaimed for copyright infringement, seeking more than one billion dollars in damages.
At summary judgment, the trial court held that Rimini had infringed Oracle’s PeopleSoft copyrights and that an update created for the City of Eugene’s PeopleSoft implementation was a “derivative work” of Oracle’s software. The district court then entered a permanent injunction against Rimini, ordering it to delete certain software files.
The trial court held that Rimini-written files and updates developed were infringing derivative works because they only interact and are useable with Oracle software. (Oracle Int’l Corp., 2023 WL 4706127, at *66.) In effect, the district court adopted an “interoperability” test for derivative works—if a product can only interoperate with a specific copyrightable work, then it must be derivative of that work.
However, the 9th Circuit disagreed, saying “Mere interoperability isn’t enough.” The court distinguished translations, abridgments, and other examples of derivative works, named in the copyright statute’s definition, from interoperable software that does not substantially incorporate the original work, noting, “Whether a work is interoperable with another work doesn’t tell us if it substantially incorporates the other work.” It recited that “Rimini claims that thousands of its files fall into this category—programs that are interoperative with Oracle’s PeopleSoft but do not contain Oracle’s copyrighted code. Without more, mere interoperability isn’t enough to make a work derivative….Instead, a derivative work must actually incorporate Oracle’s copyrighted work, either literally or nonliterally. …[S]imply being an extension or modification of a copyrighted work without any incorporation is not enough to create a derivative work.”
The court declined to reach a conclusion on two other interesting points of copyright law in software licensing: whether Oracle’s customers are ultimately owners or licensees of their copies of Oracle’s software, and whether Rimini could rely on the “essential step” defense under § 117(a)(1), which allows running of software without a copyright license. Both of these are key to enabling third parties to host and manage software for customers who have purchased licenses from software vendors.
Effect on Copyleft
This new opinion is potentially relevant to the interpretation of GPL, particularly GPL version 2. One premise of copyleft is that the license can only control activity that requires a copyright license. Otherwise, there is no need to adhere to the license terms. But when GPL 2 was written, exactly what copyright covers was unclear. So, downstream developers of GPL have always pondered this question: if I create a library that interoperates with the GPL program, but is a separate dynamically linked library, must it also be provided under GPL or a compatible license?
This question was first brought into focus by developers who wanted to create proprietary loadable kernel modules (LKMs) for the Linux kernel. LKMs are, by definition, within the same executable process as the kernel, which is covered by GPL, but separate, dynamically linked, library files. (Similar questions exist for, say, libraries in user space that operate with GPL programs in user space, but the LKM question is the quintessential embodiment of this question, so I use it here as a proxy for the larger question.)
In particular, the practical question is whether proprietary LKM developers can distribute their LKMs, allowing customers to run them in a “meal kit” manner. The argument goes like this:
- Customers all enjoy the rights of GPL, and therefore can use the GPL-licensed kernel freely.
- Vendors enjoy the rights of GPL, and can distribute the kernel under GPL freely.
- LKMs are separate files from the kernel, not built into the same executable except by reference at runtime.
- This reference requires reference to a kernel API.
- While the customer may create a derivative work by combining the kernel and LKM at runtime, creating a derivative work does not trigger source code sharing–only distribution does that.
- The LKM’s use of the API does not create a derivative work.
- Therefore, neither the vendor nor the customer is violating GPL.
The opposite position is that an LKM is a derivative work, regardless of whether it is distributed separately. This turned on the idea that in order to be interoperable, the LKM library had to include a portion of the kernel–its relevant API–which made it derivative.
This new opinion puts paid to the idea that an LKM is necessarily a derivative work, at least in the 9th Circuit. But it leaves open the question of whether an LKM might contain substantial portions of the kernel and therefore still be derivative. Indeed, any LKM would contain some elements identical to its interoperable code–such as interface definitions (APIs) or header files. No US court has created precedent on whether those are necessarily substantial.
However, we got close, once. Functional elements of code enjoy no copyright protection. In the past, many have reasoned that an API is, by definition, functional. This question was at the forefront of the Oracle v. Google lawsuit, where Google was accused of copying portions of the API for Java. The trial court (Judge Alsup, also in the 9th Circuit) held that APIs are not protectable, and therefore copying an API was not infringement, However, that ruling was later overturned (on appeal in the Federal Circuit), causing that case to go into a different doctrinal direction.
It’s my view–and I doubt I will be alone–that it is functionally identical to say that (a) per Remini Street, mere interoperability does not create a derivative work, and (b) per the Alsup opinion in Oracle v. Google, APIs standing alone are not protectable. The two opinions yield the same result, via different doctrinal paths. So perhaps, this new opinion restores the conclusion that many believed correct in the Alsup opinion.
Will it Matter?
Oracle v. Google was the last time a US court of appeals issued a meaningful opinion on the topic of software derivative works. That the Federal Circuit and 9th Circuit would come to different conclusions will surprise no keen follower of copyright law. The Federal Circuit, specially created to hear patent cases, is known to be exceptionally friendly to broad interpretations of intellectual property rights; the 9th Circuit, less so.
While this new opinion might put added wind into the sails of those making the time-honored LKM argument, it may not ultimately matter. This question has been a legal unknown for decades. In the meantime, most developers of LKMs have released them under GPL for practical reasons. That’s because, in all these years, the ambiguity of this legal question allowed GPL advocates, and community pressure, to settle the issue de facto. Most people stopped bothering with the LKM argument years ago.
Moreover, the Oracle v. Remini Street case is not over. The opinion does not dispose of the whole case, and is only precedent in the 9th Circuit. But opinions on topics like these are so rare that this one is likely to influence later courts who may examine the definition of software derivative works.
(Note: This blog post quotes heavily from the court’s opinion. Items with quotation marks are from the opinion, but other portions of this post are not marked with quotation marks. I did this for ease of reading. Also, the opinion contains related discussion of Lanham Act claims and license interpretation, which I have omitted.)
