The VMware house of cards
Bloomberg believe VMware’s IPO today may the largest technology offering since Google. But doubts have been cast over the company’s supposedly proprietary ESX product, which may be derived from Linux.
Updated:
- Added link to archived copies of Torvalds’ quote regarding hooks to binary modules.
- Clarified that ESX has two kernels that run directly on the hardware (some readers seem to have thought the statement was discussing virtualized kernels).
- Added video of ESX 3 boot process.
- Windows kernel is NTOSKRNL, not kernel32.
- Readers may be interested that Alan Cox has posted below.
- Here from VMTN? You’ll probably want to skip to ‘Linux isn’t DOS, and VMware isn’t Netware’
- VMware’s Zach Amsden has responded, but does not address the binary blob method used to start vmkernel from Linux.
For those short on time, this article is not about VMware providing source for the Linux kernel used by ESX - this can already be downloaded from VMware.
It is about whether vmkernel, a proprietary blob that can only be loaded by a Linux kernel, can be considered a derived work of Linux.
VMware recreated the modern virtualization industry, resurging an idea last heard of in the 80s to allow multiple instances of an Operating System run simultaneously on the same hardware, on today’s commodity systems.
VMware has 55% market share and few competitors: Microsoft’s competing Veridian virtualization originally scheduled for this years Windows Server release has slipped to 2009, and Xen, supported by IBM, Red Hat and Sun, has yet to get into the hands of their customers en masse.
VMware owns this market right now, and even if VMware’s share shrinks - and nobody’s saying that - Garner estimates VMs will grow from 5 to 40% of new Operating System installs will be on VMs by 2009. Their IPO this week promises to be one of the biggest since the early 2000s.
VMware’s main product is ESX Server. Unlike desktop Virtualization products, ESX is installed directly on to the hardware. ESX is an OS designed only to run VMs and tuned to run them as fast as possible. The VMs live on storage shared between ESX servers, and it’s possible to move running VMs betweens ESX servers. Need some more processing power? Plug a new server in, install ESX, and drag some VMs there to start using it – without ever stopping the apps.
It’s simple to use, avoids all kinds of downtime, and consolidates hardware assets to better utilise them. It’s not cheap, though, and neither are the SANs made by VMware’s parent company EMC.
VMware leads a rapidly growing market with a proprietary product. That’s the basis of estimated value of at least 10 billion dollars. But is VMware ESX really proprietary?
VMware and Linux
Looking at an ESX server, you’ll find what looks like a Linux OS. This isn’t a secret – VMware call this the ‘console OS’. Is ESX server based on Linux? The VMware ESX FAQ provides an answer:
‘Q. Does ESX Server Run on Linux? On Windows?
A. ESX Server runs natively on server hardware, without a host operating system. ‘
Ok, so ESX doesn’t need a host OS. It’s pretty clear that ESX installs directly on the hardware without needing Windows, Linux or any other OS installed first – ESX itself is the OS. The question then is whether the ESX OS is based on Linux. The FAQ continues:
‘The ESX Server virtualization layer is a highly compact and efficient operating system kernel entirely developed by VMware for optimum virtual machine performance … ‘
Or, as the Wikipedia discussion for this issue states:
‘ESX’s kernel is definitely NOT Linux’
Let’s hear it from the horse’s mouth. VMware employee Jim Troyer further states in the discussion for this article:
‘ESX Server’s vmkernel is definitely not Linux or derived from Linux. ‘
A kernel is the core of an Operating System. Kernels do basic things like give memory and CPU time to apps. Windows has a kernel called NTOSKRNL, Linux distributions use the Linux kernel. And apparently VMware ESX uses VMWare’s own kernel, called VMkernel.
So ESX does not use Linux. Matter settled.
Or does it?
Back to that FAQ:
‘ESX Server also incorporates a service console based on a Linux 2.4 kernel that is used to boot the ESX Server virtualization layer. It also runs ESX Server administration applications.’
The OS with Two Kernels
So according to VMware, ESX actually has two kernels that run directly on hardware - the vmkernel, and a Linux kernel. This sounds a bit odd, given a computer can only run one kernel at a given time – otherwise which one determines who gets access to the CPU, memory, and other hardware?
But VMware explain there is a Linux kernel, but it’s only used to boot the other kernel. In this interview Michael DiPetrillo, VMware’s Senior Systems Engineer, states at 4:44 ‘In the 2.xs (the Service Console) was home to a reasonably large number of things, bootloader, it had it’s own networking‘.
Jim Troyer, Senior Product Manager of the VMware Technology Network, mentions on Wikipedia’s discussion page:
‘A good citation for the relationship between the vmkernel and the Service Console is Chapter 2 of Oglesby, Herrod, and Laverick’s ESX Server Advanced Technical Design Guide‘
Which also states that Linux ‘acts as the bootstrap for the VMkernel’ (bootstrap is another term for bootloader.
A Big Bootloader
A bootloader is a small piece of software used to start a kernel. Every OS had one:
- Windows uses NTLDR. NTLDR is 245KB in size, and does not remain in memory after the Windows kernel has booted.
- Linux uses GRUB. GRUB is around 111 kilobytes in size, and does not remain in memory after the Linux kernel has booted.
- Third party bootloader XOSL is around 300 kilobytes, and does not remain in memory after any OS started through it has loaded.
- ESX, according to these references, uses Linux as a bootloader. Linux is at least ten times the size of XOSL. According to both the VMware console and the document mentioned by VMware above, the Linux kernel
But wait a moment: this might be usual, but it’s not unique - Novell Netware used the similarly large MS DOS kernel to load itself. And the document goes on to state that ‘Once the COS has loaded ESX, the VMkernel will assuming the role of primary operating system… then load the COS and several other “helper worlds” as privileged VMs.’
Hrm, it seems that Linux is used to load vmkernel, and then vmkernel virtualizes Linux.
Let’s see how that’s done.
The VMKernel Driver and Linux
vmkernel is loaded by vmkmod, which itself is loaded from the ‘vmware’ service at boot time. Linux services are started via scripts. The specific line in the vmware service script that loads vmkernel runs:
insmod vmkmod
‘insmod’ installs (loads) Linux driver modules into memory. It doesn’t load anything else but driver modules.
When ESX boots, Linux is ESXs kernel: vmkmod is a driver, and vmkernel a large piece of software loaded by that driver that functions in kernelspace.
Linux isn’t DOS, and ESX isn’t Netware
The license for the Linux kernel is quite different to the licensing for DOS that allowed Netware to use it for a bootloader. Proprietary drivers for Linux kernel have an interesting licensing situation. Unlike the license for higher level libraries, which allow those libraries to be used by both Open Source and proprietary software, the license for the Linux kernel specifies that software based on the Linux kernel must be licensed under the same terms.
As a result of that, most drivers for Linux are Open Source: whether created by coders working for Linux companies like Red Hat or IBM, hardware companies like Intel, or enthusiasts who want to make sure their hardware works well under the OS, most Linux drivers are Open Source.
But some proprietary modules do exist, and they do that on one premise: Linus Torvalds (the copyright holder for the Linux kernel) has repeatedly stated that he doesn’t consider drivers ported from other operating systems to be derived works of Linux. After all, if something can load without Linux, it can’t really be considered a derived work. NVIDIAs Linux video card driver shares most of its code with it’s Windows equivalent – NVIDIA’s Linux driver is proprietary, and according to Torvalds, that’s fine - since the driver clearly doesn’t need Linux to start it.
Witness Alexandro Rubini’s interview with Linus Torvalds, published in the September 1998 issue of Linux Gazette.
Alessandro: ‘What is your position about the availability of Linux modules in binary-only form?’
Linus: ‘I kind of accept them, but I never support them and I don’t like them. The reason I accept binary-only modules at all is that, in many cases, you have, for example, a device driver that is not written for Linux at all, but, for example, works on … other operating systems, and the manufacturer … wants to port that driver to Linux. But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn’t feel that I had the moral right to require that it be put under the GPL, so the binary-only module interface allows those kinds of modules to exist and work with Linux.
That doesn’t mean that I would accept just any kind of binary-only module: there are cases where something would be so obviously Linux-specific that it simply wouldn’t make sense without the Linux kernel. In those cases, it would also obviously be a derived work, and as such the above excuses don’t really apply any more, and it falls under the GPL license.’
VMWare’s desktop products don’t use the driver, as they don’t need the advanced storage functions that the vmkernel does. The only way to load vmkernel is by vmkmod, a driver that requires Linux. Take away Linux and there’s no way to load vmkmod and start vmkernel.
It’s possible to ditch, remove, or crash Linux after vmkernel has virtualized it - but you wouldn’t be able to get to that stage without Linux being used to load vmkernel.
But wait - perhaps vmkmod might be a derived work, but the vmkernel it loads is stored in a separate file. Lets check out Torvalds again, from 19 Oct 2001:
‘I personally consider anything a “derived work” that needs special hooks in the kernel to function with Linux (i.e., it is not acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs “help” from the main kernel.’
ESX Server 2.5 architecture, from the VMware Advanced Technical Design Guide. VMkernel uses the vmkmod hook to work with Linux (Console OS). According to Linus Torvalds, such applications are derived works of Linux.
So why hasn’t this issue come up before?
“A derived work of the Linux kernel that’s not legally redistributable”
Christopher Helwig is the Linux SCSI storage maintainer, and one of the top 10 contributors to the Linux kernel. He has been pursuing VMware over the issue for a year. Why hasn’t Hellwig pursued VMware legally? Hellwig answers in a post to iSCSI mailing list:
‘VMware uses a badly hacked 2.4 kernel with a big binary blob hooked into it, giving a derived work of the Linux kernel that’s not legally redistributable. I unfortunately don’t have enough copyrights on that particular version to sue them. I do object to use of any open-iscsi code of my origin to be used with it, though.’
Do VMware know about this? They should: they employ a number of developers who work on the Linux kernel. And they do: witness the following from last August - replying to a post from VMware’s Zachary Amsden to the Linux kernel mailing list, Hellwig wrote to Zachary:
‘Until you stop violating our copyrights with the VMWare ESX support nothing is going to be supported. So could you please stop abusing the Linux code illegally in your project so I don’t have to sue you, or at least piss off and don’t expect us to support you in violating our copyrights.
I know this isn’t your fault, but please get the VMware/EMC legal department to fix it up first.’
Zach did not post a reply, and no mention of the topic has come from VMware anywhere, despite Hellwig’s continued claim on the list in front of VMware staff. From May 6 this year: ‘VMware… are on the almost black side of the illegality’
Is Hellwig right, and is VMware ESX a derived product of Linux? Unless vmkernel can be loaded without the Linux kernel, it would appear so. VMware was developed from another, long ago OS created as a research project, but it’s unclear whether vmkernel was ported from that OS or rewritten as the Linux-requiring binary blob.
What’s more of an issue is that VMware had these serious questions posed directly to them a year ago, repeated in a public forum many times since, but have yet to respond at all.
ESX is VMware’s main product. EMC are hoping to raise 10 billion dollars from its promise. They have a duty to defend it, and clarify the licensing situation for all concerned.
Simple moderation policy:
- Contribute something
- Justify your opinion
- Be courteous to others
August 15th, 2007 04:26
You forgot IBM’s VM product which was first available in the 1960s that supported multiple logical operating systems running under one physical computer.
Today’s zVM product happily runs IBM’s enterprise operating systems as well as Linux as virtual servers.
August 15th, 2007 04:49
interesting timing
August 15th, 2007 04:54
One thing to consider is the architecture has changed in 3.0.x. The order of operations you describe here is for the 2.5 version of ESX server. Almost all of the Console duties have been moved to the vmkernel in the 3.0.x version. I do not have a legal background so I am not sure what this means for Linux but it worth noting.
Ed: Indeed, some console OS duties have been moved to vmkernel. However ESX 3 still uses the Linux kernel to start vmkernel, as you can see in this video of ESX 3 booting.
August 15th, 2007 04:55
I appreciated the rundown - we’ve had a VAR in here pretty reliably trying to sell us on ESX and I explained to them my doubts about it’s legality and (not to mention morality), so this is good stuff.
August 15th, 2007 05:12
You gotta be kidding me. GSX is the same basic archtecture and doesn’t need Linux to load. Obviously a troll post because someone has a vested interest in short-selling VMW in the wake of their IPO.
Ed:GSX does not include vmkernel (though it’s possible they may share code - only VMware knows for certain). It is unknown whether Christoph Hellwig owns VMware stock, but the author does not.
August 15th, 2007 05:28
2 things:
1) There is nothing Linux-specific in this process. The vmkernel could perfectly be loaded in a Windows console OS. So how could the vmkernel be a derived work?
2) VMware the company does not have the obligation to answer people who criticize it in public forums. They didn’t do it when Kevin Lawton was claiming they were stealing his Plex86 code (and it turn out they didn’t). They don’t do it either when Chris Hellwig claims they are violating the GPL.
Chris should either put up (and bring them to court), or shut up (and stop spreading FUD). To me, the reality is that these claims have very little substance, and that is why they have not been brought to court.
August 15th, 2007 05:38
I don’t get it. If ESX is really a derivative work of Linux and/or infringes the GPL, then why wouldn’t VMWare fix the problem? This is a large corporation with money coming out of their ears. It would be absolutely nothing to them to drop a couple of hundred grand to buy/write a bootloader, and to rewrite any infringing OS components.
August 15th, 2007 06:27
Just from this article I wonder if it’s running Mach using linux instead of BSD. Kinda like Apple did for MkLinux…
As it is possible to have a duel environment.
One with linux and one with maybe BSD.
If not maybe they will port the kernel mod to BSD and not have to worry about it.
August 15th, 2007 06:38
VM was last heard of in the ’80s? Maybe in your circles. But in the Fortune 1000 there are hundreds of mainframes running VM, some hosting hundreds of Linux instances. VM is celebrating its 35th birthday this month and has never been AWOL.
August 15th, 2007 06:46
http://www.vmware.com/download/open_source.html
What, if anything is claimed to be missing?
Ed: According to Hellwig’s statements, the source code to vmkernel
August 15th, 2007 07:14
They do run Linux! I don’t care what they say. It’s a Redhat-derived installer, using RPMs to install a linux system. I’ve not dug deep into ESX, but from what I’ve seen of the OS, it’s Linux running the core app on top. Netware, by comparison, bootstraps with DOS, then unloads it and loads the Netware Kernel. VMWare doesn’t do that at all. ESX is still pretty damn good though!
August 15th, 2007 07:31
Interesting article and good research you’ve done! It’s indeed interesting, how VMWare doesn’t respond to the accuses kernel developers made. But: They’re releasing a lot of their virtualization products for free, e.g. the VMWare Server. Maybe there will be a stripped down version of ESX someday… They usually care about GPL legal rights and even publish some of their code derived from GPL projects. Please follow up on this case!
August 15th, 2007 08:08
_ This statement - “VMware recreated the modern virtualization industry, resurging an idea last heard of in the 80s to allow multiple instances of an Operating System run simultaneously on the same hardware, on today’s commodity systems.” - distorts the history of operating systems. One needs to remember that IBM has been selling their mainframe VM operating system for over thirty years (see http://en.wikipedia.org/wiki/VM_%28operating_system%29). There’s an old saw about how knowing that something is possible is half the battle. I would think that a PC-platform (server/desktop) software vendor would be glad to have such a long-running proof-of-concept to use as an investor pacifier. The bedrock of IBM’s Linux-on-the-mainframe strategy is zVM - the current edition of that venerable OS.
August 15th, 2007 08:20
I would take your position more seriously if you had actually taken the time to proof read your article.
“Bloomberg believe [sic] VMware’s IPO today may the largest technology offering since Google.”
Did you mean to say, “Bloomberg believes VMware’s IPO today may the largest technology offering since Google.”?
“But wait a moment: this might be usual [sic], but it’s not unique - Novell Netware used the similarly large MS DOS kernel to load itself.”
Did you mean, “But wait a moment: this might be unusual, but it’s not unique - Novell Netware used the similarly large MS DOS kernel to load itself.”?
“Do [sic] VMware know about this? They should: they employ a number of developers who work on the Linux kernel. And they do: witness the following from last August - replying to a post from VMware’s Zachary Amsden to the Linux kernel mailing list, Hellwig wrote to Zachary:”
Can you say, “Does?” Or, “Semicolons and hyphens, oh my!”
You seem smart and know what you are talking about. But if you are not clear in making basic statements, how can I take you seriously on the real facts of your arguments?
Mark
VMware enthusiast
Ed: Indeed I meant unusual rather than usual. Fixed, thanks for the heads up. Referring to companies as plural (rather than singular) as in ‘Do VMware know about’ and ‘Bloomberg believes’ is both correct and quite common.
August 15th, 2007 09:14
I’ve no official opinion on Christophs view at this point but let me correct one important detail. Linus has said he’s okay with some binary modules. However he owns but a few percent of the copyright and others, me included, have quite specifically said we are not. Its entirely possible nvidia’s code is not a derived work - the caselaw is very limited, but the only question that matters is “is this a derived work”, not “what Linus thinks”
August 15th, 2007 10:10
It’s also very interesting to note that ESX server as a whole can be fairly easily crashed from the linux side. The place where I work has a driver that gets loaded into the linux kernel and we were able to take down the entire ESX by writing into memory above where the vmkernel said it had loaded.
If the console is actually virtualized, it shouldn’t be able to crash the entire machine.
August 15th, 2007 10:59
BW, in Windows world, sometimes IE can cause an OS hung, are you saying Windows depend on IE?
August 15th, 2007 11:11
“t’s also very interesting to note that ESX server as a whole can be fairly easily crashed from the linux side. The place where I work has a driver that gets loaded into the linux kernel and we were able to take down the entire ESX by writing into memory above where the vmkernel said it had loaded.
If the console is actually virtualized, it shouldn’t be able to crash the entire machine.”
Great, so you’ve proven that you can load a driver into cpl0 and crash the entire operating system. BIG argument you’ve got there. Sit down. Think.
Both kernels run on the same hardware. Yes it’s possible. Again follow the Link to coLinux above if you don’t believe me.
-Bernhard
August 15th, 2007 11:31
I just posted my own thoughts (and the contents of some files off of an ESX 3.0.1 box) on my own site.
August 15th, 2007 15:20
I can install LinuxBios on a motherboard and then boot Microsoft Vista on this motherboard. Vista is a number of large binary blobs being loaded by Linux on hardware.
If Dell or HP started shipping all their computers with LinuxBios and Microsoft Vista installed. Wouldn’t they be obligated to provide the source code to Vista? They would be distributing binary blobs loaded onto hardware by Linux making Microsoft Vista a derived work.
What if Microsoft decided to use LinuxBios on the next version of the Xbox? If you want another example.
I think this argument is on very shaky grounds and doesn’t hold much more legal weight than my above examples. I personally feel that Vmware needs to provide the source to their hacked up version of the 2.4 kernel to their customers, but that would be the extent of it.
Ed:
The issue in question is the interface - from what the kernel developers have stated, software loaded by kexec, LinuxBIOS or anything else considered a public API can have any license it wants. However the module interface is not considered a public API.
August 15th, 2007 18:32
I think this article would read better if you didn’t keep mixing ESX 3 and ESX 2 together, with ESX 2 there was 2 kernels running at the same time, interacting with the physicla hardware. in ESX 3 the vmkernel is king and the linux service console is relegated to a VM status. Give it a few months the service console will have gone totally and there wont be any problem (if indeed there is at present - which i dont think so).
Ed: Alas there’s more publicly available resources on ESX 2.5’s architecture. However ESX 3 still runs Linux to boot vmkernel - see the attached video.
August 15th, 2007 20:23
comment #22:
>Perhaps Microsoft should have gone around claiming every application out
> there that patches the Microsoft binaries at runtime to provide enhanced
> functionality
You may be missing an important point here. People can create software for w32 only because MS provides different SDKs which contain respective licenses. Coverage of this licenses is a subject to continuing litigations (vista search engine is the latest loud one).
The situation is quite different for linux. The kernel has “user-land” API which is in the public domain. Developers can access this API via LGPL’ed libc. That a raw legal concept for proprietary linux applications.
However, the above is only true for “user-land”. The moment the application included a kernel header it became GPL contaminated. This is implied by the author about vmkermel, and this is related to the kernel module you mentioned.
This is fully applicable to the nvidia case as well. In fact, this case maybe used a basis to claims that linux copyright is not enforced (similar to USL v. BSDi case, taken by BSDi). But I would not count on it, since a secret agreement between copyright holder and purported violator would ruin the case.
This article is very insightful, and so are most comments.
August 15th, 2007 20:50
first @Bernhard Poess: colinux doesn’t run ‘2 kernels on the hardware’. The Linux kernel is running completely in user mode with CoLinux, like with UserMode Linux. The only kernel running on the hardware is Windows. Also, another poster mentioned that by messing with the admin console Linux you can crash the _entire ESX_. By tinkering with CoLinux you _can not_ crash the whole windows like with Winword or IE you can’t crash the whole windows. If the Linux would be really virtualized, it would not be possible to crash the whole ESX. If the same thing done in a ‘normal’ VM doesn’t crash ESX but done in the admin console Linux does (testing this is easy), this is a proof that the admin console Lİnux is not virtual.
August 15th, 2007 23:08
Great article. I think you know you’ve really touched on a topic of interest, and confusion when you see so many people being so defensive. I’ve worked with VMware ESX for many years now and have often wondered about its legality. I saw several post mention a quick chat with VMware would resolve. Working for a fortune 50 company that has a tremendous stake in VMware, I can tell you a discussion with them will not provide you with an accurate answer. VMware has danced around this issue for 5 years or more. Anyway, great job with the article and responding to posts.
August 15th, 2007 23:11
OK, I am biased! I love VMware and for this reason this article concerns me… because it seems too true to me and I never stopped to think about this.
But one point I would like analyzed is the following: VMware uses the same hypervisor (code that does the virtualization) in all its products (like VMworstation, and VMserver). So my question is this: If VMware can load the hypervisor ***as an application*** on other OS’s, is loading it directly on hardware ***as an OS*** through the Linux kernel a port to Linux (albeit a funky one) or a derivative work?
“if something can load without Linux, it can’t really be considered a derived work. […] and according to Torvalds, that’s fine - since the driver clearly doesn’t need Linux to start it.”
Well the hypervisor seems to be able to start without Linux… but not on hardware. Conversely, I guess VMware could have used any other OS to do the same thing. Does that make a difference?
VMware workstation came first and even today, VMware continues to test many new features there before moving up the product line through VMServer and finally ESX. ***I know this logic is a reach!***
As for the Service Console or COS, it is definitely the Linux kernel running as a “special” VM and loaded with configuration and management tools. (Crap! Crap! Crap!)
I hope there is a way to resolve this because I love ESX, the vision of the VMware’s founders (Mendel Rosenblum for president!), and the improvements this is making in the datacenter.
August 15th, 2007 23:25
BTW, I successfully crashed the Service Console (filled up /) and the hypervisor continues running over twenty VM’s.
To me, this is a moot point. The concern is around “derivative work” and hypervisor configuration and management tools in the Linux-based COS.
August 16th, 2007 04:12
@Thomas Murders:
yes, coLinux runs two kernels in cpl0.
http://www.colinux.org/publications/Reprint-Aloni-OLS2004.pdf
And yes you CAN crash the windows kernel because you _are_ in cpl0.
There is a misperception here about virtualization and isolation. You can run two operating systems parallel two each other in the same privilege level by modifying them to play nicely with each other. This method is called para-virtualization. (Note there is also a version of para-virtualization that puts one or more OS’s in user mode). However those two para-virtualized OS’s will not be isolated from each other, thus crashing one may potentially crash the other.
Full virtualization, like provided by the vmware product, the virtual pc series, kvm, … also isolates a virtualized operating systems by using special techniques like binary translation or hardware virtualization.
-Bernhard
August 16th, 2007 05:22
I use VMWare for our company servers and plan to upgrade to a fancier variant as soon as we need it.
I’d be even more likely to pay for VMWare if it was 100% open source. I want the support for my business use of virtualization and I’m willing to pay for it. All the better if it’s open source as that makes me more comfortable with the product.
August 16th, 2007 06:18
It looks like a fairly grey area to me. We run six heavy ESX boxes here (including two new quad dual-core opterons) and I’ve got a fair amount of experience with it. When you watch it boot, it’s easy to see how the issue is confusing.
For instance, it appears that all the hardware (or at least most of it) is actually controlled by the Linux kernel, but that control is handed off to the VMKernel during boot, like a proxy. So, the VMkernel doesn’t need drivers for e1000 or cpqarray, it just asks the linux kernel for data and the linux kernel gets it. But, it might not. It’s hard to tell, and you can’t view the source code.
Either way, I don’t like Linus’s stance on Linux binary modules because it’s far too open for interpretation; his interpretation. To me, any module for Linux is a module that needs Linux to run, whether it was originally written for something else or not.
That being said, I feel as though binary modules are okay, but for other reasons. Stupid, but okay.
August 16th, 2007 06:19
I will not quote the Kinda anonymous, self important post, however, if anyone believes that developer can legally develop application for Microsoft OS platform without more or less, depending on the softwares used, filling Microsoft’s “pocket”, then you should think twice.
Yeah, Microsoft does not claim rites on developers work, they are after developers money instead.
Windows developer
August 16th, 2007 09:58
I recently convinced my bosses to buy an ESX license and the thoroughly impressed with the product. In the back of my mind, I did wonder about the legality of the product, but presumed VMware should know better and kernel hackers would be all over them if they hadn’t sorted this out in some way. I hope Linux copyright holders can come to some agreement that doesn’t screw us ESX customers. I would really appreciate if you all wait until they get their $10 billion and then sue and settle for a chunk of that, for past infringement. Then work whatever out for the future. Their new ESX lite, firmware version probably isn’t an extension of Linux. I am really hoping to see that product come built-in to future servers and desktops. There has been some talk of Dell pre-installing Windows and Ubuntu based on the product.
August 16th, 2007 14:49
Great article. I have wondered about this for some time. Great comments as well. Thanks all.
There is only one logical conclusion to all of this… VMware is going to open-source ESX technology. Look for this to happen coinciding with embedding it into Dell and HP desktops.
Open source ESX is the BIOS of the future.
August 16th, 2007 18:17
I make extensive use of virtualisation and I like curries.
August 16th, 2007 23:02
To address the kinda anonymous statement (which Karlo kindly addresses):
While Windows does allow software to use its “services,” I would assume that the Windows License allows such use. Is anyone aware of that license well enough to comment on the legality?
The issue, I am guessing (and mentioned above somewhere), is that the GPL requires “derivative works” to be released under the GPL. The question presented is whether VMWare’s kernal is a “derivative work” that is not being released under the GPL.
If the MS Windows license does not require any such release, it would be, I am guessing here, irrelevant whether a program was a derivative work of MS Windows (because its release under a particular license is not required)…
I’ll have to do some reading of the licenses involved and look at the technology to speak specifically on the issue.
August 16th, 2007 23:10
Wonder if this will be a good test of the GPL ? Clearly VMware/EMC has walked into the grey area. This is a case well worth following.
August 17th, 2007 06:02
I saw a mention of ESX being a RedHat derived installer. More appropriately it’s simply RedHat itself customized by VMware and although I am not sure it’s possible RedHat has helped a lot. A measurable portion of Redhat’s revenue actually comes from ESX licenses and they value the relationship as one of their most important.
August 17th, 2007 10:44
I think the best argument here is that VMware are loading a GPL licensed scsi module (soure here: http://www.vmware.com/download/esx/open_source.html) into vmkernel, which is the binary blob and restrictively licensed. Now, if you were to ask me the non-specific question, “is it legal for a restrictively licensed program to load a GPL licensed module?” I would have to say yes, it is, so long as the program doesn’t *require* that module to function, and so long as that module isn’t distributed with the restrictive program. But it seems ESX both needs this module to function and is distributed with it..
August 17th, 2007 21:32
Kinda anonymous, no-one forced you to use Linux for your application - it was given to you freely in return for your acceptance of it’s license, which states that if you sell (note: not use, you can patch away to your heart’s content if it’s just for your own use) your product and it needs the Linux kernel to run, then you must abide by the license and release your code under the GPL. Failing to do this (if, of course, you sell your wonderful application) makes you quite simply, a thief.
August 18th, 2007 01:40
I do not feel that the bulk portion of VMWare is Linux-based. In analyzing how my own VMWare ESX server works, it appears that VMWare has special drivers that load that gives it better hooks to the hardware while still utilizing the Linux driver base. These as such should be release open source as well as their custom TCP/IP stack and vmfs. The pieces that allow virtualization and all the nifty features, however are seperate programs which utilize the drivers. I feel that instead of pressing them to release the source, we should press VMWare to drop this marketing tactic of “Runs directly on Hardware” and instead they should say “Include highly-customize Linux Host OS designed for easy install and manageability as well as quick Virtualization.” Because this is what it really truly is. A highly customized version of RedHat Linux, as shown by /proc/version: Linux version 2.4.21-47.0.1.ELvmnix (mts@pa-build89.eng.vmware.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47)) #1 Thu Jul 26 13:26:41 PDT 2007[VMnix version 52542]
August 18th, 2007 03:07
There are no “drivers” in Linux kernel, only modules. And this is what licence says:
“NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of “derived work”.”
Are modules considered “user programs”? And if not. Why nVidias closed source modules and modules like EMC:s powerpath are accepted? What is the normal system call?
Linus please answer
Ed: Linus has answered - you seem to have missed that section of the article. NVIDIA drivers and Powerpath were ported from other operating systems.
August 18th, 2007 08:33
The VMware vmkernel is most definitely NOT a derived work of Linux.
I have seen three arguments that ESX is in violation of the GPL. None of them hold any water in my opinion. As for an official statement, we may make some statement in the future. What I say now is merely my professional opinion backed by hard facts.
The first argument I have seen is that ESX uses a Linux distribution during operation. It certainly does. This old Linux kernel, which is freely available under the GPL, runs an entity called the console OS. This is based on a standard Linux install. You can watch it in operation in the ESX boot video above. It uses RPM based packaging, and many userspace programs from existing Linux distributions in addition to many proprietary userspace programs. There is no GPL violation in using proprietary software on a Linux operating system. Any argument that ESX is in violation of the GPL for relying on said Linux OS falls flat on its face, so much so as to publicly humiliate the accuser.
First, many complex (proprietary) systems rely on Linux in one form or another, perhaps running on a different machine in a corporate IT network, perhaps running inside a virtual machine in a single box solution. This is no argument for GPL violation. Second, these proprietary software programs are simple UNIX programs, complying to a well established system interface. They could just as well be run on FreeBSD, Solaris, or even on Windows using UNIX emulation libraries. The only thing that matters, as Alan Cox points out, is whether the derived work argument applies. To the third and final point. Since the Linux kernel specifically grants exception to userspace programs, and allows for the creation of proprietary software which relies on and depends on the Linux kernel, there is no possible argument that any of the ESX components which run in userspace on the Console OS are derived works of Linux.
The second argument that I have seen is that the vmkernel itself (the core part of ESX) is a derived work of Linux. The argument goes - with variations - since the vmkernel is loaded by Linux, it is a binary module, and thus a violation of the GPL; alternatively, since the binary vmkernel module uses Linux symbols (standard hooks that are exposed to other binary modules), it must be in violation of the GPL. I will not debate the contentious issue of binary modules here. But I will say this argument is wrong on at least three counts.
First, the vmkernel is not a Linux kernel module. The vmkernel is a completely isolated and separate piece of software which is loaded by a module called vmnix. The vmkernel has no knowledge or understanding of Linux data structures or symbols, and as a necessary result, does not depend on the Linux kernel for any services whatsoever.
Second, the vmkernel does not run inside or as part of the Linux kernel. It simply takes over control of the CPU and switches into a completely alien operating mode - one where Linux itself no longer exists. The former kernel used to boot the systems is still alive, but to switch back to it is a complex and involved process, similar to the well-defined copyright boundary of switching between two user processes, which are completely separate programs, running in their own address spaces. The vmkernel and the console OS Linux kernel are two completely separate entities, and the process of going from one to another is even a stronger separation than that given to user processes - more like rebooting the processor and re-creating the entire world. There is also no reason this can’t be done on any other operating system, in fact, this is exactly what we do on Mac OS and Windows to run our hosted products. An extremely strong argument for an independent, rather than a derived work.
Finally, there is no source code from Linux present in the vmkernel. The most clear way to become a derived work of another code base is to copy and include part of the source. ESX does no such thing. None of the code in the vmkernel is derived or copied in any way from GPL code.
The third argument I have seen that ESX violates the GPL is complaints about the way the driver layer operates (”that VMware are loading a GPL licensed scsi module … into vmkernel”). As usual, I will dissect and dispel the claim that this violates the GPL in three co-tangential ways.
First, the vmkernel, just like any other kernel is free to run and load any other object code it desires. You can write a driver or any other piece of software under any license whatsoever, and it goes nowhere towards enforcing anything about the execution environment of said software unless it is explicitly stated in the license. Copyright merely gives the authors control over how a work is copied and distributed, not how it is run (as in, you can’t copyright your DVD under the Foo. Corp license, which gives the user permission only to play said DVD on Foo. Corp DVD players; you can however prevent people from copying your DVD and selling it unless they agree to run it only on Foo. Corp DVD players). The GPLv2 does not make any such assertions about the execution environment of the software; indeed, if it did, the following scenarios would be ludicrously possible:
1) GPL software could not be run on proprietary operating systems
2) GPL kernels could not be run on proprietary hardware, which includes software BIOS components
3) GPL drivers loaded and run in non-GPL kernels would taint those kernels and bring them under the scope of the GPL.
This concept is simply ludicrous. It would mean that loading a GPL driver in Windows would subject the Windows kernel to the GPL. Check out the OSSWin project - they have GPL drivers for Windows.
One might ask, if the vendor of a proprietary kernel were prohibited from distributing GPL software along with their proprietary product. The answer is no. In fact, in this scenario, the GPL actually specifically exempts the distributors from any such requirements. To quote, verbatim
“In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.”
Again, we see the only valid argument is whether another work is a derived work of a GPL licensed work. To tackle this argument head on, one must look at the question of derived work.
For my second response to the third argument. It is accepted among the mainstream that drivers ported from other operating systems to run on Linux are not subject to the GPL; indeed, Linux provides services to these binary driver modules that are similar among all operating systems - facilities to set timers, plug into event chains, register new device or filesystem types. Use of these type of basic facilities does not imply a derived work. And by extension, nor does emulation of these basic facilities imply a derived work. Linux has established a well defined, binary interface through which driver modules and the kernel may interact, with well defined copyright separation. In fact, in newer versions of Linux, some more internal Linux specific functions are exported only to modules which are licensed under the GPL. If there is such a clear and well defined boundary of copyright separation, there is no way to reason that being on either side of this interface creates a derived work of the other side. So emulating Linux, Windows, or any other operating system interfaces which have this clearly defined separation is not a derived work argument.
This has been constantly found to be true in similar cases, and in fact was vehemently argued correct by many in the open source community when faced with the threat that Linux was a derived work of SCO UNIX because the user / kernel interfaces of Linux were based on the traditional UNIX interfaces (and that argument is well settled). Linux itself crosses the same lines as ESX’s vmkernel. Linux can emulate the Windows NDIS layer to load network drivers, and has all sort of shims to allow loading and running binary firmware and drivers. Does this make Linux a derived work on Windows? Certainly not. And if your argument is about to be — well, ndiswrapper is technically ok, because it is not part of the kernel, it wraps Windows drivers inside a module, which is separate from the kernel — think again. The vmkernel can load drivers from Linux and Windows, and it does so by wrapping those drivers inside a module, which is separate from the vmkernel. You cannot simply choose an position and apply it only when it is convenient. In this case, there is no way for Linux to take any other stand.
For my third desconstruction of this, keep in mind that copyright only applies to the copyright holders. VMware distributes, in binary form, old drivers, which for the most part consist of drivers written by the original hardware manufacturers themselves. Not only does the GPL explicitly give us permission to redistribute these drivers in binary form, and not only are we free from any taint of derived work, but those vocal advocates such as Christoph, who are so offended by this, do not even own any copyright on the code we are distributing.
I am not a lawyer, and this is not an official statement, simply my plain and common sense reasoning. I would not stand for any GPL violation and I feel compelled to defend my position as a respectable member of the open source community. So in summary, I most sincerely believe:
1) There is no argument that depending on a Linux console OS makes any part of ESX subject to GPL that is not already opene sourced. We have open sourced those GPL components of the system which we have modified and given the changes back to the community.
2) There is no argument that loading the vmkernel by bootstrapping it with Linux makes the vmkernel subject to GPL. In fact, in the funniest counter-example, Linux itself used to be boostrapped under MS-DOS by running the command loadlin (note the 7 character name, since DOS would not allow enough characters for load-linux).
3) There is no argument that distributing GPL binary drivers makes any piece of software distributed with them or using them subject to GPL. In fact the converse appears to be explicitly stated in the GPL itself.
So I find that there is no compelling evidence nor any doubt in my mind whatsoever that VMware is most definitely not violating the GPL in any fashion, nor even infringing on any gray areas, and that those vocal complaints we have seen are completely unjustified.
Zach
Ed:Zach, thanks for posting.
1. That argument hasn’t been made anywhere in this article, which mentions that the source to the kernel used by the Console OS is available for download in the first paragraph. Neither is this the argument made by Hellwig. However I do appreciate and understand why you would address it, as many people are still confused by it.
2. VMkernel is started by the vmkmod hook - ie, from a Linux kernel module. As mentioned in the article, what happens after that module is loaded is irrelevant - the point is that vmkernel is started from Linux. The loadlin example is also irrelevant, as the userspace land of MS-DOS does not have the same copyright restrictions as the kernel space of Linux. Could you specifically address this? If vmkernel is not ported from another OS and indeed depends on Linux to load (not run), by Linus Torvalds’ logic vmkernel is a derived work. Whether vmkernel continues to depend on Linux after it has loaded or not is irrelevant, if Linux copyright had to be infringed to start vmkernel in the first place.
Could you clarify whether you are stating vmkernel has been ported from another OS, and which state any OS vmkernel was running on prior to being ported to Linux? This would happily address the issue.
3. Again, that argument hasn’t been made anywhere in this article. VMware can emulate the Linux driver API all it wants. However, again it’s understandable why you would address it.
August 18th, 2007 09:02
Thanks for this article. It’s a nicely written piece on a fairly technical topic that’s understandable by avid computer users who, like me, have limited knowledge of the inner workings of OS kernels.
August 18th, 2007 16:19
Interesting. And thanks to Zach for discussing the several ways ESX touches GPL code.
Quote this website:
“VMware’s Zach Amsden has responded, but does not address the binary blob method used to start vmkernel from Linux.”
Quote Zach Amsden:
“The vmkernel is a completely isolated and separate piece of software which is loaded by a module called vmnix … the vmkernel does not run inside or as part of the Linux kernel.”
Seems to me like he did a perfectly good job of addressing the point.
Quote Editor:
“VMkernel is started by the vmkmod hook - ie, from a Linux kernel module. As mentioned in the article, what happens after that module is loaded is irrelevant”
Eh… haven’t used many bootloaders, have you? The process Zach described - that a specific environment is set up, then handed off to an independent piece of software via a binary interface - is exactly how a bootloader works, and that is all that is relevant. It is exactly how GRUB passes control to Linux. Put more simply, if you claim vmkernel is a derived work of the Linux kernel, you must also claim the Linux kernel - or any other kernel booted from GRUB - is a derived work of GRUB (since it is loaded by a GRUB module exactly the same way). Care to make that argument?
But this is all noise around one very important issue.
Quote Linus Torvalds:
“But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn’t feel that I had the moral right to require that it be put under the GPL”
— Logically, (seen without Linux) implies not (GPL)
Quote this site:
“Unless vmkernel can be loaded without the Linux kernel, it would appear [VMware ESX is a derived product of Linux]”
— Logically, not(seen without Linux) implies (GPL)
This is a textbook example of a a logical fallacy. Linus’ statement suggested a way software could avoid being under the GPL; he did not (as you assert) imply this was the only way.
I still have not seen a reason why being loaded by a Linux kernel module requires code to be GPL - especially when the thing being loaded never “links” with the kernel (either statically, or dynamically via function pointers). The kernel module, yes, probably must be GPL since it seems derived from Linux. The thing loaded, can be anything. Microsoft code, even.
The GPL is a successful license because it carries both privileges and burdens: it gives you great freedom to use other people’s code for your own purposes, but it also gives others the right to use your code in ways that you may disagree with. (Nobody ever expected Linux to be a bootloader for another operating system!).
What next? Will there be a GPLv4 that says “any code that uses this work as a bootloader is a derived work”?
Ed: You seem to miss the point that the Linux kernel interface does not have the same licensing as Grub, DOS, etc. (in DOS case, software that is dependent on it does not have to be released under the same license, in Grub’s case, very little software is dependent on it, as it uses a common interface - an OS that could be started by Grub isn’t dependent on it as it could be started by any other bootloader).
- If VMware had used DOS to boot VMkernel, there would be licensing issues. The DOS userland environment used to run loadlin, or Netware’s SERVER.EXE does not have the same license as the Linux kernel
- If VMware had used a partition boot sector to boot vmkernel they would have no issue. Software started from a partion boot sector could be started from any bootloader - and is thus clearly not dependent on a particular bootloader in the same way that it seems vmkernel can only be started by a Linux kernel.
August 18th, 2007 17:26
It’s time for VMware to answer the question. No more silence.
August 19th, 2007 03:58
Hey Ed: Linux has the identical license that Grub has. They are both GPL2. Additional words that you’ve read from Linus do not constitute extra restrictions. Your statement that “the Linux kernel interface does not have the same licensing as Grub” is false.
Furthermore, you can use Grub, a GPL2 program, to boot Windows. By your logic, this is a license violation. In reality, it is not.
Ed: You seem to miss that OSs that start via a partition boot sector can be started by any bootloader, and thus have no dependency on that particular piece of software. If you created an OS that could only be started by Grub (rather than NTLDR, Lilo, etc) the dependent OS could indeed be considered a derivate work of Grub, in the same way vmkernel could be considered a derivative work of Linux on which it seems dependent.
August 19th, 2007 04:15
Quote Editor:
“You seem to miss the point that the Linux kernel interface does not have the same licensing as Grub, DOS, etc.”
GRUB is GPL. Linux is GPL (excepting syscall interface, which we both agree is not relevant). In point of fact, the Linux kernel interface and GRUB have exactly the same licensing. Exactly what point am I missing?
For GRUB, the analogy is just about perfect: GRUB contains a GRUB module designed specifically to load Linux (i.e. GRUB can load Linux either via multiboot or via a custom Linux interface). There is nothing special about the Linux kernel - it’s just another piece of GPLed software.
Of course, the whole Linux-based bootstrap is under GPL, so you also have the GPL-guaranteed freedom to reimplement the vmkernel bootloader however you wish - including with FreeBSD, or Windows, or DOS, or anything else. Have you tried this? Until you have demonstrated that it is impossible (by showing that all possible vmkernel bootloaders require code from the Linux kernel), you cannot claim the vmkernel requires Linux to run. (Proverbial: “It’s not impossible. It just hasn’t been done yet!”).
Ed: Grub and Linux do indeed share the same license, however Grub uses a common API - the x86 boot specification - to start Operating Systems. Because of this, very little software is dependent on it - an OS that could be started by Grub could be started by any other bootloader. vmkernel, however, can only be started by the Linux kernel, as far as we know.
It certainly is possible to port vmkernel to another OS kernel in future, however that does not change the fact that vmkernel was not previously ported to Linux from another OS - ie, it was originally created with a dependency on a GPLed work. See Linus’ comments above.
August 19th, 2007 09:57
The idea that logical dependency has anything to do with derivative work status is a complete fantasy.
USC Title 17 Section 101 defines “derivative work” as follows:
It is an enormous stretch to suggest that using the interfaces another work provides makes one work “based upon” and “recast, transformed, or adapted” from the first. There is no legal precedent. The consequences would be ridiculous.
It would for example, make every user program a derivative work of every operating system that could run it. It would make every software driver a derivative work of the corresponding hardware device. It would make every binary program a derivative work of the microprocessor and machine architecture it was compiled for. It would make network clients (like Samba) a derivative work of compatible network servers.
It is hard to imagine any more counterproductive line of reasoning than this. If one cannot be bothered to look up the definitions of terms in the relevant sources as well as consider carefully the implications of his widely publicized commentary, he would be better served to keep silient before propagating such utter ignorance and confusion upon the world at large.
It doesn’t matter what one thinks “derivative work” should mean - it only matters what a court of law has held it to mean or will hold it to mean, when interpreting the congressionally established definition of the term in the context of specific cases.
Ed: The active word here is ‘linked’ - not ‘derived’. Specifically, whether vmkernel is linked against what seems to be the only method of starting it, the Linux kernel. How a court defines linking at the kernel level could indeed be quite interesting. If vmkernel is determined to be linked against the Linux kernel, then VMware may either lose their right to distribute and use the VMkernel (which would put VMware’s existing customers into quite a quandry) or may be forced to license the versions of the software linked against the GPLed kernel under the GPL, which would concern VMware’s investors (but probably not that much - virtualization is becoming commoditized, and VMware’s advantage is its brand, and tools). Of course, I’m not a lawyer, and have no idea about legal matters.
August 19th, 2007 10:24
Sometimes the logic of an argument is best disproved by looking at it in reverse.
The author is implying that because an application relies on Linux *and* needs linux to function, then that application must be a derived work.
This would be a very worrying position to, practically, all commercial software companies out there: Your Software relies on Linux/Windows/Solaris/etc (because you were too lazy to make versions for all mainstream OSes) and so we (Linux, Microsoft, Sun, etc) say your software is subject to OUR licenses. It is patently untrue.
This is the SCO legal argument… “you have (had) access to the source, so you must have copied it or used it to make your own application”. Are the Linux community really falling into the SCO mindset?
The answer to this is simple, and has nothing to do with what bootstrap/kernel/app starts it, nor does it have anything to with dependencies.
Quite simply was the application’s SOURCE CODE DERIVED from GPLed code? That is the only question to answer - all the rest is smoke, mirrors and SCO-type FUD.
PG
Ed:The software you use in your applications can affect the license. If you disagree, I suggest you either ask a lawyer, or write some proprietary software linked against GPLd libraries.
August 19th, 2007 19:15
“VMware was developed from another, long ago OS created as a research project, but it’s unclear whether vmkernel was ported from that OS or rewritten as the Linux-requiring binary blob.”
So wait, you are stating that vmkernel was part of another OS, and then your question lies within the issue of whether it was ported to or rewritten for Linux? You don’t think that other proprietary software vendors completely rewrite their code for Linux instead of hacking together a ported version? Also, how do we know that VMWare doesn’t have a version of vmkernel that runs on BSD or Solaris in their R&D labs that they ported to Linux for release because of better hardware support/performance/whatever? Just because the products they sell run on the Linux kernel doesn’t mean it HAS to be on Linux.
Furthermore, aren’t there already a lot of other proprietary module vendors out there already and this is what the “Tainted Kernel” warning is for? Obviously VMWare doesn’t expect people to contact the lkml when there is a problem with their ESX server, and they provide support for the product they are selling. If this means that any proprietary module vendor who develops for Linux first is in legal trouble, then it seems odd that VMWare would be the first target when there are probably more clear-cut cases.
Ed: The quote you’ve posted does not mention vmkernel at all. I have no idea whether vmkernel existed on another kernel prior to Linux. Neither does anyone outside VMware, I imagine. VMware could indeed have a version of vmkernel that’s started by BSD, DOS, a bootloader - however the only version we know about is the one that requires Linux. The issue of other binary drivers that exist on Linux has been covered in the article.
August 19th, 2007 20:34
“It’s also very interesting to note that ESX server as a whole can be fairly easily crashed from the linux side. The place where I work has a driver that gets loaded into the linux kernel and we were able to take down the entire ESX by writing into memory above where the vmkernel said it had loaded.
If the console is actually virtualized, it shouldn’t be able to crash the entire machine.”
This statement is of MAJOR importance and bears repeating. So I did.
Ed:Although the article above has been solely concerned with the Linux requirement to start vmkernel (rather than that happens once it has started), if you’re interested what you’ve written above (and have a spare ESX system, which I do not), Linux has a module called ‘crash’ that crashes the kernel. If you compile it within the service console, assign some other hardware to vmkernel via vmkpcidivy, an then install the module into memory on the Service Console, the Service Console assigned hardware should continue functioning as vmkernel keeps running.
August 20th, 2007 04:05
” If VMware had used a partition boot sector to boot vmkernel they would have no issue. Software started from a partition boot sector could be started from any bootloader”
In point of fact, on a Linux system booted by Grub, the software started from, and resident in, the boot sector is Grub, not Linux (Linux lives in /boot, where Grub finds it by reading a .conf file from inside the Linux filesystem). This is the O/S specific piece of Grub that has been mentioned by others but ignored by the Editor. This makes neither piece of software a derived work of the other.
Someone has a Linux version running inside WinXP as a device driver - does this make XP a derivative of Linux? Or Linux a derivative of XP?
The NDIS wrapper exists solely to allow other, presumably copyrighted, proprietary drivers to run on the Linux kernel - does this cause any GPL angst among anyone?
Zach has told us that vmkernel is not linked against the kernel, and is in no way a derived work. The assertion that loading it with a boot-loader of whatever description somehow makes it a derived work is really too ludicrous to contemplate. Repeating the ludicrous does not make it true.
So, now lets consider the service-console kernel hosting administrative applications for the vmkernel. As no-one has managed to dispute yet, writing a Linux application does not constitute the creation of a derived work. Now, since the boot-kernel environment is the administrative interface for the vmkernel, we could posit that it is a “trusted” environment. Let’s say one of the admin apps set values in a shared memory space to configure or otherwise control the VM world. Would all those who understand programming who think that writing wild data to such a region (say, by using a loaded driver to write outside allocated memory) might cause a VM crash please raise their hand. Thanks.
Feel free to perform experiments where abusing the service console crashes the VM, but ask yourself if you aren’t just testing the limits of how far the VM trusts its own administrative console to not do silly things instead of proving anything about the copyright status of the code…
Ed: I am well aware of Grub Stage 2. However Linux is not the only OS that can be started by Grub, and most common non-Linux OS are started via chainloading. Using a PBS (rather than having special boot support) would be the simplest way for vmkernel to start without requiring a Linux kernel. The fact that Grub has some Linux specific support - eg the ability to provide kernel parameters - does not mean that Linux can not only be started by Grub. This is one reason Linux can not be considered derived from Grub. Likewise, the existing of a Windows module is also irrelevant for the same reason - Linux can be started by other means and does depend on Windows. This is one reason Linux can not be considered a derived work of Windows.
Zach Amsden can see no reason why binary blobs that can only be loaded via Linux kernel modules are considered derived works. Linus Torvalds believes that such works (unless ported from another OS) clearly are derived works. Zach has not explained why he considers Linus’ logic does not apply to VMware. Believe who you wish.
Re: crashing the service console - indeed, this may be merely a test of how well VMware virtualises the service console, rather than proving any dependency. As noted above, I’m not particularly interested in this area. The more interesting matter is how vmkernel is loaded, not what it does afterwards.
August 20th, 2007 09:47
| First, the vmkernel, just like any other kernel is free to run and load any |other object code it desires.
Actually its not. Instead you may end up with something that cannot be distributed. The legal views I’ve seen would seem to favour the view that combining GPL driver code with a proprietary OS core creates a product which must meet the GPL, and if it cannot meet the GPL cannot be distributed at all. The book analogy here is buying a copy of a book, cutting out a chapter, inserting a different version you produced and selling it. Even if you have permission to make copies of both works and sell them, you need other explicit permissions to combine them in this manner. Compare with selling the two books together as a bundle and you start to see the question about what the line is and how it is to be drawn.
The Windows analogy used is also wrong. Creating a from scratch “GPL” work expressly for use on Windows regardless of the license would be held by the court to include implied permission to use that work with Windows without relicencing Windows as it was a) clearly the intention of the author to permit its use with windows b) clearly not in the power or intention of the parties to try and relicence windows.
Civil law in general deals not with word for word dissections but intent. It primarily exists to sort out the mess caused by people reading the same agreements differently or being unclear in what they specified. That requires the court looks at what is and is not permissible in law, then at the intent of the parties, and in some cases also with reference to caselaw so that a question that has been decided need not be reconsidered - and thus to create certainty about interpretation and avoid more cases. In the ideal legal world disputes get as far as a lawyer and one sides lawyer says “Well this was decided in foo v bar, shut up and pay them”
Caselaw on free software, combinations of software, linking and dependancies through linking or even across networks between modules talking over network links is quite limited currently however. What caselaw there is for the GPL generally deals with blatant abuses as those have been the kind that have gotten to court.
While I disagree on some points with Zachary I have no view and insufficient information to form an accurate opinion upon whether VMware is violating any of my copyrights, naturally I reserve my rights to take appropriate action if they should turn out to be.
August 23rd, 2007 00:20
If vmkernel truly does not need Linux, why can’t you start vmkernel by using a userspace process, for example copying it to a previously secured (allocated) region of /dev/mem (maybe with the help of a GPL kernel module) and then jump to it using kexec?
August 24th, 2007 02:05
“can be considered a derived work of Linux.”
That’s the wrong question to ask because it implies that licenses can only put restrictions on derived works. In fact, the GPL on Linux could require any user of the software to call their pet poodle (if any) “Sugar”, even though the poodle isn’t a derived work of the Linux kernel. Microsoft’s licenses require you to hand over multiple slips of green paper even though those papers aren’t derived works. Licenses can, and usually do, impose obligations on you that extend beyond derivative works. In fact, many licenses don’t even permit derivative works.
If VMware distributes the ESX kernel with Linux and that distribution isn’t “mere aggregation”, it may violate the terms of the GPL, even if the ESX kernel isn’t a derived work of the Linux kernel.
August 24th, 2007 02:14
“It is an enormous stretch to suggest that using the interfaces another work provides makes one work “based upon” and “recast, transformed, or adapted” from the first. There is no legal precedent. The consequences would be ridiculous.”
That’s true but irrelevant. A software license can very much say “if you copy software K and then use K’s interfaces in your software, your must do X”, for any “X”, including “you must license your software under the GPL”. Whether your software is a derivative work or not doesn’t matter.
So, you are free to write software that uses the interfaces that K provides without any obligation whatsoever. But as soon as you distribute K yourself, you are bound by K’s license terms, and those license terms can restrict the way in which you use K’s interfaces.
Concretely, VMware can distribute ESX with Linux interfaces with no problems and no obligation to GPL ESX. But as soon as they distribute Linux (as they do), they accept the terms of the GPL for Linux, and that might require them to place ESX under the GPL as well.
August 24th, 2007 13:32
Nice Article! I think everyone involved with Linux can clearly see that the Linux instance (based on Red Hat) is not virtualized and it loads vmkernel and then runs VMware service console. But putting all the facts together is really a great deal.
What about Checkpoint?
August 28th, 2007 23:48
– “But VMware explain there is a Linux kernel, but it’s only used to boot the other kernel. In this interview Michael DiPetrillo, VMware’s Senior Systems Engineer, states at 4:44 ‘In the 2.xs (the Service Console) was home to a reasonably large number of things, bootloader, it had it’s own networking‘.”
It would be nice if you quoted the entire conversation instead of what was convenient for your article. That same conversation went on to say “In ESX 3.0 the Service Console is no longer the bootloader.” I guess that would have killed your pretty weak argument that you’re making here. I’ll simply refer you to two things:
1) Look at Zacahry Amsden’s post above. He lays it out pretty clearly for you.
2) Look at http://simos.stanford.edu to see the beginnings of vmkernel and you’ll see it wasn’t based on Linux but rather written from the ground up. That’s part of the research project that became VMware. Of course a little research on the history of the company would have shown you that.
One other minor correction.
DOS was still loaded into memory in NetWare. You could actually break out to it and run debugging commands. There were also many bugs associated with NetWare overwriting that memory space and abending the box. It didn’t happen very often but the bugs were there.
Hopefully you’ll do a little more research on your next article before you start spreading rumors and misinformation.
Ed: Changes in ESX 3 don’t restrospectively alter the fact that in ESX 2.5 vmkernel required Linux to run (making vmkernel as implemented in ESX 2.5 subject to the GPL). The article above already mentions the origins of ESX, but nobody from VMware, including either yourself or Zachary, has explicitly stated that vmkernel was ported from SimOS. If you would care to do so, please post here stating that explicitly, and I’d be happy to publish it.
September 12th, 2007 13:28
VMware ESX 3i anyone??
September 13th, 2007 21:34
In future that discussion might finish, since VMware announced a new ESX version, which will come without a service console anymore. That version just contains the vmkernel and would not violate any GPL’s anymore…
September 15th, 2007 03:11
Matt
September 13th, 2007 21:34
In future that discussion might finish, since VMware announced a new ESX version, which will come without a service console anymore. That version just contains the vmkernel and would not violate any GPL’s anymore…
Exactly, it called VMWare ESX 3i, shipping now as an embedded product in servers of the likes of Dell, IBM, HP and Fujitsu and which will be included in the upcoming Infrastructure 3.5 product. So I guess the question regarding ESX’s hability to run without the COS has been answered.
September 28th, 2007 06:52
Thanks for the great article. Apparently some people are nervous about this - I have no other explanation for the agressive style of some postings trying to dismiss the GPL claims.
I have been wondering for years why vmkernel was hardly ever discussed while there was an endless debate over NVidia and ATI drivers. My personal guess is that VMware is more popular than other companies in the Linux community.
The discussion won’t finish with ESX 3.0 or future versions, even if they contain no single GPL’d component. VMware will have to justify what they did in 2.5, anyway.
October 18th, 2007 11:01
VMWare 3i may still be infringing by using GPL’d drivers er modules.
November 3rd, 2007 04:20
If the esx 3.5 kernel is *not* a linux kernel, why does this hack for using a megaraid sata controller with ESX work:
ESX only supports scsi, but the megaraid driver will support the sata controller too. However, the PCI verdor ID’s are not recognised in ESX. You install ESC (using an anaconda installer) and tell it to use the megairaid2 driver when is does not autodetect it. After this the installation will complete, but upon completion only the console os will run, not esx. You have to go in and add the vendor id to a file /etc/vmware/vmware-devices.map and add a line device,0×1000,0×0409,scsi,LSI Logic MegaRAID,megaraid2.o
My question: if the vmkernel is not linux, why do you need to tell it to use the magaraid2.o kernel module which clearly is a linux module?
November 3rd, 2007 04:22
You can find the details of this here:
http://www.run-virtual.com/?p=88
November 22nd, 2007 05:34
The logic on what makes a derivative work is precisely backwards. In reality, *functional* considerations argue *against* it being a derivative work.
Copyright protects the creative choice of one option out of millions of possible other options. Linus wrote Linux, but he could have written an OS millions of other ways. Shakespeare wrote Romeo and Juliet, out of the millions of possible stories of star-crossed lovers.
If you need hooks from the kernel, that’s clearly a purely functional consideration. That’s the part that’s *not* covered by copyright. The question is whether the work takes creative choices from the kernel, that is, where it could have done things millions of possible ways, it does things the way the kernel did rather than making its own creative choices.
If you’re going to make a Linux network driver, that’s functional. You can take whatever is needed for that function without implicating copyright.
See, for example, Lexmark v. Static Controls. Here Static Controls stole an entire program from Lexmark. But the courts held that copyright was not violated because they took only what was needed for their specific function, making a toner cartridge that was compatible with Lexmark printers.
Similarly, if vmware wants to make a module that works with Linux, they can take as much as they need to work with Linux. Copyright is only implicated when you take more than you need.
January 1st, 2008 01:18
VMware came out with ESX 3i that runs without Linux, which proves that Linux kernel is used for manageability only on the ESX 3.5 or older, and that vmkernel does not need Linux kernel to function.
Ed:As other posts have noted, while ESX 3i runs without Linux, it doesn’t fix the problem of past copyright issues, especially as that older software is still being distributed.
May 19th, 2008 23:40
Hmm … I’ll be writing a blog post about this on my site, to spread the word. I’ll quote you on some parts but of course I’ll be linking to this great article…. Open source matters !