Live data from Hacker News

The Linux Kernel, CDDL and Related Issues

softwarefreedom.org

11–20 of 23 posts

Re: The Linux Kernel, CDDL and Related Issues

#11
post #6

Earlier quoted context omitted.

> 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 contributor…

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 seem…

[deleted]

Re: The Linux Kernel, CDDL and Related Issues

#12
post #6

Earlier quoted context omitted.

> 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 contributor…

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 seem…

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.

Re: The Linux Kernel, CDDL and Related Issues

#13

Earlier quoted context omitted.

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

Re: The Linux Kernel, CDDL and Related Issues

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

Re: The Linux Kernel, CDDL and Related Issues

#15
post #6

Earlier quoted context omitted.

> 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 contributor…

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 seem…

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/

Re: The Linux Kernel, CDDL and Related Issues

#16
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.

Re: The Linux Kernel, CDDL and Related Issues

#17
post #7
post #2

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 yo…

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 actua…

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

Re: The Linux Kernel, CDDL and Related Issues

#18
post #3
post #2

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 yo…

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 
    AuthorDate: Wed May 15 20:23:06 2013 -0400
    Commit:     Al Viro 
    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 
    ...
    +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 
    AuthorDate: Wed Aug 7 08:53:45 2013 -0400
    Commit:     Brian Behlendorf 
    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.

Re: The Linux Kernel, CDDL and Related Issues

#19
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.

Post reply on HN