From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpjKz-0006P0-Gy for qemu-devel@nongnu.org; Fri, 13 Jul 2012 13:07:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpjKx-00044l-Vr for qemu-devel@nongnu.org; Fri, 13 Jul 2012 13:07:29 -0400 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:36296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpjKx-00043a-Pt for qemu-devel@nongnu.org; Fri, 13 Jul 2012 13:07:27 -0400 Message-ID: <500055CB.4080502@weilnetz.de> Date: Fri, 13 Jul 2012 19:07:23 +0200 From: Stefan Weil MIME-Version: 1.0 References: <4FFA9C30.2070201@linux.vnet.ibm.com> <4FFAA0C3.3080703@redhat.com> <4FFBB7FB.3070303@linux.vnet.ibm.com> <4FFBD6F1.90403@redhat.com> <20120713091611.GC15503@stefanha-thinkpad.localdomain> <4FFFEF8E.5080705@redhat.com> <50000793.2020401@redhat.com> In-Reply-To: <50000793.2020401@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Anthony Liguori , Stefan Hajnoczi , Michael Tokarev , =?UTF-8?B?TGx1w61z?= , qemu-devel@nongnu.org, Blue Swirl , Hannes Reinecke , Wenchao Xia Am 13.07.2012 13:33, schrieb Paolo Bonzini: > Il 13/07/2012 11:51, Paolo Bonzini ha scritto: >> Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto: >>>> "Working around the QEMU block layer license" is not a goal per se, >>>> especially because you haven't a) assessed _what_ is the GPL code that >>>> the library would use; b) told us why the library should not be under >>>> the GPL. >>>> >>>> Please design first according to the functionality you want to >>>> implement, then think about the implementation. >>> >>> Licensing is one headache but the real challenge is that the QEMU block >>> layer relies on the QEMU main loop and a bunch of other architecture. >> >> It doesn't really, not on Windows which has no AIO for example. That's >> why I suggested: >> >> - assessing what code is GPL and what are the dependencies on it > > So I tried trimming down the list of files needed to compile > qemu tools, and here is a list: > > Easy to relicense to LGPLv2+: > block/raw.c none (GPLv2+: Red Hat, IBM) > error.c LGPLv2 (Red Hat, IBM, Stefan Weil) I only added an include statement and don't mind changing the license for error.c to LGPLv2+. > > iov.c GPLv2 (Red Hat, SuSE/Hannes Reinecke, Michael Tokarev) > module.c GPLv2 (Red Hat, IBM, Blue Swirl) > qemu-error.c GPLv2+ (Red Hat, Blue Swirl, IBM) > trace/control.c GPLv2 (Lluis Vilanova) > trace/default.c GPLv2 (Lluis Vilanova) > > (I added some people to Cc. Lluis and Michael, can you also look at > http://wiki.qemu.org/Relicensing if you're willing to relicense > your past contributions from GPLv2 to GPLv2+?. Blue Swirl said > he'd accept any other GPLv2 or GPLv3 compatible license, which > should include LGPLv2+). > > Harder to relicense to LGPLv2+: > block/vdi.c GPLv2+ Indeed, that one is harder. Most of the code is from me, and I need a good reason why the license should be changed. Of course the dynamic library can also be compiled without VDI support. Regards, Stefan W.