NDISwrapper dodges another bullet

Posted 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.

Sauce

Posted Mar 5, 2008 19:08 UTC (Wed) by ncm (guest, #165) [Link] (1 responses)

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 (guest, #2883) [Link] (1 responses)

> 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 (guest, #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] (8 responses)

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 (guest, #33263) [Link] (2 responses)

>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] (1 responses)

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 (guest, #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 (guest, #16953) [Link] (4 responses)

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 (guest, #5246) [Link] (1 responses)

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.