<dt>Can you explain further in words (rather than a picture) about the central

  component in ESXi that the lawsuit alleges violates the GPL?</dt>

<dd>

    <p>The GPL violation at issue involves VMware's ESXi product.

    Conservancy independently reviewed ESXi 5.5 and its incomplete

    release as part of our GPL enforcement efforts described above.</p>

    <p>Conservancy's preliminary investigation indicated that the operating

    system kernel of VMware ESXi product consists of three key components:

        <ul>

          <li> the proprietary component &ldquo;vmkernel&rdquo;, which is

            released in binary form only,</li>

            <li>the kernel module &ldquo;vmklinux&rdquo;, which contains modified Linux

            <li>other kernel modules with device drivers, most of which are

            modified Linux drivers, and for which (at least some) source code

              is provided.</li>

        </ul>

    <p>Conservancy examined the incomplete CCS alongside the

           in “vmkernel” do make function calls to Linux's kernel code

      in the usual way for a single program written in C.</p></dd>

    <dt>Doesn't VMware's &ldquo;shim layer&rdquo; insulate them from GPL

    obligations and allow them to keep certain code in their kernel

    proprietary?</dt>

       <h4>Example of &ldquo;vmkernel&rdquo;'s combination with Linux code</h4>

       <p>As one example, examine the file

           called <code>vmkdrivers/src_92/vmklinux_92/vmware/linux_pci.c</code>,

           which can be found in the “Open Source” release for

           ESXi 5.5.0 Update 2 (5.5U2).  A small excerpt from that file, found in the

<pre>

if (unlikely(

  /* NOTE: vmk_PCIGetDeviceName is defined in vmvisor64-vmkernel */

  vmk_PCIGetDeviceName(vmkDev, vmkDevName, sizeof(vmkDevName)-1) != VMK_OK))

{

    vmkDevName[0] = 0;

[...]

/* VMKAPI_MODULE_CALL_VOID is a macro calling driver's remove() here */

VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,

                        linuxDev->driver->remove,

                        linuxDev);

</pre>        

<p>The function, <code>vmk_PCIGetDeviceName()</code> must be defined, with an

      implementation, for this code above to work, or even compile.

      Inside <code>BLD/build/HEADERS/vmkapi-current-all-public/vmkernel64/release/device/vmkapi_pci_incompat.h</code>,

      found in the <code>vmkdrivers</code> package of ESXi 5.5U2, shows a

      function header definition for <code>vmk_PCIGetDeviceName()</code>.

      However, the source of its implementation is not provided there or

      anywhere in the source release.</p>

<p>Further evidence that the implementation of this function occurs elsewhere

  can by found by running <code>objdump -x</code> on the un-vmtar'ed

  <code>vmklinux_9</code> module.  Note the following output in the &ldquo;SYMBOL

<pre>

0000000000000000         *UND*  0000000000000000 vmk_PCIGetDeviceName

</pre>

…and the following lines found in the  “RELOCATION RECORDS FOR

[.text]” section:

<pre>

00000000000327ff R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc

0000000000035318 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc

00000000000387e1 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc

000000000003cf40 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc

</pre>

<p>The above two properties both suggest that the <code>vmklinux_9</code>

 module requires: (a) a definition of the <code>vmk_PCIGetDeviceName()</code>

 function to operate, but (b) that function is not defined

 inside <code>vmklinux_9</code> itself.</p>

  in the ESXi 5.5U2 installer ISO image).  Running <code>file</code>

  after <code>gunzip</code> on this file yields &ldquo;ELF 64-bit LSB shared

  object&rdquo;.  Meanwhile, <code>file k.b00</code> reports &ldquo;gzip

  compressed data, was ‘vmvisor64-vmkernel.stripped’”.

  These findings strongly suggests this is an image of the

  &ldquo;vmkernel&rdquo; component.  An <code>objdump -x</code> yields this

<pre>

000041800036a408 g     F .text  0000000000000137 vmk_PCIGetDeviceName

</pre>

for  <code>vmk_PCIGetDeviceName</code>.</p>

<p>Finally, after detailed searching, Conservancy found no evidence that any

  other code (other than modified Linux code) makes calls

  to <code>vmk_PCIGetDeviceName</code>.  This provides a strong indication

  that this function's primary purpose is to combine Linux code with

  “vmkernel”.  Conservancy also found other functions where similar analysis

  yields similar results as above.</p>

<p>Given this evidence and related contextual clues, the only logical

    <ul><li><code>vmklinux_9</code>, as a binary object, dynamically links

 with <code>k.b00</code>, another binary object, to form a single running

 binary.</li>

      <li>That binary contains code licensed under the GPLv2, and can be

       distributed in binary form only under permissions provided under

        GPLv2 &mdash; in particular <a href="https://gnu.org/licenses/gpl-2.0.html#section2">GPLv2&sect;2</a> and <a href="https://gnu.org/licenses/gpl-2.0.html#section3">GPLv2&sect;3</a>.</li>

      <li>VMware did not provide source code for any modules found in

        <code>k.b00</code>.</li>

      <li>Therefore, VMware failed to comply with the GPLv2, as such

      compliance requires source code (or an offer therefor) for the material

        in <code>k.b00</code>.</li>

    </ul>

<p>The above is but one piece of evidence among many, but hopefully it helps

  to explain the types of “combined work” violations found in

  VMware's ESXi product.</p>

<dt id="verify">How can I verify Conservancy's technical findings above?</dt>

<dd><p>The binary and source packages mentioned above are available

on VMware's website.  These packages contain the

previously-mentioned <code>linux_pci.c</code>,

<code>vmkapi_pci_incompat.h</code>, and <code>k.b00</code> files, as well as

    <code>vmklinux_9</code> and the source code that builds the latter.</p>

<ol>

<li>Visit <a href="https://my.vmware.com/web/vmware/details?downloadGroup=ESXI55U2_OSS&productId=353">https://my.vmware.com/web/vmware/details?downloadGroup=ESXI55U2_OSS&productId=353</a>.</li>

<li>Click the &ldquo;Download&rdquo; button beside the text that reads

&ldquo;Open Source Code for VMware vSphere ESXi 5.5 Update 2&rdquo;.</li>

  vSphere ESXi 5.5.0 Update 2” file from the above download page to

  complete the build — upon downloading you will find it is named

  <code>VMware-TOOLCHAIN-550u2-ODP.iso</code> and has a SHA-1 hash of

  f679e81ffb2f92729917bbc64c2d541cf75b5b94.</li>

</ol>

<ol>

<li>Register for an account at <a href="https://my.vmware.com/web/vmware/registration">https://my.vmware.com/web/vmware/registration</a>.</li>

<li>Click the &ldquo;Activate Now&rdquo; link in the follow-up email.  Enter

  the password used at registration time.  Click &ldquo;Continue&rdquo;.</li>

available when logged into an ESXi system. <code>vmtar</code> can be found

at <code>bin/vmtar</code> inside

<code>sb.v00</code> on the ISO, but one needs <code>vmtar</code> to open

<code>sb.v00</code>, similar to <code>misc_dri.v00</code> above.</li>

</ol>

  software from VMware's website.  Conservancy strongly suggests that you review these

  terms in great detail with the assistance of your own legal counsel before

  downloading the software and/or engaging in the process that Conservancy

  discusses above.</p>

  <dt>Have others issued statements of support about this action?</dt>