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

[Laszlo Ersek <lersek@xxxxxxxxxx>]

On 09/09/15 18:17, Jordan Justen wrote:
> On 2015-09-09 01:57:51, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>>
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>>
>> Here's a preliminary task list, after some off-list discussion (I tried
>> to incorporate comments):
>>
>> - create GPL'd fork called "ovmf" for expediting virt development
>>   (OvmfPkg, ArmVirtPkg)
>>   - maybe leverage the feature under
>>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> for
>>     setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>>     contributions [Jordan]
>>     - repo separation by license could make things harder for packagers
>>       and QEMU bundling [Laszlo]
> 
> I would like OVMF to follow a plan for GPL that the whole EDK II
> community decides on.
> 
> I would also like to see EDK II add a (permissively licensed; BSD,
> MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list
> recently:
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17544/focus=676
> 
> So, related to this, I wonder how the community would feel about a
> GplDriverPkg. Would the community allow it as a new package in EDK II
> directly, or would a separate repo be required?
> 
> With regards to adding it directly into the EDK II tree, here are some
> potential concerns that I might anticipate hearing from the community:
> 
> * It will make it easier for contributors to choose GPL compared to a
>   permissive license, thereby limiting some users of the contribution
> 
> * GPL code will more easily be copied into the permissively licensed
>   packages
> 
> * Some might refuse to look at EDK II entirely if it has a directory
>   with GPL source code in it
> 
> Of these, I personally only sympathize with the first.
> 
> Regarding the separate OVMF repo, my hope is that it is more of a OVMF
> specific working area, rather than a 'GPL OVMF'. For example, patches
> or features that we've not yet figured out how to upstream, but we
> hopefully plan to.

Yes, the "OVMF specific working area" is also my main goal with this.

If we can find a way to (a) replace the FAT driver with the libre
software one, and (b) more generally, accept GPL drivers, without
depending on this separate OVMF repo, that's great. So "owning" those
modules is not a goal per se, just something the new repo should cover
in case we can't solve it within edk2. (E.g. with your GplDriverPkg idea.)

> Additionally, it makes sense to use it as needed for OVMF specific
> releases. (Ie, OVMF release tags)

Good idea.

Thanks!
Laszlo

> 
> -Jordan
> 
>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>   master (arguments both for and against merging); distros should
>>   then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@xxxxxxxxxxxx
>> https://lists.01.org/mailman/listinfo/edk2-devel


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