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: Mon, 30 Apr 2018 12:16:42 -0700	[thread overview]
Message-ID: <1d4bba4b-9a68-b6e7-0551-036429567520@gmail.com> (raw)
In-Reply-To: <20180428122004.5909043f@windsurf>

On 04/28/2018 03:20 AM, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 27 Apr 2018 14:39:20 -0700, Florian Fainelli wrote:
> 
>>> Well, sure, it makes some sense _practically_, but not _legally_ AFAICU,
>>> because to be compliant you still would need a written license statement
>>> (e.g. in the printed user manual).
>>>
>>> Do we want to support every way that makes sense? We have two at least:
>>> store the manifest and store manifest + license text. If we want to
>>> support both, maybe that would actually carry more complexity than
>>> usefulness, I'm afraid.
>>>
>>> But of course I might be partially wrong! :-]  
>>
>> Let's drop this, I was not thinking this would go into such a lengthy
>> discussion, I will keep the local hack I have with make legal-info in
>> post-build.sh. Thanks a lot for your help Yann!
> 
> Well, could you share some details about your specific use-case ? As
> explained by Luca, having just the list of software components and the
> name of their license isn't enough, the complete license text is needed
> for licence compliance.
> 
> Knowing this, what is the use-case for having just the manifest ?

The use case is to have an UI page which is able to list the different
packages included, their version, a link to their license as well as
their sources. This is by no means meant to be a lawyer proof license
compliance page, just something that can eventually be used as a
template to reach that goal.

You and others have convinced me into keeping this a local modification,
I see no point in continuing this discussion any further given it was
asked as seemingly naive question.
-- 
Florian

  reply	other threads:[~2018-04-30 19:16 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
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 [this message]
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=1d4bba4b-9a68-b6e7-0551-036429567520@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.