[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support

From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Date: Fri, 14 Jun 2013 02:26:31 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6

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




    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

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?)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]