From: Laszlo Ersek <lersek@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
seabios@seabios.org, qemu-devel <qemu-devel@nongnu.org>,
Kevin O'Connor <kevin@koconnor.net>,
Gerd Hoffmann <kraxel@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
Jordan Justen <jljusten@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support
Date: Fri, 14 Jun 2013 02:26:31 +0200 [thread overview]
Message-ID: <51BA6337.20208@redhat.com> (raw)
In-Reply-To: <51BA4F6C.5070902@redhat.com>
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
next prev parent reply other threads:[~2013-06-14 0:24 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-10 16:41 [Qemu-devel] [PATCH] qemu: piix: PCI bridge ACPI hotplug support Michael S. Tsirkin
2013-06-10 18:58 ` Anthony Liguori
2013-06-10 19:17 ` Peter Maydell
2013-06-10 19:50 ` Anthony Liguori
2013-06-10 19:43 ` Laszlo Ersek
2013-06-10 19:57 ` Anthony Liguori
2013-06-10 20:43 ` Laszlo Ersek
2013-06-10 21:14 ` Laszlo Ersek
2013-06-10 21:45 ` Anthony Liguori
2013-06-10 23:05 ` Kevin O'Connor
2013-06-10 23:34 ` Anthony Liguori
2013-06-10 23:52 ` David Woodhouse
2013-06-11 0:11 ` Anthony Liguori
2013-06-11 14:11 ` David Woodhouse
2013-06-11 0:23 ` Kevin O'Connor
2013-06-11 0:51 ` Anthony Liguori
2013-06-11 1:19 ` Kevin O'Connor
2013-06-11 1:25 ` Anthony Liguori
2013-06-11 1:49 ` Kevin O'Connor
2013-06-11 6:49 ` Michael S. Tsirkin
2013-06-11 0:28 ` Jordan Justen
2013-06-11 1:03 ` Anthony Liguori
2013-06-11 1:32 ` Jordan Justen
2013-06-11 7:35 ` Michael S. Tsirkin
2013-06-13 23:05 ` Paolo Bonzini
2013-06-14 0:59 ` Anthony Liguori
2013-06-14 1:23 ` [Qemu-devel] [SeaBIOS] " Peter Stuge
2013-06-11 14:04 ` David Woodhouse
2013-06-13 23:02 ` [Qemu-devel] " Paolo Bonzini
2013-06-14 0:26 ` Laszlo Ersek [this message]
2013-06-16 10:00 ` Laszlo Ersek
2013-06-11 5:22 ` Michael S. Tsirkin
2013-06-11 5:33 ` Gerd Hoffmann
2013-06-11 6:55 ` Michael S. Tsirkin
2013-06-11 7:42 ` Gerd Hoffmann
2013-06-11 7:53 ` Michael S. Tsirkin
2013-06-11 8:00 ` Gerd Hoffmann
2013-06-11 8:18 ` Michael S. Tsirkin
2013-06-11 8:27 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51BA6337.20208@redhat.com \
--to=lersek@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=dwmw2@infradead.org \
--cc=jljusten@gmail.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).