Linus Denounces NDISWrapper, Denies It GPL Status 457
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."
You can't win this one, Linus (Score:3, Insightful)
reductio time (Score:1, Insightful)
"Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless. If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols."
Someone explain how that is a different claim than the following:
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."
Re:You can't win this one, Linus (Score:5, Insightful)
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:Linus has already changed his mind (Score:5, Insightful)
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?
Look at OpenBSD for inspiration (Score:5, Insightful)
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 (Score:5, Insightful)
Re:You can't win this one, Linus (Score:3, Insightful)
Re:You can't win this one, Linus (Score:3, Insightful)
Doesn't make sense (Score:2, Insightful)
The GPL is a distribution license. NdisWrappers doesn't distribute any binary code that isn't licensed under the GPL, and the code is available. It's up to the end user to use their own binary drivers, and such use isn't covered under the GPLv2.
I see nothing that prohibits the distribution of NdisWrappers based on the GPLv2, regardless of what that code does when it executes on the users machine.
Re:reductio time (Score:3, Insightful)
Linus was a bit brusque about it but I do see his point. Of course if all the kernel symbols needed to make wireless drivers work are GPLONLY, then well, Linux has a bigger problem, doesn't it.
So what about GPL virtualization? (Score:3, Insightful)
Re:reductio time (Score:5, Insightful)
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.
I'll side with Linus on this one (Score:3, Insightful)
Try understanding the issue. (Score:5, Insightful)
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].
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:I think Linus wrong on this (Score:3, Insightful)
It's not a completely clear area of law. But, it seems wrong that using an interface exported by another piece of code (whether via a procedure call, a remote object invocation or just sending an appropriately formatted text message to a socket) creates a derivative work.
Re:It can load GPL-licensed Windows drivers (Score:5, Insightful)
Calm down, this is only about reporting bugs (Score:3, Insightful)
Re:Linus making friends fast (Score:4, Insightful)
Re:.... right .... (Score:4, Insightful)
Re:Linus has already changed his mind (Score:3, Insightful)
Er, this is
Re:Linus making friends fast (Score:5, Insightful)
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 (Score:3, Insightful)
Yeh, too bad he got a start with the Microsoft people and all the honesty they bring to the table.
/sarcasm (included because you sound like someone who will miss it otherwise)
Re:You can't win this one, Linus (Score:5, Insightful)
Re:You can't win this one, Linus (Score:4, Insightful)
I bought 2 wireless cards this way and both needed wrappers and I went back to an ethernet cable and gave up on it.
I remember 10 years ago I was begging people to tell me which motherboard to get for a specific distro and no one would say (multiple sites and boards).
Don't insult me I know it's my fault but I know more that the average user does, and so if I had trouble I know they will.
Re:You can't win this one, Linus (Score:3, Insightful)
Re:You can't win this one, Linus (Score:2, Insightful)
a) Motivate HW Vendors to publish documentation needed to write a stable, well performing Linux driver
b) Motivate HW Vendors to produce and maintain a proper Linux driver.
The reason kernel developers probably aren't supporting your card very well isn't because they are lazy, more likely they just don't have access to the required specs to support it properly.
The real solution is to buy hardware from companies that support open source. (Disclaimer: I work for a company that has specific groups that do nothing but maintain kernel drivers and board support for our chips)
Re:Linus making friends fast (Score:4, Insightful)
Re:You can't win this one, Linus (Score:3, Insightful)
Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?
> but the driver for my network card
Get another card. Reward manufacturers supporting Open Source by supporting them.
> Trying to get rid of it will only restrict Linux adoption.
If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac. The whole point of GNU and Linux was to make a working _free_ system, not just to get you out of paying for a closed source one.
If all "open source supporters" had your attitude, free software wouldnt have survived the 90s.
Re:Try understanding the issue. (Score:5, Insightful)
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 (Score:3, Insightful)
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.
Re:Linus has already changed his mind (Score:2, Insightful)
http://www.kernel.org/pub/linux/docs/lkml/#s1-19 [kernel.org]
Re:Try understanding the issue. (Score:2, Insightful)
Re:You can't win this one, Linus (Score:5, Insightful)
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:Linus making friends fast (Score:5, Insightful)
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.
who owns the kernel? (Score:5, Insightful)
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:Try understanding the issue. (Score:3, Insightful)
NDIS is an interface. All network cards under windows need a network card driver, and the later HAS to conform to NDIS. The manufacturer, however may have decided not to release the specs for their hardware, and thus there is no Linux or BSD drivers available. Hence, implementing NDIS means that drivers conforming to the NDIS spec may be used. Just like implementing the SCSI port interface would allow NT SCSI drivers to be easily used (this has been done by some amateur open source operating systems). There is no "Microsoft bugs and malice" involved in an interface specification and any bugs occuring would be solely the domain of either poor implementation of NDIS or by bugs explicitely in the vendor-provided network driver. You're a complete tool to suggest otherwise. There is no "firmware game", and these network cards aren't braindead - you are.
Linus, btw, has just said that a public kernel interface is "tained". I call bullshit.
Re:Linus making friends fast (Score:3, Insightful)
The problem is that it is not "their code". They claim that the "project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel." That means it is a derivative work of the kernel. That means that they don't own all the code themselves, and that they have to follow the license of the other code they are using. And Linus's interpretation of the GPL and kernel modules is a lot more permissive than what is probably legally correct.
Good (Score:3, Insightful)
"Dude, just like load it with ndiswrapper and move on with working wifi!"
That attitude, I maintin, is actually harmful in the long run.
Re:You can't win this one, Linus (Score:5, Insightful)
Re:You can't win this one, Linus (Score:4, Insightful)
Fon, TiVo, and a few other companies distribute devices that run a linux kernel. To be compliant with GPLv2 they distribute their changes to the linux kernel, but the problem is that the hardware only runs a kernel that has been signed by the hardware manufacturer. That means that you can compile a new kernel using their changes, but can't load it onto the device.
TCPA is something that Intel and Windows are trying to do that would do the same thing for general-purpose computers.
That was one of the things that GPLv3 was trying to combat, but Linus doesn't want to use that license for the kernel, so there isn't much to prevent people from doing that in the future.
Comment removed (Score:3, Insightful)
Re:Linus making friends fast (Score:4, Insightful)
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.)
Does it even matter? (Score:3, Insightful)
Who really cares if its bla bla bla compliant?
Re:Linus has already changed his mind (Score:3, Insightful)
It's not pedantic. It's avoiding a variable that could waste people's time. If the problem isn't the binary blob, remove it and recreate the bug. Problem solved. If you can only reproduce the bug when the blob is loaded... hmm... sounds like it's the blob.
Re:You can't win this one, Linus (Score:3, Insightful)
Logically it follows that ndiswrapper is a derived work, BUT the binary blobs its loads are not. I don't see how this is at all productive and it IS quibbling over pedantics. Whether or not its their right to be pedantic and counter-productive does not negate the fact that they just hurt linux IMHO.
Re:Linus making friends fast (Score:4, Insightful)
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.
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.
Re:You can't win this one, Linus (Score:2, Insightful)
Linux is gplonly but ndiswrapper is non-gplonly because it can load non-gpl binary modules? Then why Linux is gplonly when it can load non-gplonly wrapper which can load non-gpl modules? What if I write ndiswrapperwrapper which is gplonly and it loads non-gplonly ndiswrapper...
Don't take it seriously. I'm just having a little bit of fun here :)
Re:Linus making friends fast (Score:4, Insightful)
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.
Re:Linus making friends fast (Score:3, Insightful)
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.)
Re:Linus making friends fast (Score:3, Insightful)
Re:Linus making friends fast (Score:2, Insightful)
The thing to understand is that as soon as a GNU/Nut starts talking about "the spirit of the GPL", they are basically admitting that the GPL doesn't actually say what they want it to, and they're going into some zone of extra-legal fantasyland. The GPL is a legal license, nothing more, and it has no spirit
Linus understands full well that there's nothing in the GPL which permits developers to add special "GPLONLY" symbols based on their personal feelings. From a legal standpoint, either the linking is legal or it ain't; the flag has nothing to do with it. Nor does the GPLONLY flag do anything to actually enforce the GPL or prevent vendors from shipping NDIS-enabled distros -- its simply used for support issues among the kernel devs (as is their right).
So, its not really that the GPL is a bad license in itself, but the culture that has developed around it where everyone feels like they can play Pretend Lawyer and dictate "the spirit of the GPL" in whatever manner is available to them. This culture is pretty much directly the result of Richard Stallman playing a guru or moses figure where he inscrutably makes proclamations about "linking" and so on and has filtered down through Debian and the Linux Kernel and most other projects were people are too scared to piss off the ideologues doing the work. If the Free Software community were run by competent lawyers and not messiah complex figures, they wouldn't have any of these problems.
Re:Try understanding the issue. (Score:3, Insightful)
Which other card? (Score:4, Insightful)
Re:You can't win this one, Linus (Score:3, Insightful)
As for loading a non-gpl module, that makes your kernel "tainted", and generally kernel maintainers will not even accept a bug report for something that has to do with a "tainted kernel".
I didn't mean that the kernel maintainers would jump to fix the issue, but with a tainted kernel, like using the nvidia module, you generally can't submit kernel bug reports.
And, as you say, NDISWrapper is quite similar to the nvidia wrapper.
Re:You can't win this one, Linus (Score:5, Insightful)
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:
(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.
Thank god for GPL (Score:3, Insightful)
Re:You can't win this one, Linus (Score:3, Insightful)
If there are any GPL WinXP wireless drivers, I could use it to load those, and still be 100% GPL.
This is basically saying that GPL code that allows users to load non-GPL drivers is not allowed, even though, as I understand it, the end user is supposed to be able to do ANYTHING THEY WANT with GPL code or binaries, and restrictions only come in when distributing. I should be able to use a GPL wrapper to load non-GPL code with full access to the Kernel if I want to, and at any rate, that wrapper is still 100% GPL, when distributed or even loaded on its own.
Re:You can't win this one, Linus (Score:2, Insightful)
Perhaps a 99.9% free system is still better than a fully proprietary one.
Re:Linus making friends fast (Score:4, Insightful)
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.
"Linking" is not a term of copyright (Score:5, Insightful)
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
Re:You can't win this one, Linus (Score:3, Insightful)
If you allow NDISwrapper to be GPL, then any manufacturer can put a wrapper around proprietary code and stick it in the kernel. Graphics cards, modems, printer interfaces - a lot of hardware uses the processor to do some of the work and would like to keep that code secret if they could. Look at nVidia. So yes, it's pretty much a "virus" as far as the GPL is concerned.
Re:You can't win this one, Linus (Score:3, Insightful)
There is a major difference here. NDISwrapper loads code that runs in kernel space. Firmware loading loads firmware to a device which runs it separately. A bug being caused by buggy firmware in a peripheral can be handled. A bug being caused by a binary blob in kernel space can have potentially disasterous effects.
See the difference and why module tainting is a good idea? There's no point in debugging a kernel that has random binary blobs since there's no way of telling what they do.
Re:You can't win this one, Linus (Score:3, Insightful)
>> I am an open source advocate
> Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?
No, as in I advocate open source, but am not a hardcore zealot. I have to work in the real world, and prefer function over ideals.
>> but the driver for my network card
> Get another card. Reward manufacturers supporting Open Source by supporting them.
I thought I did. I researched as much as I was willing to for a small purchase, and discovered that the card they sell at the local Wal-mart used a Prism GT chipset, which was fully supported by an open source driver. After I actually tried to get the thing to work, I noticed that "fully supported" is not how I would have defined it. Because it is a USB card, it requires the special "islsm" driver, which is buggy, unmaintained, and doesn't work with recent kernel versions. Islsm is difficult to compile.
I totally agree with supporting manufacturers who release OSS linux drivers. Unfortunately, the information is hard to find, or at least was harder a few years ago. But it's been several years, and the card still works with ndiswrapper. I see little reason to buy another one.
>> Trying to get rid of it will only restrict Linux adoption.
>> If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac....
>> If all "open source supporters" had your attitude, free software wouldnt have survived the 90s.
Wow. That isn't even worth responding too. But what Cheaply said is worth repeating, "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."
Re:You can't win this one, Linus (Score:2, Insightful)
>Like in "Do as I say (use open source), but not as I do (use closed source drivers)"?
No, like in "Use open source to the best of my ability, surmounting its restrictions to said ability with non-OSS fix-it stuff, if I hafta." Pragmatism over purism generally wins the day.
>> but the driver for my network card
>Get another card. Reward manufacturers supporting Open Source by supporting them.
Because they're growing on trees, aren't they? Here's another platitude for ya: Scarcity breeds cowardice. Sheesh...
>> Trying to get rid of it will only restrict Linux adoption.
>If you have to use closed source to just connect your Linux box to a network, then just fuck it and stay with Windows or buy a Mac. The whole point of GNU and Linux was to make a working _free_ system, not just to get you out of paying for a closed source one.
>If all "open source supporters" had your attitude, free software wouldnt have survived the 90s.
There is some viable argument that the whole point of GNU and Linux was not merely to make a working free system, but simply to do something else. Ars Gratia Artis, and all that. And Ipso Facto, while I'm at it...
Fact is all open source supporters come in strange clusters and myriad forms of attitude, which, like the fabled melting pot of the New World as mere noble propagandized humanitarianism, see it as a practical recourse to inevitable future tensions wrought by those of different languages/skin/religion/yo-yo ability. So, to invoke the wisdom of Woody the Yodlin' Cowboy, "Play nice."
Re:You can't win this one, Linus (Score:3, Insightful)