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

[Andrew Fish <afish@xxxxxxxxx>]

> On Sep 9, 2015, at 11:19 PM, Alexander Graf <agraf@xxxxxxx> wrote:
> 
> 
> 
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.justen@xxxxxxxxx>:
>> 
>> On 2015-09-09 20:26:54, Andrew Fish wrote:
>>>> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.justen@xxxxxxxxx> 
>>>> 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?
> 
> In fact, could we just make the non-free FAT source and GPL FAT source both 
> be git submodules? Then whoever clones the repo can get the license flavor 
> he's least scared about. Or alternatively instead of pulling in a GPL 
> licensed FAT driver we use a BSD licensed one. I'm sure someone has one of 
> those too ;).
> 
> Also for the record, the FAT driver problem is that the source license states 
> that it can not be used in certain circumstances, which by common 
> interpretation makes it non-free. The fact that there is a binary or source 
> doesn't matter fwiw.
> 

The edk2 FAT driver solves the problems faced by folks shipping hardware, but 
the source ended up as a separate project to keep the license clean. I donât 
think anyone thought about the binary + license being an issue back in the day? 
IMHO the right thing to do is remove the binary FAT driver from the tree (the 
source is already in a sub project), and update the getting started collateral. 
It seems like the right thing to do to respect folks with different down stream 
licensing constraints. 

I wish those of us with BSD development constraints got the same consideration 
from some of the GPL developers on this list. 

Thanks,

Andrew Fish


> 
> Alex
> 


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