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

[Anthony Liguori]

Blue Swirl <address@hidden> writes:

> On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori <address@hidden> wrote:
>> Avi Kivity <address@hidden> writes:
>>
>>> On 09/05/2012 12:00 AM, Anthony Liguori wrote:
>>>>>
>>>>> Why? The way this is being submitted I don't see why we should treat
>>>>> Jan's patch any different from a patch by IBM or Samsung where we've
>>>>> asked folks to fix the license to comply with what I thought was our new
>>>>> policy (it does not even contain a from-x-on-GPLv2+ notice).
>>>>
>>>> Asking is one thing.  Requiring is another.
>>>>
>>>> I would prefer that people submitted GPLv2+, but I don't think it should
>>>> be a hard requirement.  It means, among other things, that we cannot
>>>> accept most code that originates from the Linux kernel.
>>>
>>> We could extend this to "require unless there is a reason to grant an
>>> exception" if we wanted to (not saying I know whether we want to or
>>> not).
>>
>> I don't want QEMU to be GPLv3.  I don't like the terms of the GPLv3.
>>
>> 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.

But we can't share code with Linux (like for virtio).

Yes, the GPLv3 sucks and FSF screwed up massively not making it v2
compatible.

Regards,

Anthony Liguori

>
>>
>> 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.
>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>>
>>> --
>>> error compiling committee.c: too many arguments to function