From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56981) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uo9jf-0003jy-DK for qemu-devel@nongnu.org; Sun, 16 Jun 2013 05:59:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uo9jc-0007BP-9b for qemu-devel@nongnu.org; Sun, 16 Jun 2013 05:58:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1710) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uo9jc-0007B6-30 for qemu-devel@nongnu.org; Sun, 16 Jun 2013 05:58:56 -0400 Message-ID: <51BD8CCE.6050901@redhat.com> Date: Sun, 16 Jun 2013 12:00:46 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1370882347-31129-1-git-send-email-mst@redhat.com> <87r4g9rdwe.fsf@codemonkey.ws> <51B62C48.5060303@redhat.com> <87ehc920ym.fsf@codemonkey.ws> <51B63A74.1030905@redhat.com> <87mwqxzlke.fsf@codemonkey.ws> <51BA4F6C.5070902@redhat.com> <51BA6337.20208@redhat.com> In-Reply-To: <51BA6337.20208@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Peter Maydell , "Michael S. Tsirkin" , Jordan Justen , seabios@seabios.org, qemu-devel , Kevin O'Connor , Gerd Hoffmann , Anthony Liguori , David Woodhouse On 06/14/13 02:26, Laszlo Ersek wrote: > On 06/14/13 01:02, Paolo Bonzini wrote: >> Il 10/06/2013 21:03, Anthony Liguori ha scritto: >>>>> I'm not really convinced that >>>>> QEMU<->firmware is a GPL boundary because of how tightly the two are >>>>> linked. >>>> >>>> Where has 'linked' in terms of the GPL ever been anything other than >>>> actual executable linking? >>> >>> I should not have even brought this up as it's not worth debating. If >>> you're curious, http://www.gnu.org/licenses/gpl-faq.html#MereAggregation >> >> With the usual IANAL care, I think QOM would be much much more of a >> legal grey area that passing ACPI tables. >> >> If you pass ACPI tables, the ACPI tables are clearly part of QEMU, and >> are almost as clearly "just data" for the BIOS. >> >> But if you use QOM, you may start wondering if "the semantics of the >> communication are intimate enough, exchanging complex internal data >> structures". Probably not, as it is a generic interface and there could >> be in principle other consumers than the firmware, but still complex >> enough that raising the issue is not moot. > > Basing the decision about > > derivative or not > > on > > internal > > or > > complex enough > > ; well I find that unusable. > > First, complexity: web services can use very complex XML schemas, and > that clearly doesn't make the server derivative of the client, or vice > versa. > > Second, internality: this attribute can be wiped out simply by writing > documentation for the data structure (which should be done *anyway*). > Once it is documented, it is not internal any longer. However existence > of documentation for a wire format between A and B should have > absolutely no say in whether codebase A is derivative of codebase B. > > IANAL of course but I find the FSF's argument biased. > > (Of course I'm also not buying that linking against a library makes the > client application (its own source code, or its dynamically linked > binary) derivative of the library. If there are two libraries > (especially when released under different licenses) implementing the > same API, which one is the application a derivative of?) This is my personal, private opinion, of course, which is independent of what my employer holds. Laszlo