Last I joined in on the discussion I got quite convinced by the argument "if Nvidia can use a propietary license for their Linux graphics driver, then Canonical can use the CDDL for their ZFS driver". Substitute for any other propietary modules that people like to load in their Linux kernels.
Can anyone point me out why this argument is wrong? Googling around for this I was actually suprised that propietary kernel modules are in fact a debated topic (obviously to little success of the opponents), but doesn't the practical existence of propietary kernel modules at least show that no-one has had a problem with this for a long time, legally speaking?
The problem is not the use per se, the problem is delivering them to the user as one blob of software together. This is not a problem with proprietary graphics drivers, since you can just download them after setting up you system. However, if you want to boot from a ZFS disk, you need the ZFS driver and the only way to obtain it at that point is effectively from the installation medium.
OK, fair enough. So distributions that ship the Nvidia drivers in their distro install image (AFAICT OpenELEC does this, not Canonical though) should be in trouble then? And Canonical would find a way around this by autodownloading the ZFS driver when the user select the "ZFS" option in the installer?
IANAL but as far as I can tell there is no legal precedent here and so the questions you raise can only be answered by a lawsuit. Sure there is 'technically' a difference between packaging the ZFS driver with Ubuntu and audodownloading it, but it all depends on how a court sees it, because as long as there is no precedent you can't get off on a technicality like this.
Nothing really prevents the LiveUSB distribution from writing to itself under ext3, build the ZFS during installation, then use the binary compiled from this process to set it up on the actual SSDs/HDDs. This is legally essentially the same binary blob Nvidia driver as you aren't distributing the binary.
I'm assuming the reason this wasn't done was due to the convenience + you'd need to setup the USB like:
Surely that ship sailed on Android a long time ago? Proprietary drivers, shipped to the user with Linux as a single blob, is the norm. It's the biggest problem facing Linux today, much bigger than no ZFS - it kills the concept of a "distro" on the biggest class of personal computers. How does this not violate the GPL?
nvidia is using parts of the Linux API that the Linux developers have explicitly declared to not activate copyleft. They have at times asked for more non-GPL APIs, which I think has been denied:
I don't know what the situation is with ZFS with regards to the APIs that it's using.
There is also the question of how the software is being combined and distributed. If you receive ZFS and Linux as a "single work", which in SFC's view Ubuntu is doing by putting it all together in a neat little binary package, then the copyleft might activate.
If I may I'd like to share my understanding of the technical aspects which, I feel, makes the issue easier to comprehend.
It also pays to be precise and lack thereof is why so many people are confused and conflicted about the licensing.
The Canonical Kernel Team has added the 'OpenZFS on Linux' source-code [0] in the ./zfs/ directory of the Ubuntu 4.4+ kernel tree [1].
The ZFS modules are built using the OpenZFS on Linux project's stand-alone build tools.
As I understand it from reading the code and following some ZFS project developer discussions the OpenZFS on Linux code is partitioned into common parts that are largely unchanged on all the operating systems it is ported to, plus (in this case) a Linux-specific glue layer that translates the Solaris API to the Linux API in the Solaris Porting Layer (SPL). Each part is built as separate modules; there are 8:
These binary kernel objects (a.k.a. modules) are distributed in the Ubuntu linux-image-${VERSION}_${ARCH}.deb [2] according to Canonical's interpretation as an aggregate work as far as copyright is concerned.
That is, works from different projects in the same container, as in e.g. an ISO image.
As can be seen above the 'glue' layer (SPL) is under the GPL. 'zfs.ko' depends on 'spl.ko' (needs to dynamically link to it at run-time):
The modules under the CDDL contain the core OpenZFS code which is not derived in any way from Linux.
This suggests to me that any conflict between the CDDL and GPLv2 occurs in the OpenZFS on Linux port/project itself, not between the Linux kernel project GPLv2 license and the OpenZFS on Linux CDDL.
In other words, if there is a violation of the GPLv2 as Software Freedom Conservatory (SFC) claim, it occurs in the distribution of the OpenZFS on Linux binaries themselves, since that will combine both CDDL and GPLv2 binaries, even if that was distributed as a stand-alone package (e.g. OpenZFSonLinux.deb) - regardless of whether those binary modules are aggregated with the Linux kernel or not.
I'm pointing this out since most commentary I've read seems to assume that when "GPLv2" is mentioned it means the Linux kernel licence, whereas this analysis suggests the conflict is in the OpenZFS on Linux project's use of CDDL and GPLv2 if distributed in binary form.
There may be an additional viewpoint: that the code in 'spl.ko' (The Solaris Porting Layer) is a derivative of the Linux kernel code; I'm not clear if that is the case or if it would have any impact on the SFC 'binary distribution' theory.
Moving on... once installed on a target system there is a kernel image, Linux mainline dynamically loadable kernel modules, and third-party kernel modules (ZFS, DKMS-based modules, etc.):
Assuming ZFS is in use as the root file-system the ZFS modules
will be copied into the initial ramdisk by the 'update-initramfs' tool scripts:
/boot/initrd.img-${VERSION}
At boot-time the kernel will dynamically load the ZFS modules from this initial RAM disk image; This is the point where dynamic linkage actually occurs.
This is also usually the focus of arguments about GPLv2 compatibility, as in, for example, the nvidia kernel module.
In the nvidia case, rather like OpenZFS on Linux, the core code is not derived from Linux but is stand-alone and common across other operating systems (Windows, BSD). An nvidia GPLv2 API translation module is dynamically built (using DKMS) to match the kernel installed/running version(s) on the target system to the nvidia 'common core' binary blob library.
The obvious difference (setting aside the nvidia vs OpenZFS licenses) is OpenZFS on Linux API translation (SPL) is pre-built and distributed as a binary by Canonical/Ubuntu.
The problem is solely with distributing in "object code or executable form" a "work" based on a GPLv2 program without also providing the source to that work under a GPLv2 license: http://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
Practically everyone agrees that if the end user puts the GPL and CDDL pieces together (whether compiled from source or downloaded as separate binaries) that there is no legal problem. The issue is whether the conjoined pieces that Ubuntu plans to distribute constitute a single "work", for if so the GPL says that this "work" cannot be distributed with the ZFS source offered under the less restrictive CDDL.
If Ubuntu's distribution is a single "work", there isn't that much dispute that it would be considered a derivative work of the constituent pieces. So the question becomes, does a compiled kernel plus an assortment of compiled kernel modules bundled together in whatever form Ubuntu offers constitute a "work based on the Program" as defined by the GPL license?
Unfortunately, I don't think there is any clear answer possible. The technical logic of the matter is only relevant in so far as one side's lawyer can persuade one or several non-technical judges that their side has more factors in favor of their interpretation than the other side has in its. If it actually went to trial, the outcome (and possible appeals) would be a crap-shoot.
Part of your comment illustrates the confusion I was seeking - and apparently failing - to point out.
You wrote:
"The issue is whether the conjoined pieces that Ubuntu plans to distribute constitute a single "work", for if so the GPL says that this "work" cannot be distributed with the ZFS source offered under the less restrictive CDDL."
My point is that the OpenZFS on Linux project contains individual components licensed by either the CDDL or GPLv2 is where the problem lies.
As in, if I distribute binaries of the OpenZFS on Linux project to you on their own this apparent CDDL vs GPLv2 conflict arises.
In that case bundling with the Linux kernel is irrelevant to the claimed issue of license incompatibility (unless the SPL is considered a derivative work of Linux [and that implies some further license interference pattern] - but equally it could be said SPL is a derivative of Solaris).
Bundling would usually fall under the copyright aggregation definition, which in almost all jurisdictions does not cause license conflicts between the component parts of the aggregated works.
I noticed your distinction, but didn't see the relevance at first. With your clarification, I think I understand your point, although I still think this is separate from the current kerfuffle with Canonical.
Mogen and Choudhary address come close to addressing this in a footnote:
4. The phrase "derivative work" is also a term of art in US
copyright law, but is absent from most of the rest of the
world's major copyright systems. The idiosyncratic meaning
of "derivative work" in US copyright law is unrelated to
the use of the term by the kernel developers. This causes
confusion among US copyright lawyers, but the kernel
community's use of the phrase is consistent and clear
notwithstanding.
I don't know that they are correct, but I think they would assert that while a collection of kernel modules bundled as a single download could constitute a "derivative work" under US copyright law, it does not constitute a "derivative work" as defined by the GPL, and thus does not violate the license.
I think you raise a good point, though, and I don't think there is yet any case law covering this. Is it legal to distribute a tar file that contains both GPL and non-GPL files? I'd hope so, and hope that a court would agree, although I fear it would depend on which court and which lawyers are arguing it.
I was using the definition of 'derivative' from copyright.gov [0]
The most direct quote I can lift from there is:
"To be copyrightable, a derivative work must incorporate some or all of a preexisting “work” and add new original copyrightable authorship to that work.
The derivative work right is often referred to as the adaptation right"
That document also defines what I term an "aggregate" work as "Collective" works (Compilations).
Software Freedom Conservancy (SFC) claims [1]:
"In the present case, the files containing the code of the ZFS filesystem are available under free software license, but the terms offered are CDDL, not GPLv2. So although complete and corresponding source code for the GPLv2-licensed kernel binary is available under free license, some files are available only under terms of CDDL, which is inconsistent with the literal meaning of GPLv2 section 2(b)"
So if OpenZFS on Linux's spl.ko is considered a derivative work of the Linux kernel it abides by 'GPLv2 section 2(b)'.
"b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." [2]
SFC seems to be trying to extend the 'derivative' definition to the independently developed CDDL OpenZFS Solaris code in zfs.ko et al. which is ported/portable across several operating systems.
Additionally, to get ever more precise in the analysis, bearing in mind the supposed issue here is triggering GPLv2 section 2(b) incompatibility at the point of distribution of binaries by Canonical (or others):
1. If I distribute OpenZFS on Linux binaries to you on their own I'm distributing effectively 8 compiled executable files which are either CDDL or GPLv2 licensed. Is this incompatible with GPLv2 section 2(b)?
2. If I distribute those 8 OpenZFS on Linux binaries to you in the same package as another GPLv2 licensed work that is a Collective Work; is this incompatible?
3. If I distribute both Opens ZFS on Linux and Linux Kernel binaries in the same package is this a Collective or a Derivative work, and if the latter, where does the reach of the GPLv2 end?
I cannot see any sustainable argument that the CDDL code (zfs.ko et al.) could be considered a derivative work since it is independent cross-OS code originally written for and targeted at Solaris.
At this stage of analysis consider the way SFC talks about the 'kernel' as a single 'work' in terms of copyright:
"But when essentially the same code is linked into kernel space through the LKM APIs, it becomes part of one work with the kernel, and a potential conflict of license terms results."
So now the issue seems to have switched from "it is incompatible to distribute the OpenZFS on Linux and Linux kernel binaries together" to "it is incompatible to link them at run-time".
Canonical is responsible for the former but the User is responsible for the latter.
SFC also makes the argument that the Open ZFS on Linux GPLv2-ed binaries are licensed "subject to the kernel copyright holders' interpretation of those terms".
But is (as I posited previously) spl.ko a derivative work of the Linux kernel, or of OpenZFS, or Solaris, or all, or none?
As SPL contains original creative copyrightable code wouldn't the 'interpretation' of the programmers who wrote the SPL code be more controlling than that of the programmers that wrote the Linux kernel API it calls?
Furthermore, at the point of distribution those binaries do not contain Linux kernel copyright code in the 'derivative' sense, but have place-holders for linking into the Linux kernel API that will be done by an executing kernel.
It's certainly a very intriguing case study of licensing; hopefully it'll eventually help more programmers clarify their understanding.
Personally I publish all my code under the GPL, version 3 for preference, which I consider a way of encouraging 'pay-forward'. I'd be extremely annoyed (to put it mildly) if an unconnected third party was making claims that implicitly marginalised my intentions when I chose the license.
On a final (perverse yet humorous) note - this entire discussion is based on the assumption of U.S.A. copyright law and its derivative legal theory. Canonical is a U.K. company operating under E.U./U.K. law. In strict legal theory if this 'incompatibility' were taken to its maximum extent it could end up being legal to distribute OpenZFS on Linux binaries everywhere but in the U.S.A!
When it comes to the definition for 'derivative', its helpful to look at music videos as an example. They normally don't modify the song, but the video creates a adaption of the song by applying moving pictures to the music. Such adaptation requires additional copyright permission in most nations, even if someone already have permission to distribute the music unaltered.
When we talk about a kernel module in isolation, its like talking about the moving pictures in a music video without the sound. When we talk about the independently developed OpenZFS Solaris code, we are talking about specific still frames of the video. Each part is required to make the adaption that we call a music video, and each part can be a independent copyrighted work.
Copyright get interpreted by judges and juries who normally take a common sense approach to such problems. Did party X intend to create an adaptation, and if so, did they have permission to do so? I think everyone, including FSC, agree that the Solaris developers did not create an adaptation of the linux kernel. This leaves the people who created the linux module that combined the Solaris code with linux specific adaptation code, and ubuntu that distribute the combination of kernel and module. What decision a jury would decide is to me very uncertain, but one strong argument that sways me towards FSC conclusion is that judges don't like to rule based on technicalities. If something looks like a an adaptation, it is an adaptation.
Going back to the music video example, Youtube currently works by splitting videos into two parts, a video stream and a audio stream. If they argued in court that its the user that link them at run-time, I think they would loose the argument no matter how technically true it is.
Such adaptation requires additional copyright permission in most nations, even if someone already have permission to distribute the music unaltered.
It's a great comparison on a common sense basis, but could you be more specific? My impression is that in the US there still isn't any definitive "vidding" caselaw. Are you aware of some, or by "most nations" are you referring to the (primarily European) moral rights to the integrity of the work? [1]
Moral rights in EU is used to address a different problem, primarily about the association between the author and his work. For example, political advertisement would need to walk careful when using stock-photos or music repositories, since the integrity of the work could be seen as infringed on. It is normally seen as covered by defamation laws in the US, so its not part of US copyright.
What I am talking about is Synchronization rights[1]. If a musician has a deal with a publisher, they often want to be paid more if the song is played on a TV commercial then if its played on the radio or distributed on a CD. Most of this I just remember reading about years ago, but I remember that creative commons also address this concept[2]. An other example would be the agreement between NMPA and YouTube in 2011, where YouTube was granted the right to "reproduce, distribute and prepare derivative works (including synchronization rights)".
I have not memorized any specific cases where someone challenged this industry practice in court, and digging for one would take a bit more time that I have at the moment.
I see now what you are saying, although I'm not sure if the granularity of licensing affects the legality of the redistribution. But that might be because I've been thinking about it solely in the context of noncommercial areas, where "fair use" rather than licensing is the gauge. Once under "fair use", there is no special treatment of synchronization, and there even exists a specific DMCA exclusion for non-commercial video mashups: https://www.eff.org/files/2015/02/09/2014-07_eff_remix_comme...
Can anyone point me out why this argument is wrong? Googling around for this I was actually suprised that propietary kernel modules are in fact a debated topic (obviously to little success of the opponents), but doesn't the practical existence of propietary kernel modules at least show that no-one has had a problem with this for a long time, legally speaking?