NDISwrapper dodges another bullet
| LWN.net needs you! Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing |
Hardware compatibility has long been a problem for Linux—though it has gotten much better over the years—so it will be surprising to some to see a kernel change that will make some hardware cease working. For others, who follow kernel development a bit more closely, it will come as no great surprise that NDISwrapper was disabled by a change made to the kernel back in January. NDISwrapper has never been very popular with kernel hackers, but, because it is GPL licensed and allows more hardware to be used, there are folks on both sides of the argument. For a while, it looked like NDISwrapper had lost that argument, but the 2.6.25-rc4 release restores the functionality it requires.
NDISwrapper is a kernel module that is used to load Windows-only drivers into Linux. For some hardware, notably wireless network cards, it is the only way to support them because the manufacturer provides neither specifications nor a working Linux driver. Unfortunately, many of these cards are installed in laptops where it is difficult or impossible to replace them with Linux-friendly alternatives. This is what led to implementing the Network Device Interface Specification (NDIS) for Linux. NDIS is an ancient—it was originally developed by Microsoft and 3Com for MS-DOS in the mid to late 1980s—interface for networking devices, which is still in use today.
The NDISwrapper code has been around since 2003, but always as a separate module that must be built by the user (or distribution) and loaded into the kernel. It is not part of the mainline kernel, nor will it ever be; maintaining a glue layer that allows proprietary, closed-source drivers to be linked into the kernel is not high on anyone's list. But, NDISwrapper is GPL. Its code is available for inspection or modification by all, so that is not the problem, it is the intent that matters.
When a binary-only driver—the NVidia video driver for example—is loaded into the kernel, a "taint" flag is set, indicating that the kernel is tainted by code that cannot be examined. Bug reports for tainted kernels are routinely ignored, unless they can be reproduced in an untainted kernel. Life, it seems, is too short to try and diagnose problems that could easily have been created by a buggy driver that cannot be debugged. Originally, the taint flag was just a means to detect and ignore those bug reports, but over time it has become part of a mechanism to restrict which symbols a module can access.
Some kernel symbols are considered so integral that any module using them must be a derivative work. Therefore, modules that want to use them must be GPL. Modules declare their license using the MODULE_LICENSE macro, while symbols are exported using either EXPORT_SYMBOL or EXPORT_SYMBOL_GPL. Any module that doesn't have a compatible license doesn't get access to the GPL-only symbols.
Few would argue for a GPL module which existed to re-export all of the GPL-only symbols to non-GPL modules. But that is not what NDISwrapper does; instead it implements NDIS, but in order to do that, needs access to GPL-only symbols, mostly for USB and workqueue interfaces. It would be hard to contend that NDIS drivers are derivative of the Linux kernel, they were written for an entirely different system using an interface that predates Linux. This is why NDISwrapper developers and users think that an exception should be made for it. Clearly the Windows drivers taint the kernel, but accessing a subset of the GPL-only functionality through NDISwrapper should be allowed, they argue.
Since NDISwrapper itself is GPL, the normal module loading rules would allow it to access GPL-only symbols, except that an explicit check for NDISwrapper was added to the 2.6.16 kernel. The question, then, revolves around what should be done when the kernel detects it being loaded. NDISwrapper has always been careful to mark the drivers that it loads as tainted, but the recent patch marks the module itself as tainted, disallowing access to the GPL-only symbols and breaking NDISwrapper. Absent that patch, only the kernel is marked as tainted—the module itself is not.
A similar situation occurred back in October 2006, which LWN covered on the Kernel page, when a stricter interpretation of tainting started to be enforced. At that point, NDISwrapper stopped working and it looked like it might stay that way, until Andrew Morton stepped in with objections to breaking NDISwrapper with no warning. Shortly thereafter, a patch was merged that only marked the kernel as tainted when NDISwrapper is loaded. At that point, the issue fell by the wayside, until now.
Part of the problem is that marking a symbol as GPL-only means different things to different developers. For some, it is a means to warn proprietary driver developers that they are straying into territory that makes distribution of their drivers very likely to be a violation of the GPL, while others want to use it to completely eliminate binary-only kernel drivers. There is no policy that clearly delineates which interpretation is "correct". Meanwhile, NDISwrapper has been in use by many for four years or more; breaking it now, with little or no warning, is likely to create some very unhappy users.
Linus Torvalds clearly thinks there are no licensing issues with NDISwrapper:
Jon Masters, the author of the patch that inadvertently made this change, had an excellent suggestion that should be pursued to try and reduce these kinds of problems in the future:
Another interesting battle will be that surrounding exporting init_mm() which was removed in early versions of 2.6.25, but then restored in 2.6.25-rc4. It is fairly clearly a low-level kernel interface that is unused by any in-tree driver, so its export was removed. One rather glaring exception is that the out-of-tree NVidia binary drivers do use it. Its export has been restored for one more development cycle, but it is clearly seen as something that should not be touched by drivers. It could be quite a struggle between the developers and users of a very popular driver and the kernel hackers that don't want to see kernel API abuse.
Issues surrounding the GPL are always contentious on linux-kernel; this one is no different. While NDISwrapper is an out-of-tree driver, it has hardly been invisible, so complaints when it breaks should come as no surprise. A simple renaming will avoid the current kernel check, so breaking it that way will mostly be an annoyance to users rather than a real barrier to its use. Since there is no real consensus amongst kernel hackers on the binary driver issue, it is hard to see one emerging with regards to NDISwrapper, but that would be the best outcome. One way or another, it needs to be decided, NDISwrapper shouldn't come under a periodic threat of breaking. If it is determined to be a violation of the kernel interfaces, that should be clearly indicated and its users should be given some warning so they can find alternatives.
| Index entries for this article | |
|---|---|
| Kernel | Copyright issues |
| Kernel | NDISwrapper |
(Log in to post comments)
NDISwrapper dodges another bullet
Posted Mar 5, 2008 18:20 UTC (Wed) by drag (guest, #31333) [Link]
Policy document sounds useful. Just as something to avoid flamewars. Probably treat it as a sort of secondary 'soft' license that is not enforced, but is expected to be followed unless you have a very good reason not to. As far as the NDIS wrapper goes.. it is indeed horrific. I see people routinely recommend to users to blacklist open source drivers so that they can get ndiswrapper working, rather then put the effort into trying to solve the problem. Just search around Ubuntu's forums and you'll see what I mean. It's a sort of a new rehash of a old quote.. You have a problem because the default driver isn't working, so you try to get NDISwrapper working.. now you have two problems. Even here at work I had one clueless guy actually install ndiswrapper in a production machine because he didn't bother to find the perfectly working open source driver. But I don't see it as a license violation.. I mean as a end user I am under zero restrictions under the GPL. If I want to funnel all the closed source binary code in the world into the kernel nobody has any ability to tell me I can't, according to the license. It's simply implimenting a driver-level API, which is common thing to have in other operating systems.
NDISwrapper dodges another bullet
Posted Mar 5, 2008 20:27 UTC (Wed) by sbergman27 (guest, #10767) [Link]
""" You have a problem because the default driver isn't working, so you try to get NDISwrapper working.. now you have two problems. """ Well, sometimes there truly is little choice. My laptop has a Broadcom 4318 chip set. B43 works now. But for the first year or so that I had it, no FOSS driver would work. I tried and tried. I spent hours... days... to no effect. I even went to far as to order an intel minipci card to replace the broadcom. But the bios on this machine checks the model number and politely refuses to boot if the wireless card is not on the approved list. So I ended up with ndiswrapper which was a piece of cake to install and get working. (Hacking the bios, and possibly trashing my machine, was beyond the limit of what I was willing to do to run a Free driver, much as I did want to.) And yes, I did complain loudly to Broadcom and Compaq, but the responses I got made it pretty clear that they didn't get many complaints, and didn't really even understand what I was complaining about. I think the Broadcom guy thought I was some kind of kook, not running Windows. Linux is wireless driver deficient and has been for a long time. That is, in part, the kernel devs fault because the old interface was so bad. And it is mostly the chip manufacturers' fault. But I can't really see blaming the users. If it is common practice to suggest blacklisting the OSS driver in favor of ndiswrapper, that is because of shortcomings in *Linux*, not in the user. You can't blame people for wanting common hardware to work. Would you rather have them running ndiswrapper on Linux? Or go back to Windows?
NDISwrapper dodges another bullet
Posted Mar 5, 2008 21:47 UTC (Wed) by drag (guest, #31333) [Link]
""Well, sometimes there truly is little choice. "" If you have no choice, then you have no choice. What I have a problem with is people, posing as experts, recommending to new users to blacklist open source drivers to get NDIS wrapper working. This is when I have the same exact devices and they are working perfectly well with no NDIS wrapper! What they should do instead is figure out what went wrong, file a bug report, and get a working driver and try to get that stuff back into the distro, or at least provide a download, so that they are actually helping the people they are claiming to help instead of advising users to try to shoehorn Windows drivers into their kernel.
NDISwrapper dodges another bullet
Posted Mar 5, 2008 22:51 UTC (Wed) by proski (subscriber, #104) [Link]
Users who believe such "experts" are usually not good at bug reporting. They would forget to provide important information about their systems, they would be loaded with incorrect assumptions taken from "experts" in "helpful" forums, they would fail to read the documentation, they would trust obsolete posts they find on Google more than the current documentation. And even if they manage report a bug more or less correctly, it would be either a known issue, or something already fixed in the git repository and being on its way to the distros. But it's unlikely such users would bother testing the fix.In any case, it's unfair to advocate blocking free software just because it has some clueless proponents. Just because, say, KDE has some idiotic fans, it doesn't mean that developers of other software (e.g. gcc, libc) should be actively looking for ways to prevent KDE from compiling or working properly, and it particular blacklist KDE modules by name, as it was done to ndiswrapper.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 5:45 UTC (Thu) by allesfresser (guest, #216) [Link]
What I found really annoying was people (yes, on the Ubuntu forums) who told a user, as you said, to blacklist the free driver in favor of ndiswrapper. However, the system in question happened to be using a *PowerPC processor*. Obviously this will not do the user much good, to load a Windows driver in this case...
NDISwrapper dodges another bullet
Posted Mar 5, 2008 18:40 UTC (Wed) by JoeBuck (subscriber, #2330) [Link]
If the official kernel were to accept a patch that would prevent ndiswrapper from accessing some symbols, nothing would stop a distributor from reverting the patch, as GPLv2 gives distributors the freedom to make modifications.Linus is right that the GPL (any version, or any copyright-based license for that matter) applies only to derived works, so ndiswrapper isn't breaking any rules. Where it gets iffy is when a downstream distributor or hardware seller provides a customer with Linux plus ndiswrapper plus a Windows driver; the combination is a derivative work even if the Windows driver piece isn't, so a strict interpretation would say that this isn't kosher. On the other hand, the whole GPL-only symbols mechanism, the long existence of proprietary drivers, etc. implies that the real license to Linux is GPL with fuzzy exceptions for modules.
So distributors who want their customers to use ndiswrapper probably need to have their end-users load the Windows driver on their own to stay in the clear.
Sauce
Posted Mar 5, 2008 19:08 UTC (Wed) by ncm (guest, #165) [Link]
The same arguments made earlier insisting that a release under the GPL couldn't be retracted would apply equally here: ndiswrapper has been distributed with the kernel and drivers with full awareness of the kernel maintainers, for years. I.e., to withdraw permission now would be much the same as withdrawing permission to redistribute GPLed code.I'm not saying they couldn't withdraw permission. It's just that those whose position comes down on the wishful-thinking side of any argument would argue opposite here as for the previous issue, and even insist there was no contradiction.
The canonical reference for wishful thinking is also the Greatest Blog Post Ever.
Sauce
Posted Mar 6, 2008 3:08 UTC (Thu) by proski (subscriber, #104) [Link]
I think you are comparing two different things. One is like changing a contract unilaterarily after it was signed. That's clearly illegal. Another is like installing "no trespass" signs in wrong places. It can be forbidden too, but by another law, and there is no law specifically regulating GPL-only symbols.However, installing "no trespass" signs in improper location would cause people stop paying attention to them, and some trespasser could even argue that the trespass wasn't willful if there were some obviously wrong signs nearby.
NDISwrapper dodges another bullet
Posted Mar 5, 2008 19:12 UTC (Wed) by and (guest, #2883) [Link]
> If the official kernel were to accept a patch that would prevent > ndiswrapper from accessing some symbols, nothing would stop a > distributor from reverting the patch, as GPLv2 gives distributors the > freedom to make modifications. This is true from a technical point of view, but there are probably other tricks available to get non-GPL modules to load. The whole point of the EXPORT_SYMBOL_GPL thing is more legal than technical. It goes along the lines of "If you use this symbol in non-GPLed code we may sue you". It also won't help if a distributor would remove the block since if they where really sued over a GPL violation, they couldn't distribute the kernel anymore making it hard to stay a linux distributor... The thing I was wondering about is that Linus reserves himself the right to remove such patches, even though he doesn't own the copyright for the piece of code in question in about 99% of all cases. I suppose if a copyright owner was to send Linus such a patch for one of the owner's interfaces, Linus would probably be required to accept it from a legal point of view. (Strictly technically this is not true, of cource, see the first paragraph...)
NDISwrapper dodges another bullet
Posted Mar 5, 2008 21:55 UTC (Wed) by drag (guest, #31333) [Link]
> The thing I was wondering about is that Linus reserves himself the right to remove such patches, He doesn't. If you go and look at the email exchange with him you'll notice that he threatened to banish anybody arguingon any sort of the legal mumbo-jumbo to his ignore file. He was only interested in the interfaces that ndiswrapper used and told people to contact those authors and try to work out a exception if they care about it working.
NDISwrapper dodges another bullet
Posted Mar 5, 2008 20:08 UTC (Wed) by iabervon (subscriber, #722) [Link]
Unless people are distributing systems that are already booted, I don't think anyone could help but have the end user load the binary driver; I don't think ndiswrapper even supports linking the driver into it ahead of time. And selling the combination is fine with the GPL as mere aggregation, and it's, if anything, better that the nvidia drivers situation as a whole, because the closed code and the open code are separated by clean and generic API. If you modify your kernel, there's no way that this could require changes to the binary driver, since it's not even designed to work with Linux at all. If the GPL's purpose is to prevent non-GPL code rom preventing you from modifying GPL code and then being able to use the system, that's not a concern here for technical reasons, even leaving aside legal ones.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 0:25 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>Unless people are distributing systems that are already booted, I don't think anyone could help but have the end user load the binary driver; I don't think ndiswrapper even supports linking the driver into it ahead of time. Consider VMware Suspend Images (*.vmss) it is possible to distribute booted systems, and as such, every currently working combination of code. Well, it may already happen that distributing the Windows driver is bound by some license already, so you can possibly save on the time to spend about thinking about distributing linked code.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 16:07 UTC (Thu) by iabervon (subscriber, #722) [Link]
Doesn't vmware abstract access to network devices anyway? I somehow doubt that a suspend image containing a Linux kernel using a Windows driver to talk to a physical network device would actually have any chance of working at all. And running Linux under vmware with the Windows driver for the vmware simulated network device instead of the Linux driver for it is just silly. In order for this particular issue to be relevant, you'd need to distribute a booted system with a driver loaded for a chipset with only a Windows driver available, which only makes sense if it's running on physical hardware.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 17:10 UTC (Thu) by jengelh (subscriber, #33263) [Link]
>Doesn't vmware abstract access to network devices anyway? This is independent of providing a linked variant of ndiswrapper IMHO. That said, VMware provides virtual HW that behaves like AMD PCnet32 or Intel E1000; so I could link e1000.drv with ndiswrapper then what? Abstraction does not relate to anything. Imagine we had have kexec from/to VMSS someday then what?
NDISwrapper dodges another bullet
Posted Mar 6, 2008 0:33 UTC (Thu) by rahvin (guest, #16953) [Link]
As I understood how the nVidia driver works, this is exactly the method. There is a GPL'd piece that integrates into the kernel and creates the interface to the binary driver. Just like ndiswrapper works, in fact I thought that the nVidia Linux driver was created because ndiswrapper showed them how to integrate a closed source binary driver into the kernel. I also thought this was one of the reasons certain developers hate ndiswrapper so much, they started the whole trend to the binary blob in the kernel thing.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 3:18 UTC (Thu) by proski (subscriber, #104) [Link]
I'm not sure about nVidia drivers, but I believe they are compiled specifically for Linux. The free and non-free parts are distributed together by the same entity. I think that's very different from ndiswrapper from the legal standpoint (but IANAL).What I know for sure, is that a non-free driver for Lucent Orinoco cards used such trick, and it predated ndiswrapper. That's why blaming ndiswrapper that it "started the whole trend" would be misleading.
Besides, driverloader is older than ndiswrapper, and it does the same thing as ndiswrapper. It's also non-free and was caught lying about its license, something that ndiswrapper never did.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 5:39 UTC (Thu) by jzbiciak (guest, #5246) [Link]
Apparently, the NVIDIA adapter code sets its license to "NVIDIA", so it doesn't get access to GPLONLY symbols. I haven't checked this myself, but I've seen others mention it.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 8:37 UTC (Thu) by Los__D (guest, #15263) [Link]
You are completely right:$ modinfo nvidia ... license: NVIDIA ...
NDISwrapper dodges another bullet
Posted Mar 6, 2008 16:22 UTC (Thu) by iabervon (subscriber, #722) [Link]
It's very different in that the binary blobs that NDISwrapper loads were written without knowledge of the Linux kernel, and the binary blob that the nVidia shim code loads were written using knowledge of the Linux kernel as reference. This is much the same difference as that between writing an encyclopedia without having Britannica and writing one while using Britannica. In the latter case, you have to be a lot more careful about a lot of things in order to avoid doing things you shouldn't.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 6:23 UTC (Thu) by hamjudo (guest, #363) [Link]
Do any PCI interfaces include a mechanism for limiting memory access for a device?I'd accept a significant performance hit, if I could run the evil drivers in user mode under an emulator like QEMU, with a kernel driver that provided controlled access to the PCI slot, and appropriate memory buffers, but blocked access to any other device, or memory. But that is not enough, unless the network device itself is also prevented from accessing the wrong memory, or other devices.
Most DMA controllers are configured by the driver. If a DMA controller is loaded with a bad address, the device will scribble on the wrong memory. That produces bugs that are incredibly hard to track down and massive security holes. So the hardware has to be limited too, before you can really claim that the interface removes the need for tainting.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 13:05 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
There are some recent PCI extensions for IO virtualisation (IOV) that provide for (among other things) mapping of DMA addresses by the chipset. This could perhaps be used to constrain user-space drivers.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 14:41 UTC (Thu) by mcmanus (guest, #4569) [Link]
If your board has an IOMMU it can do this for you - and they are becoming more common.
DRM
Posted Mar 6, 2008 9:57 UTC (Thu) by rwmj (subscriber, #5474) [Link]
It's a bit surprising no one's mentioned DRM in this discussion yet, because this is DRM.
Just like DRM, it is technically ineffective. It's trivial to workaround this, particularly since it's free software.
Like DRM it is legally dubious -- I have a perfect right under the GPL to combine closed software on my own laptop, just as I have the (moral) right to flash my DVD drive to remove region coding restrictions to play my purchased out-of-region DVDs. If people are distributing works derived from GPL code without source, then that's a matter for the courts, not for C macros on kernel symbols.
Rich.
As long as the proprietary Windows driver ist not DISTRIBUTED...
Posted Mar 6, 2008 10:07 UTC (Thu) by morhippo (guest, #334) [Link]
I don't understand the argument. Ndiswrapper is GPL, the kernel is GPL, clearly they can be used and distributed freely. You can also USE GPL together with proprietary in any way you want because the GPL does not contain ANY use restrictions. Please check it out and repeat after me: No USE restrictions. Do what you want with GPL and proprietary (e.g. Nvidia drivers) in your PC. However, what you may not do is DISTRIBUTE a derived work of GPL and proprietary code, ie you may not distribute a kernel with Ndiswrapper and proprietary Windows driver. As long as you do not do that, the restrictions of the GPL do not apply.
As long as the proprietary Windows driver ist not DISTRIBUTED...
Posted Mar 6, 2008 11:13 UTC (Thu) by NRArnot (subscriber, #3033) [Link]
Perhaps an NDIS-lover should write a GPLed NDIS driver for some old Ethernet NIC for which sufficient programming information is available. We'd then see an assemblage of code, all GPL, being blocked, or the kernel into which it is loaded being marked as tainted, as a result of the political goals of people controlling the export of kernel symbols!
As long as the proprietary Windows driver ist not DISTRIBUTED...
Posted Mar 6, 2008 12:48 UTC (Thu) by morhippo (guest, #334) [Link]
If you read the discussion on the kernel mailing list, there is mention of such a driver actually existing.
As long as the proprietary Windows driver ist not DISTRIBUTED...
Posted Mar 6, 2008 13:01 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
There is a GPL'd NDIS driver - http://cipe-win32.sourceforge.net/ - though it's a port from Linux so there's little point in using it with ndiswrapper.
Slightly different tack
Posted Mar 6, 2008 13:16 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
Maybe there could be broader distribution of reversing kits, making it less painful to get into collecting packets and writing drivers for legacy hardware. A problem with NDISwrapper is that it appeals to laziness and doesn't foster new, pure-GPL development. Advertizing NDISwrapper as an important infrastructure piece for writing freer drivers could give it more street cred. Packaged properly, it could help improve the developer base for the kernel by helping flatten the learning curve. And I want a pony.
NDIS drivers in mainline? NEVER
Posted Mar 6, 2008 23:35 UTC (Thu) by hmh (subscriber, #3838) [Link]
Err, it is worth noticing that refusal to merge crap in the kernel happens all the time. There is no way any NDIS driver would ever be merged, AFAIK, and the reasons for this are simple: An NDIS driver would be slower, more difficult to maintain, far more complex (you have to take into account the entire NDIS wrapper too!), and IMHO just downright nastier to look at than it would be had it used the native APIs in the first place. So I am afraid an NDIS-lover will have to find another way to equal himself to the people who mark symbols GPL-only for political reasons (as opposed to technical reasons).
As long as the proprietary Windows driver ist not DISTRIBUTED...
Posted Mar 7, 2008 16:32 UTC (Fri) by giraffedata (guest, #1954) [Link]
I don't understand the argument.
I believe there are multiple arguments, as there are multiple views of the purpose of GPL_ONLY symbols. But the arguments described in this article aren't arguments about what copyright law or GPL allows -- they're just arguments over how easy the kernel.org kernel should make it to use Windows drivers with Linux. And also how easy it should be to tell that Windows drivers are being used, in a bug report.
NDISwrapper dodges another bullet
Posted Mar 6, 2008 14:38 UTC (Thu) by pr1268 (subscriber, #24648) [Link]
> Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows driver isn't a derived work of the kernel.
I have to agree with Linus' overall philosophy here wrt NDISWrapper. Wi-fi cards are the bone of contention amongst laptop users running Linux.
I can't even count how many times I've run across someone running a (fairly late-model) laptop with Linux and having to shoe-horn in Wi-fi capability on the built-in card with NDISWrapper (or other GPL-questionable methods).
(I even have a friend with a Lenovo T61 running Ubuntu - with an Intel Wi-fi card, two relatively Linux-friendly companies. But, neither of us could figure out how to get the WPA-specific features of the card to work with the university's encrypted Wi-fi network - and believe me, we spent days on this. He still is considering NDISWrapper, despite my urgings that he avoid doing so. And this is a guy who proudly sports a "Microsoft-Free" sticker on the lid of his laptop!)
I had someone else come ask me for help getting his laptop's Wi-fi card working, even though the sound card didn't work, the X display was set to a grotesquely low resolution (i.e. a 1920x1440 display running at 800x600), the sound card didn't work (not too sure whether that was a lack of Linux driver support or misconfiguration), some keyboard shortcut keys didn't work (probably not configured yet), and the thumbprint reader didn't work. Now bear in mind that every last piece of built-in hardware on this gentleman's laptop did work in Windows, and he took great pains to remind me of that while I was attempting to ascertain the best strategy of getting the Wi-fi working, but he was still willing to give Linux a try.
I get the impression that the kernel developers were/are attempting to quietly kill support for non-GPL driver/BLOB support in the kernel. I can imagine a future where, assuming this happens, then a whole counterculture sprouts up - that of Linux users of moderate skill who use outdated versions of the kernel and equally outdated versions of "driver-enabling" software (e.g., NDISWrapper) with vulnerabilities possibly lurking about, just to ensure everything Just Works™. Or, for those willing to give Linux a try, they discover just how horribly "crippled" everything becomes when switching from Windows (or Mac OS) to Linux because they've got the latest hardware devices and no driver support, and they swear off Linux forever.
I really do appreciate the evangelism RMS and the FSF have done over the years, and I am also truly grateful for the hard work the kernel developers have done to ensure Linux users don't feel "left behind" wrt hardware support (Greg K-H's open letter to IHVs a few months ago comes to mind). And, I think that the Linux community needs to continue applying this pressure on IHVs to ensure continued hardware driver support.
But, "slamming the door shut" (either clandestinely or overtly) on many users' lone ability to use their computers without caving in to the demands of one single company (and its chair-throwing CEO) just doesn't seem like the right thing to do. I understand that there are those among the kernel devs with intense philosophical beliefs about GPL adherence, but summarily "pulling the plug" without discussion is extreme, IMHO.
I can understand why some of the "tips" on the Ubuntu forums actively encourage NDISWrapper - (1) it's essentially a guaranteed solution (even if it is, as Linus said above, a distasteful one), and (2) it's a method that can be mass-marketed easily to novice Linux users.
Why NDISwrapper special case?
Posted Mar 7, 2008 13:24 UTC (Fri) by ldo (guest, #40946) [Link]
It seems to me that, regardless of the legalities or moralities of the case, having the mainline kernel include a special check for a particular out-of-mainline module by name is totally the wrong thing to do. Instead, whatever that check is doing, make it an API routine that a module can call, and persuade the NDISwrapper developers to voluntarily put in a call to it.
Because it seems from some of the other comments here that NDISwrapper is hardly an isolated case. And having to add checks to the kernel for all these cases is clearly an activity that 1) doesn't scale well, and 2) is subject to breakage, either inadvertently or deliberately, as a result of setting off an "arms race". I don't think the kernel developers want to paint themselves into that corner.
Why NDISwrapper special case?
Posted Mar 7, 2008 17:52 UTC (Fri) by zlynx (guest, #2285) [Link]
The NDISwrapper developers did exactly that. The module *does* set the taint flag as soon as it loads an NDIS driver. As I recall it some whiny RedHat guy pushed the special check in because he was getting bug reports from kernels using *old* versions of ndiswrapper and he figured it was easier to change the kernel than to get users to update their perfectly working ndiswrapper versions.
kernel-liberator.sh or uncrippling the linux kernel
Posted May 6, 2008 20:43 UTC (Tue) by da.phreak (guest, #51930) [Link]
There are kernel sources. Those sources are easility patched. Have a look here for my kernel liberator script that disables the gpl-only mechanism.Warning: Kernel Developers might don't like it.