[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: Sun, 16 Jun 2013 12:00:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6

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.


reply via email to

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