
The Linux Kernel, CDDL and Related Issues - bcantrill
https://softwarefreedom.org/resources/2016/linux-kernel-cddl.html
======
jepler

        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)

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

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

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

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

------
m_mueller
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?

~~~
ekimekim
> 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
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

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

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

------
ambulancechaser
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?

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

