Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
NDISwrapper dodges another bulletNDISwrapper dodges another bulletPosted Mar 5, 2008 20:08 UTC (Wed) by iabervon (subscriber, #722)In reply to: NDISwrapper dodges another bullet by JoeBuck Parent article: NDISwrapper dodges another bullet
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.
(Log in to post comments)
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 (subscriber, #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.
|
|
||||||||||||