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:
  • 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
  • .... right .... (Score:2, Interesting)

    by nbvb (32836) on Wednesday March 05, 2008 @01:31PM (#22651876) Journal
    And this is the year of the Linux desktop, right?

    I've been hearing that for 10+ years now, and this is a prime example of where the Linux folks miss the boat.

    Do you really think my parents give a rolling fig about GPL vs. non-GPL code, who's exporting who's symbols or any of that? They just want their damned wireless Internet to work... ... and that's why they have a Mac. Seriously - nice concept, the whole Linux thing, but it just isn't going to be for the masses. Sorry to tell you that.

    Time to re-arm and focus on the enterprise - you stand a shot there. But even there - it needs work. Stability, for one. A Red Hat box that is out of date the day we deploy it does nobody any good. A real patch management strategy would be nice.

    Binary compatibility for another. I can pick up an HP-UX PA-RISC 9 binary, drop it on an HP-UX 11.31 Itanium system and it _just runs_. Same holds true for Sun -- drop a SunOS 4 binary on a SunOS 5.10 (yes, that's Solaris 10) system, and it _just runs_.

    Once Linux can do that - without recompiling, without having to resolve mutually exclusive dependencies - you just might give enterprise Unix a run for the money. Oh, and you'll have to scale up to 128+ processors too. Again - HPUX and Solaris both do that fine.
  • 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 hedwards (940851) on Wednesday March 05, 2008 @01:38PM (#22651990)
    Not to start a holy war here, but this is just arrogance. Things like this make me not want to have anything to do with GPL software.

    I understand that it's not a good thing to have mysterious binary glomps everywhere and that it would be better to have proper drivers and such than to have to use these sorts of wrappers. But realistically the only way that most manufacturers and software outfits are going to take users of OSI sanctioned environments seriously is if we can show them the cash flow. Which is significantly easier if you can point to a contingent of their own customers that are already using their software or hardware.

    Is it really a ZOMG Linux users might be able to use a Windows driver situation? Or can people just set aside their own personal pettiness and realize that open source OSes typically have had to spend a lot of time and energy writing and maintaining drivers. Some companies aren't going to come around no matter how many installations there are. But it's rather hard to proselytize when an important bit of hardware doesn't have an appropriate driver. If most Windows drivers of a type can be made to work with an appropriate wrapper, that means that developers can focus on only rewriting the drivers which have bugs or aren't performing well. I'm sure the performance wouldn't be as good as it would've been with native drivers, but having the hardware available at all is better than none.

    Ultimately it does just come down to money, if your distro/OS of choice can show the manufacturer a meaningful amount of business at some point there's enough profit there that they're going to want to tap into it. At the end of the day you've got to choose, no cost or access to quality commercial software. Even if they don't do so actively, they're more likely to be mindful about not doing things that unnecessarily break wine compatibility similar problems.

    I may have missed the memo, but FreeBSD has had project evil for quite a while now, and I don't recall having seen any evidence that the OS is worse for having that option.
  • by jim.hansson (1181963) on Wednesday March 05, 2008 @01:39PM (#22651996) Homepage
    this is funny, most of the time I get the impression that Linus is NOT a "GPL natzi", but at times like this you could mistake him for RMS.
    but it is his tree so if he says it is not GPL compatible then it's not GPL compatible.
    for the record, I have to agree with Linus on this one (but thats me and who am i).
  • by baadger (764884) on Wednesday March 05, 2008 @01:40PM (#22652018)
    Amusing observation.

    I bet the number of GPL'd NDIS drivers for Windows can be counted on one toe. I myself started writing an NDIS 6 driver for a chipset that has no native Vista drivers (although the NDIS 5 XP driver works on Vista x86) but have recently lost interest, despite almost completing basic functionality, because I realised I will never be able to use it under Vista x64 due to the OS's draconian driver signing policy..which cannot be disabled.
  • by corychristison (951993) on Wednesday March 05, 2008 @01:53PM (#22652190)
    OpenBSD rejected NDISWrapper first, due to their "anti-binary blob" policy.

    That and Linus changed his mind shortly after this was posted to Kernel Trap. Read a few comments up.
  • by gbjbaanb (229885) on Wednesday March 05, 2008 @01:56PM (#22652248)
    This is the guy who criticised people who pointed out Bitkeeper was, erm.. less than optimal in the 'play nice' category and who wanted to keep it 'for pragmatic, non-religious' reasons.

    To quote the Register, [theregister.co.uk]

    In a post on the Real World Technologies discussion board appropriately titled "Hypocrisy the worst of human traits", Torvalds takes advantage of Tridgell's vow of silence on the matter. For the first third of his response, Torvalds gently tries to persuade us that ethics doesn't belong in the software business, taking a strictly utilitarian view. Or, as he puts it,

    "So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative." he writes.
    What a pity the people involved in Open Source give my boss another reason to distrust the community and all their projects.

  • 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.
  • Mod parent up (Score:-1, Interesting)

    by Anonymous Coward on Wednesday March 05, 2008 @02:11PM (#22652514)
    ...is what I would say if I were registered and had karma. Parent is the only post you need to read in this discussion. Ndiswrapper complies fully with the text and technicalities of the GPL, Linus's assertion notwithstanding.

    The real debate is why we still have the GPLONLY flag. It's clear that the developers intended it as a method to signal to modules which sections of the kernel code are just interfaces, and which are considered "part of the kernel" in terms of derived works, but that shouldn't start a technical arms race with module developers! In cases like this, such a restriction is less about technical enforcement of legal boundaries (of which ndiswrapper is on the correct side), and more about pushing Linus's or others' political ideologies.
  • by MenTaLguY (5483) on Wednesday March 05, 2008 @02:46PM (#22653052) Homepage
    The demonstrated intent of the copyright holder does have some bearing on the interpretation of a license, however.
  • 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.
  • by misleb (129952) on Wednesday March 05, 2008 @03:28PM (#22653756)

    As I understand it, Flash pretty much fails at 64bit on EVERY platform. Maybe not Macs (my knowledge of them is quite limited), but I definitely have memories of Windows Vista 64 having a hard time of it. Pretty much it's 32bit wrapper'd version or bust.


    32bit vs. 64bit has always been nearly completely transparent to the user on Macs (remember the G5 is 64bit). So it is possible to design a system where the differences are hidden. But of course a lot of that transparency is due to Apple having control over the hardware and drivers. It also helps that building and distributing multi-architecture binaries on the OS X is trivial. You can have one binary that works natively on ppc32, ppc64, x86, and x86_64 with just a couple options selected in Xcode. Or gcc flags, if you're building stuff on the commandline.

    -matthew

  • by Orion Blastar (457579) <orionblastar@@@gmail...com> on Wednesday March 05, 2008 @04:05PM (#22654276) Homepage Journal
    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 xtracto (837672) on Wednesday March 05, 2008 @05:04PM (#22655124) Journal
    Wireless cards have to be closed source to use US radio frequency spectrum. In many cases, merely the ability to change frequency or power via software will render these cards unuseable in a legal context.

    Hello, that is some interesting information, would you care to elaborate (some links or other citations would be nice). I am authentically interested in your claim as I have never heard about such thing.
  • by idontgno (624372) on Wednesday March 05, 2008 @05:24PM (#22655388) Journal

    How do I run this "GPL" solution on my Sparc-based Linux system? The card is PCI but the binary that gets loaded runs on Intel-only. So it's compatible hardware, and software that claims to be GPL, but the system is a doorstop.

    So, you're hosed. That has nothing to do with me. NDISWrapper works for me. You solve your own problem, in ways that don't try to deny me my workaround.

    NDISwrapper is not a bandage, it is a Typhoid Mary allowing proprietary software to infect the kernel.

    Oh, get over yourself. It's a workaround. It solves nothing but a user's immediate problem: using hardware with no native support.

    "Buy supported hardware" is not always an answer. Yes, it's the best solution, but sometimes you have no choice except either use what you've got the best you can (including ugly kluges like NDISWrapper), or use nothing at all... and that's never a solution.

    Yeah, there are numerous pragmatic limitations to crap like NDISWrapper. Non-GPL taint warnings are there for a reason: to remind you that you may chase a problem into the dank impenetrable thicket of the proprietary driver... at which point you're SOL. Likewise if you need features the NDIS driver doesn't support.

    But in a few cases, the choice is between doing something distasteful and doing nothing at all. And that is neither a valid choice or an absolutely necessary one as long as everyone involved is honest and aware of the limitations and compromises involved.

    And calling NDISWrapper "Happy happy GPL joy" isn't either honest or mindful of the very real issues. But hyperbolizing it as a disease vector isn't either.

  • by nuzak (959558) on Wednesday March 05, 2008 @05:52PM (#22655784) Journal
    > Its been portrayed as a quick fix so if your hardware doesnt work out of the box, just use NDISWrapper.

    If it doesn't work out of the box, I don't much care that it's superior. I'm tired of "learning how the system works" for the 1000th time. Not all toil is virtuous.
  • 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.
  • Great link! (Score:3, Interesting)

    by JSBiff (87824) on Wednesday March 05, 2008 @08:46PM (#22657866) Journal
    Hey,
          Thanks for the link to the discussion on Rosenlaw. That's a great link. I'm not sure I *completely* agree with Rosen - the one point where I think he might lose the argument is that statically-linked binaries are not derivatives. I understand where he's coming from - he's trying to find the simplest definition of derivative work.

          But the problem is, a statically linked binary *does* contain your original work in part or in whole. In my earlier post, I put forth a statement of principle that, where there is no copying, there can be no copyright infringement. I think most reasonable people can say that the converse of that holds as well - where there is copying (without permission), there is copyright infringement.

          Although, I suppose possibly what Rosen is getting at is that it would be possible for me to ship the original static library source code, and so fulfil the obligations of the GPL wrt providing access to the source code for the original work, and that my binary is not a derivative work. But, I think that still may be a weak argument.

          Man, I don't know. It does get rather complicated. I mean if I dynamically link, and distribute the GPL .so and source code in the same zip file, CD, or installer as my seperate program, does that make the zip file, CD, or installer a derivative work? I know Linus has talked about that issue before, which he refers to as 'mere aggregation', which I believe is a reference to the GPL which explicitely allows mere aggregation. Where do you draw the line between aggregation and derivation? Maybe Rosen's suggestion is the simplest way to resolve the question, but it makes the GPL very weak, as a result.

    But, we can't let the GPL be too strong, either. I really think these issues of loading proprietary drivers with GPL wrappers like NDISWrapper really expose the absurdity of the 'dynamic linking violates the GPL' idea, too.

FORTRAN is for pipe stress freaks and crystallography weenies.

Working...