Re: [SeaBIOS] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
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. Paolo
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?) Laszlo
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
participants (2)
-
Laszlo Ersek -
Paolo Bonzini