Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Alexander Graf <agraf@xxxxxxx>]

> Am 10.09.2015 um 14:17 schrieb Andrew Fish <afish@xxxxxxxxx>:
> 
> 
>> On Sep 10, 2015, at 4:40 AM, Alexander Graf <agraf@xxxxxxx> wrote:
>> 
>> 
>> 
>>> On 10.09.15 12:04, Laszlo Ersek wrote:
>>>> On 09/10/15 08:19, Alexander Graf wrote:
>>>> 
>>>> 
>>>>> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.justen@xxxxxxxxx>:
>>> 
>>>>> Laszlo's email raised the GPL question, but I was not sure what the
>>>>> EDK II community would accept with regards to GPL. Thus ... I asked. I
>>>>> guess I'm getting a better idea with regards to Apple and HP. :)
>>>>> 
>>>>> In your opinion, would we be able to discuss patches for a *separate*
>>>>> repo with GplDriverPkg on edk2-devel?
>>>> 
>>>> In fact, could we just make the non-free FAT source and GPL FAT
>>>> source both be git submodules?
>>> 
>>> We've discussed submodules in the past (for other purposes). The
>>> consensus seemed to be that most people dislike them (me included).
>>> 
>>> UEFI drivers are supposed to be modular / well separable (for one, they
>>> can be shipped by third parties in binary-only form; which was a design
>>> goal of UEFI). And specifically in the FAT driver's case, the source
>>> doesn't even live inside the main repo at the moment, so turning it into
>>> a source submodule might not be a step back.
>>> 
>>> But... I just don't like it. We should be moving towards a grand unified
>>> repo, where cross-module changes and dependencies are possible to
>>> implement with carefully segmented patch sets. The FAT driver's source
>>> lives outside for non-technical reasons. Rather than codifying that
>>> situation forever with a git submodule, I'd prefer some solution that
>>> leaves us with a standalone repo.
>>> 
>>> I think I'm fuzzy on the details of the earlier git-submodule
>>> discussion. In any case here's the link (I hope this is the right one):
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_15168&d=BQID-g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=VQx-tNIhMX_CI4DXORkNq10jBTMAXyaFT332GWZhfRQ&e=
>>>  
>>> 
>>>> Then whoever clones the repo can get
>>>> the license flavor he's least scared about.
>>> 
>>> I think for many companies it is important that a developer of theirs
>>> who is "blissfully ignorant" of licensing questions simply *cannot* make
>>> a mistake (eg. by copying code from the "wrong" directory, or by using
>>> the "wrong" submodule). It should be foolproof.
>>> 
>>>> Or alternatively instead
>>>> of pulling in a GPL licensed FAT driver we use a BSD licensed one.
>>>> I'm sure someone has one of those too ;).
>>> 
>>> I'm not sure at all. Do you have a pointer? :)
>> 
>> Well, the BSDs definitely have drivers, but I find the BSD VFS layer
>> quite confusing to be honest ;).
>> 
>> Then there is 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__elm-2Dchan.org_fsw_ff_00index-5Fe.html&d=BQID-g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=l2F5kQrmSHyEb7D4po7B0A-vQK1l7rCkw79eJCddVmQ&e=
>>   which from my
>> gut feeling has a compatible license (read: needs verification).
>> 
>> I'm sure with some extensive search one can find a workable driver. Or
>> for example Apple could just contribute theirs as BSD licensed.
> 
> They are talking about an EFI FAT driver with a BSD compatible license, not a 
> BSD driver. 

We're talking about replacing the non-free FAT driver with a free one for OVMF. 
The easiest path to get there isvto reuse an existing driver - the original 
proposal was to take the one from grub and fit it into uEFI's interfaces.

An alternative to the GPL grub driver would be a BSD licensed driver from 
somewhere else or a rewrite. Rewrite sounds harder. If we can throw out the 
non-free FAT driver and put in a BSD licensed FAT driver based on known working 
code into edk2, I suppose it's a win for everyone involved and we wouldn't even 
need a fork for OVMF imho but keep it as reference implementation in the tree, 
like Duet.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel