Linus Denounces NDISWrapper, Denies It GPL Status 457
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."
shim? (Score:3, Interesting)
-b
.... right .... (Score:2, Interesting)
I've been hearing that for 10+ years now, and this is a prime example of where the Linux folks miss the boat.
Do you really think my parents give a rolling fig about GPL vs. non-GPL code, who's exporting who's symbols or any of that? They just want their damned wireless Internet to work...
Time to re-arm and focus on the enterprise - you stand a shot there. But even there - it needs work. Stability, for one. A Red Hat box that is out of date the day we deploy it does nobody any good. A real patch management strategy would be nice.
Binary compatibility for another. I can pick up an HP-UX PA-RISC 9 binary, drop it on an HP-UX 11.31 Itanium system and it _just runs_. Same holds true for Sun -- drop a SunOS 4 binary on a SunOS 5.10 (yes, that's Solaris 10) system, and it _just runs_.
Once Linux can do that - without recompiling, without having to resolve mutually exclusive dependencies - you just might give enterprise Unix a run for the money. Oh, and you'll have to scale up to 128+ processors too. Again - HPUX and Solaris both do that fine.
I'd have to disagree with his logic (Score:3, Interesting)
There may be a valid argument for saying that ndiswrapper can't be GPL'd, but this isn't it. In what context would this sort of reasoning be considered sound?
...and so on. The claim may be valid but this argument certainly can't be used to establish it.
--MarkusQ
And this licensing bit is necessary why? (Score:1, Interesting)
I understand that it's not a good thing to have mysterious binary glomps everywhere and that it would be better to have proper drivers and such than to have to use these sorts of wrappers. But realistically the only way that most manufacturers and software outfits are going to take users of OSI sanctioned environments seriously is if we can show them the cash flow. Which is significantly easier if you can point to a contingent of their own customers that are already using their software or hardware.
Is it really a ZOMG Linux users might be able to use a Windows driver situation? Or can people just set aside their own personal pettiness and realize that open source OSes typically have had to spend a lot of time and energy writing and maintaining drivers. Some companies aren't going to come around no matter how many installations there are. But it's rather hard to proselytize when an important bit of hardware doesn't have an appropriate driver. If most Windows drivers of a type can be made to work with an appropriate wrapper, that means that developers can focus on only rewriting the drivers which have bugs or aren't performing well. I'm sure the performance wouldn't be as good as it would've been with native drivers, but having the hardware available at all is better than none.
Ultimately it does just come down to money, if your distro/OS of choice can show the manufacturer a meaningful amount of business at some point there's enough profit there that they're going to want to tap into it. At the end of the day you've got to choose, no cost or access to quality commercial software. Even if they don't do so actively, they're more likely to be mindful about not doing things that unnecessarily break wine compatibility similar problems.
I may have missed the memo, but FreeBSD has had project evil for quite a while now, and I don't recall having seen any evidence that the OS is worse for having that option.
Re:Linus making friends fast (Score:3, Interesting)
but it is his tree so if he says it is not GPL compatible then it's not GPL compatible.
for the record, I have to agree with Linus on this one (but thats me and who am i).
Re:It can load GPL-licensed Windows drivers (Score:5, Interesting)
I bet the number of GPL'd NDIS drivers for Windows can be counted on one toe. I myself started writing an NDIS 6 driver for a chipset that has no native Vista drivers (although the NDIS 5 XP driver works on Vista x86) but have recently lost interest, despite almost completing basic functionality, because I realised I will never be able to use it under Vista x64 due to the OS's draconian driver signing policy..which cannot be disabled.
Re:Can you be any more childish? (Score:3, Interesting)
That and Linus changed his mind shortly after this was posted to Kernel Trap. Read a few comments up.
Re:Linus making friends fast (Score:3, Interesting)
To quote the Register, [theregister.co.uk]
"So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative." he writes.
And in today's lesson... (Score:3, Interesting)
It's kinda like the Quake III engine. That's been released as open source, and there's an awful lot of games out there that make use of it. But it still relies on a binary blob that is itself rarely released as free. That doesn't make the engine itself any less free/open.
Mod parent up (Score:-1, Interesting)
The real debate is why we still have the GPLONLY flag. It's clear that the developers intended it as a method to signal to modules which sections of the kernel code are just interfaces, and which are considered "part of the kernel" in terms of derived works, but that shouldn't start a technical arms race with module developers! In cases like this, such a restriction is less about technical enforcement of legal boundaries (of which ndiswrapper is on the correct side), and more about pushing Linus's or others' political ideologies.
Re:Linus making friends fast (Score:5, Interesting)
GPL Process separation and derivative works (Score:3, Interesting)
Do not flame me for what I am about to write as it is my understanding of RMS' guidelines, if you have a problem with it, take it up with him.
To clarify what is and what is not a derivative work, the GPL and its supporting documents claim that a GPL work is not how self contained as it may seem i.e. shared libraries or loadable modules, but whether or not it inhabits the "process space" of the GPL work.
When a non-GPL module is loaded into the process space of a GPL application, it violates the GPL license of the application. This is why NDIS wrapper violates the GPL because its job is to load non-GPL code into the process space of the kernel, thus tainting it.
Do I agree? I'm not sure as I can see both sides of the argument. One side is that the module is self contained and isolated. The other side is that one of the purposes of the GPL is to protect the work of the people who contribute frm being unfairly used. It can be argued that the NIC card vendors who's drivers are enabled by NDISWrapper are unfairly enriched by the work of GPL developers in that their proprietary hardware is supported on a free platform without themselves being free.
It MIGHT be GPL. (Score:3, Interesting)
Say, I release a game which requires DirectX, links against the proprietary library, depends on it. It can't be GPL. But if I make the game run on both DirectX and SDL, it's enough to make it GPL. It's not crippled by lack of DirectX, it's just a user's choice, a preference to use it.
This way NDISWrapper just -could- be GPL if only someone writes GPL counterparts of the modules it uses. It would mean then, that it's a generic module wrapper which can load a variety of modules, GPL or not, and it's up to the user to feed it the restricted ones in place of the free ones. It may load any -generic- modules, but it should have no provisions towards any specific restricted modules without having an equivalent free part.
Re:You can't win this one, Linus (Score:3, Interesting)
32bit vs. 64bit has always been nearly completely transparent to the user on Macs (remember the G5 is 64bit). So it is possible to design a system where the differences are hidden. But of course a lot of that transparency is due to Apple having control over the hardware and drivers. It also helps that building and distributing multi-architecture binaries on the OS X is trivial. You can have one binary that works natively on ppc32, ppc64, x86, and x86_64 with just a couple options selected in Xcode. Or gcc flags, if you're building stuff on the commandline.
-matthew
Why we need NDISWrapper for Linux (Score:3, Interesting)
That is the Achilles heel of Linux, lack of third party driver support. Heck that's the Achilles Heel of any Non-Windows operating system be it OS/2, BeOS, AmigaOS, even Mac OSX. One OS, ReactOS, is trying to implement Windows' WDM driver model in GPLed software so that ReactOS can use Windows drivers. I would like to see Linux have the ability to use Windows drivers via some GPLed software, so Linus can borrow that from ReactOS, or write it from scratch, or maybe the WINE team can make a Linux module that loads Windows drivers for Linux that uses the WINE libraries.
I have myself gone through several different wireless cards to get a Linux desktop working and eventually I gave up because I couldn't find a Linux native driver that wasn't flaky or lost the connection, and the only success I had was with NDISWrapper, but as soon as the Linux kernel is updated it breaks NDISWrapper forcing me to recompile the code and reinstall the Windows drivers.
In fact, I have a Linux desktop near my wireless router that uses a CAT5 cable to hook into it and then use VNC from a Windows desktop in another part of the house to log into the Linux system that way. It would be nice if I was able to get good wireless networking support from a Linux native driver without losing the connection or going flaky on me. But I suppose I'll always have a VMWare Virtual Machine to use as well if I wanted to run Linux from any part of my house and not just where the router is located.
Re:its against US law (Score:3, Interesting)
Hello, that is some interesting information, would you care to elaborate (some links or other citations would be nice). I am authentically interested in your claim as I have never heard about such thing.
Re:You can't win this one, Linus (Score:3, Interesting)
How do I run this "GPL" solution on my Sparc-based Linux system? The card is PCI but the binary that gets loaded runs on Intel-only. So it's compatible hardware, and software that claims to be GPL, but the system is a doorstop.
So, you're hosed. That has nothing to do with me. NDISWrapper works for me. You solve your own problem, in ways that don't try to deny me my workaround.
NDISwrapper is not a bandage, it is a Typhoid Mary allowing proprietary software to infect the kernel.
Oh, get over yourself. It's a workaround. It solves nothing but a user's immediate problem: using hardware with no native support.
"Buy supported hardware" is not always an answer. Yes, it's the best solution, but sometimes you have no choice except either use what you've got the best you can (including ugly kluges like NDISWrapper), or use nothing at all... and that's never a solution.
Yeah, there are numerous pragmatic limitations to crap like NDISWrapper. Non-GPL taint warnings are there for a reason: to remind you that you may chase a problem into the dank impenetrable thicket of the proprietary driver... at which point you're SOL. Likewise if you need features the NDIS driver doesn't support.
But in a few cases, the choice is between doing something distasteful and doing nothing at all. And that is neither a valid choice or an absolutely necessary one as long as everyone involved is honest and aware of the limitations and compromises involved.
And calling NDISWrapper "Happy happy GPL joy" isn't either honest or mindful of the very real issues. But hyperbolizing it as a disease vector isn't either.
Re:Linus making friends fast (Score:3, Interesting)
If it doesn't work out of the box, I don't much care that it's superior. I'm tired of "learning how the system works" for the 1000th time. Not all toil is virtuous.
explain how this violates gpl please (Score:3, Interesting)
Can someone explain to me how creating a computability layer for a proprietary model inherently violates GPL? Linus is trying to claim that loading the Windows Driver violates GPL. But I really fail to see how, ndiswrapper is a computability layer, and itself GPL'd, the windows driver is not loaded into the kernel like other modules it is sandboxed by ndiswrapper. It edges towards that gray area of the GPL, but itself doesn't violate it.
Great link! (Score:3, Interesting)
Thanks for the link to the discussion on Rosenlaw. That's a great link. I'm not sure I *completely* agree with Rosen - the one point where I think he might lose the argument is that statically-linked binaries are not derivatives. I understand where he's coming from - he's trying to find the simplest definition of derivative work.
But the problem is, a statically linked binary *does* contain your original work in part or in whole. In my earlier post, I put forth a statement of principle that, where there is no copying, there can be no copyright infringement. I think most reasonable people can say that the converse of that holds as well - where there is copying (without permission), there is copyright infringement.
Although, I suppose possibly what Rosen is getting at is that it would be possible for me to ship the original static library source code, and so fulfil the obligations of the GPL wrt providing access to the source code for the original work, and that my binary is not a derivative work. But, I think that still may be a weak argument.
Man, I don't know. It does get rather complicated. I mean if I dynamically link, and distribute the GPL
But, we can't let the GPL be too strong, either. I really think these issues of loading proprietary drivers with GPL wrappers like NDISWrapper really expose the absurdity of the 'dynamic linking violates the GPL' idea, too.