All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.