Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux Kernel, CDDL and Related Issues

softwarefreedom.org

Post reply on HN
Print view View original

1–10 of 23 posts

Re: The Linux Kernel, CDDL and Related Issues

#2

Post by 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)

Re: The Linux Kernel, CDDL and Related Issues

#3

Post by mioelnir »

jepler wrote: 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?

Re: The Linux Kernel, CDDL and Related Issues

#4

Post by 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?

Re: The Linux Kernel, CDDL and Related Issues

#5

Post by groovy2shoes »

m_mueller wrote: post #4

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?

> ...why hasn't this been accounted for in a new version of GPL?

According to the article, it has been addressed in GPLv3.

Re: The Linux Kernel, CDDL and Related Issues

#6

Post by ekimekim »

m_mueller wrote: post #4

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?

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

Re: The Linux Kernel, CDDL and Related Issues

#7

Post by ryao »

jepler wrote: 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 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

Re: The Linux Kernel, CDDL and Related Issues

#8

Post by 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?

Re: The Linux Kernel, CDDL and Related Issues

#9

Post by m_mueller »

groovy2shoes wrote: post #5
m_mueller wrote: post #4

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?

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

#10

Post by m_mueller »

ekimekim wrote: post #6
m_mueller wrote: post #4

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?

> 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 seems straightforward

Post reply on HN