Hacker News Reader

Comment by rnovak | Hacker News Reader

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.

View on HN

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

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.

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.

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.

FYI - BusyBox is just a regular application that a kernel would run. It's not part of the kernel itself.

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.

FYI - The complaint is regarding the VMWare ESXi kernel.

Reply on news.ycombinator.com