[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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


Alex


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.