Re: [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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Laszlo Ersek]

On 09/09/15 18:17, 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:
> 
> http://thread.gmane.org/gmane.comp.bios.tianocore.devel/17544/focus=676
> 
> 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?
> 
> 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
> 
> Of these, I personally only sympathize with the first.
> 
> 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.

Yes, the "OVMF specific working area" is also my main goal with this.

If we can find a way to (a) replace the FAT driver with the libre
software one, and (b) more generally, accept GPL drivers, without
depending on this separate OVMF repo, that's great. So "owning" those
modules is not a goal per se, just something the new repo should cover
in case we can't solve it within edk2. (E.g. with your GplDriverPkg idea.)

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

Good idea.

Thanks!
Laszlo

> 
> -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
>>   - Hannes and Gabriel have refreshed patches, but their versions differ
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

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

[Blibbet]

> I don’t understand the issue BSD licensed code?
> It should be compatible with the GPL?
> The GPL code could merge bug fixes from the BSD
> source base as needed. It is just the BDS source
> base that can not take back GPL code.

I'm not sure I understand, I presume you understand all BSD/GPL
licensing issues very well. :-)

Sure, mixture of licenses makes life more difficult. Not an excuse for
ignoring non-BSD innovations and embracing Linux OSV/OEM community with
their preferred license. GPL'ed LibreOffice bugfixes can't go upstream
to BSD-like, ASF2 license of Apache OpenOffice, but that's life. Even
with BSD licensed code, vendor's often don't contribute bugs back, look
at XNU.

Issue: Linux community uses often uses GPL, UEFI Forum and Tianocore
forbids any but BSD (except gives Microsoft freedom to pick any license
they want for FAT).

Windows and OSX aside, for FOSS OSVs, like FreeBSD and Linux-based ones,
the open source community often uses open source licenses other than
BSD, including GPL. All of that community contributions are lost to
TIanocore and UEFI Forum. And to closed-source IBVs who can't handle GPL
taint exposing their code.

I'd hope that any new code that the Linux/FreeBSD/FOSS OS community
needs could be BSD-licensed, so it could be upstreamed to Tianocore, if
they deem to approve it. An IBV (or other group) that helps direct any
open source contributions could help manage that. Ungroomed community
contributions are much more likely to be unusable by BSD-centric subset
of firmware community. Apple and Microsoft are last in the list of big
players that don't properly leverage open source community
contributions, along with silicon vendors, all of which control UEFI
Forum, so likely no change there. :-(

>> Look at the coreboot blog, the other week the Purism BIOS developer was
>> talking about a "Free Software port of FSP". That should be a shared
>> effort by all Linux OEMs/vendors, not shouldered by a single OEM. A
>> Linux-centric IBV could be getting help from multiple companies -- like
>> Linaro does with ARM -- to help with this effort. It could be part of
>> Linux Foundation's Core Infrastructure Initiative, maybe.
>>
>> They should also tailor Linux-friendly ACPI, like recent thread about
>> Linux standardization of _DSD. As well as not include a WBPT table in
>> Linux OEM systems, and look at the other tables to see what's should be
>> removed.
>>
>
> In general it is not good form to discuss pre-released industry standard
> stuff not on the standards group mailing list. The idea is to not have
folks
> implementing pre released stuff that causes interoperability issues.

Sorry,  I don't understand this comment. Nothing I mentioned above was
pre-released. Coreboot blog post was public. _DSD mailing list post was
public. I'm not on any non-public firmware communities.

The UEFI Forum only has 1 community, EDK2-devel, to go to for
experience. I'd love to see a non-dev discussion list, where I could
mention some stifling firmware patent issues that scare me, which I've
omitted from discussing on a list with engineers eager to stay ignorant
with patents so they can more easily patent more things. :-)

>> Alternately, the UEFI Forum should create a non-BSD tree to contain
>> this, not just focus on BSD for the fully-closed-source end of the
>> spectrum, and work with some FOSS-centric OSVs to better support UEFI
>> using their community's models.
>>
>
> The UEFI Forum only publishes the UEFI tests, SCTs. The UEFI Forum
> owns the specifications, but does not own or advocate for implementations
> (other than advocating conformance to the specification).

I guess you could frame it that way.

The UEFI forum maintains a BSD codebase where non-FOSS OSVs thrive, and
GPL OSVs are stifled.

If they chose to help FOSS OSVs, the UEFI Forum could choose to also
maintain a codebase with other-than-BSD code, and not ignore the non-BSD
contributions from the FOSS community.

I just mentioned the UEFI Forum could -- if they chose -- also maintain
another codebase, where their FOSS ISVs could also use.

I expect an IBV would probably be a better choice than UEFI Forum for
anything beyond BSD, given current members anti-non-BSD position.

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

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

[Andrew Fish]

> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.jus...@intel.com> 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 <af...@apple.com>
>> Cc: Lenny Szubowicz <lenn...@redhat.com>; Karen Noel <kn...@redhat.com>; Ard 
>> Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel-01 
>> <edk2-devel@lists.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-de...@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
>> 
>> On 2015-09-09 10:04:50, Andrew Fish wrote:
>>> 
>>>> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> 
>>>> 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 fo

Re: [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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [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: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Blibbet]

Short term an OVMF-centric solution is good.

But long term, I think Linux needs a Linux-friendly IBV to build native
UEFI -- as well as OVMF-flavored UEFI -- with non-BSD licensed community
code. If you restrict this to just OVMF, any GPL innovations will only
happen at virtual level. Right now, boot loaders (eg, rEFInd) and VM
projects (VirtualBox) are the only ones to benefit from UEFI
non-BSD-licensed code. An IBV could offer these enhancements to Linux
OEMs, not just server VMs. Linaro is already an IBV, to a degree, they
produce UEFI binaries for the supported dev boards, as part of BSP build
process.

Look at the coreboot blog, the other week the Purism BIOS developer was
talking about a "Free Software port of FSP". That should be a shared
effort by all Linux OEMs/vendors, not shouldered by a single OEM. A
Linux-centric IBV could be getting help from multiple companies -- like
Linaro does with ARM -- to help with this effort. It could be part of
Linux Foundation's Core Infrastructure Initiative, maybe.

They should also tailor Linux-friendly ACPI, like recent thread about
Linux standardization of _DSD. As well as not include a WBPT table in
Linux OEM systems, and look at the other tables to see what's should be
removed.

Alternately, the UEFI Forum should create a non-BSD tree to contain
this, not just focus on BSD for the fully-closed-source end of the
spectrum, and work with some FOSS-centric OSVs to better support UEFI
using their community's models.

I hope an IBV is listening. Create a separate project from your current
closed-source code, and fully-embrace the open source community.

Today, Sage Engineering is the only Open Source-friendly IBV that I'm
aware of. They mostly focus on coreboot, not UEFI, though. (Like
Phoenix, their blob recently went dark, I hope they're doing ok.)

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

Re: [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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [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-de...@lists.xen.org [xen-de...@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 <af...@apple.com>
Cc: Lenny Szubowicz <lenn...@redhat.com>; Karen Noel <kn...@redhat.com>; Ard 
Biesheuvel <ard.biesheu...@linaro.org>; edk2-devel-01 
<edk2-devel@lists.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-de...@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

On 2015-09-09 10:04:50, Andrew Fish wrote:
> 
> > On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.jus...@intel.com> 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 a