A GPL-enforcement suit against VMware

This article brought to you by LWN subscribers Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

When Karen Sandler, the executive director of the Software Freedom Conservancy , spoke recently at the Linux Foundation's Collaboration Summit , she spent some time on the Linux Compliance Project, an effort to improve compliance with the Linux kernel's licensing rules. This project, launched with some fanfare in 2012, has been relatively quiet ever since. Karen neglected to mention that this situation was about to change; that had to wait for the announcement on March 5 of the filing of a lawsuit against VMware alleging copyright infringement for its use of kernel code. This suit, regardless of its outcome, should help to bring some clarity to the question of what constitutes a derived work of the kernel.

In her talk, Karen said that the Conservancy gets "passionate requests" for enforcement of the GNU General Public License (GPL) from two distinct groups: "ideological developers" and corporate general counsels. The interest from the developers is clear: they released their code under the GPL for a reason, and they want its terms to be respected. On the other hand, a typical general counsel releases little code under any license. Their interest, instead, is in a demonstration that the GPL has teeth so that they can be taken seriously when they tell management that the company must comply with the license terms of the code it ships.

The VMware suit should bring some comfort to both groups, in that it targets the primary product of a prominent company that has long been seen in some circles as pushing the boundaries of the GPL. But, beyond that, the suit will be of interest to the larger group of people that would like more clarity on just where the "derived work" line is drawn.

The complaint

The complaint has been filed in Hamburg, Germany, in the name of kernel developer Christoph Hellwig; the Conservancy is helping to fund the case and the lawyer involved is Till Jaeger, who also represented Harald Welte in his series of successful compliance cases. It focuses on the "vmkernel" component of VMware's vSphere ESXi 5.5.0 hypervisor product — one of VMware's primary sources of revenue.

VMware openly uses Linux as part of the ESXi product, and it ships the source for (presumably) all of the open-source components it uses; that code can be downloaded from VMware's web site. But ESXi is not a purely open-source product; it also contains a proprietary component called "vmkernel." The bootstrap process starts with Linux, which loads a module called "vmklinux." That module, in turn, loads the vmkernel code that does the actual work of implementing the hypervisor functionality. [Update: in truth, newer versions of ESXi no longer need the initial Linux bootstrap; in current versions, vmkernel boots directly.]

To many, the mere fact that vmkernel was once loaded into the kernel by a module is enough to conclude that it is a derived product of the kernel and, thus, only distributable under the terms of the GPL. That would make an interesting case in its own right, but there is more to it than that. It would seem that vmkernel loads and uses quite a bit of Linux kernel code, sometimes in heavily modified form. The primary purpose for this use appears to gain access to device drivers written by Linux, but supporting those drivers requires bringing in a fair amount of core code as well.

If one downloads the source-release ISO image from the page linked above and untars vmkdrivers-gpl/vmkdrivers-gpl.tgz , one will find these components under vmkdrivers/src_92/vmklinux_92 . There is some interesting stuff there. In vmware/linux_rcu.c, for example, is an "adapted" version of an early read-copy-update implementation from Linux. vmware/linux_signal.c contains signal-handling code, vmware/linux_task.c contains process-management code (including an implementation of schedule() ), and so on. Of particular interest to this case are linux/lib/radix-tree.c (a copy of the kernel's radix tree implementation) and several files in the vmware directory containing a modified copy of the kernel's SCSI subsystem. Both of these subsystems carry Christoph's copyrights and, thus, give him the standing to pursue an infringement case against VMware.

The picture that emerges suggests that vmkernel is not just another binary-only kernel module making use of the exported interface. Instead, VMware's developers appear to have taken a substantial amount of kernel code, adapted it heavily, and built it directly into vmkernel itself. It seems plausible that, in a situation like this, the case that vmkernel is a derived product of the Linux kernel would be relatively easy to make.

Unfortunately, we cannot see the complaint itself, because "court proceedings are not public by default in Germany (unlike in the USA)," according to the FAQ maintained by the Conservancy.

A service to the community

In her talk, Karen stated that litigation is the Conservancy's last resort after every other approach fails to obtain compliance. Certainly there can be no accusations of a rush to litigation here; the first indications of trouble emerged in 2007. The Conservancy raised the issue with VMware a number of times with no luck. Christoph approached VMware in August 2014 with his own request for compliance, starting a series of communications that did not lead to an agreement. There was a meeting in December where, it is said, VMware wanted to propose a settlement but only under strict non-disclosure terms — terms which Christoph refused. So, it seems, going to court is about the only remaining option.

One might wonder about the choice to file in Germany. The FAQ says:

VMware distributes ESXi throughout the world, but Germany is close to Christoph's home and his lawyer was available to do the litigation work there. Finally, historically, Mr. Jaeger's cases in Germany have usually achieved worldwide compliance on the products at issue in those cases.

It is worth adding that Germany's courts seem to be relatively friendly toward this sort of claim, with the result that previous GPL-enforcement cases filed there have tended to go well for the plaintiffs. The ability to pick the battlefield is a powerful advantage in a dispute of this nature.

Filing an enforcement lawsuit is an intimidating prospect for a number of reasons. Karen's talk noted that there is a lot of tension around the topic of GPL enforcement. Some people would rather that it were not done at all, seeing it as an incentive for companies to avoid GPL-licensed code. There are not many developers who want to make a stand in an enforcement effort; the Linux Compliance Project, she said, contains a number of kernel developers, but almost none of them want to stick their necks out in an actual enforcement effort.

But, she said, there is value in such efforts. Companies worldwide spend vast amounts of money to ensure that they are in compliance with free-software licenses. In the absence of enforcement, some will certainly question the value and necessity of that expense — and some will decide not to bother. There are also highly successful projects that have resulted from enforcement efforts; router distributions like OpenWrt are usually featured at the top of that list. GPL enforcement, by making it clear that everybody needs to play by the rules, is, she said, performing a service to the community as a whole.

How that service plays out in this case is going to be interesting to watch, which is good, since we are likely to be watching for some time. Given that ESXi is at the core of VMware's business, VMware seems unlikely to either release the code or withdraw the product willingly. So the case may have to go all the way through trial, and perhaps through appeals as well. But, at the end, perhaps we'll have a clearer idea of what constitutes a derived product of the kernel; that could be seen to be a useful service even if the enforcement effort itself fails.

