"A change after 2.6.24 broke ndiswrapper by accidentally removing its access to GPL-only symbols," noted Pavel Roskin, offering a patch to address the issue. Linux creator Linus Torvalds was unimpressed, "I'm not seeing why ndiswrapper should be treated separately. If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols." The NDISwrapper project page explains, "many vendors do not release specifications of the hardware or provide a Linux driver for their wireless network cards. This project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel. A Windows driver for wireless network card is then linked to this implementation so that the driver runs natively, as though it is in Windows, without binary emulation." Due to this, Linus explained:
"Ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL'd."
From: Pavel Roskin <proski@...> Subject: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 28, 6:11 pm 2008 A change after 2.6.24 broke ndiswrapper by accidentally removing its access to GPL-only symbols. Revert that change and add comments about the reasons why ndiswrapper and driverloader are treated in a special way. Signed-off-by: Pavel Roskin <proski@gnu.org> --- kernel/module.c | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index 901cd6a..a11f523 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -1933,8 +1933,15 @@ static struct module *load_module(void __user *umod, /* Set up license info based on the info section */ set_license(mod, get_modinfo(sechdrs, infoindex, "license")); + /* + * ndiswrapper is under GPL by itself, but loads proprietary modules. + * Don't use add_taint_module(), as it would prevent ndiswrapper from + * using GPL-only symbols it needs. + */ if (strcmp(mod->name, "ndiswrapper") == 0) - add_taint_module(mod, TAINT_PROPRIETARY_MODULE); + add_taint(TAINT_PROPRIETARY_MODULE); + + /* driverloader was caught wrongly pretending to be under GPL */ if (strcmp(mod->name, "driverloader") == 0) add_taint_module(mod, TAINT_PROPRIETARY_MODULE); -- Regards, Pavel Roskin --
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 28, 7:25 pm 2008 On Thu, 28 Feb 2008, Pavel Roskin wrote: > > A change after 2.6.24 broke ndiswrapper by accidentally removing its > access to GPL-only symbols. Revert that change and add comments about > the reasons why ndiswrapper and driverloader are treated in a special > way. I'm not seeing why ndiswrapper should be treated separately. If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols. So if ndiswrapper needs GPL-only symbols, you'd better ask the people who made those symbols GPL-only whether they could be made available to ndiswrapper. ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL'd. Linus --
From: Pavel Roskin <proski@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 2:20 am 2008 Quoting Linus Torvalds <torvalds@linux-foundation.org>: > On Thu, 28 Feb 2008, Pavel Roskin wrote: >> >> A change after 2.6.24 broke ndiswrapper by accidentally removing its >> access to GPL-only symbols. Revert that change and add comments about >> the reasons why ndiswrapper and driverloader are treated in a special >> way. > > I'm not seeing why ndiswrapper should be treated separately. It is already treated separately, and has been for a long time. Since ndiswrapper taints itself when it loads a proprietary NDIS module, I don't think any special treatment is needed anymore, but that's beyond my point. All I'm trying to do it to revert a patch that, as its author admitted, had unexpected consequences: http://kerneltrap.org/mailarchive/linux-kernel/2008/1/30/648044 > If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols. This is not the original intention of GPLONLY. GPLONLY exists to prevent loading of modules that are proprietary, but can be considered to be Linux derivatives due to their use of Linux specific API. In case of ndiswrapper, there is no question that ndiswrapper is a Linux derivative, but it's under GPL. Yet the proprietary modules are not Linux derivatives because they don't use Linux API. In fact, they were never intended to run on Linux. By using GPLONLY to exclude ndiswrapper, you would give GPLONLY an additional meaning, namely functions that are not available to ndiswrapper. > So if ndiswrapper needs GPL-only symbols, you'd better ask the people who > made those symbols GPL-only whether they could be made available to > ndiswrapper. That would mean that I would have to ask those symbols to be opened to proprietary Linux kernel modules as well, which is not my intention. > ndiswrapper itself is *not* compatible with the GPL. Trying to claim that > ndiswrapper somehow itself is GPL'd even though it then loads modules that > aren't is stupid and pointless. Clearly it just re-exports those GPLONLY > functions to code that is *not* GPL'd. Simple re-exporting would be useless. It's a wrapper that isolates NDIS API from Linux API. Anything Linux specific is in ndiswrapper itself. The proprietary modules call only NDIS functions. I believe, the license is a choice of the copyright holders. Apart from that, I don't feel qualified to discuss any legal matters. -- Regards, Pavel Roskin --
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 12:08 pm 2008 On Fri, 29 Feb 2008, Pavel Roskin wrote: > > > > I'm not seeing why ndiswrapper should be treated separately. > > It is already treated separately, and has been for a long time. No, I mean "separately from the thing it loads". It loads non-GPL code, it is non-GPL. > > If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols. > > This is not the original intention of GPLONLY. GPLONLY exists to prevent > loading of modules that are proprietary, but can be considered to be Linux > derivatives due to their use of Linux specific API. Exactly. And ndiswrapper loads proprietary modules. You're not following the argument. There was a reason ndiswrapper was marked for tainting. Linus --
From: Zan Lynx <zlynx@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 12:59 pm 2008 On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote: [cut] > It loads non-GPL code, it is non-GPL. [cut] > Exactly. And ndiswrapper loads proprietary modules. The Linux kernel itself will load proprietary modules. It does not as a general rule, but it will. Is the Linux kernel then not GPL? No. This argument doesn't work, Linus. There exists at least one GPL NDIS driver[1]. How about if everyone involved piously promises to load it at least once? [1] http://cipe-win32.sourceforge.net/ --=20 Zan Lynx <zlynx@acm.org>
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 1:07 pm 2008 On Fri, 29 Feb 2008, Zan Lynx wrote: > > The Linux kernel itself will load proprietary modules. It does not as a > general rule, but it will. .. and it doesn't export GPLONLY modules to them. How stupid do you have to be to not understand that? Linus --
From: Pavel Roskin <proski@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 1:20 pm 2008 On Fri, 2008-02-29 at 09:07 -0800, Linus Torvalds wrote: > > On Fri, 29 Feb 2008, Zan Lynx wrote: > > > > The Linux kernel itself will load proprietary modules. It does not as a > > general rule, but it will. > > .. and it doesn't export GPLONLY modules to them. > > How stupid do you have to be to not understand that? Actually, it's a flawed comparison. The only thing ndiswrapper exports to NDIS modules is NDIS API. GPLONLY symbols are only used to implement that API in the code that's under GPL. That's the code you can fork, change and redistribute. -- Regards, Pavel Roskin --
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 1:33 pm 2008 On Fri, 29 Feb 2008, Pavel Roskin wrote: > > Actually, it's a flawed comparison. The only thing ndiswrapper exports > to NDIS modules is NDIS API. GPLONLY symbols are only used to implement > that API in the code that's under GPL. That's the code you can fork, > change and redistribute. .. and it's stuill just a wrapper. A fairly thick one, but still... More importantly, none of the people arguing against this at all even reacted to my suggestion for how to fix things *properly* in my original email. Which just means that you're apparently not interested in actually fixing this, you're just trying to disagree about some interpretation of GPLONLY. In other words: the next person who can't even be bothered to tell what symbols are involved and why they haven't asked whether those symbols could instead be relaxed, automaticaly will go into my "flamers" filter, and just stay there. Then you can complain as much as you like, and I'll never see it. Linus --
From: Pavel Roskin <proski@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 3:39 pm 2008 On Fri, 2008-02-29 at 09:33 -0800, Linus Torvalds wrote: > > On Fri, 29 Feb 2008, Pavel Roskin wrote: > > > > Actually, it's a flawed comparison. The only thing ndiswrapper exports > > to NDIS modules is NDIS API. GPLONLY symbols are only used to implement > > that API in the code that's under GPL. That's the code you can fork, > > change and redistribute. > > .. and it's stuill just a wrapper. > > A fairly thick one, but still... So it the Linux syscall interface. It's a wrapper around the kernel internals, including GPLONLY symbols. Yet some userspace programs are proprietary. > More importantly, none of the people arguing against this at all even > reacted to my suggestion for how to fix things *properly* in my original > email. Which just means that you're apparently not interested in actually > fixing this, you're just trying to disagree about some interpretation of > GPLONLY. I'm actually interested in fixing this, or I would not have sent a patch. > In other words: the next person who can't even be bothered to tell what > symbols are involved and why they haven't asked whether those symbols > could instead be relaxed, automaticaly will go into my "flamers" filter, > and just stay there. Then you can complain as much as you like, and I'll > never see it. Well, here's the list __create_workqueue_key destroy_workqueue flush_workqueue queue_work task_nice usb_alloc_urb usb_buffer_alloc usb_buffer_free usb_clear_halt usb_control_msg usb_deregister usb_free_urb usb_get_current_frame_number usb_get_descriptor usb_get_status usb_ifnum_to_if usb_init_urb usb_kill_urb usb_lock_device_for_reset usb_register_driver usb_reset_configuration usb_reset_device usb_set_interface usb_submit_urb usb_unlink_urb I already know what USB folks will say. They want proprietary drivers to be in the userspace. I doubt ndiswrapper will ever be ported to the userspace. It's much more likely that some other approach will be used. -- Regards, Pavel Roskin --
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 3:53 pm 2008 On Fri, 29 Feb 2008, Pavel Roskin wrote: > > I already know what USB folks will say. They want proprietary drivers > to be in the userspace. I doubt ndiswrapper will ever be ported to the > userspace. It's much more likely that some other approach will be used. If that's the case, then talk to the USB people. Maybe they are ok with wrapping them in GPL wrappers. But it sounds like they would prefer the stricter GPLONLY meaning (ie no ndiswrapper), and it's their code. Linus --
From: Pavel Roskin <proski@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 4:08 pm 2008 On Fri, 2008-02-29 at 11:53 -0800, Linus Torvalds wrote: > > On Fri, 29 Feb 2008, Pavel Roskin wrote: > > > > I already know what USB folks will say. They want proprietary drivers > > to be in the userspace. I doubt ndiswrapper will ever be ported to the > > userspace. It's much more likely that some other approach will be used. > > If that's the case, then talk to the USB people. Maybe they are ok with > wrapping them in GPL wrappers. But it sounds like they would prefer the > stricter GPLONLY meaning (ie no ndiswrapper), and it's their code. This still leaves us with the workqueue interface: __create_workqueue_key destroy_workqueue flush_workqueue queue_work ndiswrapper has its own workqueue implementation, but it would be great to avoid code duplication. As for task_nice(), it's strange that task_nice() is GPLONLY, but set_user_nice() is not. Anyway, it can probably be worked around. -- Regards, Pavel Roskin --
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 4:28 pm 2008 On Fri, 29 Feb 2008, Pavel Roskin wrote: > > This still leaves us with the workqueue interface: > > __create_workqueue_key > destroy_workqueue > flush_workqueue > queue_work Hmm. Personally, I don't see those as being a big issue, but they've been marked GPL-only for a long while. The thing is, I personally don't mind, and I think "derived code" is what matters, but others disagree, and quite frankly, I'm not going to force them - I have my _personal_ beliefs, but hey, others have theirs. So you really need to talk to not me, but to the people who actually wrote and maintain that code. When they come back and say "yeah, we think ndiswrapper is a special case and we're ok with it", I'll happily either mark those things non-GPL or just mark ndiswrapper special in the module loader again. Quite frankly, I don't care about ndiswrapper enough (at all) to push this along in the least. Linus --
From: Pavel Roskin <proski@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 5:13 pm 2008 On Fri, 2008-02-29 at 12:28 -0800, Linus Torvalds wrote: > > On Fri, 29 Feb 2008, Pavel Roskin wrote: > > > > This still leaves us with the workqueue interface: > > > > __create_workqueue_key > > destroy_workqueue > > flush_workqueue > > queue_work > > Hmm. Personally, I don't see those as being a big issue, but they've been > marked GPL-only for a long while. > > The thing is, I personally don't mind, and I think "derived code" is what > matters, but others disagree, and quite frankly, I'm not going to force > them - I have my _personal_ beliefs, but hey, others have theirs. > > So you really need to talk to not me, but to the people who actually wrote > and maintain that code. As far as I can tell, those people have never tried to prevent ndiswrapper from using their code. Both times ndiswrapper was prevented from using GPLONLY symbols, it was done unintentionally. > When they come back and say "yeah, we think > ndiswrapper is a special case and we're ok with it", I'll happily either > mark those things non-GPL or just mark ndiswrapper special in the module > loader again. OK, I'll keep it in mind in case such approach actually becomes necessary. -- Regards, Pavel Roskin --
From: Chris Friesen <cfriesen@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 12:54 pm 2008 Linus Torvalds wrote: > > On Fri, 29 Feb 2008, Pavel Roskin wrote: > >>>I'm not seeing why ndiswrapper should be treated separately. >> >>It is already treated separately, and has been for a long time. > > > No, I mean "separately from the thing it loads". > > It loads non-GPL code, it is non-GPL. But the GPL only applies to derivative works. Given that ndiswrapper loads binaries designed for another OS, doesn't that mean that it is unlikely that the binaries would be impacted by the GPL? So the portion that is a derivative work (ndiswrapper itself) is GPL, and it loads something that is clearly not a derivative work. From a licensing standpoint how is this different than an open-source driver loading a proprietary firmware? Once ndiswrapper loads the binary blob the kernel should be considered tainted from a debuggability standpoint, but I have some sympathy for an argument suggesting that ndiswrapper should be able to use GPLONLY symbols. Chris --
From: Linus Torvalds <torvalds@...> Subject: Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Date: Feb 29, 1:06 pm 2008 On Fri, 29 Feb 2008, Chris Friesen wrote: > > But the GPL only applies to derivative works. Given that ndiswrapper loads > binaries designed for another OS, doesn't that mean that it is unlikely that > the binaries would be impacted by the GPL? But that's what GPLONLY means. What's so hard to understand? The driver may not be a derivative work, but it sure as hell isn't GPL'd. So stop blathering. ndiswrapper has one purpose, and one purpose only: to load non-GPL'd code. So OF COURSE it shouldn't touch GPLONLY functions. Linus --
| Resetting the bios password for Toshiba Laptop | 7 hours ago | Hardware |
| Lock contention | 20 hours ago | Linux kernel |
| PAGE_ALIGN | 2 days ago | Linux kernel |
| bootsplash patch for kernel 2.6.25.3-zen1 | 3 days ago | Linux kernel |
| sysfs_create_group() | 3 days ago | Linux general |
| temporary mapping | 3 days ago | Linux kernel |
| ATI ES1000 driver | 4 days ago | Linux general |
| Can anyone tell me the Procedure to create an init ramdisk using busybox | 5 days ago | Linux general |
| mapping of High Memory to ZONE_NPRMAL | 1 week ago | Linux kernel |
| Page global directory | 1 week ago | Linux kernel |
isnt this what apple/webkit
isnt this what apple/webkit is doing to get some insane js improvements in safari? some private functions on a few select can use?
No.
No.
No. Read
No.
Read this:
http://blog.vlad1.com/2008/02/28/finding-the-os-x-turbo-button/
But this gets repeated a lot...
Oddly enough, the page you link to has some interesting comments by the author aimed at those who are taking his article out of context. To quote:
Another example of so called
Another example of so called "freedom" caused by GPL.
The freedom that the one who
The freedom that the one who wrote the code decides whether it can be used for proprietary drivers?
Very condemnable, really...
GPL is supposed to give
GPL is supposed to give "freedom" to the _users_.
Well, yeah, sure, the
Well, yeah, sure, the "_users_" can always apply the patch in the email above to their kernel and recompile it. *shrug*
Redistributing it can get them into trouble though.
Actually, they can't get in trouble
Actually, they can't get in legal trouble.
If the original code and this patch code are GPL'd, they can not only add it they CAN redistribute it, as long as they GPL the result (and abide by it - e.g. distribute the source if asked.)
This prevents anyone, ever, from forcing things too strongly, and is a big part of the point of the GPL.
Of course, the get in SOCIAL trouble - because what I just described is a fork, so doing so is considered rude unless you have a really good reason. But the big disadvantage is really just that if you fork it you'll have to re-patch each new version yourself, which is a pain.
on the long-term this is good
graylisting, then blacklisting hardware without drivers could be a winner on the long term
I myself chose my last laptop after being perfectly aware that it does not contain devices from specific (chipset) vendors.
The more we do this, the better. Little restriction now, more freedom later.
So call me dense but...
what is to keep NDISWrapper from distributing itself with a patch to the kernel which restores this access? What is to keep distros from including the patch in their kernels?
IMO, Linus is probably wrong on this one, but what keeps people from simply going around him? Isnt that freedom found in the GPL itself?
The problem is that working
The problem is that working code is actively attacked by the kernel developers.
The goal to have everything open source under GPL is laudable, but in reality it is not as easy, and I think the whole Linux is hostile and unfriendly towards these developers.
I am using ndiswrapper happily, and it works.
No ndiswrapper here ...
I'm using BSD, happily, and it works; without idiotic wrappers. For some reason, BSD is far ahead of Linux when it comes to wireless support.
Yes, I know this sounds like flamebait, but it's not intended to. I use GNU/Linux too, FWIW ;-)
NDIS on FreeBSD
Without wrappers? What about http://www.freebsd.org/cgi/man.cgi?query=ndis ?
--
:wq
Available
Sure, it's available on some BSDs. I didn't say it wasn't or that every Wireless card was supported.
I'm using BSD, happily, and
Puhleeez! Do tell me if you can get any of the Intel-chipsets to work, eh? Last time I looked, you couldn't and that's the one and only reason I'm still using Linux on my laptop (OK, maybe because of suspend2ram, too). Would rather use BSD, but, huh, I can't make do without driver support for my Intel 3945 card.
Intel cards ...
Not any Intel cards, you say?
OLD really OLD stuff is
OLD really OLD stuff is that.
What about th 4965? Iwlwifi? -.-
Not sure
I don't know. Why don't you look it up yourself? You Linux fanboys are furiously trying to find something to attack BSD with. No WPA yet? Wow, BSD sucks! The newest Intel card isn't supported? Wow, BSD sucks! I don't care what you like or don't like. But that does not change the simple fact that BSD (OpenBSD in particular) have much better wireless support than Linux. Get over it.
Suspend2ram and wireless drivers
Wow ... you got suspend2ram to actually work? I am awestruck ... it's been a non-starter for while on a 2005 laptop.
FWIW, when linux wireless drivers actually work maybe I won't need ndiswrapper, which btw I've been using since 2005 without a hitch.
Sounds like I probably won't have wireless the next time I update the kernel ... thanks guys ... go GPL !!!
Better approach
And that reason is: instead of trying to run Windows drivers, signing NDAs and/or using binary blobs, the OpenBSD folks try to get the vendor to free the programming documentation and, in case that fails, they try to reverse-engineer the hardware.
http://cvs.openbsd.org/papers/brhard2007/mgp00012.html
Yes, much better
Yes, and they also make sane tools for configuring wireless devices. OpenBSD use the well known
ifconfigcommand.Linux apparently thinks this is a bad idea, so they add
iwconfigand a bunch of other "fancy" commands for wireless support. That's after you've wasted hours trying to getndiswrapper, MadWifi, or what not going.With so many people hacking Linux, I'm amazed that this is the best they've come up with.
All the more reason...
That's all the more reason to raise an eyebrow at NDISwrapper and not give it an unnecessary free pass.
--
Program Intellivision and play Space Patrol!
Where's WPA for OBSD?
Where's WPA for OBSD?
WPA
They don't bother much with that because WPA still sucks and using an IPSec solution is much better.
Mmm hmmm
I'm sure that allows you to usefully connect to others' WPA-configured networks, too.
--
Program Intellivision and play Space Patrol!
It doesn't
No, it doesn't, which is one of the reasons they /are/ working on WPA. It's just that it's not all that high up on their to-do list.
What would you prefer; poor hardware support and WPA, or good hardware support but no WPA? I for one would prefer the latter (or good hardware support /and/ WPA, but let's be realistic here) ;-)
Ehm... Of course WPA is more
Ehm... Of course WPA is more important than more hardware support you can mostly choose the hardware yourself, but you can't control the people you need to visit (No, OS support will NOT overrule who I keep as friends)
So you choose your friends
So you choose your friends based on what wireless security protocol they have?
ehm, you apparently read the
ehm, you apparently read the opposite of what I wrote
And yet they still support
And yet they still support WEP.
WEP and WPA
Ofcourse. WEP is rather easy to implement compared to the over-engineered beast that is WPA, so why not?
However, they're not recommending it as a security solution. A quote from ipw(0): "Unfortunately, due to serious weaknesses in the WEP protocol it is strongly recommended that it not be used as the sole mechanism to secure wireless communication."
So, there you have it. It's all rather simple. WEP is supported because it's easy to support compared to WPA. WPA is of course desirable (and work /is/ being done to support it), because some APs requires it. However, for securing a wireless network, OpenBSD provides far better mechanisms than WEP or WPA (AuthPF + IPSec comes to mind).
stop blathering! how can you
stop blathering! how can you compare ipsec and WPA? are you so dumb? if your OS does not support WPA, it is a piece of shit and you can shove it. if it cant support a card natively, it needs to be fixed, but puhleaze, WPA uses AES instead of RC4, and if obsd cant even get that in, it means it is a *DEAD* project with not enough people to contribute.
the nice thing about a DEAD project is that it stays that way ad infinitum...
Dead?
It's not dead, it's been carved in stone! https://https.openbsd.org/images/tshirt-26_front.gif
OK, don't feed the trolls. Sorry.
thats a tomb stone.
thats a tomb stone.
And yet, they've got WEP.
And yet, they've got WEP. Which, I guess, doesn't suck?
> Where's WPA for
> Where's WPA for OBSD?
wpa_supplicant, so what's the problem?
The problem is ...
The problem is this http://www.undeadly.org/cgi?action=article&sid=20070705092624
So, it's not ready yet but work is being done.
and I think the whole Linux
and I think the whole Linux is hostile and unfriendly towards these developers.
----------------
No, the kernel developers are protecting themselves and linux. Sometimes that means tough love. Is everyone's memory so short they forget the SCO vs. World stuff?
Tainting the kernel will destroy it eventually, even if you just taint it "a little" ; ) It's precisely vigilance like this on the kernel developer's part that saved IBM (and subsequently linux) in court. Had the kernel really been tainted with the code that SCO now owns, we'd all be paying SCO through the nose to run linux.
If the NDISWrapper developers have any sense, they'll take Linus' advice and not use the GPLONLY symbols. It will take more work, but long term legal stability with the kernel code is far too important compared to some extra work that one group of developers needs to do to support a very limited number of users.
If he allowed it, he'd be unfriendly to everyone else that uses the kernel.
How would everyone feel if this led to the kernel project folding because they couldn't defend themselves in court because they really were wrong and violated IP laws? The FSF and all the high powered lawyers in the world couldn't help them then and everyone running a linux server would be EOL'd, along with their jobs.
Linus has no say in the matter, he's just following the law. It's the law and hardware manufacturers that won't support linux that you should be pointing fingers at. The kernel crew enables not disables. They leave all the disabling and restricting up to the screwed up laws and lawyers.
They do their best to work with these restrictions, but sometimes there's nothing they can do. All of this animosity should be directed towards a letter writing campaign to congress to get the relevant IP laws changed, which caused this mess. It might do some good then.
-Viz
First, the GPL license
First, the GPL license wouldn't help in any way if Linux kernel contained any SCO code. It woulnd't prevent adding code owned by SCO or infringing any kind of IP either.
Second, there are various projects that do just fine with mixing licenses.
Third, it seems you're trying to invent some philosophy where there is just a simple restriction placed (or maybe not; that thing is disputable and FSF didn't do anything to make the situation more clear - as opposed to, say, CDDL, which goes to great lengths to define what is _not_ a derived work) in the GPL license. It's the same "more freedom by adding restrictions" thing as usual.
SCO owns nothing
"Had the kernel really been tainted with the code that SCO now owns, we'd all be paying SCO through the nose to run linux."
SCO owns nothing. Novell owns all the UNIX code copyright. The court ruled about that not so long ago.
ndiswrapper doesn't work for everything
I came across that comment while searching for information about how to get a wireless network adapter to work. I tried ndiswrapper already, and it sort of works. Except that half the functionality I need doesn't work, and it frequently crashes my system. I'd be happy to see a user mode implementation of ndiswrapper if that would make it more stable. But that wouldn't make up for the lack of essential functionality such as master mode and bridging.
Broadcom...
"I am using ndiswrapper happily, and it works."
I'm using it too. And I'll be doing that as long as it will work better than the reverse engineered bcm43xx/b43 driver. Besides, the aforementioned driver still needs the windows driver to cut firmware from it, so there's no difference for me - I still need the damn blob.
THis not really correct. The
THis not really correct. The 4 freedoms apply to the code. To make sure the code stays free. IT is not intended to let teh _user_ do what ever they want with it. That is more public domain or possibly the 3 line BSD(I may be wrong on this last point, not really a BSD person).
GPL Freedom
No, the GPL is supposed to give freedom to developers. It doesn't give a whit about users.
GPL NOT an end-user license
>GPL is supposed to give "freedom" to the _users_.
Incorrect.
Read the GPL.
It is neutral to the user.
The GPL protects the AUTHOR and enables DISTRIBUTION.
It does not speak to the USERS at all. It neither constrains the user's rights, nor does it grant any rights to the user. Copyright does that, by allowing an author to grant nonexclusive licenses.
Not true. Author does not
Not true. Author does not need any kind of license to protect his rights, they are protected by default. Purpose of GPL is to give away some of them, in order to give some kind of freedom to the recipients of the code - users and other developers. And it's the restrictive definition on that freedom - compared to freedom granted by BSD or MIT (or public domain) licenses - that causes problems like this.
The GPL explicitly states
The GPL explicitly states that the user can do anything s/he wants, it only limits distribution of the product
"This program is Free
"This program is Free software. You are Free to use it only in ways that I approve of." Now compare this to the inherent freedom of use that comes with, say, a hammer...
Not exactly.
You can do whatever you want with the code for your own purposes, including modifying it to use NDISwrapper. Nothing stops you, and it's permitted by the license. The GPL does not take that freedom from you.
Redistributing the result, though, is not permitted. However, anyone else is free to do just as you did.
--
Program Intellivision and play Space Patrol!