If APIs aren't (shouldn't be) copyrightable, how can ZFS-on-Linux infringe the GPL?

Question

Note: This is a question about a specific individual's viewpoints and beliefs. Good answers will cite that individual, or other people with similar beliefs.

Bradley Kuhn of the Software Freedom Conservancy holds (or has previously held) the following positions:

• APIs are not copyrightable, and also the Federal Circuit never said they are. (I am ignoring the second half of that sentence to focus on the first.)
• Compiling ZFS into a Linux kernel module and distributing the resulting binary is a GPL violation.

However, these positions seem contradictory to me. As I understand it (and I may be mistaken about this part), the ZFS kernel module is built entirely from ZFS code, plus a small amount of "declaring" code similar to that at issue in Oracle v. Google. Yes, the Java API is a "public" or "external" API and the Linux API is a "private" or "internal" API, but I don't see why copyrightability should care about that distinction. They are both functional objects in the sense of the merger doctrine, regardless of whether they are labeled as "internal" or "external" (or even "GPL'd callers only"). An API is an API, and if you can't copyright an API, then you can't copyright any API.

If the kernel module is not legally a derivative work of the Linux kernel (because it incorporates only an uncopyrightable API from the Linux side), I cannot understand how it could infringe the GPL all by itself. After all, the GPLv2 quite plainly says:

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

The binary module is "distributed as a separate work." It certainly doesn't include a compiled copy of the entire Linux kernel. The GPL does not say "...when you distribute them in source form as separate works," so the fact that the module is a binary is irrelevant.

From an equitable perspective, we can argue that the ZFS code is obviously not based on Linux, and it would be "unfair" to apply the GPL to it. And the GPL itself supports that position:

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

One might point out that Canonical also distributes the Linux kernel itself, and perhaps by distributing both at once, they somehow infringe the GPL. But that runs right into the next paragraph of the GPL:

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

So I really don't understand how Mr. Kuhn can simultaneously maintain that APIs are not subject to copyright, and that Canonical's ZFS distribution is a copyright infringement.

What part of Mr. Kuhn's reasoning have I misunderstood? Can these two positions be reconciled?

(I am "picking on" Mr. Kuhn in particular because he has clearly articulated both these viewpoints in detailed blog posts, but many other people in the various FLOSS communities have similar beliefs. I have nothing against him personally.)

Answer 1

The two statements are compatible because the argument that Linux-plus-ZFS is a copyright violation isn't based on the copyrightability of the API through which they interact.

The licence violation arises because GPLv2, which covers the kernel, requires that derivative works in their entirety be distributed under GPLv2. The CDDL, which covers ZFS, requires that any files which were under CDDL remain so. If Linux+ZFS is a single work, it cannot therefore be distributed without violating the terms of at least one of those licences. The FSF explains this in more detail here.

Why would Linux+ZFS be a single work? If it is, it's because linking two codebases together makes a derivative work of both. This is not a settled issue; you can find it argued in any number of places. We have a pair of questions that argue both for and against the conclusion; note that APIs (and the copyrightability thereof) don't feature in any of the answers.

So because the question of whether or not Linux+ZFS is a single work for copyright purposes doesn't turn on the issue of the API between them, it's possible for both statements to be true at the same time.

Edit (following your comment): "If the module is not a derivative work of the kernel, and the instructions certainly aren't either, then I do not see where a "classical" copyright infringement would live." I think I agree with you there. Note, however, that your argument starts "if the module isn't a derivative work". What we're examining in my answer, and the linked answers, are the arguments that it is a derivative work of the kernel, and those arguments don't turn on the copyrightability of the API. Nor, incidentally, do they turn on how many parts the work is shipped in.

Answer 2

The two topics are entirely orthogonal, in my understanding. The debate about whether APIs can be copyrighted is about whether program interfaces are copyrightable even without the implementation of those interfaces. In the case of Oracle v. Google, the question was whether Google could duplicate class and method names without infringing Oracle's copyright. For example, is a method signature like

void <E> quicksort(List<E> items);

along with many other similar method signatures protected under copyright?

The issue with ZFS and Linux is unrelated as far as I can tell. In that case, all parties agree that Linux is copyrightable and ZFS is copyrightable because they are more than mere APIs. Instead, Linux and ZFS are implementations of APIs, along with the specification of the APIs.

To continue this point, as an example, I think people who would argue API are not copyrightable would say it would be okay for someone (e.g. Canonical) to completely reimplement ZFS with the same interface and release the reimplementation under any license. If that license were GPLv2 compatible, then it could be released together with Linux with no issue.

Whether you agree with Kuhn's characterization of "ZFS+Linux" as a combined, derivative work, rather than an aggregation of two separate programs is a separate question.