from the libertarian newspaper

[Jon Pruente]

On 1/22/07, Luke -Jr <luke at 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.