From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 4/4] kvm: i386: Add classic PCI device assignment Date: Wed, 05 Sep 2012 15:46:28 -0500 Message-ID: <87a9x49p0b.fsf@codemonkey.ws> References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503B62F4.9070500@suse.de> <87k3wjyy0e.fsf@codemonkey.ws> <503E227B.40904@suse.de> <874nndmrjs.fsf@codemonkey.ws> <50476F3E.7000100@redhat.com> <87wr081nq4.fsf@codemonkey.ws> <87zk54l1fd.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Alexey Kardashevskiy , Marcelo Tosatti , qemu-devel@nongnu.org, Alex Williamson , Jan Kiszka , Avi Kivity , qemu-ppc , Andreas =?utf-8?Q?F=C3=A4rber?= To: Blue Swirl Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Blue Swirl writes: > On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori wrote: >> Blue Swirl writes: >> >>> On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori wrote: >>>> Avi Kivity 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). > > It's a tradeoff between reimplementing disassembler without using > binutils vs. reimplementing virtio without using Linux. Both have > their problems and both are growing areas. Disassembler is a bit > smaller and the basic function does not ever change. Since binutils is the project with a copyright controlled by a single entity that decided to change their license such that it was no longer compatible with QEMU, as far as I'm concerned, it's a no brainer. We should care more about working with projects that are willing to cooperate with us. What do we do when the FSF comes out with the GPLv4 and relicenses again in an incompatible fashion? Do we do this exercise every couple of years? >> Yes, the GPLv3 sucks and FSF screwed up massively not making it v2 >> compatible. > > I sort of agree. They had their reasons, of course. Too bad binutils > licensing is fully controlled by FSF, for us it would be enough if > they had some sort of dual licensing scheme (GPLv3 + BSD for example) > in place. I think it's clear that FSF controlled projects are not good places to try to share code with... Regards, Anthony Liguori > >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MUe-0001KF-9N for qemu-devel@nongnu.org; Wed, 05 Sep 2012 16:46:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9MUb-0003qK-PX for qemu-devel@nongnu.org; Wed, 05 Sep 2012 16:46:36 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:34096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9MUb-0003pu-Ir for qemu-devel@nongnu.org; Wed, 05 Sep 2012 16:46:33 -0400 Received: by obbta14 with SMTP id ta14so970751obb.4 for ; Wed, 05 Sep 2012 13:46:32 -0700 (PDT) From: Anthony Liguori In-Reply-To: References: <825e653c9cfe9d8e26185917cbe1f1dd7ae299e2.1346048917.git.jan.kiszka@web.de> <503B62F4.9070500@suse.de> <87k3wjyy0e.fsf@codemonkey.ws> <503E227B.40904@suse.de> <874nndmrjs.fsf@codemonkey.ws> <50476F3E.7000100@redhat.com> <87wr081nq4.fsf@codemonkey.ws> <87zk54l1fd.fsf@codemonkey.ws> Date: Wed, 05 Sep 2012 15:46:28 -0500 Message-ID: <87a9x49p0b.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Qemu-devel] [PATCH 4/4] kvm: i386: Add classic PCI device assignment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: kvm@vger.kernel.org, "Michael S. Tsirkin" , Alexey Kardashevskiy , Marcelo Tosatti , qemu-devel@nongnu.org, Alex Williamson , Jan Kiszka , Avi Kivity , qemu-ppc , Andreas =?utf-8?Q?F=C3=A4rber?= Blue Swirl writes: > On Wed, Sep 5, 2012 at 7:22 PM, Anthony Liguori wrote: >> Blue Swirl writes: >> >>> On Wed, Sep 5, 2012 at 3:41 PM, Anthony Liguori wrote: >>>> Avi Kivity 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). > > It's a tradeoff between reimplementing disassembler without using > binutils vs. reimplementing virtio without using Linux. Both have > their problems and both are growing areas. Disassembler is a bit > smaller and the basic function does not ever change. Since binutils is the project with a copyright controlled by a single entity that decided to change their license such that it was no longer compatible with QEMU, as far as I'm concerned, it's a no brainer. We should care more about working with projects that are willing to cooperate with us. What do we do when the FSF comes out with the GPLv4 and relicenses again in an incompatible fashion? Do we do this exercise every couple of years? >> Yes, the GPLv3 sucks and FSF screwed up massively not making it v2 >> compatible. > > I sort of agree. They had their reasons, of course. Too bad binutils > licensing is fully controlled by FSF, for us it would be enough if > they had some sort of dual licensing scheme (GPLv3 + BSD for example) > in place. I think it's clear that FSF controlled projects are not good places to try to share code with... Regards, Anthony Liguori > >> >> 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