4 ms·
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
by 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 agoSo, 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 agoNot 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 agoCompiling 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.