VMware: A "significant portion" of our technology may include open source

VMware has been publicly chastised for allegedly violating the GPL in its proprietary vmkernel technology. Now, in VMware's most recent quarterly report, the company calls out widespread use of open-source software in its products.

It is customary for public companies to overstate risks to their businesses in an effort to forestall shareholder lawsuits. Better safe than sorry, seems to be the thinking.

Even so, I find it fascinating to see the extent of VMware's admission to using open-source software in its products, especially in light of the criticism noted above. Here is the relevant section of VMware's 10-Q in its (near-) entirety:

Our use of "open source" software could negatively affect our ability to sell our products and subject us to possible litigation.

A significant portion of the products or technologies acquired, licensed or developed by us may incorporate so-called "open source" software, and we may incorporate open source software into other products in the future....We monitor our use of open source software in an effort to avoid subjecting our products to conditions we do not intend.

Although we believe that we have complied with our obligations under the various applicable licenses for open source software that we use such that we have not triggered any such conditions, there is little or no legal precedent governing the interpretation of many of the terms of certain of these licenses, and therefore the potential impact of these terms on our business is somewhat unknown and may result in unanticipated obligations regarding our products and technologies.

For example, we may be subjected to certain conditions, including requirements that we offer our products that use the open source software for no cost [Asay note: VMware legal team: Time to brush up on your understanding of open-source licensing - this is blatantly false], that we make available source code for modifications or derivative works we create based upon, incorporating or using the open source software and/or that we license such modifications or derivative works under the terms of the particular open source license.

If an author or other third party that distributes such open source software were to allege that we had not complied with the conditions of one or more of these licenses, we could be required to incur significant legal expenses defending against such allegations. [Asay note: Or you could simply contribute the code as per the license rather than fighting it out in court.]

If our defenses were not successful, we could be subject to significant damages, enjoined from the distribution of our products that contained the open source software and required to comply with the foregoing conditions, which could disrupt the distribution and sale of some of our products.

In addition, if we combine our proprietary software with open source software in a certain manner, under some open source licenses we could be required to release the source code of our proprietary software, which could substantially help our competitors develop products that are similar to or better than ours.

In addition to risks related to license requirements, usage of open source software can lead to greater risks than use of third party commercial software, as open source licensors generally do not provide warranties or assurance of title or controls on origin of the software.

We have established processes to help alleviate these risks, including a review process for screening requests from our development organizations for the use of open source, but we cannot be sure that all open source software is submitted for approval prior to use in our products. In addition, many of the risks associated with usage of open source, such as the lack of warranties or assurances of title, cannot be eliminated, and could, if not properly addressed, negatively affect our business. [Asay note: Additional paragraph breaks added to make it easier to read.]

VMware seems to be dancing around the elephant in the room: its controversial use of Linux in its proprietary hypervisor technology. It's interesting that the company, which has refused to comment publicly on these specific allegations, is content to serve up a blanket advisory in its 10-Q.

If I were a VMware shareholder, I'd want clarity. The company suggests that it's complying with all open-source licenses, to the best of its knowledge. If this is true, it's perhaps time for the company to put those claims to a public sniff test.

The developer community hasn't been amused by VMware's use of embedded Linux in its hypervisor technology. Why not call out specifically why VMware feels it is in compliance with the GPL?

[mbenedict]

First of all, Mike McCana's criticism of vmware on that VentureCake blog you cite is more than a year old, and since then we the public have a better understanding of the vmkernel architecture. From what we know now, most would conclude that Mike's criticism was probably off-base.

The bulk of Mike's criticism was based on the (highly dubious) claim that if you need Linux to boot-load your code, then your code is derived.

Suppose I write my own "fooKernel" from scratch, which has nothing to do with Linux, sharing exactly zero lines of code with it. Instead of using a small bootloader, I merely use Linux to bootstrap fooKernel and load it into memory. Suddenly fooKernel is "derived" from Linux? No. It is a completely separate piece of code, written from scratch. I could have chosen FreeBSD as my bootloader, for example, and the bulk of "fooKernel" would remain the same. The fact that at this time only Linux can load my kernel is irrelevant.

Mike's other claim is if a piece of code needs "special hooks" into Linux then it is derived, based on a quote from Linus that he misunderstands. What Linus was talking about is a situation where Linux is running as the "main kernel" (his words) -- in charge of the hardware -- and a proprietary binary module requiring special hooks is running "on top" of Linux.

But we know that's not how vmkernel works. Once it is loaded, then the vmkernel -- not Linux -- is in charge of the hardware. It does NOT run "on top" of Linux. In fact quite the opposite: the vmkernel loads a Linux Console OS as a privileged guest, so Linux is actually running "on top" of the vmkernel, not the other way around.

Lastly, one can indeed run ESX without a Linux console at all, so again the claim that the vmkernel is "derived" seems highly dubious.

[mrsteveman1]

In the past, VMware has said publicly that they do in fact use drivers derived from GPL kernel drivers to support some hardware.

They have documentation available about this stuff but it only leads to more questions. Does (or did) the Linux kernel completely go away after VMkernel loads? That is in fact how it worked in the past, the Linux kernel and its drivers were loaded first. They say this is not the case anymore.

[mrsteveman1]

For the purposes of this discussion I don't care what newer versions of ESX do or how they work (though i DO NOT believe new versions are significantly different, even ESX3, perhaps even ESXi), I'm interested in how the controversial versions work, and the truth, because it has been ignored and obfuscated for too long.

A lot of the comments on that venturcake site (including the one by the VMware guy) completely dance around the issue of architecture, perhaps intentionally. There are only so many ways to run code on an x86 system, and there are only so many ways for a Linux kernel to run alongside another piece of code. VMware has claimed all along that it wasn't just a Linux system running an app on top, so they could make it sound super special compared to GSX/vmware server. So either they are wrong, or they are violating the GPL as I see it. Either vmkernel is in userspace, or it's in the same address space as the Linux kernel at the same time as the linux kernel, making them linked together and making vmkernel derived.

There is a chart from VMware on the venturecake site that all the comments seem to ignore. The VMkernel is shown running completely disconnected from the hardware itself (they are parallel and not touching). At the same time the console OS is shown intersecting both the hardware and the vmkernel, being the only contact between the 2. Meaning, the only access the vmkernel has to the hardware is through the console os and therefor, the linux kernel and its drivers. Meaning, it is still running, still very much necessary for vmkernel to function.

It's quite simple really, Linux is running in ring0. Where is vmkernel running once it loads? Ring3? Then it's separate and that's userspace. If it's in ring0 while the Linux kernel is still running in the same address space, vmkernel is a derived work, even if the Linux kernel doesn't actually do anything after that point (which I don't believe, and the diagram backs me up). And if it doesn't do anything once vmkernel loads, why is the Linux kernel even still in memory? Why use Linux at all if you don't need it once VMkernel loads? Do the extra work and make it entirely self sufficient.

The claim was made by the VMware employee that the Linux kernel continues to run but the VMkernel is in control, and I don't believe that. He also claimed that switching control back to the Linux kernel would be akin to rebooting, and that it is difficult to do. Really, you picked this fairly large kernel just to do work as a bootloader? To do nothing at all once vmkernel loads? Why? I don't believe that.

Then he claimed that this is the case on Windows and OS X as well with their other products. On OS X their fusion product runs in a user space process. The only kernel code is the kexts for the various drivers they use for networking etc. If the VM and its guest WERE running alongside the XNU kernel in the same address space it would be incredibly unstable and would negate a number of the benefits of virtualization.

Making all of this even MORE questionable is their description of how they use GPL drivers (And they are). Either the Linux kernel is providing hardware access (As the diagram shows), or they are linking GPL drivers into the closed source vmkernel.