Licensing? Was: Removing Optical Boot Requirement from F20 Alpha Release Requirements

[Eric Blake]

On 09/19/2013 03:53 PM, Chris Murphy wrote:
> 
> On Sep 19, 2013, at 8:56 AM, Eric Blake <eblake at redhat.com> wrote:
>>
>> Given the current state of the art, all known UEFI implementations for
>> VMs require the use of a FAT driver whose license forbids redistribution
>> for general purpose use, which means Fedora cannot ship it. 
> 
> I don't understand this. 
> 
> First, there is already a FAT driver that works out of the box in Fedora for general purpose use. 

The kernel FAT driver is GPL.  But state of the art for UEFI is the OVMF
code base, which is mostly BSD, but contains a non-open FAT driver.
Meanwhile, the OVMF folks have explicitly stated they are unwilling to
incorporate GPL code (which would make their entire project GPL, and cut
them off from proprietary vendors that currently rely on the looseness
of BSD licensing).  So far, no one has forked the open portions of OVMF
to mix in an alternative FAT module (such as providing a GPL UEFI
solution by reusing the kernel's fat driver), and as no other VM boot
loader code understands UEFI (Fedora ships SeaBIOS, but that is BIOS not
UEFI), then there is currently no way to boot a VM under UEFI while
still being able to distribute that loader in Fedora.

> 
> And second, the UEFI spec in section 12.3 considers the EFI file system to be distinct from, although based on, FAT. And the spec includes long file name support, using UCS-2 encoding. Microsoft only have patent claims on FAT that relate to long file names. This is in effect not Microsoft's FAT, but rather an EFI file system maintained by the UEFI spec and is unchanging from Microsoft FAT variants.
> 
> We probably ought to have a mkfs variant for ESP's to ensure it's created per the UEFI spec and is guaranteed to not evolve with mkdosfs|mkfs.msdos|mkfs.vfat.

What the kernel FAT drivers do is independent of what a VM loader has to
be able to do to emulate UEFI to the guest.  Although you are probably
right that the kernel folks should take care that their UEFI
interactions don't break, that is independent of the licensing issue at
hand for VM booting.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/test/attachments/20130919/e7381132/attachment.sig>