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 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 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.
  • 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 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.sverdrupNO@SPAMgmail.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 pembo13 (770295) on Wednesday March 05, 2008 @01:49PM (#22652132) Homepage
    The summary doesn't imply that he's trying to get ndiswrapper out. This is how rumours start.
  • 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.
  • by SirTalon42 (751509) on Wednesday March 05, 2008 @01:53PM (#22652192)
    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.
  • 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.
  • Re:reductio time (Score:3, Informative)

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Wednesday March 05, 2008 @01:59PM (#22652312) Homepage Journal

    Trying to claim that Linux somehow itself is GPL'd even though it then loads programs that aren't is stupid and pointless. If it loads non-GPL programs, it shouldn't be able to use GPLONLY symbols.

    Userspace programs don't link against the kernel. Additionally, from http://www.kernel.org/pub/linux/kernel/COPYING [kernel.org]:

    NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it.
  • by Achromatic1978 (916097) <robert AT chromablue DOT net> on Wednesday March 05, 2008 @02:01PM (#22652346)

    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.

  • by WindSword (596780) on Wednesday March 05, 2008 @02:05PM (#22652402)
    Agree whole heartedly. If it weren't for NDIS, I wouldn't be typing this now. Pick another more deserving target, Linus.
  • by Kozar_The_Malignant (738483) on Wednesday March 05, 2008 @02:05PM (#22652414)
    I'm trying to care, but it's not working. A few thoughts do come to mind:
    • Ndiswrapper works
    • People use it, because it works
    • There really isn't an alternative
    • People are going to keep using it
    • Linus is not a lawyer, and he should quit trying to be one
  • by Knuckles (8964) <knuckles AT dantian DOT org> on Wednesday March 05, 2008 @02:06PM (#22652424)
    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:shim? (Score:4, Informative)

    by Omnifarious (11933) <eric-slashNO@SPAMomnifarious.org> on Wednesday March 05, 2008 @02:14PM (#22652548) Homepage Journal

    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.

  • Re:reductio time (Score:1, Informative)

    by Anonymous Coward on Wednesday March 05, 2008 @02:15PM (#22652572)
    Go to the source [kerneltrap.org] next time.

    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
    The argument isn't about whether or not NDISWrapper is GPLed, it's whether or not it should have access to the kernel functions marked for use by only by GPLed modules.
  • by WhyDoYouWantToKnow (1039964) on Wednesday March 05, 2008 @02:18PM (#22652626)
    From Mozdev - http://plugindoc.mozdev.org/faqs/index.html [mozdev.org]:

    How do I stop Mozilla Firefox from prompting me to install a plugin? (for Windows)

    Open about:config, and set plugin.default_plugin_disabled to false. Then delete the file named npnul32.dll from your Mozilla Firefox plugins folder. You may have to enable showing hidden files to do this.

    How do I stop Mozilla Firefox from prompting me to install a plugin? (for Linux)

    1. Open about:config, and set plugin.default_plugin_disabled to false.
    2. Delete the libnullplugin.so from your Mozilla Firefox plugins directory. You may have to do this as root if you do not have write access to your Mozilla Firefox installation from your user account.

  • by FishWithAHammer (957772) on Wednesday March 05, 2008 @02:35PM (#22652882)
    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.
  • 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 :)
  • by xivulon (957825) on Wednesday March 05, 2008 @02:49PM (#22653116)
    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.

  • by sconeu (64226) on Wednesday March 05, 2008 @02:51PM (#22653152) Homepage Journal
    Trolltech, however, can grant exceptions to certain licenses, although I don't know which clause permits them to do so.

    The fact that they own the copyright on the Qt code and can therefore license it however the hell they want permits them to do so.
  • by MbM (7065) on Wednesday March 05, 2008 @03:14PM (#22653542) Homepage

    Well, I for one think it is a great idea since the most popular card manufacturers could not be bothered for the longest time to make linux drivers (and a lot still don't.)
    Somewhat a flawed argument, since now that ndiswrapper exists there is no incentive to write a linux driver. I would have preferred ndiswrapper didn't exist, allowing linux developers to push for open drivers and specificiations.
  • by dubious_1 (170533) on Wednesday March 05, 2008 @03:53PM (#22654104) Homepage
    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.
  • by dgatwood (11270) on Wednesday March 05, 2008 @04:01PM (#22654208) Journal

    He's not denying access to it. The issue (from what I can tell) seems to be that he/others find the the NDISWrapper is not using the proper set of kernel functionality.

    Read what I read again. I didn't say he was denying access to the driver. I said he was using his right to allow binary linking but denying the developers of the NDISWrapper code that same right. Sorry, poor choice of wording on my part.

    This code is not giving binary-only drivers access to GPLONLY symbols. It is strictly providing an emulation layer that happens to require some of those symbols in order to work correctly. Those are two completely different things. About the only valid reason to complain would be if the NDISWrapper code didn't set the tainted flag. If it doesn't, that's a one line fix.

  • No he didn't (Score:3, Informative)

    by schwaang (667808) on Wednesday March 05, 2008 @04:16PM (#22654458)
    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 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.


    What's confusing to slashdotters about this whole shebang is that there are two separate issues going on.

    First, there is a technical/legal issue relating ndiswrapper's access to the Linux kernel (specifically, access to symbols marked GPLONLY). On this matter Linus is doing his job, which is to enforce existing policy for GPLONLY stuff. Workarounds had been discussed, including the possibility that the people who actually wrote the code (USB stuff mostly) agree to remove the GPLONLY restriction that *they* imposed. Linus is not opposed to the workarounds, but he won't brook discussion about bending enforcement of GPLONLY.

    Secondly, Linus' expressed personal opinion about ndiswrapper (whose only purpose is to load Windows code) is complete indifference. He simply doesn't agree that because users depend heavily on ndiswrapper, he should go out of his way to bend the GPLONLY policy or make other special efforts. And he's not alone in the kernel community. Which freaks out the users who are afraid they won't be able to keep using their wireless cards and whatnot.

    So people see these two issues fused together and think that Linus is killing off ndiswrapper by personal fiat.
  • by cheater512 (783349) <nick@nickstallman.net> on Wednesday March 05, 2008 @05:20PM (#22655332) Homepage
    NDISWrapper deals with Window's binary blob drivers.
    That, under anyone's definition, means nothing GPLed can touch them.

    NDISWrapper tried calling its self GPL while exposing all of Linux's GPLed interfaces to the binary blobs.
    A very straight forward violation.

    Personally I never liked NDISWrapper.
    I use Linux to get away from Windows. I dont want their drivers running on my system.

    Many people use it even when there are superior native drivers.
    Its been portrayed as a quick fix so if your hardware doesnt work out of the box, just use NDISWrapper.
  • by F452 (97091) on Wednesday March 05, 2008 @06:11PM (#22656000) Homepage
    I was looking in to this recently and found lots of info at:

    http://www.fsf.org/resources/hw/net/wireless/cards.html [fsf.org]
  • by baadger (764884) on Wednesday March 05, 2008 @06:43PM (#22656414)
    No I am afraid that is not correct. The situation is a lot more complex as of Vista SP1:

    http://thebackroomtech.wordpress.com/2007/11/05/howto-disabling-driver-signing-in-windows-vista-64-bit/ [wordpress.com]

    None of the workarounds you describe will work with x64 editions of Vista SP1, or for "boot drivers" in x86. I do plan to continue develop of the driver, but I doubt I will ever be able to get it signed using anything but the test certificate from MS. Still, will find out during testing...
  • by Cheapy (809643) on Wednesday March 05, 2008 @06:53PM (#22656536)
    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.

  • by mikiN (75494) on Wednesday March 05, 2008 @07:34PM (#22657052)
    Since "you" is ambiguous referring to an AC, I will post my $.02 worth of searching.

    FCC Rules on FOSS and Software-Defined Radio [softwarefreedom.org]
    Cognitive Radio Technologies and Software Defined Radios [gpo.gov]

    As far as I can gather the main problem is that part of the licensing requirements is that "security measures" that need to be in place to prevent use of the device outside the specifications for which it is licensed.
    With the boundary between driver software on the computer vs. firmware on the device shifting ever more away from the device, it becomes harder to implement these security measures.
  • by drinkypoo (153816) <martin.espinoza@gmail.com> on Wednesday March 05, 2008 @07:49PM (#22657236) Homepage Journal

    I don't know how you got marked all the way up to 5, but what you say has never been tested in court - which is the only thing that matters. It is NOT repeat NOT clear whether linking constitutes creation of a derivative work. Providing the source and headers may well prove to constitute a published specification, and the right to interoperate is generally protected by US law (there's even an exception to the DMCA restrictions on reverse engineering specifically for the purpose of interoperability.) So really, you are quite wrong about the GP advocating an end to software copyrights in their comment. No such thing was stated or implied.

    The question of whether any restrictions on linking are actually legal is a very real one.

  • by imtheguru (625011) on Wednesday March 05, 2008 @08:02PM (#22657390)
    http://linux.slashdot.org/comments.pl?sid=476560&cid=22656000
    by F452 (97091) Alter Relationship on 14:11 Wednesday 05 March 2008

    Cheers to F452 for this information.

Someday your prints will come. -- Kodak

Working...