6 ms·

> Our conclusion is good for Ubuntu users, good for Linux, and good for all of free and open source software I would say that your conclusion is bad for linux

by pilif 11y ago

> Our conclusion is good for Ubuntu users, good for Linux, and good for all of free and open source software I would say that your conclusion is bad for linux and bad for all of free software. Because if linking your non-gpl-licensed binary blob with the GPLed kernel is legal then linking any other non-gpl-licensed binary blobs with any other GPL binary is also legal and thus the GPL is completely worthless. Is it worth setting such a precedent over the ability to run ZFS on Linux?

FireBeyond 11y ago
Is it somehow Ubuntu's fault if these behaviors are found to be legal and not protected by the GPL?
snuxoll 11y ago
There is already precedent set for loading non-GPL blobs into GPL binaries, and the FSF even has some information on what they believe to be the line for this case [0]. Now, mind you, this specific case does fall under what the FSF believes - so we start falling into the argument of what constitutes a derived work. Linus obviously believes it is possible to create kernel modules that aren't GPL'ed, and he has allowed nvidia, amd and many other vendors to create proprietary blobs without legal issues. We also see something similar with Illumos' KVM support, where they are loading the GPL'ed KVM module into their CDDL kernel. The argument is that KVM was not developed as "part" or dependent on Illumos, only minor changes had to be made to allow it to work there instead of on Linux, as such it is not a derived work of Illumos and can be used even though the GPL and CDDL are incompatible. The same case is being made here for ZFS, the OpenZFS code has been modified to work as a Linux kernel module but it is not a derived work of Linux as it is a standalone product that someone just so happened to port. Legal precedent on this is going to be very interesting to watch if someone decides to take this case to court. http://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins http://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins
bjornsing 11y ago
I think Torvald's is a much more nuanced and reasonable approach to this issue: http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html. Also, if you feel that kernel modules should be GPL without exception then you should lobby the Linux kernel maintainers to export all symbols with the EXPORT_SYMBOL_GPL macro. As it now stands, the division of exported symbols into two classes ("normal" and "GPL only") is a strong indication that the copyright holders do believe that kernel modules are not necessarily derivative works.
- timtadh 11y ago
  That is great explanation from Linus. Thanks for linking it. He uses AFS (Andrew File System) as an example in that post which I think would be very analogous to ZFS. Linus says > Historically, there's been things like the original Andrew filesystem > module: a standard filesystem that really wasn't written for Linux in > the first place, and just implements a UNIX filesystem. Is that > derived just because it got ported to Linux that had a reasonably > similar VFS interface to what other UNIXes did? Personally, I didn't > feel that I could make that judgment call. Maybe it was, maybe it > wasn't, but it clearly is a gray area. > Personally, I think that case wasn't a derived work, and I was willing > to tell the AFS guys so. So, the ZFS case is not cut and dried either way. It would probably take a court case to clarify the matter as it is in a "gray area". To me, there seems like there is a good chance than ZFS and the Linux Kernel can be distributed as a combined work (But I Am Not A Lawyer!).
  - snuxoll 11y ago
    > To me, there seems like their is a good chance than ZFS and the Linux Kernel can be distributed as a combined work (But I Am Not A Lawyer!). This is a situation the GPL tries to prevent by explicitly using the language "combined work" - however copyright law doesn't typically have a concept of a combined work, only a derived work. It will take a court to settle this.
ithkuil 11y ago
Just some informative notes for those who are not familiar with the intricacies of GPL. I'm not detracting your point. Disclaimer: IANAL The GPLv2 license governs the distribution of software licensed with said license. It forces anyone who distributes a GPL binary to also distribute the source code used to build that binary. If in order to build that particular binary you had to include some other code, then you have to provide the sources for that code as well. Furthermore, that code you provide must be distributed in turn under the GPL license. Any such "added code" becomes part of the thing you distribute and thus constitutes "derivative work". The key thing here is that it doesn't matter if the "added code" is just some bit of extra functionality of if it's the "whole thing" while the GPL code is just one header. When you build a kernel module, you have use some GPLd headers at the very least. This last point technically taints a binary kernel module and forces you to release all the sources used to build it and release those sources as GPL. However there are two interesting points here: 1. Distribution Notice how the license only mentions distribution. You are allowed to do whatever you want with a GPL source that you hold on your hands: you can change it, add some code, link it with other code. There is absolutely nothing forcing you to immediately release your derivate work to the public and thus nothing forcing you to release the sources of your derivate work. This means, that if you build a kernel module on your machine, from a mixture of sources with GPL and an other licence; you didn't violate the GPL (whether you violated the other license, it depends on that other license). Please read very informative: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue TL;DR: ^^^ In the case of the kernel, this prevents us from distributing ZFS as part of the kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code. 2. Exemptions http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. This has a much less clear interpretation in the context of kernel modules. This clause is mainly intended to allow you to use GPL software on a proprietary operating systems as well as running proprietary software on GPL operating systems. You can compile it: which means you can include headers provided by the compiler and OS. And you can run it: which means you can invoke system calls and/or link it with possibly proprietary libraries that make up the main interface. I have no idea whether in the context of a kernel module, the kernel internal API can fall under this category, given that it's arguable that it doesn't make up the "main interface" of the linux OS. ---- How does this relate to the article from canonical ? They are claiming something entirely different. They claim that the ZFS kernel module is "evidently" not a derivate work on the grounds that it's self contained and they cite existing exemptions for other binary drivers such as those by nvidia. They don't explicitly mention the exemption on the aforementioned point in the GPLv2 license text. Thus, it's not clear how this will affect the observation of the GPL license and whether it will set a precedent at least for all cases where one can argue that the binary blob is linked against an well define interface that is meant to provide an "execution environment". (e.g. plugins, kernel modules, binaries running inside an OS). Not sure if setting this precedent will eventually erode the general case of linking though. The line is thin, but I would have preferred some more explicit reasoning instead of "we have concluded that we are acting within the rights " and "is clearly not a derivative work", and finishing with a "As we have already reached the conclusion, we are not interested in debating license compatibility".
ryao 11y ago
1. The GPL does not forbid linking. It forbids distribution of derivative works until incompatible licenses. 2. Canonical is not linking ZFS to the kernel. Doing that would mean there would be no need to load zfs.ko. 3. Under the definitions of derivative works used by every legal jurisdiction in the world, an port of a driver via a kernel module is insufficient to constitute a derivative work. This has been verified by many lawyers. 4. The GPL never provided the guarantees you seem to have thought it did. Providing them would violate clause #9 of the definition of open source software: https://opensource.org/osd-annotated https://opensource.org/osd-annotated
- convivialdingo 11y ago
  This is correct. I have sat in legal meetings over this a few times. The only murky area is how much of the original port constitutes a derivative. I would argue that any legitimate working kernel module ported from one OS to another is enough to show derivation. Others may argue that any large amount of adapting from one kernel to another (e.g. NDIS drivers) creates a new work. The truth is somewhere in the middle.
- huxley 11y ago
  re: #4 the Free Software Foundation goes to great pains to distinguish itself and free software from the Open Source Initiative and open source software, so whether the GPL violated or failed to violate a principle of open source software probably wouldn't keep Stallman up at night.

by pilif 11y ago

FireBeyond 11y ago

Is it somehow Ubuntu's fault if these behaviors are found to be legal and not protected by the GPL?

snuxoll 11y ago

There is already precedent set for loading non-GPL blobs into GPL binaries, and the FSF even has some information on what they believe to be the line for this case [0]. Now, mind you, this specific case does fall under what the FSF believes - so we start falling into the argument of what constitutes a derived work. Linus obviously believes it is possible to create kernel modules that aren't GPL'ed, and he has allowed nvidia, amd and many other vendors to create proprietary blobs without legal issues. We also see something similar with Illumos' KVM support, where they are loading the GPL'ed KVM module into their CDDL kernel. The argument is that KVM was not developed as "part" or dependent on Illumos, only minor changes had to be made to allow it to work there instead of on Linux, as such it is not a derived work of Illumos and can be used even though the GPL and CDDL are incompatible. The same case is being made here for ZFS, the OpenZFS code has been modified to work as a Linux kernel module but it is not a derived work of Linux as it is a standalone product that someone just so happened to port. Legal precedent on this is going to be very interesting to watch if someone decides to take this case to court. http://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins http://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins

bjornsing 11y ago

I think Torvald's is a much more nuanced and reasonable approach to this issue: http://yarchive.net/comp/linux/gpl_modules.html http://yarchive.net/comp/linux/gpl_modules.html. Also, if you feel that kernel modules should be GPL without exception then you should lobby the Linux kernel maintainers to export all symbols with the EXPORT_SYMBOL_GPL macro. As it now stands, the division of exported symbols into two classes ("normal" and "GPL only") is a strong indication that the copyright holders do believe that kernel modules are not necessarily derivative works.

timtadh 11y ago
That is great explanation from Linus. Thanks for linking it. He uses AFS (Andrew File System) as an example in that post which I think would be very analogous to ZFS. Linus says > Historically, there's been things like the original Andrew filesystem > module: a standard filesystem that really wasn't written for Linux in > the first place, and just implements a UNIX filesystem. Is that > derived just because it got ported to Linux that had a reasonably > similar VFS interface to what other UNIXes did? Personally, I didn't > feel that I could make that judgment call. Maybe it was, maybe it > wasn't, but it clearly is a gray area. > Personally, I think that case wasn't a derived work, and I was willing > to tell the AFS guys so. So, the ZFS case is not cut and dried either way. It would probably take a court case to clarify the matter as it is in a "gray area". To me, there seems like there is a good chance than ZFS and the Linux Kernel can be distributed as a combined work (But I Am Not A Lawyer!).
- snuxoll 11y ago
  > To me, there seems like their is a good chance than ZFS and the Linux Kernel can be distributed as a combined work (But I Am Not A Lawyer!). This is a situation the GPL tries to prevent by explicitly using the language "combined work" - however copyright law doesn't typically have a concept of a combined work, only a derived work. It will take a court to settle this.

ithkuil 11y ago

Just some informative notes for those who are not familiar with the intricacies of GPL. I'm not detracting your point. Disclaimer: IANAL The GPLv2 license governs the distribution of software licensed with said license. It forces anyone who distributes a GPL binary to also distribute the source code used to build that binary. If in order to build that particular binary you had to include some other code, then you have to provide the sources for that code as well. Furthermore, that code you provide must be distributed in turn under the GPL license. Any such "added code" becomes part of the thing you distribute and thus constitutes "derivative work". The key thing here is that it doesn't matter if the "added code" is just some bit of extra functionality of if it's the "whole thing" while the GPL code is just one header. When you build a kernel module, you have use some GPLd headers at the very least. This last point technically taints a binary kernel module and forces you to release all the sources used to build it and release those sources as GPL. However there are two interesting points here: 1. Distribution Notice how the license only mentions distribution. You are allowed to do whatever you want with a GPL source that you hold on your hands: you can change it, add some code, link it with other code. There is absolutely nothing forcing you to immediately release your derivate work to the public and thus nothing forcing you to release the sources of your derivate work. This means, that if you build a kernel module on your machine, from a mixture of sources with GPL and an other licence; you didn't violate the GPL (whether you violated the other license, it depends on that other license). Please read very informative: http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue TL;DR: ^^^ In the case of the kernel, this prevents us from distributing ZFS as part of the kernel binary. However, there is nothing in either license that prevents distributing it in the form of a binary module or in the form of source code. 2. Exemptions http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. This has a much less clear interpretation in the context of kernel modules. This clause is mainly intended to allow you to use GPL software on a proprietary operating systems as well as running proprietary software on GPL operating systems. You can compile it: which means you can include headers provided by the compiler and OS. And you can run it: which means you can invoke system calls and/or link it with possibly proprietary libraries that make up the main interface. I have no idea whether in the context of a kernel module, the kernel internal API can fall under this category, given that it's arguable that it doesn't make up the "main interface" of the linux OS. ---- How does this relate to the article from canonical ? They are claiming something entirely different. They claim that the ZFS kernel module is "evidently" not a derivate work on the grounds that it's self contained and they cite existing exemptions for other binary drivers such as those by nvidia. They don't explicitly mention the exemption on the aforementioned point in the GPLv2 license text. Thus, it's not clear how this will affect the observation of the GPL license and whether it will set a precedent at least for all cases where one can argue that the binary blob is linked against an well define interface that is meant to provide an "execution environment". (e.g. plugins, kernel modules, binaries running inside an OS). Not sure if setting this precedent will eventually erode the general case of linking though. The line is thin, but I would have preferred some more explicit reasoning instead of "we have concluded that we are acting within the rights " and "is clearly not a derivative work", and finishing with a "As we have already reached the conclusion, we are not interested in debating license compatibility".

ryao 11y ago

1. The GPL does not forbid linking. It forbids distribution of derivative works until incompatible licenses. 2. Canonical is not linking ZFS to the kernel. Doing that would mean there would be no need to load zfs.ko. 3. Under the definitions of derivative works used by every legal jurisdiction in the world, an port of a driver via a kernel module is insufficient to constitute a derivative work. This has been verified by many lawyers. 4. The GPL never provided the guarantees you seem to have thought it did. Providing them would violate clause #9 of the definition of open source software: https://opensource.org/osd-annotated https://opensource.org/osd-annotated

convivialdingo 11y ago
This is correct. I have sat in legal meetings over this a few times. The only murky area is how much of the original port constitutes a derivative. I would argue that any legitimate working kernel module ported from one OS to another is enough to show derivation. Others may argue that any large amount of adapting from one kernel to another (e.g. NDIS drivers) creates a new work. The truth is somewhere in the middle.
huxley 11y ago
re: #4 the Free Software Foundation goes to great pains to distinguish itself and free software from the Open Source Initiative and open source software, so whether the GPL violated or failed to violate a principle of open source software probably wouldn't keep Stallman up at night.