GPL-only symbols and ndiswrapper [LWN.net]

GPL-only symbols and ndiswrapper

Posted Oct 26, 2006 14:43 UTC (Thu) by malor (subscriber, #2973)
In reply to: GPL-only symbols and ndiswrapper by josh_stern
Parent article: GPL-only symbols and ndiswrapper

Actually, after thinking about it, I'm not sure it would be illegal to distribute that way. A Windows driver isn't a derivative work of Linux, period.

If someone could get permission to distribute the drivers, I suspect it might be perfectly legal to distribute Linux (GPL), ndiswrapper (GPL), and Windows binary drivers (non-GPL, but not a derivative work.) I don't think a Windows driver could be considered a derivative work even if distributed this way. I could be wrong. This is at least a little gray, but it's certainly much less egregious than Tivoizing the code, which the kernel devs are perfectly happy with.

I don't think there's any way AT ALL that this can be painted as a GPL issue. It's just kernel devs being assholes, and using the GPL flag to do so.

They are abusing their users, and I would encourage distros to just disable the 'taint' code in their kernels. It's being misused.

(Log in to post comments)

GPL-only symbols and ndiswrapper

Posted Oct 30, 2006 23:21 UTC (Mon) by tbird20d (subscriber, #1901) [Link]

Lots of people would argue that shipping the Windows binary drivers with ndiswrapper makes a derived work and not a mere aggregation,...

Lot of people would be dead wrong. This idea that shipping two things on the same media somehow turns one of them into a derivative work of the other is asanine.

GPL-only symbols and ndiswrapper

Posted Nov 2, 2006 12:50 UTC (Thu) by arcticwolf (guest, #8341) [Link]

First of all, let me say that IANAL, so you should disregard everything I wrote here - including this line. ^_~

I think the real question is why and how a driver was written. If a hardware vendor wanted to create a Linux driver for a product without GPL'ing it and still use GPL-only symbols, they could - from a technical perspective - create a GPL'ed wrapper module that doesn't really do anything other than providing a "GPL-proof buffer" between the kernel and the real driver.

However, that obviously would be piracy^Wcopyright infringement; the real driver would be a derived work of the Linux kernel.

The other "extreme" is what ndiswrapper is like: here, the "real" driver is not written with Linux in mind at all and was never supposed to run on or interface with Linux. Clearly, as you say, one cannot claim that such a driver would be a derived work of Linux, and I think - hope - that any lawyer making such a claim would be laughed out of court.

There is a gray area, too, of course. What if a company writes a driver for windows, and then *later on* decides to make it work on Linux as well by creating a wrapper module? I'd like to say that this isn't legal, but I'm not sure how one could argue that a piece of code that was already written a long time ago can retroactively become a derived work of something else (Linux, in this case). Things get even less clear when you consider updates to the (non-GPL'ed) driver: would a fix for a bug that only shows when the driver is used with Linux instead of windows make the driver a derived work of Linux, for example? I have no answer to this.

But that's not the kind of situation at hand, fortunately. As others have pointed out, the core of this dispute is not copyright: ndiswrapper does is licensed under the GPL and does not violate the copyright(s) of the Linux kernel developers.

The *real* question is whether the kernel developers have a moral right to do what they did - that is, whether it's acceptable to try to interfere with uses of a piece of free software (which it is in practice, even if it's not "officially" designated Free Software(tm)). I don't really have an answer to that, either, but given that the whole thing is mostly symbolic, anyway (it's trivial to change this again, and since ndiswrapper does not violate the GPL, distros can make this change without having to worry about violating copyright themselves), I would be happier if the kernel developers refrained from this kind of politics.

And politics it is: enforcing the GPL and insisting that contri- and distributors abide by it is laudable, and not caring about whether a change makes life more difficult for proprietary code etc. is certainly OK, too, but a change that *only* exists to do that and that does not have any other raison d'être... that's asinine.

And what's more, given the kernel developers' criticism of the GPL v3 and their insistence that as far as the kernel is concerned, only the GPL v2 matters, it's hypocritical, too; if the GPL v2 really was all that mattered, this change would not have been added to Linus' tree.

So even though I agree that proprietary modules are bad, and even though I have mixed feelings about ndiswrapper (on one hand, scratching itches is a good thing, but on the other hand, it's not good if band-aid prevents a real solution to a problem), I think that this change was a bad thing that should be reverted as soon as possible. Let's not get political.