Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs
Date: Fri, 27 Apr 2018 18:31:30 +0200	[thread overview]
Message-ID: <20180427163130.GD2471@scaer> (raw)
In-Reply-To: <46b6f4f0-033e-9a67-168e-51e16e6a40d5@gmail.com>

Florian, All,

On 2018-04-27 09:14 -0700, Florian Fainelli spake thusly:
> On 04/27/2018 06:46 AM, Thomas Petazzoni wrote:
> > Yann, Florian,
> > 
> > On Thu, 26 Apr 2018 21:32:52 +0200, Yann E. MORIN wrote:
> >> Some users want to be able to easily ship the manifest of the legal-info
> >> directly in the target filesystem.
> >>
> >> Those users currently hack their ways around, usign a post-build script
> >> that calls back to generate legal-info; this is a bit hackish...
> >>
> >> Add an option to that effect.
> >>
> >> Reported-by: Florian Fainelli <f.fainelli@gmail.com>
> >> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> >> Cc: Florian Fainelli <f.fainelli@gmail.com>
> >> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> >> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
> > 
> > I'd like to challenge the usefulness of having the manifest on the
> > target. What is the actual use case ?
> 
> The use case is primarily to have the exact list of
> software/versions/licenses to be displayed in e.g: an UI "legal
> disclaimer" page

So, presumably you would also have that page display a URL where to find
all the rest of the legal-info, right?

This use-case is IMHO really valid: you want to inform the end user of
their rights, give the minimum relevant info, and point outside for the
big parts.

> and possibly use parts of the manifest to issue
> appropriate warnings to developers that shipping a system with GPLv3
> software packages may conflict with the security mechanisms deployed on
> the device.

There, I disagree. That should be part of a CI job to run legal-info for
each build, and parse the manifest to find things you don't like.

Regards,
Yann E. MORIN.

> > Indeed, for license compliance of copyleft license (i.e at least GPL,
> > LGPL), having the name of the software package, its version and its
> > license is not sufficient, you also need to provide the full
> > corresponding source code.
> > 
> > So what is the need for having just the manifest ? Obviously the
> > complexity of the patch is low, but it's yet another Config.in option,
> > so I'd like to be sure there is a real, useful use case for it.
> > 
> > Thanks!
> > 
> > Thomas
> > 
> 
> -- 
> Florian

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-04-27 16:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 19:32 [Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs Yann E. MORIN
2018-04-26 21:47 ` Florian Fainelli
2018-04-27 13:46 ` Thomas Petazzoni
2018-04-27 16:14   ` Florian Fainelli
2018-04-27 16:31     ` Yann E. MORIN [this message]
2018-04-27 16:41       ` Florian Fainelli
2018-04-27 16:33   ` Luca Ceresoli
2018-04-27 16:45     ` Florian Fainelli
2018-04-27 20:02     ` Yann E. MORIN
2018-04-27 21:23       ` Luca Ceresoli
2018-04-27 21:39         ` Florian Fainelli
2018-04-28 10:20           ` Thomas Petazzoni
2018-04-30 19:16             ` Florian Fainelli
2018-04-28 15:15           ` Yann E. MORIN

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=20180427163130.GD2471@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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