Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

LWN has a very clear explanation of just how clear-cut this is: https://lwn.net/SubscriberLink/635290/e501ce0264c182f4/

In particular, this isn't just a question of whether a kernel module is a derived work of the kernel. Apparently VMWare has copied code from the Linux kernel, with GPLed headers on top, and compiled that code directly into some of their code.

View on HN

I don't think it is as clear cut at all, but that makes it much more interesting. I left a comment there, but it bears some repeating I think

ESXi's kernel does not bootstrap itself from Linux at all.

There is no linux kernel as such [1]

ESXi does reuse linux kernel drivers ... a lot of them. But the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. What you are seeing in the code above is the mapping between various Linux API's and these calls to the vmkernel.

I have no idea about the complaint. VMware's position is probably that anyone can go and write anything they want against the vmkernel's vmkapi interface. Indeed some vendors ship drivers written espeically for this API.

VMware have chosen to write a linux<->vmkapi interface, which then allows them to re-use many linux drivers. All of the linux<->vmkapi interface is released, along with the drivers and any modifications and this is considered sufficient. My guess is that the software conservatories position is that it is not.

Note exactly the other thing happens on the "other" side -- between user-land and the vmkernel. ESXi uses glibc ... but of course that interfaces to vmkernel via standard system calls. Maybe that's part of it too, I don't know.

So this may be a fight over API boundaries and where the GPL starts and stops. That's quite interesting...

[1] There was with the ESX product, which shipped a version of Red Hat. That hasn't been around for ages

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.

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.

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.

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.

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

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

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.

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

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.

Aside, shouldn't you be parsimonious with subscriber links for LWN and not post them publicly? I haven't had a LWN subscription in a while, but I really like their business model. I would not have posted this link myself.

No, the subscriber links are for exactly this kind of situation. They are to allow you to link to articles when it's relevant to a discussion, as long as you don't abuse them by doing something like posting a regular feed of all LWN articles or submitting every single one to Reddit/HN.

Jonathan Corbet, editor of LWN, frequently posts his own subscriber links to LWN articles:

https://news.ycombinator.com/submitted?id=corbet

And has explicitly endorsed posting occasional links to HN:

https://news.ycombinator.com/item?id=5688938

Ah, I thought that might be the case. I wasn't sure. Thanks!

Thanks for this comment. I have often wondered about this, and I'm really glad to discover that it's above board.

Reasonable question (and I don't think you should be downvoted for it), but no, LWN editors (including Jonathan Corbet) have explicitly said that they're very happy to see LWN subscriber links posted to social networking sites and discussion sites. The main thing they don't want to see is someone systematically posting links for every single subscriber-only article.

It sounded to me like they have two things: one that's proprietary and the other that has modified kernel code in it.

Interesting. My reading is that there are two components. The first is the Linux bootstrap, which they are entirely in compliance for. The second is vmkernel, which includes some GPL code whose source they're releasing, but vmkernel as a whole is not GPL; this is almost certainly out of compliance (but also easily fixable), unless they're doing something to isolate "vmkdrivers" from the rest of vmkernel.

(Can I legally port, say, the GPLv2 ext4 filesystem driver from Linux to a non-GPL OS like OS X? Can Apple pick up that port, and distribute ext4.kext and its source in OS X, without putting the entire xnu kernel under GPLv2?)

The harder and fuzzier part is that the ESX boot process works by asking Linux to "load" vmkernel, using the vmklinux helper module. If this is in the sense of loading a kernel module, it's (mostly) clearly wrong. If this is in the sense of loading a userspace app (as if vmklinux was a binfmt module, and vmkernel was a non-ELF executable), then this is (mostly) clearly okay. But it's doing neither of those. It's loading vmkernel above Linux, making the Linux process the first world, analogous to a Xen domU. So this isn't userspace, but it's also arguably a new address space. Neither of which are legal concepts per se, so it's hard to tell where this lies.

This fuzzy part is neither the first component (Linux / "vmnix" / the bootstrap) nor the second (vmkernel), but the way in which they interact and are designed around each other. This itself might be an infringement, even if the first is not infringing, and the second is fixed.

vmnix aka Service Console aka Console OS aka the Fuzzy part, was part of ESX, which was discontinued with the 5.0 series of ESX products.

They still use it for bootstrapping, right? I know they've gotten rid of the Red Hat-ish userspace, but according to the LWN article, there's still a Linux kernel involved and a kernel module used to pass control to vmkernel.

(Is the word "vmnix" wrong? Does it apply only to the entire Red Hat-ish distribution in the COS, and not to the Linux stepping stone alone?)

Nope, that stuff is all gone with the ESXi product. The vmkernel can bootstrap itself now.

Basically the old 1.0 - 4.0 process for _ESX_ was like this:

* Bootloader

* Linux Kernel boot

* Load VMnix module.

* Load VMkernel

* hardware control passed to VMkernel

* Linux continues running as a sort of 'super' VM with some limited hardware access.

For _ESXi_ from 4.0 - now :

* Bootloader

* VMkernel

What's curious is that VMkernel's "personality" for ESXi userworlds (which are analogous to sessions IIRC) is it implements the x64 Linux ABI, with some signal/syscalls masked.

I don't know if this was to make the transition for stuff like vpxa from ESX 4 on easier internally, or to make it easier for 3rd parties to develop against, or both.

Is it lazily wrapping some functionality that should be open sourced that fills in where the service console would normally be? Probably not, but I can see why people would be a little suspicious.

To answer the 2nd part of the question:

vmnix was the name of the Linux kernel module that was loaded during the Service Console's boot process.

The terms "Service Console", "Console OS (COS)" were at times used interchangeably and referred to the Redhat distro you logged into at the terminal.

VSphere 4.0 had 2 versions: ESX (with COS) and ESXi (without COS). In 5.0 the COS was removed entirely.

Reply on news.ycombinator.com