On Wed, Sep 5, 2012 at 7:24 PM, Eric Blake <ebl...@redhat.com> 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 ebl...@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- 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
