VMware Cloud Community
peetz
Leadership
Leadership

ESX /VMKernel violating the GPL?

Have you guys read this?:

The VMware house of cards[/url]

It's an article about a Linux kernel developer claiming that VMware is violating Linux copyrights with its ESX product. It talks about the VMKernel, not the service console that is - of course - Linux-based like we all know.

I wonder what the gurus here think. Is it just FUD or something that VMware should really worry about?

\- Andreas

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
Reply
0 Kudos
17 Replies
sgunelius
Hot Shot
Hot Shot

I read the article and while I can't claim to be a guru, I don't think VMware in their right mind, with the engineering talent they have on staff, would put themselves at risk like this. They've always seemed above board to me in my dealings with them as a customer. I think that in light of the IPO, this guy's just trying to rain on their parade. My two cents...Anyone from guruville care to comment?

Reply
0 Kudos
kix1979
Immortal
Immortal

FUD! They have their GPL source code modifications on the vmware.com website for people to download. The kernel is proprietary, but someone would have to pull a SCO on them to find out for sure, but again I don't think there is anything to worry about. Everything I have seen in the source code looks fine to me Smiley Wink

Thomas H. Bryant III
Reply
0 Kudos
dpomeroy
Champion
Champion

I think this is written by someone who doesn't have an intimate knowledge of how ESX 3 works.

There are some in the Linux community that dont like VMware because of it using Linux but then also have a close source kernel. Sounds like FUD to me.

Reply
0 Kudos
devzero
Expert
Expert

>Sounds like FUD to me.

i don`t think this is FUD, at least i think it isn`t Mr. Hellwigs intention to spread FUD.

Anyway - you cannot deny that VMWare ESX is a derived work from the Linux kernel, can you ?

Rip off all the Linux out of ESX and look what you have then......

Reply
0 Kudos
peetz
Leadership
Leadership

One day VMware will remove the service console from ESX putting all of its functionality in a VMKernel user world and have the VMKernel boot directly on the iron.

I don't know when this will happen, but I know that it will happen and that it is not a big deal.

\- Andreas

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
Reply
0 Kudos
devzero
Expert
Expert

not a big deal?

what about drivers ? Smiley Wink

Reply
0 Kudos
peetz
Leadership
Leadership

Drivers? They are in the VMKernel already.

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
Reply
0 Kudos
devzero
Expert
Expert

an extract of the GPLv2:

2. You may modify your copy or copies of the Program or any portion

of it, thus forming a work based on the Program, and copy and

distribute such modifications or work under the terms of Section 1

above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices

stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in

whole or in part contains or is derived from the Program or any

part thereof, to be licensed as a whole at no charge to all third

parties under the terms of this License.

afaik, proprietary and closed source vmkernel loads gpl`ed and modified linux drivers. i`m no lawyer and but this sounds "problematic" to me.

Reply
0 Kudos
peetz
Leadership
Leadership

How do you know that the VMkernel device drivers are just modified Linux device drivers? Have you seen their source code?

If this was really true it would be very easy for VMware to support all the hardware that the Linux kernel supports today. But it is not.

For SAN HBAs e.g. VMware wrote a lot of proprietary[/i] code to properly handle multi-pathing and failover, code that has not existed before.

Twitter: @VFrontDe, @ESXiPatches | https://esxi-patches.v-front.de | https://vibsdepot.v-front.de
Reply
0 Kudos
devzero
Expert
Expert

Reply
0 Kudos
nailer
Contributor
Contributor

I think most people in this forum don't seem to have read the article - witness the pasting of the source code to VMware's Linux kernel. As the article mentions, the source code in question is for vmkernel, not the Linux kernel modifications. There's been no technical response to any of the questions raised by the article (which cites publications recommended by VMware) in this forum (which I'm a little disappointed with really).

To summarize: vmkernel is loaded by a vmkmod, and constitutes what's referred to as a binary blob by most Linux kernel developers. Such things, unless they have been ported from another OS, are considered derived works of the Linux kernel, as they cannot function without a Linux kernel.

Ie, attempt to start vmkernel without Linux.

As mentioned in TFA, this is a long running issue VMware have known about for nearly a year.

Reply
0 Kudos
JDLangdon
Expert
Expert

Rip off all the Linux out of ESX and look what you

have then......

ESX Lite Smiley Wink

Jason

Reply
0 Kudos
ORRuss
Enthusiast
Enthusiast

Uh-oh. This made the top line of el Reg.

http://www.theregister.co.uk/2007/08/16/vmware_derived_from_linux/

When will VMWare respond?

Times like these they are happy to have EMC legal behind them. Smiley Wink

orRuss

Reply
0 Kudos
devzero
Expert
Expert

>ESX Lite Smiley Wink

you`re kidding ! Smiley Wink

Reply
0 Kudos
kingneutron
Expert
Expert

I saw the article 1sthand when it hit Slashdot, but wasn't going to post it here.

This is one reason why Vmware would arguably be better served by migrating their tech to run on *BSD.

./. If you have appreciated my response, please remember to apply Helpful/Correct points. TIA
Reply
0 Kudos
devzero
Expert
Expert

>This is one reason why Vmware would arguably be better served by

>migrating their tech to run on *BSD.

why that difficult ?

they could talk about this first, give an official statement, be nice to the linux community, contribute - whatever.......

Reply
0 Kudos
devzero
Expert
Expert

at http://www.venturecake.com/the-vmware-house-of-cards/ , Zachary Amsden just gave a nice and very long reply:

Zachary Amsden

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

Reply
0 Kudos