Hacker News Reader

Right. Part of this seems to be related to something I wrote about back in 2007 when I was an industry analyst: http://vmblog.com/archive/2007/08/22/vmware-and-the-gpl.aspx (IANAL, my opinion only, etc.)

That's a great link. That clarifies the relationship between the vmkernel and Linux.

And I think it's closer to how I think vmmon works in Workstation: you load the module, and as part of initialization, it hoists itself as owner of the CPU and stuffs the existing system in a world, creating what Xen would call "dom0". If I'm reading you right, it sounds like ESX uses "vmnix" to boot from disk and initialize hardware, and then loads vmkernel in a way that does not link with vmnix at all (unlike Linux module loading), hands over control of the processor to vmkernel, and puts itself in a world.

Two things worth noting about how the world has changed since 2007: VMware has made the shell much less extensive in ESXi (which was one of the major changes: ESX was very Red Hat-based, and ESXi's UNIX parts are just enough busybox to make things work and the shell is disabled by default), and Linux has been pushing back more on proprietary drivers using in-kernel interfaces (see, like, Nvidia and DMA-BUF).

I still think that VMware needs Linux for hardware compatibility. If it's at all legal, they'd be wasting their time implementing support for every last SCSI controller, network card, etc. on their own -- and Linux is far ahead in cases where you need reverse engineering or politicking to get support. I don't know how good the BSDs are at this sort of thing; I'm curious if they'd solve this problem well enough on server hardware.

They do. Those who builds and sells the stuff that VMware runs on has tech centers set up just to support Linux.

IBM and whatever ended up in HP probably spent hundreds of million (or more) to make sure Linux runs on anything anywhere. You don't have to spend that on writing an operating system that could run on select hardware at best, you can leverage their work and run on commodity hardware, for free.

Thanks to the reciprocity of the license they can do this with the guarantee that their competitors will do the same.

VMware did rip out the drivers from Linux and use in their own closed product, which is then guaranteed to run anything with no further work required. They argue, and this may very well be so, that since they wrote a binary shim between the Linux stuff and their own they are two separate products. They can therefore release the source of the shim only.

While that's clearly against the spirit of the licensors (which they have made abundantly clear over the years), it will be very interesting to see if it also is against the letter of the law.

> I think the remaining Linux parts mostly exist as hardware drivers, and VMware is providing the core kernel routines like scheduling and memory management and "world" management (equivalent to process management, but it's a hypervisor).

That description of vmkernel reminds me of Xen's hypervisor (dom0 handling hardware access, providing drivers but otherwise still sitting "above" the hypervisor), one technical difference I'm aware of is that Xen's hypervisor is the first piece of code loaded by the bootloader.

But does that even count as a technical difference once the system is running? Does vmkernel effectively do the same thing Xen does even though it loads dynamically via the kernel module interface after the Linux kernel boots?

I don't know much at all about how each of these common hypervisors (vmkernel, KVM, Xen, Hyper-V) interact with their "driver domain", and certainly I'm in no position to say whether any technical distinction in the way they each load or work will matter legally, but I've been interested in the vmkernel situation for a long time so I'll be watching closely.

I'm also reminded that there seem to be several proprietary versions of Xen's (otherwise GPL'd) hypervisor that bolt on closed source features, perhaps they'll end up in a similar situation as VMWare if this goes badly for them?

I don't think so. Xen is a Type 1 "bare metal" hypervisor, perhaps like ESXi, this is about a Type 2 hypervisor like Virtual Box: https://en.wikipedia.org/wiki/Hypervisor#Classification.

Proper Type 1 hypervisors run on top of the bare metal, boot first, and then in the case of Xen load a privileged virtual machine as Dom0 which has access to the bare hardware, which can be e.g. NetBSD in addition to Linux. Dom0's device drivers then provide as services raw block and network devices to the DomUs (and there can also be pass-through of devices to DomUs, something I'm not familiar with).

So the isolation is very white line, and as we engineers view it, not GPL violating. But as someone else has noted, the address space concept is not a legal one.

This case does seem to be about ESXi though.

My read of what they've been doing as their "enterprise" hypervisor evolves (it's hard for me to keep track anymore) is that they went from the old ESX bootstrapping vmkernel using Linux and a kernel module (as I was vaguely recalling in my other post), to ESXi loading vmkernel directly, and in the process of moving to this new Type-1 architecture they decided to just lump a bunch of GPL'd code from the Linux kernel in to vmkernel.

I'll be interested to see more about how this thing actually works at runtime, legal issues aside. It's quite fascinating :)

Unfortunately, it sounds like recent versions of ESXi avoid having a privileged Linux virtual machine for drivers by incorporating GPLed Linux kernel code into their proprietary hypervisor, which allows it to run Linux drivers and userland software directly. Which is why they're in deep legal hot water right now.

From the wording in the link it sounds like they include modified GPL code and don't publish that, not that they are expected to open-source ESXi (or whatever it is called right now) entirely:

> In 2011, Conservancy discovered that VMware had failed to provide nor offer any source code for the version of BusyBox included in VMware's ESXi products (as required by BusyBox's license, GPLv2).

They then say that, while they were poking around at BusyBox violations, they also realized that vmkernel is probably continuing to infringe Linux, and decided to pursue that. (I think VMware's been vaguely moving away from putting large parts of Linux in vmkernel, but may not have moved fast enough.)

From the FAQ at http://sfconservancy.org/linux-compliance/vmware-lawsuit-faq... :

"[...] admittedly, VMware made substantial and good efforts toward compliance on BusyBox. However, VMware still refused to fix a few minor and one major compliance problem that we discovered during the process. Namely, there was a major violation regarding Linux itself that ultimately became Christoph's key complaint in this lawsuit."

The FAQ implies the lawsuit is relating to the Linux kernel: http://sfconservancy.org/linux-compliance/vmware-lawsuit-faq...

> This case is specifically regarding a combined work that VMware allegedly created by combining their own code (“vmkernel”) with portions of Linux's code, which was licensed only under GPLv2. As such, this, to our knowledge, marks the first time an enforcement case is exclusively focused on this type of legal question relating to GPL. However, there are so many different ways to make combined and/or derivative works that are covered by GPL that no single case could possibly include all such issues.

The article is bit muddled in describing the nature of the charges; it seems like there are multiple GPL violations. Withholding the source to BusyBox is one of them, in addition to the violations involving the Linux kernel.

The issue is that there's linking, not merely calling from.

As for "what came first"- the license (which is a legal contract) specifies what is and isn't allowed. The LGPL would work in the way you are saying that VMWare might like it to work- where linking isn't the same as deriving. The fact that these two licenses exist demonstrates that distinction clearly.

The issue will be whether or not a judge understands these distinctions.

"Linking" isn't really a legal term either; it doesn't occur either in copyright law (of course), nor does it occur in the text of the GPLv2. It's true that in non-legally-binding prose, the FSF describes the GPLv2 as prohibiting linking with proprietary apps, but the license itself doesn't draw that line. The FSF may have intended to draw that distinction with the LGPL, but that doesn't necessarily mean that it's there in a legally-binding fashion.

("Derivative work" does occur in both copyright law and the text of the GPL contract, which is why the time argument is relevant. US copyright law specifically says, "A 'derivative work' is a work based upon one or more preexisting works." So unless you can argue that OpenAFS has become "based upon" Linux, it's not a derivative work; Linux is clearly not preexisting.)

Are you allowed to write and sell a proprietary LD_PRELOAD for a GPL'd app, that only intercepts standard POSIX functions and doesn't mess with internal symbols at all?

Are you allowed to distribute that library, the app, and a wrapper script? Are they "reasonably considered independent and separate works in themselves", or distribution "as part of a whole" (GPLv2 sect. 2)?

On the flip side, if you sell a virtual appliance that includes the GNU userspace (GPL) and some proprietary binaries, is that considered distribution "as part of a whole" (the appliance), and are you obligated to make your code available under the GPL? Even though there's no linking involved, it's not clear to me whether your code can be "reasonably considered independent and separate" if it's only distributed as part of the appliance.

I think that informed people in good faith can come to different conclusions about what they "reasonably consider" independent and separate. This isn't as obvious as, say, copying-and-pasting glibc's implementation of DNS resolution into your proprietary libc.

> On the flip side, if you sell a virtual appliance that includes the GNU userspace (GPL) and some proprietary binaries, is that considered distribution "as part of a whole" (the appliance), and are you obligated to make your code available under the GPL? Even though there's no linking involved, it's not clear to me whether your code can be "reasonably considered independent and separate" if it's only distributed as part of the appliance.

There is already legal precedent separating software licenses at process boundaries. This is why every piece of software in a Linux distribution doesn't need to be GPL'ed.

"Linking" and "calling" are also technical concepts, not legal. The GPL and LGPL claim a distinction, but that claim may not have teeth in all cases (as I understand it as a non-lawyer who has worked with FOSS for more than half my existence).

To continue the OpenAFS example though, while OpenAFS.ko itself considered as a standalone item might well be not a derivative work, that doesn't mean that you if distributed a work comprising the Linux kernel combined with OpenAFS that that combined work might not be a derivative (of both the Linux kernel and OpenAFS).

In the same way that if I took some pictures I drew back in 1960 and used them to illustrate a copy of Harry Potter, I've created a work that's a derivative of both my original picture collection and Rowling's work.

> VMware is providing the core kernel routines like scheduling and memory management

According to the LWN article someone linked[1], they're actually using modified versions of the Linux scheduling code in their hypervisor, along with the Linux implementations of fundamental data structures like radix trees. They're probably in deep trouble.

[1] https://lwn.net/SubscriberLink/635290/e501ce0264c182f4/