On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori <anth...@codemonkey.ws> wrote: > Avi Kivity <a...@redhat.com> 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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
