From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] Some legal-info observations/problems
Date: Wed, 02 Oct 2013 18:33:24 +0200 [thread overview]
Message-ID: <524C4AD4.9040902@lucaceresoli.net> (raw)
In-Reply-To: <20131002172307.0d6f02ea@skate>
Dear ThomasDe Schampheleire,
thanksfor the comments and detailed analysis.
Find my comments below.
Thomas Petazzoni wrote:
> Dear Thomas De Schampheleire,
>
> (Skipping items 2 and 3, since they have been solved apparently.)
>
> On Wed, 2 Oct 2013 16:06:13 +0200, Thomas De Schampheleire wrote:
>
>> 1. there is no longer a provision to 'hide' proprietary packages from
>> the manifest, and not get warnings on them. Previously you could mark
>> a package as license: PROPRIETARY, but this has been removed. I still
>> think that a similar feature is useful.
> <pkg>_REDISTRIBUTE = NO
>
> is what you're looking for, no?
No,<pkg>_REDISTRIBUTEonly prevents the source tarballfrom beingcopied.
At the beginning we had a magic value:
FOO_LICENSE = PROPRIETARY
which would prevent /any/ info from being generated for FOO.
Then we preferred to separatethingsfor license declaration
(_LICENSE*)and source tarball copying trigger (_REDISTRIBUTE).
I still think this change was good and it cleaned up a lot the code,
so I wonldn't step back.
Three ideas pop up in my mind.
Option 1:introduce a new tag such as:
FOO_SAVE_LEGAL_INFO = {YES|NO}
defaulting to YES.If NO, nothing is saved for FOO: no manifest,
no licenses.txt, no source tarball (and FOO_REDISTRIBUTE ignored).
This somehow mimics the old behaviour, but with a new variable in lieu
of a magic value.
option 2, slightly different:
FOO_LIST_IN_MANIFEST= {YES|NO}
defaulting to YES.If NO, nothing is saved for the package in manifest
and licenses.txt, but FOO_REDISTRIBUTE tells whether the source tarball
is to be saved.
The latter mode would keep things separate and orthogonal, which is
cleaner. But it's probably infrequent that people want to save one part
of the info and not the other.
option 3, a mix the other two:
FOO_SAVE_LEGAL_INFO = {YES|NO}, default YES
FOO_REDISTRIBUTE= {YES|NO}, default $(FOO_SAVE_LEGAL_INFO)
Meaning:
* by default FOO_SAVE_LEGAL_INFO rules it all, and we do the same thing
for manifest+licenses.txt and source tarball copying (save all or
save nothing);
* the two can be forced to behave differently by defining
FOO_REDISTRIBUTE with a value opposite to FOO_SAVE_LEGAL_INFO.
Comments?
>> 4. Suppose that a package has no license files and explicitly declares
>> this with FOO_LICENSE_FILES =
>> In this case, you will still get a warning: "cannot save license
>> (FOO_LICENSE_FILES not defined)", but in fact it is simply empty.
>> I think it would be better to distinghuish the situation 'empty' and
>> 'not defined'.
> Agreed. However, in make, doing FOOBAR = or not defining FOOBAR leads
> to the same thing: FOOBAR is an empty variable. So we have to decide on
> an explicit magic value to use when no license files are available (and
> ensure this magic value is never going to be used for the name of a
> license file).
>
> FOO_LICENSE_FILES = N/A
> FOO_LICENSE_FILES = not-available
> FOO_LICENSE_FILES = none
> FOO_LICENSE_FILES = NONE
It's not clear to me whether this is the correct way to address the problem
of packages having license file.
I think usually that means they /do/ have a license, but it's only written
in the top lines of source files and/or in a README containing other stuff.
IOW, the license text is there, but we currently have no way to extract it.
This topic was discussed with the first round of implementation of the
legal-info stuff, sometime around FOSDEM 2012. At that time we concluded
we could leave out this quite rare case.
Unfortunately they are not so rare, so should we invent something now to
handle them? Is it worth the effort?
Some options are:
* manually copy the license snippet in package/foo/COPYING and set
FOO_LICENSE_FILES = $(TOPDIR)/package/foo/COPYING(just an idea,
may not actually work);this would require checking if our file is in
line with upstream at each version bump;
* writing in FOO_LICENSE_FILES some instruction for BR to go in the
sources and grab the snippet; say:
FOO_LICENSE_FILES = src/foo-main.c at 20+14
meaning: pick 14 lines starting at line 20 from src/foo-main.c and
that's your license text;
* do nothing.
I'm not super-happy with any of these, so I'm very open to discussionand
other ideas.
>> 5. the manifest also lists all host packages, like automake, autoconf,
>> ... while these are not distributed on target. Strictly speaking you
>> do not have to list these in the customer documentation of a product,
>> in my interpretation. I find it confusing that both target and host
>> packages are mixed like that.
>> Of course, it's probably difficult to change this, because some
>> packages can be built for host _and_ target, and the legal-info
>> infrastructure does not know which of these was used for a particular
>> project.
> I think we discussed that the legal-info for target and host packages
> should be separated: either the CSV should mention whether it's used
> for the target or the host (or both), or there should be two separate
> CSV files.
Yeah, we did.it's on my todo list, but not quite getting close to the
top ofit...
--
Luca
next prev parent reply other threads:[~2013-10-02 16:33 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 [this message]
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
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=524C4AD4.9040902@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--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