shim drivers and the gpl [LWN.net]

shim drivers and the gpl

Posted Aug 25, 2016 20:08 UTC (Thu) by excors (subscriber, #95769)
In reply to: shim drivers and the gpl by Garak
Parent article: GPL compliance suit against VMware dismissed

> 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.

to post comments

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...