Hi Jordan,
On Mon, Jun 10, 2013 at 7:28 PM, Jordan Justen jljusten@gmail.com wrote:
On Mon, Jun 10, 2013 at 2:45 PM, Anthony Liguori anthony@codemonkey.ws wrote:
OVMF is proprietary.
I don't agree that not-OSI means proprietary.
I call it blue if that makes you all feel better :-) But no matter what the word we use it, the point still stands, we need a UEFI firmware that has a OSI-approved license. Forgetting everything else, the distros can't ship OVMF in its current form.
I agree that the FAT driver is not 'free software' and I agree that is a problem for usage with free software projects, such as QEMU. This is a big deal, but unfortunately, as an Intel employee, I think I've done as much as I can to address this.
It couldn't hurt if more people that actually care about this spoke up on edk2-devel about the issue, or perhaps within a UEFI working group. Because, I know that they've stopped listening to me about it.
Is this useful? I can try to make noise. I assume since folks like you who have much more credibility and familiarity in this space have given up, it's a lost cause.
It is not "supported" by QEMU.
No, but I've always thought that QEMU was happy to have alternative firmware projects.
We are and we're happy to accept patches to enable things even if its proprietary. But that's all assuming we're improving hardware emulation.
What we're talking about here is doing something that's very un-hardware like.
I'm not really convinced that QEMU<->firmware is a GPL boundary because of how tightly the two are linked.
Where has 'linked' in terms of the GPL ever been anything other than actual executable linking?
I should not have even brought this up as it's not worth debating. If you're curious, http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
Moving large chunks of firmware code into QEMU just to avoid solving licensing issues is a non-starter with me.
Is this a licensing issue? I thought this was a "let's save time by doing it in one place" thing. I'm pretty ambivalent about this feature, really. I don't think it is even worth all this bickering.
I'm certain OVMF has ACPI issues on QEMU, but I don't think it is a huge deal to resolve them independently of this feature.
Doing it one place could just mean share code. Code can't be shared today, that's why licensing has come up.
Regards,
Anthony Liguori
I was not a huge fan of supporting this type of thing for Xen in OVMF, but it does seem to work fine.
-Jordan