> On Sep 9, 2015, at 11:19 PM, Alexander Graf <ag...@suse.de> wrote: > > > >> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.jus...@intel.com>: >> >> 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? > > 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@lists.xen.org http://lists.xen.org/xen-devel
