Submitted by “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.”
“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.”
That’s just not possible and although they have an explanation for this, it sound like a load of crap.
Why would you want to run Linux as a boot loader? Even if you where to cut the kernel down to just what you needed, it would still outweigh GRUB by about a few hundred megabytes!
If VMWare can come up with a more detailed breakdown of what they need a Linux kernel for, great! Otherwise, this is clearly a derived work.
Alan Cox has a great post in this article
“Even if you where to cut the kernel down to just what you needed, it would still outweigh GRUB by about a few hundred megabytes!”
Huh????? And where do you get your information from?
Damn Small Linux (DSL) is only 50 MB. A Linux boot loader could be even smaller, if you cut out all the unnecessary stuff.
I find it extremely suspicious that these allegations regarding ESX were released the day before VMWare’s Initial Public Offering (IPO). It’s nothing more than a blatant attempt to manipulate the stock price. Talk about FUD!
Edited 2007-08-15 21:09
Whoops, forgot all about DSL, thanks for the heads up. Still, why would you want to run Linux as a boot loader when Linux itself needs a boot loader? Is it because certain devices need to be initialized before VMWare’s proprietary kernel is able to load? Seems a bit strange to me.
I didn’t figure with that and again, thanks for the heads up. It could very well be that this is an attempt to manipulate the stock price. It seems to me though that there is something funny going on trying to us one boot loader to load a kernel, then use that kernel to bootstrap another, entirely proprietary kernel, and then to claim that the third is not a derived work of the second.
Oh, you mean just like vmware’s statements earlier this week regarding OS’s becoming obsolete?
Two kernels simultaneously?
That’s essentially the heart of the matter. If it’s possible to have two kernels running simultaneously, then ESX could possibly be violating the GPL. But if there is only one kernel running at a time, then there is no solid case for copyright infringement.
The native bootloader boots a heavily-hacked Linux-2.4 kernel. Then userspace loads vmkmod, which I believe is under the GPL, into the kernel. This module then loads vmkernel, the proprietary hypervisor kernel, into memory and boots it.
So vmkernel isn’t really loaded into the Linux kernel per se. In this very low-level context, the notion of an address space is relatively vague. The code gets copied into memory that Linux sees as part of its kernel address space. But when this code begins to execute, it creates its own notion of the kernel address space.
For a brief, fleeting moment, vmkernel is a proprietary blob distributed with the Linux kernel and loaded into its address space. But it’s questionable whether any substantial portion of vmkernel executes in the Linux kernel’s address space before this address space ceases to exist.
Furthermore, it doesn’t appear that any of the vmkernel code depends on Linux kernel code at runtime. Sure, it depends on Linux to load and execute itself in an appropriate context, but does it actually depend on Linux while running? This is an important distinction given the language of the GPL.
I take a somewhat strict approach to non-GPL kernel modules. I don’t buy Linus’ position that it’s OK to distribute proprietary modules with the Linux kernel as long as the modules are ported from non-Linux systems. I think that these modules are only legal when distributed independently from the kernel. So I’m more aligned with Alan’s position.
However, it’s not clear that vmkernel is a Linux kernel module at all. It’s not clear that it shares an address space with the Linux kernel in any meaningful way. It’s not clear that it depends on Linux code at runtime.
I’m inclined to think that ESX is NOT violating the GPL with respect to its interaction with the Linux kernel. I’m also inclined to think that a legal battle on this situation would be fascinating. I’m finally inclined to believe that VMware would promptly settle any such suit.
Edited 2007-08-15 22:54
http://en.wikipedia.org/wiki/Vmware#VMware_ESX_Server
http://www.vi3book.com/esxatdg_ch2.pdf
After the Linux kernel has loaded, the S90vmware script loads the vmkernel. VMware states that vmkernel does not derive from Linux. The Linux kernel continues running but under vmkernel, providing functions including the proc file system used by the ESX and an environment to run support applications.
Do you know how long it would take to write a vmkernel from scratch? It would take one decent *NIX programmer about 2 months, give or take a few weeks.
But it might take even less to use the BSD vmkernel.
This rumor is FUD.
Uh? Trust me, writing a virtualization kernel that works properly on a reasonable variety of hardware is a non-trivial task that will take a team of engineers about a year. I don’t think the vmkernel depends much on linux, and it doesn’t derive from linux in a truly meaningful way. I personally think that this is a particularly stupid application of the GPL’s derivation clause, much like the way it’s applied in the TiVO situation.
Linux has two separate functions as far as ESX is concerned:
1. A trampoline to load the hypervisor, which is implemented as a Linux loadable module
2. Providing a management interface
Now, instead of making the bootloader load the ESX hypervisor, which is then responsible for ensuring that the Linux-based management console comes up properly (leaving very little recourse if something goes wrong, and no ability to log errors and so forth in the event of a problem, or provide a straightforward way to bring up the system without the hypervisor, tweak something, and then load it [or—and I don’t know if ESX can do this currently, but the implementation leaves room for it] shut down the hypervisor and the guests, perform some configuration, and start it all back up again remotely], VMware opted to boot Linux *first* and then load the hypervisor from within it—using the binary module interface as a means of getting the code into privileged space; in logical terms, when vmkernel is loaded, the Linux installation switches role from “bootloader” to “management console”.
Unless Linux has had—since the early days of ESX—some amazing chunk of supporting code that made the hypervisor possible when it somehow wasn’t otherwise, it’s highly unlikely that it’s a derived work. If demand was such that usage of Linux and FreeBSD was a straight 50/50 split, we’d probably see two editions of ESX, depending upon which OS you prefer to work with as the management console… but that is hypothetical, of course.
Half of the commenters here seems to be missing the real point: the author argues that the ESX “kernel” is just a kernel Linux module, and that if this module requires Linux, it is arguably a derived product.
You may agree or disagree that this is a violation of the GPL (which reflects the disagreement in interpretation of various kernel developers), but does not change what seems to happen technically. If the author is correct in this, it is (potentially) up to lawyers to analyze this situation.
Some short remarks on previous comments:
Why would you want to run Linux as a boot loader? Even if you where to cut the kernel down to just what you needed, it would still outweigh GRUB by about a few hundred megabytes!
$ du -k /boot/vmlinuz-2.6.21-2-686
1305 /boot/vmlinuz-2.6.21-2-686
What hundreds of megabytes?
Do you know how long it would take to write a vmkernel from scratch? It would take one decent *NIX programmer about 2 months, give or take a few weeks.
Right, maybe to program some basic kernel functionality. But not if you want good scheduling, good I/O, good MP support, and a huge collection of hardware drivers.
But it might take even less to use the BSD vmkernel.
Well, it would still be a high investment. Their current work is possibly highly tied to Linux, and rebasing to another system takes a lot of QA time. Still, it is possible, and even attractive license-wise.
“the author argues that the ESX “kernel” is just a kernel Linux module, and that if this module requires Linux, it is arguably a derived product.”
Uhm, what kind of argument is this? Isn’t it pretty obvious that a linux kernel module does require linux.
How is this different from nvidia kernel modules or any other binary modules?
A hypervisor doesn’t need any dependencies on Linux because hypervisor runs in its own address space.
It is a stand-alone machine code which doesn’t depend on any libraries etc. Now vmware might have code from Linux in their kernel but that would be too difficult to prove without code inspection.
They can also remove the Linux code as we talk (if any).
See, this is where the linux community divides itself…
Camp #1 says “You wrote this to hook into specific kernel functions, therefore it is a derived work”.
This of course amuses me, since if there were a stable kernel API (Or something approximating one), it would be harder to claim “derived work”.
Then there’s camp #2 that says “You wrote this app for linux, and it only runs on linux, therefore it’s a derived work”.
#2 is a fairly radical and strict interpretation of #1, and I’m not sure it would hold up in court.
This is of course, the same tactic(s) used by SCO in their attempts to prove that Linux is a derivative work of Dynix, which is a Unix license, therefore linux is a derivative work of Unix.
My personal opinion is that the issues of “viral GPL”, “derivative or not” and “GPLv3 – We don’t like your business” are the biggest reasons why even with Vista being disappointing, Microsoft isn’t going to lose much market share to linux.
It is this kind of garbage that will make people less and less likely to use Linux.
Here is where Linux should be very concerned. Right now the big problem is that Linux, and operating systems like FreeBSD have driver problems. FreeBSD is even worse off than Linux.
Though imagine the situation and it is coming where the base operating system is a virtual operating system and the virtual operating system provides all of the drivers. The operating system thus does not need to provide any driver, and operating systems like FreeBSD become REALLY interesting because there is no garbage GPL license issue.
I know for myself I could see myself dropping Linux like a hot-potato… It is not that I don’t like Linux, I just hate the freaken hassle of the GPL “facists.”
I know for myself I could see myself dropping Linux like a hot-potato… It is not that I don’t like Linux, I just hate the freaken hassle of the GPL “facists.”
It’s almost as if they want to screw things up. It also paints a really bad picture too: GPL isn’t about sharing code, it’s about taking code… or money… money’s good too.
This kind of stuff is so much worse than ANY Microsoft FUD campaign.
>>This kind of stuff is so much worse than ANY Microsoft FUD campaign.
I think with this, the Kon user desktop issue and a few other things that have been going around Microsoft is saying, “wow and all we have to do was NOTHING… To think we wasted all this money on campaigns…”
I know for myself I could see myself dropping Linux like a hot-potato… It is not that I don’t like Linux, I just hate the freaken hassle of the GPL “facists.”
You can like or dislike the GPL, but the people enforcing it are certainly not facists. Try to incorporate some proprietary code in your software without having a license to do so, and see how fast you will be sued for copyright infringement. At the very least, the people who hunt for GPL violations try to settle issues, rather than taking people to court at the first opportunity. If you use someone else’s code, abide by the license, or don’t use it.
A license is not worth anything if it is not enforced, be it the CDDL, GPL or BSD license.
Edited 2007-08-16 10:11
Do I dislike the GPL? Absolutely because of its viral aspect.
The GPL and its viral issue is something that scares the pants off of people. My bet is that the VMWare stuff is probably GPL compliant and there is nothing here to watch. BUT, in the mean time the GPL license folks get their panties in a knot.
I know if I were running a software shop I would put the X on GPL software in case some GPL folks came running after me.
And for each day folks keep yelling and screaming about potential license violations is a day that is not spent on improving Linux.
What viral issue? The GPL applies only to GPL code.
If some product uses GPL code, then you cannot distribute the GPL code part of that product as a closed binary.
The rest of the product is fine … it is only the GPL part that comes under the provisions of the GPL. (Take a look at what happened in the “Parallels” case if you doubt this).
That much should be obvious …
If you are so undisciplined as to take GPL code and try to put it into your proprietary product, then you deserve to have people coming after you.
If you were running a software shop, surely it isn’t too hard to just insist that your shop writes its own code?
Would you prefer your coders stole some Microsoft code and put it in your product? Do you believe you would be better off then?
I think yours is a truly silly arguement.
Edited 2007-08-17 02:13
I can understand that slashdot picked up on this story.
But please, osnews?
I always liked the more calm and technical background here. So why don’t we all take a few breath and then go back to work. Let the slashdot people fight the flamewar. If anything, we should discuss the obviously lack of a technical OS background in the article, not agains some GPL license issues.
-Bernhard
After you look at the installation and how similar it is from Redhat linux; have a look at “uname -a” for esx 3.0.(0,1,2) and you will see version 2.4.xx.ELxx
So linux derivative 100% with a lot of customization for performance. EL in the kernel is like RHEL EL used in their kernel naming.
VMWare would never be that big without linux and they have to admit it otherwise they should be banned from using linux code!
After you look at the installation and how similar it is from Redhat linux; have a look at “uname -a” for esx 3.0.(0,1,2) and you will see version 2.4.xx.ELxx
So linux derivative 100% with a lot of customization for performance
Truth is, it’s unclear how it works. However, keep in mind that ‘uname’ is running on the service console, not the VMkernel. No one has ever suggested that the service console is not a direct (centos style) rip of RHEL3.
It’s no secret that the ESX Service Console is based on RedHat 7.3 (at least ESX 2.x was). The service console just provides a means of starting and controlling the VM Kernel (which provides the hypervisor access and deals with the VM’s). The “linux isn’t grub” approach to the argument in the article seems odd. The Linux kernel brings some of the basic system stuff up and loads the VM kernel into kernel space. Isn’t this more or less the equivalent of writing a “program” that runs in kernelspace instead of userspace?
I doubt that there is much true reliance on the Linux kernel specifically- VMWare could probably just as easily port vmkernel to BSD or Solaris (and I wonder if they might if they get too much crap just because they chose to use Linux!). The article actually states VMWare was developed on an old non-linux OS, but that it is unclear whether vmkernel was ported or written from scratch, so I guess that is why they are raising such a big stink? Although at some point isn’t a complete rewrite when switching platforms just a very high-level port? (Still uses the concept but little/none of the original code)
This all seems very silly. I guess VMWare has gone for too long with an awesome product that in some way involves the GPL not to be the target of FUD from someone, and what better time to sling the mud than near their IPO. Look out, Apple, you’re next (OMG THEY USED GCC! GCC IS GPL’ed! The FSF is going to sue all Mac owners! Make sure you’re safe by only using proprietary software because its legal status is never in question!)