The Linux Kernel, CDDL and Related Issues | Hacker News Reader

The Linux Kernel, CDDL and Related Issues

softwarefreedom.org

46 pointsbcantrill21 comments

    anything that has knowledge of and plays with fundamental internal 
    Linux behaviour is clearly a derived work. If you need to muck around
    with core code, you're derived, no question about it.

In 100+ places, the zfsonlinux/zfs.git master branch has to change its compile-time behavior depending on the details of the kernel it is being compiled for. i.e., out of 100+ yes-no questions, you only get a working zfs.ko if you answer each one in the same way the kernel does. To me, this indicates a strong likelyhood that zfs is way towards the "muck[s] around with core code" end of the spectrum.

(The 100+ places I cite are actually a count of 121 uses of the macro ZFS_LINUX_TRY_COMPILE while configuring zfs at zfs-0.6.5-166-gd2f3e29; each one presumably corresponds to one or more #ifdef sites in the actual source code of zfs, each one adapting to a change in the internal details of Linux from 2.6.x to the present day)

So, because it supports more than one KBI it is a derived work, whereas if it had one static KBI to only work on one specific version it would not be derived?

Not necessarily. But let's look at one specific instance of adapting to a different "KBI", as you call it. I picked HAVE_VFS_ITERATE, just because it sounded interesting. What's the story?

Well, in May 2013, Al Viro committed code to Linux to add several new "KBIs", dir_emit and related functions (in include/linux/fs.h, which does not have a license block):

    commit 5f99f4e79abc64ed9d93a4b0158b21c64ff7f478
    Author:     Al Viro <viro@zeniv.linux.org.uk>
    AuthorDate: Wed May 15 20:23:06 2013 -0400
    Commit:     Al Viro <viro@zeniv.linux.org.uk>
    CommitDate: Sat Jun 29 12:46:48 2013 +0400

    [readdir] switch dcache_readdir() users to ->iterate()
    
    new helpers - dir_emit_dot(file, ctx, dentry), dir_emit_dotdot(file, ctx),
    dir_emit_dots(file, ctx).
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    ...
    +static inline bool dir_emit(struct dir_context *ctx,
    +                           const char *name, int namelen,
    +                           u64 ino, unsigned type)
    +{
    +       return ctx->actor(ctx, name, namelen, ctx->pos, ino, type) == 0;
    +}
    +static inline bool dir_emit_dot(struct file *file, struct dir_context *ctx)
    +{
    +       return ctx->actor(ctx, ".", 1, ctx->pos,
    +                         file->f_path.dentry->d_inode->i_ino, DT_DIR) == 0;
    +}
    +static inline bool dir_emit_dotdot(struct file *file, struct dir_context *ctx)
    +{
    +       return ctx->actor(ctx, "..", 2, ctx->pos,
    +                         parent_ino(file->f_path.dentry), DT_DIR) == 0;
    +}
    +static inline bool dir_emit_dots(struct file *file, struct dir_context *ctx)
    +{
    +       if (ctx->pos == 0) {
    +               if (!dir_emit_dot(file, ctx))
    +                       return false;
    +               ctx->pos = 1;
    +       }
    +       if (ctx->pos == 1) {
    +               if (!dir_emit_dotdot(file, ctx))
    +                       return false;
    +               ctx->pos = 2;
    +       }
    +       return true;
    +}

Soon after, this was added in zfsonlinux/zfs.git in include/sys/zpl.h (which has a CDDL license block), gated by HAVE_VFS_ITERATE:

    commit 0f37d0c8bed442dd0d2c1b1dddd68653fa6eec66
    Author:     Richard Yao <ryao@gentoo.org>
    AuthorDate: Wed Aug 7 08:53:45 2013 -0400
    Commit:     Brian Behlendorf <behlendorf1@llnl.gov>
    CommitDate: Thu Aug 15 16:19:07 2013 -0700

        Linux 3.11 compat: fops->iterate()
    ...
        Compatibility with older kernels was accomplished by adding
        versions of the trivial dir_emit* helper functions.
    ...
    +static inline bool
    +dir_emit(struct dir_context *ctx, const char *name, int namelen,
    +    uint64_t ino, unsigned type)
    +{
    +       return ctx->actor(ctx->dirent, name, namelen, ctx->pos, ino, type) == 0;
    +}
    +
    +static inline bool
    +dir_emit_dot(struct file *file, struct dir_context *ctx)
    +{
    +       return ctx->actor(ctx->dirent, ".", 1, ctx->pos,
    +           file->f_path.dentry->d_inode->i_ino, DT_DIR) == 0;
    +}
    +
    +static inline bool
    +dir_emit_dotdot(struct file *file, struct dir_context *ctx)
    +{
    +       return ctx->actor(ctx->dirent, "..", 2, ctx->pos,
    +           parent_ino(file->f_path.dentry), DT_DIR) == 0;
    +}
    +
    +static inline bool
    +dir_emit_dots(struct file *file, struct dir_context *ctx)
    +{
    +       if (ctx->pos == 0) {
    +               if (!dir_emit_dot(file, ctx))
    +                       return false;
    +               ctx->pos = 1;
    +       }
    +       if (ctx->pos == 1) {
    +               if (!dir_emit_dotdot(file, ctx))
    +                       return false;
    +               ctx->pos = 2;
    +       }
    +       return true;
    +}

Except that Richard Yao took care to say he felt the copying was "trivial", I don't think this example inspires much confidence that zfs.ko is not a derived work of some GPL software.

Compiling against headers is a fairly standard autotools technique for writing portable software. It avoids the mess of doing an `#ifdef` on the kernel version, which allows people to build against arbitrary git commits to Linus' tree and also kernels where things where API changes were backported. In either case, you can have different kernel headers than what your kernel version suggests.

That being said, the actual number of kernel header API checks is 63. The duplicate use of ZFS_LINUX_TRY_COMPILE occurs when the code explicitly checks each version of an interface used in different kernel versions. It is basically an if-else chain. If one does not match, another is checked. Ideally, we should explicitly check each version (rather than assuming that on failure, an older API is in use), but not all checks do that yet.

We could reduce them to 0 if we just went by kernel version, which is what just about everyone else does, but it is not as good. That being said, this inspired me to think of a way to reduce all 63 checks to 1 check based on the kernel version unless something turns out to be wrong. I put the idea into the issue tracker:

https://github.com/zfsonlinux/zfs/issues/4375

"Compiling against headers is a fairly standard autotools technique for writing portable software"

I agree entirely. But are you arguing that, in general when a program Z links to a library L to run, it is not important for the license of Z and the license of L to both permit it? A conclusion like this eviscerates all Copyleft licenses, so I am loathe to accept it.

I have harped on the close relationship between the organization of zfsonlinux's zfs.git and the linux kernel in multiple threads, because the core claim coming from Canonical is that the code in zfs.git is somehow essentially independent of the linux kernel. They do not articulate what this means or how we can determine whether it's the case in general. So far no definition I've considered seems to paint zfsonlinux in the same light that canonical have claimed.

The kernel is built with APIs for the attachment of modules---which in a user space program might be called "plug-ins"---which can be statically linked with the kernel or dynamically loaded into kernel space by a running kernel. As with any such interface in a GPLv2 program running outside kernel space, we can assume that within kernel space the overwhelming preponderance of such modules or plug-ins can be assumed to fall within the scope of the copyleft on the kernel.

I don't think I'm understanding this passage correctly. Or if I am understanding it correctly, I'm not sure I see the logic. How is this passage intended to be interpreted?

I think it's saying that if a user space program has an API that allows plugins to be written, the plugins should be considered derivative works of the main program. Thus if the main program is distributed under a standard copyright, any 3rd-party plugin is copyright infringing in the absence of specific licensing to allow it.

Is this true? If anyone would know it would be Eben, but this seems at odds with the purpose of such an API. On the other hand, "As with any such interface ... we can assume ... that the overwhelming preponderance ... can be assumed to fall within the scope of the copyleft" doesn't sound like the sort of precise legal prose Eben normally writes.

From Eben Moglen's wikipedia page:

Moglen is closely involved with the Free Software Foundation, serving as general counsel since 1994 and board member from 2000 to 2007. As counsel, Moglen was charged with enforcing the GNU General Public License (GPL) on behalf of the FSF,[4] and later became heavily involved with drafting version 3 of the GPL.

I'm comfortable calling him the leading legal scholar of the GPL.

Is SFLC Shooting Open Source in the Foot? http://info9.net/wiki/tmarble/posts/is-slfc-shooting-open-so...

How is the situation with OpenZFS and Linux any different from Minecraft Server and Bukkit? It seems that the act of distributing a combined work is what causes problems, in that Spigot or zfs.ko binaries cannot be shared but one can freely build those things by oneself. No one's DMCAed BuildTools, for instance, even though CraftBukkit and Spigot binaries have been (and probably should be).

Here's what I don't understand: Since this apparently has been an issue for quite some time for highly visible projects like OpenSolaris and ZFS - why hasn't this been accounted for in a new version of GPL? More specifically, why hasn't Torwalds spawned a Linux license he's fully on board with?

> ...why hasn't this been accounted for in a new version of GPL?

According to the article, it has been addressed in GPLv3.

.. which Torwalds AFAIK opposes, so no Linux kernel on GPLv3.

Torvalds couldn't move the kernel to GPLv3 if he wanted to. Every contribution under v2 without the "or later" clause would have to be relicensed by the contributor, first.

> why hasn't Torwalds spawned a Linux license he's fully on board with?

Changing a licence in an open source project can be difficult. Unless you've specifically had all contributors sign away their ownership of their contribution, then you can't change the licence without their permission, as they've only given permission for their contribution to be used under the current licence. When you have 1000s of contributors, the problem swiftly becomes impractical to solve.

I'm not aware of whether the linux kernel asks contributors to give up their rights in such a way, or otherwise has some provision for changing the licence terms.

I can see that. Here's why I think it could work nonetheless:

(1) Torwalds is one of the people able to drum up the OSS community. If people hated him so much as to not follow him on a technical detail, they'd develop for BSD rather than Linux.

(2) the reason GPLv3 has mostly failed seems to be mostly due to the controversial nature of the changes while the change for more compatibility with another free license seems straightforward

If standards are followed and cross platform libraries are used for functionality absent from the standards, userland software should work equally well on various platforms. An enormous amount of software available for Linux already does that.

Mozilla relicensed code from 445 contributors (from MPL-only to MPL/GPL/LGPL tri-license). It took them 5 years [1]. Consider complications like finding the relatives of a dead contributor, getting them to listen to you, then to understand the issue, then to agree. The Linux codebase is much older and has accumulated more contributors over that time, so the task is much larger, too.

1: http://blog.gerv.net/2006/03/relicensing_complete/

Torvald's has said in the past he won't ever change the license of Linux.

The GPL normally has a clause that says the source code has to be licensed under "this license or a newer version of the GPL". Projects that have moved from GPLv2 to GPLv3 did so because of this clause in the license. Torvalds specifically removed this clause.

I doubt Torvalds is concerned about whether or not users can use ZFS. He's defended the existence of closed source kernel modules (ex graphics drivers, network drivers). There's even the quote in the article that Torvald's didn't consider Andrew File System derivative of the kernel. Further, users can use ZFS-FUSE; there's no question that ZFS-FUSE doesn't infringe. Finally, Oracle owns sole copyright to ZFS; they can re-licence it.

Linux will never move from GPLv2 and I'd be really surprised if Torvalds saw the ZFS issue as a problem with the GPLv2 and not an Oracle problem.

Thanks, good answer. Is Torvalds legally correct with his defence of non-GPL kernel modules? I mean his position makes total sense to me technically, I just find it a bit strange that he wouldn't push for an OSS license that unambiguously allows for such kernel modules, s.t. everyone could shut up about this issue. I also understand though if his position is that it's just not a problem that needs to be solved (since he doesn't think that contributors would end up suing distributors about this issue).

asking to make sure that i somewhat understand. The point is that licenses can allow for literal readings or equity readings, ie. the spirit of the law. On its face, debian is fine as it makes it easy to set up zfs but is separately distributing two binaries. Canonical is distributing one binary with the zfs linked inside of the kernel, which a literal reading can allow. However the equity reading disallows as although all source code can be released, it must be under gplv2. Therefore, we are in a holding pattern to see whether stakeholders will take the literal or equity reading of the license and will proceed accordingly?

"The Linux Kernel" is a tautological pleonasm. "Free gift" "New Beginner" "true fact". Linux is a kernel. Everything else, is not Linux.

Reply on news.ycombinator.com