3 ms·

They have developed their own kernel, it's called vmkernel.

by jabedude 7y ago

monocasa 7y ago
And it links in GPLed drivers from the Linux kernel.
- rrdharan 7y ago
  The lawsuit was withdrawn; VMware is no longer using GPLed drivers. No precedent was established as to whether their prior use actually was a derivative work - personally I've always shared the VMware take on it that this was a loophole, and that if the VMkernel was a derivative work of Linux by virtue of the vmklinux compatibility layer, then Windows becomes a derivative work of any open source driver, which doesn't make any sense...
  - kijiki 7y ago
    The official VMware take, at least while we were there, was that the vmkernel itself was a binary only kernel module loaded by the Console OS's Linux kernel, and as such was no different than the binary-only Nvidia driver. This was a bit sketchy, since the vmkernel linked in a different version of the GPL'd drivers in question than the ones in the Console OS, but you know, close enough. Of course, when ESXi shipped without a console OS, but with a vmklinux and GPL'd drivers, a new take was needed.
    - monocasa 7y ago
      Which is funny, because that doesn't match Nvidia's legal theory as to why they're allowed to ship binary drivers. The Nvidia blob doesn't import, export, or reimplement any Linux symbols (that's relegated to an open source, dual GPLv2/proprietary bridge). The Nvidia blob is also way older than their Linux port, being the same codebase as their Windows driver. They believe that a judge will look at those facts and rule that there's no way their blob is derived from the Linux kernel. It seems like neither of those applied to vmklinux.
    - rrdharan 7y ago
      > the vmkernel linked in a different version of the GPL'd drivers in question than the ones in the Console OS, but you know, close enough. It wasn't "close enough" - they released the drivers/patches/modifications of those drivers, per the terms of the GPL. IIRC they also avoided at least one network driver (I believe Alan Cox's 3com driver?) because the author had strong personal objections, and 3com actually wrote an alternative. They also open-sourced the vmklinux API/wrapper layer itself, so the full picture pre-ESXi was: vmklinux module - GPL'ed module for a proprietary VMkernel vmklinux-based drivers - GPL'ed forks of drivers from the Linux source tree console OS - GPL/open-sourced light fork of RHEL VMkernel - proprietary, closed source (later available under shared source w/ NDA) Hellwig's lawsuit AIUI argued that there was significant implementation, covered by copyright, in vmklinux headers and elsewhere, such that the vmklinux<->VMkernel boundary was not sufficient to prevent the latter from being a derived work of the former. I also think that beyond that there was a strong belief and assumption in the Linux community that other parts of the VMkernel "must have" been copied from OSS/Linux as there was simply no way a random/small/private company could have possibly created its own file system, scheduler, network and disk stack, etc. But the reality was simply that VMware had a ton of really talented and highly productive operating system experts in the early days. [I was an employee at VMware from 2002-2011, opinions my own]

They have developed their own kernel, it's called vmkernel.

monocasa 7y ago

And it links in GPLed drivers from the Linux kernel.

rrdharan 7y ago
The lawsuit was withdrawn; VMware is no longer using GPLed drivers. No precedent was established as to whether their prior use actually was a derivative work - personally I've always shared the VMware take on it that this was a loophole, and that if the VMkernel was a derivative work of Linux by virtue of the vmklinux compatibility layer, then Windows becomes a derivative work of any open source driver, which doesn't make any sense...
- kijiki 7y ago
  The official VMware take, at least while we were there, was that the vmkernel itself was a binary only kernel module loaded by the Console OS's Linux kernel, and as such was no different than the binary-only Nvidia driver. This was a bit sketchy, since the vmkernel linked in a different version of the GPL'd drivers in question than the ones in the Console OS, but you know, close enough. Of course, when ESXi shipped without a console OS, but with a vmklinux and GPL'd drivers, a new take was needed.
  - monocasa 7y ago
    Which is funny, because that doesn't match Nvidia's legal theory as to why they're allowed to ship binary drivers. The Nvidia blob doesn't import, export, or reimplement any Linux symbols (that's relegated to an open source, dual GPLv2/proprietary bridge). The Nvidia blob is also way older than their Linux port, being the same codebase as their Windows driver. They believe that a judge will look at those facts and rule that there's no way their blob is derived from the Linux kernel. It seems like neither of those applied to vmklinux.
  - rrdharan 7y ago
    > the vmkernel linked in a different version of the GPL'd drivers in question than the ones in the Console OS, but you know, close enough. It wasn't "close enough" - they released the drivers/patches/modifications of those drivers, per the terms of the GPL. IIRC they also avoided at least one network driver (I believe Alan Cox's 3com driver?) because the author had strong personal objections, and 3com actually wrote an alternative. They also open-sourced the vmklinux API/wrapper layer itself, so the full picture pre-ESXi was: vmklinux module - GPL'ed module for a proprietary VMkernel vmklinux-based drivers - GPL'ed forks of drivers from the Linux source tree console OS - GPL/open-sourced light fork of RHEL VMkernel - proprietary, closed source (later available under shared source w/ NDA) Hellwig's lawsuit AIUI argued that there was significant implementation, covered by copyright, in vmklinux headers and elsewhere, such that the vmklinux<->VMkernel boundary was not sufficient to prevent the latter from being a derived work of the former. I also think that beyond that there was a strong belief and assumption in the Linux community that other parts of the VMkernel "must have" been copied from OSS/Linux as there was simply no way a random/small/private company could have possibly created its own file system, scheduler, network and disk stack, etc. But the reality was simply that VMware had a ton of really talented and highly productive operating system experts in the early days. [I was an employee at VMware from 2002-2011, opinions my own]