Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Some legal-info observations/problems
Date: Fri, 4 Oct 2013 11:07:04 +0200	[thread overview]
Message-ID: <20131004110704.78f5b1a6@skate> (raw)
In-Reply-To: <CAAXf6LUTTX0OFNaP4NxVWXKC4OFBROXK-PFiumL8zYrumkbtog@mail.gmail.com>

Dear Thomas De Schampheleire,

On Fri, 4 Oct 2013 10:54:55 +0200, Thomas De Schampheleire wrote:

> To come back on the comment ThomasP made about 'FOO =' and not
> defining FOO leading to the same empty FOO variable: this does not
> mean we cannot differentiate both cases: with $(origin FOO) you can.

You can also use "ifdef" I believe. But still, I believe that having:

BLEH_LICENSE_FILES =

in a package looks somewhat strange. I found find it more
explicit/readable to have:

BLEH_LICENSE_FILES = N/A
BLEH_LICENSE_FILES = none
BLEH_LICENSE_FILES = NONE

(pick your choice).

> >  That said, it would be good if we would just error out when a license is
> > defined but no license files are provided. Now we check for that during
> > review (and require an explicit comment if no license file exists), but it's
> > of course even better if that can be done during autobuilder tests.
> 
> When you say 'error out' you mean actually aborting the make process?
> Currently, anomalies in the legal-info area are just warnings hinting
> the developer he has to take some action. Do we really want to error
> out in such cases?
> 
> But if we will make a distinction between an undefined
> FOO_LICENSE_FILES (an anomaly) and an empty/magic one, then the
> autobuilder package stats could be updated with an extra column, or a
> YES/NO/EMPTY value in the existing column.
> http://autobuild.buildroot.org/stats/
> 
> (by the way: where is the code that generates these stats? I had
> expected to find it in buildroot-test, but didn't.)

support/scripts/pkg-stats in your favorite Buildroot tree :-)

> But, re-thinking this, I think none of these are actually very good:
> there _should_ be a license file but it is missing. So it's not
> 'not-applicable', and it's not 'none'. Rather, something like:
> FOO_LICENSE_FILES = missing
> FOO_LICENSE_FILES = not-provided
> FOO_LICENSE_FILES = none-provided

I'm fine with either of those choices, except 'missing'. There is very
often a 'missing' script in autotools-based packages.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2013-10-04  9:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-02 14:06 [Buildroot] Some legal-info observations/problems Thomas De Schampheleire
2013-10-02 14:22 ` Peter Korsgaard
2013-10-02 14:32   ` Thomas De Schampheleire
2013-10-02 15:23 ` Thomas Petazzoni
2013-10-02 16:33   ` Luca Ceresoli
2013-10-03  8:24     ` Thomas De Schampheleire
2013-10-03 16:40       ` Arnout Vandecappelle
2013-10-04  8:54         ` Thomas De Schampheleire
2013-10-04  9:07           ` Thomas Petazzoni [this message]
2013-10-04 15:30             ` Ryan Barnett
2013-10-04 15:34               ` Thomas Petazzoni
2013-10-04 15:39                 ` Ryan Barnett
2013-10-04 15:46                 ` Simon Dawson
2013-10-07 22:43                   ` Arnout Vandecappelle
2013-10-09  7:23                     ` Simon Dawson
2013-10-09  7:29                       ` Thomas Petazzoni
2013-10-09  7:31                         ` Simon Dawson
2013-10-05 21:07       ` Luca Ceresoli
2013-10-02 16:31 ` Arnout Vandecappelle
2013-10-03  8:30   ` Thomas De Schampheleire
2013-10-02 18:49 ` Ryan Barnett
2013-10-03  8:34   ` Thomas De Schampheleire
2013-10-03 13:31     ` Ryan Barnett
2013-10-03 13:42       ` Danomi Manchego
2013-10-03 14:12         ` Ryan Barnett
2013-10-03 16:50           ` Arnout Vandecappelle
2013-10-03 21:38     ` Peter Korsgaard
2013-10-03 22:44       ` Ryan Barnett
2013-10-07  8:19 ` Thomas De Schampheleire
2013-10-09 13:14   ` Luca Ceresoli
2013-10-09 16:46     ` Arnout Vandecappelle
2013-10-11 14:13       ` Thomas De Schampheleire
2013-10-09 19:54     ` Ryan Barnett

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=20131004110704.78f5b1a6@skate \
    --to=thomas.petazzoni@free-electrons.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox