All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH RFC] legal-info: add option to store manifest in rootfs
Date: Fri, 27 Apr 2018 09:41:59 -0700	[thread overview]
Message-ID: <47141054-2a88-231d-288d-59734b3d1df6@gmail.com> (raw)
In-Reply-To: <20180427163130.GD2471@scaer>



On 04/27/2018 09:31 AM, Yann E. MORIN wrote:
> 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?

Yes.

> 
> 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.

I think so too.

> 
>> 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.

Well of course, but the idea is also to make sure that someone gets a
chance to see a warning if they accidentally decided to ship a
development rootfs to someone. Anyhoo, first use case described is the
intended one FWIW.

> 
> 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
> 

-- 
Florian

  reply	other threads:[~2018-04-27 16:41 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
2018-04-27 16:41       ` Florian Fainelli [this message]
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=47141054-2a88-231d-288d-59734b3d1df6@gmail.com \
    --to=f.fainelli@gmail.com \
    --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.