2

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:

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.)

3

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.

  • Sorry, but I have to downvote, because Canonical is not distributing any single file that can fairly be described as "Linux+ZFS." They are distributing two separate files (the kernel and the module) plus instructions for how to link them together. 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. (In other words "If the Linux kernel were proprietary, then this would not infringe. The GPL only grants rights, so it still does not infringe.") – Kevin May 8 at 7:05
  • @Kevin see edit above. – MadHatter May 8 at 7:46
  • That's still no adequate. The sole similarity between the module and the kennel is a bunch of function prototypes, i.e. an API. The heart of my question is how that can possibly be a derivative work, and your argument for that proposition is to point to a pair of other questions which don't discuss this issue. That is not an answer. – Kevin May 8 at 13:38
  • @Kevin it's the only argument you'll get. Whether or not dynamic linking establishes a derivative relationship for the purposes of copyright control, your personal feelings about the tenuousness of the link between the code structures are immaterial. Derivative works are a matter of copyright law, not of coding. – MadHatter May 8 at 14:07
  • 3
    The heart of your question is whether a dynamically-linked kernel module is prima facie a derivative work of the kernel. If you can't see how I'm answering that for you, I don't know what else I can do. I think the upvotes the answer is garnering speak for how the community sees the issue. – MadHatter May 8 at 16:03
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.