I find it odd he uses the term "quite obviously" twice in his post. If it was so obvious, why bother seeking legal counsel? I think he's doing Ubuntu a disservice with that kind of response. It makes it seems as though they haven't put in an appropriate amount of effort to vet this thing out.
I'm also curious as to why they'd have waited so long to include it if the legal questions were so trivial.
I imagine the wait was mostly that it wasn't deemed necessary to have ZFS on Ubuntu until now.
Containerisation has drastically increased interest in CoW filesystems. Traditionally their only use-case has been for implementing livecds and similar ro + rw layer environments.
For this AUFS has been the gold standard since basically forever. However AUFS has some flaws and lack of features that make it undesirable to use in production container workloads, hence looking to ZFS to fill this gap.
Note that AUFS has been succeeded by overlayfs which, unlike the various earlier union fs attempts, has actually been merged into the kernel. I'm not sure where it stands with regard to flaws
It's pretty flawed - for example, if you open a file read-only, open it again read-write and the write to it, any read from the first file descriptor won't show the writes. The corner cases don't bite people under most circumstances, but when they do they're awful.
its still pretty raw. check out cve-2015-8660, which basically let unprivileged users bypass normal file permissions without even trying. it's fixed in mainline now, but still hasn't hit a lot of distros.
It is always good to double check things on the off chance that you are wrong. Many of the critics of Canonical's decision cannot claim to have done that.
I believe the claims are along the lines that the core of the Nvidia blob is actually the Windows driver, which is then not a derived work of Linux. They do provide the source for the bit that adapts between the Linux kernel and their blob.
If you are being most charitable, you could consider this like NDISWrapper which doesn't make the driver used become part of the kernel from a license point of view. The least charitable is that Nvidia are circumventing / violating the kernel GPL by their stunt.
Ultimately it would likely take some lawyers, time and money to get a strong decision, which no one seems willing to do, yet.
> Who will/can/should file a lawsuit against them and on what probable cause?
A copyright holder for the linux kernel, on the grounds that they are distributing an unlicensed derivative work thereof (there would be no need to show damages, there are statutory damages; it's definitely unlicensed, the part that's not clear is whether it's a derivative work). It's not really in the EFF's wheelhouse; mjg59 (who holds at least some kernel copyrights) claimed to be talking to the software freedom law center about his options. I'm unsure why he'd regard zfs.ko as more problematic than nvidia.ko (I mean fundamentally end users have the access they need to fix bugs in the ZFS source, the CDDL is basically the same as the GPL, whereas end users cannot fix bugs in the NVidia video drivers, not in some theoretical legal sense but in actual practice), and if the legal theory is correct then it surely applies equally well to both, but he's the one with standing to sue so it's his call. IANAL.
Theoretically, nvidia.ko never comes in the same dvd / usb-stick / download as the kernel, it's always a separate piece installed by the user later (even if with a helper program). "Super Easy" derivatives of mainstream distros may include nvidia.ko (and libdvdcss etc) in the initial install, but mainstream distros including ubuntu do not. So they could say, if there was some violation of license going on, it wasn't them doing it, because they were not distributing something derived from the linux kernel. They may separately offer some "shim" code and binary under a separate license that the user then combines with the linux kernel headers on their own machine, and does not distribute the combination.
That's one of the attempted justifications anyway. So what's more "audacious" here is Ubuntu distributing zfs.ko included in the initial install, and not requiring a dkms-like setup.
There's disagreement, even among core kernel developers, about whether nvidia's binary kernel module is OK. The fact that they've gotten away with it for a long time doesn't mean that it's OK, just that it's somewhere between hard and impossible to enforce copyleft (for various reasons worth of a separate post). ref: https://lkml.org/lkml/2012/8/1/411
Then, theoretically, how about distributing the zfs-on-linux source code with the NAS and present a button in the web interface "Install ZFS" which pops up a big "this will install a non-GPL-compliant module" message which everyone just clicks "OK" on and we're done?
This is essentially what DKMS does and how Debian is shipping ZFS. I can only imagine that Ubuntu wants to make it easier that (perhaps it would be hard to have the installer support ZFS as root filesystem without having the binary ZFS module - you'd have to ship a full compiler toolchain as part of the installer?)
Just like a patent troll can hold a company hostage with a patent, can a "copyleft" troll / lawyers hold a company and users hostage with copyleft lawsuit?
If the zfs + linux kernel NAS products become wildly popular, can a lawyer + a kernel src copyright holder sent letter to NAS company + its customers and demand $500K or $1-10K per users to ask them to pay up?
An interesting question, and there is at least one storage appliance company that, to my knowledge, has previously been shipping ZFS with their Ubuntu based appliance for some time (Quantastor)
Not exactly a company on the size of WD or similar, though.
I was going to try getting a Synology with btrfs but seeing the comments in the other thread has given me pause. Maybe they will take a run at this and make things work with zfs.
My ReadyNAS has been a ROCK over the last 11(!!!) years and up until recently was still getting updates. They are a market leader anymore but damn, color me impressed with the level of commitment to updates over the years.
> 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?
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.
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.
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!).
> 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.
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).
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.
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 wher...
I wonder what a legal engineering solution looks like.
Clearly ZFS is open source, Linux would profit by including it, but both ZFS and Linux have licenses that are, at this point, impossible to change for various reasons.
It seems that the people opposing this move by Ubuntu claim that by linking against the VFS stuff in Linux, that particular ZFS distribution becomes a derivative of Linux (weak claim IMO but argiuable) and therefore must be GPL'd. But it can't be. And we (or I at least) would like to see ZFS on Linux become easier.
I wonder if some brave soul could make a new, completely superfluous layer of glue on top of ZFS that's both GPL and CDDL? And then could link that glue to linux/vfs while leaving ZFS itself in a completely underived state? Would that satisfy people?
Ultimately we're talking about open source code with nice engineering, here. I think the whole computing community could benefit from a solution.
Sidenote: I wonder how many people here who claim copyright of an API (vfs) prohibits this integration felt the exact opposite way when it was Oracle v Google.
Imagine you have a small GPL program, that all it does is to load plugins, e.g. with dlopen and invokes some function, let's call it "main".
It clearly doesn't care what license the binary loaded that way has.
What i does is to load a binary in memory, locate an address and transfer control to it. If the GPL didn't allow this kind of thing to happen, then the GPL linux kernel couldn't possibly load any proprietary program.
Now, let's allow those "plugins" to do something more interesting: request some action by the plugin host. The "main" function receives a function pointer that serves as an entry point for "system calls". Again, it's perfectly legal to invoke such a function, regardless of whether you can see this as "dynamic linking", you can also see this as "providing an operating system system call".
If you're not convinced, let's call this "plugin host" an novel operating deepcloudstrumpfkernel operating system.
Now, this is a pretty hard to use interface. You probably want a library linked to your "plugin"/"program" that provides a more natural interface on top of this basic "syscall" interface. This library and it's headers will contain functions, constants etc.
This library doesn't have to be licensed with GPL; any license compatible with your "plugin" will do. Let's make it CDDL (or MIT).
Now, it would be very useful that this library, or parts of it (e.g. constant definitions), is shared with the "plugin host" a.k.a deepcloudstrumpfkernel; No problem again, whoever owns the copyright for this library can release it with both MIT and GPL license.
You can use the same trick to implement a loadable kernel module that doesn't violate the GPL. However there is a lot of work.
In order to properly abide by the GPL rules, you must be able to build a fully working kernel module without touching any line of GPL code (except header files and library objects provided by the compiler and your OS "primary interface").
This last part is what is tricky. If you want to create a kernel module, you need to include some helpers. If linux had a stable "driver API", somebody else could write a library that helps you build a compliant kernel module, but in order to be more agile, IIRC the linux kernel module subsystem is designed to be source compatible and not binary compatible between releases and the layer exposes a lot of linux internals, which are part of the kernel and it would be very hard to duplicate all this without being caught in a copy paste.
jbooth's suggestion was to write such a dummy layer that bridges the linux VFS interface with something else; thus not requiring the kernel module to use the internal linux API. However
there is more to it than the VFS API: you also need the bare minimum to make your kernel module actually loadable by the kernel not depend on any GPL library that helps you adhere to that ABI.
Canonical's view is the view actual lawyers are taking while the ZoL FAQ's links are another theory that the project lead thought was more appropriate for explanation to non-lawyers.
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:
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.
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.
Wouldn't the same logic let you conclude that, say, CLISP under a proprietary license + readline under GPL can be distributed together, if readline is distributed as a loadable module instead of a static binary? readline is "quite obviously" not a derivative of CLISP, or vice versa.
The definition of a derivative work comes into play here. An argument has been made by Illumos who ported the KVM module from Linux that since they did not have to make any changes to Illumos to support KVM, and they only made minor modifications to allow KVM to be loaded into the Illumos kernel that it does not constitute a derived work since it in no way depends on Illumos to function and that there was no changes made to Illumos to support it. Illumos gets to stay as CDDL and KVM remains GPL.
A program that functionally requires libreadline to function is very obviously a derived work in copyright law, calling dlopen() isn't going to save you from that.
Interesting that it took so long to reach this conclusion. I thought Linux devs stayed away from ZFS mainly due to the licensing which leads me to believe it's not quite as 'obvious' as this post mentions.
Linux stayed away from including it into the shipped kernel, which is indeed a derivative work. Their argument is that kernel module loaded into kernel separately is acceptable to avoid GPL violation.
GPL defines what is supposed to be the subject to its limitations. And apparently this use case isn't part of it. So how do you define what's in spirit and what is in the letter of the law here?
> And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris
I don't see at all why that follows. Why not both? Building a kernel module requires including headers and writing glue code to conform to the kernel API, which is licensed only under the GPLv2. It strains reason to argue that a ELF binary with Linux metadata and Linux module entry points registering functions to implement a Linux filesystem is "clearly not" derivative of Linux.
So then the question is, why is "nvidia.ko"'s binary blob not a derivative of Linux? What's the logic that says one binary blob is a derivative work, and the other is not when they both are 'ELF binary with Linux metadata and Linux module entry points'.
It certainly would be interesting to see a "Software Freedom Law Center" vs "Free Software Foundation" legal battle. But if no one wants to fight over a clearly more egregious graphics blob, then why would they go after Canonical for something seemingly less of an issue.
The Linux community already had this discussion over the Andrew Filesystem, which was a proprietary port. That is partly why we have symbols designated as being okay for non-GPL code. As for using headers, few consider them to be subject to copyright and those that do would likely find a fair use case for using them for compatibility. However, complex macros and inline functions are a concern. There are not many that are quite so large that they would be considered non-trivial. So far, I have yet to see any that should pose a problem for legal review, although I have only paid attention to ones used by ZFS.
Also, if it is not clear, this was raised inside Gentoo. There was a discussion involving this with myself, the ZoL project lead, the concerned developer and a member of the licensing team who had final call on the matter. The descriptions of what was being done and why it should be okay passed review.
> As for using headers, few consider them to be subject to copyright and those that do would likely find a fair use case for using them for compatibility.
Except as it stands, Oracle have now won cases in the US courts that designate them copyrightable, have they not?
That is restricted to the US, involved whether a compatible implementation could be made using them and offered the possibility that all such implementations were actually fair use. It really is not relevant unless you are discussing making a Linux kernel replacement under a different license using the Linux kernel headers. As far as I last heard from lawyers on this, it is not considered to affect anyone until the legal battle finishes and as far as I can tell, if a oracle manages to say this is not okay, they will be in far deeper trouble over their DTrace module that circumvents GPL symbol exports than ZFSOnLinux that restricts itself to an interface intended to allow proprietary modules.
Oracle v. Google did break Oracle's way on API copyrightability, but the precedent is from the Federal Circuit (because there were also-appealed patent claims), and they wouldn't end up hearing most subsequent copyright cases... so it's all pretty murky at best.
Despite their occasional enthusiasm for overturning the Federal Circuit, the Supreme Court denied cert in the case, so this probably won't be settled any time soon.
> Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL and even proprietary (hi, nvidia.ko) kernel modules.
If your conclusion depends on asserting the obvious legality of nvidia.ko and saying that you're just doing what they are, you're in a super bad place.
That, plus at least one of the authors in question (Oracle, nee Sun) appears to have picked a license deliberately to ensure that ZFS couldn't be distributed with Linux. They were otherwise happy to dual-license with some form of GPL where it suited them; Apple dropped the thing like a hot rock too.
A read of the license text is one thing, the intent of the author is quite another...
61 comments
[ 3.7 ms ] story [ 112 ms ] threadI'm also curious as to why they'd have waited so long to include it if the legal questions were so trivial.
Containerisation has drastically increased interest in CoW filesystems. Traditionally their only use-case has been for implementing livecds and similar ro + rw layer environments.
For this AUFS has been the gold standard since basically forever. However AUFS has some flaws and lack of features that make it undesirable to use in production container workloads, hence looking to ZFS to fill this gap.
What seems obvious to the legal layperson is not always a cut-and-dry issue for the law.
If you are being most charitable, you could consider this like NDISWrapper which doesn't make the driver used become part of the kernel from a license point of view. The least charitable is that Nvidia are circumventing / violating the kernel GPL by their stunt.
Ultimately it would likely take some lawyers, time and money to get a strong decision, which no one seems willing to do, yet.
Let's say a NAS company (WD?) takes the linux + zfs and build a NAS incorporate all the zfs features.
Who will/can/should file a lawsuit against them and on what probable cause?
Would/should EFF do it? Why?
A copyright holder for the linux kernel, on the grounds that they are distributing an unlicensed derivative work thereof (there would be no need to show damages, there are statutory damages; it's definitely unlicensed, the part that's not clear is whether it's a derivative work). It's not really in the EFF's wheelhouse; mjg59 (who holds at least some kernel copyrights) claimed to be talking to the software freedom law center about his options. I'm unsure why he'd regard zfs.ko as more problematic than nvidia.ko (I mean fundamentally end users have the access they need to fix bugs in the ZFS source, the CDDL is basically the same as the GPL, whereas end users cannot fix bugs in the NVidia video drivers, not in some theoretical legal sense but in actual practice), and if the legal theory is correct then it surely applies equally well to both, but he's the one with standing to sue so it's his call. IANAL.
That's one of the attempted justifications anyway. So what's more "audacious" here is Ubuntu distributing zfs.ko included in the initial install, and not requiring a dkms-like setup.
There's disagreement, even among core kernel developers, about whether nvidia's binary kernel module is OK. The fact that they've gotten away with it for a long time doesn't mean that it's OK, just that it's somewhere between hard and impossible to enforce copyleft (for various reasons worth of a separate post). ref: https://lkml.org/lkml/2012/8/1/411
Just like a patent troll can hold a company hostage with a patent, can a "copyleft" troll / lawyers hold a company and users hostage with copyleft lawsuit?
If the zfs + linux kernel NAS products become wildly popular, can a lawyer + a kernel src copyright holder sent letter to NAS company + its customers and demand $500K or $1-10K per users to ask them to pay up?
Not exactly a company on the size of WD or similar, though.
My ReadyNAS has been a ROCK over the last 11(!!!) years and up until recently was still getting updates. They are a market leader anymore but damn, color me impressed with the level of commitment to updates over the years.
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?
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
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.
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.
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
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
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 wher...
Clearly ZFS is open source, Linux would profit by including it, but both ZFS and Linux have licenses that are, at this point, impossible to change for various reasons.
It seems that the people opposing this move by Ubuntu claim that by linking against the VFS stuff in Linux, that particular ZFS distribution becomes a derivative of Linux (weak claim IMO but argiuable) and therefore must be GPL'd. But it can't be. And we (or I at least) would like to see ZFS on Linux become easier.
I wonder if some brave soul could make a new, completely superfluous layer of glue on top of ZFS that's both GPL and CDDL? And then could link that glue to linux/vfs while leaving ZFS itself in a completely underived state? Would that satisfy people?
Ultimately we're talking about open source code with nice engineering, here. I think the whole computing community could benefit from a solution.
Sidenote: I wonder how many people here who claim copyright of an API (vfs) prohibits this integration felt the exact opposite way when it was Oracle v Google.
Imagine you have a small GPL program, that all it does is to load plugins, e.g. with dlopen and invokes some function, let's call it "main".
It clearly doesn't care what license the binary loaded that way has.
What i does is to load a binary in memory, locate an address and transfer control to it. If the GPL didn't allow this kind of thing to happen, then the GPL linux kernel couldn't possibly load any proprietary program.
Now, let's allow those "plugins" to do something more interesting: request some action by the plugin host. The "main" function receives a function pointer that serves as an entry point for "system calls". Again, it's perfectly legal to invoke such a function, regardless of whether you can see this as "dynamic linking", you can also see this as "providing an operating system system call".
If you're not convinced, let's call this "plugin host" an novel operating deepcloudstrumpfkernel operating system.
Now, this is a pretty hard to use interface. You probably want a library linked to your "plugin"/"program" that provides a more natural interface on top of this basic "syscall" interface. This library and it's headers will contain functions, constants etc.
This library doesn't have to be licensed with GPL; any license compatible with your "plugin" will do. Let's make it CDDL (or MIT).
Now, it would be very useful that this library, or parts of it (e.g. constant definitions), is shared with the "plugin host" a.k.a deepcloudstrumpfkernel; No problem again, whoever owns the copyright for this library can release it with both MIT and GPL license.
You can use the same trick to implement a loadable kernel module that doesn't violate the GPL. However there is a lot of work.
In order to properly abide by the GPL rules, you must be able to build a fully working kernel module without touching any line of GPL code (except header files and library objects provided by the compiler and your OS "primary interface").
This last part is what is tricky. If you want to create a kernel module, you need to include some helpers. If linux had a stable "driver API", somebody else could write a library that helps you build a compliant kernel module, but in order to be more agile, IIRC the linux kernel module subsystem is designed to be source compatible and not binary compatible between releases and the layer exposes a lot of linux internals, which are part of the kernel and it would be very hard to duplicate all this without being caught in a copy paste.
jbooth's suggestion was to write such a dummy layer that bridges the linux VFS interface with something else; thus not requiring the kernel module to use the internal linux API. However there is more to it than the VFS API: you also need the bare minimum to make your kernel module actually loadable by the kernel not depend on any GPL library that helps you adhere to that ABI.
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
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.
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...
A program that functionally requires libreadline to function is very obviously a derived work in copyright law, calling dlopen() isn't going to save you from that.
I don't see at all why that follows. Why not both? Building a kernel module requires including headers and writing glue code to conform to the kernel API, which is licensed only under the GPLv2. It strains reason to argue that a ELF binary with Linux metadata and Linux module entry points registering functions to implement a Linux filesystem is "clearly not" derivative of Linux.
So then the question is, why is "nvidia.ko"'s binary blob not a derivative of Linux? What's the logic that says one binary blob is a derivative work, and the other is not when they both are 'ELF binary with Linux metadata and Linux module entry points'.
Also, if it is not clear, this was raised inside Gentoo. There was a discussion involving this with myself, the ZoL project lead, the concerned developer and a member of the licensing team who had final call on the matter. The descriptions of what was being done and why it should be okay passed review.
Except as it stands, Oracle have now won cases in the US courts that designate them copyrightable, have they not?
Despite their occasional enthusiasm for overturning the Federal Circuit, the Supreme Court denied cert in the case, so this probably won't be settled any time soon.
If your conclusion depends on asserting the obvious legality of nvidia.ko and saying that you're just doing what they are, you're in a super bad place.
A read of the license text is one thing, the intent of the author is quite another...