On Monday 22 January 2007 16:51, Jon Pruente wrote:
On 1/22/07, Luke -Jr [email protected] wrote:
Using an internal GPL'd API, it does.
The question is what do you mean by use? This is where I lose track from what most people seem to write about it. Use, as in taking the API code and using it and modifiying it in the driver, or using the code as in making API calls to it?
Both.
ndiswrapper is in a grey area since, at least in theory, a GPL-compatible NDIS driver exists.
But, that GPL compatible NDIS driver ends up executing closed code, thus it's whole purpose.
No it doesn't. I mean the driver itself, not the binding.
WINE is not GPL'd, but even if it were, it would be a similar situation to ndiswrapper-- "GPL'd" software does exist built on the Win32 API.
For WINE to function it must make calls into all sorts of areas of GPL code.
Not quite.
How is it different to have a graphics routine call from a Win32 program be redirected to a GPL video driver, or even have a Win32 program make a transfer through the network of the host Linux system than it is for nVidia or ATI to make drivers that take input from GPL code to display on their hardware? All have to interact with a GPL API at some point. Where do we draw the line? Making calls to the API is one thing. Building in the actual code to the API is another. That's the distinction I've been pointing out. Modifying code is different than pointing data streams and variable values at locations used by code under the GPL.
Linux specifically excludes userland from the GPL obligations. Even if it did not, the code itself is not technically linking to Linux until runtime if it has the potential to link against something else (for example, BSD) unmodified.