A GPL-enforcement suit against VMware

Posted Mar 6, 2015 9:43 UTC (Fri) by jsanders (subscriber, #69784)
In reply to: A GPL-enforcement suit against VMware by jpfrancois
Parent article: A GPL-enforcement suit against VMware

It's an interesting question. If somebody were to write a shim allowing Linux modules to load into a BSD or Windows, providing the same API as Linux, why would a module that could legitimately be used for either count as a derived work of Linux? That is unless providing an API for compatibility counts as a derived work, which opens up another can of worms.

A GPL-enforcement suit against VMware

Posted Mar 6, 2015 10:05 UTC (Fri) by jpfrancois (subscriber, #65948) [Link] (1 responses)

But is it possible to write such a shim to load linux driver on an otherwise unmodified kernel ?

In other words, given the complexity and non stability of the internal linux API, the shim is a derived work for sure.

From the shim, you can probably tell if the function called by the shim and belonging to the core kernel are generic core kernel function, or have an API so similar to the Linux one that it makes it a derived work.

A GPL-enforcement suit against VMware

Posted Mar 6, 2015 17:03 UTC (Fri) by mjthayer (guest, #39183) [Link]

> But is it possible to write such a shim to load linux driver on an otherwise unmodified kernel ?

I might be wrong: haven't the Genode[1] people done just that? Antti Kantee also discussed something like this as part of his talk[2] at FOSDEM.

[1] http://genode.org/
[2] https://fosdem.org/2015/schedule/event/what_is_wrong_with...

A GPL-enforcement suit against VMware

Posted Mar 6, 2015 16:38 UTC (Fri) by fuhchee (guest, #40059) [Link] (2 responses)

The more analogous question is whether Windows or MacOS would have to become deemed "derived works" of the linux kernel module, just because a GPL'd shim allowed those lkm's to be loaded into those other kernels.

A GPL-enforcement suit against VMware

Posted Mar 6, 2015 22:35 UTC (Fri) by realnc (guest, #60393) [Link]

That's not really relevant, since the GPL only affects distribution to the general public (as the name of the license implies). If you were to distribute parts of Windows, then this would apply. But it's an absurd thought :-) You'd be violating MS's copyright to begin with.

A GPL-enforcement suit against VMware

Posted Mar 7, 2015 15:13 UTC (Sat) by smurf (subscriber, #17840) [Link]

No. If you write shim code to get a Linux driver to run on BSD, your code becomes a derived work.

You cannot create a derived work of Windows because (a) you're just talking to it and (b) you can't derive from something you don't have access to, and I presume you don't have Windows source code lying around.

However, from what I understand, in this case it's the other way round: vmware created a massive derived work from the Linux kernel, added a proprietary-but-documented API to that, declared that API to be a border between GPL space and not-, wrote various closed-source things for that API, and expects to get away with it.

The problem with that line of reasoning is that the kernel was there first, so the API itself is a derived work, and thus so is anything coded to it. The kernel devs clearly did not intend that to happen, and presumably vmware knew this and did it anyway.

Courts tend to not like you when you do that.

A GPL-enforcement suit against VMware

Posted Mar 7, 2015 14:49 UTC (Sat) by smurf (subscriber, #17840) [Link]

Such a shim would be OK because the BSD license allows it. The aggregate (Linux drivers plus BSDish kernel) would then be redistributable under the GPL only.

Here, however, vmware used neither the syscall interface nor the module interface (which is usable by closed-source modules, if you buy the legal fiction that since some symbols are exported GPL-ONLY, the rest must therefore be exempt from that restriction); they simply created their own. Which makes their code a derived work.

I assume that they invented this API from scratch. This would make any code using it a derived work, too. If they didn't (i.e. the API existed in some form before they forced the Linux kernel into its mold, or vice versa), this trial will might become more interesting than we'd like.

A GPL-enforcement suit against VMware

Posted Mar 11, 2015 6:00 UTC (Wed) by bug1 (guest, #7097) [Link] (3 responses)

If the code cant do "its thing" by itself then it cant be considered an independent work, it must be a derivative of something.

A GPL-enforcement suit against VMware

Posted Mar 11, 2015 11:10 UTC (Wed) by mpr22 (subscriber, #60784) [Link] (2 responses)

That's a rather awkward position, since it immediately raises the question "OK, so what are my C and C++ programs derivative works of?" since they can't do their thing without a language runtime and a CPU.

A GPL-enforcement suit against VMware

Posted Mar 11, 2015 11:22 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (1 responses)

Which is why many runtimes/libraries have explicit linking exceptions in their licensing. E.g. http://www.gnu.org/licenses/gcc-exception.html . Most of those specifically prevent the runtime's license to affect the running program.

A GPL-enforcement suit against VMware

Posted Mar 11, 2015 16:20 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

There the resulting executable contains pieces of the runtime/library. The discussion at hand is around the case where there are no direct code inclusions. I.e., is a program written in the C of K&R a derivative of the book, even if no lines of code were copied from the examples?

An interesting case in point is the readline library (GPLed). The FSF claimed any program using its API had to be GPLed, until the BSD-licensed editline library came around, with the same API...