> On Sep 9, 2015, at 10:57 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: > > On 2015-09-09 10:04:50, Andrew Fish wrote: >> >>> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> wrote: >>> >>> 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. > > There doesn't seem to be any guiding rules here. For example, I think > some people are not comfortable with the FatBinPkg being in the tree > due to the license.
I don’t think it is fair to look backwards to make this comparison A long time ago your co-workers decided to check some binaries in to make folks life easier. 1) Tools compiled by VC++ that only run on Windows 2) Shell binary 3) FAT binary I think the goal was one svn pull and no extra tools needed to install, build, and run NT32 on Windows. The source code was BSD so other than the FAT driver it is all compatible with a GPL project that wanted to import the code. That was good enough when this decision was made. I personally have no issue removing the binaries from the tree, especially the FAT driver if it causes issues for folks. I think that would imply the website, and any getting started collateral would need to get updated. > Why is that okay? > It was OK, at the time. The intellectual property around FAT is a mess, but at least it is permissible to use it in (U)EFI to boot a system. >>> 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. > > We've recently expanded beyond just allowing BSD code into the tree, > and that appeared to be no big deal. No one brought this up as a > fundamental change. > > Just to be clear, are you saying Apple probably won't be able to > contribute to EDK II if there is any GPL licensed code in the tree? > (Even if it is contained in a clearly indicated package.) I guess > using dual-licensed BSD/GPL is okay though? > (EmbeddedPkg/Library/FdtLib) > BSD compatible is OK. Thanks, Andrew Fish > -Jordan > _______________________________________________ > 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=Kmc0BLQJkt9XKCJf_d8PrrQXQ9eNhkkTmN6cq2RzIzo&s=gmyUS4K6xDQ0QIZyAv_DkOp_G9rMBrDpvqa_VV_4RTo&e= > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
