5 ms·

Is there any information about why VMware thinks they are not bound by the GPL? Curious whether they have a technical justification, rather than simply being a

Is there any information about why VMware thinks they are not bound by the GPL? Curious whether they have a technical justification, rather than simply being a blatant licensing violation.

emacsen 12y ago
This is just speculation but I suspect this is a matter of being caught with their pants down. They violated the GPL, but to comply with the license would mean that they'd have to release a lot of code that they don't want to release. From the page, it seems like there's been ongoing negotiation, so I am guessing there's been a lot of stalling.
- rdtsc 12y ago
  > They violated the GPL, but to comply with the license would mean that they'd have to release a lot of code that they don't want to release. Well they could replace the component with proprietary (so there is not license to comply with), stop releasing the old version and then probably settle to pay fines or damages. In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL.
  - MatthewWilkes 12y ago
    Probably have to pay damages to all their commercial users, too, given they charged them for a licence for something they had no rights to distribute.
  - MatthewWilkes 12y ago
    Probably have to pay damages to all their commercial users, too, given they charged them for a licence for something they had no rights to distribute.
  - emacsen 12y ago
    Right but they also didn't have rights to distribute the work. There will be issues of demonstrating damages, but you can't just say "Oh sure I violated your copyright... but now that you take me to court, I'll stop." and expect to get off without paying anything.
    - rdtsc 12y ago
      Well that's why I said they'll probably be forced to pay a fine or damages. They could for example look at number of licenses VMWare sold with the GPL code in it, then take a fraction of the profits from each or something like that. Stopping will probably just be another outcome unless they can come with some kind of agreement, like a separate commercial relicensed version of the GPL (but with multiple contributors that becomes a nightmare)
  - yaeger 12y ago
    >In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL. True. I have met many people who didn't make that connection. They had this idea that if they found GPL code inside a commercial, closed source product, that it would be completely okay to start distributing this software themselves. Because in their minds, "GPL is in there, so the entire thing automatically becomes GPL licensed and everybody can distribute GPL licensed code and even charge money for it". I had to explain to them that is doesn't work that way. And if they found such a component, all they would have found was a GPL violation which they can report and which then would be an issue between the software's developers to resolve. Which may either end in them actually releasing their entire product under GPL or simply paying a fine. Out of those options I am pretty sure most would rather pay a fine than to give up their own IP to the GPL.
notacoward 12y ago
Don't know specifically, but these usually come down to hair-splitting over terms like "linking" and "derived work" and so on. I guess VMware think they can convince a judge that the way their code interacts with the Linux kernel does not cause it to fall under the GPL's source-publication requirement. On the other hand, I know Christoph enough to know how insanely smart and persistent he is. If he's confident enough in his conclusions to go forward with this, I wouldn't want to be on the other team.
- filmgirlcw 12y ago
  And frankly, some of the hair-splitting differentiators need to be settled in court. It seems more obvious in compiled software (such as what VMWare is doing and with BusyBox), but if you think about the persistent issues that arise with what is the difference between "derived works" and "linked works" with web apps (even before JavaScript started taking over the client and server side), there are a lot of questions that I have long believed only a court could really settle to at least give a legal precedent.
geofft 12y ago
I'm not fully up-to-date on this case, but there is a bit of wiggle room on what counts as a derivative work, even in kernelspace. My favorite example is OpenAFS. Development of the AFS kernel module started in 1983, so the code is a decade older than Linux itself. So it's hard to argue that openafs.ko is a derivative work of Linux, and since it continues to run on several kernels other than Linux (Darwin, Solaris, NT, etc.) and the Linux-specific code is just glue code to make it work, it's not really obvious that it's become a derivative work of Linux. (OpenAFS is free software under the IBM Public License, which is a GPL-incompatible free software license, and the rightsholders will not relicense. The Linux kernel infrastructure assumes that any non-GPL kernel module is proprietary, for extra amusement.) Along the same lines is the kernel module for VMware Workstation, the desktop product that runs on Linux as well as Windows and Mac OS X. It doesn't predate Linux, so the argument is slightly less clear. VMware's vmkernel, as I understand it, is an amalgamation of VMware's hypervisor code (that predated ESX, and originated on Workstation) plus Linux. I think it conceptually started off as a Linux server with the existing kernel module, but both have evolved quite a bit. I think the remaining Linux parts mostly exist as hardware drivers, and VMware is providing the core kernel routines like scheduling and memory management and "world" management (equivalent to process management, but it's a hypervisor). I think that VMware's argument is that they did not start with Linux and add proprietary features to existing GPL'd code and call it proprietary; they started with their own code and linked in parts of Linux via well-defined interfaces, and they're happy to comply with the GPL for the parts that came from Linux, but they don't want to GPL the entirety of the ESXi kernel. It's worth noting that the concept of address space isn't a legal concept, just a technical one. We generally acknowledge that it's not a GPL violation to run proprietary applications on Linux, even applications that use Linux-specific interfaces like cgroups and epoll and signalfd and all that good stuff. Is this simply because the Linux kernel copyright explicitly disclaims virality to userspace, or because there's some fundamental legal reason why userspace and kernelspace are far enough apart? Can two components in ring 0 also be "far enough apart"?
- detaro 12y ago
  From the wording in the link it sounds like they include modified GPL code and don't publish that, not that they are expected to open-source ESXi (or whatever it is called right now) entirely: > In 2011, Conservancy discovered that VMware had failed to provide nor offer any source code for the version of BusyBox included in VMware's ESXi products (as required by BusyBox's license, GPLv2).

Is there any information about why VMware thinks they are not bound by the GPL? Curious whether they have a technical justification, rather than simply being a blatant licensing violation.

emacsen 12y ago

This is just speculation but I suspect this is a matter of being caught with their pants down. They violated the GPL, but to comply with the license would mean that they'd have to release a lot of code that they don't want to release. From the page, it seems like there's been ongoing negotiation, so I am guessing there's been a lot of stalling.

rdtsc 12y ago
> They violated the GPL, but to comply with the license would mean that they'd have to release a lot of code that they don't want to release. Well they could replace the component with proprietary (so there is not license to comply with), stop releasing the old version and then probably settle to pay fines or damages. In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL.
- MatthewWilkes 12y ago
  Probably have to pay damages to all their commercial users, too, given they charged them for a licence for something they had no rights to distribute.
- MatthewWilkes 12y ago
  Probably have to pay damages to all their commercial users, too, given they charged them for a licence for something they had no rights to distribute.
- emacsen 12y ago
  Right but they also didn't have rights to distribute the work. There will be issues of demonstrating damages, but you can't just say "Oh sure I violated your copyright... but now that you take me to court, I'll stop." and expect to get off without paying anything.
  - rdtsc 12y ago
    Well that's why I said they'll probably be forced to pay a fine or damages. They could for example look at number of licenses VMWare sold with the GPL code in it, then take a fraction of the profits from each or something like that. Stopping will probably just be another outcome unless they can come with some kind of agreement, like a separate commercial relicensed version of the GPL (but with multiple contributors that becomes a nightmare)
- yaeger 12y ago
  >In other words the legal outcome of GPL violations is not necessarily being forced to release the rest of the code as GPL. True. I have met many people who didn't make that connection. They had this idea that if they found GPL code inside a commercial, closed source product, that it would be completely okay to start distributing this software themselves. Because in their minds, "GPL is in there, so the entire thing automatically becomes GPL licensed and everybody can distribute GPL licensed code and even charge money for it". I had to explain to them that is doesn't work that way. And if they found such a component, all they would have found was a GPL violation which they can report and which then would be an issue between the software's developers to resolve. Which may either end in them actually releasing their entire product under GPL or simply paying a fine. Out of those options I am pretty sure most would rather pay a fine than to give up their own IP to the GPL.

notacoward 12y ago

Don't know specifically, but these usually come down to hair-splitting over terms like "linking" and "derived work" and so on. I guess VMware think they can convince a judge that the way their code interacts with the Linux kernel does not cause it to fall under the GPL's source-publication requirement. On the other hand, I know Christoph enough to know how insanely smart and persistent he is. If he's confident enough in his conclusions to go forward with this, I wouldn't want to be on the other team.

filmgirlcw 12y ago
And frankly, some of the hair-splitting differentiators need to be settled in court. It seems more obvious in compiled software (such as what VMWare is doing and with BusyBox), but if you think about the persistent issues that arise with what is the difference between "derived works" and "linked works" with web apps (even before JavaScript started taking over the client and server side), there are a lot of questions that I have long believed only a court could really settle to at least give a legal precedent.

geofft 12y ago

I'm not fully up-to-date on this case, but there is a bit of wiggle room on what counts as a derivative work, even in kernelspace. My favorite example is OpenAFS. Development of the AFS kernel module started in 1983, so the code is a decade older than Linux itself. So it's hard to argue that openafs.ko is a derivative work of Linux, and since it continues to run on several kernels other than Linux (Darwin, Solaris, NT, etc.) and the Linux-specific code is just glue code to make it work, it's not really obvious that it's become a derivative work of Linux. (OpenAFS is free software under the IBM Public License, which is a GPL-incompatible free software license, and the rightsholders will not relicense. The Linux kernel infrastructure assumes that any non-GPL kernel module is proprietary, for extra amusement.) Along the same lines is the kernel module for VMware Workstation, the desktop product that runs on Linux as well as Windows and Mac OS X. It doesn't predate Linux, so the argument is slightly less clear. VMware's vmkernel, as I understand it, is an amalgamation of VMware's hypervisor code (that predated ESX, and originated on Workstation) plus Linux. I think it conceptually started off as a Linux server with the existing kernel module, but both have evolved quite a bit. I think the remaining Linux parts mostly exist as hardware drivers, and VMware is providing the core kernel routines like scheduling and memory management and "world" management (equivalent to process management, but it's a hypervisor). I think that VMware's argument is that they did not start with Linux and add proprietary features to existing GPL'd code and call it proprietary; they started with their own code and linked in parts of Linux via well-defined interfaces, and they're happy to comply with the GPL for the parts that came from Linux, but they don't want to GPL the entirety of the ESXi kernel. It's worth noting that the concept of address space isn't a legal concept, just a technical one. We generally acknowledge that it's not a GPL violation to run proprietary applications on Linux, even applications that use Linux-specific interfaces like cgroups and epoll and signalfd and all that good stuff. Is this simply because the Linux kernel copyright explicitly disclaims virality to userspace, or because there's some fundamental legal reason why userspace and kernelspace are far enough apart? Can two components in ring 0 also be "far enough apart"?

detaro 12y ago
From the wording in the link it sounds like they include modified GPL code and don't publish that, not that they are expected to open-source ESXi (or whatever it is called right now) entirely: > In 2011, Conservancy discovered that VMware had failed to provide nor offer any source code for the version of BusyBox included in VMware's ESXi products (as required by BusyBox's license, GPLv2).