[Qemu-devel] OVMF BoF @ KVM Forum 2015

[Qemu-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

Hi.

Let's do an OVMF BoF at this year's KVM Forum too.

Paolo will present

  Securing secure boot: system management mode in KVM and Tiano Core

on Thursday, August 20, in the 5:00pm - 5:30pm time slot.

Right after that, the BoF section starts at 5:30pm:

  http://events.linuxfoundation.org/events/kvm-forum/program/schedule

We should convene and discuss stuff. I don't have an agenda, so people
should bring their ideas and questions (famous last words).

As food for thought, I tried to collect the feature-looking patches from
the git history that have been committed since last year's KVM Forum,
and to match them against patch sets on the mailing list:

  git log --reverse --oneline --since=2014-10-14 -- \
      OvmfPkg/ \
      ArmVirtPkg/ \
      ArmPlatformPkg/ArmVirtualizationPkg/

I attempted to sort them into categories. You can see the list below.
The ordering is totally random, it's just what I ended up with.
Corrections / additions welcome.

Personally, one (missing) feature I'd like to see discussed is
"SataControllerDxe in OVMF". SMM will require Q35, and the only "IDE"
that Q35 speaks is SATA / AHCI. (And you can't disable that controller
on Q35.)

Anyway, here goes.

Features completed
------------------

(... unless marked [pending])

- Xen guest:

  - PV block driver:
    [PATCH v4 00/19] Introducing Xen PV block driver to OVMF

  - Xen for ARM:
    [PATCH v5 00/29] Xen/ARM guest support

- PCI / hw related:

  - PCI on ARM; detect VGA and USB keyboard:
    [PATCH v3 00/28] ArmVirtualizationPkg/ArmVirtualizationQemu: enable PCI
    [PATCH 0/4] ArmVirtualizationPkg: PlatformIntelBdsLib: dynamic console setup

  - support for Q35:
    [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type
    [PATCH 1/1] OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges

  - USB3 (ARM and x86):
    [PATCH v2 2/4] ArmVirtualizationPkg/ArmVirtualizationQemu: include XHCI driver
    [PATCH v2 4/4] OvmfPkg: include XHCI driver

  - support TCO watchdog emulation features:
    [PATCH v5 2/2] OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) register

  - virtio-vga:
    [PATCH] Add virtio-vga support

  - support extra PCI root buses for NUMA-locality with assigned
    devices:
    [PATCH v3 00/23] OvmfPkg: support extra PCI root buses

- QEMU config integration:

  - fw_cfg, boot order, and -kernel booting on ARM:
    [PATCH v4 00/13] ArmVirtualizationQemu: support fw_cfg, bootorder, '-kernel'
    [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

  - support for "-boot menu=on[,splash-time=N]":
    [PATCH v2 0/3] OVMF, ArmVirt: consume QEMU's "-boot menu=on[,splash-time=N]"

  - ACPI tables for ARM:
    [PATCH v2 0/3] ACPI over fw_cfg for ARM/AARCH64 qemu guests

  - SMBIOS features: Type 0 default, and SMBIOS 3.0 support on ARM and
    x86:
    [PATCH] OvmfPkg/SMBIOS: Provide default Type 0 (BIOS Information) structure
    [PATCH v2 0/6] ArmVirtPkg/ArmVirtQemu: support SMBIOS
    [PATCH 0/9] OvmfPkg, ArmVirtPkg: SMBIOS 3.0, round 2

- ARM specific:

  - "fun" with the caches:
    [PATCH v4 0/5] ArmVirtualizationPkg: explicit cache maintenance

  - secure boot:
    [PATCH v3 0/3] ArmVirtualizationQemu: enable support for UEFI Secure Boot

  - performance optimization:
    [PATCH v2 0/6] ArmPkg/ArmVirtPkg: GIC revision detection

  - better handling for the typical Linux terminal (generic driver code,
    hooked up to ArmVirt):
    [PATCH V4 0/5] Add TtyTerm terminal type

- SMM for OVMF (in progress):
    [PATCH 00/11] Bits and pieces
    [PATCH 00/58] OvmfPkg: support SMM for better security (single VCPU, IA32) [pending]

- Build system:

  - moving to NASM:
    [PATCH 0/7] Convert OVMF assembly to NASM
    [PATCH v2 0/6] OvmfPkg/XenBusDxe: Convert *.asm to NASM.

  - accept UTF-8 in .uni files:
    [PATCH v4 00/10] Support UTF-8 in .uni string files

  - LLVM/clang support for AARCH64 (in progress):
    [PATCH v4 00/13] BaseTools: unify all GCC linker scripts
    [PATCH v4 0/7] small model and clang support for AARCH64 [pending]

- UEFI compliance:

  - support for OsIndications:
    [PATCH v2 0/9] OvmfPkg: PlatformBdsLib cleanups and improvements

  - signal ReadyToBoot:
    [PATCH 1/8] OvmfPkg/PlatformBdsLib: Signal ReadyToBoot before booting QEMU kernel

  - signal EndOfDxe:
    [PATCH v2] ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit
    [PATCH v2 0/6] OvmfPkg: save S3 state at EndOfDxe

  - fix Serial IO Protocol issues flagged by SCT
    [PATCH V4 0/5] Some improvements on serial terminal

- other

  - big OVMF guests:
    [PATCH v2 0/4] OvmfPkg: enable >= 64 GB guests

  - IPv6 (conditionally enabled):
    [PATCH v2] OvmfPkg: enable the IPv6 support

  - many fixes for toolchain warnings and C language misuse

Thanks
Laszlo

Re: [Qemu-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

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
    <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> 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]
- 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

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

[Jordan Justen]

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
>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> 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.

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

-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

Re: [Qemu-devel] EDK II & GPL - Re: [edk2] 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
>>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> 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

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

[Andrew Fish]

> On Sep 9, 2015, at 9:17 AM, Jordan Justen <jordan.l.justen@intel.com> 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
>>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__permalink.gmane.org_gmane.comp.bios.edk2.devel_941&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=NkAF9nkaYv90MC55j7jme4YajlZK14oKVu3L61jRnJ4&e= > 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&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=HauTLYzaQYz935VMYQCCR8xzuSADw1ZcWSSjSyEXIpw&e= 
> 
> 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
>>  - Hannes and Gabriel have refreshed patches, but their versions differ
>> 
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=sqGoNWq1TnVknPoRJPafosJli9Yd2f7SM7YQcWQptcc&e= 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Izfl0sCkWmvl39u6ZohbZ52fhf2U-GzLJ9cQpL9sdnA&s=sqGoNWq1TnVknPoRJPafosJli9Yd2f7SM7YQcWQptcc&e= 

Re: [Qemu-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 <jordan.l.justen@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 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

Re: [Qemu-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-bounces@lists.01.org] On Behalf Of Jordan Justen
Sent: Wednesday, September 09, 2015 12:58 PM
To: Andrew Fish <afish@apple.com>
Cc: Lenny Szubowicz <lennysz@redhat.com>; Karen Noel <knoel@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel-01 <edk2-devel@lists.01.org>; Reza Jelveh <reza.jelveh@tuhh.de>; Alexander Graf <agraf@suse.de>; qemu devel list <qemu-devel@nongnu.org>; Hannes Reinecke <hare@suse.de>; Gabriel L. Somlo (GMail) <gsomlo@gmail.com>; Peter Jones <pjones@redhat.com>; Peter Batard <pete@akeo.ie>; Gerd Hoffmann <kraxel@redhat.com>; Cole Robinson <crobinso@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; xen-devel@lists.xen.org; Laszlo Ersek <lersek@redhat.com>; Ademar de Souza Reis Jr. <areis@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.justen@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 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: [Qemu-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-bounces@lists.01.org] On Behalf Of Jordan Justen
> Sent: Wednesday, September 09, 2015 12:58 PM
> To: Andrew Fish <afish@apple.com>
> Cc: Lenny Szubowicz <lennysz@redhat.com>; Karen Noel <knoel@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel-01 <edk2-devel@lists.01.org>; Reza Jelveh <reza.jelveh@tuhh.de>; Alexander Graf <agraf@suse.de>; qemu devel list <qemu-devel@nongnu.org>; Hannes Reinecke <hare@suse.de>; Gabriel L. Somlo (GMail) <gsomlo@gmail.com>; Peter Jones <pjones@redhat.com>; Peter Batard <pete@akeo.ie>; Gerd Hoffmann <kraxel@redhat.com>; Cole Robinson <crobinso@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; xen-devel@lists.xen.org; Laszlo Ersek <lersek@redhat.com>; Ademar de Souza Reis Jr. <areis@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.justen@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 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: [Qemu-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

[Andrew Fish]

> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.justen@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-bounces@lists.01.org] On Behalf Of Jordan Justen
>> Sent: Wednesday, September 09, 2015 12:58 PM
>> To: Andrew Fish <afish@apple.com>
>> Cc: Lenny Szubowicz <lennysz@redhat.com>; Karen Noel <knoel@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel-01 <edk2-devel@lists.01.org>; Reza Jelveh <reza.jelveh@tuhh.de>; Alexander Graf <agraf@suse.de>; qemu devel list <qemu-devel@nongnu.org>; Hannes Reinecke <hare@suse.de>; Gabriel L. Somlo (GMail) <gsomlo@gmail.com>; Peter Jones <pjones@redhat.com>; Peter Batard <pete@akeo.ie>; Gerd Hoffmann <kraxel@redhat.com>; Cole Robinson <crobinso@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; xen-devel@lists.xen.org; Laszlo Ersek <lersek@redhat.com>; Ademar de Souza Reis Jr. <areis@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.justen@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 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=yvzCzDdEDVjZEzZI9AOKS3bV8FD8sjx1LqCww7Vn3rA&s=p1Kcan7EiiR_ZC78qKT0jfGMD0yx2Wpv5vJ6LnwXkD0&e= 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=yvzCzDdEDVjZEzZI9AOKS3bV8FD8sjx1LqCww7Vn3rA&s=p1Kcan7EiiR_ZC78qKT0jfGMD0yx2Wpv5vJ6LnwXkD0&e= 

Re: [Qemu-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: afish@apple.com [mailto:afish@apple.com] 
Sent: Wednesday, September 09, 2015 6:05 PM
To: Jordan Justen <jordan.l.justen@intel.com>
Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahmoud@hpe.com>; Lenny Szubowicz <lennysz@redhat.com>; Karen Noel <knoel@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel-01 <edk2-devel@lists.01.org>; Cole Robinson <crobinso@redhat.com>; Ademar de Souza Reis Jr. <areis@redhat.com>; Alexander Graf <agraf@suse.de>; qemu devel list <qemu-devel@nongnu.org>; Gabriel L. Somlo (GMail) <gsomlo@gmail.com>; Peter Jones <pjones@redhat.com>; Peter Batard <pete@akeo.ie>; Hannes Reinecke <hare@suse.de>; Reza Jelveh <reza.jelveh@tuhh.de>; Paolo Bonzini <pbonzini@redhat.com>; xen-devel@lists.xen.org; Laszlo Ersek <lersek@redhat.com>; Gerd Hoffmann <kraxel@redhat.com>; Doran, Mark <mark.doran@intel.com>
Subject: Re: [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015


> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.justen@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-bounces@lists.01.org] On Behalf 
>> Of Jordan Justen
>> Sent: Wednesday, September 09, 2015 12:58 PM
>> To: Andrew Fish <afish@apple.com>
>> Cc: Lenny Szubowicz <lennysz@redhat.com>; Karen Noel 
>> <knoel@redhat.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; 
>> edk2-devel-01 <edk2-devel@lists.01.org>; Reza Jelveh 
>> <reza.jelveh@tuhh.de>; Alexander Graf <agraf@suse.de>; qemu devel 
>> list <qemu-devel@nongnu.org>; Hannes Reinecke <hare@suse.de>; Gabriel 
>> L. Somlo (GMail) <gsomlo@gmail.com>; Peter Jones <pjones@redhat.com>; 
>> Peter Batard <pete@akeo.ie>; Gerd Hoffmann <kraxel@redhat.com>; Cole 
>> Robinson <crobinso@redhat.com>; Paolo Bonzini <pbonzini@redhat.com>; 
>> xen-devel@lists.xen.org; Laszlo Ersek <lersek@redhat.com>; Ademar de 
>> Souza Reis Jr. <areis@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.justen@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 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mai
>> lman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuX
>> D1wDvw67rut5_idw&m=yvzCzDdEDVjZEzZI9AOKS3bV8FD8sjx1LqCww7Vn3rA&s=p1Kc
>> an7EiiR_ZC78qKT0jfGMD0yx2Wpv5vJ6LnwXkD0&e=
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mail
> man_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=yvzCzDdEDVjZEzZI9AOKS3bV8FD8sjx1LqCww7Vn3rA&s=p1Kcan7EiiR_ZC78qKT0jfGMD0yx2Wpv5vJ6LnwXkD0&e=

Re: [Qemu-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 <jordan.l.justen@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?

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

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

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 4116 bytes --]


> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.justen@intel.com> wrote:
> 
> On 2015-09-09 16:05:20, Andrew Fish wrote:
>> 
>>> On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.justen@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?
> 
> 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-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU&s=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=QYa4zV8t1IKrqv8dzBT9QGeAY0RWiBcTz1WwIesvScU&s=nVrllStzjUOtvIbFx2GiI-npvnVHMREDrHQ1CcfBD2E&e=>

[-- Attachment #2: Type: text/html, Size: 20831 bytes --]

Re: [Qemu-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 <jordan.l.justen@intel.com> wrote:
> > On 2015-09-09 16:05:20, Andrew Fish wrote:
> >> So you have a legal degree and are speaking on behalf of your
> >> employer on this subject?
> > 
> > No and no. How about you? :)
> 
> No but I have to review any code contributed to the open source
> project to make sure it follows the corporate polices.

Is Apple corporate policy that you could never contribute to a project
that has a GPL directory in the tree?

> > Nevertheless, I have not heard the interpretation that just having GPL
> > in a source tree would impact your code, even if you do not include,
> > nor link to it. Is this Apple's interpretation of how GPL works?
> 
> No but thanks for making my point for me. 1st off the rules are made
> by lawyers and managers so you trying to argue logic is kind of
> funny. What does logic have to do with it.

Whoa! What's next in this crazy world? Dogs and cats living together!
Mass hysteria! How can we be sure that the lawyers won't decide that
BSD means GPL and vice versa? ;)

> Your company started this edk2 project as a BSD project, and I
> assume there was a reason for that.

And then more licenses were added.

> The reasons rules like this end up getting made is that developers
> like you are confused about the company policy regarding open
> source, closed source and protecting intellectual property rights.
> So your very smart and well versed and you are confused, so

I don't think I'm confused (or smart :), but you are trying hard to
make it seem confusing and scary.

Anyway, you are correct. We do have rules. But, I don't think those
rules prevent us from discussing *possible* changes to those rules.

> some more jr. engineer has no hope of getting it right and would
> copy the GPL code and be clueless to what he just did. As I always
> say a development process exists to slow down the best developer, at
> the price of preventing the most jr. developers from doing something
> stupid.

If we have another repo with GplDriverPkg, then I guess the same jr.
developer might just go find the code over there and copy it.

> > I would be more worried about the GPL based drivers becoming too
> > featureful over time, and the permissively licensed code not being
> > very useful. For example, I'm worried that the non-GPL OVMF may end up
> > missing a lot of features.
> 
> Then logically you should just make OVMF a GPL project?

Not if you are someone that prefers permissive source licenses, such
as myself.

I'm basically trying to argue the other side of this to not let the
GPL FUD go by unimpeded.

Laszlo's email raised the GPL question, but I was not sure what the
EDK II community would accept with regards to GPL. Thus ... I asked. I
guess I'm getting a better idea with regards to Apple and HP. :)

In your opinion, would we be able to discuss patches for a *separate*
repo with GplDriverPkg on edk2-devel?

Thanks,

-Jordan

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

[Alexander Graf]

> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.justen@intel.com>:
> 
> On 2015-09-09 20:26:54, Andrew Fish wrote:
>>> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.justen@intel.com> wrote:
>>>> On 2015-09-09 16:05:20, Andrew Fish wrote:
>>>> So you have a legal degree and are speaking on behalf of your
>>>> employer on this subject?
>>> 
>>> No and no. How about you? :)
>> 
>> No but I have to review any code contributed to the open source
>> project to make sure it follows the corporate polices.
> 
> Is Apple corporate policy that you could never contribute to a project
> that has a GPL directory in the tree?
> 
>>> Nevertheless, I have not heard the interpretation that just having GPL
>>> in a source tree would impact your code, even if you do not include,
>>> nor link to it. Is this Apple's interpretation of how GPL works?
>> 
>> No but thanks for making my point for me. 1st off the rules are made
>> by lawyers and managers so you trying to argue logic is kind of
>> funny. What does logic have to do with it.
> 
> Whoa! What's next in this crazy world? Dogs and cats living together!
> Mass hysteria! How can we be sure that the lawyers won't decide that
> BSD means GPL and vice versa? ;)
> 
>> Your company started this edk2 project as a BSD project, and I
>> assume there was a reason for that.
> 
> And then more licenses were added.
> 
>> The reasons rules like this end up getting made is that developers
>> like you are confused about the company policy regarding open
>> source, closed source and protecting intellectual property rights.
>> So your very smart and well versed and you are confused, so
> 
> I don't think I'm confused (or smart :), but you are trying hard to
> make it seem confusing and scary.
> 
> Anyway, you are correct. We do have rules. But, I don't think those
> rules prevent us from discussing *possible* changes to those rules.
> 
>> some more jr. engineer has no hope of getting it right and would
>> copy the GPL code and be clueless to what he just did. As I always
>> say a development process exists to slow down the best developer, at
>> the price of preventing the most jr. developers from doing something
>> stupid.
> 
> If we have another repo with GplDriverPkg, then I guess the same jr.
> developer might just go find the code over there and copy it.
> 
>>> I would be more worried about the GPL based drivers becoming too
>>> featureful over time, and the permissively licensed code not being
>>> very useful. For example, I'm worried that the non-GPL OVMF may end up
>>> missing a lot of features.
>> 
>> Then logically you should just make OVMF a GPL project?
> 
> Not if you are someone that prefers permissive source licenses, such
> as myself.
> 
> I'm basically trying to argue the other side of this to not let the
> GPL FUD go by unimpeded.
> 
> Laszlo's email raised the GPL question, but I was not sure what the
> EDK II community would accept with regards to GPL. Thus ... I asked. I
> guess I'm getting a better idea with regards to Apple and HP. :)
> 
> In your opinion, would we be able to discuss patches for a *separate*
> repo with GplDriverPkg on edk2-devel?

In fact, could we just make the non-free FAT source and GPL FAT source both be git submodules? Then whoever clones the repo can get the license flavor he's least scared about. Or alternatively instead of pulling in a GPL licensed FAT driver we use a BSD licensed one. I'm sure someone has one of those too ;).

Also for the record, the FAT driver problem is that the source license states that it can not be used in certain circumstances, which by common interpretation makes it non-free. The fact that there is a binary or source doesn't matter fwiw.


Alex

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

[Andrew Fish]

> On Sep 9, 2015, at 11:19 PM, Alexander Graf <agraf@suse.de> wrote:
> 
> 
> 
>> Am 10.09.2015 um 07:32 schrieb Jordan Justen <jordan.l.justen@intel.com>:
>> 
>> On 2015-09-09 20:26:54, Andrew Fish wrote:
>>>> On Sep 9, 2015, at 5:41 PM, Jordan Justen <jordan.l.justen@intel.com> wrote:
>>>>> On 2015-09-09 16:05:20, Andrew Fish wrote:
>>>>> So you have a legal degree and are speaking on behalf of your
>>>>> employer on this subject?
>>>> 
>>>> No and no. How about you? :)
>>> 
>>> No but I have to review any code contributed to the open source
>>> project to make sure it follows the corporate polices.
>> 
>> Is Apple corporate policy that you could never contribute to a project
>> that has a GPL directory in the tree?
>> 
>>>> Nevertheless, I have not heard the interpretation that just having GPL
>>>> in a source tree would impact your code, even if you do not include,
>>>> nor link to it. Is this Apple's interpretation of how GPL works?
>>> 
>>> No but thanks for making my point for me. 1st off the rules are made
>>> by lawyers and managers so you trying to argue logic is kind of
>>> funny. What does logic have to do with it.
>> 
>> Whoa! What's next in this crazy world? Dogs and cats living together!
>> Mass hysteria! How can we be sure that the lawyers won't decide that
>> BSD means GPL and vice versa? ;)
>> 
>>> Your company started this edk2 project as a BSD project, and I
>>> assume there was a reason for that.
>> 
>> And then more licenses were added.
>> 
>>> The reasons rules like this end up getting made is that developers
>>> like you are confused about the company policy regarding open
>>> source, closed source and protecting intellectual property rights.
>>> So your very smart and well versed and you are confused, so
>> 
>> I don't think I'm confused (or smart :), but you are trying hard to
>> make it seem confusing and scary.
>> 
>> Anyway, you are correct. We do have rules. But, I don't think those
>> rules prevent us from discussing *possible* changes to those rules.
>> 
>>> some more jr. engineer has no hope of getting it right and would
>>> copy the GPL code and be clueless to what he just did. As I always
>>> say a development process exists to slow down the best developer, at
>>> the price of preventing the most jr. developers from doing something
>>> stupid.
>> 
>> If we have another repo with GplDriverPkg, then I guess the same jr.
>> developer might just go find the code over there and copy it.
>> 
>>>> I would be more worried about the GPL based drivers becoming too
>>>> featureful over time, and the permissively licensed code not being
>>>> very useful. For example, I'm worried that the non-GPL OVMF may end up
>>>> missing a lot of features.
>>> 
>>> Then logically you should just make OVMF a GPL project?
>> 
>> Not if you are someone that prefers permissive source licenses, such
>> as myself.
>> 
>> I'm basically trying to argue the other side of this to not let the
>> GPL FUD go by unimpeded.
>> 
>> Laszlo's email raised the GPL question, but I was not sure what the
>> EDK II community would accept with regards to GPL. Thus ... I asked. I
>> guess I'm getting a better idea with regards to Apple and HP. :)
>> 
>> In your opinion, would we be able to discuss patches for a *separate*
>> repo with GplDriverPkg on edk2-devel?
> 
> In fact, could we just make the non-free FAT source and GPL FAT source both be git submodules? Then whoever clones the repo can get the license flavor he's least scared about. Or alternatively instead of pulling in a GPL licensed FAT driver we use a BSD licensed one. I'm sure someone has one of those too ;).
> 
> Also for the record, the FAT driver problem is that the source license states that it can not be used in certain circumstances, which by common interpretation makes it non-free. The fact that there is a binary or source doesn't matter fwiw.
> 

The edk2 FAT driver solves the problems faced by folks shipping hardware, but the source ended up as a separate project to keep the license clean. I don’t think anyone thought about the binary + license being an issue back in the day? IMHO the right thing to do is remove the binary FAT driver from the tree (the source is already in a sub project), and update the getting started collateral. It seems like the right thing to do to respect folks with different down stream licensing constraints. 

I wish those of us with BSD development constraints got the same consideration from some of the GPL developers on this list. 

Thanks,

Andrew Fish


> 
> Alex
> 

Re: [Qemu-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 <jordan.l.justen@intel.com>:

>> 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

Re: [Qemu-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 <jordan.l.justen@intel.com>:
> 
>>> 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

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

[Andrew Fish]

> On Sep 10, 2015, at 4:40 AM, Alexander Graf <agraf@suse.de> 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 <jordan.l.justen@intel.com>:
>> 
>>>> 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&d=BQID-g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=VQx-tNIhMX_CI4DXORkNq10jBTMAXyaFT332GWZhfRQ&e= 
>> 
>>> 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&d=BQID-g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=l2F5kQrmSHyEb7D4po7B0A-vQK1l7rCkw79eJCddVmQ&e=  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

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

[Alexander Graf]

> Am 10.09.2015 um 14:17 schrieb Andrew Fish <afish@apple.com>:
> 
> 
>> On Sep 10, 2015, at 4:40 AM, Alexander Graf <agraf@suse.de> 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 <jordan.l.justen@intel.com>:
>>> 
>>>>> 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&d=BQID-g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=VQx-tNIhMX_CI4DXORkNq10jBTMAXyaFT332GWZhfRQ&e= 
>>> 
>>>> 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&d=BQID-g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=l2F5kQrmSHyEb7D4po7B0A-vQK1l7rCkw79eJCddVmQ&e=  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

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

[Kevin Davis]

> 
> > On Sep 10, 2015, at 4:40 AM, Alexander Graf <agraf@suse.de> 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
> <jordan.l.justen@intel.com>:
> >>
> >>>> 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.
> >>
> >> 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&d=BQID-
> g&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=6S8FigY
> 338Lo73J1DVLkCR-sshwa_iC7dw0Ng-S8U4o&s=l2F5kQrmSHyEb7D4po7B0A-
> vQK1l7rCkw79eJCddVmQ&e=  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.
> >
As Fish said with a bit of a modernization:
I'm not an attorney nor do I play one on YouTube, and adding that I'm not speaking for my employer although I actually do that on YouTube...

If you follow the above link to http://elm-chan.org/fsw/ff/00index_e.html , that software source code is licensed to the user of the software source code under a very permissive 1 clause BSD license.  Ok, that solves one issue.  

If you read down in the web page, it points to the Microsoft EFI FAT32 File System Specification page where the next issue is addressed.  By the way, this probably is something close to the specification that was used by the original developers to create the EDK2 driver.

"Note: The download license agreement permits you to use the Microsoft EFI FAT32 File System Specification only in connection with a firmware implementation of the Extensible Firmware Initiative Specification, v. 1.0. If you plan to implement the FAT32 File System specification for other purposes, you must obtain an additional license from Microsoft." - copied from https://msdn.microsoft.com/en-us/windows/hardware/gg463080.aspx

Snipping the statement of interest to "If you plan to implement... for other purposes... you must obtain an additional license from Microsoft."

Just being an individual person and not an attorney, this leads me to guess that Microsoft wants one to have a license if one plans on implementing the spec.  Not use, not implement, but the act of planning to implement.  I would also guess when one goes to Microsoft to obtain this license, one would then learn about the license to actually use ones code after you planned and implemented.

So, continuing to guess here, I would guess that ANY of the FAT file systems that you find with clean BSD source code license or standard GPL, were not developed under a valid Microsoft FAT implementation license.  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. 

> 
> 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
> 
Please forgive me if I have violated any of the rules for responding to emails on the cc:'ed list.  I'm just a manager at work so I'm not very experienced at following rules.  Feel free to flame me directly.  

As an aside to another branch of this thread, is the only way to prove friendliness to the Linux community by having a complete un-permissive GPL'ed BIOS source code?  After years of working in the industry and trying to effect change in the companies for which I work and in the customers that I service, I would have thought what I'm doing is being friendly.    Again, feel free to flame me directly instead of filling up this branch of the thread.

Thanks!
Kevin
An actual individual not speaking for my employer

Re: [Qemu-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

Re: [Qemu-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

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

On 09/10/2015 08:14 PM, Kevin Davis wrote:
>>
>>
>> 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?

A bit of wikipedia reading turns up these indirect documentations of the
solutions:
http://arstechnica.com/information-technology/2009/07/vfat-linux-patch-could-circumvent-microsofts-patent-claims/
https://web.archive.org/web/20130131034455/http://www.desktoplinux.com/news/NS4980952387.html

which in turn leads to this FAQ:
https://web.archive.org/web/20121116185559/http://lkml.org/lkml/2009/6/26/314

So reading between the lines, IBM's opinion was that implementing a
workaround that operates FAT in such a way that it never uses a common
namespace was sufficient to avoid any legal questions about whether that
code conflicts with a patent on a common namespace, sidestepping the
longer question of any legal battle over the patent itself.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Kevin Davis]

> 
> On 09/10/2015 08:14 PM, Kevin Davis wrote:
> >>
> > Ah.  I wasn't in the room when they figured it out.  And I've never seen
> their written opinion.  Is it documented somewhere?
> 
> which in turn leads to this FAQ:
> https://web.archive.org/web/20121116185559/http://lkml.org/lkml/2009/6/
> 26/314
> 
> So reading between the lines, IBM's opinion was that implementing a
> workaround that operates FAT in such a way that it never uses a common
> namespace was sufficient to avoid any legal questions about whether that
> code conflicts with a patent on a common namespace, sidestepping the
> longer question of any legal battle over the patent itself.
> 

Of course I have no comment on the legal opinion other than it is interesting and nice to have a pointer to it.

Thanks for the pointers

> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org

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

[Andrew Fish]

> On Sep 10, 2015, at 8:44 PM, Kevin Davis <Kevin.Davis@insyde.com> wrote:
> 
>> 
>> On 09/10/2015 08:14 PM, Kevin Davis wrote:
>>>> 
>>> Ah.  I wasn't in the room when they figured it out.  And I've never seen
>> their written opinion.  Is it documented somewhere?
>> 
>> which in turn leads to this FAQ:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__web.archive.org_web_20121116185559_http-3A__lkml.org_lkml_2009_6_&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=mhYwzTqxMG2tM5He0exVnKYSFG58txsY87BTZP3pIqo&s=LKChPDVsVauW8_4ZGz2OukddijAHxwPZhnjeXQZCW5I&e= 
>> 26/314
>> 
>> So reading between the lines, IBM's opinion was that implementing a
>> workaround that operates FAT in such a way that it never uses a common
>> namespace was sufficient to avoid any legal questions about whether that
>> code conflicts with a patent on a common namespace, sidestepping the
>> longer question of any legal battle over the patent itself.
>> 
> 
> Of course I have no comment on the legal opinion other than it is interesting and nice to have a pointer to it.
> 
> Thanks for the pointers
> 

This history of issues is why we should remove the binary FAT driver from the common repo, so we accommodate the realities of all the down stream partners. 

Thanks,

Andrew Fish

PS Nice to see the FOSS and traditional PC folks learning from each other on the list.

>> --
>> Eric Blake   eblake redhat com    +1-919-301-3266
>> Libvirt virtualization library https://urldefense.proofpoint.com/v2/url?u=http-3A__libvirt.org&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=mhYwzTqxMG2tM5He0exVnKYSFG58txsY87BTZP3pIqo&s=-yJzLpdTqQeS_UK_JwAuIFrCqfdN48GJH6q_ljHnfI8&e= 
> 

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

[Sharma Bhupesh]

> From: edk2-devel [mailto:edk2-devel-bounces@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 <jordan.l.justen@intel.com>
> wrote:
> > > On 2015-09-09 16:05:20, Andrew Fish wrote:
> > >> So you have a legal degree and are speaking on behalf of your
> > >> employer on this subject?
> > >
> > > No and no. How about you? :)
> >
> > No but I have to review any code contributed to the open source
> > project to make sure it follows the corporate polices.
> 
> Is Apple corporate policy that you could never contribute to a project
> that has a GPL directory in the tree?
> 
> > > Nevertheless, I have not heard the interpretation that just having
> > > GPL in a source tree would impact your code, even if you do not
> > > include, nor link to it. Is this Apple's interpretation of how GPL
> works?
> >
> > No but thanks for making my point for me. 1st off the rules are made
> > by lawyers and managers so you trying to argue logic is kind of funny.
> > What does logic have to do with it.
> 
> Whoa! What's next in this crazy world? Dogs and cats living together!
> Mass hysteria! How can we be sure that the lawyers won't decide that BSD
> means GPL and vice versa? ;)
> 
> > Your company started this edk2 project as a BSD project, and I assume
> > there was a reason for that.
> 
> And then more licenses were added.
> 
> > The reasons rules like this end up getting made is that developers
> > like you are confused about the company policy regarding open source,
> > closed source and protecting intellectual property rights.
> > So your very smart and well versed and you are confused, so
> 
> I don't think I'm confused (or smart :), but you are trying hard to make
> it seem confusing and scary.
> 
> Anyway, you are correct. We do have rules. But, I don't think those rules
> prevent us from discussing *possible* changes to those rules.
> 
> > some more jr. engineer has no hope of getting it right and would copy
> > the GPL code and be clueless to what he just did. As I always say a
> > development process exists to slow down the best developer, at the
> > price of preventing the most jr. developers from doing something
> > stupid.
> 
> If we have another repo with GplDriverPkg, then I guess the same jr.
> developer might just go find the code over there and copy it.
> 
> > > I would be more worried about the GPL based drivers becoming too
> > > featureful over time, and the permissively licensed code not being
> > > very useful. For example, I'm worried that the non-GPL OVMF may end
> > > up missing a lot of features.
> >
> > Then logically you should just make OVMF a GPL project?
> 
> Not if you are someone that prefers permissive source licenses, such as
> myself.
> 
> I'm basically trying to argue the other side of this to not let the GPL
> FUD go by unimpeded.
> 
> Laszlo's email raised the GPL question, but I was not sure what the EDK
> II community would accept with regards to GPL. Thus ... I asked. I guess
> I'm getting a better idea with regards to Apple and HP. :)
> 
> In your opinion, would we be able to discuss patches for a *separate*
> repo with GplDriverPkg on edk2-devel?
 
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

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

[Paolo Bonzini]

On 10/09/2015 08:57, Sharma Bhupesh wrote:
> 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]),

No, that would require agreement from the original copyright holder,
which you are not going to get.

> 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).

The dual BSD/GPL license is pointless, since you can already take
BSD-licensed code and distribute it under the GPL.  It just makes the
picture murkier without changing anything in practice.

Paolo

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

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

[Daniel P. Berrange]

On Wed, Sep 09, 2015 at 05:41:59PM -0700, Jordan Justen wrote:
> On 2015-09-09 16:05:20, Andrew Fish wrote:
> > 
> > > On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.justen@intel.com> wrot> > > 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.

Plenty of projects have a scenario in which different parts of their
codebase are under different licenses, without there being undue
problems. If you make it clear by having a separate directory, then
I think you can ultimately credit the developers with having enough
intelligence to do the right thing here. If not, then I'd probably
question whether you can trust them to submit any code at all, as
they could equally have blindly copied it from a 3rd party project
under an incompatible license.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Wed, Sep 09, 2015 at 05:41:59PM -0700, Jordan Justen wrote:
> > On 2015-09-09 16:05:20, Andrew Fish wrote:
> > > 
> > > > On Sep 9, 2015, at 3:24 PM, Jordan Justen <jordan.l.justen@intel.com> wrot> > > 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.
> 
> Plenty of projects have a scenario in which different parts of their
> codebase are under different licenses, without there being undue
> problems. If you make it clear by having a separate directory, then
> I think you can ultimately credit the developers with having enough
> intelligence to do the right thing here. If not, then I'd probably
> question whether you can trust them to submit any code at all, as
> they could equally have blindly copied it from a 3rd party project
> under an incompatible license.

Many companies dont trust their engineers to do that, and have painful
review processes to stop their engineers stupidly copying closed
code into open projects; and in general they're needed because the
engineers would do it if they weren't stopped.

Dave

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Andrew Fish]

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

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-devel@lists.01.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=Kmc0BLQJkt9XKCJf_d8PrrQXQ9eNhkkTmN6cq2RzIzo&s=gmyUS4K6xDQ0QIZyAv_DkOp_G9rMBrDpvqa_VV_4RTo&e= 

Re: [Qemu-devel] [Xen-devel] OVMF BoF @ KVM Forum 2015

[Ian Campbell]

On Wed, 2015-09-09 at 10:57 +0200, 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

Thanks for including xen-devel in this. Was anyone from the Xen community
present at the BoF (so far as you know)? Are there any minutes or anything
like that for those interested in the discussion and reasoning rather than
just the resulting action items?

Thanks,
Ian.

> , 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
>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> 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]
> - 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
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [Qemu-devel] [Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, 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
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)?

Noone was. And I know it for a fact, because all of the handful of BoF
participants were sitting around one table. :)

(If someone speaks up now, "hey I was there, and I'm a Xen guy", then
I'll just dig myself a pit.)

> Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Not really; I think this todo list is pretty comprehensive. I remember
talking a lot and having trouble breathing (I had gotten sick just a few
days earlier -- yay crowded conferences and parties), but I tend to
speak in many details about few things, and not concisely about many things.

Should you care about those details, I've now forgotten them all. They
probably weren't important anyway. I recall trying to convince Jordan
politely to review my SMM patches. We probably discussed some SMM details.

... Please ask Jordan or the other participants, they weren't sick, and
they don't have a chronic verbosity problem.

... Man, it must be great to work with me! ;)

Thanks for your interest!
Laszlo

> 
> Thanks,
> Ian.
> 
>> , 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
>>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> 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]
>> - 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
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: [Qemu-devel] [Xen-devel] OVMF BoF @ KVM Forum 2015

[Laszlo Ersek]

On 09/09/15 18:34, Ian Campbell wrote:
> On Wed, 2015-09-09 at 10:57 +0200, 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
> 
> Thanks for including xen-devel in this. Was anyone from the Xen community
> present at the BoF (so far as you know)? Are there any minutes or anything
> like that for those interested in the discussion and reasoning rather than
> just the resulting action items?

Okay, second attempt at an answer. I *have* forgotten a great deal of
the sentences that were uttered at the BoF, but I mostly remember why we
wanted these things. :)

So let me see if I can elaborate on these (after all you are interested
in the reasoning in general, not just the discussions that I fail to
recall in detail):

>> , 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
>>     <http://permalink.gmane.org/gmane.comp.bios.edk2.devel/941> 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]

So in this item (which, in the above form, is already obsolete) I
managed to mix up three separate things. (But Jordan then went on and
clarified those today.)

(1) One thing is a virt-oriented fork of edk2, without explicit
licensing-oriented goals. The main purpose of this fork would be to
expedite virt development (OvmfPkg, ArmVirtPkg, and central packages on
which the former two depend).

It has sometimes occurred that an OVMF feature got tied up in
inter-maintainer disagreement, or other non-technical reasons (lack of
review capacity etc). This holds back virt development, plus it has the
potential to force downstreams (let's be concrete: Red Hat at minimum)
to carry some patches in downstream only.

The fork would accelerate things here. We'd have a set of rules for
committing to the fork (and the divergence would have to be rebased
periodically, or alternatively edk2 patches would have to be merged into
the fork, periodically).

Considering this purpose (ie. expediting virt development) in isolation,
the fork should stick with the original edk2 licenses.

(2) The *ability* to provide the end user with free software (in the
FSF's definition) or open source software (in the OSI's definition),
which the current FAT driver is regrettably none of, is extremely important.

Currently the only alternative that appears feasible is Peter Batard's
UEFI port of GRUB's read-only FAT driver. That driver comes under the
GPL, and therefore it ties into topic (3) below.

However, note that if the in-tree FAT driver were liberated (= made Free
or Open Source Software, for example by dropping the "Additional Terms"
from its license, thereby rendering it 3-BSDL), then goal (2) would be
immediately achieved, and it wouldn't tie into goal (3) below.

(3) Accommodating drivers that contributors can (or are willing to)
submit only under the GPL would be nice. For example there has been such
a contribution from Ludovic Rousseau, a smart card reader protocol
implementation (a port from Linux).

Jordan's most recent suggestion was to actually keep GPL'd drivers
within edk2, under "GplDriverPkg". This is being discussed on
edk2-devel, so I'll move on.

>> - document the rules / justification for "ovmf" (licensing
>>   conflicts, non-technical blockage on edk2 etc).
>> - No new mailing list needed

Okay, so the rules. They would go like (obviously they are up for
discussion):

- submit your stuff to edk2-devel as always

- work with the reviewers / maintainers

- if you get demonstrably stuck, due to inter-maintainer deadlock (ie.
  you'd be fine implementing either maintainer's request, but their
  requirements *together* are unsatisfiable, because they conflict),
  the patches can be committed to the fork, subject to review *for* the
  fork

- same if there's just no feedback for a patchset

- same if the patches are blocked due to non-technical criticism

- maybe the same if the technical feedback would require
  *disproportionate* effort (ie. cross-package refactorings), esp.
  involving client (=platform) packages that are not related to virt.
  We have to be careful with this one (it's not a blanket excuse, and
  arguments are bound to be somewhat subjective here), but such
  unjustified / overarching / disproportionate requirements can block
  the upstreaming of a feature (developed under a deadline) for good.

  Example: consider a refactoring that straddles DuetPkg or EmulatorPkg
  *and* MdeModulePkg, so that you can use a feature in OvmfPkg. You
  just turned a two week development effort into 6-8 weeks.

  No. You might not even have the environment to test DuetPkg. Etc.

- Initial set of committers to this fork would be the current virt
  package maintainers (ArmVirtPkg, OvmfPkg).

- Reviews should be done for the fork too, of course. But, the chance
  for inter-maintainer deadlock is much smaller. (Eg. if a virt-pkg
  maintainer "deadlocks" with a non-virt-pkg maintainer while reviewing
  a virt-related (or virt-serving!) patch, then as far as the "ovmf"
  repo is concerned, the virt-pkg maintainer's requirements
  automatically "win", and the patch submitter becomes capable of
  implementing the requirements, even if the implementation affects the
  non-virt-pkg maintainer's package.)

>> - push RH's downstream-only patches to "ovmf", wherever that makes
>>   sense

Some of those are downstream only due to problems listed above. Some
other patches are admittedly not suitable for upstream. (They are not
"secret"; anyone can see them in the SRPM.)

>> - remove encumbered FAT driver

See (2)

>> - import Peter Batard's GPL r/o FAT driver port of GRUB's

This is *one* alternative for solving (2), and it happens to tie into
(3). (The optimal alternative would be relicensing the in-tree FAT
driver, but that's not something that can be contributed.)

>> - secure OpenSSL linking exception for the former from the copyright
>>   holders (Peter Batard, GRUB project)

Further complication for (3). "Linking" GPL code together with OpenSSL
licensed code is not trivial, I'm told. (The concept of "linking" might
also be interesting for a firmware image.) I'm not a lawyer (obviously),
so this item is here to keep the question on the radar.

I'll note that if (2) was solved by relicensing the current FAT driver
(and therefore (2) didn't tie into (3)), then (2) would become
independent of this question as well, and this question would lose a lot
of significance (similarly to (3)).

>> - "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

Distros packaging OVMF and/or ArmVirtPkg should follow the fork, because
some ("trapped") features would exist only there.

>> - get OVMF into Fedora (as pkg) and QEMU (as bundled binary)

(2) is both necessary and sufficient for this!

>> - do OVMF releases, maybe in sync with QEMU's releases
>>   - we can probably build from known good revisions from git [Alex]

Helps with error reporting and narrowing down regressions, before
starting an actual bisection.

>> - revive Q35 SATA driver work / poke Reza
>>   - Hannes and Gabriel have refreshed patches, but their versions differ

A SATA driver for Q35 would be really nice, although both Linux and
Windows guests can be installed without such a firmware driver
(requiring virtio-containing initrd's / driver disks, respectively).
AFAIR this work got bogged down in cross-module requirements too.

... I hope this helps. I'm sorry if the above ended up chaotic; I'm
tired but I didn't want to leave it at "I don't remember". I do remember
the reasons, if not the specific discussion.

Corrections welcome, of course...

Thanks
Laszlo


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