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…
The Linux Kernel, CDDL and Related Issues
11–20 of 23 posts
Re: The Linux Kernel, CDDL and Related Issues
#12Earlier 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…
Re: The Linux Kernel, CDDL and Related Issues
#13Earlier 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.
Re: The Linux Kernel, CDDL and Related Issues
#14Re: The Linux Kernel, CDDL and Related Issues
#15Earlier 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…
Re: The Linux Kernel, CDDL and Related Issues
#16I 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
#17anything 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…
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
#18anything 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?
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
#19Moglen 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.