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

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

[.text]” section:

</p>

<pre>

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 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 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 ‘vmvisor64-vmkernel.stripped’”.

  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>

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

  “vmkernel”.  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 */

[...]

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) */

[...]

  };

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

<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/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, &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-&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-&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>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 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

       — 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§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 “combined work” violations found in

<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 obtain the source components, follow these steps (no login is required):</p>

<ol>

<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 software accompanying ESXi&rdquo;.</li>

<li>Confirm that the SHA-1 hash matches the published one

  (35811b981470abe8b606d8a7a97c9795ce570597), found under “Read

  More&rdquo; on that web page.</li>

<li>Mount (or otherwise open) the

  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/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;Open source software disclosure package for

  toolchain” file from the above download page to

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

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

  ISO image (Includes VMware Tools)&rdquo;.</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-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 “Customize System/View Logs ->

Troubleshooting Options -> Enable SSH”.  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>

  <p>Note that VMware may present you with <abbr title="End User Licensing Agreement">EULA</abbr>s and <abbr title="Terms of Service">ToS</abbr> when you download

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

exclusively on various parts of the GNU system, not on the kernel, Linux.  As

such, FSF probably does not have copyright interests available to directly

enforce the GPL regarding the primary issue in this case.</dd>

  <dt><em>I</em> care about copyleft and the GPL.  How can I help?</dt>

  <dd>Conservancy needs <a href="#donate-box" class="donate-now">your immediate financial

  support to proceed with this litigation</a>.  Litigation costs are

  unpredictable, and this lawsuit may take years to resolve.  Conservancy is

  prepared to fund this case through its conclusion, but we can only do so

  with <a href="/supporter/"><em>your</em> support</a>.  If you are an

  individual who supports copyleft and wants to see it defended, please

  donate now.  And, if you make a public statement of support, please email the

  URL

  to <a href="mailto:info@sfconservancy.org">&lt;info@sfconservancy.org&gt;</a>,

  as we'd like to include representative selection of supportive statements above.</dd>

  <dt>Why is the case in Germany?</dt>

  <dd>Copyright infringement claims can be brought anywhere that distribution

  of the copyrighted works occur.  VMware distributes ESXi throughout the

  world, but Germany is close to Christoph's home and his lawyer was

  available to do the litigation work there.  Finally, historically,

  Mr. Jaeger's cases in Germany have usually achieved worldwide compliance on

  the products at issue in those cases.</dd>

</dl>

{% endblock %}

<!--  LocalWords:  Christoph Hellwig VMware vmkernel Linux's GPLv VMware's

 -->

<!--  LocalWords:  ESXi CCS Christoph's Jaeger NDA SVG PNG vmklinux vmk un

 -->

<!--  LocalWords:  Hellwig's PCIGetDeviceName vmvisor vmkDev vmkDevName UND

 -->

<!--  LocalWords:  sizeof VMKAPI pciDevExt moduleID linuxDev vmtar'ed LSB ec

 -->

<!--  LocalWords:  xfffffffffffffffc gzip login vSphere SHA fd cef pre ffb

 -->

<!--  LocalWords:  Toolchain bbc Hypervisor cafc cb fae ToS Airlie mcgrof

 -->

<!--  LocalWords:  Rik userspace Jaeger's endblock

 -->