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

[Jordan Justen <jordan.l.justen@xxxxxxxxx>]

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.

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

-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