VMware joins Linux Foundation--while reportedly violating the GPL
Today the Linux world broke out the champagne to celebrate VMware joining the Linux Foundation. I agree. It's good news.
What it doesn't resolve is the allegation that VMware is in active and conscious violation of the GPL. Some of these allegations appear to be well-founded. VMware's lack of response to the allegations is not golden, especially in light of its embrace of the Linux Foundation.
Here's the problem with how VMware apparently uses Linux (though there's still an open question as to whether VMware does, in fact, use Linux, the evidence points pretty strongly to VMware's use of the open-source operating system).
Products like VMware ESX Server and Citrix Xen Server divide each computer into one or more virtual machines. The virtual machines provide logical memory, CPU, and device resources to guest operating systems. ESX Server, like Citrix Xen Server, uses a hypervisor to mediate between the virtual machines and physical resources of the computer, and an embedded operating system (distinct from guest operating systems) to implement essential virtualization operations.
ESX Server and Citrix Xen Server both use Linux as the embedded operating system. This is where the trouble begins.
In both cases, the respective embedded Linux is installed as part of the computer virtualization product, and neither VMware nor Citrix support using the remainder of the virtualization product without the coupled embedded Linux. Citrix releases all essential Citrix Xen Server components, including the hypervisor, under the GPL and compatible open source licenses. VMware does not.
If true, this would be a clear violation of the GPL, and if VMware's ESX Server cannot effectively function but for Linux, then VMware has a problem. It's a convenient problem as it gives VMware a distinct advantage over the open-source Xen project, as well as Citrix.
But it's a problem all the same, one that should be resolved with open and honest communication. VMware can't hope to cozy up to Linux and its community without participating on the principles of transparency and trust. At present, it has shown little of the former and has yet to earn much of the latter.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
The kernel developers have had SFLC at their disposal if they've ever wanted to bring a lawsuit. Don't hold your breath waiting for Linus Torvalds to approve that. And don't expect the Linux Foundation, an industry association of companies who have no desire to have the GPL enforced against themselves, to show interest in enforcing the GPL. This legal theory will have to be decided with another GPL kernel, not Linux.
"if VMware's ESX Server cannot effectively function but for Linux, then VMware has a problem"
That can be said for every single Linux application. I know you are not saying that the Linux version of Flash for instance, violates the GPL, but what you wrote implies exactly that.
So, if ESX Server could be run with the BSD kernel instead and provide exactly the same functionality (even if some rewriting is required) then it's not a derivative work. However, if it specifically requires a specific function of the Linux kernel which no other kernel can possibly provide then it's both dependent and derivative.
However, ESXi does allow use of Linux device drivers and thus emulates a Linux kernel for GPL'd code. I would find it interesting to see the analysis of the ESXi product from a license compliance perspective.
- by tzs108 August 7, 2008 6:02 PM PDT
- If you have two programs, A and B, that work together in some fashion (e.g., A == the Linux kernel and B == the nVidia binary driver), the question of whether or not B is a derivative work of A is *independent* of whether or not B can also work with some other program C (e.g., Windows).
- Reply to this comment
-
(6 Comments)There is this huge myth among open source people that designing a program, B to specifically work (perhaps exclusively) with another program, A requires permission of the A copyright owners. This is simply not so. There is plenty of case law on this, because in the proprietary software world there are a lot of people writing program B's, and a lot of owners of A's who are very annoyed by this (as they want to keep the market for add-ons to their programs to themselves).
You can find examples in many areas. Cheat programs for video games. Jail break programs for closed cell phones or set top boxes. Numerous third-party utilities for Windows and Mac that use reverse-engineered non-public interfaces to access MS-only or Apple-only aspects of the system.
The case law has come down pretty strongly in favor of the B's. Offhand, I can't think of any significant A wins under copyright law in this area. There have been cases where B had to stop, but those were cases where a contract was involved, and A won on a contract theory, not a copyright theory.
Some A's have tried to be tricky, and made it so that for the B programs to work, they had to actually copy non-trivial amount of code from A. Even those B's have won in court--things that you have to copy in order to interface to A are functional elements of A that are not copyrightable.
I think the GPL people need to just get over this. There are some things that are just not within the power of an expansive copyright license to stop, no matter how it is written. Some of those things that are outside its scope are things that they might not like--such as ugly binary blobs (carefully written to only use what is necessary to interface) getting splattered onto your nice, clean, shiny GPL code. :-)