File diff 8ea1abb31ecd → 1081bd358292
www/conservancy/static/copyleft-compliance/vmware-lawsuit-faq.html
Show inline comments
...
 
@@ -158,49 +158,49 @@
 
  their kernel?</dt>
 

	
 
  <dd>
 
  <p id="diagram">
 
    Conservancy prepared this diagram to show the technical situation as we
 
    understand it.  The diagram compares the technical architecture of a full,
 
    running Linux kernel with a full, running VMware kernel:
 
    <p>
 
      <a href="/copyleft-compliance/linux-vs-vmkernel_en.png">
 
    <img class="inside-faq" alt="[Diagram of Linux and VMware running kernels]" src="/copyleft-compliance/linux-vs-vmkernel_en_scaled.png" /></a>
 
    </p>
 

	
 
    <p>If you want to download the diagram, it's available
 
    in <a href="/copyleft-compliance/linux-vs-vmkernel_en.svg">SVG
 
    (English)</a>, <a href="/copyleft-compliance/linux-vs-vmkernel_en.png">PNG
 
    (English)</a>, <a href="/copyleft-compliance/linux-vs-vmkernel_de.svg">SVG
 
    (German)</a>, and <a href="/copyleft-compliance/linux-vs-vmkernel_de.png">PNG
 
    (German)</a>.</p>
 
  </dd>
 

	
 
  <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
 
    Conservancy independently reviewed ESXi and its incomplete
 
      <abbr title="complete, corresponding source">CCS</abbr>
 
    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
 
Code, and for which (at least some) source code is provided.
 
            <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
 
           binary &ldquo;vmkernel&rdquo; component.  Such examination indicates that functions
 
           in &ldquo;vmkernel&rdquo; 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>
 

	
...
 
@@ -222,350 +222,353 @@ Code, and for which (at least some) source code is provided.
 
    modifications to &ldquo;vmkernel&rdquo; in a tightly coupled manner.</p>
 
    </dd>
 
   <dt id="shim-meaningless">Is Conservancy proposing a &ldquo;shim
 
      layer&rdquo; as a viable solution for GPL compliance?</dt>
 

	
 
    <dd>No, in fact, as we say above, Conservancy doesn't think the phrase
 
        &ldquo;shim layer&rdquo; has any meaning, despite regular use of that
 
        phrase in the media.  Conservancy generally doubts there is any
 
        technological manipulation that changes the outcome of a
 
        combined/derivative work analysis.</dd>
 

	
 
    <dt id="example">Can you give a <em>specific</em> example, with code, showing how
 
    VMware combined Linux source code with their binary-only components?</dt>
 

	
 
     <dd><p>There are numerous examples available that show this.  The
 
       details of alleged infringement specifically relating to Hellwig's
 
       contributions to Linux are of course the main matter of the
 
       allegations in the litigation, and Conservancy
 
       released <a href="#diagram">the diagram above</a> to exemplify that
 
       issue.  Conservancy continues to <a href="#court-documents">hope VMware will
 
       agree to make public all court documents</a> as a matter of public
 
       good, since the court documents discuss the specifics of alleged
 
         infringement on Hellwig's copyrights.</p>
 

	
 
       <p>However, Conservancy examined VMware's ESXi 5.5 product in detail
 
       <p>However, Conservancy examined VMware's ESXi product in detail
 
       even before Hellwig's enforcement action began.  Below is one example
 
       among many where VMware's CCS was incomplete per GPLv2&sect;2(c) and
 
       GPLv2&sect;3(a).  (One can verify these results by
 
       <a href="#verify">downloading and installing the binary and source
 
       packages for VMware's ESXi 5.5 Update 2</a>.)  Note that this
 
       packages for VMware's ESXi 6.0</a>.)  Note that this
 
       example below is not necessarily regarding
 
       Hellwig's copyrights; VMware incorporated Linux code copyrighted by
 
       many others as well into their kernel.</p>
 

	
 
       <h3>Example of &ldquo;vmkernel&rdquo;'s combination with Linux code</h3>
 
       <p>Our example begins with examination of the file
 
           called <code>vmkdrivers/src_92/vmklinux_92/vmware/linux_pci.c</code>,
 
           which can be found in the &ldquo;Open Source&rdquo; release for
 
           ESXi 5.5.0 Update 2 (5.5U2).  A small excerpt from that file, found in the
 
           ESXi 6.0.  A small excerpt from that file, found in the
 
           function <code>LinuxPCIDeviceRemoved()</code>, reads as follows:</p>
 

	
 
<pre>
 
#include &lt;linux/pci.h&gt;
 
[...]
 
/*
 
 * This function [...] is modelled after pci_remove_device, the function which would
 
 * be called in a linux system.
 
 */
 
static void
 
LinuxPCIDeviceRemoved(vmk_PCIDevice vmkDev)
 
{
 
   LinuxPCIDevExt *pciDevExt;
 
   struct pci_dev *linuxDev;
 
[...]
 
  if (unlikely(
 
    vmk_PCIGetDeviceName(vmkDev, vmkDevName, sizeof(vmkDevName)-1) != VMK_OK))
 
  {
 
      vmkDevName[0] = 0;
 
  }
 
[...]
 
VMKAPI_MODULE_CALL_VOID(pciDevExt->moduleID,
 
                        linuxDev->driver->remove,
 
VMKAPI_MODULE_CALL_VOID(pciDevExt-&gt;moduleID,
 
                        linuxDev-&gt;driver-&gt;remove,
 
                        linuxDev);
 
</pre>        
 

	
 
<h4>Combination of &ldquo;vmkernel&rdquo; code with &ldquo;vmkdrivers&rdquo;</h4>
 

	
 
<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
 
      Inside <code>BLD/build/HEADERS/vmkapi-current-all-public/generic/release/hardware/vmkapi_pci_incompat.h</code>,
 
      found in the <code>vmkdrivers</code> package of ESXi 6.0, 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
 
  TABLE&rdquo; section:</p>
 

	
 
<pre>
 
0000000000000000         *UND*  0000000000000000 vmk_PCIGetDeviceName
 
</pre>
 

	
 
<p>
 
&hellip;and the following lines found in the  &ldquo;RELOCATION RECORDS FOR
 
[.text]&rdquo; section:
 
</p>
 

	
 
<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
 
0000000000032db3 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc
 
00000000000333ea R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc
 
0000000000036644 R_X86_64_PC32     vmk_PCIGetDeviceName+0xfffffffffffffffc
 
000000000003986a 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>
 

	
 
<p>The definition can however be found in binary-only software provided in
 
  ESXi 5.5U2 &mdash; specifically, inside a file named <code>k.b00</code>,
 
  ESXi 6.0 &mdash; specifically, inside a file named <code>k.b00</code>,
 
  which is located in partition 5 on a disk where ESXi has been installed (or
 
  in the ESXi 5.5U2 installer ISO image).  Running <code>file</code>
 
  in the ESXi 6.0 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 &lsquo;vmvisor64-vmkernel.stripped&rsquo;&rdquo;.
 
  These findings strongly suggests this is an image of the
 
  &ldquo;vmkernel&rdquo; component.  An <code>objdump -x</code> yields this
 
  &ldquo;SYMBOL TABLE&rdquo; section:</p>
 

	
 
<pre>
 
000041800036a408 g     F .text  0000000000000137 vmk_PCIGetDeviceName
 
000041800033193c g     F .text  000000000000012e vmk_PCIGetDeviceName
 
</pre>
 

	
 
<p>&hellip; which indicated these binary file contains the function body
 
for  <code>vmk_PCIGetDeviceName</code>.</p>
 

	
 
<p>Furthermore, 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
 
  &ldquo;vmkernel&rdquo;.  Conservancy also found other functions where similar analysis
 
  yields similar results as above.</p>
 

	
 
<h4>Linux's <code>struct pci</code> combined with <code>LinuxPCIDeviceRemoved()</code></h4>
 

	
 
<p>Having established the direct and close combination
 
  of <code>vmk_PCIGetDeviceName</code>
 
  and <code>LinuxPCIDeviceRemoved()</code>,  focus now on the
 
  quoted code from <code>LinuxPCIDeviceRemoved()</code>.  That code, note
 
  that one of the local variables is <code>struct pci_dev *linuxDev;</code>.
 
  A definition of <code>pci_dev</code> is found in
 
  <code>vmkdrivers/src_92/include/linux/pci.h</code> (which
 
  is <code>#include</code>'d above) reads:</p>
 

	
 
  <pre>
 
struct pci_dev {
 
[...]
 
#if defined(__VMKLNX__)
 
        /* 2008: Update from Linux source */
 
        u8              revision;       /* PCI revision, low byte of class word */
 
#endif /* defined(__VMKLNX__) */
 
[...]
 
       struct pci_driver *driver;      /* which driver has allocated this device */
 
[...]
 
truct pci_driver {
 
struct pci_driver {
 
        struct list_head node;
 
        char *name;
 
[...]
 
        void (*remove) (struct pci_dev *dev);   /* Device removed (NULL if not a hot-plug capable driver) */
 
[...]
 
#if defined(__VMKLNX__)
 
        /* 2008: Update from Linux source */
 
        u8              revision;       /* PCI revision, low byte of class word */
 
#endif /* defined(__VMKLNX__) */
 
  };
 
</pre>
 

	
 
<p>These structures, and based on those from Linux itself
 
  (<a href="http://lxr.free-electrons.com/source/include/linux/pci.h?v=2.6.24">a
 
    similar version of this file can be seen in Linux 2.6.24</a>), and as can
 
  be seen above, have been modified to work with &ldquo;vmkernel&rdquo;</p>
 
  be seen above, have been modified to work with &ldquo;vmkernel&rdquo;.</p>
 

	
 
<p>In <code>LinuxPCIDeviceRemoved()</code>, we saw a macro called with a
 
  variable, <code>linuxDev</code> which was of type <code>struct pci</code>.
 
  Thus, the combination of code from Linux's <code>pci.h</code>
 
  and VMware's <code>vmware/linux_pci.c</code> is very tightly coupled and
 
  interdependent.</p>
 

	
 
<h4><code>VMKAPI_MODULE_CALL_VOID</code> macro calls driver's code</h4>
 

	
 
<p>The
 
  file <code>BLD/build/HEADERS/vmkapi-current-all-public/vmkernel64/release/base/vmkapi_module.h</code>
 
  file <code>BLD/build/HEADERS/vmkapi-current-all-public/generic/release/base/vmkapi_module.h</code>
 
  contains the macro definition of  <code>VMKAPI_MODULE_CALL_VOID</code>,
 
  which is quoted below (with debug lines removed):
 
<pre>
 
#define VMKAPI_MODULE_CALL_VOID(moduleID, function, args...)  \
 
do {                                                    \
 
    vmk_ModInfoStack modStack;                          \
 
    vmk_ModulePushId(moduleID, function, &amp;modStack);    \
 
    (function)(args);                                   \
 
    )                                                   \
 
    vmk_ModulePopId();                                  \
 
} while(0)
 
</pre>
 

	
 
<p>When the macro is expanded, it means that <code>(function)(args)</code> is
 
  actually expanded to <code>linuxDev->driver->remove(linuxDev)</code>.
 
  Therefore, we see <code>LinuxPCIDeviceRemoved()</code>, makes directs calls
 
  actually expanded to <code>linuxDev-&gt;driver-&gt;remove(linuxDev)</code>.
 
  Therefore, we see <code>LinuxPCIDeviceRemoved()</code> makes directs calls
 
  to a driver's remove() function, by combining with Linux's <code>struct
 
  pci</code>, and by VMware's introduction of this new calling code.
 
  Conservancy has confirmed many drivers from Linux are incorporated via
 
  these mechanisms; one specific example is discussed next.</p>
 

	
 
<h4>Combination of the tg3 driver with &ldquo;vmkernel&rdquo;</h4>
 

	
 
<p>VMware includes a file <code>vmkdrivers/src_9/drivers/net/tg3/tg3.c</code>
 
  in their source release.  This file appears to be Linux's tg3 driver.  It
 
  includes a definition of the <code>struct pci_dev</code> for this device,
 
  which reads:</p>
 

	
 
<pre>
 
static struct pci_driver tg3_driver = {
 
[...]
 
        .remove         = __devexit_p(tg3_remove_one),
 
</pre>
 

	
 
<p>Therefore, when the code in <code>LinuxPCIDeviceRemoved()</code>
 
  calls <code>linuxDev->driver->remove(linuxDev)</code>, the code ultimately
 
  called (in the case where a tg3 card is driven by the kernel)
 
  calls <code>linuxDev-&gt;driver-&gt;remove(linuxDev)</code>, the code
 
  ultimately called (in the case where a tg3 card is driven by the kernel)
 
  is <code>tg3_remove_one()</code>, which is found in <code>tg3.c</code> and
 
  comes directly from Linux.</p>
 

	
 
<p>(Note: <code>__devexit_p</code> is a straightforward macro found
 
  in <code>vmkdrivers/src_92/include/linux/init.h</code> (which also comes
 
  from Linux) that will simply expand to its first argument in this
 
  case.)</p>
 

	
 
<h4>VMware distribution of binary version of <code>tg3.c</code></h4>
 

	
 
<p>VMware furthermore distributes a modified version of <code>tg.c</code> in
 
<p>VMware furthermore distributes a modified version of <code>tg3.c</code> in
 
  binary form.  This can be found in <code>usr/lib/vmware/vmkmod/tg3</code>,
 
  which is extracted by un-vmtar'ing the file <code>net_tg3.v00</code> (found
 
  on the ESXi 5.5U2 installer ISO image).  Conservancy has confirmed that
 
  file is a compiled version of <code>tg3.c</code></p>
 
  on the ESXi 6.0 installer ISO image).  Conservancy has confirmed that
 
  file is a compiled version of <code>tg3.c</code>.</p>
 

	
 
<h4>Conclusions</h4>
 

	
 
<p>Given this evidence and related contextual clues, the only logical
 
  conclusions are:</p>
 
    <ul><li><code>vmklinux_9</code>, a binary object, dynamically links with
 
        the binary objects: <code>k.b00</code> and <code>tg3</code> (the
 
        driver built from <code>tg3.c</code>'s source).  These three binary
 
        objects together form a single running binary (likely along with many
 
        other binary objects as well).</li>
 
      <li>That single running binary contains code licensed under the GPLv2
 
       &mdash; namely the code derived from <code>tg3.c</code>
 
       and <code>pci.h</code>.  Thus, the single running binary may 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>GPLv2&sect;3(a&ndash;b) requires that <q>complete corresponding
 
          machine-readable source code</q> must accompany binary
 
          distributions such as these.  GPLv2&sect;3 further states
 
          that <q>for an executable work, complete source code means all the
 
          source code for all modules it contains</q>.</li>
 
      <li>The binary work in question contains modules from <code>k.b00</code>,
 
        <code>vmlinux_9</code> and <code>tg3</code>.</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 some of the &ldquo;combined work&rdquo; violations found in
 
  VMware's ESXi product.</p>
 
  VMware's ESXi product.  Conservancy did a similar analysis for ESXi 5.0
 
  as well as ESXi 5.5 Update 2 and found nearly identical results.</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>
 

	
 
  <p>To speed up the process, Conservancy has provided
 
  a <a href="https://git.sfconservancy.org/?p=vmkdrivers;a=summary">Git
 
  repository that we built that includes the source components that VMware
 
  released</a>, and which are discussed above in our examples.  However, one
 
  can also obtain the source components directly from VMware, by following
 
  these steps (no login is required):</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>Visit <a href="https://my.vmware.com/web/vmware/details?downloadGroup=ESXI600_OSS&productId=491">https://my.vmware.com/web/vmware/details?downloadGroup=ESXI600_OSS&productId=491</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>
 
&ldquo;Open source software accompanying ESXi&rdquo;.</li>
 

	
 
<li>Confirm that the SHA-1 hash matches the published one
 
  (d121634668a137ec808b63679fd941cef9a59715), found under &ldquo;Read
 
  (35811b981470abe8b606d8a7a97c9795ce570597), found under &ldquo;Read
 
  More&rdquo; on that web page.</li>
 

	
 
<li>Mount (or otherwise open) the
 
  downloaded <code>VMware-ESX-550U2-ODP.iso</code>.</li>
 
  downloaded <code>VMware-ESXI-600-ODP.iso</code>.</li>
 

	
 
<li>Extract <code>vmkdrivers/src_92/vmklinux_92/vmware/linux_pci.c</code>
 
  and <code>BLD/build/HEADERS/vmkapi-current-all-public/vmkernel64/release/device/vmkapi_pci_incompat.h</code>
 
  and <code>BLD/build/HEADERS/vmkapi-current-all-public/generic/release/hardware/vmkapi_pci_incompat.h</code>
 
  from <code>vmkdrivers-gpl/vmkdrivers-gpl.tgz</code> with tar and gzip.</li>
 

	
 
<li>Generate <code>vmklinux_9</code> by following the steps
 
  in <code>vmkdrivers-gpl/BUILD.txt</code> in the ISO.
 
  (Note: <code>vmklinux_9</code> is also available pre-built on a running
 
  ESXi system; <a href="#vmklinux">see below for instructions on how to access it</a>).</li>
 

	
 
<li>You may need the &ldquo;Supporting Toolchain packages for VMware
 
  vSphere ESXi 5.5.0 Update 2&rdquo; file from the above download page to
 
<li>You may need the &ldquo;Open source software disclosure package for
 
  toolchain&rdquo; file from the above download page to
 
  complete the build &mdash; upon downloading you will find it is named
 
  <code>VMware-TOOLCHAIN-550u2-ODP.iso</code> and has a SHA-1 hash of
 
  f679e81ffb2f92729917bbc64c2d541cf75b5b94.</li>
 
  <code>VMware-TOOLCHAIN-600-ODP.iso</code> and has a SHA-1 hash of
 
  9a68df4cbeb645c25002a02f11b1923f98d3d5b5.</li>
 

	
 
</ol>
 

	
 
  <p>To obtain the binary components, follow these steps (a login is required):<p>
 

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

	
 
<li>Visit <a href="https://my.vmware.com/web/vmware/evalcenter?p=free-esxi5">https://my.vmware.com/web/vmware/evalcenter?p=free-esxi5</a>.</li>
 
<li>Visit <a href="https://my.vmware.com/web/vmware/evalcenter?p=free-esxi6">https://my.vmware.com/web/vmware/evalcenter?p=free-esxi6</a>.</li>
 

	
 
<li>Click &ldquo;Register&rdquo; (under the text that reads &ldquo;You have
 
  not registered for this product&rdquo;).</li>
 

	
 
<li>Enter the number of servers you plan to install on (e.g., 1).  Click
 
  &ldquo;Continue&rdquo;.</li>
 

	
 
<li>If the &ldquo;VMware vSphere Hypervisor 5.5 Update 2 &ndash;
 
<li>If the &ldquo;VMware vSphere Hypervisor 6.0 &ndash;
 
  Binaries&rdquo; section is not expanded, click the plus sign next to it.</li>
 

	
 
<li>Click the &ldquo;Manually Download&rdquo; link that's beside &ldquo;ESXi
 
  5.5 Update 2 ISO image (Includes VMware Tools)&rdquo;.</li>
 
  ISO image (Includes VMware Tools)&rdquo;.</li>
 

	
 
<li>Confirm that the SHA-1 hash matches the published one (9475938b51cafc86c8b17d09f2493cb6b4fae927).</li>
 
<li>Confirm that the SHA-1 hash matches the published one (a38a9d37ea529329338de049679c1dd1687d3860).</li>
 

	
 
<li>Mount (or open via some other means) the
 
downloaded <code>VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64.iso</code>.</li>
 
downloaded <code>VMware-VMvisor-Installer-6.0.0-2494585.x86_64.iso</code>.</li>
 

	
 
<li>Find the <code>k.b00</code> file in the root directory.  Extract it
 
using <code>zcat k.b00 &gt; vmvisor64-vmkernel</code> (or a similar command).
 
Repeat the steps described above using <code>objdump -x
 
vmvisor64-vmkernel</code>.</li>
 

	
 
<li id="vmklinux">To retrieve <code>vmklinux_9</code> you will need to install
 
ESXi on your system by booting the ISO and following the instructions.  Once
 
booted, you can then enable SSH access using &ldquo;Customize System/View Logs -&gt;
 
Troubleshooting Options -&gt; Enable SSH&rdquo;.  Login to the system with SSH
 
and then run <code>find /vmfs -name misc_dri.v00 -print</code>.  On the
 
resulting file, run <code>zcat misc_dri.v00 &gt; misc_dri.vmtar</code> then
 
<code>vmtar -x misc_dri.vmtar -o misc_dri.tar</code>.  You can then extract
 
<code>misc_dri.tar</code> using the usual <code>tar</code> to extract
 
<code>usr/lib/vmware/vmkmod/vmklinux_9</code>.  The <code>misc_dri.v00</code>
 
file is also available next to <code>k.b00</code> in the root directory of
 
the ISO (mentioned above), but the <code>vmtar</code> command itself is only
 
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>
 

	
...
 
@@ -597,49 +600,49 @@ copied Christoph's code into their product.</dd>
 
    In <a href="http://bombadil.infradead.org/~hch/vmware/2016-08-09.html">a
 
    statement on his website</a>, Christoph Hellwig announced that he will
 
    appeal the ruling. Christoph also published
 
    (in <a href="http://bombadil.infradead.org/~hch/vmware/Urteil_2016-07-08.pdf">German</a>
 
    and <a href="http://bombadil.infradead.org/~hch/vmware/Judgment_2016-07-08.pdf">English)
 
    the Court's ruling</a> which explains why the materials submitted did not
 
    satisfy German evidence rules &mdash; despite publicly available
 
    information in Linux's Git repositories. In addition, the Court chose not
 
    to seek expert testimony.</dd>
 
  <dt id="statements-of-support">Have others issued statements of support about this action?</dt>
 
  <dd>Various individuals and groups have publicly stated their support for
 
    Conservancy's and Hellwig's actions in this matter.  They include:
 
    <ul>
 
        <li><a href="http://www.april.org/en/statement-support-software-freedom-conservancy-and-christoph-hellwig-gpl-enforcement-lawsuit">APRIL</a></li>
 
        <li><a href="https://fsf.org/news/conservancy-and-christoph-hellwig-gpl-enforcement-lawsuit">Free
 
            Software Foundation</a></li>
 
        <li><a href="https://fsfe.org/news/2015/news-20150331-01.en.html">Free
 
            Software Foundation Europe</a></li>
 
        <li><a href="https://www.gnome.org/news/2015/03/gnome-supports-gpl-compliance-through-vmware-suit-2/">GNOME Foundation</a></li>
 
        <li><a href="http://opensource.org/node/739">Open Source Initiative</a></li>
 
        <li><a href="https://samba.org/samba/news/announcements/2015-03-06_vmware_lawsuit.html">The
 
            Samba Team</a></li>
 
        <li><a href="http://sourceforge.net/p/swig/news/2015/03/defending-the-gpl/">The
 
        SWIG Project</a></li>
 
        <li><a href="https://plus.google.com/104877287288155269055/posts/cHgyreA76yY">Dave Airlie, Linux Developer</a></li>
 
        <li><a href="https://web.archive.org/web/20170911061201/https://plus.google.com/104877287288155269055/posts/cHgyreA76yY">Dave Airlie, Linux Developer</a></li>
 
        <li><a href="https://twitter.com/mjg59/status/573530001758294016">Matthew Garrett, Linux Developer</a></li>
 
        <li><a href="/news/2015/mar/05/vmware-lawsuit/#glikely">Grant Likely, Linux Kernel Engineer</a></li>
 
        <li><a href="http://mina86.com/2015/03/11/the-time-has-come-to-stand-up-for-the-gpl/">Michal Nazarewicz, Linux Developer</a></li>
 
        <li><a href="http://lwn.net/Articles/635624/">Luis R. Rodriguez (aka mcgrof), Linux Developer</a></li>
 
        <li><a href="http://lwn.net/Articles/635855/">Wolfram Sang, Linux Developer</a></li>
 
        <li><a href="https://twitter.com/josh_triplett/status/573543072929198083">Josh
 
        Triplett, Linux Developer</a></li>
 
        <li><a href="https://lwn.net/Articles/635617/">Rik van Riel, Linux Developer</a></li>
 
    </ul>
 
  </dd>
 

	
 
<dt>I
 
see <a href="https://fsf.org/news/conservancy-and-christoph-hellwig-gpl-enforcement-lawsuit">FSF's
 
statement of support</a>, but why
 
isn't <a href="https://www.fsf.org/licensing/compliance">FSF enforcing</a> in
 
this case?</dt>
 

	
 
<dd>While FSF are the authors and license steward of the GNU GPL, it's up to
 
the copyright holder to enforce GPL.  VMware created an operating system by
 
combining parts of the kernel named Linux with their own proprietary code,
 
and then added BusyBox to provide the userspace operating system components.
 
As such, ESXi is not
 
a <a href="https://www.gnu.org/gnu/linux-and-gnu.html">traditional GNU/Linux
 
system</a>.  FSF has many copyrights of its own, but these are almost