U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Tom Rini <trini@konsulko.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>,
	<u-boot@lists.denx.de>, Simon Glass <sjg@chromium.org>,
	Quentin Schulz <quentin.schulz@theobroma-systems.com>,
	Peter Robinson <pbrobinson@gmail.com>,
	Enric Balletbo i Serra <eballetb@redhat.com>,
	Josh Boyer <jwboyer@redhat.com>,
	"NXP i.MX U-Boot Team" <uboot-imx@nxp.com>
Subject: Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)
Date: Wed, 17 Jul 2024 07:11:47 -0500	[thread overview]
Message-ID: <20240717121147.2otvlmo6tpmek3wm@vacancy> (raw)
In-Reply-To: <20240716213618.GO561963@bill-the-cat>

On 15:36-20240716, Tom Rini wrote:
[...]

> > > > Distributing the closed source binaries and U-Boot in separate packages
> > > > according to their respective licenses and only assemble them on the target
> > > > device via a post-installation script might be allowable.
> > > 
> > > For this project the question is making sure that the binaries are
> > > licensed such that they could be externally redistributable.
> > > 
> > > I don't know why someone would suggest that ABI calls are suddenly
> > > linkage as I thought that (as far as these matters go) that was already
> > > settled, but I am not a lawyer.
> > 
> > The relevant term in the GPL 2.0 license is "work based on the Program".
> > According to the GPL a "work based on the Program" is "a work containing the
> > Program or a portion of it".
> > 
> > If you build a binary via binman that contains U-Boot and another binary,
> > the resulting binary could be considered "a work containing the Program or a
> > portion of it".
> > 
> > The GPL 2.0 requires:
> > 
> > "But when you distribute the same sections as part of a whole which is a
> > work based on the Program, the distribution of the whole must be on the
> > terms of this License, whose permissions for other licensees extend to the
> > entire whole, and thus to each and every part regardless of who wrote it."
> 
> I'm not a lawyer and I don't pretend to be one on mailing lists, either.
> 
> In that my non-lawyer statements matter, I don't think binman
> constitutes some new form of linking and I believe it falls in to the
> same well known ABI exception.
> 
> But that's entirely unrelated to the question of hosting binaries (some
> of which may be closed source) for use in firmware projects, some of
> which will not be GPL. For example, I would assume that running
> tianocore on i.MX8 requires the same assorted binaries that U-Boot does,
> and that would not have a license conflict.

Usual disclaimers (not a lawyer, not representing corporate policy..  etc):
buildroot and yocto for example prebuild images for embedded systems and
they have had to deal with closed firmwares in the past as well.
Packaging binaries in a filesystem or some format (x509/fit) is
essentially the same thing - anyways.. interesting thought there.


PS: For folks interested: LPC accepted our proposal[1] in the
security/boot MC and if folks could join in person or virtually, it
would be great to lay this out and get the thoughts out and come to some
direction here.

[1] https://lpc.events/event/18/contributions/1815/


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

      reply	other threads:[~2024-07-17 12:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-20 21:35 Request for hosting a boot-firmware repository in u-boot git (denx and GitHub) Nishanth Menon
2024-06-20 22:10 ` Peter Robinson
2024-06-21 14:54   ` Bryan Brattlof
2024-06-20 22:22 ` Quentin Schulz
2024-06-20 22:29   ` Peter Robinson
2024-06-21  8:44     ` Quentin Schulz
2024-06-21  8:56       ` Peter Robinson
2024-06-21  8:57         ` Peter Robinson
2024-06-21  9:29         ` Quentin Schulz
2024-06-21  9:37           ` Peter Robinson
2024-06-20 22:33   ` Mark Kettenis
2024-06-20 23:05 ` Simon Glass
2024-06-21  7:35   ` Peter Robinson
2024-06-21 14:57     ` Simon Glass
2024-06-21 15:35       ` Bryan Brattlof
2024-07-16 19:13 ` Tom Rini
2024-07-16 19:35   ` Heinrich Schuchardt
2024-07-16 20:01     ` Tom Rini
2024-07-16 20:14       ` Heinrich Schuchardt
2024-07-16 21:36         ` Tom Rini
2024-07-17 12:11           ` Nishanth Menon [this message]

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-all 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=20240717121147.2otvlmo6tpmek3wm@vacancy \
    --to=nm@ti.com \
    --cc=eballetb@redhat.com \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=jwboyer@redhat.com \
    --cc=pbrobinson@gmail.com \
    --cc=quentin.schulz@theobroma-systems.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=uboot-imx@nxp.com \
    /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