In message: <[EMAIL PROTECTED]>
Paul Brook <[EMAIL PROTECTED]> writes:
: > 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 problem with that belief is that it might not be what the law
requires. The GPL cannot be used to force users that do not create
derived works to do anything. The entire power of the GPL is based in
copyright law. Copyright law is about verbatim copies and creating
derived works. Anything outside of these activities, the GPL cannot
regulate. One of the reasons for the "OS Exception" is because no
other license tries to dictate which license to use when you link with
OS compoents. It merely recongizes common practice in the industry
that says linking against libc doesn't create a derived work.
: > 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.
Acutally, closed-source vs open-source isn't the issue. The issue is
GPL compatible or not GPL compatible. There are many libraries that
the source is available for which do not meet this definition. Were
it not for the OS exception, you couldn't use GPL'd products on
systems whose libc wasn't released under the GPL, or a compatible
license. You couldn't have gcc on Solaris, becuase libc on solaris is
closed-source. You couldn't have gcc on FreeBSD because FreeBSD's
libc has files in it which contain the advertising clause.
: In the same way you can't distribute a GPL
: library as part of a closed source application.
This is true, with the same caveat. It isn't just closed-source
applications, but rather everything has to be compatible with the
GPL. GPL'd libraries are difficult to use. There's also some
ambiguity in this statement, because one could have a shared library
based on non-GPL'd technology with the same ABI as the GPL'd one. In
those cases, it is hard to argue that linking dynamically against one
or the other creates a derived work. The whole issue hinges on what
is a derive work, and as I've stated before, that's an area of the law
that's not well defined when it comes to thinks like the GPL.
: Libraries
: (eg. glibc) that want to allow linking with proprietary code have
: LGPL or additional licence exceptions to permit this.
Alternatively, their license can be written not to need a special
exception.
: I'd guess
: linking against the system libc is reasonably covered by the
: exception I quoted.
The exception that you quoted says I don't have to provide source for
libc and other system libraries that a user may be reasonably expected
to have in binary format. The purpose of the GPL is so that people
can make changes to the application, and have all the parts needed to
rebuild the application.
: 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.
Linking against a 3rd party libc is perfectly acceptible, depending on
how it is done. Static linking likely isn't OK unless that 3rd party
libc is available to others. Dynamic linking almost certainly is. If
one has a drop-in replacement for libc.so, say, then one can certainly
use that drop-in replacement. The trickier legal issues arise when
one tries to define what exactly is an OS, and how are OS vendors.
Merely calling something libc.so doesn't make it part of the OS, so
you are right about that.
: If the GPL doesn't cover linking against libraries then it's effectively
: useless for its stated purpose.
The coverage isn't as absolute as you might think. It all hinges on
what is a derived work. Does calling a kernel that's GPL'd make
something a drived work. Why is the kernel different than a userland
library that's GPL'd from a copyright perspective? That's what we're
talking about with kqemu: it is part of the kernel because it is
linked in at run-time. Yet does that create a derived work? Some say
yes, and some say now. Which brings us back to my original statement
earlier in this thread "lots of people have opinions, there's very
little court precident to help us decide who is right."
Anyway, enough about abstract legal theory. The bottom line is that
distributing a binary kqemu is OK.
Warner
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
