From: "Pedro Falcato" <pedro.falcato@gmail.com>
To: Rebecca Cran <rebecca@bsdio.com>
Cc: devel@edk2.groups.io, rebecca@os.amperecomputing.com,
Chao Li <lichao@loongson.cn>,
andrei.warkentin@intel.com, Ard Biesheuvel <ardb@kernel.org>,
"quic_llindhol@quicinc.com" <quic_llindhol@quicinc.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] [PATCH] Emulator/X86EmulatorDxe: Replace with MultiArchUefiPkg build
Date: Wed, 23 Oct 2024 12:10:51 +0100 [thread overview]
Message-ID: <CAKbZUD0iqnoL8Sk4GpPDNVwccgLb_gQdprs7SqZkMiC_ZkxPTg@mail.gmail.com> (raw)
In-Reply-To: <5da6e748-a2da-44dc-9710-82be5d1599a3@bsdio.com>
On Wed, Oct 23, 2024 at 3:20 AM Rebecca Cran <rebecca@bsdio.com> wrote:
>
> On 10/22/24 5:44 PM, Pedro Falcato wrote:
>
> > You can build whatever GPL-violating contraption as long as you don't
> > distribute it. If you do, you need to comply with the terms of the
> > license.
> > FWIW, GNU seems to think merely including this module would be a GPL
> > violation (https://www.gnu.org/licenses/gpl-faq.html#MereAggregation,
> > see the mention of running together in a shared address space), and
> > thus all your firmware would potentially need to be distributed under
> > the GPL's terms.
> >
> > Ard's old version seems to only be LGPL and thus you'd only need to
> > comply with the LGPL's terms for that specific module (there's no
> > "virality").
>
>
> If loading into the same address space is the issue, wouldn't GRUB being
> loaded infect the firmware too?
I suspect the issue is that it's very hard to consider GRUB and the
firmware a "single program", particularly if you don't distribute GRUB
with the firmware.
>
> My point was that UEFI firmware could be considered a filesystem, with
> the EmulatorDxe.efi simply being on the same filesystem as the other
> drivers. That's opposed to being linked into the same binary, which is
> clearly a GPL violation.
To me (definitely not a lawyer), what we do in EFI with protocols is
very, very similar with dynamic linking (what's dynamic linking if not
calling into a table of well-defined function pointers (elf PLT)?).
For me the case is strengthened even more if you consider that all of
these modules and protocols are not only in bed with each other, but
also in the same frequently-not-replaceable firmware volume, and
together form "the firmware".
Even worse:
>MultiArchUefiPkg won't work with just any UEFI implementations, but only with implementations that provide the EDKII_PECOFF_IMAGE_EMULATOR_PROTOCOL interface, which is the magic that enables loading foreign ISA binaries
so it uses private EDK2 interfaces (not just standard EFI protocols),
thus sounds kind of intimately linked with EDK2...
But this is ofc my two cents... The GPL is murky and has plenty of
grey areas in these situations.
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120662): https://edk2.groups.io/g/devel/message/120662
Mute This Topic: https://groups.io/mt/108202804/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2024-10-23 11:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-31 22:32 [edk2-devel] [PATCH] Emulator/X86EmulatorDxe: Replace with MultiArchUefiPkg build Rebecca Cran
2024-09-01 8:05 ` Ard Biesheuvel via groups.io
2024-09-02 2:49 ` Chao Li
2024-09-06 5:41 ` Andrei Warkentin
2024-09-06 8:44 ` Chao Li
2024-09-06 5:32 ` Andrei Warkentin
2024-09-06 14:22 ` Rebecca Cran via groups.io
2024-09-06 15:25 ` Ard Biesheuvel via groups.io
2024-09-06 15:39 ` Rebecca Cran via groups.io
2024-10-22 8:48 ` Chao Li
2024-10-22 10:29 ` Rebecca Cran via groups.io
2024-10-22 23:44 ` Pedro Falcato
2024-10-23 2:08 ` Chao Li
2024-10-23 2:20 ` Rebecca Cran
2024-10-23 11:10 ` Pedro Falcato [this message]
2024-09-02 16:45 ` Michael D Kinney
2024-09-02 21:21 ` Rebecca Cran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKbZUD0iqnoL8Sk4GpPDNVwccgLb_gQdprs7SqZkMiC_ZkxPTg@mail.gmail.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox