Re: [Qemu-riscv] [Qemu-devel] [PULL 33/34] roms: Add OpenSBI version 0.3

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Mon, 1 Jul 2019 at 18:50, Alistair Francis <Alistair.Francis@wdc.com> wrote:
>>
>> On Mon, 2019-07-01 at 17:54 +0100, Peter Maydell wrote:
>> > On Thu, 27 Jun 2019 at 16:24, Palmer Dabbelt <palmer@sifive.com>
>> > wrote:
>> > > From: Alistair Francis <alistair.francis@wdc.com>
>> > >
>> > > Add OpenSBI version 0.3 as a git submodule and as a prebult binary.
>> > >
>> > > Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
>> > > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>> > > Tested-by: Bin Meng <bmeng.cn@gmail.com>
>> > > Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
>> > > ---
>> > >  .gitmodules                                  |   3 ++
>> > >  Makefile                                     |   5 +-
>> > >  pc-bios/opensbi-riscv32-virt-fw_jump.bin     | Bin 0 -> 28848
>> > > bytes
>> > >  pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin | Bin 0 -> 28904
>> > > bytes
>> > >  pc-bios/opensbi-riscv64-virt-fw_jump.bin     | Bin 0 -> 28904
>> > > bytes
>> > >  roms/Makefile                                |  48 ++++++++++++++-
>> > > ----
>> > >  roms/opensbi                                 |   1 +
>> > >  7 files changed, 44 insertions(+), 13 deletions(-)
>> > >  create mode 100644 pc-bios/opensbi-riscv32-virt-fw_jump.bin
>> > >  create mode 100644 pc-bios/opensbi-riscv64-sifive_u-fw_jump.bin
>> > >  create mode 100644 pc-bios/opensbi-riscv64-virt-fw_jump.bin
>> > >  create mode 160000 roms/opensbi
>> > >
>> > > diff --git a/.gitmodules b/.gitmodules
>> > > index 2857eec76377..7a10e72e09cd 100644
>> > > --- a/.gitmodules
>> > > +++ b/.gitmodules
>> > > @@ -55,3 +55,6 @@
>> > >  [submodule "slirp"]
>> > >         path = slirp
>> > >         url = https://git.qemu.org/git/libslirp.git
>> > > +[submodule "roms/opensbi"]
>> > > +       path = roms/opensbi
>> > > +       url = https://github.com/riscv/opensbi.git
>> >
>> > It would be nice to state the license for new blobs we're
>> > adding to the source tree... In particular, I find the
>> > readme at https://github.com/riscv/opensbi a bit confusing
>> > because it says it's 2-BSD but also that some parts are Apache-2.0;
>> > the latter is *not* GPL-2.0 compatible. That makes it not completely
>> > obvious to me that we can ship this with QEMU.
>>
>> Ah, I didn't realise there is Apache-2.0 code in there.
>>
>> In this case all of the code we are using (we aren't using the Kendryte
>> code with QEMU) is BSD-2-Clause. Even then though does it matter if it
>> is GPL compatible? This isn't being linked with QEMU it is just being
>> included with QEMU.
>
> Yeah, if we're not building the apache-2.0 parts then I think
> we're OK, and as you say there's the question of whether QEMU's
> GPL affects what we ship as mere bios blobs to run as guest
> code anyway. But it's sufficiently not a "really obviously ok"
> that I'd like a second opinion; cc'd some people who might have
> second opinions.

You need an expert opinion.

My non-expert opinion: we can't distribute anything that's not
compatible with GPLv2, at least as long as LICENSE makes the following
claims:

    1) QEMU as a whole is released under the GNU General Public License,
    version 2.

    2) Parts of QEMU have specific licenses which are compatible with the
    GNU General Public License, version 2. Hence each source file contains
    its own licensing information.  Source files with no licensing information
    are released under the GNU General Public License, version 2 or (at your
    option) any later version.

    As of July 2013, contributions under version 2 of the GNU General Public
    License (and no later version) are only accepted for the following files
    or directories: bsd-user/, linux-user/, hw/vfio/, hw/xen/xen_pt*.

    3) The Tiny Code Generator (TCG) is released under the BSD license
       (see license headers in files).

Complicating things further just to distribute a firmware blob would be
a mistake.  Our licensing situation is already complex enough for me to
call it a mistake.

[...]