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

[Kevin Davis]

> 
> 
> On 10/09/2015 16:24, Kevin Davis wrote:
> > Further leading me to guess that any actual use of those
> > implementations could lead to you actually needing to hire a real
> > attorney and not one that you find on YouTube.
> 
> The good thing is that attorneys have already figured it out.  IBM figured out
> a few years ago how to work around Microsoft's patents, and that's how
> FAT32 (and more specifically long file names) are implemented in Linux.

Ah.  I wasn't in the room when they figured it out.  And I've never seen their 
written opinion.  Is it documented somewhere?

>From my viewpoint, I wouldn't worry too much if I was an IBM attorney either.  
>I can only imagine the cross licensing agreements between Microsoft and IBM.  
>Was this opinion part of OSDL?

Thanks,
Kevin

> 
> Paolo

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

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

[Sharma Bhupesh]

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jordan Justen
> Sent: Thursday, September 10, 2015 11:03 AM
> On 2015-09-09 20:26:54, Andrew Fish wrote:
> > > On Sep 9, 2015, at 5:41 PM, Jordan Justen 
> 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?
 
Sorry to chime-in into the discussion out-of-turn, but we at Freescale were 
struggling
for some time with the different licensing models/downloading privileges  of 
EDK2, FatDriverPkg
and SCT 2.4.

So based on my limited understanding, can't the OVMF driver which uses features 
from some GPL based code,
carry a dual license (GPL + x11 [MIT]), like most device trees in Linux do now
(including the Freescale ARMv8 DTS, see [1] for reference), thus allowing its 
usage
across both GPL and BSD based projects (like EDK2).

We already have examples of such dual-licensed code (libfdt) being used in 
BSD-licensed EDK2
(see [2] for details).

In such a case we might not be required to create a separate GIT repo for the 
same.

[1] https://patchwork.ozlabs.org/patch/385248/
[2] 
http://sourceforge.net/p/tianocore/edk2/ci/3e8576dd363fe516ceec1ddc4aff51bc5a3d4bd7/

Regards,
Bhupesh

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

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

[Laszlo Ersek]

On 09/10/15 08:19, Alexander Graf wrote:
> 
> 
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen :

>> 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@lists.xen.org
http://lists.xen.org/xen-devel

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

[Alexander Graf]

> Am 10.09.2015 um 14:17 schrieb Andrew Fish :
> 
> 
>> On Sep 10, 2015, at 4:40 AM, Alexander Graf  wrote:
>> 
>> 
>> 
>>> On 10.09.15 12:04, Laszlo Ersek wrote:
 On 09/10/15 08:19, Alexander Graf wrote:
 
 
> Am 10.09.2015 um 07:32 schrieb Jordan Justen :
>>> 
> 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):
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_15168=BQID-g=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o=VQx-tNIhMX_CI4DXORkNq10jBTMAXyaFT332GWZhfRQ=
>>>  
>>> 
 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? :)
>> 
>> Well, the BSDs definitely have drivers, but I find the BSD VFS layer
>> quite confusing to be honest ;).
>> 
>> Then there is 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__elm-2Dchan.org_fsw_ff_00index-5Fe.html=BQID-g=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o=l2F5kQrmSHyEb7D4po7B0A-vQK1l7rCkw79eJCddVmQ=
>>   which from my
>> gut feeling has a compatible license (read: needs verification).
>> 
>> I'm sure with some extensive search one can find a workable driver. Or
>> for example Apple could just contribute theirs as BSD licensed.
> 
> They are talking about an EFI FAT driver with a BSD compatible license, not a 
> BSD driver. 

We're talking about replacing the non-free FAT driver with a free one for OVMF. 
The easiest path to get there isvto reuse an existing driver - the original 
proposal was to take the one from grub and fit it into uEFI's interfaces.

An alternative to the GPL grub driver would be a BSD licensed driver from 
somewhere else or a rewrite. Rewrite sounds harder. If we can throw out the 
non-free FAT driver and put in a BSD licensed FAT driver based on known working 
code into edk2, I suppose it's a win for everyone involved and we wouldn't even 
need a fork for OVMF imho but keep it as reference implementation in the tree, 
like Duet.


Alex


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

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

[Andrew Fish]

> On Sep 10, 2015, at 4:40 AM, Alexander Graf  wrote:
> 
> 
> 
> On 10.09.15 12:04, Laszlo Ersek wrote:
>> On 09/10/15 08:19, Alexander Graf wrote:
>>> 
>>> 
 Am 10.09.2015 um 07:32 schrieb Jordan Justen :
>> 
 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):
>> 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_15168=BQID-g=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o=VQx-tNIhMX_CI4DXORkNq10jBTMAXyaFT332GWZhfRQ=
>>  
>> 
>>> 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? :)
> 
> Well, the BSDs definitely have drivers, but I find the BSD VFS layer
> quite confusing to be honest ;).
> 
> Then there is 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__elm-2Dchan.org_fsw_ff_00index-5Fe.html=BQID-g=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o=l2F5kQrmSHyEb7D4po7B0A-vQK1l7rCkw79eJCddVmQ=
>   which from my
> gut feeling has a compatible license (read: needs verification).
> 
> I'm sure with some extensive search one can find a workable driver. Or
> for example Apple could just contribute theirs as BSD licensed.
> 

They are talking about an EFI FAT driver with a BSD compatible license, not a 
BSD driver. 
The edk2 EFI FAT driver has a license that matches the FAT32 spec it was coded 
against, but that license restricts the usage of the code to EFI. This is not 
deemed a GPL compatible license, so that causes issues with down stream GPL 
projects of the edk2 as there is a binary for the EFI FAT driver checked into 
the main branch of the edk2. The source to the edk2 EFI FAT driver is separate 
from the edk2 based on its funky license. 

Thanks,

Andrew Fish

> 
> Alex


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

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

[Alexander Graf]

On 10.09.15 12:04, Laszlo Ersek wrote:
> On 09/10/15 08:19, Alexander Graf wrote:
>>
>>
>>> Am 10.09.2015 um 07:32 schrieb Jordan Justen :
> 
>>> 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? :)

Well, the BSDs definitely have drivers, but I find the BSD VFS layer
quite confusing to be honest ;).

Then there is http://elm-chan.org/fsw/ff/00index_e.html which from my
gut feeling has a compatible license (read: needs verification).

I'm sure with some extensive search one can find a workable driver. Or
for example Apple could just contribute theirs as BSD licensed.


Alex

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

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

[Paolo Bonzini]

On 10/09/2015 16:24, Kevin Davis wrote:
> Further leading me to guess that any actual use of those
> implementations could lead to you actually needing to hire a real
> attorney and not one that you find on YouTube.

The good thing is that attorneys have already figured it out.  IBM
figured out a few years ago how to work around Microsoft's patents, and
that's how FAT32 (and more specifically long file names) are implemented
in Linux.

Paolo

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

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

[Alexander Graf]

> Am 10.09.2015 um 07:32 schrieb Jordan Justen :
> 
> On 2015-09-09 20:26:54, Andrew Fish wrote:
>>> On Sep 9, 2015, at 5:41 PM, Jordan Justen  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@lists.xen.org
http://lists.xen.org/xen-devel

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

[Andrew Fish]

> On Sep 9, 2015, at 11:19 PM, Alexander Graf  wrote:
> 
> 
> 
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen :
>> 
>> On 2015-09-09 20:26:54, Andrew Fish wrote:
 On Sep 9, 2015, at 5:41 PM, Jordan Justen  
 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

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

[Andrew Fish]

> On Sep 9, 2015, at 10:57 AM, Jordan Justen  wrote:
> 
> On 2015-09-09 10:04:50, Andrew Fish wrote:
>> 
>>> On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
>>> 
>>> So, related to this, I wonder how the community would feel about a
>>> GplDriverPkg. Would the community allow it as a new package in EDK II
>>> directly, or would a separate repo be required?
>>> 
>> 
>> I think we would need a separate repo, like the FAT driver. That is
>> the only way to deal with the license issues.
> 
> There doesn't seem to be any guiding rules here. For example, I think
> some people are not comfortable with the FatBinPkg being in the tree
> due to the license.

I don’t think it is fair to look backwards to make this comparison 

A long time ago your co-workers decided to check some binaries in to make folks 
life easier. 
1) Tools compiled by VC++ that only run on Windows
2) Shell binary
3) FAT binary

I think the goal was one svn pull and no extra tools needed to install, build, 
and run NT32 on Windows. 

The source code was BSD so other than the FAT driver it is all compatible with 
a GPL project that wanted to import the code. That was good enough when this 
decision was made. 

I personally have no issue removing the binaries from the tree, especially the 
FAT driver if it causes issues for folks. I think that would imply the website, 
and any getting started collateral would need to get updated. 

> Why is that okay?
> 

It was OK, at the time. 

The intellectual property around FAT is a mess, but at least it is permissible 
to use it in (U)EFI to boot a system. 

>>> With regards to adding it directly into the EDK II tree, here are some
>>> potential concerns that I might anticipate hearing from the community:
>>> 
>>> * It will make it easier for contributors to choose GPL compared to a
>>> permissive license, thereby limiting some users of the contribution
>>> 
>>> * GPL code will more easily be copied into the permissively licensed
>>> packages
>>> 
>>> * Some might refuse to look at EDK II entirely if it has a directory
>>> with GPL source code in it
>>> 
>> 
>> Or have their rights to contribute revoked since this is a
>> fundamental change, and would require employees to get reauthorized
>> by their legal departments to contribute.
> 
> We've recently expanded beyond just allowing BSD code into the tree,
> and that appeared to be no big deal. No one brought this up as a
> fundamental change.
> 
> Just to be clear, are you saying Apple probably won't be able to
> contribute to EDK II if there is any GPL licensed code in the tree?
> (Even if it is contained in a clearly indicated package.) I guess
> using dual-licensed BSD/GPL is okay though?
> (EmbeddedPkg/Library/FdtLib)
> 

BSD compatible is OK. 

Thanks,

Andrew Fish

> -Jordan
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Kmc0BLQJkt9XKCJf_d8PrrQXQ9eNhkkTmN6cq2RzIzo=gmyUS4K6xDQ0QIZyAv_DkOp_G9rMBrDpvqa_VV_4RTo=
>  


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

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

[Andrew Fish]

> On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
> 
> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
>> The recent expansions beyond BSD where all permissive licenses (BSD
>> like) as far as I can tell.
>> 
>> I agree with Andrew, opening the door for GPL licensed code in EDK2
>> will have severe consequences for products that are built using
>> EDK2.
> 
> I don't think simply having a GplDriverPkg in the tree would have any
> consequences for a platform that doesn't use any code in that package.
> Obviously we could not make any core packages rely on that package.
> 

So you have a legal degree and are speaking on behalf of your employer on this 
subject? 

> This would just be a sanctioned, clear landing place for people that
> cannot, or will not provide their driver under a permissive license.
> 
> This license will limit who can use drivers from this package. For
> that reason, I hope that we will always ask if a contribution can be
> permissively licensed instead.
> 
> Personally, I would prefer a 2-clause BSD only tree for simplicity,
> but unfortunately, that sort of restriction has its own drawbacks as
> well. (frustrated contributors and less contributions)
> 
> FWIW, I don't mind if the consensus is that GplDriverPkg must live in
> a separate repo. But, it would be nice to hear a good reason why it
> must live elsewhere.

Because GPL is not a permissive license. An accidental git grep and copying 
some code can change the license of the code that gets the GPL code pasted into 
it. Thus having GPL code in the same repository as BSD code can end up 
accidentally converting BSD code to GPL code over time. If GPL was OK with 
everyone we would have started with GPL. The good thing is the BDS code is GPL 
compatible so it can be used for GPL code and bug fixes in the BDS code can be 
merged into to GPL code, but this is a one way operation. 

If you don’t believe me please feel free to sit down and have a long 
conversation with Intel IP lawyers.


> (And, why that doesn't also apply to FatBinPkg.)
> 

There is no IP leakage from a binary. This FAT driver is licensed for use with 
EFI, and given this is a EFI code base that seemed like a good thing. 

I don’t pretent to understand the GPL FAT thing, I guess it is some kind of 
civil disobedience. it does not mater what license you strap on the code the 
the device makers still have to “pay the man”. 

Thanks,

Andrew Fish

PS As I stated before I’m fine removing all the binaries from the main repo, as 
you don’t really want binaries in your production repo, and source level 
debugging is a nice feature and all. 

> -Jordan
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Jordan Justen
>> Sent: Wednesday, September 09, 2015 12:58 PM
>> To: Andrew Fish 
>> Cc: Lenny Szubowicz ; Karen Noel ; Ard 
>> Biesheuvel ; edk2-devel-01 
>> ; Reza Jelveh ; Alexander Graf 
>> ; qemu devel list ; Hannes Reinecke 
>> ; Gabriel L. Somlo (GMail) ; Peter Jones 
>> ; Peter Batard ; Gerd Hoffmann 
>> ; Cole Robinson ; Paolo Bonzini 
>> ; xen-devel@lists.xen.org; Laszlo Ersek 
>> ; Ademar de Souza Reis Jr. 
>> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
>> 
>> On 2015-09-09 10:04:50, Andrew Fish wrote:
>>> 
 On Sep 9, 2015, at 9:17 AM, Jordan Justen  
 wrote:
 
 So, related to this, I wonder how the community would feel about a
 GplDriverPkg. Would the community allow it as a new package in EDK
 II directly, or would a separate repo be required?
 
>>> 
>>> I think we would need a separate repo, like the FAT driver. That is
>>> the only way to deal with the license issues.
>> 
>> There doesn't seem to be any guiding rules here. For example, I
>> think some people are not comfortable with the FatBinPkg being in
>> the tree due to the license. Why is that okay?
>> 
 With regards to adding it directly into the EDK II tree, here are
 some potential concerns that I might anticipate hearing from the community:
 
 * It will make it easier for contributors to choose GPL compared to
 a  permissive license, thereby limiting some users of the
 contribution
 
 * GPL code will more easily be copied into the permissively licensed
 packages
 
 * Some might refuse to look at EDK II entirely if it has a directory
 with GPL source code in it
 
>>> 
>>> Or have their rights to contribute revoked since this is a fundamental
>>> change, and would require employees to get reauthorized by their legal
>>> departments to contribute.
>> 
>> We've 

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

[Jordan Justen]

On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
> The recent expansions beyond BSD where all permissive licenses (BSD
> like) as far as I can tell.
> 
> I agree with Andrew, opening the door for GPL licensed code in EDK2
> will have severe consequences for products that are built using
> EDK2.

I don't think simply having a GplDriverPkg in the tree would have any
consequences for a platform that doesn't use any code in that package.
Obviously we could not make any core packages rely on that package.

This would just be a sanctioned, clear landing place for people that
cannot, or will not provide their driver under a permissive license.

This license will limit who can use drivers from this package. For
that reason, I hope that we will always ask if a contribution can be
permissively licensed instead.

Personally, I would prefer a 2-clause BSD only tree for simplicity,
but unfortunately, that sort of restriction has its own drawbacks as
well. (frustrated contributors and less contributions)

FWIW, I don't mind if the consensus is that GplDriverPkg must live in
a separate repo. But, it would be nice to hear a good reason why it
must live elsewhere. (And, why that doesn't also apply to FatBinPkg.)

-Jordan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
> Justen
> Sent: Wednesday, September 09, 2015 12:58 PM
> To: Andrew Fish 
> Cc: Lenny Szubowicz ; Karen Noel ; Ard 
> Biesheuvel ; edk2-devel-01 
> ; Reza Jelveh ; Alexander Graf 
> ; qemu devel list ; Hannes Reinecke 
> ; Gabriel L. Somlo (GMail) ; Peter Jones 
> ; Peter Batard ; Gerd Hoffmann 
> ; Cole Robinson ; Paolo Bonzini 
> ; xen-devel@lists.xen.org; Laszlo Ersek 
> ; Ademar de Souza Reis Jr. 
> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
> 
> On 2015-09-09 10:04:50, Andrew Fish wrote:
> >
> > > On Sep 9, 2015, at 9:17 AM, Jordan Justen  
> > > wrote:
> > >
> > > So, related to this, I wonder how the community would feel about a
> > > GplDriverPkg. Would the community allow it as a new package in EDK
> > > II directly, or would a separate repo be required?
> > >
> >
> > I think we would need a separate repo, like the FAT driver. That is
> > the only way to deal with the license issues.
> 
> There doesn't seem to be any guiding rules here. For example, I
> think some people are not comfortable with the FatBinPkg being in
> the tree due to the license. Why is that okay?
> 
> > > With regards to adding it directly into the EDK II tree, here are
> > > some potential concerns that I might anticipate hearing from the 
> > > community:
> > >
> > > * It will make it easier for contributors to choose GPL compared to
> > > a  permissive license, thereby limiting some users of the
> > > contribution
> > >
> > > * GPL code will more easily be copied into the permissively licensed
> > > packages
> > >
> > > * Some might refuse to look at EDK II entirely if it has a directory
> > > with GPL source code in it
> > >
> >
> > Or have their rights to contribute revoked since this is a fundamental
> > change, and would require employees to get reauthorized by their legal
> > departments to contribute.
> 
> We've recently expanded beyond just allowing BSD code into the tree,
> and that appeared to be no big deal. No one brought this up as a
> fundamental change.
> 
> Just to be clear, are you saying Apple probably won't be able to
> contribute to EDK II if there is any GPL licensed code in the tree?
> (Even if it is contained in a clearly indicated package.) I guess
> using dual-licensed BSD/GPL is okay though?
> (EmbeddedPkg/Library/FdtLib)
> 
> -Jordan
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

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

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

[Jordan Justen]

On 2015-09-09 16:05:20, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
> > 
> > On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
> >> The recent expansions beyond BSD where all permissive licenses (BSD
> >> like) as far as I can tell.
> >> 
> >> I agree with Andrew, opening the door for GPL licensed code in EDK2
> >> will have severe consequences for products that are built using
> >> EDK2.
> > 
> > I don't think simply having a GplDriverPkg in the tree would have any
> > consequences for a platform that doesn't use any code in that package.
> > Obviously we could not make any core packages rely on that package.
> > 
> 
> So you have a legal degree and are speaking on behalf of your
> employer on this subject?

No and no. How about you? :)

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?

> > FWIW, I don't mind if the consensus is that GplDriverPkg must live in
> > a separate repo. But, it would be nice to hear a good reason why it
> > must live elsewhere.
> 
> Because GPL is not a permissive license. An accidental git grep and
> copying some code can change the license of the code that gets the
> GPL code pasted into it.

I like this argument. It is slightly tempered by the fact that git
grep always shows the source path, and thus 'GplDriverPkg' would be
obviously visible.

> Thus having GPL code in the same repository as BSD code can end up
> accidentally converting BSD code to GPL code over time.

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.

-Jordan

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

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

[Andrew Fish]

> On Sep 9, 2015, at 5:41 PM, Jordan Justen  wrote:
> 
> On 2015-09-09 16:05:20, Andrew Fish wrote:
>> 
>>> On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
>>> 
>>> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
 The recent expansions beyond BSD where all permissive licenses (BSD
 like) as far as I can tell.
 
 I agree with Andrew, opening the door for GPL licensed code in EDK2
 will have severe consequences for products that are built using
 EDK2.
>>> 
>>> I don't think simply having a GplDriverPkg in the tree would have any
>>> consequences for a platform that doesn't use any code in that package.
>>> Obviously we could not make any core packages rely on that package.
>>> 
>> 
>> 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. 

> 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. Your company started this edk2 project as a BSD project, 
and I assume there was a reason for that. 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 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. 

>>> FWIW, I don't mind if the consensus is that GplDriverPkg must live in
>>> a separate repo. But, it would be nice to hear a good reason why it
>>> must live elsewhere.
>> 
>> Because GPL is not a permissive license. An accidental git grep and
>> copying some code can change the license of the code that gets the
>> GPL code pasted into it.
> 
> I like this argument. It is slightly tempered by the fact that git
> grep always shows the source path, and thus 'GplDriverPkg' would be
> obviously visible.
> 

If the developer is even paying attention, or using a tool that highlights path 
vs. filename. Or maybe the path is too long to display and gets shortened in a 
way that Gpl is not obvious. Not to mention if this was so easy why not include 
the source for the FAT driver with the GPL sources? We could add 
EvilNonGplCompatibleLicence to the path and that would solve everything. 

>> Thus having GPL code in the same repository as BSD code can end up
>> accidentally converting BSD code to GPL code over time.
> 
> 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?

Thanks,

Andrew Fish

> -Jordan
> ___
> edk2-devel mailing list
> edk2-de...@lists.01.org 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E=
>  
> 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Jordan Justen]

On 2015-09-09 20:26:54, Andrew Fish wrote:
> > On Sep 9, 2015, at 5:41 PM, Jordan Justen  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?

Thanks,

-Jordan

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

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

[El-Haj-Mahmoud, Samer]

Adding back edk2-devel that got accidently dropped 

I am against putting any GPL licensed code in EDK2. Having it live in a 
separate repo and pulling an additional package from that repo is fine. But the 
main EDK2 repo needs to stay GPL-free.

Thanks,
--Samer


-Original Message-
From: af...@apple.com [mailto:af...@apple.com] 
Sent: Wednesday, September 09, 2015 6:05 PM
To: Jordan Justen 
Cc: El-Haj-Mahmoud, Samer ; Lenny Szubowicz 
; Karen Noel ; Ard Biesheuvel 
; edk2-devel-01 ; Cole 
Robinson ; Ademar de Souza Reis Jr. ; 
Alexander Graf ; qemu devel list ; 
Gabriel L. Somlo (GMail) ; Peter Jones ; 
Peter Batard ; Hannes Reinecke ; Reza Jelveh 
; Paolo Bonzini ; 
xen-devel@lists.xen.org; Laszlo Ersek ; Gerd Hoffmann 
; Doran, Mark 
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015


> On Sep 9, 2015, at 3:24 PM, Jordan Justen  wrote:
> 
> On 2015-09-09 12:11:26, El-Haj-Mahmoud, Samer wrote:
>> The recent expansions beyond BSD where all permissive licenses (BSD
>> like) as far as I can tell.
>> 
>> I agree with Andrew, opening the door for GPL licensed code in EDK2 
>> will have severe consequences for products that are built using EDK2.
> 
> I don't think simply having a GplDriverPkg in the tree would have any 
> consequences for a platform that doesn't use any code in that package.
> Obviously we could not make any core packages rely on that package.
> 

So you have a legal degree and are speaking on behalf of your employer on this 
subject? 

> This would just be a sanctioned, clear landing place for people that 
> cannot, or will not provide their driver under a permissive license.
> 
> This license will limit who can use drivers from this package. For 
> that reason, I hope that we will always ask if a contribution can be 
> permissively licensed instead.
> 
> Personally, I would prefer a 2-clause BSD only tree for simplicity, 
> but unfortunately, that sort of restriction has its own drawbacks as 
> well. (frustrated contributors and less contributions)
> 
> FWIW, I don't mind if the consensus is that GplDriverPkg must live in 
> a separate repo. But, it would be nice to hear a good reason why it 
> must live elsewhere.

Because GPL is not a permissive license. An accidental git grep and copying 
some code can change the license of the code that gets the GPL code pasted into 
it. Thus having GPL code in the same repository as BSD code can end up 
accidentally converting BSD code to GPL code over time. If GPL was OK with 
everyone we would have started with GPL. The good thing is the BDS code is GPL 
compatible so it can be used for GPL code and bug fixes in the BDS code can be 
merged into to GPL code, but this is a one way operation. 

If you don’t believe me please feel free to sit down and have a long 
conversation with Intel IP lawyers.


> (And, why that doesn't also apply to FatBinPkg.)
> 

There is no IP leakage from a binary. This FAT driver is licensed for use with 
EFI, and given this is a EFI code base that seemed like a good thing. 

I don’t pretent to understand the GPL FAT thing, I guess it is some kind of 
civil disobedience. it does not mater what license you strap on the code the 
the device makers still have to “pay the man”. 

Thanks,

Andrew Fish

PS As I stated before I’m fine removing all the binaries from the main repo, as 
you don’t really want binaries in your production repo, and source level 
debugging is a nice feature and all. 

> -Jordan
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Jordan Justen
>> Sent: Wednesday, September 09, 2015 12:58 PM
>> To: Andrew Fish 
>> Cc: Lenny Szubowicz ; Karen Noel 
>> ; Ard Biesheuvel ; 
>> edk2-devel-01 ; Reza Jelveh 
>> ; Alexander Graf ; qemu devel 
>> list ; Hannes Reinecke ; Gabriel 
>> L. Somlo (GMail) ; Peter Jones ; 
>> Peter Batard ; Gerd Hoffmann ; Cole 
>> Robinson ; Paolo Bonzini ; 
>> xen-devel@lists.xen.org; Laszlo Ersek ; Ademar de 
>> Souza Reis Jr. 
>> Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015
>> 
>> On 2015-09-09 10:04:50, Andrew Fish wrote:
>>> 
 On Sep 9, 2015, at 9:17 AM, Jordan Justen  
 wrote:
 
 So, related to this, I wonder 

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

[El-Haj-Mahmoud, Samer]

The recent expansions beyond BSD where all permissive licenses (BSD like) as 
far as I can tell.

I agree with Andrew, opening the door for GPL licensed code in EDK2 will have 
severe consequences for products that are built using EDK2. 



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Wednesday, September 09, 2015 12:58 PM
To: Andrew Fish 
Cc: Lenny Szubowicz ; Karen Noel ; Ard 
Biesheuvel ; edk2-devel-01 
; Reza Jelveh ; Alexander Graf 
; qemu devel list ; Hannes Reinecke 
; Gabriel L. Somlo (GMail) ; Peter Jones 
; Peter Batard ; Gerd Hoffmann 
; Cole Robinson ; Paolo Bonzini 
; xen-devel@lists.xen.org; Laszlo Ersek 
; Ademar de Souza Reis Jr. 
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> > 
> > So, related to this, I wonder how the community would feel about a 
> > GplDriverPkg. Would the community allow it as a new package in EDK 
> > II directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is 
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think some 
people are not comfortable with the FatBinPkg being in the tree due to the 
license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are 
> > some potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to 
> > a  permissive license, thereby limiting some users of the 
> > contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed  
> > packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory  
> > with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a fundamental 
> change, and would require employees to get reauthorized by their legal 
> departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree, and that 
appeared to be no big deal. No one brought this up as a fundamental change.

Just to be clear, are you saying Apple probably won't be able to contribute to 
EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess using 
dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

-Jordan
___
edk2-devel mailing list
edk2-de...@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

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

[Andrew Fish]

> On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> 
> On 2015-09-09 01:57:51, Laszlo Ersek wrote:
>> On 08/10/15 18:24, Laszlo Ersek wrote:
>>> Hi.
>>> 
>>> Let's do an OVMF BoF at this year's KVM Forum too.
>> 
>> Here's a preliminary task list, after some off-list discussion (I tried
>> to incorporate comments):
>> 
>> - create GPL'd fork called "ovmf" for expediting virt development
>>  (OvmfPkg, ArmVirtPkg)
>>  - maybe leverage the feature under
>>
>> >  > for
>>setting up a separate "tianocore/edk2-gpl" repo, for GPL'd
>>contributions [Jordan]
>>- repo separation by license could make things harder for packagers
>>  and QEMU bundling [Laszlo]
> 
> I would like OVMF to follow a plan for GPL that the whole EDK II
> community decides on.
> 
> I would also like to see EDK II add a (permissively licensed; BSD,
> MIT, etc) DriverPkg (DriversPkg?). We discussed this on the list
> recently:
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__thread.gmane.org_gmane.comp.bios.tianocore.devel_17544_focus-3D676=BQICAg=eEvniauFctOgLOKGJOplqw=1HnUuXD1wDvw67rut5_idw=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA=HauTLYzaQYz935VMYQCCR8xzuSADw1ZcWSSjSyEXIpw=
>  
> 
> So, related to this, I wonder how the community would feel about a
> GplDriverPkg. Would the community allow it as a new package in EDK II
> directly, or would a separate repo be required?
> 

I think we would need a separate repo, like the FAT driver. That is the only 
way to deal with the license issues. 

> With regards to adding it directly into the EDK II tree, here are some
> potential concerns that I might anticipate hearing from the community:
> 
> * It will make it easier for contributors to choose GPL compared to a
>  permissive license, thereby limiting some users of the contribution
> 
> * GPL code will more easily be copied into the permissively licensed
>  packages
> 
> * Some might refuse to look at EDK II entirely if it has a directory
>  with GPL source code in it
> 

Or have their rights to contribute revoked since this is a fundamental change, 
and would require employees to get reauthorized by their legal departments to 
contribute. 

> Of these, I personally only sympathize with the first.
> 

Your employer probably has issues with all of this. 

> Regarding the separate OVMF repo, my hope is that it is more of a OVMF
> specific working area, rather than a 'GPL OVMF'. For example, patches
> or features that we've not yet figured out how to upstream, but we
> hopefully plan to.
> 

Mixing is never going to work. If you mix then the pure BSD edk2 will fork and 
continue, I’m guessing a lot of the Intel resources will work on that version 
as it will be the one enabling Intel products. 

> Additionally, it makes sense to use it as needed for OVMF specific
> releases. (Ie, OVMF release tags)
> 

Seems to me we are really solving the wrong problem. What we need is a smaller 
BSD edk2 project that supports the industry standards and works on some set of 
BSD platforms. There can be down stream consumers that have more platform 
support, and different licenses. 

Seems the real problem is the unpredictable changes to MdePkg libraries, and 
MdeModulePkg infrastructure. So it is the lack of a transparent plan, and 
discussion about upcoming changes that break compatibility between different 
projects. So the solution is to keep everything in the tree working on master. 
We should fix the edk2 process, and place a process in place to communicate 
pending non backward compatible changes in the edk2 to down stream consumers. 

Don’t forget a lot (majority) of edk2 based products that ship today live in a 
separate repo that likely contains a UDK or specific version of edk2 with 
cherry picked patches. So this processes is kind of already happening in the 
non-GPL world….

Thanks,

Andrew Fish

> -Jordan
> 
>> - document the rules / justification for "ovmf" (licensing
>>  conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed
>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>  sense
>> - remove encumbered FAT driver
>> - import Peter Batard's GPL r/o FAT driver port of GRUB's
>> - secure OpenSSL linking exception for the former from the copyright
>>  holders (Peter Batard, GRUB project)
>> - "ovmf" should be periodically rebased / should fetch+merge edk2 as
>>  master (arguments both for and against merging); distros should
>>  then track "ovmf" as their upstream, not edk2
>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)
>> - do OVMF releases, maybe in sync with QEMU's releases
>>  - we can probably build from known good revisions from git [Alex]
>> - revive Q35 SATA driver work / poke Reza

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

[Jordan Justen]

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> > 
> > So, related to this, I wonder how the community would feel about a
> > GplDriverPkg. Would the community allow it as a new package in EDK II
> > directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think
some people are not comfortable with the FatBinPkg being in the tree
due to the license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are some
> > potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to a
> >  permissive license, thereby limiting some users of the contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed
> >  packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory
> >  with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a
> fundamental change, and would require employees to get reauthorized
> by their legal departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree,
and that appeared to be no big deal. No one brought this up as a
fundamental change.

Just to be clear, are you saying Apple probably won't be able to
contribute to EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess
using dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

-Jordan

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

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

[Paolo Bonzini]

Well, FatPkg is only superficially permissive and not even open source, so 
there is a precedent. (A precedent that, I might add, happens to violate 
SourceForge's the off service).

When we import edk2 into Fedora we just remove FatBinPkg. We would think twice 
before contributing to it, but do not make any kind of fuss about it.

GPL is just the same. For example, it would be possible to have an 
automatically-updated git repo that omits the GPL directory; and development 
would then be easier for people whose legal departments tend not to influence 
the engineers' productivity.

In fact:

1) it is not like, among non-Intel contributors, proprietary software companies 
have the lion's share of edk2 commits, and they probably use Tiano releases. 
Intel could strip any GPL pieces as part of the Tiano release process.

2) the GPL is working just fine for Linux, which is not that different from 
UEFI. So, picture me skeptical. If anything, what Linux can teach edk2 is that 
a closed prices and balkanized trees are a direct cause of the abysmal security 
of those implementations.

Paolo

-Original Message-
From: El-Haj-Mahmoud, Samer [samer.el-haj-mahm...@hpe.com]
Received: mercoledì, 09 set 2015, 21:12
To: Jordan Justen [jordan.l.jus...@intel.com]; Andrew Fish [af...@apple.com]
CC: Lenny Szubowicz [lenn...@redhat.com]; Karen Noel [kn...@redhat.com]; Ard 
Biesheuvel [ard.biesheu...@linaro.org]; edk2-devel-01 [edk2-de...@ml01.01.org]; 
Reza Jelveh [reza.jel...@tuhh.de]; Alexander Graf [ag...@suse.de]; qemu devel 
list [qemu-de...@nongnu.org]; Hannes Reinecke [h...@suse.de]; Gabriel L. Somlo 
(GMail) [gso...@gmail.com]; Peter Jones [pjo...@redhat.com]; Peter Batard 
[p...@akeo.ie]; Gerd Hoffmann [kra...@redhat.com]; Cole Robinson 
[crobi...@redhat.com]; Paolo Bonzini [pbonz...@redhat.com]; 
xen-devel@lists.xen.org [xen-devel@lists.xen.org]; Laszlo Ersek 
[ler...@redhat.com]; Ademar de Souza Reis Jr. [ar...@redhat.com]
Subject: RE: [edk2] EDK II & GPL - Re:  OVMF BoF @ KVM Forum 2015

The recent expansions beyond BSD where all permissive licenses (BSD like) as 
far as I can tell.

I agree with Andrew, opening the door for GPL licensed code in EDK2 will have 
severe consequences for products that are built using EDK2. 



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan 
Justen
Sent: Wednesday, September 09, 2015 12:58 PM
To: Andrew Fish 
Cc: Lenny Szubowicz ; Karen Noel ; Ard 
Biesheuvel ; edk2-devel-01 
; Reza Jelveh ; Alexander Graf 
; qemu devel list ; Hannes Reinecke 
; Gabriel L. Somlo (GMail) ; Peter Jones 
; Peter Batard ; Gerd Hoffmann 
; Cole Robinson ; Paolo Bonzini 
; xen-devel@lists.xen.org; Laszlo Ersek 
; Ademar de Souza Reis Jr. 
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen  wrote:
> > 
> > So, related to this, I wonder how the community would feel about a 
> > GplDriverPkg. Would the community allow it as a new package in EDK 
> > II directly, or would a separate repo be required?
> > 
> 
> I think we would need a separate repo, like the FAT driver. That is 
> the only way to deal with the license issues.

There doesn't seem to be any guiding rules here. For example, I think some 
people are not comfortable with the FatBinPkg being in the tree due to the 
license. Why is that okay?

> > With regards to adding it directly into the EDK II tree, here are 
> > some potential concerns that I might anticipate hearing from the community:
> > 
> > * It will make it easier for contributors to choose GPL compared to 
> > a  permissive license, thereby limiting some users of the 
> > contribution
> > 
> > * GPL code will more easily be copied into the permissively licensed  
> > packages
> > 
> > * Some might refuse to look at EDK II entirely if it has a directory  
> > with GPL source code in it
> > 
> 
> Or have their rights to contribute revoked since this is a fundamental 
> change, and would require employees to get reauthorized by their legal 
> departments to contribute.

We've recently expanded beyond just allowing BSD code into the tree, and that 
appeared to be no big deal. No one brought this up as a fundamental change.

Just to be clear, are you saying Apple probably won't be able to contribute to 
EDK II if there is any GPL licensed code in the tree?
(Even if it is contained in a clearly indicated package.) I guess using 
dual-licensed BSD/GPL is okay though?
(EmbeddedPkg/Library/FdtLib)

-Jordan
___
edk2-devel mailing list