4 ms·

I don't think it is as clear cut at all, but that makes it much more interesting. I left a comment there, but it bears some repeating I think ESXi's kernel do

I don't think it is as clear cut at all, but that makes it much more interesting. I left a comment there, but it bears some repeating I think ESXi's kernel does not bootstrap itself from Linux at all. There is no linux kernel as such [1] ESXi does reuse linux kernel drivers ... a lot of them. But the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. What you are seeing in the code above is the mapping between various Linux API's and these calls to the vmkernel. I have no idea about the complaint. VMware's position is probably that anyone can go and write anything they want against the vmkernel's vmkapi interface. Indeed some vendors ship drivers written espeically for this API. VMware have chosen to write a linux<->vmkapi interface, which then allows them to re-use many linux drivers. All of the linux<->vmkapi interface is released, along with the drivers and any modifications and this is considered sufficient. My guess is that the software conservatories position is that it is not. Note exactly the other thing happens on the "other" side -- between user-land and the vmkernel. ESXi uses glibc ... but of course that interfaces to vmkernel via standard system calls. Maybe that's part of it too, I don't know. So this may be a fight over API boundaries and where the GPL starts and stops. That's quite interesting... [1] There was with the ESX product, which shipped a version of Red Hat. That hasn't been around for ages

geofft 12y ago
Thank you, that makes a lot of sense. I can see now how VMware can believe in good faith that they're in compliance (and in fact did a fairly major move towards compliance with ESXi) and Conservancy can believe in good faith that they're not.
rnovak 12y ago
From reading the linked article, it read to me like the complaint asserts that VMKernel itself is a violation of the GPL. If I'm wrong, please feel free to correct me, but these statements seems to point in this direction Conservancy discovered that VMware had failed to provide nor offer any source code for the version of BusyBox included in VMware's ESXi products But ESXi is not a purely open-source product; it also contains a proprietary component called "vmkernel." VMware's developers appear to have taken a substantial amount of kernel code, adapted it heavily, and built it directly into vmkernel itself If so, that would be like me finding some code on Github, changing it a little, and then including it in my own closed source application, clearly a violation of the GPL. Obviously though, I'm not sure how to prove that without the source of VMKernel Again, this is honestly just how I'm reading it, if I'm wrong feel free to correct it.
- spinlock 12y ago
  FYI - BusyBox is just a regular application that a kernel would run. It's not part of the kernel itself.
  - rnovak 12y ago
    To be clear, I didn't make the above statements regarding BusyBox, they were made by the claimant, and the author of the linked article.
  - wildfire 12y ago
    FYI - The complaint is regarding the VMWare ESXi kernel.
- Sanddancer 12y ago
  This sounds more like Oracle vs Google regarding Java, where VMWare, like Google, is stating that APIs are not copyrightable, and the SFC, like Oracle, is claiming that even those APIs are copyrightable.
  - hugoroy 12y ago
    There is a huge difference: in this case the Vmware product does include linux kernel code. So there's definitely some reproduction and distribution of copyrighted parts even excluding the use of APIs.
  - belorn 12y ago
    I don't see the commonalities except that both are about copyright. Has there been any information that the kernel API is being claimed to be copyrighted, or header files, or are VMWare claiming that no copyrighted code has actually been distributed? The above extract mention "substantial amount of kernel code". If that code is implemented algorithms, data structure or full kernel features, then this case has nothing in common with the core issue between Oracle and Google.
- vsl 12y ago
  > clearly a violation of the GPL. It’s not clear, this really is an interesting case. From the description in the comments here, it seems that the GPL code from Linux, together with the code to interface with vmkernel is published, complying with GPL for that part. My guess is that VMware considers vmkernel to be the operating system (which it is, albeit a minimalistic one, just the barebones hypervisor) and regard it as GPL code from Linux linking with the glue layer and the vmkernel system library. Which, if it provides some generic interface that the glue uses, arguably is. And that - GPL code linking with proprietary system library - is an explicitly permitted exception in GPL: http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryExcept... I am just guessing here, but seen like this, VMware’s position makes sense. I would be surprised if they all-out violated GPL, Linksys-style, to be honest, because some competent FLOSS folks work(ed) there.
DannyBee 12y ago
"ut the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. " From my understanding, the problem is that vmkernel directly includes linux kernel GPL code, but they do not open source it. If that's the case, this is 100% clear cut. IE they aren't obeying their own interface, and have shoved GPL code in the wrong side of it.
Patrick_Devine 12y ago
I worked at VMware for over 11 years and was one of the first dozen or so people on the vmkernel team (which produced ESX and later ESXi), although I left several years ago. If I recall correctly, the source tarball was created from a simple script which pulled in a bunch of open source files which were stuck into their own separate branch in the source repository. To my knowledge, there wasn't any linux source in the vmkernel. We did use plenty of open source code, such as busybox, but my understanding was it was always in user space and the source was always published. It's possible that Christoph's code was just pulled in and published with a bunch of other crap that wasn't actually in the product, but someone had checked it into the open source part of the source tree.
yarou 12y ago
That sounds an awful lot like embrace, extend, and extinguish in my woefully uneducated opinion.
nailer 12y ago
Re: [1] There's an argument that ESXi was released to handle these concerns, which predate ESXi's release. I ran venturecake which first published the story, showing how the Linux kernel started vmkernel, not the other way around. Proprietary kernel modules are considered derived works unless they can run independently (eg, nvidia.ko isn't generally considered to be a derived work because it's largely code ported from other platforms). However retrospectively making something portable doesn't change it's previous status as a derived work, and ESXi wouldn't be popular without ESX, which wouldn't exist without Linux booting vmware (despite vmware's protestation otherwise - load ESX and watch the boot process).
- makomk 12y ago
  I dunno, a bootloader seems like the most clear-cut example of something not being a derived work you could get - it doesn't care about the code being bootloeaded and vice-versa, and the API between the two is about as trivial as it can get. What matters according to the GPL isn't whether the code runs on other platforms but how deeply intertwined it is with the kernel; for most Linux drivers, whether it runs on other platforms is a good rule of thumb for determining this, but it kind of breaks down for ESX. Also, "retrospectively making something portable doesn't change it's previous status as a derived work" was if I'm not mistaken SCO's argument for why it should be illegal for customers to run software they'd developed on SCO Unix under Linux. It's not something we should be supporting because it'd a really dangerous tool for locking users into a particular OS. (Fortunately, SCO lost.)
  - nailer 12y ago
    There is no boot loader. This is the Linux kernel module interface. The boot loader used on ESX was an actual boot loader, IIRC grub. Arguing kernel modules are derived works from the kernel is very very different from arguing user space software is derived from an OS.
- xorcist 12y ago
  > nvidia.ko isn't generally considered to be a derived work That's far from clear. Many core developers (including Torvalds, IIRC, but correct me if I'm wrong) are on the record that they consider Nvidia to violate the spirit and/or the letter of the GPL there. It's just that nobody cares enough to litigate.

geofft 12y ago

Thank you, that makes a lot of sense. I can see now how VMware can believe in good faith that they're in compliance (and in fact did a fairly major move towards compliance with ESXi) and Conservancy can believe in good faith that they're not.

rnovak 12y ago

From reading the linked article, it read to me like the complaint asserts that VMKernel itself is a violation of the GPL. If I'm wrong, please feel free to correct me, but these statements seems to point in this direction Conservancy discovered that VMware had failed to provide nor offer any source code for the version of BusyBox included in VMware's ESXi products But ESXi is not a purely open-source product; it also contains a proprietary component called "vmkernel." VMware's developers appear to have taken a substantial amount of kernel code, adapted it heavily, and built it directly into vmkernel itself If so, that would be like me finding some code on Github, changing it a little, and then including it in my own closed source application, clearly a violation of the GPL. Obviously though, I'm not sure how to prove that without the source of VMKernel Again, this is honestly just how I'm reading it, if I'm wrong feel free to correct it.

spinlock 12y ago
FYI - BusyBox is just a regular application that a kernel would run. It's not part of the kernel itself.
- rnovak 12y ago
  To be clear, I didn't make the above statements regarding BusyBox, they were made by the claimant, and the author of the linked article.
- wildfire 12y ago
  FYI - The complaint is regarding the VMWare ESXi kernel.
Sanddancer 12y ago
This sounds more like Oracle vs Google regarding Java, where VMWare, like Google, is stating that APIs are not copyrightable, and the SFC, like Oracle, is claiming that even those APIs are copyrightable.
- hugoroy 12y ago
  There is a huge difference: in this case the Vmware product does include linux kernel code. So there's definitely some reproduction and distribution of copyrighted parts even excluding the use of APIs.
- belorn 12y ago
  I don't see the commonalities except that both are about copyright. Has there been any information that the kernel API is being claimed to be copyrighted, or header files, or are VMWare claiming that no copyrighted code has actually been distributed? The above extract mention "substantial amount of kernel code". If that code is implemented algorithms, data structure or full kernel features, then this case has nothing in common with the core issue between Oracle and Google.
vsl 12y ago
> clearly a violation of the GPL. It’s not clear, this really is an interesting case. From the description in the comments here, it seems that the GPL code from Linux, together with the code to interface with vmkernel is published, complying with GPL for that part. My guess is that VMware considers vmkernel to be the operating system (which it is, albeit a minimalistic one, just the barebones hypervisor) and regard it as GPL code from Linux linking with the glue layer and the vmkernel system library. Which, if it provides some generic interface that the glue uses, arguably is. And that - GPL code linking with proprietary system library - is an explicitly permitted exception in GPL: http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException http://www.gnu.org/licenses/gpl-faq.html#SystemLibraryExcept... I am just guessing here, but seen like this, VMware’s position makes sense. I would be surprised if they all-out violated GPL, Linksys-style, to be honest, because some competent FLOSS folks work(ed) there.

DannyBee 12y ago

"ut the way this happens is through a well-defined API provided by (proprietary) vmkernel called vmkapi. " From my understanding, the problem is that vmkernel directly includes linux kernel GPL code, but they do not open source it. If that's the case, this is 100% clear cut. IE they aren't obeying their own interface, and have shoved GPL code in the wrong side of it.

Patrick_Devine 12y ago

I worked at VMware for over 11 years and was one of the first dozen or so people on the vmkernel team (which produced ESX and later ESXi), although I left several years ago. If I recall correctly, the source tarball was created from a simple script which pulled in a bunch of open source files which were stuck into their own separate branch in the source repository. To my knowledge, there wasn't any linux source in the vmkernel. We did use plenty of open source code, such as busybox, but my understanding was it was always in user space and the source was always published. It's possible that Christoph's code was just pulled in and published with a bunch of other crap that wasn't actually in the product, but someone had checked it into the open source part of the source tree.

yarou 12y ago

That sounds an awful lot like embrace, extend, and extinguish in my woefully uneducated opinion.

nailer 12y ago

Re: [1] There's an argument that ESXi was released to handle these concerns, which predate ESXi's release. I ran venturecake which first published the story, showing how the Linux kernel started vmkernel, not the other way around. Proprietary kernel modules are considered derived works unless they can run independently (eg, nvidia.ko isn't generally considered to be a derived work because it's largely code ported from other platforms). However retrospectively making something portable doesn't change it's previous status as a derived work, and ESXi wouldn't be popular without ESX, which wouldn't exist without Linux booting vmware (despite vmware's protestation otherwise - load ESX and watch the boot process).

makomk 12y ago
I dunno, a bootloader seems like the most clear-cut example of something not being a derived work you could get - it doesn't care about the code being bootloeaded and vice-versa, and the API between the two is about as trivial as it can get. What matters according to the GPL isn't whether the code runs on other platforms but how deeply intertwined it is with the kernel; for most Linux drivers, whether it runs on other platforms is a good rule of thumb for determining this, but it kind of breaks down for ESX. Also, "retrospectively making something portable doesn't change it's previous status as a derived work" was if I'm not mistaken SCO's argument for why it should be illegal for customers to run software they'd developed on SCO Unix under Linux. It's not something we should be supporting because it'd a really dangerous tool for locking users into a particular OS. (Fortunately, SCO lost.)
- nailer 12y ago
  There is no boot loader. This is the Linux kernel module interface. The boot loader used on ESX was an actual boot loader, IIRC grub. Arguing kernel modules are derived works from the kernel is very very different from arguing user space software is derived from an OS.
xorcist 12y ago
> nvidia.ko isn't generally considered to be a derived work That's far from clear. Many core developers (including Torvalds, IIRC, but correct me if I'm wrong) are on the record that they consider Nvidia to violate the spirit and/or the letter of the GPL there. It's just that nobody cares enough to litigate.