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

[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. 
The edk2 EFI FAT driver has a license that matches the FAT32 spec it was coded 
against, but that license restricts the usage of the code to EFI. This is not 
deemed a GPL compatible license, so that causes issues with down stream GPL 
projects of the edk2 as there is a binary for the EFI FAT driver checked into 
the main branch of the edk2. The source to the edk2 EFI FAT driver is separate 
from the edk2 based on its funky license. 

Thanks,

Andrew Fish

> 
> Alex


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