GPL-only symbols and ndiswrapper [LWN.net]

GPL-only symbols and ndiswrapper

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

"This is pure bullshit. The kernel devs are trying to restrict what end users do with their systems, which is as profoundly un-GPL and as un-free as you get. This kind of move is something you'd expect from Microsoft or Apple."

More accurately, some kernel devs are trying to restrict what developers do with their *un-patched code*. It is neither enforcing GPL nor un-GPL. The GPL license permits developers to modify the GPL'd kernel, but restricts the licensing and distribution of that modified code. GPL doesn't say that GPL'd code should be equally friendly to all usage. As a relevant point of interest, distributing together a kernel, an ndiswrapper, and the binary drivers that people want to use ndiswrapper with would be a GPL violation. Since that distribution isn't in question, what we are talking about is just a preference by the developers for making their unpatched code unfriendly to such usage (distributed or not). That is not surprising, but it is controversial because it hurts some users.

Is the policy good or bad? Tt comes down to weighing conflicting interests of some end users and some kernel developers. Also relevant is the technical question of how much work or difficulty is involved in making ndiswrapper work with the GPL SYMBOL stuff.

to post comments

GPL-only symbols and ndiswrapper

Posted Oct 26, 2006 14:43 UTC (Thu) by malor (guest, #2973) [Link] (3 responses)

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.

GPL-only symbols and ndiswrapper

Posted Oct 26, 2006 16:12 UTC (Thu) by josh_stern (guest, #4868) [Link] (2 responses)

There is a kind of argument that arises with GPL about what is a derived work and what is mere aggregation. Lots of people would argue that shipping the Windows binary drivers with ndiswrapper makes a derived work and not a mere aggregation, in which case that would be considered a GPL violation.

GPL-only symbols and ndiswrapper

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

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.