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
