I worked at VMware for over 11 years and was one of the first dozen or so people on the vmkernel team (which produced ESX and later ESXi), although I left several years ago.

If I recall correctly, the source tarball was created from a simple script which pulled in a bunch of open source files which were stuck into their own separate branch in the source repository.

To my knowledge, there wasn't any linux source in the vmkernel. We did use plenty of open source code, such as busybox, but my understanding was it was always in user space and the source was always published.

It's possible that Christoph's code was just pulled in and published with a bunch of other crap that wasn't actually in the product, but someone had checked it into the open source part of the source tree.

From reading the linked article, it read to me like the complaint asserts that VMKernel itself is a violation of the GPL. If I'm wrong, please feel free to correct me, but these statements seems to point in this direction

    Conservancy discovered that VMware had failed 
    to provide nor offer any source code for the 
    version of BusyBox included in VMware's ESXi products

    But ESXi is not a purely open-source product;
    it also contains a proprietary component called
    "vmkernel."

    VMware's developers appear to have taken a 
    substantial amount of kernel code, adapted 
    it heavily, and built it directly into 
    vmkernel itself

    

If so, that would be like me finding some code on Github, changing it a little, and then including it in my own closed source application, clearly a violation of the GPL.

Obviously though, I'm not sure how to prove that without the source of VMKernel

Again, this is honestly just how I'm reading it, if I'm wrong feel free to correct it.

> clearly a violation of the GPL.

It’s not clear, this really is an interesting case. From the description in the comments here, it seems that the GPL code from Linux, together with the code to interface with vmkernel is published, complying with GPL for that part.

My guess is that VMware considers vmkernel to be the operating system (which it is, albeit a minimalistic one, just the barebones hypervisor) and regard it as GPL code from Linux linking with the glue layer and the vmkernel system library. Which, if it provides some generic interface that the glue uses, arguably is.

And that - GPL code linking with proprietary system library - is an explicitly permitted exception in GPL: http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryExcept...

I am just guessing here, but seen like this, VMware’s position makes sense. I would be surprised if they all-out violated GPL, Linksys-style, to be honest, because some competent FLOSS folks work(ed) there.

This sounds more like Oracle vs Google regarding Java, where VMWare, like Google, is stating that APIs are not copyrightable, and the SFC, like Oracle, is claiming that even those APIs are copyrightable.

There is a huge difference: in this case the Vmware product does include linux kernel code. So there's definitely some reproduction and distribution of copyrighted parts even excluding the use of APIs.

I don't see the commonalities except that both are about copyright. Has there been any information that the kernel API is being claimed to be copyrighted, or header files, or are VMWare claiming that no copyrighted code has actually been distributed?

The above extract mention "substantial amount of kernel code". If that code is implemented algorithms, data structure or full kernel features, then this case has nothing in common with the core issue between Oracle and Google.

FYI - BusyBox is just a regular application that a kernel would run. It's not part of the kernel itself.

To be clear, I didn't make the above statements regarding BusyBox, they were made by the claimant, and the author of the linked article.

FYI - The complaint is regarding the VMWare ESXi kernel.

Thank you, that makes a lot of sense. I can see now how VMware can believe in good faith that they're in compliance (and in fact did a fairly major move towards compliance with ESXi) and Conservancy can believe in good faith that they're not.

"ut the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. "

From my understanding, the problem is that vmkernel directly includes linux kernel GPL code, but they do not open source it.

If that's the case, this is 100% clear cut.

IE they aren't obeying their own interface, and have shoved GPL code in the wrong side of it.

Re: [1] There's an argument that ESXi was released to handle these concerns, which predate ESXi's release. I ran venturecake which first published the story, showing how the Linux kernel started vmkernel, not the other way around. Proprietary kernel modules are considered derived works unless they can run independently (eg, nvidia.ko isn't generally considered to be a derived work because it's largely code ported from other platforms). However retrospectively making something portable doesn't change it's previous status as a derived work, and ESXi wouldn't be popular without ESX, which wouldn't exist without Linux booting vmware (despite vmware's protestation otherwise - load ESX and watch the boot process).

I dunno, a bootloader seems like the most clear-cut example of something not being a derived work you could get - it doesn't care about the code being bootloeaded and vice-versa, and the API between the two is about as trivial as it can get. What matters according to the GPL isn't whether the code runs on other platforms but how deeply intertwined it is with the kernel; for most Linux drivers, whether it runs on other platforms is a good rule of thumb for determining this, but it kind of breaks down for ESX.

Also, "retrospectively making something portable doesn't change it's previous status as a derived work" was if I'm not mistaken SCO's argument for why it should be illegal for customers to run software they'd developed on SCO Unix under Linux. It's not something we should be supporting because it'd a really dangerous tool for locking users into a particular OS. (Fortunately, SCO lost.)

There is no boot loader. This is the Linux kernel module interface. The boot loader used on ESX was an actual boot loader, IIRC grub.

Arguing kernel modules are derived works from the kernel is very very different from arguing user space software is derived from an OS.

> nvidia.ko isn't generally considered to be a derived work

That's far from clear. Many core developers (including Torvalds, IIRC, but correct me if I'm wrong) are on the record that they consider Nvidia to violate the spirit and/or the letter of the GPL there. It's just that nobody cares enough to litigate.

That sounds an awful lot like embrace, extend, and extinguish in my woefully uneducated opinion.