> 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

Reply via email to