Re: [Qemu-devel] why is kqemu closed?

[Paul Brook]

> I think that you are missing the point.  He's not saying that you have
> to distribute the source (which is what that exemption is about).
> He's saying that the license on a mere library cannot and should not
> force applications linked with that library to become a derived work.
> And he's right about that being a dangerous precident.  If I call
> write(2) in my application, the mere fact that the kernel is GPL'd
> shouldn't matter for the license of my application.  It is not a
> derived work.

Well, the whole point of the GPL is that you have to provide sufficient 
sources for the user to be able to regenerate your binary. If your 
application includes closed-source code then by definition you've broken that 
requirement.

> The circumlocutions that some people go through to try to show that
> somehow using internal kernel interfaces make something a derived work
> do border on the absurd and are a very agressive interpretation of
> what makes a work a derived work.  That interpretation needs to be
> curbed, otherwise we'd have a slipperly slope where libc becomes GPL'd
> and merely linking against it once and providing that binary infects
> the application with the GPL (a position that no court has endorced).

You can't legally distribute a GPL application linked against a closed-source 
library. In the same way you can't distribute a GPL library as part of a 
closed source application.
Libraries (eg. glibc) that want to allow linking with proprietary code have 
LGPL or additional licence exceptions to permit this.
I'd guess linking against the system libc is reasonably covered by the 
exception I quoted. Linking against 3rd party libc probably isn't, which IMHO 
is prefectly reasonably. Otherwise a proprietary product could just take GPL 
code, modify it and put all the interesting proprietary bits in a library 
called libc.so.

If the GPL doesn't cover linking against libraries then it's effectively 
useless for its stated purpose.

Paul