Slashdot Mirror


Linus Denounces NDISWrapper, Denies It GPL Status

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."

15 of 457 comments (clear)

  1. Linus has already changed his mind by baadger · · Score: 5, Informative

    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
    1. Re:Linus has already changed his mind by Chris+Mattern · · Score: 5, Informative

      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.

    2. Re:Linus has already changed his mind by SirTalon42 · · Score: 4, Informative

      Linus isn't saying you can't use ndiswarapper. What'll happen, though, is when you report a bug they'll see your kernel has been tainted by a random binary blob they can't touch, and your bug report will be much less useful to them and it'll probably be marked as being much lower priority unless it can be confirmed that the binary blob isn't causing the problems (i.e. re-create the problem without the blob, either by not loading the module or from another machine without the module to begin with).

      Again, no ones complaining that you're using it to load non-GPL code.

    3. Re:Linus has already changed his mind by xivulon · · Score: 3, Informative

      To clarify even further:

      * Is ndiswrapper GPL? Yes
      * Can ndiswrapper use GPLONLY code? Yes
      * Can ndiswrapper "pass" GPLONLY code (export their symbols) to non-GPL modules? NO
      * Can ndiswrapper "pass" GPL code without GPLONLY directive to non-GPL modules? YES

      The third point is the one that was raised here and that needs to be addressed by either relaxing the GPLONLY directive or rewriting the code.

  2. Re:You can't win this one, Linus by betterunixthanunix · · Score: 3, Informative

    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.

    --
    Palm trees and 8
  3. Summary completely mistaken by tarm · · Score: 5, Informative

    Summary is missing a HUGE portion of what actually happened. The discussion continued. After the discussion, Linus applied a patch to ALLOW access to GPL_ONLY symbols (for those who care, it's git commit 9b37ccfc637be27d9a652fcedc35e6e782c3aa78).

  4. It's fixed in 2.6.24-rc4 by Englabenny · · Score: 5, Informative

    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

    The battle is over, the discussion is at end and Linus has already signed off a change to restore Ndiswrapper functionality.

  5. for those who lack understanding... by Edgewize · · Score: 5, Informative

    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.

  6. Re:Linus making friends fast by Achromatic1978 · · Score: 3, Informative

    but it is his tree so if he says it is not GPL compatible then it's not GPL compatible

    HUH??

    No, the wording of the license and its interpretation by legally qualified people determines whether or not something is GPL compatible, not the whims and say-so of a person, be it Linus, RMS, or whomsoever.

  7. Re:You can't win this one, Linus by WindSword · · Score: 3, Informative

    Agree whole heartedly. If it weren't for NDIS, I wouldn't be typing this now. Pick another more deserving target, Linus.

  8. Re:shim? by Omnifarious · · Score: 3, Informative

    The nVidia driver is also not considered GPLONLY. Your kernel is considered 'tainted' if you use it. You will get no help or support from the kernel people if you have a kernel problem when your kernel is tainted.

    Linus wants ndiswrapper to be in the same class. And he's right to. Maybe it's GPL, but it's whole purpose is to load stuff that isn't right into the kernel.

  9. Re:Try understanding the issue. by FishWithAHammer · · Score: 3, Informative

    NDIS wrapper has never been a great idea. It puts you at the mercy of Microsoft bugs and malice all for the benefit of a $30 network card. The kind of card that needs NDIS wrapper is usually worst of class and should be shunned. It's brain dead much like a winmodem and the "firmware" game is intentional. The card maker wants to be Windows only so don't buy it. Sooner or later hardware vendors will have to come around.

    That's a little hard on just about any laptop with an AMD processor. Intel boards have Centrino, which works under Linux without trouble. AMD-based laptops...not so much.

    --
    "You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
  10. Re:You can't win this one, Linus by richlv · · Score: 5, Informative

    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 :)

    --
    Rich
  11. Re:You can't win this one, Linus by dubious_1 · · Score: 3, Informative

    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 the GPL, this caused a problem. Linus was requiring that the owner of those symbols agree to NDISwrapper using them ( and preferably having them not defined as GPLONLY for consistency ). As the principal kernel god, he was right in flagging this problem.
    Of course he and many others in the Linux community would prefer that linux native drivers existed for these devices, but anyone who has spent any time reading his comments would agree that Linus is a pragmatist ( he is an engineer ), not an idealist. He does have an obligation to enforce the license that all of the kernel developers are releasing their work under.
    By the way, the end of the discussion seems to be Linus agreeing to roll back the change that broke the NDISwrapper. The hope is that if the change had been made intentionally to break NDISWrapper, then the submitter will resubmit the change and they discuss the reasons.

  12. Re:You can't win this one, Linus by F452 · · Score: 3, Informative

    I was looking in to this recently and found lots of info at:

    http://www.fsf.org/resources/hw/net/wireless/cards.html