[SeaBIOS] [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Laszlo Ersek
lersek at redhat.com
Sun Jun 16 12:00:46 CEST 2013
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
More information about the SeaBIOS
mailing list