Recent Features
| |||||||||||||
GPL-only symbols and ndiswrapperGPL-only symbols and ndiswrapperPosted Oct 26, 2006 2:05 UTC (Thu) by josh_stern (guest, #4868)In reply to: GPL-only symbols and ndiswrapper by dlang Parent article: GPL-only symbols and ndiswrapper
I meant that ndiswrapper has an LPGL-like philosophy that is ideologically incompatible with the intent of those kernel developers who wanted their work to use EXPORT_SYMBOL_GPL only. At least that is my interpretation.
(Log in to post comments)
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 8:05 UTC (Thu) by malor (subscriber, #2973) [Link] But at no time is the GPL ever violated. The GPL says we can't distribute free- and non-free code (either in source or binary form) together. But nobody is doing that.
Ndiswrapper itself is GPL. The kernel code is GPL. Windows binaries are never GPL. You could certainly make the argument that distributing all three of these together violates the GPL, but *that is not what is happening here*.
Rather, they seem to be upset that end-users are using ndiswrapper to load proprietary drivers. But an end-user who uses ndiswrapper to load a Windows binary is NOT VIOLATING THE GPL, because he is not distributing it.
This is pure bullshit. The kernel devs are trying to restrict what end users do with their systems, which is as profoundly un-GPL and as un-free as you get. This kind of move is something you'd expect from Microsoft or Apple.
Fortunately, they have a lot less power to enforce their edicts, since their changes can generally be patched out, but making this edict at all shows that they really don't understand the license they're using.
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 11:06 UTC (Thu) by drag (subscriber, #31333) [Link] ""This is pure bullshit. The kernel devs are trying to restrict what end users do with their systems, which is as profoundly un-GPL and as un-free as you get. This kind of move is something you'd expect from Microsoft or Apple.""
No they aren't. You just change the names around an it works fine. You just comment out the 3 lines or so that check for ndiswrapper.
There are a dozen easy ways to work around this and the kernel developers know it.
People are ignoring new open source drivers and such because their stuff works with ndiswrapper. This is entirely unsupported and can't be depended on working. People are told that it does work though, when they shouldn't be told anything of the sort.
They don't want to end up in a position were manufaturers are using ndiswrapper as a excuse for not supporting Linux.
For instance Texas Instrument used the existance of the linuxant and ndiswrapper drivers for not supporting Linux for their wifi stuff. This is a fact. They even advertise this fact by in a press release that they support linux by helping out conextent development.
If their hardware works fine in ndiswrapper then what possible justification can you provide for releasing documentation and code for writing proper drivers?!
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 11:58 UTC (Thu) by malor (subscriber, #2973) [Link] In other words, you just agreed with me that it IS NOT about the GPL. It has nothing to do with the GPL. The GPL is a big fat red herring.
They're using their code to try to control what end-users do. They are painting it as a GPL issue, when it isn't. This is either dishonesty or poor thinking on their part. If they want people to use the open source drivers, they should be doing it a different way, not deliberately breaking people's machines.
The HONEST approach would be to refuse to load ndiswrapper with an error message. "We don't like this code, and we don't want you to use it." That would piss people off mightily, but it would be accurate.
We're not supposed to run Linus kernels anymore anyway. Hopefully the distros will just comment out this garbage.
GPL-only symbols and ndiswrapper & GPLv3 Posted Oct 29, 2006 15:50 UTC (Sun) by mingo (subscriber, #31122) [Link] They're using their code to try to control what end-users do. I think you might be confusing things here. Every OS code on this planet, including the GNU Hurd OS, "controls" what end-users do: that is what code does to begin with. (For example: the Linux kernel does not allow the modification of kernel-space memory by user-space code.) The question here is purely implementational: what does the kernel code do by default? If you dont agree with the default behavior, and if you think the resulting work is still fine under the license, you can change the source code and redistribute the result. (Some raised the "how is this different from the GPLv3 situation" question and the answer to that is simple: the GPLv3 draft was claimed to limit what end-users can do via the license. I hope you will agree with me that there is a big difference between code-based limitations and license-based limitations.)
GPL-only symbols and ndiswrapper & GPLv3 Posted Oct 29, 2006 17:47 UTC (Sun) by malor (subscriber, #2973) [Link] Oh for chrissake, you're splitting hairs.
The kernel devs were trying to make it difficult for you to run code they don't like. They've changed their minds subsequently, but they had decreed that ndiswrapper was Not Acceptable Code as written, and wrote a specific blockage of that code into the kernel. By name, even.
They were using, in other words, code to enforce a political viewpoint...and an INCORRECT political viewpoint at that, since ndiswrapper doesn't violate the GPL.
This is entirely different from code that controls behavior because of technical reasons, and you know that perfectly well. They were trying to limit end users from running *specific code*. They weren't saying "nobody can do X because it will break systems", they were saying "We don't like ndiswrapper and you can't use it anymore."
The fact that we can hack around their edict is irrelevant. We shouldn't have to.
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 14:55 UTC (Thu) by cventers (subscriber, #31465) [Link] I agree that ndiswrapper is a problem in the long run (though I respectits authors for coming forth with a solution, even if I don't agree with it).
But I absolutely agree that it's un-GPL and un-free. Bringing the GPL
Kernel developers are often heard to say "We don't do licenses, we do
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 14:04 UTC (Thu) by josh_stern (guest, #4868) [Link] "This is pure bullshit. The kernel devs are trying to restrict what end users do with their systems, which is as profoundly un-GPL and as un-free as you get. This kind of move is something you'd expect from Microsoft or Apple."
More accurately, some kernel devs are trying to restrict what developers do with their *un-patched code*. It is neither enforcing GPL nor un-GPL. The GPL license permits developers to modify the GPL'd kernel, but restricts the licensing and distribution of that modified code. GPL doesn't say that GPL'd code should be equally friendly to all usage. As a relevant point of interest, distributing together a kernel, an ndiswrapper, and the binary drivers that people want to use ndiswrapper with would be a GPL violation. Since that distribution isn't in question, what we are talking about is just a preference by the developers for making their unpatched code unfriendly to such usage (distributed or not). That is not surprising, but it is controversial because it hurts some users.
Is the policy good or bad? Tt comes down to weighing conflicting interests of some end users and some kernel developers. Also relevant is the technical question of how much work or difficulty is involved in making ndiswrapper work with the GPL SYMBOL stuff.
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 14:43 UTC (Thu) by malor (subscriber, #2973) [Link] Actually, after thinking about it, I'm not sure it would be illegal to distribute that way. A Windows driver isn't a derivative work of Linux, period.
If someone could get permission to distribute the drivers, I suspect it might be perfectly legal to distribute Linux (GPL), ndiswrapper (GPL), and Windows binary drivers (non-GPL, but not a derivative work.) I don't think a Windows driver could be considered a derivative work even if distributed this way. I could be wrong. This is at least a little gray, but it's certainly much less egregious than Tivoizing the code, which the kernel devs are perfectly happy with.
I don't think there's any way AT ALL that this can be painted as a GPL issue. It's just kernel devs being assholes, and using the GPL flag to do so.
They are abusing their users, and I would encourage distros to just disable the 'taint' code in their kernels. It's being misused.
GPL-only symbols and ndiswrapper Posted Oct 26, 2006 16:12 UTC (Thu) by josh_stern (guest, #4868) [Link]
There is a kind of argument that arises with GPL about what is a derived work and what is mere aggregation. Lots of people would argue that shipping the Windows binary drivers with ndiswrapper makes a derived work and not a mere aggregation, in which case that would be considered a GPL violation.
GPL-only symbols and ndiswrapper Posted Oct 30, 2006 23:21 UTC (Mon) by tbird20d (subscriber, #1901) [Link] Lots of people would argue that shipping the Windows binary drivers with ndiswrapper makes a derived work and not a mere aggregation,...Lot of people would be dead wrong. This idea that shipping two things on the same media somehow turns one of them into a derivative work of the other is asanine.
GPL-only symbols and ndiswrapper Posted Nov 2, 2006 12:50 UTC (Thu) by arcticwolf (guest, #8341) [Link] First of all, let me say that IANAL, so you should disregard everything I wrote here - including this line. ^_~
I think the real question is why and how a driver was written. If a hardware vendor wanted to create a Linux driver for a product without GPL'ing it and still use GPL-only symbols, they could - from a technical perspective - create a GPL'ed wrapper module that doesn't really do anything other than providing a "GPL-proof buffer" between the kernel and the real driver.
However, that obviously would be piracy^Wcopyright infringement; the real driver would be a derived work of the Linux kernel.
The other "extreme" is what ndiswrapper is like: here, the "real" driver is not written with Linux in mind at all and was never supposed to run on or interface with Linux. Clearly, as you say, one cannot claim that such a driver would be a derived work of Linux, and I think - hope - that any lawyer making such a claim would be laughed out of court.
There is a gray area, too, of course. What if a company writes a driver for windows, and then *later on* decides to make it work on Linux as well by creating a wrapper module? I'd like to say that this isn't legal, but I'm not sure how one could argue that a piece of code that was already written a long time ago can retroactively become a derived work of something else (Linux, in this case). Things get even less clear when you consider updates to the (non-GPL'ed) driver: would a fix for a bug that only shows when the driver is used with Linux instead of windows make the driver a derived work of Linux, for example? I have no answer to this.
But that's not the kind of situation at hand, fortunately. As others have pointed out, the core of this dispute is not copyright: ndiswrapper does is licensed under the GPL and does not violate the copyright(s) of the Linux kernel developers.
The *real* question is whether the kernel developers have a moral right to do what they did - that is, whether it's acceptable to try to interfere with uses of a piece of free software (which it is in practice, even if it's not "officially" designated Free Software(tm)). I don't really have an answer to that, either, but given that the whole thing is mostly symbolic, anyway (it's trivial to change this again, and since ndiswrapper does not violate the GPL, distros can make this change without having to worry about violating copyright themselves), I would be happier if the kernel developers refrained from this kind of politics.
And politics it is: enforcing the GPL and insisting that contri- and distributors abide by it is laudable, and not caring about whether a change makes life more difficult for proprietary code etc. is certainly OK, too, but a change that *only* exists to do that and that does not have any other raison d'être... that's asinine.
And what's more, given the kernel developers' criticism of the GPL v3 and their insistence that as far as the kernel is concerned, only the GPL v2 matters, it's hypocritical, too; if the GPL v2 really was all that mattered, this change would not have been added to Linus' tree.
So even though I agree that proprietary modules are bad, and even though I have mixed feelings about ndiswrapper (on one hand, scratching itches is a good thing, but on the other hand, it's not good if band-aid prevents a real solution to a problem), I think that this change was a bad thing that should be reverted as soon as possible. Let's not get political.
GPL-only symbols and ndiswrapper Posted Oct 27, 2006 4:19 UTC (Fri) by pimlott (guest, #1535) [Link] The kernel devs are trying to restrict what end users do with their systems, which is as profoundly un-GPL and as un-free as you get.They are not trying to restrict, they are trying to make less convenient. The FSF is well-known to do this as well. For example, it declines features in GCC to export and import the intermediate formats, so that end-users can't conveniently plug in proprietary front- and back-ends. It's not exactly the same technically, but the goal is the same: Reject hooks that could be used by proprietary software. Users can always add them themselves, so it is in no way a restriction of the FSF's freedoms. That said, the use of GPL-only symbols to enforce this is questionable and certainly confusing. GPL-only was supposed to express the intent that modules using them are derivative works. ndiswrapper acknowledges that it is a derivative, and its GPL license seems uncontrovercial since it simply implements a public interface with a variety of users.
GPL-only symbols and ndiswrapper Posted Nov 2, 2006 12:53 UTC (Thu) by arcticwolf (guest, #8341) [Link] But there is a difference between "we won't make it easier for you" and "we will make it more difficult for you on purpose". I can very much understand that the gcc folks aren't willing to spend time and energy on implementing features that essentially would be of use only (or mostly) to vendors of proprietary front-/back-ends, but they aren't going out of their way and spending and energy on implementing restrictions that make it even more difficult to do that and that don't serve any other purpose, either. (Or are they?)
GPL-only symbols and ndiswrapper Posted Nov 2, 2006 15:13 UTC (Thu) by pimlott (guest, #1535) [Link] Or are they?If our discussion were more timely, Joe Buck would answer. :-) I'm out of my authority here, but I think I've heard that there have been developers interested in implementing it, and that it was vetoed from the top.
|
|||||||||||||