GPL-only symbols and ndiswrapper

Posted Oct 26, 2006 23:43 UTC (Thu) by filipjoelsson (guest, #2622) [Link]

A lot of "probably" in there.

The nvidia binary module is developed for Windows. Ndiswrapper is a shim to load proprietary drivers developed for Windows, exactly the same as the nvidia shim is. The only difference is that ndiswrapper is a generalized framework whereas the nvidia shim is specialized for just one driver.

So the following question is perfectly valid: Why should ndiswrapper use GPL-symbols when the nvidia shim can't? Both are shipped as source, and ndiswrapper relies on the user providing the proprietary driver.

Posted Oct 25, 2006 21:08 UTC (Wed) by drag (guest, #31333) [Link]

Like maybe spend their time working on something like the BCM43xx drivers instead which eliminate 90% of the reason for having ndiswrapper drivers in the first place? No joke it's silly to be pissed off about this when they've made allowances for NDIS wrapper in the past. Do you remember the 4k vs 8k kernel stacks and the effect it made on supporting ndiswrapper?

We now have open source drivers aviable for virtually every single wireless device you want. But it depends on distributions for testing and support. The kernel developers can't do it all by themselves..

So they work hard on this support.. The broadcom driver now has decent in-kernel driver. It's not perfect, but it works. This, along with the intel drivers, give you support for the vast majority of 802.11g devices out there.

And as a response to this what do you see happenning? Instead of distribution beta testers troubleshooting these things and sending in bug reports and such so that people can improve on support you get a crapload of howtos on Ubuntu's websites and other distro's websites on how to blacklist the open source drivers and install the ndiswrapper drivers in their place

What sort of BS is that? It's almost like a slap in the face of the people that went through the trouble of reverse engineering the broadcom drivers for driver documentation and a whole 2nd set of people using that documentation for writing decent drivers!

And the same thing with the Ralink drivers. The ralink company released documentation and source code and you have people telling end users that they should blacklist those drivers also and install ndiswrapper!!

To me that is complete bullshit. Distros should work on getting those things working well and ndiswrapper should only be used if nothing else using open source drivers can be made to work in a sane manner.

I know nothing is perfect and that ndiswrapper is legitament way of getting oddball hardware to work.. but maybe, just maybe the Kernel developers are tired of putting up with this crap themselves.

Posted Oct 30, 2006 14:23 UTC (Mon) by liljencrantz (guest, #28458) [Link]

Isn't a distributor also usually an end user? Shouldn't the rights granted to a distributor also be granted to an end user?

For example, many GPL:ed pieces of software are licendes under GPL2 or later. So the end user may choose if he accepts the license terms of GPL2, GPL3 or GPL4. But does that mean that any user may download the source of a package, accept the license terms of GPL2, modify the package and then release the resulting derivative work under GPL2 only?

Posted Oct 26, 2006 17:38 UTC (Thu) by pizza (subscriber, #46) [Link]

Yeah, but how are those userspace drivers supposed to talk to the rest
of the kernel and the non-GPLONLY functions and services it provides?

What if you need other kernel services? What if you have tight timing requirements?

From what I can tell, the userspace usb stuff basically sets you up to
do URB tx/rx, but nothing more. It's useless if you need to hook into the rest of the kernel.

For many types of devices, userspace drivers make sense, but that should be a *technical* decision.

Posted Oct 25, 2006 22:44 UTC (Wed) by lutchann (subscriber, #8872) [Link]

People would laugh at my face if I told them that they had to pay money and modify their laptop instead of deleting two lines from the kernel source.

OK, then all you have to do is help them patch and recompile the kernel every time they need to update, and everything will be fine. As many other posters have pointed out, there's nothing in the license that prevents you from doing this.

The best option is for as many people as possible to use Linux (and to want to use it) and to have it as functional as possible. Then those people are more likely to buy Linux-compliant hardware next time.

I'm not sure I follow your reasoning there. It seems more likely that if we compromise and allow them to install proprietary drivers today, they will expect us to compromise and allow them to install proprietary drivers next time.

Posted Oct 25, 2006 23:03 UTC (Wed) by gmaxwell (guest, #30048) [Link]

>> are trying to use hardware for which there currently exists free drivers

>I didn't realize that, though personally I haven't had to use ndiswrapper yet.
>I guess most people expect that if a free driver was available, it would be autodetected. From a user's perspective, downloading a free but beta driver from sourceforge (because it isn't included in the distribution) is probably worse than using ndiswrapper, which happens to be included in the distribution (and they already have the Windows driver because they are probably dual booting).

Some drivers (Intel is the perfect example) will not grant permission for third parties to distribute their firmware, so they can't be made to work automatically.

But yes, in some cases it's a free beta driver... yes, NDIS wrapper might be easier once (although you learn a bad habbit that will be unneeded later, you lose support, and you introduce weird bugs (which NDISwrappered drivers do .. It's not unfounded FUD that I'm spreading :))), but if you want to go for the easiest solution, we're back to "buy a system preloaded with the OS you want" as the easiest.

>I don't think this is a reasonable option, except for geeks and true enthusiasts. While I personally would do that, I wouldn't dare recommend it to anybody who asks me for help with their laptop. I especially wouldn't recommend it if their laptop happened to be working one hour ago, until they upgraded their kernel.

Upgrade the mini-pci card themselves? Perhaps not (although it is userservicable on most laptops)... but they could have it done. I think you over estimate the prospects of someone laughing about it, often in the windows world people have to pay for silly solutions. In any case, it's not as simple as "modify two lines" ... Ndiswrapper is a hack of a solution and I think most people can appricate "make it work with duct tape" vs "spend $50 and do it right".

> While that is true, not all people are using Linux with the idea of testing it and putting up with problems. If the free driver is in any way less functional than the NDIS one, they have zero incentive of using it.

In the case of the intel drivers the NDIS driver is less functional, yet people are using it. Generally the NDIS drivers have poor integration.

>The best option is for as many people as possible to use Linux (and to want to use it) and to have it as functional as possible. Then those people are more likely to buy Linux-compliant hardware next time.

Of course, if the drivers compromise the stability of their systems, they may not have any reason to continue to use Linux. Its a fine line.

>That is an excellent question. Why not run Linux in VMWare under Windows ? I really don't know how I could explain that to my wife for example (if she knew what VMWare was). Most laptops come with Windows anyway. Why not really ?

As you said, less memory.. somewhat lower performance.. You suffer all the bugs of Windows and linux. But to hear Microsoft advocates argue, the drivers are the weakest link in Windows stability... so perhaps you're no worse off with ndiswrapper than windows + vmware.

It's a personal decision and the answer depends on what hardware you have and why you are using Linux.

In my case, the hardware I use is usually much better supported in Linux (good luck finding windows vista drivers for random SCSI controllers, T1 interface boards, 900Mhz pre-802.11 radios, etc)... and none of the software that I'm interested in is Windows only. ::shrugs::

The reality is that once you've decided that running Free Software is a non-issue for you (by adding binary nvidia drivers, ndiswrapper, etc)... And that stability/supportability isn't an issue (by running ndiswrapper with drivers outside of their intended/tested enviroment)... You might as well run Linux in VM. Nothing wrong with that.

Posted Oct 26, 2006 22:32 UTC (Thu) by k8to (guest, #15413) [Link]

You presume a single agent where there are many.

Such a daemon would really need to be set up by the distribution, who are in a better situation to drive users towards free drivers in the first place, by autoinstalling them. Such a further steps seems a nuisance to me.

"I just installed NDISwrapper after repeated crashes from the free driver, and this stupid popup is complaining that I should go back, what a joke!"

Maybe that wouldn't happen, but I do not like this style of solution.

The kernel developers are -- via technical means -- conveying to kernel-driver developers what they believe is a fair manner of use of their code by proprietary modules. This is completely reasonable. The debate is in the details of how they go about it.

Posted Oct 25, 2006 23:53 UTC (Wed) by sfeam (subscriber, #2841) [Link]

Please see above.
There is no difference between the GPL and the LGPL except for a promise not to argue. ndiswrapper is not LGPL, so we are inflicted with the argument.

The GPL/LGPL does not prohibit linking to non-GPL code. It only restricts, potentially, the distribution of such a combination. That is not the issue here. Rather we are concerned about end use, which is outside the purview of the GPL. Some people may also be opposed to the end use, but they must find some mechanism other than a claim of GPL infrigement to exercise that opposition.

Posted Oct 26, 2006 3:18 UTC (Thu) by interalia (subscriber, #26615) [Link]

It depends on the ability to link with proprietary stuff in order to do what it is intended to do.

This same assertion about ndiswrapper happened on the Debian mailing lists, regarding whether it was non-free. Some people argued that nothing prevented you using ndiswrapper to load a GPL-licensed Windows driver, were such a beast to exist. Since ndiswrapper's own license doesn't preclude the loading of a GPL (or otherwise DFSG-free) driver, it didn't therefore deserve to be in non-free. Or, indeed, you might be writing Windows drivers and want to try loading them in ndiswrapper.

This was a contentious point, and although I personally feel the logic makes sense, others felt the practical reality that there is currently no free driver overruled this and consigned ndiswrapper to non-free. I seem to recall a slim majority holding to that latter viewpoint, though the maintainer himself felt it was suitable for main and no-one requested Debian's Technical Committee override his decision.

Posted Oct 26, 2006 8:05 UTC (Thu) by malor (guest, #2973) [Link]

But at no time is the GPL ever violated. The GPL says we can't distribute free- and non-free code (either in source or binary form) together. But nobody is doing that.

Ndiswrapper itself is GPL. The kernel code is GPL. Windows binaries are never GPL. You could certainly make the argument that distributing all three of these together violates the GPL, but *that is not what is happening here*.

Rather, they seem to be upset that end-users are using ndiswrapper to load proprietary drivers. But an end-user who uses ndiswrapper to load a Windows binary is NOT VIOLATING THE GPL, because he is not distributing it.

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.

Fortunately, they have a lot less power to enforce their edicts, since their changes can generally be patched out, but making this edict at all shows that they really don't understand the license they're using.