On 1/22/07, Luke -Jr luke@dashjr.org wrote:
Linus is wrong. He's not the only copyright holder, either.
Be that as it may, he still has no say over GPL code in userland. But, you also did post that "Linux specifically excludes userland from the GPL obligations." So, if it is stated that the userland is not bound and it must make calls to GPL APIs to talk to the kernel, then why aren't modules that make calls to GPL APIs in the kernel clear too? From what I've read they should be treated the same, which ever way is chosen.
No, it translates them into libc and X11 API calls, in addition to implementing the Win32 API that has no libc/X11 equivalent.
I sit corrected here.
Much of the Linux API is GPL code. I'm sure we all know that. The userspace exception applies to the kernel, not GPL components running on top of the kernel.
Linux *is* the kernel. libc is not Linux, and is a standard API with multiple implementations. GNU libc is LGPL, not GPL. Your claim is without basis.
There is more in a distro than libc for software to talk to. Even so, it still boils down to the userspace exception. It still isn't clear, in terms of the license, if the userspace is really clear. AFAICT it's not. Programs must talk to the GPL kernel at some point and the argument is that the ability to talk (using header files, and possible macros and inline functions) is necessary to run. It seems to me that programmers who write a header and include macros and inline functions have created a chicken-and-egg situation. You can't talk to the code without bringing GPL code into the object file, but you can't get that code removed without having to include the modified source of that header with the GPL and all. I'd think the clearest way is to clean up the code to remove those parts (if possible, move them out the the header) and include those changed files as appropriate under the GPL. Then, the compiled source wouldn't include GPL code in the object. Of course the modification would have to be done seperately and I'm not sure about "avoiding loopholes" in doing it this way.
You're still missing the point that there is a legitimate use of WINE when the program running is GPL-compatible. For example, VirtualDub. VirtualDub is GPL, running with WINE's LGPL API, running on glibc (LGPL) and X11 (compatible). Everything here is linking happily.
But, I never said there wasn't a legitimate use. We can take this argument to where DRM is ok because it does have some legitimate uses. There's that whole related debate over if teh kernel should actively block non-GPL code, which would be a form of DRM in itself.
It also makes "tolerable" exceptions for kernel modules.
It doesn't, never has, and never will (legal impossibility).
I guess the "exceptions" part is at issue. Kernel modules that are not derived works are allowed, but I'm still wondering if the translation layer between closed code and the GPL is supposed to be open. Without seeing the nVidia source we don't know if they are going straight for the kernel API with new code, or if they are merely fine tuning an abstraction/translation layer to an existing driver.
Jon.