| |||||||||||||
NDISwrapper dodges another bulletNDISwrapper dodges another bulletPosted Mar 5, 2008 18:40 UTC (Wed) by JoeBuck (subscriber, #2330)Parent article: NDISwrapper dodges another bullet If the official kernel were to accept a patch that would prevent ndiswrapper from accessing some symbols, nothing would stop a distributor from reverting the patch, as GPLv2 gives distributors the freedom to make modifications. Linus is right that the GPL (any version, or any copyright-based license for that matter) applies only to derived works, so ndiswrapper isn't breaking any rules. Where it gets iffy is when a downstream distributor or hardware seller provides a customer with Linux plus ndiswrapper plus a Windows driver; the combination is a derivative work even if the Windows driver piece isn't, so a strict interpretation would say that this isn't kosher. On the other hand, the whole GPL-only symbols mechanism, the long existence of proprietary drivers, etc. implies that the real license to Linux is GPL with fuzzy exceptions for modules. So distributors who want their customers to use ndiswrapper probably need to have their end-users load the Windows driver on their own to stay in the clear.
(Log in to post comments)
Sauce Posted Mar 5, 2008 19:08 UTC (Wed) by ncm (subscriber, #165) [Link] The same arguments made earlier insisting that a release under the GPL couldn't be retracted would apply equally here: ndiswrapper has been distributed with the kernel and drivers with full awareness of the kernel maintainers, for years. I.e., to withdraw permission now would be much the same as withdrawing permission to redistribute GPLed code.I'm not saying they couldn't withdraw permission. It's just that those whose position comes down on the wishful-thinking side of any argument would argue opposite here as for the previous issue, and even insist there was no contradiction. The canonical reference for wishful thinking is also the Greatest Blog Post Ever.
Sauce Posted Mar 6, 2008 3:08 UTC (Thu) by proski (subscriber, #104) [Link] I think you are comparing two different things. One is like changing a contract unilaterarily after it was signed. That's clearly illegal. Another is like installing "no trespass" signs in wrong places. It can be forbidden too, but by another law, and there is no law specifically regulating GPL-only symbols.However, installing "no trespass" signs in improper location would cause people stop paying attention to them, and some trespasser could even argue that the trespass wasn't willful if there were some obviously wrong signs nearby.
NDISwrapper dodges another bullet Posted Mar 5, 2008 19:12 UTC (Wed) by and (subscriber, #2883) [Link] > If the official kernel were to accept a patch that would prevent > ndiswrapper from accessing some symbols, nothing would stop a > distributor from reverting the patch, as GPLv2 gives distributors the > freedom to make modifications. This is true from a technical point of view, but there are probably other tricks available to get non-GPL modules to load. The whole point of the EXPORT_SYMBOL_GPL thing is more legal than technical. It goes along the lines of "If you use this symbol in non-GPLed code we may sue you". It also won't help if a distributor would remove the block since if they where really sued over a GPL violation, they couldn't distribute the kernel anymore making it hard to stay a linux distributor... The thing I was wondering about is that Linus reserves himself the right to remove such patches, even though he doesn't own the copyright for the piece of code in question in about 99% of all cases. I suppose if a copyright owner was to send Linus such a patch for one of the owner's interfaces, Linus would probably be required to accept it from a legal point of view. (Strictly technically this is not true, of cource, see the first paragraph...)
NDISwrapper dodges another bullet Posted Mar 5, 2008 21:55 UTC (Wed) by drag (subscriber, #31333) [Link] > The thing I was wondering about is that Linus reserves himself the right to remove such patches, He doesn't. If you go and look at the email exchange with him you'll notice that he threatened to banish anybody arguingon any sort of the legal mumbo-jumbo to his ignore file. He was only interested in the interfaces that ndiswrapper used and told people to contact those authors and try to work out a exception if they care about it working.
NDISwrapper dodges another bullet Posted Mar 5, 2008 20:08 UTC (Wed) by iabervon (subscriber, #722) [Link] Unless people are distributing systems that are already booted, I don't think anyone could help but have the end user load the binary driver; I don't think ndiswrapper even supports linking the driver into it ahead of time. And selling the combination is fine with the GPL as mere aggregation, and it's, if anything, better that the nvidia drivers situation as a whole, because the closed code and the open code are separated by clean and generic API. If you modify your kernel, there's no way that this could require changes to the binary driver, since it's not even designed to work with Linux at all. If the GPL's purpose is to prevent non-GPL code rom preventing you from modifying GPL code and then being able to use the system, that's not a concern here for technical reasons, even leaving aside legal ones.
NDISwrapper dodges another bullet Posted Mar 6, 2008 0:25 UTC (Thu) by jengelh (subscriber, #33263) [Link] >Unless people are distributing systems that are already booted, I don't think anyone could help but have the end user load the binary driver; I don't think ndiswrapper even supports linking the driver into it ahead of time. Consider VMware Suspend Images (*.vmss) it is possible to distribute booted systems, and as such, every currently working combination of code. Well, it may already happen that distributing the Windows driver is bound by some license already, so you can possibly save on the time to spend about thinking about distributing linked code.
NDISwrapper dodges another bullet Posted Mar 6, 2008 16:07 UTC (Thu) by iabervon (subscriber, #722) [Link] Doesn't vmware abstract access to network devices anyway? I somehow doubt that a suspend image containing a Linux kernel using a Windows driver to talk to a physical network device would actually have any chance of working at all. And running Linux under vmware with the Windows driver for the vmware simulated network device instead of the Linux driver for it is just silly. In order for this particular issue to be relevant, you'd need to distribute a booted system with a driver loaded for a chipset with only a Windows driver available, which only makes sense if it's running on physical hardware.
NDISwrapper dodges another bullet Posted Mar 6, 2008 17:10 UTC (Thu) by jengelh (subscriber, #33263) [Link] >Doesn't vmware abstract access to network devices anyway? This is independent of providing a linked variant of ndiswrapper IMHO. That said, VMware provides virtual HW that behaves like AMD PCnet32 or Intel E1000; so I could link e1000.drv with ndiswrapper then what? Abstraction does not relate to anything. Imagine we had have kexec from/to VMSS someday then what?
NDISwrapper dodges another bullet Posted Mar 6, 2008 0:33 UTC (Thu) by rahvin (subscriber, #16953) [Link] As I understood how the nVidia driver works, this is exactly the method. There is a GPL'd piece that integrates into the kernel and creates the interface to the binary driver. Just like ndiswrapper works, in fact I thought that the nVidia Linux driver was created because ndiswrapper showed them how to integrate a closed source binary driver into the kernel. I also thought this was one of the reasons certain developers hate ndiswrapper so much, they started the whole trend to the binary blob in the kernel thing.
NDISwrapper dodges another bullet Posted Mar 6, 2008 3:18 UTC (Thu) by proski (subscriber, #104) [Link] I'm not sure about nVidia drivers, but I believe they are compiled specifically for Linux. The free and non-free parts are distributed together by the same entity. I think that's very different from ndiswrapper from the legal standpoint (but IANAL).What I know for sure, is that a non-free driver for Lucent Orinoco cards used such trick, and it predated ndiswrapper. That's why blaming ndiswrapper that it "started the whole trend" would be misleading. Besides, driverloader is older than ndiswrapper, and it does the same thing as ndiswrapper. It's also non-free and was caught lying about its license, something that ndiswrapper never did.
NDISwrapper dodges another bullet Posted Mar 6, 2008 5:39 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] Apparently, the NVIDIA adapter code sets its license to "NVIDIA", so it doesn't get access to GPLONLY symbols. I haven't checked this myself, but I've seen others mention it.
NDISwrapper dodges another bullet Posted Mar 6, 2008 8:37 UTC (Thu) by Los__D (guest, #15263) [Link] You are completely right:$ modinfo nvidia ... license: NVIDIA ...
NDISwrapper dodges another bullet Posted Mar 6, 2008 16:22 UTC (Thu) by iabervon (subscriber, #722) [Link] It's very different in that the binary blobs that NDISwrapper loads were written without knowledge of the Linux kernel, and the binary blob that the nVidia shim code loads were written using knowledge of the Linux kernel as reference. This is much the same difference as that between writing an encyclopedia without having Britannica and writing one while using Britannica. In the latter case, you have to be a lot more careful about a lot of things in order to avoid doing things you shouldn't.
|
|||||||||||||