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

[Laszlo Ersek]

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