Blue Swirl <blauwirbel@xxxxxxxxx> writes: > On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote: >> Avi Kivity <avi@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
