From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59657) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiQHv-0001OV-Ir for qemu-devel@nongnu.org; Fri, 31 May 2013 10:26:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UiQHo-0007ae-Ur for qemu-devel@nongnu.org; Fri, 31 May 2013 10:26:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UiQHo-0007aX-Kz for qemu-devel@nongnu.org; Fri, 31 May 2013 10:26:32 -0400 Message-ID: <51A8B38A.6010109@redhat.com> Date: Fri, 31 May 2013 16:28:26 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <20130531023426.GB18156@morn.localdomain> <51A88D73.1090302@redhat.com> <87bo7rmhbp.fsf@codemonkey.ws> <1370009305.5141.95.camel@i7.infradead.org> In-Reply-To: <1370009305.5141.95.camel@i7.infradead.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for 2013-05-28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Woodhouse Cc: "Michael S. Tsirkin" , KVM devel mailing list , Juan Quintela , seabios@seabios.org, qemu-devel qemu-devel , Kevin O'Connor , ddutile@redhat.com, Anthony Liguori , Jordan Justen On 05/31/13 16:08, David Woodhouse wrote: > On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote: >> >> >> >> Fork OVMF, drop the fat module, and just add GPL code. It's an easily >> solvable problem. >=20 > Heh. Actually it doesn't need to be a fork. It's modular, and the FAT > driver is just a single module. Which is actually included in *binary* > form in the EDK2 repository, I believe, and its source code is > elsewhere. Correct. > We could happily make a GPL=C2=B9 or LGPL implementation of a FAT modul= e and > build our OVMF with that instead, and we wouldn't need to fork OVMF at > all. Yes, that's one plan, *if* someone can sort out, or is willing to shoulder, the perhaps illogical but still worrisome surroundings of FatPkg / FatBinPkg. (I don't intend to spread FUD!) For example, if your employer authorizes you to implement GplFatPkg from scratch, and distribute it as an external module, I -- as someone without any education in law though -- will give you a standing ovation and buy you a case of beer at KVM Forum 2013. Deal? :) (You proved to have great leverage by getting the efi compat table extended, so... :)) > =C2=B9 If it's GPL, of course, then we mustn't include any *other* bina= ry > blobs in our OVMF build. But the whole point in this conversation is > that we don't *want* to do that. So that's fine. Right. Eg. Shell1 is embedded as a pre-built binary, but that's just "convenience", you can build the in-tree Shell2 from source afresh and embed that instead (and ship its source too). Laszlo