4 ms·

The Linux Kernel, CDDL and Related Issues

46 points by bcantrill 11y ago

jepler 11y ago
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)
- mioelnir 11y ago
  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?
  - jepler 11y ago
    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.
- ryao 11y ago
  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 https://github.com/zfsonlinux/zfs/issues/4375
  - jepler 11y ago
    "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.
m_mueller 11y ago
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?
- groovy2shoes 11y ago
  > ...why hasn't this been accounted for in a new version of GPL? According to the article, it has been addressed in GPLv3.
  - m_mueller 11y ago
    .. which Torwalds AFAIK opposes, so no Linux kernel on GPLv3.
    - dragonwriter 11y ago
      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.
- ekimekim 11y ago
  > 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.
  - m_mueller 11y ago
    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
ambulancechaser 11y ago
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?
xenophonf 11y ago
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).
nkurz 11y ago
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.
helper 11y ago
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.
mobystrip 11y ago
"The Linux Kernel" is a tautological pleonasm. "Free gift" "New Beginner" "true fact". Linux is a kernel. Everything else, is not Linux.
tmarble 11y ago
Is SFLC Shooting Open Source in the Foot? http://info9.net/wiki/tmarble/posts/is-slfc-shooting-open-source-in-the-foot/ http://info9.net/wiki/tmarble/posts/is-slfc-shooting-open-so...

46 points by bcantrill 11y ago

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)

mioelnir 11y ago
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?
- jepler 11y ago
  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.
ryao 11y ago
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 https://github.com/zfsonlinux/zfs/issues/4375
- jepler 11y ago
  "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.

m_mueller 11y ago

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?

groovy2shoes 11y ago
> ...why hasn't this been accounted for in a new version of GPL? According to the article, it has been addressed in GPLv3.
- m_mueller 11y ago
  .. which Torwalds AFAIK opposes, so no Linux kernel on GPLv3.
  - dragonwriter 11y ago
    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.
ekimekim 11y ago
> 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.
- m_mueller 11y ago
  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

ambulancechaser 11y ago

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?

xenophonf 11y ago

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

nkurz 11y ago

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.

helper 11y ago

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.

mobystrip 11y ago

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

tmarble 11y ago

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