shim drivers and the gpl [LWN.net]

shim drivers and the gpl

Posted Aug 25, 2016 18:10 UTC (Thu) by Garak (guest, #99377)
Parent article: GPL compliance suit against VMware dismissed

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.

to post comments

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