From mboxrd@z Thu Jan  1 00:00:00 1970
From: Laszlo Ersek <lersek@redhat.com>
Subject: Re: KVM call agenda for 2013-05-28
Date: Fri, 31 May 2013 16:28:26 +0200
Message-ID: <51A8B38A.6010109@redhat.com>
References: <20130523124132.GA18596@redhat.com>
	<20130528235309.GA31648@morn.localdomain>
	<20130531023426.GB18156@morn.localdomain>
	<CAFe8ug--stQH7KW7Bzy7+eSsZ5W-9T4PtU7xpOfsozAd9kt5vA@mail.gmail.com>
	<51A88D73.1090302@redhat.com> <87bo7rmhbp.fsf@codemonkey.ws>
	<1370009305.5141.95.camel@i7.infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>, seabios@seabios.org,
	qemu-devel qemu-devel <qemu-devel@nongnu.org>,
	Kevin O'Connor <kevin@koconnor.net>, ddutile@redhat.com,
	Anthony Liguori <anthony@codemonkey.ws>, Jordan Justen <jljusten@gmail.com>
To: David Woodhouse <dwmw2@infradead.org>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
In-Reply-To: <1370009305.5141.95.camel@i7.infradead.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=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

On 05/31/13 16:08, David Woodhouse wrote:
> On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
>>
>> <soapbox>
>>
>> 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