qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignmen


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment
Date: Wed, 5 Sep 2012 19:43:29 +0000

On Wed, Sep 5, 2012 at 7:24 PM, Eric Blake <address@hidden> wrote:
> On 09/05/2012 01:04 PM, Blue Swirl wrote:
>>> I don't mind GPLv2+, if people want to share code from QEMU in GPLv3
>>> projects, GPLv2+ enables that.
>>
>> The advantage of 100% GPLv2+ (or other GPLv3 compatible) would be that
>> QEMU could share code from GPLv3 projects, specifically latest
>> binutils. Reinventing a disassembler for ever growing x86 assembly is
>> no fun.
>
> Not quite right.
>
> If qemu is 100% GPLv2+ and binutils is GPLv3+, then binutils can borrow
> code from qemu and the result is that binutils is still GPLv3+; but in
> the converse direction, if qemu borrows code from binutils then qemu is
> no longer 100% GPLv2+ but becomes GPLv3+ by tainting.

I don't see how this disagrees with what I wrote. GPLv2+ QEMU sharing
code from GPLv3 would of course become GPLv3.

>
> That is, requesting GPLv2+ allows qemu code to be reused elsewhere, but
> does not help qemu import external code that is not already GPLv2+.

Unless we demanded relicensing to GPLv2+ for all GPLv2 QEMU code and
forbid new GPLv2 entries.

>
>>
>>>
>>> But if new code is coming in and happens to be under GPLv2, that just
>>> means that the contribution cannot be used outside of QEMU in a GPLv3
>>> project.  That's fine and that's a decision for the submitter to make.
>>
>> This policy means that we are locked in with GPLv2.
>
> I'm afraid we're already locked at GPLv2 (and not GPLv2+), for good or
> for bad.
>
> --
> Eric Blake   address@hidden    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]