From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZoQm-00033G-94 for qemu-devel@nongnu.org; Wed, 09 Sep 2015 19:05:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZoQi-00057y-WF for qemu-devel@nongnu.org; Wed, 09 Sep 2015 19:05:32 -0400 Received: from mail-out4.apple.com ([17.151.62.26]:65198 helo=mail-in4.apple.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZoQi-00056Y-KC for qemu-devel@nongnu.org; Wed, 09 Sep 2015 19:05:28 -0400 Received: from [17.153.40.73] (unknown [17.153.40.73]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUF00KYCMSXEN20@marigold.apple.com> for qemu-devel@nongnu.org; Wed, 09 Sep 2015 16:05:25 -0700 (PDT) Sender: afish@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Andrew Fish In-reply-to: <20150909222410.14692.78094@jljusten-ivb> Date: Wed, 09 Sep 2015 16:05:20 -0700 Content-transfer-encoding: quoted-printable Message-id: <2291309F-6521-4966-B8EB-FDCC1DCD2B1F@apple.com> References: <55C8D046.7040203@redhat.com> <55EFF48F.7090005@redhat.com> <20150909161735.30348.87652@jljusten-ivb> <20150909175753.1013.69101@jljusten-ivb> <20150909222410.14692.78094@jljusten-ivb> Subject: Re: [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jordan Justen Cc: Lenny Szubowicz , Karen Noel , Gerd Hoffmann , "El-Haj-Mahmoud, Samer" , Ard Biesheuvel , edk2-devel-01 , Reza Jelveh , Alexander Graf , qemu devel list , "Gabriel L. Somlo (GMail)" , Peter Jones , Peter Batard , Hannes Reinecke , "Doran, Mark" , Cole Robinson , Paolo Bonzini , "xen-devel@lists.xen.org" , Laszlo Ersek , "Ademar de Souza Reis Jr." > On Sep 9, 2015, at 3:24 PM, Jordan Justen = wrote: >=20 > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote: >> The recent expansions beyond BSD where all permissive licenses (BSD >> like) as far as I can tell. >>=20 >> I agree with Andrew, opening the door for GPL licensed code in EDK2 >> will have severe consequences for products that are built using >> EDK2. >=20 > I don't think simply having a GplDriverPkg in the tree would have any > consequences for a platform that doesn't use any code in that package. > Obviously we could not make any core packages rely on that package. >=20 So you have a legal degree and are speaking on behalf of your employer = on this subject?=20 > This would just be a sanctioned, clear landing place for people that > cannot, or will not provide their driver under a permissive license. >=20 > This license will limit who can use drivers from this package. For > that reason, I hope that we will always ask if a contribution can be > permissively licensed instead. >=20 > Personally, I would prefer a 2-clause BSD only tree for simplicity, > but unfortunately, that sort of restriction has its own drawbacks as > well. (frustrated contributors and less contributions) >=20 > FWIW, I don't mind if the consensus is that GplDriverPkg must live in > a separate repo. But, it would be nice to hear a good reason why it > must live elsewhere. Because GPL is not a permissive license. An accidental git grep and = copying some code can change the license of the code that gets the GPL = code pasted into it. Thus having GPL code in the same repository as BSD = code can end up accidentally converting BSD code to GPL code over time. = If GPL was OK with everyone we would have started with GPL. The good = thing is the BDS code is GPL compatible so it can be used for GPL code = and bug fixes in the BDS code can be merged into to GPL code, but this = is a one way operation.=20 If you don=E2=80=99t believe me please feel free to sit down and have a = long conversation with Intel IP lawyers. > (And, why that doesn't also apply to FatBinPkg.) >=20 There is no IP leakage from a binary. This FAT driver is licensed for = use with EFI, and given this is a EFI code base that seemed like a good = thing.=20 I don=E2=80=99t pretent to understand the GPL FAT thing, I guess it is = some kind of civil disobedience. it does not mater what license you = strap on the code the the device makers still have to =E2=80=9Cpay the = man=E2=80=9D.=20 Thanks, Andrew Fish PS As I stated before I=E2=80=99m fine removing all the binaries from = the main repo, as you don=E2=80=99t really want binaries in your = production repo, and source level debugging is a nice feature and all.=20= > -Jordan >=20 >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf = Of Jordan Justen >> Sent: Wednesday, September 09, 2015 12:58 PM >> To: Andrew Fish >> Cc: Lenny Szubowicz ; Karen Noel = ; Ard Biesheuvel ; = edk2-devel-01 ; Reza Jelveh = ; Alexander Graf ; qemu devel list = ; Hannes Reinecke ; Gabriel L. = Somlo (GMail) ; Peter Jones ; Peter = Batard ; Gerd Hoffmann ; Cole Robinson = ; Paolo Bonzini ; = xen-devel@lists.xen.org; Laszlo Ersek ; Ademar de = Souza Reis Jr. >> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015 >>=20 >> On 2015-09-09 10:04:50, Andrew Fish wrote: >>>=20 >>>> On Sep 9, 2015, at 9:17 AM, Jordan Justen = wrote: >>>>=20 >>>> 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? >>>>=20 >>>=20 >>> I think we would need a separate repo, like the FAT driver. That is >>> the only way to deal with the license issues. >>=20 >> 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. Why is that okay? >>=20 >>>> With regards to adding it directly into the EDK II tree, here are >>>> some potential concerns that I might anticipate hearing from the = community: >>>>=20 >>>> * It will make it easier for contributors to choose GPL compared to >>>> a permissive license, thereby limiting some users of the >>>> contribution >>>>=20 >>>> * GPL code will more easily be copied into the permissively = licensed >>>> packages >>>>=20 >>>> * Some might refuse to look at EDK II entirely if it has a = directory >>>> with GPL source code in it >>>>=20 >>>=20 >>> 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. >>=20 >> 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. >>=20 >> 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) >>=20 >> -Jordan >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__lists.01.org_mailma= n_listinfo_edk2-2Ddevel&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3D1HnUuXD1= wDvw67rut5_idw&m=3DyvzCzDdEDVjZEzZI9AOKS3bV8FD8sjx1LqCww7Vn3rA&s=3Dp1Kcan7= EiiR_ZC78qKT0jfGMD0yx2Wpv5vJ6LnwXkD0&e=3D=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__lists.01.org_mailma= n_listinfo_edk2-2Ddevel&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3D1HnUuXD1= wDvw67rut5_idw&m=3DyvzCzDdEDVjZEzZI9AOKS3bV8FD8sjx1LqCww7Vn3rA&s=3Dp1Kcan7= EiiR_ZC78qKT0jfGMD0yx2Wpv5vJ6LnwXkD0&e=3D=20