Updated to add: I'm reading through the FAQ now, but I still don't understand why VMware is taking the stance they are.
VMware publishes source of the modified drivers and the source for the adapter layer that translates Linux kernel functions to vmkernel functions, but not the source of the vmkernel. Their historical claim was that the vmkernel was a binary-only kernel module loaded into the service console's Linux kernel. I always found this argument a bit sketchy.
With ESXi, the "user-world" support in the vmkernel was used to move all the processes running in the service console to run directly by the vmkernel, avoiding the need for the service console, and the service console's Linux kernel. Obviously this invalidates their old "vmkernel is binary-only kernel module" argument, and as far as I know, no new argument was made.
This is the crux of the issue that is being disputed. There is no "segregation" in Linux. A kernel module is a derived work of the kernel, and thus users are entitled to receive the source code for the entire work under the GPL version 2. VMWare cannot add in proprietary features.
I'm going to make that assumption in the following. Note that if a work is not a derived work of the kernel, then it doesn't matter what GPLv2 says about it because you would not need permission of the kernel copyright holders to distribute the work. We only reach the question of what is a GPLv2 "derived work" once we determine that a work is a derivative work.
Modules do not appear to inherently be derivative works of the kernel. Looking at the source code to various simple modules, I don't see anything in the minimal necessary code that is copied from the kernel other than the names of kernel header files and the names of some functions. It would be hard to argue that file names and function names are copyrightable, so I don't see any copyrightable kernel elements necessarily copied into simple modules.
So, if I were to write a module and release it in source form only, it sure looks like I could do this in a way that would make it not a derivative work of the kernel, and so I would have no obligation to license it under GPLv2.
If I were to do that, other people might have trouble using the module, for to use it they would have to compile it and combine it with a kernel. If that violates GPLv2, then they would be the ones liable for this, not me the module author.
Could I be held responsible for their violation? There are a couple of ways in the US (not sure about other countries) whereby one can be held accountable for the copyright violation of another. The first is if that other is acting as an agent under one's control. That would not be applicable here.
The second, contributory infringement, is when one person does something to knowingly enable someone else's infringement. For there to be contributory infringement, there are a couple of important requirements. First, there must be a direct infringement for the contributory infringer to contribute to. Second, my contribution has to be mostly only useful for infringing.
I think contributory infringement is unlikely. The person who compiles and loads my module would have a very strong fair use defense against claims that they are infringing GPLv2 by combining my module and a kernel for their own use. (Also, GPLv2 kind of implies that you can do whatever you want with GPLv2 code on your own system in private, only having to obey GPL if you are going to distribute).
It gets more interesting if I compile the module and release the binary. Macros in the source code may be expanded by the compilation process into code copied from kernel header files, or from the compiler. That could make the binary module a derivative work even though the module source code is not. This would depend on just what the macros expand to.
It would be an interesting technical and legal project, although it would probably tick off a lot of people, to approach Linux modules that same way people approach third-party kernel modules for proprietary operating systems when the copyright holder doesn't approve: clean room reverse engineering.
If the big proprietary operating system vendors, with their big legal teams and budgets and financial interest in keeping control over who runs what on their platforms, were unable to keep third parties from producing unauthorized kernel modules, I don't see why anyone would expect that Linux could do so.
The problem of viewing modules as separate work from the kernel us that the module is non-functioning without the kernel.
Lets say I took a painting (Mona Lisa) and cut it into two parts. Is that two works, or two parts of a single work? what legal test could you use? what would a non-technical group of random citizen think?
If the module had a common interface with other kernels like bsd, osx and windows, then it would be much clearer that the module is a separate work from the linux kernel. ZFS, not including the kernel compatibility code, would be such example. A module designed only for linux however is a harder argument.
It should be noted, however, that this is merely the FSF's opinion, and this has never been definitively legally established.
The GPLv3 was designed to, inter alia, eliminate such ambiguities, but added so much complexity it never really caught on outside the GNU project.
I hear this argument a lot. It is certainly intended to be the case as it's the whole point of the GPL. VMWare is, at the very least, in clear violation of the spirit of the GPL. If it's not the case, as ruled by German courts, then the GPLv2 is useless and free software will be in deep trouble. In the US the courts have found that GPLv2 is pretty clear on this (and judges don't like those that try to find loopholes) with successful compliance cases like the Linksys WRT54G router firmware.
>this is merely the FSF's opinion
It's a pretty important opinion since they wrote it and know what the intent of the legalese was.
It's easy enough to claim that a kernel module is more analogous to a program running on an OS than to a library linked into a program.
The intent of a license is defined by the person offering the license, not the person writing the license that they choose to offer.
I think I remember SCO trying your argument at some point (as they were wont to do), and if so it obviously didn't work. The law generally doesn't support being offended on behalf of someone else. What aspect do you think is specious?
If you have been injured in some other way, you are welcome to try to sue for that instead.
Actually, I think GPLv3 did something even stranger, at least something I didn't expect. I've now seen numerous entities use the GPLv3 as a mechanism to deny Companies access to that software unless they purchase a copy that is under a proprietary license. This is because some company legal departments see the GPLv3 as inherently dangerous to use. So the "Open Source" entity uses the GPLv3 to get in the door, and then offers a proprietary license that the code is sold under as an alternative to the GPLv3 for corporate use.
I'm still torn on if I like this model of dual-licensing or not. It definitely gives Open Source companies an ability to earn money from Corporations that want to keep their code closed.
But anyways, how does that deny companies access any more than simply using a proprietary license in the first place? You're already denied access to 99.9% of code written because it isn't publicly licensed at all.
The denial is not from the GPL it's from the corporate legal team. This is a big reason why the Apache 2.0 and MIT licenses are much more popular among tech companies with private codebases (in addition to the Open Source code that they release).
VMware has segregated their proprietary "stuff", namely the hypervisor monitor, from the variant of the Linux kernel that runs a bunch of hardware drivers. This segregation doesn't involve a separate address space, and does not (I think) use the official Linux userspace ABI that is documented as one border of where the GPL ends. So, on the surface, the default assumption should be that it violates the GPL.
But it seems like it would be conceptually straightforward to use something like Xen's driver domains (http://wiki.xen.org/wiki/Driver_Domain) to run Linux in a separate virtual address space and pass through all the hardware to it. There might be technical complexity, but it's doable; VMware already has a product (Workstation) which takes a normal, running Linux machine, loads some GPL'd kernel modules written by VMware, and inserts the VMware hypervisor above the current kernel. ESXi could, in theory, do the same thing.
If the result of the lawsuit were to force ESXi to make that architectural change, would that really be a win for free software? And if that architectural change is doable, and results in no benefit to Hellwig (maybe just some annoyance on the part of VMware's developers), what legally-actionable damage is being done by Hellwig's code being used the way it currently is?