[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


 


Rackspace

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