from the libertarian newspaper

Luke-Jr luke at dashjr.org
Mon Jan 22 19:31:40 CST 2007


On Tuesday 23 January 2007 00:31, Jon Pruente wrote:
> 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.

1) Linux isn't a microkernel. Linux is monolithic. It is a single program. 
Modules are part of the program that can be disabled or loaded at runtime.
2) The GPL terms apply to Linux and any Linux-specific APIs that are not 
deemed userland (as userland has a specific exception). Anyone 
copying/deriving from the internal API must legally abide by its copyright.

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

Code that is/becomes part of Linux is clearly not userspace.

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

DRM is illegitimate use of an encryption chip. Illegit use cannot have some 
legit use.

>  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 would be DRM just as much as GPL is copyright. It's abusing copyright/DRM 
to reverse its effect.

> > > 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,

Kernel modules are always derived works, and there is no exceptions for them 
in any form.

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

Irrelevant. Their wrapper would need to work against a 
GPL-compatible "blob-piece" in order for it to be valid. For example, if they 
released the code to a stripped down blob, they might get into the grey-area.


More information about the Kclug mailing list