As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 10:07 UTC (Thu) by morhippo (guest, #334)
Parent article: NDISwrapper dodges another bullet

I don't understand the argument. Ndiswrapper is GPL, the kernel is GPL, clearly they can be
used and distributed freely. You can also USE GPL together with proprietary in any way you
want because the GPL does not contain ANY use restrictions. 
Please check it out and repeat after me: No USE restrictions. Do what you want with GPL and
proprietary (e.g. Nvidia drivers) in your PC.

However, what you may not do is DISTRIBUTE a derived work of GPL and proprietary code, ie you
may not distribute a kernel with Ndiswrapper and proprietary Windows driver. As long as you do
not do that, the restrictions of the GPL do not apply.

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 11:13 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (4 responses)

Perhaps an NDIS-lover should write a GPLed NDIS driver for some old Ethernet NIC for which
sufficient programming information is available. 

We'd then see an assemblage of code, all GPL,  being blocked, or the kernel into which it is
loaded being marked as tainted, as a result of the political goals of people controlling the
export of kernel symbols!

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 12:48 UTC (Thu) by morhippo (guest, #334) [Link]

If you read the discussion on the kernel mailing list, there is mention of such a driver
actually existing.

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 6, 2008 13:01 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

There is a GPL'd NDIS driver - http://cipe-win32.sourceforge.net/ - though it's a port from
Linux so there's little point in using it with ndiswrapper.

Slightly different tack

Posted Mar 6, 2008 13:16 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Maybe there could be broader distribution of reversing kits, making it less painful to get
into collecting packets and writing drivers for legacy hardware.
A problem with NDISwrapper is that it appeals to laziness and doesn't foster new, pure-GPL
development.
Advertizing NDISwrapper as an important infrastructure piece for writing freer drivers could
give it more street cred.
Packaged properly, it could help improve the developer base for the kernel by helping flatten
the learning curve.
And I want a pony.

NDIS drivers in mainline? NEVER

Posted Mar 6, 2008 23:35 UTC (Thu) by hmh (subscriber, #3838) [Link]

Err, it is worth noticing that refusal to merge crap in the kernel happens all the time.
There is no way any NDIS driver would ever be merged, AFAIK, and the reasons for this are
simple:

An NDIS driver would be slower, more difficult to maintain, far more complex (you have to take
into account the entire NDIS wrapper too!), and IMHO just downright nastier to look at than it
would be had it used the native APIs in the first place.

So I am afraid an NDIS-lover will have to find another way to equal himself to the people who
mark symbols GPL-only for political reasons (as opposed to technical reasons).

As long as the proprietary Windows driver ist not DISTRIBUTED...

Posted Mar 7, 2008 16:32 UTC (Fri) by giraffedata (guest, #1954) [Link]

I don't understand the argument.

I believe there are multiple arguments, as there are multiple views of the purpose of GPL_ONLY symbols. But the arguments described in this article aren't arguments about what copyright law or GPL allows -- they're just arguments over how easy the kernel.org kernel should make it to use Windows drivers with Linux. And also how easy it should be to tell that Windows drivers are being used, in a bug report.