From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FTLIK-0002GW-IA for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:00:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FTLIJ-0002Ft-Qh for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:00:44 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FTLII-0002Fm-En for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:00:43 -0400 Received: from [65.74.133.6] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FTLNB-0003xh-QS for qemu-devel@nongnu.org; Tue, 11 Apr 2006 12:05:46 -0400 From: Paul Brook Subject: Re: [Qemu-devel] why is kqemu closed? Date: Tue, 11 Apr 2006 17:00:38 +0100 References: <443B32A6.20501@foo-projects.org> <200604111636.25101.paul@codesourcery.com> <20060411.094301.57440985.imp@bsdimp.com> In-Reply-To: <20060411.094301.57440985.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200604111700.38801.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > 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=20 sources for the user to be able to regenerate your binary. If your=20 application includes closed-source code then by definition you've broken th= at=20 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. =A0That 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-sour= ce=20 library. In the same way you can't distribute a GPL library as part of a=20 closed source application. Libraries (eg. glibc) that want to allow linking with proprietary code have= =20 LGPL or additional licence exceptions to permit this. I'd guess linking against the system libc is reasonably covered by the=20 exception I quoted. Linking against 3rd party libc probably isn't, which IM= HO=20 is prefectly reasonably. Otherwise a proprietary product could just take GP= L=20 code, modify it and put all the interesting proprietary bits in a library=20 called libc.so. If the GPL doesn't cover linking against libraries then it's effectively=20 useless for its stated purpose. Paul