GPL-only symbols and ndiswrapper
One of the many changes that went into the 2.6.16 kernel was an explicit check for the ndiswrapper module. It is, in fact, this explicit:
if (strcmp(mod->name, "ndiswrapper") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
This test means that any system which has had ndiswrapper loaded will have the "proprietary module" taint flag set. As a result, the kernel developers are highly unlikely to be interested in helping with any problems encountered running that kernel. Since 2.6.16 was released last March, one might well wonder why ndiswrapper author Giridhar Pemmasani is only now getting around to complaining about that test. It turns out that the kernel developers have quietly taken things one step further in the 2.6.19-rc kernels.
The kernel has long exported symbols to modules in two modes. Symbols exported with EXPORT_SYMBOL are available to all modules loaded into the kernel, while those exported with EXPORT_SYMBOL_GPL are only available to those which declare a GPL-compatible license. This distinction has never been a problem for ndiswrapper, which is licensed under the GPL. So, even after the explicit taint was added, ndiswrapper could load and function normally.
For 2.6.19, a patch by Florin Malita was merged which changes the calculation for GPL-only symbols slightly. Rather than checking whether a module has a GPL-compatible license, the new code checks whether the module has the "proprietary module" taint bit set. In most cases, the end result is the same. For ndiswrapper, however, the result is that GPL-only symbols, which were accessible in earlier kernels, are now unavailable. And that means that ndiswrapper can no longer be loaded into the kernel. The module's author thinks that this is unfair, since ndiswrapper is, in fact, GPL-licensed code.
Alan Cox's response reads like this:
The core idea makes sense: the GPL-only restrictions are not worth much if they can be trivially circumvented by loading a glue module. One cannot help but wonder, however, if the wrong target has been chosen in this case.
The purpose of GPL-only exports is to inhibit the creation of proprietary derived products of the kernel. It is hard to imagine an argument that could demonstrate that a typical NDIS module is, in any way, a derived product of the Linux kernel. These are drivers written for another operating system entirely by people who, likely as not, have never had any sort of contact with Linux source. Unlike certain other types of proprietary modules, NDIS drivers are clearly independent works. One may well balk at the notion of loading such a driver into one's kernel, but it is hard to make a case that copyright law somehow prohibits such an action.
It also seems a little strange to penalize a module for having the wrong name. There are no explicit checks for, say, the MadWifi module, which also loads a binary-only component. Simply renaming the module would circumvent this check, opening a window which would take the kernel developers some months to close again. One could imagine a determined programmer coming up with a random name every time a module is built, decisively winning that particular battle. The ndiswrapper author seems uninclined to play those games, however; he has, instead, tried to work within the kernel community. The module already takes pains to add a kernel taint itself whenever an NDIS driver is loaded.
There does not seem to be any particular interest in the kernel community
in backing down on this change however. That leaves the ndiswrapper author
in a position where he must either rework the code to avoid GPL-only
symbols or find some other way of enabling it to load once again. One
assumes that some sort of workaround will be found; it may not be an
optimal solution, but ndiswrapper does have a significant community which
depends on it to make its hardware work under Linux.
| Index entries for this article | |
|---|---|
| Kernel | Copyright issues |
| Kernel | NDISwrapper |
Posted Oct 25, 2006 17:00 UTC (Wed)
by coopj (subscriber, #1139)
[Link] (5 responses)
Posted Oct 25, 2006 17:12 UTC (Wed)
by vondo (guest, #256)
[Link] (3 responses)
I suspect (but have no knowledge) that the GPL licensed ndiswrapper uses the GPL symbols but does not provide access to those symbols to any driver it loads. At most, it will translate between the GPL symbols and the Windows symbols.
Come to think of it, I suppose it's technically possible that the NV driver wrapper (which is GPL) might do the same thing.
Pure speculation on my part, so if I'm wrong, please let me know.
Posted Oct 25, 2006 19:21 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
I don't think that your realy going to work around the issue.
The ndiswrapper is different as it's more of a generic loader and the windows drivers are clearly 100% not derived code. There are absolutely no restrictions on what end users can do via the GPL license. Personally I could steal W2k source code and shovel it into the kernel code and that is 100% ok as far as the GPL goes. Problems crop up however when you want to ship it to other people.
As for shipping working ndiswrapper drivers.. that's even worse then the nvidia stuff.
Not only are you violating the kernel developer's copyright license, but your also probably violating the licenses provided by the windows drivers writers who probably signed licenses with Microsoft stating that their code is only allowed to run on MS operating systems.. which seems the standard stuff for Microsoft's software licensing.
Posted Oct 26, 2006 23:43 UTC (Thu)
by filipjoelsson (guest, #2622)
[Link]
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 Nov 2, 2006 18:30 UTC (Thu)
by jengelh (guest, #33263)
[Link]
The nvidia glue is not GPL at all (there is not even a MODULE_LICENSE string in there), just like the binary blob.
Posted Oct 25, 2006 17:16 UTC (Wed)
by nikarul (subscriber, #4462)
[Link]
Posted Oct 25, 2006 17:56 UTC (Wed)
by mheily (subscriber, #27123)
[Link] (9 responses)
Perhaps it is time to switch to Debian GNU/kFreeBSD which has integrated NDIS support via the ndis driver and does not have all the political and legal crap associated with the Linux kernel.
Posted Oct 25, 2006 19:45 UTC (Wed)
by khim (subscriber, #9252)
[Link] (8 responses)
Since ndiswrapper is GPL, it should receive the same treatment as other GPL modules. Why ? Kernel developers are not obliged to help you run proprietary stuff - be it NDIS driver or NVidia driver. On the other hand it's probably childish to punish ndiswrapper so: you can not distribute the end result (ndiswrapper plus NDIS windows's driver) anyway and you can easily patch the kernel to make it work so (and it's legal! as long as you keep all chnages private) thus all this thing accomplis is a lot hassle for the people who are already punished...
Posted Oct 25, 2006 20:24 UTC (Wed)
by proski (subscriber, #104)
[Link] (7 responses)
If driver developers are treated like nuisance, they'll find something better to do.
Posted Oct 25, 2006 21:08 UTC (Wed)
by drag (guest, #31333)
[Link] (6 responses)
Posted Oct 25, 2006 21:35 UTC (Wed)
by proski (subscriber, #104)
[Link]
Clueless web pages are annoying, but they are not written by developers. Users who trust such web pages more than the official documentation should be asked politely to choose a "better" forum for their questions and leave the developers alone.
Posted Oct 25, 2006 21:55 UTC (Wed)
by sfeam (subscriber, #2841)
[Link] (4 responses)
Even if you are correct about 90% of current ndiswrapper use being for network cards, that leaves the remaining 10% as being for less generic devices. Less generic, and hence less likely to be tackled by your hypothetical driver developers with free time on their hands.
Yeah sure, if HP were to release the specs, and someone were to write a driver, I'd use it. But I'm not holding my breath. Notwithstanding your rant about wireless support, ndiswrapper serves a need. And it does so in a way that doesn't trample on any kernel developer's copyright or on GPLv2 license terms.
You, yourself, say 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". Maybe so, but preventing legitimate end use because of frustration with distro beta-testing is an strange response. This comes across as political posturing, and a sad case of cutting off your nose to spite your face.
Posted Oct 26, 2006 6:56 UTC (Thu)
by drag (guest, #31333)
[Link] (3 responses)
Since I don't own one and don't care much about it I think that it's you that should be in a much better position to provide a driver for it.
Anyways I have no freaking clue what the hell your scanner has to do with either ndiswrapper or wireless drivers or the fact that distributions are telling people to remove a working open source in-kernel driver and telling them to use a binary blob.
Especially doubly-so that your scanner wouldn't have any sort of kernel driver anyways.
Posted Oct 26, 2006 7:01 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
Posted Oct 26, 2006 10:53 UTC (Thu)
by drag (guest, #31333)
[Link]
I didn't know people used ndiswrapper for anything other then wifi stuff. Learn new stuff everyday, I guess.
Like I said before though, I know that ndiswrapper has legitament uses. It's just that the kernel developers can't afford to have people ignoring open source driver development over binary blobs.
However, if they let end users get comfortable with binary blobs then they would end up being forced to support binary only drivers.
Intel 802.11g, Broadcom 802.11g, Ti 802.11g, Ralink 802.11g, Realtech 802.11g, all of these things have open source drivers for Linux, but all the time people are recommended to abandon everything except for the Intel for the ndiswrapper driver.
If kernel developers sit on this then they are essentially saying:
Posted Oct 26, 2006 23:38 UTC (Thu)
by Hawke (guest, #6978)
[Link]
"the fact that distributions are telling people to remove a working open source in-kernel driver" But they're not. From my understanding, the advice from distro fora and such comes from other users, not from anyone official at the distro. I don't recall ever seeing any bugs that were closed with "here's a workaround, use ndiswrapper" -- at the most, the closed-source drivers might be suggested as an interim solution until the open-source drivers are fixed. I'm pretty sure most users will be happier getting to use their shiny new network card with proprietary drivers than not using it at all, and between replacing a distribution or replacing the network card, I can guess what most people will pick.
Posted Oct 25, 2006 18:22 UTC (Wed)
by sfeam (subscriber, #2841)
[Link] (13 responses)
If true, I find this a very troubling symptom of an increasingly politicized stance on the part of some kernel developers, possibly exascerbated by the ongoing GPL2 vs. GPL3 flame-fests.
I do not know whether ndiswrapper truly needs these GPL symbols; let us assume that it does. Modifying the kernel to forbid access to them appears to me a purely punitive action, with no grounding in fairness, copyright, or technical justification. It goes well beyond any concern of compliance with the re-distribution clauses of the GPL, since its primary effect is on the end-user, who can no longer load and run legally obtained, independent pieces of software.
Tainting? - OK, that is justifiable for technical reasons. But to outright forbid running non-GPL code is a sad retreat from what I have up until now seen as the overall spirit of linux development - one of inclusiveness, helpfulness, practicality, and a general aversion to hard-line politics.
I am hopeful, however, that you have mis-read the mood of the lkml response. It seemed to me that an alternative proposal to make ndiswrapper an officially-blessed kernel component was not rejected outright. This would allow more finely-considered restrictions on use to be implemented in ndiswrapper itself, with input and review from developers with legitimate concerns.
Posted Oct 25, 2006 18:53 UTC (Wed)
by man_ls (guest, #15091)
[Link] (5 responses)
It will be a good change if it ends up in more free drivers. But to limit users' possibilities to load modules at runtime is a different thing, IMHO. After all ndiswrapper was always meant as an interim solution.
Posted Oct 25, 2006 20:32 UTC (Wed)
by cventers (guest, #31465)
[Link] (4 responses)
Posted Oct 30, 2006 14:23 UTC (Mon)
by liljencrantz (guest, #28458)
[Link] (3 responses)
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 30, 2006 14:45 UTC (Mon)
by cventers (guest, #31465)
[Link]
And yes, the end user can relicense within the GPL depending on the "or
Posted Nov 2, 2006 12:05 UTC (Thu)
by forthy (guest, #1525)
[Link] (1 responses)
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? Yes, any user/distributor can do that. And actually that's what Linus
Torvalds did, when he put his "GPLv2 only" comment on top of COPYING in
2.4.0-test-something.
Posted Nov 2, 2006 12:25 UTC (Thu)
by arcticwolf (guest, #8341)
[Link]
If you read the GPL, you will find that the whole "any later version" thing is not actually part of the license. It's being used in the example of how to apply the GPL to your work, but the license itself does not contain any clause like that. (In fact, if it did, the whole "GPL v2 or later" vs. "GPL v2 only" distinction would be meaningless; the GPL v2 would already say that any later version is also acceptable, and declaring a program to be licensed under "the GPL v2 only" would make no sense, just like saying "licensed under the GPL, but you may not make copies or modify it" doesn't make sense, either.)
It's important to keep this in mind. Linus licensed Linux under the GPL, but he never used the "any later version" language, so Linux[1] was *always* licensed under the GPL v2 only. The change you mention merely made this explicit to combat confusion.
1. That is, the parts he holds the copyright to, as well as Linux as a whole; individual parts contributed by others may well be available under additional licenses, such as later versions of the GPL, of course.
Posted Oct 25, 2006 19:04 UTC (Wed)
by uravanbob (guest, #4050)
[Link]
Posted Oct 25, 2006 20:34 UTC (Wed)
by proski (subscriber, #104)
[Link] (5 responses)
Posted Oct 26, 2006 1:18 UTC (Thu)
by i3839 (guest, #31386)
[Link] (4 responses)
Posted Oct 26, 2006 17:38 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
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
For many types of devices, userspace drivers make sense, but that should be a *technical* decision.
Posted Oct 28, 2006 0:26 UTC (Sat)
by i3839 (guest, #31386)
[Link] (2 responses)
Those drivers want to talk to their hardware, not to the rest of the kernel which they shouldn't know or care about.
Posted Oct 31, 2006 2:17 UTC (Tue)
by proski (subscriber, #104)
[Link] (1 responses)
Posted Oct 31, 2006 13:38 UTC (Tue)
by i3839 (guest, #31386)
[Link]
> how are you going to emulate Linux API expected by those modules (provided you are talking about Linux modules)?
Well, you'd hope they don't expect Linux specific API functions, or keeping them closed source makes it even more questionable than it already is. So I assume they only need general hardware interaction functions, like setting up interrupt handlers and things like that. In the case of graphic cards they have a way to send data and commands to the card, they might need a bit help with DMA and stuff from the kernel, but other than that not much more needs to be done by the kernel and the rest can be done by the userspace driver.
The userspace driver will not be easy to make and most likely be slightly slower, but even if that's 10% it's worth it to get the 4MB big unknown blob out of kernel space.
Posted Oct 25, 2006 19:47 UTC (Wed)
by mikov (guest, #33179)
[Link] (11 responses)
What options do people have ?
I wonder whether Ubuntu will ship a kernel with ndiswrapper disabled.
Posted Oct 25, 2006 21:10 UTC (Wed)
by kamil (guest, #3802)
[Link]
Surely, that's OK from the GPL point of view?
Posted Oct 25, 2006 21:39 UTC (Wed)
by gmaxwell (guest, #30048)
[Link] (9 responses)
From spending time giving free linux support to linux newbies on IRC I've found that the majority of people trying to use ndiswrapper today are trying to use hardware for which there currently exists free drivers (and in somecases, like Intel 2100, very good free drivers). The reason they are trying to use ndiswrapper is because when they googled for their hardware old mentions of ndiswrapper is what came up first. .. Worse, some distributions advocate ndiswrapper for drivers long after solid free drivers are available.
>- Buy another laptop (yeah, right)
Although most people don't realize it, almost all laptop's wireless cards are on mini-pci and are removable as a result. Linux compatible mini-pci cards can be purchased for fairly low prices, and cards are available with far better recieve sensitivity and higher transmit power than what probably shipped with their laptop. So while not an ideal solution, it isn't unreasonable to suggest that someone change their hardware.
>- Use Windows (yeah, right)
The best option is to use a free driver.
The next best option is to change to Linux supported hardware even ignoring that much of the better hardware is Linux supported, it will simply work better because you need not worry about bugs introduced by running a windows driver in an unintended enviroment.
Using ndiswrapper? ... well Why do you suggest people us Windows drivers after discarding out the option of using Windows itself? There are several nice VMs that Linux works well in, ... If the user is going to have propritary code in their kernel, why not go all the way?
Posted Oct 25, 2006 22:10 UTC (Wed)
by mikov (guest, #33179)
[Link] (4 responses)
I didn't realize that, though personally I haven't had to use ndiswrapper yet.
> Although most people don't realize it, almost all laptop's wireless cards are on mini-pci and are removable as a result.
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.
Buying a new laptop so that it could be used for Linux is another thing. In that case buying an extra mini-pci card is also acceptable.
> The best option is to use a free driver
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.
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.
> Using ndiswrapper? ... well Why do you suggest people us Windows drivers after discarding out the option of using Windows itself? There are several nice VMs that Linux works well in, ... If the user is going to have propritary code in their kernel, why not go all the way?
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 ?
Cons:
Pros:
How would you answer ?
Posted Oct 25, 2006 22:44 UTC (Wed)
by lutchann (subscriber, #8872)
[Link] (2 responses)
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 26, 2006 12:01 UTC (Thu)
by malor (guest, #2973)
[Link] (1 responses)
Posted Oct 26, 2006 19:57 UTC (Thu)
by AJWM (guest, #15888)
[Link]
True. What they don't have the right to is expect somebody else to help them do it, or make it easy for them to do it.
Posted Oct 25, 2006 23:03 UTC (Wed)
by gmaxwell (guest, #30048)
[Link]
>I didn't realize that, though personally I haven't had to use ndiswrapper yet.
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 5:26 UTC (Thu)
by jamesh (guest, #1159)
[Link]
Note that some laptop manufacturers will prevent a laptop from booting with a third party MiniPCI wireless card. The excuse being that the wireless device is made up of the MiniPCI card and the antenna in the lid, so they only allow complete wireless devices that they've received FCC approval for.
This behaviour has been seen in Thinkpad X40 laptops.
Posted Oct 26, 2006 7:44 UTC (Thu)
by lacostej (guest, #2760)
[Link] (1 responses)
If users, why not add a littel daemon that detects ndiswrapper, reports the hardware used, query a DB and report a warning to the user saying that a better driver exists ?
Users don't know about alternatives ? Let them know the alternatives.
Posted Oct 26, 2006 22:32 UTC (Thu)
by k8to (guest, #15413)
[Link]
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 26, 2006 16:09 UTC (Thu)
by GreyWizard (guest, #1026)
[Link]
Linux compatible mini-pci cards can be purchased for fairly low prices, and cards are available with far better recieve sensitivity and higher transmit power than what probably shipped with their laptop. Could you provide links? This is an appealing prospect. Why do you suggest people us Windows drivers after discarding out the option of using Windows itself? Even speaking as someone who has returned hardware known to work ndiswrapper because a free driver was not available (we need to demonstrate to hardware vendors that poor support for free software operating systems means fewer sales), this objection seems unreasonable. A system running 95% free software less desirable than one running 100% free software, but if I can't return the hardware for a refund I'll take 95% over nothing.
Posted Oct 25, 2006 20:11 UTC (Wed)
by josh_stern (guest, #4868)
[Link] (32 responses)
After reading it through, I came around to the belief that the kernel developers actual point of view is that ndiswrapper was misrepresenting itself as GPL when it is is really only LGPL - sort of analogous to the complaint that distributing GPL's KDE was illegal in the days before Qt-X11 become (optionally) GPL.
Posted Oct 25, 2006 21:02 UTC (Wed)
by sfeam (subscriber, #2841)
[Link] (1 responses)
Posted Oct 25, 2006 22:45 UTC (Wed)
by josh_stern (guest, #4868)
[Link]
My point is that ndiswrapper seems like something that really should be LGPL rather than GPL as it depends on linking with proprietary code in order to be useful to people. Since my understanding of EXPORT_SYMBOL_GPL is that it is specifically designed as a mechanism for some kernel authors to prohibit their code from being used within a work that is not really GPL, the approach taken by the kernel developers as described in the article seems reasonable to me. They are basically saying that ndiswrapper's claim to be GPL compatible is a sham. That is, it's doubtful that those developers who made their contributions EXPORT_SYMBOL_GPL had really wanted to allow something like ndiswrapper.
Posted Oct 25, 2006 21:28 UTC (Wed)
by proski (subscriber, #104)
[Link] (13 responses)
Posted Oct 25, 2006 22:39 UTC (Wed)
by josh_stern (guest, #4868)
[Link] (12 responses)
I'm saying that ndiswrapper is really an LGPL concept covertly hiding in GPL clothing. It depends on the ability to link with proprietary stuff in order to do what it is intended to do.
Posted Oct 25, 2006 23:53 UTC (Wed)
by sfeam (subscriber, #2841)
[Link] (6 responses)
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 1:29 UTC (Thu)
by josh_stern (guest, #4868)
[Link] (5 responses)
Posted Oct 26, 2006 13:19 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (4 responses)
But with ndiswrapper, it's good.
This is a perfect example of hypocrisy from the kernel developers, that's all.
Joachim
Posted Oct 26, 2006 14:48 UTC (Thu)
by cventers (guest, #31465)
[Link] (3 responses)
Actually, despite what the kernel developers might tell you, GPLv3 does
Shouldn't be IMO, but I don't make these decisions for Linux.
Sadly, indeed.
Posted Nov 3, 2006 0:40 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (2 responses)
It matters that that the kernel developers argue against GPLv3 because they think it restricts end use and they cannot tolerate such restrictions. But then they restrict end use themselves in the case of ndiswrapper. This inconsistent behavior is hypocrisy, independent of the legal facts.
Posted Nov 3, 2006 1:17 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted Nov 3, 2006 1:44 UTC (Fri)
by jschrod (subscriber, #1646)
[Link]
I didn't want to imply that all kernel developers have the opinion that ndiswrapper is illegal, but important and well known people have, as shown in the thread from your link.
Btw, I don't even use ndiswrapper myself. So my opinion is not connected to any influence on my own usage of Linux. It is a general observation about a behavior of kernel developers that I don't understand.
Posted Oct 26, 2006 3:18 UTC (Thu)
by interalia (subscriber, #26615)
[Link] (4 responses)
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 3:44 UTC (Thu)
by josh_stern (guest, #4868)
[Link]
Personally, I would have supported the decision that Debian made and I would also support people who wanted to remove GPL-only symbols from the kernel. Here I'm just saying that I also support the decision of other kernel developers not to allow unintended workarounds for using GPL-only symbol code once they've already accepted that way of doing things.
Posted Oct 26, 2006 10:47 UTC (Thu)
by syntaxis (guest, #18897)
[Link] (1 responses)
Posted Oct 27, 2006 2:12 UTC (Fri)
by interalia (subscriber, #26615)
[Link]
Yes, that's what I said :) I probably wasn't very clear, but I said the maintainer felt it was OK for main and no-one tried to override his decision, implying that the maintainer's decision held.
Posted Oct 31, 2006 4:45 UTC (Tue)
by proski (subscriber, #104)
[Link]
All "linking" is happening in the kernel memory on the end user system. There is no such thing as ndiswrapper "linked" to a non-free driver for the purpose of distribution.
Posted Oct 26, 2006 1:56 UTC (Thu)
by dlang (guest, #313)
[Link] (15 responses)
so even if ndiswrapper was LGPL instead of GPL, how does that make it less acceptable?
Posted Oct 26, 2006 2:05 UTC (Thu)
by josh_stern (guest, #4868)
[Link] (14 responses)
I meant that ndiswrapper has an LPGL-like philosophy that is ideologically incompatible with the intent of those kernel developers who wanted their work to use EXPORT_SYMBOL_GPL only. At least that is my interpretation.
Posted Oct 26, 2006 8:05 UTC (Thu)
by malor (guest, #2973)
[Link] (13 responses)
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.
Posted Oct 26, 2006 11:06 UTC (Thu)
by drag (guest, #31333)
[Link] (4 responses)
No they aren't. You just change the names around an it works fine. You just comment out the 3 lines or so that check for ndiswrapper.
There are a dozen easy ways to work around this and the kernel developers know it.
People are ignoring new open source drivers and such because their stuff works with ndiswrapper. This is entirely unsupported and can't be depended on working. People are told that it does work though, when they shouldn't be told anything of the sort.
They don't want to end up in a position were manufaturers are using ndiswrapper as a excuse for not supporting Linux.
For instance Texas Instrument used the existance of the linuxant and ndiswrapper drivers for not supporting Linux for their wifi stuff. This is a fact. They even advertise this fact by in a press release that they support linux by helping out conextent development.
If their hardware works fine in ndiswrapper then what possible justification can you provide for releasing documentation and code for writing proper drivers?!
Posted Oct 26, 2006 11:58 UTC (Thu)
by malor (guest, #2973)
[Link] (2 responses)
They're using their code to try to control what end-users do. They are painting it as a GPL issue, when it isn't. This is either dishonesty or poor thinking on their part. If they want people to use the open source drivers, they should be doing it a different way, not deliberately breaking people's machines.
The HONEST approach would be to refuse to load ndiswrapper with an error message. "We don't like this code, and we don't want you to use it." That would piss people off mightily, but it would be accurate.
We're not supposed to run Linus kernels anymore anyway. Hopefully the distros will just comment out this garbage.
Posted Oct 29, 2006 15:50 UTC (Sun)
by mingo (guest, #31122)
[Link] (1 responses)
They're using their code to try to control what end-users do.
I think you might be confusing things here. Every OS code on this planet, including the GNU Hurd OS, "controls" what end-users do: that is what code does to begin with. (For example: the Linux kernel does not allow the modification of kernel-space memory by user-space code.)
The question here is purely implementational: what does the kernel code do by default? If you dont agree with the default behavior, and if you think the resulting work is still fine under the license, you can change the source code and redistribute the result.
(Some raised the "how is this different from the GPLv3 situation" question and the answer to that is simple: the GPLv3 draft was claimed to limit what end-users can do via the license. I hope you will agree with me that there is a big difference between code-based limitations and license-based limitations.)
Posted Oct 29, 2006 17:47 UTC (Sun)
by malor (guest, #2973)
[Link]
The kernel devs were trying to make it difficult for you to run code they don't like. They've changed their minds subsequently, but they had decreed that ndiswrapper was Not Acceptable Code as written, and wrote a specific blockage of that code into the kernel. By name, even.
They were using, in other words, code to enforce a political viewpoint...and an INCORRECT political viewpoint at that, since ndiswrapper doesn't violate the GPL.
This is entirely different from code that controls behavior because of technical reasons, and you know that perfectly well. They were trying to limit end users from running *specific code*. They weren't saying "nobody can do X because it will break systems", they were saying "We don't like ndiswrapper and you can't use it anymore."
The fact that we can hack around their edict is irrelevant. We shouldn't have to.
Posted Oct 26, 2006 14:55 UTC (Thu)
by cventers (guest, #31465)
[Link]
But I absolutely agree that it's un-GPL and un-free. Bringing the GPL
Kernel developers are often heard to say "We don't do licenses, we do
Posted Oct 26, 2006 14:04 UTC (Thu)
by josh_stern (guest, #4868)
[Link] (4 responses)
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.
Posted Oct 26, 2006 14:43 UTC (Thu)
by malor (guest, #2973)
[Link] (3 responses)
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.
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.
Posted Oct 30, 2006 23:21 UTC (Mon)
by tbird20d (subscriber, #1901)
[Link] (1 responses)
Posted Nov 2, 2006 12:50 UTC (Thu)
by arcticwolf (guest, #8341)
[Link]
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.
Posted Oct 27, 2006 4:19 UTC (Fri)
by pimlott (guest, #1535)
[Link] (2 responses)
That said, the use of GPL-only symbols to enforce this is questionable and certainly confusing. GPL-only was supposed to express the intent that modules using them are derivative works. ndiswrapper acknowledges that it is a derivative, and its GPL license seems uncontrovercial since it simply implements a public interface with a variety of users.
Posted Nov 2, 2006 12:53 UTC (Thu)
by arcticwolf (guest, #8341)
[Link] (1 responses)
Posted Nov 2, 2006 15:13 UTC (Thu)
by pimlott (guest, #1535)
[Link]
Posted Oct 26, 2006 15:32 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
Posted Oct 27, 2006 0:00 UTC (Fri)
by proski (subscriber, #104)
[Link]
Andrew jumped into discussion because an LWN reader became aware of the controversy thanks to LWN and sent an e-mail to LKML and Alan Cox summarizing the thoughts expressed in your story and the comments posted by LWN readers.
In other words, LWN and you personally should be credited for restoring sanity in the kernel :)
Thanks!
Posted Oct 27, 2006 9:58 UTC (Fri)
by NRArnot (subscriber, #3033)
[Link]
OK, the former executes in a different CPU on the controller, the latter doesn't. But if you are going to claim that because of that it can't bork your Linux, or given malicious intent subvert it, you're wrong. A disk controller has DMA access to your system's memory and, of course, access to all your data on the disk.
Come to that, there IS a binary blob that executes in your system's CPU: the Intel (or AMD) CPU microcode patch blob that gets loaded very early in system initialisation. How would you like it if Intel did to Linux what Linux is doing to NDISwrapper? (thought experiment, it's not likely to happen!)
NDISwrapper creates an interface for a class of blobs having an interface specified by the NDIS driver spec. NDISwrapper is GPL code. The blobs are by definition NOT linux-derived works and are not and may not be shipped with Linux. They taint the kernel when the end user loads them. So what is the kernel trying to accomplish by blocking NDISwrapper by name?
Incidentally, what happens if someone takes the NDIS specifications and writes a null driver and GPL's it? You can then load NDISwrapper + NDIS null driver, and you'd have the kernel preventing some all-GPL software from being used! You never know, there might even be an open NDIS driver for some odd or old bit of hardware out there already, and if so this isn't even just a thought experiment.
This is reduction to absurdity. Sorry, but the kernel guys are being absurd here.
Passing thought: why does VMware emulate an AMD PCnet network card? Is its NDIS driver source open by any chance?
Posted Jan 30, 2008 0:39 UTC (Wed)
by jcm (subscriber, #18262)
[Link]
What about the nvidia graphics drivers?GPL-only symbols and ndiswrapper
How is this case different or the same?
Totally different. The NV drivers do not use the GPL symbols at all.GPL-only symbols and ndiswrapper
Get back when you get people to agree that:GPL-only symbols and ndiswrapper
propriatory code + gpl'd code you own copyright for + gpl'd code that you don't own copyright for = perfectly ok.
A lot of "probably" in there.GPL-only symbols and ndiswrapper
>Come to think of it, I suppose it's technically possible that the NV driver wrapper (which is GPL) might do the same thing.GPL-only symbols and ndiswrapper
The nvidia driver already taints the kernel and is denied access to GPL only symbols.GPL-only symbols and ndiswrapper
This is madness. Binary drivers designed for the Windows kernel cannot be considered "derivitive works" of the Linux kernel. According to Linus, modules which weren't designed for Linux and don't depend on any special Linux behaviour aren't derived works. Therefore, they don't have to be GPL. Since ndiswrapper is GPL, it should receive the same treatment as other GPL modules.
GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
Kernel developers are not obliged to do anything, but Linux development depends on respect to those developers, and also on implicit assumptions that external modules won't be blacklisted or limited based on somebody's arbitrary preferences.
GPL-only symbols and ndiswrapper
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?
GPL-only symbols and 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.
The stack size change had a real motivation other than breaking ndiswrapper.
GPL-only symbols and ndiswrapper
I look forward to your contribution of a reverse-engineered driver for my old HP S20 PhotoSmart slide scanner. GPL-only symbols and ndiswrapper
"HP S20 PhotoSmart slide scanner"GPL-only symbols and ndiswrapper
he's saying that his scanner is able to work with a windows driver and the ndis wrapper. if ndiswrapper isn't available he has no way to use his scanner.GPL-only symbols and ndiswrapper
That's odd.GPL-only symbols and ndiswrapper
'Hey, your a dipshit if you release your IP (documetation, code, etc) for open source developers to write drivers when end users will just use the windows drivers anyways. Other guys aren't doing it and their stuff runs in Linux just fine, so why should you?'
GPL-only symbols and ndiswrapper
"There does not seem to be any particular interest in the kernel community in backing down on this change"GPL-only symbols and ndiswrapper
Speaking of GPLv3, suddenly end use restrictions are good? Whatever happened to:
Runtime restrictions
our belief in the essential freedoms of section 3 forbids us from ever accepting any licence which contains end use restrictions.
The even greater irony is that the document you link is wrong about end Runtime restrictions
use restrictions in the first place. GPL's terms don't even apply to the
end user. It only restricts what you do when you make copies.
Isn't a distributor also usually an end user? Shouldn't the rights granted to a distributor also be granted to an end user?Runtime restrictions
A distributor may also be an end user, but calling restrictions on Runtime restrictions
distribution 'end use restrictions' is wrong and/or intellectually
dishonest, because the restrictions in question don't apply to mere end
users and only apply to distributors.
any later version" clause or lack of version specification.
Runtime restrictions
No, that's definitely not what he did.Runtime restrictions
Well said.GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
I do not know whether ndiswrapper truly needs these GPL symbols; let us assume that it does.
USB support cannot be implemented without them. The message is quite misleading, by the way:
Symbol usb_register_driver is being used by a non-GPL module, which will
not be allowed in the future
USb drivers can be written in userspace anyway, so that shouldn't be a problem.GPL-only symbols and ndiswrapper
Yeah, but how are those userspace drivers supposed to talk to the restGPL-only symbols and ndiswrapper
of the kernel and the non-GPLONLY functions and services it provides?
do URB tx/rx, but nothing more. It's useless if you need to hook into the rest of the kernel.
I thought we were talking about binary only modules and ndiswrapper? In that light I don't see how that construction could be in anyway better than when pushed to userspace. Currently closed source kernel modules from ATI and Nvidia should also be put into userspace with no more than a tiny kernel module handling the necessary, IMHO.GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
I thought we were talking about binary only modules and ndiswrapper? In that light I don't see how that construction could be in anyway better than when pushed to userspace.
I think many people would prefer not to run closed source Windows driver with the kernel permissions (in "ring 0" in x86 terminology). Of course, having a network driver in userspace can have its drawbacks.
Currently closed source kernel modules from ATI and Nvidia should also be put into userspace with no more than a tiny kernel module handling the necessary, IMHO.
Sorry, that's getting off-topic, and I'm in now way a video card expert, but how are you going to emulate Linux API expected by those modules (provided you are talking about Linux modules)? Are you going to reimplement it in userspace? I think that's going to be the hard part, and not the "tiny kernel module".
The few extra milliseconds latency is well worth it, if it's even that high.GPL-only symbols and ndiswrapper
> Are you going to reimplement it in userspace?
Tehnical issues aside (wasn't NDIS specifically designed to allow binary portability of network drivers?), what I don't get is this: the kernel developers know very well that many people use ndiswrapper, simply because they don't have a choice. It is much better to use Linux + ndiswrapper, than not to use Linux at all. So, suddenly they are saying "we don't care about you guys anymore, go buy another laptop".GPL-only symbols and ndiswrapper
- Buy another laptop (yeah, right)
- Use Windows (yeah, right)
- Patch the kernel to remove the restriction.
Well, I'm neither a user of ndiswrapper nor Ubuntu, but what I think Ubuntu and other distributions depending on ndiswrapper should do, is to essentially show kernel developers a finger by shipping a modified kernel, one that does has this new "feature" disabled.Re: I wonder whether Ubuntu will ship a kernel with ndiswrapper disabled
> that many people use ndiswrapper, simply because they don't have a choiceGPL-only symbols and ndiswrapper
>- Patch the kernel to remove the restriction.
> From spending time giving free linux support to linux newbies on IRC I've found that the majority of people trying to use ndiswrapper today are trying to use hardware for which there currently exists free driversGPL-only symbols and ndiswrapper
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).
Seriously, this is out of the question. 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.
- Less available memory ?
- Slower ?
- Less stable ???
- Worse battery life ??? (but is it really, considering that currently the battery life in Windows is noticeably better)
- Better networking (my wireless does work better in Windows than Ubuntu)
- Longer battery life
- Convenient access to Windows applications in the few cases you do need them
- Much more controllable, easy to back and restore the entire image
GPL-only symbols and ndiswrapper
They have the right to install proprietary drivers. You're supposed to be giving them freedom, not chaining them to free code. GPL-only symbols and ndiswrapper
> They have the right to install proprietary drivers.GPL-only symbols and ndiswrapper
>> are trying to use hardware for which there currently exists free driversGPL-only symbols and ndiswrapper
>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).
> Although most people don't realize it, almost all laptop's wireless cardsGPL-only symbols and ndiswrapper
> are on mini-pci and are removable as a result. Linux compatible mini-pci
> cards can be purchased for fairly low prices, and cards are available with
> far better recieve sensitivity and higher transmit power than what
> probably shipped with their laptop. So while not an ideal solution, it
> isn't unreasonable to suggest that someone change their hardware.
So basically developpers are trying to put a technical restriction to solve a communication problem. That won't work.Wrong problem, wrong solution
You presume a single agent where there are many. Wrong problem, wrong solution
Links for mini-PCI wireless cards with free drivers?
GPL-only symbols and ndiswrapper
The only difference between GPL and LGPL is that the latter comes with a promise not to argue about the exact issue being argued about here. So what is your point, exactly?GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
I don't see any references to LGPL in ndiswrapper code.GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
Please see above.GPL-only symbols and ndiswrapper
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.
It is understood that it is not technically a license violation to distribute ndiswrapper. But the discussion here is not about legal technicalities but rather about whether it was appropriate behavior for the kernel developers to redefine their policy wrt ndiswrapper and EXPORT_SYMBOL_GPL. From my point of view, the new policy is understandable as something designed to better support the intentions of the developers who wanted the use of their code restricted (note - it wouldn't be surprising if Linus accepted later patches introducing different implementations without those restrictions, but that's not really the point). So the discussion about appropriateness should center on whether it was a good idea to respect the intentions of those developers at the expense of user inconvenience.
GPL-only symbols and ndiswrapper
Ah, in the GPLv3 it is bad that end use is restricted.GPL-only symbols and ndiswrapper
> Ah, in the GPLv3 it is bad that end use is restricted.GPL-only symbols and ndiswrapper
no such thing. It's still just a copyright license. You don't even have
to accept it to use the covered work!
> But with ndiswrapper, it's good.
> This is a perfect example of hypocrisy from the kernel developers,
> that's all.
For my argument, it doesn't matter if the GPLv3 restricts end use or not.GPL-only symbols and ndiswrapper
As reported on this very site, that was an accident. No hypocrisy here.
GPL-only symbols and ndiswrapper
Please click on the link in your post, then click on "Thread", and then read the comments of Alan Cox, Adrian Bunk, and others. Also Arjan van de Ven to some extent (he wants to patch it now, but doesn't acknowledge the USB problem). Please note as well that the thread states that the kernel developers think seriously about reintroducing the problem in 6 months again, just to give ndiswrapper developers and users more time to plan some action until then. (Well, but what action? Maybe installing Windows because Linux won't support their exotic USB hardware any more? 0.5 ;-) )GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
It depends on the ability to link with proprietary stuff in order to do what it is intended to do.
GPL-only symbols and ndiswrapper
Currently ndiswrapper is in Debian main, not non-free.
http://packages.debian.org/cgi-bin/search_packages.pl?searchon=sourcenames\
&version=all&exact=1&keywords=ndiswrapper
GPL-only symbols and ndiswrapper
<blockquote>Currently ndiswrapper is in Debian main</blockquote>GPL-only symbols and ndiswrapper
I believe you misunderstood the discussion. I don't think moving ndiswrapper to non-free was even considered. It was discussed whether to put ndiswrapper to contrib. Software in contrib is required to follow the DFSG, but it's allowed to depend on non-free software. In other words, nobody challenged the notion that ndiswrapper was free software per se.
GPL-only symbols and ndiswrapper
LGPL code can be included in the kernel, just like BSD code can be included in the kernel.GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
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. 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.""GPL-only symbols and ndiswrapper
In other words, you just agreed with me that it IS NOT about the GPL. It has nothing to do with the GPL. The GPL is a big fat red herring. GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper & GPLv3
Oh for chrissake, you're splitting hairs. GPL-only symbols and ndiswrapper & GPLv3
I agree that ndiswrapper is a problem in the long run (though I respect GPL-only symbols and ndiswrapper
its authors for coming forth with a solution, even if I don't agree with
it).
into this is a huge red herring because the end-user is not bound by the
terms of the GPL. If proprietary NDIS drivers were being shipped
side-by-side with ndiswrapper, I'd call that suspicious if not completely
illegal, but GPL does _not_ apply to end users.
code!" or "Ask an attorney." This is just further proof that they are
right, because they still seem to think GPL somehow controls what an end
user does.
"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."GPL-only symbols and ndiswrapper
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. GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
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.
First of all, let me say that IANAL, so you should disregard everything I wrote here - including this line. ^_~GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
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.
They are not trying to restrict, they are trying to make less convenient.
The FSF is well-known to do this as well. For example, it declines features in GCC to export and import the intermediate formats, so that end-users can't conveniently plug in proprietary front- and back-ends. It's not exactly the same technically, but the goal is the same: Reject hooks that could be used by proprietary software. Users can always add them themselves, so it is in no way a restriction of the FSF's freedoms.
But there is a difference between "we won't make it easier for you" and "we will make it more difficult for you on purpose". I can very much understand that the gcc folks aren't willing to spend time and energy on implementing features that essentially would be of use only (or mostly) to vendors of proprietary front-/back-ends, but they aren't going out of their way and spending and energy on implementing restrictions that make it even more difficult to do that and that don't serve any other purpose, either. (Or are they?)GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
Or are they?
If our discussion were more timely, Joe Buck would answer. :-) I'm out of my authority here, but I think I've heard that there have been developers interested in implementing it, and that it was vetoed from the top.
An update: Andrew Morton has jumped into the discussion, stating that he had not expected this particular result from the patch. The breaking of ndiswrapper, he says, was a "mistake." So things might just get reverted - for now, at least.
Andrew Morton: "this was a mistake"
Jon,
Andrew Morton: "this was a mistake"
What is the difference between a binary blob loaded by (say) a RAID controller driver, and a binary blob (aka Windows NDIS driver) loaded by NDISwrapper?GPL-only symbols and ndiswrapper
GPL-only symbols and ndiswrapper
I guess I just started round 2 of this debate, actually not really intentionally...sorry :)
Jon.