Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Jordan Justen <jordan.l.justen@xxxxxxxxx>]

On 2015-09-09 16:05:20, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.justen@xxxxxxxxx> wrote:
> > 
> > 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.
> >> 
> >> I agree with Andrew, opening the door for GPL licensed code in EDK2
> >> will have severe consequences for products that are built using
> >> EDK2.
> > 
> > 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.
> > 
> 
> So you have a legal degree and are speaking on behalf of your
> employer on this subject?

No and no. How about you? :)

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?

> > 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.

I like this argument. It is slightly tempered by the fact that git
grep always shows the source path, and thus 'GplDriverPkg' would be
obviously visible.

> Thus having GPL code in the same repository as BSD code can end up
> accidentally converting BSD code to GPL code over time.

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.

-Jordan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel