Forgot your password?
typodupeerror
Linux Software

Linus Denounces NDISWrapper, Denies It GPL Status 457

Posted by CmdrTaco
from the he-has-spoken dept.
eldavojohn writes "On message boards, Linus Torvalds was explaining why NDISWrapper is not eligible to be released under the GPL even though the project claims to be. Linus remarked, "Ndiswrapper itself is *not* compatible with the GPL. Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. Clearly it just re-exports those GPLONLY functions to code that is *not* GPL'd." This all sprung up with someone restricted NDISWrapper's access to GPL-only symbols thereby breaking the utility. Linus merely replied that "If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols." As you may know, NDISWrapper implements Windows kernel API and then loads Windows binaries for a number of devices and runs them natively to avoid the cost and complication of emulation."
This discussion has been archived. No new comments can be posted.

Linus Denounces NDISWrapper, Denies It GPL Status

Comments Filter:
  • by arth1 (260657) on Wednesday March 05, 2008 @01:23PM (#22651722) Homepage Journal
    As long as there are no usable alternatives for many common chipsets, you won't win this one, Linus. People are then going to mod the kernel source so ndiswrapper appears kosher, and all you'll get is a +nd version for all major distributions, and fewer people using relatively clean source.
    • by corsec67 (627446) on Wednesday March 05, 2008 @01:28PM (#22651800) Homepage Journal
      I don't think that Linus is trying to say that people shouldn't be able to use NDISWrapper, just that if you use it, your kernel isn't a pure "gpl only" kernel.

      IIRC, that matters to people trying to report a bug: if your kernel isn't GPLONLY, then you will have a much harder time trying to get anyone to do anything about a crash. I think that is correct, since with NDISWrapper you just loaded a big blob of who-knows-what into the kernel, which can't help stability.

      Personally, I dislike wrappers like that, which I have to use for the flash plugin on my AMD64 computer. It allows companies to say "yeah, we support AMD64, just run our plugin in this wrapper", which fails quite often. Linux isn't only on i686, so why should we accept binary blobs of code for that processor?
      • by starm_ (573321) on Wednesday March 05, 2008 @02:56PM (#22653250)
        also if your kernel is not pure gpl IT IS ILLIGAL FOR YOU TO DISTRIBUTE IT. You are allowed to _use_ it like that but not distribute it. There are good reasons for that. Consider the following scenario:

        Intel develops new closed undocumented architecture with a 16 core cpu. Similarly to current network or video cards, you need a proprietary driver to enable the super accelerated multicoreness. In order to enable the use of the newer faster computers, Linux vendors do what they did with the other proprietary drivers, label these drivers as "not part of the kernel" put them in a wrapper and ship their version of Linux with the proprietary drivers which, for now, intel is giving away for free with the hardware. For a while everybody is happy and content. The new 16 cores chip becomes the new standard. There are even 32 core chips on the market and the 64 cores chips are soon to be released all of which rely on proprietary drivers.

        Suddenly, we hear that a large company, Lintelsoft, started by ex MS executives, makes a deal with Intel, a very lucrative deal for Intel, to license the drivers. Intel then says they won't give away the drivers anymore but you are free to buy the brand new Lintel Linux distribution. This distribution, which sells for 699$ a piece is all GPL'd except for those drivers that have become so standard that you need them in order for computers to run at a reasonable speed.

        Open source programmers scramble to write free replacement drivers that work on their Gnubian distribution but only manage to make drivers that can run the multi core cpu's at 1/20th the speed as Intel won't release documentation or specifications. Linux is rendered mostly useless except for the Lintel distro, (which is also available for free and with sourcecode as Lintelora excluding the proprietary driver sources of course) You can always plug in the Gnubian drivers in the free Lintelora project and get a working computer but it will only run at 1/20th the speed of the commercial 699$ a pop version and isn't powerful enough to run the new Mozilaurus browser smoothly.

        In this scenario, Lintelsoft would have effectively stolen Linux from the open source community, making profit with their source code and breaking all versions that are free.

        How can we let anyone close up an obviously derived work based on some wrappers?

        Notice that, even today I sometimes need to pay to get a fully working Linux from certain vendors, like Mandriva. (if i don't pay, 3d acceleration wont work.) I expect that kind of twisting of the law by commercial vendors. It surprises me that even Ubuntu is including proprietary video drivers nowadays.

        What's worst is that legally in order to maintain copyrights you need to make reasonable efforts at protecting those rights. Legally if the open source community waits until the binary drivers become problematic before acting. Proprietary vendors will be able to argue legitimately that closed source code has been allowed in the kernel by the open source community for a long time now: You are not legally allowed to suddenly change your mind about interpretations to suit current needs.
        • by corsec67 (627446) on Wednesday March 05, 2008 @03:16PM (#22653564) Homepage Journal
          I agree with you, but the problem is that several companies are already doing something quite similar, and it is called TiVoization [wikipedia.org]

          Fon, TiVo, and a few other companies distribute devices that run a linux kernel. To be compliant with GPLv2 they distribute their changes to the linux kernel, but the problem is that the hardware only runs a kernel that has been signed by the hardware manufacturer. That means that you can compile a new kernel using their changes, but can't load it onto the device.

          TCPA is something that Intel and Windows are trying to do that would do the same thing for general-purpose computers.

          That was one of the things that GPLv3 was trying to combat, but Linus doesn't want to use that license for the kernel, so there isn't much to prevent people from doing that in the future.
    • by betterunixthanunix (980855) on Wednesday March 05, 2008 @01:30PM (#22651840)
      Thank you. I am an open source advocate, but the driver for my network card is a half-assed approach that doesn't connect to any access points, or do much else that can be called "useful." ndiswrapper is a bandage that can be used until the kernel team and third party module developers can produce something usable. Trying to get rid of it will only restrict Linux adoption.
      • Re: (Score:3, Informative)

        by Knuckles (8964)
        Nobody's trying to get rid of it, read the numerous other posts correcting that assumption. This is just about the kernel losing GPLONLY status if you load ndiswrapper, which is important for debugging purposes and other things.
      • Re: (Score:3, Insightful)

        by muuh-gnu (894733)
        > I am an open source advocate

        Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?

        > but the driver for my network card

        Get another card. Reward manufacturers supporting Open Source by supporting them.

        > Trying to get rid of it will only restrict Linux adoption.

        If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac. The whole point of GNU and Linux was to make a working _free_ system, not just
        • Which other card? (Score:4, Insightful)

          by tepples (727027) <`tepples' `at' `gmail.com'> on Wednesday March 05, 2008 @05:19PM (#22655308) Homepage Journal

          Get another card. Reward manufacturers supporting Open Source by supporting them.
          Which card do you recommend in each format (classic PCI, PC Card, PCI Express, ExpressCard, chipset in desktop PC motherboard, chipset in laptop PC motherboard)? What new desktop and laptop computer models do you recommend that come with one of these cards?

          If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac. The whole point of GNU and Linux was to make a working _free_ system, not just to get you out of paying for a closed source one.
          Which notable personal computer to the general public uses coreboot [wikipedia.org] or some other free BIOS?
        • Re: (Score:3, Informative)

          by Cheapy (809643)
          Wow, it's an open source fundamentalist! Let's ban closed-open source marriages since they aren't pure and the most Holy of Programmers has spoken out against it.

        • Re: (Score:3, Insightful)

          by WK2 (1072560)
          I'm not the OP, but until recently, I used ndiswrapper to make my wireless card work (and might go back. the OSS driver is buggy.)

          >> I am an open source advocate

          > Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?

          No, as in I advocate open source, but am not a hardcore zealot. I have to work in the real world, and prefer function over ideals.

          >> but the driver for my network card

          > Get another card. Reward manufacturers supporting Open Source by supporting t
    • Re: (Score:3, Insightful)

      by nonsequitor (893813)
      My sentiments exactly. You can break ndiswrapper AFTER Linux fully supports every wireless chipset that Windows has drivers for. Until then, please learn to live in the real world. Or create a new symbol other than _GPLONLY that ndiswrapper can use instead. Breaking things that work for pedantic reasons is childish and punitive.
      • by A nonymous Coward (7548) * on Wednesday March 05, 2008 @02:13PM (#22652532)
        Or do the right thing in the first place and don't falsely label ndiswrapper as GPLONLY.
        • by nonsequitor (893813) on Wednesday March 05, 2008 @03:14PM (#22653540)
          It was a hack to make things work from what I understand, and I could be wrong. I agree it should register as a tainted kernel. However whoever 'fixed' the Linux kernel and broke ndiswrapper should have provided a mechanism which will continue to allow ndiswrapper to work, and show that the kernel is tainted. Breaking things and starting fights between development teams is the wrong way to go about it. Maybe that exists and the ndiswrapper team isn't using it, if that's the case then the ndiswrapper developers should change the wrapper to identify itself properly.
      • by richlv (778496) on Wednesday March 05, 2008 @02:46PM (#22653066)
        it's quite important to understand the issue, i think.
        it has been repeated in the thread several times already, but i'll try again (from my, outsider viewpoint, but i'd hope somewhat educated one :) ) - nobody is _breaking_ anything.

        short interpretation by me :
        kernel has a variable which denotes that it is gpl only - that is, the core and all loaded modules are gpled.
        this shows to people trying to debug things that they can debug everything and there are no binary modules that break shit in unexplainable ways.
        now, if a binary module is loaded, kernel notes in the variable that it is no more gpl only and breakages can be extremely hard to debug and impossible to fix. i guess you'll agree we don't want the kernel devs to waste time on such cases.

        now, ndiswrapper itself poses as gpl, thus it does not taint the kernel, but it then loads modules inside itself...

        so you get a tainted kernel that does not identify as one.

        and that is the only behaviour which is going to change.

        if i have misunderstood things miserably, correct me, thanks :)
    • Re: (Score:3, Insightful)

      by 0racle (667029)
      Since Linus' only concern is if his source is clean, I doubt he has a problem with that. The only 'winning' or 'loosing' he has to do are if his stuff is clean or not, if he is in violation of the GPL or not.
    • Re: (Score:3, Informative)

      by pembo13 (770295)
      The summary doesn't imply that he's trying to get ndiswrapper out. This is how rumours start.
    • Re: (Score:3, Informative)

      by WindSword (596780)
      Agree whole heartedly. If it weren't for NDIS, I wouldn't be typing this now. Pick another more deserving target, Linus.
    • Re: (Score:3, Informative)

      by dubious_1 (170533)
      Did you actually bother to read the entire thread? Linus is not anti-NDISwrapper. He is at worst ambivalent toward it. He is however unwilling to violate the will of the developer's who released their work under the GPL if they in fact feel that NDISwrapper is not legitimately a GPL module.
      There is legitimate cause to believe that NDISwrapper cannot itself be licensed under the GPL if it links against non-GPL code. Since the GPLONLY flag defines symbols that are only exported to modules licensed under t
      • Re: (Score:3, Insightful)

        by Fallingcow (213461)
        I can load the NDISWrapper module without loading any proprietary code. It wouldn't do much, but I could load it.

        If there are any GPL WinXP wireless drivers, I could use it to load those, and still be 100% GPL.

        This is basically saying that GPL code that allows users to load non-GPL drivers is not allowed, even though, as I understand it, the end user is supposed to be able to do ANYTHING THEY WANT with GPL code or binaries, and restrictions only come in when distributing. I should be able to use a GPL wra
  • by baadger (764884) on Wednesday March 05, 2008 @01:23PM (#22651728)

    Quite frankly, my position on this has always been that the GPLv2 explicitly covers _derived_ works only, and that very obviously a Windows
    driver isn't a derived work of the kernel. So as far as I'm concerned, ndiswrapper may be distasteful froma technical and support angle, but not against the license.

    -- Linus, in this post [lkml.org]
    • by baadger (764884) on Wednesday March 05, 2008 @01:28PM (#22651810)
      Oh and if that wasn't clear enough...

      IOW: I _personally_ don't think there are any license issues, but I do want to have the situation clear to people involved.
      -- Linus, in the same post.

      This is merely how Linus goes about discussion, do we really have to keep taking posts off of the LKML and blowing them all out of proportion?
      • No he didn't (Score:3, Informative)

        by schwaang (667808)
        The mail you referenced as a change of heart expresses the exact same view as this one from 29 Feb and others in that series (if you read the TFKernalTrapA you would have seen it):

        Excerpted from Linus mail of 29 Feb:

        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

    • by Chris Mattern (191822) on Wednesday March 05, 2008 @01:37PM (#22651968)
      No, Linus's position here is perfectly consistent. ndiswrapper itself can be covered by the GPL, but when you use ndiswrapper, your kernel is no longer GPLONLY, even though ndiswrapper is itself GPL, because ndiswrapper then loads and runs the Windows driver which is *not* GPL. The fact that ndiswrapper loads and runs non-GPL code doesn't make it non-GPL, but it certainly makes the kernel in which it is running not GPLONLY. If ndiswrapper loaded a GPL driver, the kernel would still be GPLONLY (which, in fact, it wouldn't be if ndiswrapper was not GPL). It's just that ndiswrapper's basic purpose means it'll never load a GPL driver.
  • by Anonymous Coward on Wednesday March 05, 2008 @01:29PM (#22651824)
    Before people flame Linus for whining, or trying to sabotage Linux users' ability to run drivers that they need, look at how OpenBSD handled this matter. They too rejected ndiswrapper, and ended up putting their energy towards reverse engineering wireless drivers instead. The results were positive, and in some cases the Linux folks ended up picking up their code too.

    And, when you write an open driver, you can maintain it more effectively. You can check it for security problems. You can fix its bugs. With ndiswrapper, you are putting a completely unknown blob of code inside your kernel and trusting it. This is never a good idea when other alternatives exist!

    So, use ndiswrapper if you feel that you absolutely must... But it shouldn't receive any official endorsement that would cause most users to be dependent on it. Kernel developers shouldn't think of the wireless driver issue as a "resolved" one. The ideal situation is to reverse engineer a free driver.
  • shim? (Score:3, Interesting)

    by PenguinX (18932) on Wednesday March 05, 2008 @01:30PM (#22651836) Homepage
    Isn't ndiswrapper just a shim, even if it's does very little translation? Businesses have been making proprietary to GPL shim's for ages, you know like Nvidia's driver. Why wouldn't the converse acceptable, or at least worthy of discussion?

    -b
  • by Drinking Bleach (975757) on Wednesday March 05, 2008 @01:30PM (#22651858)
    As ridiculous as it may sound, it's theoretically possible for a Windows driver to be licensed under the GPL. Thus, no legal troubles when loaded by ndiswrapper :)
  • by MarkusQ (450076) on Wednesday March 05, 2008 @01:32PM (#22651882) Journal

    Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless.

    There may be a valid argument for saying that ndiswrapper can't be GPL'd, but this isn't it. In what context would this sort of reasoning be considered sound?

    • Trying to claim that a cows somehow itself is a mammal even though it then eats things that aren't is stupid and pointless.
    • Trying to claim that 5 somehow itself is an integer even though it then can be multiplied by fractions that aren't is stupid and pointless.
    • Trying to claim that Apache somehow itself is open source even though it then serves content files that aren't is stupid and pointless.

    ...and so on. The claim may be valid but this argument certainly can't be used to establish it.

    --MarkusQ

  • by joshv (13017) on Wednesday March 05, 2008 @01:39PM (#22651998)
    So will GPL'd virtualization projects be similarly excluded? It seems to me they are the functional equivalent of NDISWrapper.
  • by tarm (583789) on Wednesday March 05, 2008 @01:40PM (#22652030)
    Summary is missing a HUGE portion of what actually happened. The discussion continued [gmane.org]. After the discussion, Linus applied a patch to ALLOW access to GPL_ONLY symbols (for those who care, it's git commit 9b37ccfc637be27d9a652fcedc35e6e782c3aa78).
  • by Englabenny (625607) <ulrik...sverdrup@@@gmail...com> on Wednesday March 05, 2008 @01:41PM (#22652044) Homepage
    Look at the second entry from the top in the changelog:

    http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.25-rc4 [kernel.org]

    The battle is over, the discussion is at end and Linus has already signed off a change to restore Ndiswrapper functionality.
  • by laing (303349) on Wednesday March 05, 2008 @01:48PM (#22652120)
    If ndiswrapper loads proprietary binary-only drivers and provides an API translation between Windows & Linux, then when ndiswrapper itself gets loaded as a kernel module, the kernel's "taint" flag should be set. The purpose of the taint flag is clear and it is quite applicable in this case. I don't think that Linus is saying the ndiswrapper authors cannot release their code under the GPL, what he's saying is that the run-time environment is not "pure GPL".
  • by Edgewize (262271) on Wednesday March 05, 2008 @01:50PM (#22652148)
    The stance isn't as crazy as the context-free summary makes it out to be. Linus isn't talking about the license for the ndiswrapper code. He's talking about access to kernel functions which have been marked as "GPLONLY". These are functions which are intentionally not exported to non-GPL code. Linus is saying that allowing ndiswrapper to use them is equivalent to allowing calls from non-GPL windows binary drivers. Which is true.

    The debate then is whether or not this should be considered a problem. The contributors who added many of the GPLONLY functions may have different opinions on the topic. Linus hints that the contributors for the USB functions would prefer a strict interpretation and deny ndiswrapper access to the GPLONLY kernel-level functions, because there is a perfectly good user-space API. But everyone involved agrees that ndiswrapper is will never live in user-space, because there's no programmer who would do it and it's a crazy idea anyway. Anyway you slice it, it's clear that ndiswrapper will get fixed one way or another, and nobody is accusing the ndiswrapper project of misusing the GPL.

    In summmary, it's a tempest in a teapot: someone accidentally broke ndiswrapper, kernel API discussion ensues, Slashdot posts inflammatory summary, life goes on.
  • bullshit (Score:3, Informative)

    by nguy (1207026) on Wednesday March 05, 2008 @01:54PM (#22652210)
    The ndiswrapper developers can release their code under any license they like, including the GPL; Linus has nothing to say about that. Furthermore, as long as Linux is under the GPL, Linus has no say over what I link into my kernel. If I want to link code under non-GPL compatible licenses into my kernel, that's my good right, under the GPL.

    Linus possibly has a say over whether distributors can simultaneously distribute the Linux kernel and ndiswrapper as pre-packaged binaries. But even there, I don't see a problem: ndiswrapper itself is under the GPL and complies with the GPL. The fact that it allows end users to link code under non-GPL compliant licenses into the kernel doesn't change that.

    While I think it would be nice if we didn't have to use ndiswrapper, and while one can argue either way about the desirability of its existence, now that it exists, Linus needs to honor the letter of the GPL and not try to redefine the terms after the fact. If he wants to, he can always relicense his code under different licenses in the future.
  • by ink (4325) * on Wednesday March 05, 2008 @01:55PM (#22652234) Homepage
    The only time GPLONLY is used is when submitting kernel crashes. Linus (and other developers) doesn't want to get backtraces for code that cannot be debugged, because it's in a Windows-only blob. You can still use ndiswrapper, just like you can use the Nvidia drivers -- the only caveat being that you cannot send a kernel hacker a dump.
    • Re: (Score:3, Insightful)

      by squiggleslash (241428)

      Not exactly, though you're correct in suggesting this is about code and flags in the kernel code, not about copyright law.

      The kernel has a number of symbols that are only accessible to modules that are GPL'd. The USB stack, for example, has a whole suite of symbols marked as "GPLONLY". These symbols provide access to functions provided by that stack. Unless NDISWrapper is identified as GPLONLY by the kernel, it cannot access those symbols. That's why the original patch "broke" NDISWrapper - it wasn't tha

  • by KillerBob (217953) on Wednesday March 05, 2008 @01:57PM (#22652260)
    we learn that in spite of his contributions to the open source community, Linus does not have the right to deny GPL status to anything. (yeah yeah, I know, it's a misleading headine... this *is* Slashdot after all) It's a software license. If the software developpers decide to release under the GPL or LGPL, then it's GPL software. Period. Whether or not the software is a shim for a binary blob that itself may or may not be proprietary, like NDISWrapper, is irrelevant. NDISWrapper, itself, is *not* closed source.

    It's kinda like the Quake III engine. That's been released as open source, and there's an awful lot of games out there that make use of it. But it still relies on a binary blob that is itself rarely released as free. That doesn't make the engine itself any less free/open.
  • by mlwmohawk (801821) on Wednesday March 05, 2008 @02:56PM (#22653260)
    At the core of this issue is the GPL definition of a derivative work.

    Do not flame me for what I am about to write as it is my understanding of RMS' guidelines, if you have a problem with it, take it up with him.

    To clarify what is and what is not a derivative work, the GPL and its supporting documents claim that a GPL work is not how self contained as it may seem i.e. shared libraries or loadable modules, but whether or not it inhabits the "process space" of the GPL work.

    When a non-GPL module is loaded into the process space of a GPL application, it violates the GPL license of the application. This is why NDIS wrapper violates the GPL because its job is to load non-GPL code into the process space of the kernel, thus tainting it.

    Do I agree? I'm not sure as I can see both sides of the argument. One side is that the module is self contained and isolated. The other side is that one of the purposes of the GPL is to protect the work of the people who contribute frm being unfairly used. It can be argued that the NIC card vendors who's drivers are enabled by NDISWrapper are unfairly enriched by the work of GPL developers in that their proprietary hardware is supported on a free platform without themselves being free.
  • It MIGHT be GPL. (Score:3, Interesting)

    by SharpFang (651121) on Wednesday March 05, 2008 @03:00PM (#22653330) Homepage Journal
    A piece of software may not be GPL if it -relies- on non-GPL code. Not if it -optionally uses- it.

    Say, I release a game which requires DirectX, links against the proprietary library, depends on it. It can't be GPL. But if I make the game run on both DirectX and SDL, it's enough to make it GPL. It's not crippled by lack of DirectX, it's just a user's choice, a preference to use it.

    This way NDISWrapper just -could- be GPL if only someone writes GPL counterparts of the modules it uses. It would mean then, that it's a generic module wrapper which can load a variety of modules, GPL or not, and it's up to the user to feed it the restricted ones in place of the free ones. It may load any -generic- modules, but it should have no provisions towards any specific restricted modules without having an equivalent free part.
  • Good (Score:3, Insightful)

    by PingXao (153057) on Wednesday March 05, 2008 @03:08PM (#22653442)
    I've said it before and I'll keep on saying it: ndiswrapper is evil. The biggest obstacle right now to greater Linux usage, IMO, is the lack of wireless chipset drivers. ndiswrapper is a crutch, not a solution. Intel may have provided enough datasheets to enable writing wireless drivers for their chipsets, but Broadcomm is the 800 lb. gorilla in the room.

    "Dude, just like load it with ndiswrapper and move on with working wifi!"

    That attitude, I maintin, is actually harmful in the long run.
  • by nurb432 (527695) on Wednesday March 05, 2008 @03:40PM (#22653912) Homepage Journal
    With out it, many of us would be screwed for drivers.

    Who really cares if its bla bla bla compliant?
  • First there is a lot of hardware that don't have Linux native drivers, mostly wireless network cards and Winmodems. NDISWrapper allows people to use Windows drivers under Linux for when there isn't a native Linux driver available for Linux.

    That is the Achilles heel of Linux, lack of third party driver support. Heck that's the Achilles Heel of any Non-Windows operating system be it OS/2, BeOS, AmigaOS, even Mac OSX. One OS, ReactOS, is trying to implement Windows' WDM driver model in GPLed software so that ReactOS can use Windows drivers. I would like to see Linux have the ability to use Windows drivers via some GPLed software, so Linus can borrow that from ReactOS, or write it from scratch, or maybe the WINE team can make a Linux module that loads Windows drivers for Linux that uses the WINE libraries.

    I have myself gone through several different wireless cards to get a Linux desktop working and eventually I gave up because I couldn't find a Linux native driver that wasn't flaky or lost the connection, and the only success I had was with NDISWrapper, but as soon as the Linux kernel is updated it breaks NDISWrapper forcing me to recompile the code and reinstall the Windows drivers.

    In fact, I have a Linux desktop near my wireless router that uses a CAT5 cable to hook into it and then use VNC from a Windows desktop in another part of the house to log into the Linux system that way. It would be nice if I was able to get good wireless networking support from a Linux native driver without losing the connection or going flaky on me. But I suppose I'll always have a VMWare Virtual Machine to use as well if I wanted to run Linux from any part of my house and not just where the router is located.
  • by hcmtnbiker (925661) on Wednesday March 05, 2008 @06:04PM (#22655916)
    Since ndiswrapper taints itself when it loads a proprietary NDIS module

    Can someone explain to me how creating a computability layer for a proprietary model inherently violates GPL? Linus is trying to claim that loading the Windows Driver violates GPL. But I really fail to see how, ndiswrapper is a computability layer, and itself GPL'd, the windows driver is not loaded into the kernel like other modules it is sandboxed by ndiswrapper. It edges towards that gray area of the GPL, but itself doesn't violate it.
  • Thank god for GPL (Score:3, Insightful)

    by pclminion (145572) on Wednesday March 05, 2008 @06:09PM (#22655978)
    Thank God the kernel is GPL. I can go in there and remove all this stupid GPLONLY garbage.

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.

Working...