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

Linus has already changed his mind

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]

Re:Linus has already changed his mind

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?

Re:Linus has already changed his mind

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.

Re:Linus has already changed his mind

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.

Look at OpenBSD for inspiration

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.

It can load GPL-licensed Windows drivers

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

Re:It can load GPL-licensed Windows drivers

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.

Re:It can load GPL-licensed Windows drivers

If a Windows driver was available under the GPL, it would certainly be ported in no time to GNU/Linux, defeating the need of ndiswrapper.

Summary completely mistaken

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

It's fixed in 2.6.24-rc4

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.

for those who lack understanding...

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.

Re:You can't win this one, Linus

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?

Re:You can't win this one, Linus

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.

Re:You can't win this one, Linus

Or do the right thing in the first place and don't falsely label ndiswrapper as GPLONLY.

Re:You can't win this one, Linus

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.

Re:You can't win this one, Linus

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:You can't win this one, Linus

I think you should know that you're engaging in the same kind of ideological wordmongering you accuse the other side of.

Look, I'm a pragmatic open source user. I understand the ideology.I generally agree to it. But not because of its perceived social Rightness, but because it's a reliable source of Good Bits. Its ideology supports methodology which supports good stuff like working kernels.

Upthread, I chastised a Free Software hyperbolist for being unrealistic and ignoring the practical side. Now I'm going to do the same in the other direction here.

The taint flag is a disclaimer of warranty.

What it comes down to is:

If you use only this open source software, we the developers can troubleshoot it with you, because no matter where the bug lies, we can find it. But if you inject a piece of kernel code which is only known as a black box... all bets are off. At best, we might conceivably help you chase the problem down into this black box, at which point we can only shrug and walk away. But the very real worst-case scenario is that the closed-source module does things to unrelated parts of the kernel which simply cannot be traced because of their origin. The kernel is, after all, a single shared memory space running at a single common privilege level, so you're giving carte blanche to a piece of driver you can neither inspect or verify. And trying to debug that quagmire would be massively unproductive. Really, we'd rather not waste time which would be better spent working on the real open source code and solving problems we actually can solve. So, rather than make any promises in this situation, my NDISWrapping friend, we the kernel developers can only tell you "Y'all on your own, dog!"

(BTW, that's not a real quote from any kernel developer I know of. It's just intended to express one good functional reason for kernel taintedness.)

See, no hysteria, no missionary fervor, no revolutionary speeches or dialectical materialism or any of that. Just practical reasons based on a balance of costs and benefits.

Re:reductio time

the difference is in how the kernel project uses the "GPL only" flag versus actual legality.

It's perfectly legal for NDIS to be GPL because all of the code they provide is open. That's the legal standard. That the USER loads non-GPL modules at runtime is a known loophole.

Lots of other projects use GPL for the same thing... Console emulators, word processing programs that read binary .docs, and so on. As NDIS doesn't DISTRIBUTE the program WITH the windows drivers (they don't own that code) it's perfectly fine for their "emulator" to be GPL same as an emulator for a Nintendo NES system.

Linus Uses the flag for people like Nvidia who it's NOT OK to use the GPL for their drivers because they own and distribute the binary code AND the wrapper in the same package. It's not legal for them to claim to be GPL. But in this case NDIS is only liable for the part they distribute and the user is responsible for how the program is used on the system. The license is fine it's just Linus is assuming that a "license flag" will cover all the programming options (so they can deny support) when that's not the case.

Try understanding the issue.

NDIS wrapper might itself be GPL but a kernel that uses it is not because the kernel is monolithic. Linus is actually giving everyone what they want.

What is this about GPLONLY symbols? [kernel.org].

EXPORT_SYMBOL_GPL was added ... To clarify the ambiguous legal ground on which non-GPL (particularly proprietary) modules lie. [and] ... To allow choice for developers who wish, for their own reasons, to contribute code which cannot be used by proprietary modules. Just as a developer has the right to distribute code under a proprietary licence, so too may a developer distribute code under an anti-proprietary licence (i.e. strict GPL).

Loading a non GPL kernel module makes the whole kernel non GPL and hard to debug because it's a monolithic program. Check out the Linuxant controversy [wikipedia.org] of 2001.

Linus won't keep you from making and loading non free modules but he's not going to be responsible when changes break your module. If others would cooperate, this would not be an issue. The NDIS wrapper people will have to reimplement functions written by GPL strict coders. That kind of sucks for them but they can do it. If Linus were to piss off the GPL strict coders, NDIS wrapper still would not work because those coders would quit contributing. A project as large as the kernel demands give and take. GPLONLY was a nice compromise.

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.

Re:Try understanding the issue.

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.

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.) You see, I could have bought an orinoco gold ABG card for $99 back in the day, or a $10 clearance walmart G card, and spend $98 on more RAM instead. Guess which one I chose (And for several years now, the card has been working just fine). Ndiswrapper got me online with gentoo (I know, I love pounding my head against a brick wall, its fun!) Without it, I'd still be using windows all the time.

Saying "Don't buy cards that don't support linux" is all well and good until you realize how much money you are dumping into hardware when a small free program can make it work just fine.

I think there is a term that covers this... Ah yes. "Not cost effective."

Re:Linus making friends fast

I don't think Linus ever had any doubts about whether Bitkeeper was proprietary or not. He simply stated that it was the best tool for the job.

Here, he claims "well, go ahead and use it, but don't call it GPL code because it isn't. Oh, and if you use it, I'm not responsible".

Hope your boss can now breath more easily.

Re:Linus making friends fast

The demonstrated intent of the copyright holder does have some bearing on the interpretation of a license, however.

who owns the kernel?

"This is stupid, people are trying to release the code of the project to the community and the restrictive terms of the GPL is preventing them."

This would be different if it were purely their code, but it isn't. This isn't stand-alone code. What they created is a derivative work of the Linux kernel. They used code which they didn't write and they don't own. Your argument is that the people who actually wrote the original kernel code have no right to say how it and its derivative works are used. Legally, you are completely and totally wrong. Essentially, you are advocating an end to copyrights on computer code. That's fine, but it has nothing to do with the GPL.

Re:Linus making friends fast

> IMHO, the GPL is a BAD license precisely because it causes fights like this to break out with regularity.

I don't necessarily think it's a bad license, I just don't think it's a one-size-fits-all thing. When you bring together a group of intelligent, opinionated, and (in large part) socially awkward people, fights are going to break out. Now it's true that things like religion and licenses tend to act as amplifiers (thus why I don't buy the classic "people will kill each other anyway" argument about religion) but I think this is just a pretty isolated case of Linus having another tirade. Reportedly he's already backing off.

"Linking" is not a term of copyright

I think almost all of these types of problems come down to the fact that, for copyright law with respect to computer software, the most *sane* approach is that linking does not create a derivative work, and therefor license terms cannot be applied to other works which link to the licensed work. NOTE: I am not a lawyer, this is not a statement of fact regarding current law, this is a statement of personal opinion. In otherwords, my opinion is that, if my view of copyright were adopted, there would be no GPL, only the LGPL. That is to say, since the only difference between the GPL and LGPL is the linking clause, and since I do not believe copyright should extend to other linked works, the GPL 'decays' to become the same thing as the LGPL.

Let me state it this way: It is my understanding that copyright law, currently, has no notion of 'linking'. Copyright covers copying material, or creating derivative works (such as translations, modified versions, etc). I don't know the full definition of derived work (I've tried to research it before, and it appears to get a bit complicated), but it is my understanding that the basic principle of a derived work is that it contains all or part of the work from which it is derived. For example, a translation is a derived work because, while all the words may be literally different, being in a different language, the works still essentially contains all the ideas and expressions from the original work.

It's also my understanding that copyright does not govern what you can and cannot do with with copyrighted work, except to the extent that you cannot copy, distribute, or perform for other people, the copyrighted work or distribute derivatives without permission (I think you can create derivatives without permission, even, you just can't distribute/copy/perform that derivative). So, copyright doesn't give me the power to say you can't 'link' your work with mine, unless such 'linking' creates a derivative and you then subsequently distribute/copy/perform that derivative work (so even if a derivative is created on the on the end-user computer, which I believe is not the case, I don't think copyright law would prohibit that).

The thing about software which dynamically links other software is, the two software works are fundamentally almost completely separate works, if I understand dynamic linking correctly. They are distributed separately (or at least, *can be* distributed separately), they are loaded into memory separately, and the works are never really combined, even in computer memory, I believe. Is that not correct? My understanding of 'dynamic linking' is that the computer is running code in one segment of memory, and encounters an instructions which just causes it to jump to another part of memory and start executing what's there, and when finished executing the linked function, to return to the original memory location + 1. If that is, in fact, the case, then it's rather like a note in a book which says, "Go read such-and-such magazine article, then return to this page and continue reading". Even if my book makes *no sense* unless you read the article I put the note in for, my book is still not a derivative, because it contains no copy of the magazine article. (I mention that last part because I've read where Linus, and some other people, make the claim that the test for derivative work should be whether software can run without the linked software - I personally think that is an irrelevant fact, because where there is no copying, there can be no violation of copyright).

Anyhow, I just ultimately believe that all this stuff about restricting what symbols can and can't be used by non-GPL software is just a mess, and not reasonable. I think the idea that because one work links another work, that the author of the linked work gets some kind of control over the second work is not reasonable. Separate works should have separate copyrights which do not touch each other AT ALL.

Now, it's my understanding that all this linking stuff vis-a-vis the GPL has never