I very much doubt the accuracy of their claims that vmkernel is largely a copy of linux ( http://sfconservancy.org/linux-compliance/linux-vs-vmkernel_... ) Mostly since in many of those drivers, it performs better than linux, but also because vmware did not hire idiots, (and non-idiots know not to ever use GPL code). Source: worked there a while ago.
The wayback machine* has Zachary Amsden's opinion in 2007 why the vmkernel (and other components) are not in violation of GPL. It's an interesting read. He concludes: > 1) There is no argument that depending on a Linux console OS makes any part of ESX subject to GPL that is not already opene sourced. We have open sourced those GPL components of the system which we have modified and given the changes back to the commu…
1) The GPL doesn't cover execution, only distribution
True, and as such an end user loading a proprietary kernel driver into a GPLed kernel (or vice versa) isn't infringing. But things get more complicated when you're distributing a product that consists of GPLed and proprietary code and requires both of them to be useful. If vmkernel is basically useless without vmklinux, there's a reasonable argument that the distributed product is a derived work of both vmkernel and vmklinux.
(The same argument doesn't apply to a product using proprietary applications on top of the Linux kernel - there's an explicit statement in the Linux copyright file that using the standard userspace interfaces doesn't create a derived work)
2) There's a copyright boundary between Linux and kernel modules
Quoting from his comment:
"Linux has established a well defined, binary interface through which driver modules and the kernel may interact, with well defined copyright separation."
This is, well, nonsense. Calling the Linux kernel ABI well-defined is entirely untrue - it changes rapidly between releases, it changes within releases (there's no guarantee that an LTS kernel will keep the same ABI between minor point releases) and even Red Hat, who expend a huge amount of effort on maintaining a stable kernel ABI, only make their kABI guarantees for a small subset of the actual kernel ABI.
3) Nobody complaining about this has any standing
"those vocal advocates such as Christoph, who are so offended by this, do not even own any copyright on the code we are distributing"
I'll be charitable and chalk this up to being misinformed rather than an outright lie.
There is certainly an argument that distributing GPL drivers and a shim layer to load them into a proprietary kernel may (depending on a whole host of things) create a derived work, and thus subject to the GPL.
Zach pointed out that he's not a lawyer and that he wasn't making an official response, but VMware's only real defences are likely to be along those lines. I personally think they'll have a hard time convincing a judge of that, but we'll see how it goes.