> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jordan Justen > Sent: Thursday, September 10, 2015 11:03 AM > On 2015-09-09 20:26:54, Andrew Fish wrote: > > > On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.jus...@intel.com> > wrote: > > > On 2015-09-09 16:05:20, Andrew Fish wrote: > > >> So you have a legal degree and are speaking on behalf of your > > >> employer on this subject? > > > > > > No and no. How about you? :) > > > > No but I have to review any code contributed to the open source > > project to make sure it follows the corporate polices. > > Is Apple corporate policy that you could never contribute to a project > that has a GPL directory in the tree? > > > > Nevertheless, I have not heard the interpretation that just having > > > GPL in a source tree would impact your code, even if you do not > > > include, nor link to it. Is this Apple's interpretation of how GPL > works? > > > > No but thanks for making my point for me. 1st off the rules are made > > by lawyers and managers so you trying to argue logic is kind of funny. > > What does logic have to do with it. > > Whoa! What's next in this crazy world? Dogs and cats living together! > Mass hysteria! How can we be sure that the lawyers won't decide that BSD > means GPL and vice versa? ;) > > > Your company started this edk2 project as a BSD project, and I assume > > there was a reason for that. > > And then more licenses were added. > > > The reasons rules like this end up getting made is that developers > > like you are confused about the company policy regarding open source, > > closed source and protecting intellectual property rights. > > So your very smart and well versed and you are confused, so > > I don't think I'm confused (or smart :), but you are trying hard to make > it seem confusing and scary. > > Anyway, you are correct. We do have rules. But, I don't think those rules > prevent us from discussing *possible* changes to those rules. > > > some more jr. engineer has no hope of getting it right and would copy > > the GPL code and be clueless to what he just did. As I always say a > > development process exists to slow down the best developer, at the > > price of preventing the most jr. developers from doing something > > stupid. > > If we have another repo with GplDriverPkg, then I guess the same jr. > developer might just go find the code over there and copy it. > > > > I would be more worried about the GPL based drivers becoming too > > > featureful over time, and the permissively licensed code not being > > > very useful. For example, I'm worried that the non-GPL OVMF may end > > > up missing a lot of features. > > > > Then logically you should just make OVMF a GPL project? > > Not if you are someone that prefers permissive source licenses, such as > myself. > > I'm basically trying to argue the other side of this to not let the GPL > FUD go by unimpeded. > > Laszlo's email raised the GPL question, but I was not sure what the EDK > II community would accept with regards to GPL. Thus ... I asked. I guess > I'm getting a better idea with regards to Apple and HP. :) > > In your opinion, would we be able to discuss patches for a *separate* > repo with GplDriverPkg on edk2-devel? Sorry to chime-in into the discussion out-of-turn, but we at Freescale were struggling for some time with the different licensing models/downloading privileges of EDK2, FatDriverPkg and SCT 2.4.
So based on my limited understanding, can't the OVMF driver which uses features from some GPL based code, carry a dual license (GPL + x11 [MIT]), like most device trees in Linux do now (including the Freescale ARMv8 DTS, see [1] for reference), thus allowing its usage across both GPL and BSD based projects (like EDK2). We already have examples of such dual-licensed code (libfdt) being used in BSD-licensed EDK2 (see [2] for details). In such a case we might not be required to create a separate GIT repo for the same. [1] https://patchwork.ozlabs.org/patch/385248/ [2] http://sourceforge.net/p/tianocore/edk2/ci/3e8576dd363fe516ceec1ddc4aff51bc5a3d4bd7/ Regards, Bhupesh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
