[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexander Graf
Subject: Re: [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
Date: Thu, 10 Sep 2015 15:28:47 +0200

> Am 10.09.2015 um 14:17 schrieb Andrew Fish <address@hidden>:
>> On Sep 10, 2015, at 4:40 AM, Alexander Graf <address@hidden> 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 <address@hidden>:
>>>>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]