Is there any information about why VMware thinks they are not bound by the GPL? Curious whether they have a technical justification, rather than simply being a blatant licensing violation.
My favorite example is OpenAFS. Development of the AFS kernel module started in 1983, so the code is a decade older than Linux itself. So it's hard to argue that openafs.ko is a derivative work of Linux, and since it continues to run on several kernels other than Linux (Darwin, Solaris, NT, etc.) and the Linux-specific code is just glue code to make it work, it's not really obvious that it's become a derivative work of Linux. (OpenAFS is free software under the IBM Public License, which is a GPL-incompatible free software license, and the rightsholders will not relicense. The Linux kernel infrastructure assumes that any non-GPL kernel module is proprietary, for extra amusement.)
Along the same lines is the kernel module for VMware Workstation, the desktop product that runs on Linux as well as Windows and Mac OS X. It doesn't predate Linux, so the argument is slightly less clear.
VMware's vmkernel, as I understand it, is an amalgamation of VMware's hypervisor code (that predated ESX, and originated on Workstation) plus Linux. I think it conceptually started off as a Linux server with the existing kernel module, but both have evolved quite a bit. 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).
I think that VMware's argument is that they did not start with Linux and add proprietary features to existing GPL'd code and call it proprietary; they started with their own code and linked in parts of Linux via well-defined interfaces, and they're happy to comply with the GPL for the parts that came from Linux, but they don't want to GPL the entirety of the ESXi kernel.
It's worth noting that the concept of address space isn't a legal concept, just a technical one. We generally acknowledge that it's not a GPL violation to run proprietary applications on Linux, even applications that use Linux-specific interfaces like cgroups and epoll and signalfd and all that good stuff. Is this simply because the Linux kernel copyright explicitly disclaims virality to userspace, or because there's some fundamental legal reason why userspace and kernelspace are far enough apart? Can two components in ring 0 also be "far enough apart"?
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.
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.
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?
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.
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 :)
> 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).
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."
> 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.
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.
("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.
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.
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.
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.
From the page, it seems like there's been ongoing negotiation, so I am guessing there's been a lot of stalling.
Well they could replace the component with proprietary (so there is not license to comply with), stop releasing the old version and then probably settle to pay fines or damages.
In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL.
True. I have met many people who didn't make that connection. They had this idea that if they found GPL code inside a commercial, closed source product, that it would be completely okay to start distributing this software themselves. Because in their minds, "GPL is in there, so the entire thing automatically becomes GPL licensed and everybody can distribute GPL licensed code and even charge money for it".
I had to explain to them that is doesn't work that way. And if they found such a component, all they would have found was a GPL violation which they can report and which then would be an issue between the software's developers to resolve. Which may either end in them actually releasing their entire product under GPL or simply paying a fine. Out of those options I am pretty sure most would rather pay a fine than to give up their own IP to the GPL.
Stopping will probably just be another outcome unless they can come with some kind of agreement, like a separate commercial relicensed version of the GPL (but with multiple contributors that becomes a nightmare)