> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> 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 >> >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__permalink.gmane.org_gmane.comp.bios.edk2.devel_941&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=NkAF9nkaYv90MC55j7jme4YajlZK14oKVu3L61jRnJ4&e= >> > 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: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_17544_focus-3D676&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=HauTLYzaQYz935VMYQCCR8xzuSADw1ZcWSSjSyEXIpw&e= > > > 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? >
I think we would need a separate repo, like the FAT driver. That is the only way to deal with the license issues. > 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 > Or have their rights to contribute revoked since this is a fundamental change, and would require employees to get reauthorized by their legal departments to contribute. > Of these, I personally only sympathize with the first. > Your employer probably has issues with all of this. > 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. > Mixing is never going to work. If you mix then the pure BSD edk2 will fork and continue, I’m guessing a lot of the Intel resources will work on that version as it will be the one enabling Intel products. > Additionally, it makes sense to use it as needed for OVMF specific > releases. (Ie, OVMF release tags) > Seems to me we are really solving the wrong problem. What we need is a smaller BSD edk2 project that supports the industry standards and works on some set of BSD platforms. There can be down stream consumers that have more platform support, and different licenses. Seems the real problem is the unpredictable changes to MdePkg libraries, and MdeModulePkg infrastructure. So it is the lack of a transparent plan, and discussion about upcoming changes that break compatibility between different projects. So the solution is to keep everything in the tree working on master. We should fix the edk2 process, and place a process in place to communicate pending non backward compatible changes in the edk2 to down stream consumers. Don’t forget a lot (majority) of edk2 based products that ship today live in a separate repo that likely contains a UDK or specific version of edk2 with cherry picked patches. So this processes is kind of already happening in the non-GPL world…. Thanks, Andrew Fish > -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@lists.01.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=sqGoNWq1TnVknPoRJPafosJli9Yd2f7SM7YQcWQptcc&e= >> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=sqGoNWq1TnVknPoRJPafosJli9Yd2f7SM7YQcWQptcc&e= > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
