[froseph]

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 community.

> 2) There is no argument that loading the vmkernel by bootstrapping it with Linux makes the vmkernel subject to GPL. In fact, in the funniest counter-example, Linux itself used to be boostrapped under MS-DOS by running the command loadlin (note the 7 character name, since DOS would not allow enough characters for load-linux).

> 3) There is no argument that distributing GPL binary drivers makes any piece of software distributed with them or using them subject to GPL. In fact the converse appears to be explicitly stated in the GPL itself.

* http://web.archive.org/web/20080105204946/http://www.venture...

updated for formatting.

[mjg59]

Points (1) and (2) aren't relevant - nobody in this case is making those arguments. Point (3) is more interesting. He makes three arguments there.

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.

[geofft]

> 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.

Yes there is: the GPLv2 says:

"If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it."

You would have to not consider the ESX product "a whole which is a work based on" the COS.

Naturally, this interpretation would extend to just about everyone who builds virtual appliances, special-purpose bootable CDs, etc. So it would be an unfortunate interpretation. (In particular, you couldn't intermingle GPLv2 and GPLv3 software on a virtual appliance!) But just because it is unfortunate does not mean it is not valid.

[btw, it's worth noting that the COS basically no longer exists.]

[snuxoll]

There is already precedent for the separation of software licenses at process boundaries, if the GPL was viral enough to cause issues with virtual appliances then Linux distributions would be in deep water already since they are a product of the combined software included on the installation media.