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
And as you may know, Linux loads NDISWrapper.
"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."
That would be the Grand Polycarp Lodge, an ancient source of hermetic wisdom.
If you have to ask, just keep using Windows.
Your suffering will be minimized.
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.
Isn't ndiswrapper just a shim, even if it's does very little translation? Businesses have been making proprietary to GPL shim's for ages, you know like Nvidia's driver. Why wouldn't the converse acceptable, or at least worthy of discussion?
-b
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 :)
And this is the year of the Linux desktop, right?
... and that's why they have a Mac. Seriously - nice concept, the whole Linux thing, but it just isn't going to be for the masses. Sorry to tell you that.
I've been hearing that for 10+ years now, and this is a prime example of where the Linux folks miss the boat.
Do you really think my parents give a rolling fig about GPL vs. non-GPL code, who's exporting who's symbols or any of that? They just want their damned wireless Internet to work...
Time to re-arm and focus on the enterprise - you stand a shot there. But even there - it needs work. Stability, for one. A Red Hat box that is out of date the day we deploy it does nobody any good. A real patch management strategy would be nice.
Binary compatibility for another. I can pick up an HP-UX PA-RISC 9 binary, drop it on an HP-UX 11.31 Itanium system and it _just runs_. Same holds true for Sun -- drop a SunOS 4 binary on a SunOS 5.10 (yes, that's Solaris 10) system, and it _just runs_.
Once Linux can do that - without recompiling, without having to resolve mutually exclusive dependencies - you just might give enterprise Unix a run for the money. Oh, and you'll have to scale up to 128+ processors too. Again - HPUX and Solaris both do that fine.
There may be a valid argument for saying that ndiswrapper can't be GPL'd, but this isn't it. In what context would this sort of reasoning be considered sound?
...and so on. The claim may be valid but this argument certainly can't be used to establish it.
--MarkusQ
I'm sorry, Linus. But that argument makes no sense.
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.
If you need web hosting, you could do worse than here
.. and it doesn't export GPLONLY modules to them.How stupid do you have to be to not understand that?
In other words: the next person who can't even be bothered to tell what symbols are involved and why they haven't asked whether those symbols could instead be relaxed, automaticaly will go into my "flamers" filter, and just stay there. Then you can complain as much as you like, and I'll never see it.Totally OT but I've had to rebuild a few kernels to get the ACX-100 (texas instruments) wireless going.
C|N>K
Not to start a holy war here, but this is just arrogance. Things like this make me not want to have anything to do with GPL software.
I understand that it's not a good thing to have mysterious binary glomps everywhere and that it would be better to have proper drivers and such than to have to use these sorts of wrappers. But realistically the only way that most manufacturers and software outfits are going to take users of OSI sanctioned environments seriously is if we can show them the cash flow. Which is significantly easier if you can point to a contingent of their own customers that are already using their software or hardware.
Is it really a ZOMG Linux users might be able to use a Windows driver situation? Or can people just set aside their own personal pettiness and realize that open source OSes typically have had to spend a lot of time and energy writing and maintaining drivers. Some companies aren't going to come around no matter how many installations there are. But it's rather hard to proselytize when an important bit of hardware doesn't have an appropriate driver. If most Windows drivers of a type can be made to work with an appropriate wrapper, that means that developers can focus on only rewriting the drivers which have bugs or aren't performing well. I'm sure the performance wouldn't be as good as it would've been with native drivers, but having the hardware available at all is better than none.
Ultimately it does just come down to money, if your distro/OS of choice can show the manufacturer a meaningful amount of business at some point there's enough profit there that they're going to want to tap into it. At the end of the day you've got to choose, no cost or access to quality commercial software. Even if they don't do so actively, they're more likely to be mindful about not doing things that unnecessarily break wine compatibility similar problems.
I may have missed the memo, but FreeBSD has had project evil for quite a while now, and I don't recall having seen any evidence that the OS is worse for having that option.
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
So will GPL'd virtualization projects be similarly excluded? It seems to me they are the functional equivalent of NDISWrapper.
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.
Linux has never struck me as practical, from a user point of view and even less as a business model. Yet I cannot help but notice that every year adoption continues to grow and every year more Linux based software is produced. Obviously I am missing something. Also, I can't see announcing software is compliant with GPL, or any other standard, if the governing body has not certified it so, so once again I am missing something. But that is just me.
If ndiswrapper loads proprietary binary-only drivers and provides an API translation between Windows & Linux, then when ndiswrapper itself gets loaded as a kernel module, the kernel's "taint" flag should be set. The purpose of the taint flag is clear and it is quite applicable in this case. I don't think that Linus is saying the ndiswrapper authors cannot release their code under the GPL, what he's saying is that the run-time environment is not "pure GPL".
Well, yeah basically. It's been that way for years, mainly for legal reasons.
C|N>K
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.
I'm not even sure that linking statically creates a derivative work, as much as it creates a compilation. It's more similar to including a poem in a book of poems than it is to changing the poem itself. A derivative work involves changing or recasting the original -- static linking doesn't do this. The reason that you can't (w/o permission) distribute a program with an embedded library is more basic -- you're violating the distribution right of the library (and, presumably, the duplication right also.)
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.
OpenBSD rejected NDISWrapper first, due to their "anti-binary blob" policy.
That and Linus changed his mind shortly after this was posted to Kernel Trap. Read a few comments up.
The ndiswrapper developers can release their code under any license they like, including the GPL; Linus has nothing to say about that. Furthermore, as long as Linux is under the GPL, Linus has no say over what I link into my kernel. If I want to link code under non-GPL compatible licenses into my kernel, that's my good right, under the GPL.
Linus possibly has a say over whether distributors can simultaneously distribute the Linux kernel and ndiswrapper as pre-packaged binaries. But even there, I don't see a problem: ndiswrapper itself is under the GPL and complies with the GPL. The fact that it allows end users to link code under non-GPL compliant licenses into the kernel doesn't change that.
While I think it would be nice if we didn't have to use ndiswrapper, and while one can argue either way about the desirability of its existence, now that it exists, Linus needs to honor the letter of the GPL and not try to redefine the terms after the fact. If he wants to, he can always relicense his code under different licenses in the future.
The only time GPLONLY is used is when submitting kernel crashes. Linus (and other developers) doesn't want to get backtraces for code that cannot be debugged, because it's in a Windows-only blob. You can still use ndiswrapper, just like you can use the Nvidia drivers -- the only caveat being that you cannot send a kernel hacker a dump.
The wheel is turning, but the hamster is dead.
To quote the Register, In a post on the Real World Technologies discussion board appropriately titled "Hypocrisy the worst of human traits", Torvalds takes advantage of Tridgell's vow of silence on the matter. For the first third of his response, Torvalds gently tries to persuade us that ethics doesn't belong in the software business, taking a strictly utilitarian view. Or, as he puts it,
"So I think open source tends to become technically better over time (but it does take time), but I don't think it's a moral imperative." he writes. What a pity the people involved in Open Source give my boss another reason to distrust the community and all their projects.
we learn that in spite of his contributions to the open source community, Linus does not have the right to deny GPL status to anything. (yeah yeah, I know, it's a misleading headine... this *is* Slashdot after all) It's a software license. If the software developpers decide to release under the GPL or LGPL, then it's GPL software. Period. Whether or not the software is a shim for a binary blob that itself may or may not be proprietary, like NDISWrapper, is irrelevant. NDISWrapper, itself, is *not* closed source.
It's kinda like the Quake III engine. That's been released as open source, and there's an awful lot of games out there that make use of it. But it still relies on a binary blob that is itself rarely released as free. That doesn't make the engine itself any less free/open.
If you believe everything you read, you'd better not read. - Japanese proverb
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.
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.
The rest of your post may have some validity but this part is just FUD. Unless you've made a distro then licensing doesn't even come into play. On the contrary if your business built a system based around Microsoft java virtual machine, when Microsoft got caught stealing code then your employees would be unable to use it.
IranAir Flight 655 never forget!
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
Feh .. clearly I don't quite understand what GPLONLY is about. Looks to me like he's trying to claim that a driver adaptor shim around non-GPL'd drivers can't qualify the kernel as GPL. I'm not entirely sure I buy that, assuming the driver has the purpose of opening up a driver's use (like NDISWrapper appears to do) rather than closing one off (like binary-blob drivers). But interpreting intent is a slippery slope that leads to GPLv3 and worse...
And despite his tone, it does look like he's willing to be convinced otherwise.
Done with slashdot, done with nerds, getting a life.
http://lkml.org/lkml/2008/3/4/300 and http://lkml.org/lkml/2008/3/4/310 do clarify the position of both Linus (right or wrong) and the maintainer of the symbols in question. *shrug*
"When did I realize I was God? Well, I was praying and I suddenly realized I was talking to myself." ~ Jack Gurney
What a pity the people involved in Open Source give my boss another reason to distrust the community and all their projects.
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)
Infuriate left and right
Yeah and why do they have to pass a checklist of requirements to release their code freely? You should be freely available to release your code freely, and the first "freely" I mean in the sense of completely free, not GPL-free.
"Because nobody wants to deal with a crazy zealot."
Right.
http://www.youtube.com/watch?v=KMU0tzLwhbE
Somehow I don't see any businesses caring one bit. Businesses don't care if Linus is a loon. They care that Red Hat, Novell, or whomever their reseller is supports the product they bought. End of story.
Btw Linux hasn't had to try and look like "a true contender" for a decade. Where have you been?
If you wanna get rich, you know that payback is a bitch
I don't get it. So if the Linux kernel allows non-GPL modules to be loaded, then the Linux kernel cannot be released under GPL? Do I need to remove my NVIDIA drivers now?
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
that causes unnecessary hysteria. This isn't exactly encouragement to purchase a subscription to Slashdot.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
For many -- perhaps for millions of users -- wireless networking was *THE* development that made personal computers interesting to them.
The fact of the matter is that with vanishingly rare exceptions, you cannot make a specification-based order for either desktop or laptop devices and have a reasonable apprehension of acquiring a working system. if the operating system happens to be Linux.
This may be the fault of the manufacturers of the Broadcom or Atheros chips, it may be the fault of the OEM's who are known to change chipsets without even changing the product codes on the packaging, and it may be the fault of the NDISWrapper folks who took the half-a-loaf opportunity and provided something that relieved some of the pressure of this, in my opinion, the most serious compatibility problem in the history of Linux.
It amazes me that, even to this day, I cannot reference a compatibility list for wireless devices in such a way that allows me to actually acquire a working device!
I think this was a huge enough problem that somebody like IBM and/or RedHat should have bought out the wi-fi chipset manufacturers for no other purpose than to force disclosure of their specs.
This wireless driver problem is the whip that has driven me to choose Macs for my last 3 portable computers. I wonder if we can even measure the impact of the lack of wireless support?
As an experiment try this: You are tasked with obtaining 255 Linux desktop computers. They must all have the same 802.11/g PCI card. It need not be "officially" supported by any company, but you do need to personally assure that it works after testing one unit. The remaining units will be deployed around the world based on your spec. Pre-assembled or in-house assembly is acceptable. What PCI card do you choose?
Try the same experiment with laptops. What wireless laptop do you order for Linux compatibility?
You can probably do both of these simply buy buying one of the few really expensive cards and/or laptops. Scale the experiment back down to the individual though, and the cost of special hardware combined with the difficulty of tracking down a compatible piece of hardware combined with the frustration that comes from buying a piece of hardware that was ON THE LIST, only to find it DOES NOT work... (Does anybody want a drawer full of Linksys USB radios that are supposed to be Prism2/Intersil according to the part number???)
This problem goes much further than any argument of whether the authors of NDISWrapper should be allowed to paste the GPL header at the top of their code. On that subject: Anybody who holds a legitimate copyright may use the GPL, or NO ONE may use it. It's copyright that allows the use of the license, and nothing else. You want your "tested in court" failure of the GPL? Assert that Linus or anyone else has some authority over your right to use the license for your work. Unfortunately, prevailing in this assertion will tend to weaken the license, since you've just made it revocable by some third party without consideration.
This theory that a piece of software cannot be released under GPL if the software loads non-GPL objects, falls flat on its face. There's simply no mechanism for a third party to constrain distribution based on that argument.
-fb Everything not expressly forbidden is now mandatory.
And as a prize for ou efforts, I'll bite. When you mean "completely free", what do you mean? Do you think there is such a thing as absoulute freedom? I don't think so, myself, because I think that freedom involves more people than the developer and direct recipients of his software, and every actor that gets some freedom has the possibility of taking some freedom away from other actors, but I would like to see what _you_ mean by "completely free", and who you are taking into account (original developers, contributors, distributors, users) when you think about that "complete" freedom.
It's a stupid irregular verb but in this case "This all sprung up" should be "This all sprang up".
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.
* Apache != Kernel module
This is where the serious fun begins.
"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."
On the other hand, for someone like me who bought a used PIII laptop in order to have a cheap linux laptop, it made using a WIFI card incredibly easy. Not something I'm interested in learning how to hack.
I also think I understand that NDIS wrappers are used to make 32bit flash work on my 64 bit system without any input on my part (not sure I understood the article, though). Me likes NDIS wrapper. See, once more, wrappers mean more bling.
The demonstrated intent of the copyright holder does have some bearing on the interpretation of a license, however.
DNA just wants to be free...
Would the above command make the GNU cat(1) command, or the GNU coreutils package non-GPL compliant? I'm not trolling, just saying that it seems up to the end-user how NDISwrapper is used, although in this case the end user seems to be the kernel.
I confess I'm very likely not comprehending the issue correctly since it doesn't seem possible that it's that simple.
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
So the license of the software should be determined by it's ties to hardware or use of a particular virtual memory model?
Linux is more difficult to install and get started (I'm a Mac user, can you tell :)) So for most users I do not think Linux is practical. But every year the user interface improves and more software gets produced, so who is to say that it could not grow to dominate the market? I have seen the OLPC computer, it is good, but still not a Mac. So I just don't think Linux is practical yet, but plenty of Linux desktop users disagree.
At the core of this issue is the GPL definition of a derivative work.
Do not flame me for what I am about to write as it is my understanding of RMS' guidelines, if you have a problem with it, take it up with him.
To clarify what is and what is not a derivative work, the GPL and its supporting documents claim that a GPL work is not how self contained as it may seem i.e. shared libraries or loadable modules, but whether or not it inhabits the "process space" of the GPL work.
When a non-GPL module is loaded into the process space of a GPL application, it violates the GPL license of the application. This is why NDIS wrapper violates the GPL because its job is to load non-GPL code into the process space of the kernel, thus tainting it.
Do I agree? I'm not sure as I can see both sides of the argument. One side is that the module is self contained and isolated. The other side is that one of the purposes of the GPL is to protect the work of the people who contribute frm being unfairly used. It can be argued that the NIC card vendors who's drivers are enabled by NDISWrapper are unfairly enriched by the work of GPL developers in that their proprietary hardware is supported on a free platform without themselves being free.
> 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.
And this is a big deal because ... why? Because Linus' name is on it? Slashdot reminds me of the idiots who used to follow Tolstoy around and write down every word he said, "to save for posterity".
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
A piece of software may not be GPL if it -relies- on non-GPL code. Not if it -optionally uses- it.
Say, I release a game which requires DirectX, links against the proprietary library, depends on it. It can't be GPL. But if I make the game run on both DirectX and SDL, it's enough to make it GPL. It's not crippled by lack of DirectX, it's just a user's choice, a preference to use it.
This way NDISWrapper just -could- be GPL if only someone writes GPL counterparts of the modules it uses. It would mean then, that it's a generic module wrapper which can load a variety of modules, GPL or not, and it's up to the user to feed it the restricted ones in place of the free ones. It may load any -generic- modules, but it should have no provisions towards any specific restricted modules without having an equivalent free part.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.
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 noted elsewhere in this thread, this is *nothing* to do with the GPL-as-a-license, and *everything* to do with GPLONLY as a flag:
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
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.
This is where the serious fun begins.
Linus says, "Trying to claim that ndiswrapper somehow itself is GPL'd even though it then loads modules that aren't is stupid and pointless."
I wrote a program and made it entirely proprietary. I compiled it and ran it on my Linux system. The kernel loaded it right up. What's the difference? The way pointers to entry points are managed? Irrelevant. The state of a "privileged" bit on the processor? A mere conceit with no legal significance. Whether it's a "kernel module" or "user code", it's all a blob of x86 instructions that the kernel loads and hands execution over to from time to time. Quod erat demonstrandum.
Ok, I do indeed agree with you that it is not feasible (for most) to spend the initial energy getting it up and running. It definitely has improved within the last couple of years! I was just afraid that you were thinking (a) since it's not practical to me (b) then it's not practical at all. I'll stop there and refrain from getting too nerdy by discussing how (a) doesn't imply (b) ;)
I do have say that Mac does interest me because I do prefer the UNIX(y) base. I'm currently a poor college student so the price is a little steep for me, however I'd still like to give the Mac a try at some point...
Lack of planning on your part does not constitute an emergency on mine.
lol. I understand sarcasm, possibly because I'm not an American :-)
My boss, just doesn't like OSS at all, if you can't buy it, it must be worthless and too risky to use is his attitude. Unfortunately, this attitude is too common in the business community, possibly ever since the adage "no-one ever got fired for buying IBM" was around.
Try a distro from this century. Installation is far easier than Windows, unless you are using something like Gentoo (in that case, it shouldn't be a surprise). Many distros offer live CDs for install, even allowing you to use the computer while it installs.
I have not used an OLPC first hand, but someone I know did. From what I heard it has irritations not directly related to Linux, but rather design decisions. If you're going by it, it's not modern Linux. Nor is it the Linux attempt to simulate a Mac.
Quite a few non-technical people I know have switched to Linux, some with assistance some without. I think you are putting Mac users in the place of PC users.
Great Intellect...
It depends how you define the public interfaces. Most people would say that the public interfaces are the system calls. And any program under any license can run on Linux and use the system calls.
You have a completely different view of what is a public interface. Who gets to define which interfaces are public? If it is the code authors, then you can say that the kernel authors have decided that the interface in question is not public.
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)
If a VM loads *gasp* Windows code *gasp* then is it ineligible to be GPL? Oh noes!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
With out it, many of us would be screwed for drivers.
Who really cares if its bla bla bla compliant?
---- Booth was a patriot ----
I stand corrected, what i was thinking was in his distribution of the kernel it is his choice if he wish to include NDISwrapper or not. and as IANAL what I say does not matter, but my opinion is that NDISWrapper should not have access to GPLONLY symbols.
and as another poster here said maybe it would be good to dump NDISWrapper so we could start working on getting drivers under GPL license, is it so hard for people that read slashdot to only buy hardware that has open drivers?
I have never ever needed to use NDISWrapper.
preview button, my computer does't have any preview button
These are exactly the reasons we wanted GPL - freedom of choice concerning vendors, modifications to programs, and more. Enforcing GPL without consideration of the needs of the people using the system just puts us right back in the hole of closed systems since we can now see and use the code but just not with anything that is on the "approved" list of applications and systems to use it with. Most people don't care if the software is free or costly but they certainly care when they cannot obtain the functionality they required. Business and personal needs really never coincide with the ideals of the thought police.
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.
Somewhat a flawed argument, since now that ndiswrapper exists there is no incentive to write a linux driver. I would have preferred ndiswrapper didn't exist, allowing linux developers to push for open drivers and specificiations.
So is the point of open source software to be free to do what you want or are we no better than Microsoft in insisting that everything has to be done 'our way'. I would hope that we could win arguments on merit without having to use legal means to force behaviour.
The public interface provided to plug-ins (drivers) is clearly not and can never be limited to system calls. You wouldn't even have basic things like printf or copyin/copyout if you did that. That's the driver writers' equivalent to tying both hands and feet behind the developer's back and telling him/her to write a driver using only his/her tongue and an electrified keyboard.
If the kernel authors decide an interface is not public, it should not be used outside that component of the kernel and maybe a little bit of other code that is closely integrated with that component. These are not functions that are private to a subsystem we're talking about.
We're talking about calls that somebody has simply decided should be limited to drivers under licenses that they like for political reasons. Having a tainted flag is so you can quickly identify that a non-debuggable driver might be involved is useful, but the only valid reason to limit what functions a binary drivers can call is fear of future changes breaking those binary drivers. If the reason is fear of breaking binary drivers, an open source compatibility shim completely alleviates that. If a Windows driver stops working, people generally blame the shim, not some obscure function that it calls or data structure through which it iterates.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Read what I read again. I didn't say he was denying access to the driver. I said he was using his right to allow binary linking but denying the developers of the NDISWrapper code that same right. Sorry, poor choice of wording on my part.
This code is not giving binary-only drivers access to GPLONLY symbols. It is strictly providing an emulation layer that happens to require some of those symbols in order to work correctly. Those are two completely different things. About the only valid reason to complain would be if the NDISWrapper code didn't set the tainted flag. If it doesn't, that's a one line fix.
Check out my sci-fi/humor trilogy at PatriotsBooks.
First there is a lot of hardware that don't have Linux native drivers, mostly wireless network cards and Winmodems. NDISWrapper allows people to use Windows drivers under Linux for when there isn't a native Linux driver available for Linux.
That is the Achilles heel of Linux, lack of third party driver support. Heck that's the Achilles Heel of any Non-Windows operating system be it OS/2, BeOS, AmigaOS, even Mac OSX. One OS, ReactOS, is trying to implement Windows' WDM driver model in GPLed software so that ReactOS can use Windows drivers. I would like to see Linux have the ability to use Windows drivers via some GPLed software, so Linus can borrow that from ReactOS, or write it from scratch, or maybe the WINE team can make a Linux module that loads Windows drivers for Linux that uses the WINE libraries.
I have myself gone through several different wireless cards to get a Linux desktop working and eventually I gave up because I couldn't find a Linux native driver that wasn't flaky or lost the connection, and the only success I had was with NDISWrapper, but as soon as the Linux kernel is updated it breaks NDISWrapper forcing me to recompile the code and reinstall the Windows drivers.
In fact, I have a Linux desktop near my wireless router that uses a CAT5 cable to hook into it and then use VNC from a Windows desktop in another part of the house to log into the Linux system that way. It would be nice if I was able to get good wireless networking support from a Linux native driver without losing the connection or going flaky on me. But I suppose I'll always have a VMWare Virtual Machine to use as well if I wanted to run Linux from any part of my house and not just where the router is located.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Excerpted from Linus mail of 29 Feb:
What's confusing to slashdotters about this whole shebang is that there are two separate issues going on.
First, there is a technical/legal issue relating ndiswrapper's access to the Linux kernel (specifically, access to symbols marked GPLONLY). On this matter Linus is doing his job, which is to enforce existing policy for GPLONLY stuff. Workarounds had been discussed, including the possibility that the people who actually wrote the code (USB stuff mostly) agree to remove the GPLONLY restriction that *they* imposed. Linus is not opposed to the workarounds, but he won't brook discussion about bending enforcement of GPLONLY.
Secondly, Linus' expressed personal opinion about ndiswrapper (whose only purpose is to load Windows code) is complete indifference. He simply doesn't agree that because users depend heavily on ndiswrapper, he should go out of his way to bend the GPLONLY policy or make other special efforts. And he's not alone in the kernel community. Which freaks out the users who are afraid they won't be able to keep using their wireless cards and whatnot.
So people see these two issues fused together and think that Linus is killing off ndiswrapper by personal fiat.
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.)
My boss, just doesn't like OSS at all, if you can't buy it, it must be worthless and too risky to use is his attitude..
In order to establish Open Source in any business you must have this mentality: "if it works for you, good, use it. If it does not work too bad". That, in case you want to "roll over" your own "sollution" using Open Source technologies. If as you said, you want to pay someone, you can always pay a consultancy which uses Open Source software or any other company which offers the "solution" you need (using open or closed source software).
Ubuntu is an African word meaning 'I can't configure Debian'
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...
Wireless cards have to be closed source to use US radio frequency spectrum. In many cases, merely the ability to change frequency or power via software will render these cards unuseable in a legal context.
Hello, that is some interesting information, would you care to elaborate (some links or other citations would be nice). I am authentically interested in your claim as I have never heard about such thing.
Ubuntu is an African word meaning 'I can't configure Debian'
IMHO, the GPL is a BAD license precisely because it causes fights like this to break out with regularity.
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.
Business. Numbers. Money. People. Computer World.
Linus has a point here, and I think we should discourage the use of Ndiswrapper in general. Personally I have a USB wireless stick (Linksys WUSB54GC) with the rt73 chipset, and thus I'm able to use the open-source drivers from the rt2x00 project -- which work flawlessly; Ndiswrapper is a mixed bag generally. I got lucky with my choice of wireless adaptor, but still -- like someone above said -- we should be focusing on making native Linux drivers for these adaptors and not be content with stopgaps such as Ndiswrapper.
NDISWrapper deals with Window's binary blob drivers.
That, under anyone's definition, means nothing GPLed can touch them.
NDISWrapper tried calling its self GPL while exposing all of Linux's GPLed interfaces to the binary blobs.
A very straight forward violation.
Personally I never liked NDISWrapper.
I use Linux to get away from Windows. I dont want their drivers running on my system.
Many people use it even when there are superior native drivers.
Its been portrayed as a quick fix so if your hardware doesnt work out of the box, just use NDISWrapper.
What Linus is ignoring is that nobody's distributing a kernel with NDISWrapper and binary drivers using NDISWrapper. Now all that's left is copyright, and I have every right to make closed-source modifications to Linux, so long as I don't distribute those modifications.
So Linus isn't allowing everything the license allows; he's just using his position for politics. Whether that's right or not, regular people are getting screwed.
... and there are numerous cases where open source wrappers have been written as a border between proprietary and GPLed code. To my knowledge, none of those use (or are allowed to use) GPLONLY symbols. 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. That just... makes no sense. A function marked with EXPORT_SYMBOL_GPL() is intended to only be called by code that is licensed under the GPLv2 (or rather, code that is licensed under a GPLv2-compatible license). The rest of the "code within the Linux kernel itself that calls those functions" are also GPLv2-compatibly-licensed. Where's the problem? What Linus himself *has* said in the past was that he considers binary modules ok *if* those modules weren't developed specifically for Linux. NDISWrapper is a module that loads binaries specifically developed for Windows, so there you go. And, again, those binary modules that Linus considers to be ok aren't allowed to use GPLONLY symbols. Excellent point about Stallman, though. His original vision was indeed born out of compatibility frustrations, but it seems to me to be a bit of a stretch to assert that the purpose of today's GPL is to maintain compatibility.Xfce: Lighter than some, heavier than others. Just right.
Sure he denounced NDISWrapper, but does he reject AND denounce it? The American voters want to know!
But apart from that, I agree with your point that it is a best practice to develop applications on top of cross-platform APIs with Free implementations, such as SDL, Allegro, wxWidgets, Qt, or Gtk+. And in a way, even DirectX could be considered such an API because of Winelib.
The above discussion applies to applications. I have no idea how it applies to kernel modules.
Linux kernels dont come with "NVidia" drivers. Linux kernels come with "generic card support" which all video cards handle in order to display anything at boot time, before drivers have been loaded. Then, the operating system loads the next video card driver layer on top of that after that while the OS starts. this doesn't mean the driver was in the kernel.
-- Betting on the survival of the media industry is a serious risk. I advise investing elsewhere.
> Its been portrayed as a quick fix so if your hardware doesnt work out of the box, just use NDISWrapper.
If it doesn't work out of the box, I don't much care that it's superior. I'm tired of "learning how the system works" for the 1000th time. Not all toil is virtuous.
Done with slashdot, done with nerds, getting a life.
Since ndiswrapper taints itself when it loads a proprietary NDIS module
Can someone explain to me how creating a computability layer for a proprietary model inherently violates GPL? Linus is trying to claim that loading the Windows Driver violates GPL. But I really fail to see how, ndiswrapper is a computability layer, and itself GPL'd, the windows driver is not loaded into the kernel like other modules it is sandboxed by ndiswrapper. It edges towards that gray area of the GPL, but itself doesn't violate it.
If i had one dollar for every brain you dont have, i would have $1.
Thank God the kernel is GPL. I can go in there and remove all this stupid GPLONLY garbage.
An example which I've personally encountered:
The AT76c503a is a 802.11b usb wifi chipset.
Until it was merged in to the kernel, you had to install it from a package (on Gentoo anyway).
Once the package was installed, it worked out of the box and its quite a nice driver.
No packet injection but it can do most other things.
A little bit of Googling to figure out what driver you need vs using NDISWrapper?
No contest there. Googling is fine.
That driver is now merged in to the kernel btw so its now out of the box.
I may be being stupid here, but I'm trying to follow this and not getting it. Please correct where my chain of logic is going awry.
1) the point of GPL that you can't distribute code that's derived from GPL code under anything other than the GPL.
2) Linking against code is considered 'derivative'. Using a public interface is not.
3) NDISWrapper links against the GPL'd kernel.
4) NDISWrapper is required to release under GPL and does so.
5) NDISWrapper uses the public interface of the binary driver
6) This imposes no license requirements on NDISwrapper
7) No license violations have occurred.
Even if Linus doesn't like it, it doesn't seem like there's anything in the GPL that specifically stipulates that you can't both link against GPL'd code and use the public interface of non-GPL'd code, and if there is, it will cause a LOT of problems in LinuxLand. Am I wrong?
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
I keep hoping for a Linux distro that automatically loads all the proprietary and "illegal" codecs in existence so that I don't have to hunt for them all over the net and install them all individually. It could have a disclaimer like this:
"I acknowledge that I am a crook, a thief, a pirate, and all manner of other evil, and that I eat little kittens for breakfast. Please download and install all the non-GPL programs and all utilities and codecs that our corrupt legal system deems 'illegal.'"
Check: YES or NO
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
I wasn't talking about the kernel.
It's a blatant double standard. Either GPL with a linking exception is or is not allowed to call code marked with EXPORT_SYMBOL_GPL. You can't have it both ways. Therefore, any code in the kernel that provides a linking exception---basically almost anything that exports a module interface---should not be allowed to call these functions unless this wrapper is also allowed to call them.
Check out my sci-fi/humor trilogy at PatriotsBooks.
ROTFLMAO. I disagree that the license doesn't have a spirit; any legal document had an intent behind it when it was written, and that's what we refer to when we use the term "spirit" in reference to a law, a license, etc. Beyond that, though, you make some excellent points. :-)
Check out my sci-fi/humor trilogy at PatriotsBooks.
Because it's not exactly their code - NDISWrapper uses kernel interfaces*, so it's derivative of Linus et al's code. That means the kernel developers get to tell them how they can release it, and they've said "GPLv2, no linking exception".
*Not just the syscall interface which the kernel license says doesn't constitute a derivative work. It even uses those interfaces that the kernel specifically marks as constituting a derivative work.
I wasn't actually aware that Linus was the Supreme God of GPL.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Since "you" is ambiguous referring to an AC, I will post my $.02 worth of searching.
FCC Rules on FOSS and Software-Defined Radio
Cognitive Radio Technologies and Software Defined Radios
As far as I can gather the main problem is that part of the licensing requirements is that "security measures" that need to be in place to prevent use of the device outside the specifications for which it is licensed.
With the boundary between driver software on the computer vs. firmware on the device shifting ever more away from the device, it becomes harder to implement these security measures.
The Hacker's Guide To The Kernel: Don't panic()!
No, the purpose of the GPL is best explained in its preamble:
If you allow linking of this sort then you allow people to possibly use GPL software under a different license. For instance, Microsoft would take whatever GPL code they wish from Linux, wrap it in a binary interface, and include it in their operating system as long as they released the source code for just those portions. You still couldn't use the GPL code without paying Microsoft for their non-free code. I think it's done a lot of goodYeah, good luck on asking the 1000+ people that have copyright on the kernel...
I'm pretty sure he knows precisely what is meant. I think that he, like me, thinks that it is a meaningless concept for a legal document, because the spirit in which you wrote it is largely irrelevant; words have specific legal meaning and what you might want them to mean is not important to anyone but you.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
GPLONLY variables from the kernel is what was denied. The source code and project license seem to be ok as being stated as GPL.
That may be fairly easy when you can piece together a desktop system, but for laptops, it's a lot tougher. Though more and more native drivers are appearing, it's not hard to find a laptop out there that uses some goofy proprietary WiFi hardware. I'm in something of a situation with an actual Broadcom NIC driver for my crappy little HP laptop. The WiFi is recognized, but not the Ethernet. If I have to use NDISWrapper to get my ethernet working, I'll do it. Guys like Linus can stand on principle if they like, my job entails actually getting things done, and not stomping my feet and having a tantrum because I have to use a shitty kludge like ndiswrapper to get some crappy Win-hardware working.
The world's burning. Moped Jesus spotted on I50. Details at 11.
NDISWrapper is the only thing that can run tons of devices... Ohwell...
http://linux.slashdot.org/comments.pl?sid=476560&cid=22656000
by F452 (97091) Alter Relationship on 14:11 Wednesday 05 March 2008
Cheers to F452 for this information.
Yet Socrates himself is particularly missed.
A lovely little thinker but a bugger when he's pissed.
However, I think you miss the point that many people (e.g. OP and myself too) consider the case of linking-against-header to NOT be a derived work. And of course many other people disagree, but this issue has not been decided in court, so neither side can claim a definitive opinion.
The key argument here is that you are using a work, but that's not necessarily the same thing as deriving a work. The header defines a public interface, in other words a standard or a protocol. For example, if I GPL the text of a standard describing a network protocol, that does not mean that all implementations must be GPL. Or if a GPL program provides a command line or network/socket-based interface, I can use a non-GPL program to tell it what to do. Similarly, if my linker produces code that can interface with a GPL library, it's simply using a function call mechanism to do the same thing. If you want to complain about that, simply replace the direct function call with a remote procedure call serialized through a socket, and things get very blurry, yet the same functionality remains.
Of course, statically linking or using headers with inline functions does mean the executable has GPL code in it, and thus must be GPL. But to me, purely dynamic linking means that there is a clear separation of GPL code, and a client executable is no longer a "derived" work.
if ndiswrapper gets a free pass on this, whats stopping anything and anyone to write a wrapper that access the gpl hooks, and then have a binary module at the other end?
would that not be a run around the whole point of the gpl only hooks in the first place?
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
If it's a derivative work of the Linux kernel because it implements a Linux API, then by that rationale and the description you quoted, it's also a derivative work of the Windows kernel. Do Microsoft know about this?
I can only imagine how the code must feel, conflicted over whether it's free-as-in-freedom or evil and proprietary. I see lots of therapy in its future.
This sig is false.
Hey,
.so and source code in the same zip file, CD, or installer as my seperate program, does that make the zip file, CD, or installer a derivative work? I know Linus has talked about that issue before, which he refers to as 'mere aggregation', which I believe is a reference to the GPL which explicitely allows mere aggregation. Where do you draw the line between aggregation and derivation? Maybe Rosen's suggestion is the simplest way to resolve the question, but it makes the GPL very weak, as a result.
Thanks for the link to the discussion on Rosenlaw. That's a great link. I'm not sure I *completely* agree with Rosen - the one point where I think he might lose the argument is that statically-linked binaries are not derivatives. I understand where he's coming from - he's trying to find the simplest definition of derivative work.
But the problem is, a statically linked binary *does* contain your original work in part or in whole. In my earlier post, I put forth a statement of principle that, where there is no copying, there can be no copyright infringement. I think most reasonable people can say that the converse of that holds as well - where there is copying (without permission), there is copyright infringement.
Although, I suppose possibly what Rosen is getting at is that it would be possible for me to ship the original static library source code, and so fulfil the obligations of the GPL wrt providing access to the source code for the original work, and that my binary is not a derivative work. But, I think that still may be a weak argument.
Man, I don't know. It does get rather complicated. I mean if I dynamically link, and distribute the GPL
But, we can't let the GPL be too strong, either. I really think these issues of loading proprietary drivers with GPL wrappers like NDISWrapper really expose the absurdity of the 'dynamic linking violates the GPL' idea, too.
I didn't know Linus (or anyone else) could control my ability to release my code under GPL. Assuming that its my code and I didn't swipe it from someone else (violating some other copyright ) I can choose the GPL and there's not much anyone else can do.
The code I release under the GPL may have nothing whatsoever to do with Linux, Linus, *NIX-like operaing systems or whatever.
What Linus does have power over is the trademark 'Linux'. He can, if he desires, deny the right to use that name for any product that doesn't meet his standards, including those that bundle NDISwrapper in the kernel source.
I'm not certain what control Linus has over my building/installing a Linux kernel that complies with his wishes (i.e. no NDSIwrapper) and then my downloading/building/installing NDISwrapper on my own system for my own use.
Have gnu, will travel.
Though again it's a matter of licensing -- if a module reports itself as "GPL with linking exception", I'd expect it to be denied access to GPLONLY modules, and I'm pretty sure that's how it works today. ndiswrapper was getting around this by claiming to be GPL in the past; now it looks like there's an explicit check for ndiswrapper in the kernel that will deny it access to GPLONLY symbols, even if it tells the kernel it's just plain old GPL.
Xfce: Lighter than some, heavier than others. Just right.
So are you saying that I can write a closed-source program and link it against a GPLed library? I'm only using the header files and using its public interface. That sounds wrong to me and essentially makes LGPL = GPL.
Xfce: Lighter than some, heavier than others. Just right.
Bzzt - wrong. GPL is a one way street, not a two way street. There are no negative requirements in the GPL. *Anything* can be placed under the GPL.
Where GPL requirements come into play is that the GPL sometimes requires code to be placed under the GPL. Code that is derived from GPL licensed code *must* be placed under the GPL. Derived code has been held to be both code that is a modification of a piece of code *and* code that is linked to and depended on, like a library. It's a one way street, though. If you make something like ndiswrapper it can be released under the GPL. The fact the ndiswrapper provides functions to proprietary code doesn't have any bearing on its GPL status. And, the fact that proprietary code is now linked to ndiswrapper doesn't force the proprietary code to become GPL'd - it doesn't depend on ndiswrapper and it wasn't linked with ndiswrapper by its creator and distributor.
OK, if we're going to assume the GPL has a spirit, its a "copyleft" license that relies on copyright law for enforcement, and it says explicitly that is not a use license.
This bothers some people who would like to use the GPL to implement specific EULA restrictions, and those generally are the people who are citing "the spirit of the GPL".
Business. Numbers. Money. People. Computer World.
Not really. It's similar to the legal concept in DMCA/copyright of "significant non-infringing use.
The problem is that there's no stated technical or legal criteria for a GPLONLY symbol. It appears to exist mainly to appease certain developers that are angry about end users loading binary modules.
Business. Numbers. Money. People. Computer World.
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."
AFAIK Microsoft has never threatened to sue a developer or made any copyright claims for using their published APIs. So unless you're talking about patents (legally entirely different), this is way off in the FUD zone.
Business. Numbers. Money. People. Computer World.
The main danger with BSD is someone forking your project and extending it with proprietary but obvious additions. The original project then suffocates because it can't implement the now-protected IP.
"I've got more toys than Teruhisa Kitahara."
I ain't no lawyer (thank god) but if you don't think that the intent of a contract matters when you go into court, I suspect that you ain't no lawyer either.
The real trouble with all these issues is that programmers have trouble understanding that legal code is not computer code -- legal definitions are not always precise, and they often require judgement calls (which is why we have judges), and in the case of the GPL the question of what a "derived work" is can be a problem on occasion.
(And if you ask me, the GPL is a pretty brilliant social institution, a really clever legal hack -- if you slashkids don't get the point, it's just because we haven't been seeing too many problems of late like the unix wars of the 80s... unless of course, you count OSX which looks a hell of a lot to me like the latest proprietary fork of the BSD code base.)
People who know the truth and are sure of themselves don't have to use insults like you do. Blame shifting and malice are for the desperate:
There is no "Microsoft bugs and malice" involved in an interface specification and any bugs occuring [sic] would be solely the domain of either poor implementation of NDIS or by bugs explicitely [sic] 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.
If I'm a braindead tool, Microsoft is in big trouble because anyone can verify what I did. Firmware, like this, is loaded in Windows with software that's nothing more than SDK parts provided by MickeySoft. Bugs come from the clowns who play, the malice is all from Redmond. The game is painfully obvious.
But the dam has given way. Hardware that sucks does not sell, regardless of who's really at fault. Companies playing the Microsoft game are having trouble but people selling software that works with free software are doing well. Things are not perfect by a long shot but Vista's failure to generate substantial income for Microsoft's partners has changed the game forever. Here's the winner:
Don't blame me, I didn't vote for either of them!
Unfortunately I'm in that age bracket that remembers the Unix wars. However, there's an enormous tangible differences between trying to prevent some poor hack from using his NDIS driver and some large proprietary vendor using a closed blob to fork Linux.
And Linux people should be a lot more confident in their economic model, because code-sharing between vendors seems to be beating forking.
Business. Numbers. Money. People. Computer World.
But my money would be on that you can, as long as the binary you're providing doesn't contain any GPL code, just names of symbols to lookup. (Otherwise, we could turn this around on its head --the windows drivers are the ones in the wrong because they can link against ndiswrapper, a GPL program, and therefore all of the applicable vendors must now release their driver source code!) That sounds wrong to me and essentially makes LGPL = GPL.
Yup, that's exactly what I'm saying. Except LGPL also permits static linking, for whatever that's worth. Of course it's not what certain GPL promoters want it to mean, and really I'm sympathetic to their cause, but there are limits to what you can claim as "derived". IMHO, those limits allow a symbol table without making it a "derived work". Otherwise we wouldn't be allowed to use reverse-engineered protocols and file formats, which are a well established freedom for compatibility and interoperability.
This is all relative to the GPL 2.0 btw, I don't know the 3.0 very well. But take this comment from the FSF FAQ:
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.So they want to have a blurry definition depending on how extensively you use the library, and I don't think that will stand up very well.
Personally, I would put the blurry line as a matter of distribution... if you distribute your executable bundled with the GPL'd library, then you are providing a derived work. If you require end users to acquire and install the library themselves, then you are linking against a specification, and the user is free to choose the implementation. Further, any potential license violation is at the user's end, for they were the one to mix the GPL'd library with the proprietary executable. For example, OS X masquerading BSD libedit as GNU readline.
How is the Ndiswrapper different from the ELF loader in the respect that it can load non GPL software. The ELF loader is not placed under these restrictions afaik.
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.
Actually I read it as an issue of Linus saying that ndiswrapper shouldn't have access to these symbols, not a specific legal licensing issue. I don't see Linus making any claims about NDISWrapper's licensing.
Since it is not a licensing issue, it seems to me that the easy way forward is for ndiswrapper to include a patch which restores this access and require that patch be included on the kerenels on which it runs. This just means that distros have to build their kernels with that patch. Sooner or later, pressure will build to get the functionality merged back into the main kernel.
That seems the obvious, easy, and safe way forward.
LedgerSMB: Open source Accounting/ERP
So by your idea, writing Windows-only GPL software should be....?
LedgerSMB: Open source Accounting/ERP
The NDIS drivers are not in any way based on the GPL code, and the NDISwrapper is not in any way based on any of those specific drivers. So I don't see what the issue is. It is the same issue which has been hashed out over and over in SCO v. IBM relating to whether JFS is a derivative of Sco's purported copyrights. The answer has clearly been "no" for much the same reason, even before Novel won the judgement relating to the copyrights.
LedgerSMB: Open source Accounting/ERP
He won't do that because, he can't.
Amateur radio is prohibited from using encryption on the public airwaves, at least not unless you also provide the key. Generally, the FCC regulates to favor those who build their own equipment and systems, (even outside of amateur, for all the trolls I know I'm going to get for that, I'd provide you with a link, but, as I'm currently getting my source from a book, that won't work) so, obviously these systems can be open-sourced for others to try building themselves. (Another point, if it were illegal to open-source the equipment/software, why has openwrt not been shut down?)
In short: The article headline and synopsis is false, probably misunderstood by the joker that submitted it. From a licensing standpoint, NDISWrapper is GPL'd code. However, it loads non-GPL code, and should thus be treated as such by the kernel - disallowing GPLONLY symbol and module calls. Reading farther down the thread, it seems that this isn't a real serious problem, as the workflow module has already been reimplemented, and either a relaxation of the USB module's restrictions, or a userspace side workaround would solve it quickly.
In short, much ado about nothing. Move along.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
Except that's not true at all. The intent behind a legal document can and often does have a significant bearing on how court cases are decided. Don't believe me? The entire SCO/Novell case (or was that the SCO/IBM case?) hinged on whether it was Novell's intent in the licensing process to transfer the UNIX copyrights to SCO or not. It is actually not at all uncommon for the spirit of an agreement to have an impact on how a court rules on a contract issue, particularly if the contract is vague about certain details.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The elf loader loads non gpl software INTO the kernel?
Patents Drive Free Software as Hurricanes Drive Construction Industry
I think that as long as it's adhering to the license it can do whatever it wants - I don't know much about licenses so I don't know if that's allowed or not. I think that one of the main points in open source software is that anyone who wants to modify the software can do so, and so using platform specific libraries where crossplatform ones are available should be avoided, but if code makes use of some standard part of Windows then there's nothing wrong with it. I don't really see the problem with using GPL code to work with Windows drivers either, since the program itself doesn't have any non-GPL code, just the drivers it loads in, but again I've not studied the license. What license is WINE distributed under?
which is totally what she said
We are inside a cardboard box. While the walls and floor are GPL-licenced, the top ceiling is too, with a glitch. Instead of expensive glueing system to close the box, we use ducktape. Of course when we open the box, ductape ruins some of the coating outside but it works the same way as the glue which does not break coating.
Linus is trying to keep GPL pure and perhaps this wrapper in the future could break some apps and usability. This is why he prefers emulation.
> 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.
This has never been the purpose of GPL. GPL is a political license. It is written to oppose whoever trying to limit the freedom of users. It is built to partition the whole world of software into "free" and "non-free", and so that they cannot easily cooperate. The hope is that with a world of free software being inter-operable, each individual non-free software, even those large and evil ones, will fail to compete. And the few "license compatibility issue" is seen as technicalities that might make the license less desirable, but is a necessary evil and never so much to worth ditching the effort. In this sense, NDISwrapper is against the whole idea, so it has every reason to have been denied access to other GPL software.
If you hate GPL for this (or whatever) reason, you are free not to use it. But don't expect you can ask projects using GPL to stop using it. They do so for a reason, many of them feel really unhappy if non-free software end up using them as a platform.
If I have nothing to hide, you have no reason to search me
Is it bad that when I saw this I thought
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
It's very important.
If Ndiswrapper is in violation of the GPL then the network card vendors will have to release their source code.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I don't consider myself to be socially awkward. I have an instinctive love of precision which lesser minds confuse with pendantry and a contempt for the pointless social rituals of the bovine masses.
Oh wait. Nevermind.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Well yeah, that is their prerogative. And they've decided that only GPL code is allowed in the kernel.
But if you do that you have to accept that companies with drivers that depend on third party code will not support Linux because they can't release that third party code under the GPL. As will companies that don't want to release the code because the consider it a trade secret. And good luck getting them to release hardware details either since they'll probably view driver source code and hardware register details as being equally sensitive.
Given that most hardware companies don't bother with Mac support and Macs have a far higher market share and allow binary drivers, making things difficult for them like this seems to be highly self defeating.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Exactly why would network card vendors have to release their source code? I don't recall any of them using the wrapper in their product, they deliver Windows drivers that Linux users use via ndiswrapper. The vendors aren't required to do anything.
Public Domain is even easier, anyone can do anything they want and no arguments at all ....
....the point of both of these is to stop people doing things you don't want, the list of things people cannot do are just different, and since this is a legal matter people will argue about the complex or borderline cases ...
But that is not the point of either the BSD licence or the GPL
Puteulanus fenestra mortis
I don't think you know what is the real problem here, so let me help: the GPLONLY symbol used to keep track of the loaded modules binary-only vs open source status. If you load a binary only module, the kernel becomes "tainted", and the kernel developers tell you to take a hike when it crashes and you go to them for help. They do it for a reason: they can't help you without the complete source of the running kernel and they don't have it if you loaded binary-only drivers. In our case, it doesn't really matter if modprobe loaded the binary-only code or ndiswrapper did, in the end we have binary-only code running in kernel space, if it does something wrong, the no-one can figure out what happened, only the author of the binary-only code. This is what Linus is talking about.
Szo
Red Leader Standing By!
NDISWrapper deals with Window's binary blob drivers.
That, under anyone's definition, means nothing GPLed can touch them.
It's not so clear-cut as that. Can a GPL program, say Open Office, "touch" Word documents?
A Word document is file of binary data (ie, not strictly text). Open Office loads this binary file to perform some work: reading and writing a document.
A Windows network driver is a file of binary data. NDISWrapper loads this binary file to perform some work: reading and writing network data.
Why is the GPL available to one but not the other? NDISWrapper just loads the driver into memory and shuttles data back and forth between it and the kernel. I don't see any reason preventing it being GPL licensed.
--
Promoting critical thinking since 1994.
The basic thing is-- the GPL uses the term "based on" in several places. IANAL, but my reading of the current copyright law in the US suggests that "based on" has a very specific meaning which is quite different than the way RMS and Linus use it. "Based on" as in "this movie is based on the following book" implies transforming one work into another through a creative process. This is the same standard and definition of "derivative work" which is fundamentally different than a "collected" or "compiled" work under copyright law (linking seems to my mind to create the latter, not the former).
LedgerSMB: Open source Accounting/ERP
A GPLed program specifically cannot have non-GPLed code linked to it.
NDISWrapper doesnt load a file. It executes it, linking it to its self.
Here is a relevant quote from the GPL FAQ:
In this case, the binary blob drivers are essentially plugins.
They are dynamically linked to GPLed code and then executed.
The GPL only applies to programs, not data which is why its fine to open
As you can see, this is a very clear cut case.
The normal people of the world, who actually need to get shit done with their Linux machines, and know that manufacturers don't get it, and don't give a shit... will continue to use NDISWrapper and ignore it's GPL status or anything else related to it.
They'll happily run native drivers if the kernel devs can ever figure them out, but meanwhile they've got shit to do... and no fiscal or moral reason to care.
+++OK ATH
"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."
I guess it is a good thing that was back when printers where expensive.
What do you do today if the your printer doesn't work with your OS? Buy a printer that does. In fact that is the very advice that you will get from the FOSS crowd. You should only buy devices that have not just working drivers but working drivers that are FOSS...
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Comment removed based on user account deletion
Comment removed based on user account deletion