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