Slashdot Mirror
Linus Denounces NDISWrapper, Denies It GPL Status
eldavojohn writes "On message boards, Linus Torvalds was explaining why NDISWrapper is not eligible to be released under the GPL even though the project claims to be. Linus remarked, "Ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL'd." This all sprung up with someone restricted NDISWrapper's access to GPL-only symbols thereby breaking the utility. Linus merely replied that "If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols." As you may know, NDISWrapper implements Windows kernel API and then loads Windows binaries for a number of devices and runs them natively to avoid the cost and complication of emulation."
-- Linus, in this post
Before people flame Linus for whining, or trying to sabotage Linux users' ability to run drivers that they need, look at how OpenBSD handled this matter. They too rejected ndiswrapper, and ended up putting their energy towards reverse engineering wireless drivers instead. The results were positive, and in some cases the Linux folks ended up picking up their code too.
And, when you write an open driver, you can maintain it more effectively. You can check it for security problems. You can fix its bugs. With ndiswrapper, you are putting a completely unknown blob of code inside your kernel and trusting it. This is never a good idea when other alternatives exist!
So, use ndiswrapper if you feel that you absolutely must... But it shouldn't receive any official endorsement that would cause most users to be dependent on it. Kernel developers shouldn't think of the wireless driver issue as a "resolved" one. The ideal situation is to reverse engineer a free driver.
As ridiculous as it may sound, it's theoretically possible for a Windows driver to be licensed under the GPL. Thus, no legal troubles when loaded by ndiswrapper :)
Summary is missing a HUGE portion of what actually happened. The discussion continued. After the discussion, Linus applied a patch to ALLOW access to GPL_ONLY symbols (for those who care, it's git commit 9b37ccfc637be27d9a652fcedc35e6e782c3aa78).
Look at the second entry from the top in the changelog:
http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.25-rc4
The battle is over, the discussion is at end and Linus has already signed off a change to restore Ndiswrapper functionality.
the difference is in how the kernel project uses the "GPL only" flag versus actual legality.
.docs, and so on. As NDIS doesn't DISTRIBUTE the program WITH the windows drivers (they don't own that code) it's perfectly fine for their "emulator" to be GPL same as an emulator for a Nintendo NES system.
It's perfectly legal for NDIS to be GPL because all of the code they provide is open. That's the legal standard. That the USER loads non-GPL modules at runtime is a known loophole.
Lots of other projects use GPL for the same thing... Console emulators, word processing programs that read binary
Linus Uses the flag for people like Nvidia who it's NOT OK to use the GPL for their drivers because they own and distribute the binary code AND the wrapper in the same package. It's not legal for them to claim to be GPL. But in this case NDIS is only liable for the part they distribute and the user is responsible for how the program is used on the system. The license is fine it's just Linus is assuming that a "license flag" will cover all the programming options (so they can deny support) when that's not the case.
The stance isn't as crazy as the context-free summary makes it out to be. Linus isn't talking about the license for the ndiswrapper code. He's talking about access to kernel functions which have been marked as "GPLONLY". These are functions which are intentionally not exported to non-GPL code. Linus is saying that allowing ndiswrapper to use them is equivalent to allowing calls from non-GPL windows binary drivers. Which is true.
The debate then is whether or not this should be considered a problem. The contributors who added many of the GPLONLY functions may have different opinions on the topic. Linus hints that the contributors for the USB functions would prefer a strict interpretation and deny ndiswrapper access to the GPLONLY kernel-level functions, because there is a perfectly good user-space API. But everyone involved agrees that ndiswrapper is will never live in user-space, because there's no programmer who would do it and it's a crazy idea anyway. Anyway you slice it, it's clear that ndiswrapper will get fixed one way or another, and nobody is accusing the ndiswrapper project of misusing the GPL.
In summmary, it's a tempest in a teapot: someone accidentally broke ndiswrapper, kernel API discussion ensues, Slashdot posts inflammatory summary, life goes on.
NDIS wrapper might itself be GPL but a kernel that uses it is not because the kernel is monolithic. Linus is actually giving everyone what they want.
What is this about GPLONLY symbols?.
Loading a non GPL kernel module makes the whole kernel non GPL and hard to debug because it's a monolithic program. Check out the Linuxant controversy of 2001.
Linus won't keep you from making and loading non free modules but he's not going to be responsible when changes break your module. If others would cooperate, this would not be an issue. The NDIS wrapper people will have to reimplement functions written by GPL strict coders. That kind of sucks for them but they can do it. If Linus were to piss off the GPL strict coders, NDIS wrapper still would not work because those coders would quit contributing. A project as large as the kernel demands give and take. GPLONLY was a nice compromise.
NDIS wrapper has never been a great idea. It puts you at the mercy of Microsoft bugs and malice all for the benefit of a $30 network card. The kind of card that needs NDIS wrapper is usually worst of class and should be shunned. It's brain dead much like a winmodem and the "firmware" game is intentional. The card maker wants to be Windows only so don't buy it. Sooner or later hardware vendors will have to come around.
it's quite important to understand the issue, i think. :) ) - nobody is _breaking_ anything.
:)
it has been repeated in the thread several times already, but i'll try again (from my, outsider viewpoint, but i'd hope somewhat educated one
short interpretation by me :
kernel has a variable which denotes that it is gpl only - that is, the core and all loaded modules are gpled.
this shows to people trying to debug things that they can debug everything and there are no binary modules that break shit in unexplainable ways.
now, if a binary module is loaded, kernel notes in the variable that it is no more gpl only and breakages can be extremely hard to debug and impossible to fix. i guess you'll agree we don't want the kernel devs to waste time on such cases.
now, ndiswrapper itself poses as gpl, thus it does not taint the kernel, but it then loads modules inside itself...
so you get a tainted kernel that does not identify as one.
and that is the only behaviour which is going to change.
if i have misunderstood things miserably, correct me, thanks
Rich