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."
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.
-- Linus, in this post
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.
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 :)
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).
preview button, my computer does't have any preview button
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).
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.
the difference is in how the kernel project uses the "GPL only" flag versus actual legality.
.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.
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
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.
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.
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?.
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 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.
Try the other way around. The NDISWrapper folks are trying to GPL something that Linus doesn't believe merits it. They're the ones trying to add the restrictions, and Linus isn't having it.
Done with slashdot, done with nerds, getting a life.
Good thing desktop users are unlikely to install a new non-distro kernel between February 28th, when Linus posted that, and March 4th, when he looked more carefully at what ndiswrapper is doing and determined that it's not re-exporting functions to non-GPL code, but rather using them to implement an API that's not a derived work of the kernel. Linus saying something dumb on a Thursday afternoon which he corrects on a Tuesday shouldn't be news on Wednesday, especially as it's a discussion about a kernel that hasn't been released yet, won't be for a couple of weeks, and probably won't be provided by distributions for a couple of months.
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.
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.
"I think it would be a good idea!"
Gandhi, about Internet Security
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.
Need a Python, C++, Unix, Linux develop
Isn't it rather obvious? What happens if someone tries to GPL code that needs non-free libraries - or worse, contains code that has been copied or reverse engineered from another program without the author's consent, or that uses an incompatible license?
which is totally what she said
Agreed. This is precisely the reason why I regularly rail against the GPL as a license and think that all libraries should be under the LGPL. In effect, the kernel acts as a giant library. Any public interfaces to the kernel should be treated like a library and licensed appropriately, not under some idiotic license that doesn't allow linking non-GPLed code against it.
Indeed, this is doubly true for a plug-in API. There should not be restrictions for who can write code to a public specification, period. There are far too many people who say that the GPL should have this right and still decry Microsoft for their shady, intentionally non-GPL-compatible licenses. That is the height of hypocrisy.
More to the point, though, as long as something provides a public interface and uses only public interfaces, it is entirely the right of the author to decide how to license it, and if the author decides to license it under the GPL but provide a linking exception to allow closed source drivers to call it, that is the author's right. Linus himself said that he felt binary-only drivers should be allowed, so he took advantage of the right to provide a linking exception, and yet now he wants to deny it to others? What's wrong with this picture?
Heck, it wouldn't even be wrong in my book if it directly exported GPLONLY symbols as-is. The purpose of the GPL was supposed to be that non-open source can't directly call into GPLed code to avoid compatibility problems if the open source code changed. Since this code is providing a layer of indirection, if the kernel changes, it can become a compatibility shim. As such, even a direct export indirection layer would be in the true spirit of the GPL, IMHO. But this isn't even doing that. This is providing a translation layer from one API to another. This is providing an emulation of an entirely different API and uses GPLed symbols to do so. That is absolutely in the spirit of the GPL, as the whole thing is already a translation layer. This doesn't allow the closed source driver developers access to GPLONLY symbols. It's not a workaround to dodge the GPL. It's an enabling tool that makes the overall Linux user experience better, and if someone's interpretation of the GPL causes such a tool to be effectively banned, then it is the GPL that needs to be changed, not the tool.
IMHO, the GPL is a BAD license precisely because it causes fights like this to break out with regularity. Instead of providing the best service we can to the users of open source software (and thus promoting the power of open source over closed, proprietary solutions), we, the open source/free software community, end up fighting amongst ourselves over how to interpret a license written by Stallman out of spite for closed software vendors. Instead of supporting free software against proprietary solutions, we end up causing people to think of us as a bunch of loons who are dogmatic about an ideal no matter how much it hurts the users. That's not a good way to encourage adoption by anything but the most zealous free software extremists, and most of those folks already use Linux, so basically it isn't a good way to encourage adoption, period..
Remember, every time the GPL is used to impede progress, proprietary software wins.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The demonstrated intent of the copyright holder does have some bearing on the interpretation of a license, however.
DNA just wants to be free...
> 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.
Done with slashdot, done with nerds, getting a life.
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.
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.
As you point out "it is entirely the right of the author to decide how to license it" and "Linus himself said that he felt binary-only drivers should be allowed, so he took advantage of the right to provide a linking exception". That "linking" exception requires that a module properly declare whether its license is GPL or not. If not, then its access to the kernel is restricted; if it is, it is given access to most all the symbols - the GPLONLY symbols. This is for (a) compatibility, but also (b) stability. They didn't want binary drivers breaking the kernel.
From the sounds of it, they don't agree with the NDISWrapper guys (or whoever is complaining) that NDISWrapper deserves the ability to access the GPLONLY symbols. Perhaps the way NDISWrapper functions is breaks compatibility with the GPL - by loading non-GPL code . I don't know the whole story, but I think I would have to side with the Linux guys on this one. It's their "linking" exception, and you have to play by the rules.
Note: This is not a GPL issue with respect to the Linux kernel; if it's a GPL issue at all, it is with NDISWrapper not validly being able to use the GPL, and if that is the case, then they should not be allowed to access the GPLONLY symbols. The primary issue is a matter of playing by the rules the developers set - and that goes for GPL and non-GPL code alike, regardless of projects, commercialization, etc. (And no, I'm not claiming, implying, or otherwise stating the the Linux Kernel guys determine that for everyone. Look at the project authors and who has the right, the ability, to make such a rule. It'll change for every project.)
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
What Linus himself *has* said in the past was that he considers binary modules ok *if* those modules weren't developed specifically for Linux. Take nvidia as an example: they have a binary driver core (possibly developed for Windows, possibly developed just as a generic driver core) which has an open-source shim to adapt it to the Linux kernel's specific interfaces. NDISWrapper could be thought of similarly, as an open-source shim to adapt Windows drivers to Linux's specific interfaces. However, this doesn't mean that NDISWrapper itself can be licensed under the GPL (of course, it can be licensed under "GPL with linking exception"), which is not compatible with Linux's GPLONLY symbols. Heck, it wouldn't even be wrong in my book if it directly exported GPLONLY symbols as-is. Sorry, but your book isn't relevant here. (I assume by "it" you mean NDISWrapper.) You don't own the copyright on the kernel, so you don't get to decide. While this stuff may not be tested in court, seems like the copyright holders are in the right here. The purpose of the GPL was supposed to be that non-open source can't directly call into GPLed code to avoid compatibility problems if the open source code changed. No, the purpose of the GPL is to allow anyone to freely modify and redistribute source code, but to require that the source code remain open. The GPL is about idealism (with a bit of pragmatism mixed in); it has nothing to do with "compatibility problems." It's not a workaround to dodge the GPL. Oh, I agree, it's not. NDISWrapper is a great (temporary!) tool to fill a void until manufacturers get their act together or people have the time and motivation to reverse-engineer the relevant chipsets. Can it be licensed under the GPL? No, it can't. It does things anathema to the GPL's purpose (linking to code with an incompatible license). Can it be licensed under the "GPL with linking exception"? Sure. Is "GPL with linking exception" compatible with the Linux kernel's license for a derived work? No, it's not.
You're at the mercy of the copyright holders and the courts as to whether or not you're allowed to use NDISWrapper with Linux (and you are, it just can't use GPLONLY symbols!). Deal with it, or find some supported hardware or a different OS. Remember, every time the GPL is used to impede progress, proprietary software wins. You're implying that there's some sort of competition going on here. Your personal agenda for open source might be to rule the world, but that's not everyone's. And some people who do share your agenda would like to "win" without cutting corners and compromising on their ideals. Is that naive? Maybe. But just because you don't understand other people's motivations, it doesn't make them wrong.
Xfce: Lighter than some, heavier than others. Just right.
NDISWrapper is not a derived work of the Linux kernel. That is a gross misuse of the term "derived work". Using headers and linking against something does not make it a derived work. That was, IMHO, decided way back in the early 80s with Galoob v Nintendo, though no GPL linking case has gone far enough in court to test this, AFAIK.
You are correct that I can't take someone else's code and add a linking exception, but that's not what is being done here by any stretch of the imagination, and there are numerous cases where open source wrappers have been written as a border between proprietary and GPLed code. Again, to my knowledge, no cases about this have ever made it to court, in part because arguments that such linking is a GPL violation are relatively precarious, and in part because most companies that have found themselves getting threatened with a lawsuit have been small enough that they choose to settle out of court rather than risk a lengthy and expensive court battle.
More to the point, you can argue that the GPLONLY limitations were intended to disallow linking by code that is licensed as GPL with a linking exception, but then you would also have to disallow any code within the Linux kernel itself that calls those functions unless those pieces of code are also marked with the GPLONLY restriction. That makes the GPLONLY functions substantially less useful to the point of being nearly worthless.
NDISWrapper is a module that loads binaries specifically developed for Windows, so there you go.
Funny, I saw Stallman give a speech, and he basically said that he started hating proprietary software specifically when a printer failed to work with a new computer setup. Had the driver been open, he could have fixed it. Had the OS been open, he could have fixed it to be compatible. Neither was, so he couldn't. While the goals of the GPL may have drifted from that original purpose these days, compatibility was a very important part of the reason the Free Software movement was created in the first place, and I think it is important that the movement not lose touch with its roots.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Microsoft is saying "here are some specifications for a document format, and here is a vague 'promise'. You might be able to use these specifications, but if you do, we might sue you, but we won't tell you how we'll actually decide that, or what parts of the specification we think we could sue you over."
Linus is saying "here is an API for kernel modules, and here is the GNU GPL. You can use the whole specification if you place your code under a GPL-compatible license; otherwise you can use this, this, and this, but you cannot use this, this, or this. If that's not clear, ask us and we'll tell you whether we agree with what you're planning to do."
Can you see the difference? Because if you can't, then I suggest you take a deep breath, step back, suppress your dislike of the GPL for a moment, and think about it. You don't have to agree that Linus is being reasonable. All I'm asking is that you recognise that what Microsoft is doing is not the same as what Linus is doing, and therefore that people who approve of either activity but disapprove of the other are not being hypocrites.
(Lest you dismiss me as a mindless GPL fanboy, let me point out that when I've released software I've always made a point of choosing LGPL or MIT-style licenses for libraries, and in this instance I'm not at all convinced Linus is right. I just think the rhetoric needs toning down a bit. I'm sure you can argue against Linus' ideas without having to fling around blanket accusations of hypocrisy.)
People on this forum are not understanding what is being discussed. There are two issues -- licensing and Kernel tainting, and these actually are separate issues. Licensing: GPL only covers derived works. Making code that interfaces from a GPL'd software to a binary that is a windows derivative IS legal. Linus specifically made this point in his posts, and several times. Tainting: Tainting has two purposes... First, it tells the Kernel that a module is suspect. If someone reports a Kernel bug on a Tainted Kernel, then the Kernel maintainers have no visibility into the binary that may or may not causing an issue. Kernel maintainers then require removal of whatever is causing the tainting as a first step in tracking down a bug. The second purpose of tainting is to indicate to the outside world that if they used certain calls in a module, that that module would definitely indicate that it was a "derived work." Currently NDISWrapper taints the Kernel by itself if it loads a proprietary driver. All agree that this tainting is necessary -- especially for the first purpose. Linus wanted to know which symbols that NDISWrapper was using so that he could find out if those symbols really needed to be GPL_ONLY symbols. Additionally, there seemed to be some confusion if NDISWrapper was simply acting as a pass-thru vehicle for avoidance of the GPL -- and we found through the posts, and through the lists of exports, that it clearly was not. There was also discussion on if the exports could be removed from NDISWrapper or the exports could be made non-GPL_ONLY -- presumably, so that it didn't /have/ to do the funky chicken with tainting, or to make more people happy & reduce the chance of NDISWrapper being bullied again...
I think that it's a horribly misunderstood license. While the concepts themselves are easy to understand, when you get into the nitty gritty details of interoperating with other software, things get sticky really quickly.
BSD is so much easier, but you run the risk of someone doing more with your code (and getting paid for it) than you did, without getting anything out of it. Personally, that doesn't bother me all that much.
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