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.
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¹ or LGPL implementation of a FAT module 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... :))
¹ If it's GPL, of course, then we mustn't include any *other* binary 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