[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
On 09/10/15 08:19, Alexander Graf wrote: > > >> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.justen@xxxxxxxxx>: >> 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? We've discussed submodules in the past (for other purposes). The consensus seemed to be that most people dislike them (me included). UEFI drivers are supposed to be modular / well separable (for one, they can be shipped by third parties in binary-only form; which was a design goal of UEFI). And specifically in the FAT driver's case, the source doesn't even live inside the main repo at the moment, so turning it into a source submodule might not be a step back. But... I just don't like it. We should be moving towards a grand unified repo, where cross-module changes and dependencies are possible to implement with carefully segmented patch sets. The FAT driver's source lives outside for non-technical reasons. Rather than codifying that situation forever with a git submodule, I'd prefer some solution that leaves us with a standalone repo. I think I'm fuzzy on the details of the earlier git-submodule discussion. In any case here's the link (I hope this is the right one): http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15168 > Then whoever clones the repo can get > the license flavor he's least scared about. I think for many companies it is important that a developer of theirs who is "blissfully ignorant" of licensing questions simply *cannot* make a mistake (eg. by copying code from the "wrong" directory, or by using the "wrong" submodule). It should be foolproof. > 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 ;). I'm not sure at all. Do you have a pointer? :) > 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. I agree. The restriction on use conflicts both the FSF's defintion of Free Software, and the OSI's definition of Open Source Software. > The fact that there > is a binary or source doesn't matter fwiw. Right. Laszlo _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |