1 2 Previous Next 17 Replies Latest reply: Aug 18, 2007 4:39 AM by devzero Go to original post RSS
      • 15. Re: ESX /VMKernel violating the GPL?
        kingneutron Master

        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.

        • 16. Re: ESX /VMKernel violating the GPL?
          devzero Master

          >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.......

          • 17. Re: ESX /VMKernel violating the GPL?
            devzero Master

            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.



            1 2 Previous Next