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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
