|
|
Log in / Subscribe / Register

GPL compliance suit against VMware dismissed

By Jake Edge
August 17, 2016

In a setback to the Christoph Hellwig's efforts to enforce the GPL on code that he wrote in the Linux kernel, his suit against VMware in Germany has been dismissed on procedural grounds. The court ruled that he had not provided enough specificity about the code he was claiming had been used by the company. The merits of the GPL and whether the two main parts of VMware's product constitute a derived work of the kernel were not even considered. There may be another chance for the court to do so, however, as Hellwig will appeal the dismissal.

The suit was announced by the Software Freedom Conservancy (SFC) back in March. SFC is funding the litigation, which revolves around VMware's ESXi virtualization product. ESXi has two pieces of interest here: the proprietary "vmkernel" that uses Linux code and drivers in an open source "vmklinux" module.

The source code for vmklinux unquestionably contains Hellwig's code and copyright notices. But vmklinux itself does comply with the GPLv2. The question then becomes: does combining vmklinux and vmkernel make the resulting executable a derivative work of the kernel? Hellwig argued that it does, but the court never even got to that point.

The court dismissed the suit on the grounds that "the materials submitted did not satisfy German evidence rules", Hellwig said on his blog. He provided links to the official ruling [PDF in German] and an unofficial English translation [PDF]. In that post, he announced his intention to appeal, and expressed his dismay that the main question of the case was never addressed:

I'm disappointed that the court didn't even consider the actual case of reusing the Linux code written by me, and I hope the Court of Appeal will investigate this central aspect of the lawsuit.

The court chose not bring in an expert and relied on the filings made by Hellwig and VMware (which are not public, though they are referred to in the ruling). In Germany, the court decides whether expert testimony is required. Based on Hellwig's statement, it would seem that he and his legal team expected the court to do so in this case.

The judgment is split into two main parts: the "findings of fact", which is largely a restatement of the arguments both sides made in their filings, and the "reasons for the decision" that describes the problems the court found with Hellwig's evidence. The court decided that the suit was "admissible" even though Hellwig only held copyright on some portions of the kernel because he claimed "adapters copyright" on the changes that he made to parts of the kernel. The concept of "adapter's copyright" (or at least the term) appears to be specific to Germany, but the ruling makes it reasonably clear what is meant:

As discussed at the hearing, the only property rights from which the Plaintiff might possibly derive the right to claim forbearance are adapter's copyrights, because the Plaintiff states that he successively made independent contributions to the Linux kernel. It follows from Copyright Act § 69c No. 2 clause 2 in conjunction with § 3 that adapter's copyright can also be created when software is modified. Whether any of said contributions was created in collaboration with others does nothing to alter this fact, because then the community of originators would also be entitled to a mere adapter's copyright and the Plaintiff thus to "co-adapter's copyright".

But, the fact that it is an admissible action does not mean that Hellwig is entitled to the injunction he seeks, unless his "pleading is sufficiently substantiated to establish the cause of action and whether the Plaintiff has proved where necessary [...] which parts of the Linux program he claims to have modified, and in what manner" That is the first of three tests (the others are establishing that his contributions meet the criteria for adapter's copyright and that VMware has in fact used that code) that are required to be met before the substantive questions about vmkernel and vmklinux can even be considered:

Nonetheless, these questions (on which the legal interest of the parties and their counsel presumably focus) can and must remain unanswered. This is because the very first requirement for conducting an examination, namely that code possibly protected for the Plaintiff as a holder of adapter's copyright has been used in the Defendant's product, cannot be established. This is still true even after taking into account the Plaintiff's subsequently admitted procedural document dated 29.04.2016, in which he (after the deadline had been extended) had a further opportunity to enter a pleading on the reservations in this respect which the court had already expressed at the hearing.

The evidence presented by Hellwig would seem to be files and other information that would be instantly recognizable by a kernel developer or many other members of the free-software community: Git repositories, tar files, git blame output, and so on. None of that information constitutes "an admissible pleading in court procedure", however. The problem seems to be that Hellwig did not directly and specifically show exactly which chunks of code in Linux were his and to link them to the corresponding chunks in vmklinux.

There were apparently three different facets of Hellwig's work on Linux that were part of the claims: his modifications to code throughout the kernel, his work on the SCSI subsystem starting in 2000, and his development of the radix tree code. For the changes to the overall kernel, the evidence presented was the publicly available Git repository of the kernel, which the court considered to be too broad. In addition, a CD containing the entire source code of Linux was submitted but it also lacked specifics:

[...] it is not the job of the court or of the opposing party to pick out from an entire source code any parts of code that might originate from the Plaintiff, and to judge for themselves to what extent and for which parts and related issues the Plaintiff might be seeking protection under copyright law.

There was also some git blame output submitted, which might serve to identify those with an adapter's copyright in the files, the court said, but it did not indicate where that code appeared in vmklinux, so it doesn't establish that the code was used by VMware. While there were statements that a full comparison had been made between vmklinux and the kernel, only some examples from that comparison were submitted. Furthermore, the two header files distributed with vmklinux that contain Hellwig's copyrights are not sufficient to show that he has an adapter's copyright in that code: "This cannot simply be assumed merely because the Defendant itself has named the Plaintiff as a possible modifier of Linux; instead, it must be established by the Plaintiff."

For the SCSI subsystem, Hellwig's filings are more specific, but still insufficient for the court. While he claimed to be one of the most active SCSI developers from 2000 to 2004, which involved "complex programming that merits protection", that claim does not provide enough information; "he needs to specifically name those programming achievements for which he seeks protection". The ruling also mentions that VMware had argued that only eight functions from the SCSI code submitted could be attributed to Hellwig's work and that Hellwig did not contest that argument. Furthermore:

The Defendant has argued moreover that one of these eight functions has been “commented out” in “vmklinux”, i.e. it is not used in “vmklinux”; and that in the remaining seven functions, more than half the lines of code have either been written by another originator (without any contribution from the Plaintiff) or have simply been modified or at the most shifted by the Plaintiff [...] In this respect therefore, the Plaintiff should have specified more exactly his shares in the functions claimed with [exhibit] K 15 and furnished proof of his adapter’s copyright.

The 19 patches to the SCSI hotplug functionality that were submitted were not tied to vmklinux, but also were not accompanied by a statement about how those contributions are complex enough for copyright protection:

[...] the Plaintiff concedes that he merely modified third-party code at the place concerned in order to be able to use another interface, something that is relevant in terms of copyright law; but he neither submits the code he modified, nor does he explain to what extent adapting the code to an interface exceeded average programming work

For the radix tree work, the explanations offered in the filings evidently were not sufficient to convince the court that it should be covered by copyright. Radix trees are a data structure that are used in various places in the kernel, but the distinction between the code to implement them and the abstraction of the data structure was either not explicitly made or, perhaps, not understood by the court.

It seems clear that Hellwig's legal team did not anticipate the level of detail the court would require to establish the copyrights and where they were alleging that VMware was infringing them. The team also seems to have relied on the kind of evidence that would be compelling to a technical audience, but evidently was not precise enough for the court. For its part, VMware seems to have vigorously defended itself—if no code of Hellwig's can be shown to have been used by the company, clearly the whole argument disappears, thus the dismissal.

SFC also announced the appeal; in it, executive director Karen Sandler lamented that there is something of a mismatch in the resources each side has available to it:

Reading the ruling, it's clear that VMware brought considerable resources to make every possible argument for dismissal. Christoph and Conservancy have a fraction of the resources for our enforcement efforts than VMware has at its disposal.

The money expended by VMware could become a real issue if the appeal is not successful, as the court awarded VMware its costs when dismissing the case. That number is sure to be quite large at this point and will only grow through the appeals process.

The SFC also released a comparison of vmklinux and Hellwig's contributions to the kernel that was done by Bradley M. Kuhn. It shows considerable similarity between Hellwig's contributions and vmklinux. But, perhaps like what was filed with the court, it is a technical analysis, rather than a detailed, line-by-line annotation that the court seems to indicate that it wants.

Hopefully, the appeal is successful in at least getting past the procedural hurdles so that the court can rule on the more interesting (at least to the free-software community) part of the puzzle: whether vmklinux and vmkernel constitute a combined work that is derived from the kernel. Though it won't really set precedents either inside or outside of Germany, a ruling on that question would start to clarify some of the scope of the GPL, which will be helpful to both the community and those who might want to better understand all of the facets of where and how the license applies.



to post comments

GPL compliance suit against VMware dismissed

Posted Aug 18, 2016 18:39 UTC (Thu) by smoofra (subscriber, #86163) [Link] (3 responses)

"whether the two main parts of VMware's product constitute a derived work of the kernel were not even considered"

That's not true. The opinion clearly opines that they are neither part is a derived work of the other.

GPL compliance suit against VMware dismissed

Posted Aug 18, 2016 22:46 UTC (Thu) by chirlu (guest, #89906) [Link] (2 responses)

[citation needed]

GPL compliance suit against VMware dismissed

Posted Aug 18, 2016 22:51 UTC (Thu) by smoofra (subscriber, #86163) [Link] (1 responses)

From the english translation linked in this very article:

"""nor is the Plaintiff’s argument for classifying the “vmkernel” as a “derived work” based on Linux within the meaning of the GPL-2.0 correct in either factual or legal terms."""

GPL compliance suit against VMware dismissed

Posted Aug 18, 2016 23:01 UTC (Thu) by jake (editor, #205) [Link]

> """nor is the Plaintiff’s argument for classifying the “vmkernel” as a “derived work” based on Linux within the
> meaning of the GPL-2.0 correct in either factual or legal terms."""

that's part of what VMware argued, not what the court found ...

jake

GPL compliance suit against VMware dismissed

Posted Aug 19, 2016 18:47 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

It's a *good* thing the court is pushing back against this and demanding high quality evidence. I couldn't care less what happens to VMware, but the last thing anyone needs is an EU venue open to litigation tourism.

GPL compliance suit against VMware dismissed

Posted Aug 21, 2016 19:15 UTC (Sun) by peregrin (guest, #56601) [Link]

I agree. Having read the original version of the ruling I found it rather naive to just present a link to the kernel Git repository plus some output of git-blame and assume the court would do the non-trivial work of separating between simple code refactoring, code merges and addition of relevant code (including authorship clarification).

GPL compliance suit against VMware dismissed

Posted Aug 19, 2016 19:58 UTC (Fri) by Felix (subscriber, #36445) [Link] (1 responses)

> The money expended by VMware could become a real issue if the appeal is not successful, as the court awarded VMware its costs when dismissing the case. That number is sure to be quite large at this point and will only grow through the appeals process.

I'm not 100% sure but I think this does not mean the looser will have to pay VMware's *actual* costs. AFAIK the looser has to pay costs as calculated according to the RVG ("Rechtsanwaltsvergütungsgesetz"). A major factor in that calculation is the "Streitwert" (amount in dispute). However the law assumes that a single lawyer is sufficient for each party (so the cost is basically capped at a sensible amount even if VMware pays a few million for their lawyers).

(Again: I'm not a lawyer and thankfully I did not have to deal with courts in copyright matters so far so I may be off.)

GPL compliance suit against VMware dismissed

Posted Aug 20, 2016 13:03 UTC (Sat) by chirlu (guest, #89906) [Link]

It's capped, yes; the winning party can only claim those costs that were “necessary”, not inflate the amount at will. Still, the costs can quickly get quite high (by the standards of a private individual or a small non-profit organization); in addition to the lawyers’ and the court’s fees, there are travel expenses, payment for the expert witness(es) who will be needed, etc. It is also safe to assume the case will proceed to the Federal Court of Justice in the end, and each of the three levels will of course add to the total cost.

shim drivers and the gpl

Posted Aug 25, 2016 18:10 UTC (Thu) by Garak (guest, #99377) [Link] (6 responses)

disclaimer: my comments are occasionally trollish in nature. I also worked on linux stuff for vmware in palo alto briefly from 2008 to early 2009. For that entire duration I recall the status of the case as having been closed, and not reopened until after I left, thus making it fall squarely into the 'not my responsibility in any conceivable way' category.

That said, much as it probably serves no good purpose for me, I tried to wrap my head around the issue based on the last LWN article. I didn't really succeed, though at some point the similarity between the VMWare situation, and the raspberry pi 'shim driver' to the GPU caught my mind's eye. I wonder if any commenters have any illuminating thoughts on comparing and contrasting those cases of 'shim drivers' and the GPLd linux kernel.

My take from the last LWN article was- company (that I happened to work for briefly) wanted to enhance and sell OS scheduler algorithms. Thus tried to architect a legal way to do that. And I'm sympathetic (more out of personality trait I think than employment history) to the idea that the general strategem of taking an arbitrary FOSS codebase, and basically forking and rearchitecting to allow an API into a new non-GPL codebase, seems nearabouts to a reasonably ethical and legal thing to do. But of course I've long figured out that my fondness for the concept of open source forking, and how I think it should never be frowned upon for such, is at odds with the current political positions of LWN. Whatever...

But trying to express this- the gedanken situation that ran through my mind reading the previous LWN article was- Ok, so I'm trying to imagine this in quake3/openarena terms. This vmware strategem seems roughly akin to an innovator wanting to enhance, and then profit from, improving the AI algorithms in quake3/openarena. I.e. to accomplish the same thing there, you could fork quake3/openarena, and modify/rearchitect the code of the fork to channel all the AI through a new API. Then plug your closed source, or less-than-equivalent-GPL code into that. In the terminology of the lwn article, this is the same kind of loophole/workaroundish thing, whereby to be compliant, you release all the code of that new fork. Which the community then turns its nose up, because it isn't of any use to anyone ... *except* someone who wants to do very nearly the same thing, of working on the AI in complete isolation (even license-wise) from the wider code-base. And while the previous LWN article made this sound like a contribution of 0.000 to the FOSS community, I find myself disagreeing. It sounds to me like there may be a (probably exceptionally small) pool of developers to whom that conformant fork might benefit. Likewise I don't take as granted the assertion by LWN that vmware's conformant release was of benefit to nobody, ever. I mean, if a hundred years from now, some code anthropoligist manages to save 30 minutes of work on some more-or-less toy project by utilizing that vmware loophole fork codeset, does that not count as a benefit to humanity?

Anyway, I figured those barely coherent ramblings were worth posting for the record. I still don't have a strong desire to understand this. As far as I'm concerned, the ethics of international law in this regard are more than I want to deal with in my life. Google censoring tiananmen square massacre related search results still bothers the shit out of me.

shim drivers and the gpl

Posted Aug 25, 2016 20:08 UTC (Thu) by excors (subscriber, #95769) [Link] (5 responses)

> at some point the similarity between the VMWare situation, and the raspberry pi 'shim driver' to the GPU caught my mind's eye.

In the RPi, there is a GPL Linux kernel driver and a BSD-licensed userspace OpenGL driver running on the ARM CPU, communicating over a shared-memory remote messaging protocol to a corresponding driver in the proprietary firmware running on a proprietary CPU.

Those messages are essentially a serialised form of the OpenGL API. The drivers on both sides of the interface were written by Broadcom, and no GPLed code from other authors was included in the proprietary firmware.

In that situation, I think it's clear the firmware is not a derivative of the Linux kernel, and the shipped combination of firmware and kernel seems like mere aggregation - it's no different to any other firmware on the device, apart from using relatively high-level messages. The VMware case sounds very different, with much tighter coupling between the GPLed vmklinux and proprietary vmkernel, since apparently they're both running in the same kernel space and calling functions in each other.

shim drivers and the gpl

Posted Aug 29, 2016 7:40 UTC (Mon) by robbe (guest, #16131) [Link] (4 responses)

I think a more apt comparison is ndiswrapper, a GPL’d "adapter" that sits between a GPL kernel and non-GPL drivers.

Of course, with VMware the direction is the other way around, the driver is GPL’d and the kernel is not. ndiswrapper did not have the intention of "isolating" drivers from GPL. But both it and vmklinux are there to get access to drivers that would not otherwise be available.

shim drivers and the gpl

Posted Aug 29, 2016 18:37 UTC (Mon) by Garak (guest, #99377) [Link] (3 responses)

My openarena/quake3 hypothetical was crafted to imply a similar scenario- Someone wanting to profit from enhanced AI algorithms (not GPL licensed) that would be considerably less useful to customers without the attached rearchitected rest-of-the-videogame code.

Likewise, just about every non-GPL android app also falls into that category. I.e. they are pretty much useless unless attached to a large distribution of GPL code.

Now I grok that somewhere along the line, people try to talk about things at the kernel level, or kernel address space sharing level, being more special or intimate or something. But that is a nuance I think it may be difficult to get across to a jury. (hell, I'm not sure I think I understand it, and I have a computer engineering degree).

I think I'll let my mind dwell on comparing and contrasting the rpi GPU and ndiswrapper cases for a while... For instance, the bit about the GPU being a seperate processor, I have the vague years old recollection like maybe the vmware stuff has an SMP requirement where part of it always runs on a seperate processer/core from the rest. Perhaps something like that plays a part in their big money legal (or not perhaps) profiting from leveraging the wider GPL ecosystem.

shim drivers and the gpl

Posted Aug 29, 2016 19:34 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Likewise, just about every non-GPL android app also falls into that category. I.e. they are pretty much useless unless attached to a large distribution of GPL code.

FYI, the only GPL code present on a typical Android system is the Linux kernel itself -- and by the time you get to typical android apps (ie written in Java) the underlying kernel itself is nearly irrelevant. (There's nothin in the Android Runtime that inherently requires Linux either, witness the Android Runtime stuff on Chrome...)

shim drivers and the gpl

Posted Aug 29, 2016 20:46 UTC (Mon) by Garak (guest, #99377) [Link] (1 responses)

I would go more with a wording of "fairly easily (from a billion dollar corp perspective) replaceable" rather than "nearly irrelevent". After all, that java code makes system calls to that kernel which then makes the hardware do the stuff that translates into the app user getting value/utility. If it's running on chromium on winblowz then the GPL code in chromium and the non-GPL code in winblowz is performing the equivalent function to the linux kernel on the phone.

But despite the fact that at some point vmware and google became large enough companies that writing a dedicated closed source OS for a relatively small set of targeted hardware configurations is run of the mill, I think it bears noting how to come to that Goliath business level, they deftly leveraged the wider GPL ecosystem, perhaps until the point they were big and able enough to transcend dependence on it. I.e. in my openarena/quake3 (pure contrived hypothetical fantasy), the AI innovator makes millions of dollars, then hires a dozen others and sets about the task of rewriting the entire video game code, until no GPL code remains in the picture at all.

I'd note that my personality inclines me more to clever schemes that end up both with myself profiting, and much more widely useful GPL code ending up in the ecosystem. But I find it easy enough to speculate how more ferengi-like players might go at things. (ferengi that are choosing to tactically care about legal compliance, because they have visions that such is their tactically wisest choice in this particular scenario)

shim drivers and the gpl

Posted Aug 29, 2016 21:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Android had its own Apache 2.0-licensed implementation of the userspace (including even libc) from the very first release...


Copyright © 2016, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds