[Buildroot] Some legal-info observations/problems

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Hi,

I am starting to use the legal-info infrastructure now, and this
resulted in a number of observations/problems, which I'll list below.

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.

2. suppose FOO_LICENSE_FILES = subdir/COPYING, then the manifest also
contains the string 'subdir/COPYING'. However, the license is copied
into a flat structure output/legal-info/licenses/foo/, so I think that
the manifest should no longer mention the 'subdir'.
Of course, this may contradict with the needs of licenses.txt (the
flat representation of all licenses) that does not suffer from the
subdir problem.

3. partially related to point 2: if a package has multiple license
files with the same name but in subdirectories, e.g. a/COPYING and
b/COPYING, the copying of the license will copy both files on top of
each other. This is the case for xenomai-forge (not yet in buildroot),
which is the new strategy for xenomai [1]. I have brought up this
issue with the developers [2], but maybe there is something else we
can do.

[1] http://git.xenomai.org/?p=xenomai-forge.git;a=summary
[2] http://www.xenomai.org/pipermail/xenomai/2013-October/029262.html

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

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.

Best regards,
Thomas

[Buildroot] Some legal-info observations/problems

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

 Thomas> Hi,
 Thomas> I am starting to use the legal-info infrastructure now, and this
 Thomas> resulted in a number of observations/problems, which I'll list below.

 Thomas> 1. there is no longer a provision to 'hide' proprietary packages from
 Thomas> the manifest, and not get warnings on them. Previously you could mark
 Thomas> a package as license: PROPRIETARY, but this has been removed. I still
 Thomas> think that a similar feature is useful.

 Thomas> 2. suppose FOO_LICENSE_FILES = subdir/COPYING, then the manifest also
 Thomas> contains the string 'subdir/COPYING'. However, the license is copied
 Thomas> into a flat structure output/legal-info/licenses/foo/, so I think that
 Thomas> the manifest should no longer mention the 'subdir'.
 Thomas> Of course, this may contradict with the needs of licenses.txt (the
 Thomas> flat representation of all licenses) that does not suffer from the
 Thomas> subdir problem.

 Thomas> 3. partially related to point 2: if a package has multiple license
 Thomas> files with the same name but in subdirectories, e.g. a/COPYING and
 Thomas> b/COPYING, the copying of the license will copy both files on top of
 Thomas> each other. This is the case for xenomai-forge (not yet in buildroot),
 Thomas> which is the new strategy for xenomai [1]. I have brought up this
 Thomas> issue with the developers [2], but maybe there is something else we
 Thomas> can do.

Do you still see this after 31aa4264d8839d0?

Author: Peter Korsgaard <jacmet@sunsite.dk>
Date:   Wed Jun 5 10:52:18 2013 +0200

    pkg-utils.mk: legal-license-file: handle multiple license files with same name
    
    Some packages (kmod, e2fsprogs, ..) contain multiple (different) license
    files with the same file name, but in different directories.
    
    These are currently all copied to the same filename in
    output/legal-info/licenses/<pkg>, overwriting everything but the last file.
    
    Fix it by recreating the same directory structure under legal-info.
    
    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>

-- 
Bye, Peter Korsgaard

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Hi Peter,

On Wed, Oct 2, 2013 at 4:22 PM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:
>
>
>  Thomas> 2. suppose FOO_LICENSE_FILES = subdir/COPYING, then the manifest also
>  Thomas> contains the string 'subdir/COPYING'. However, the license is copied
>  Thomas> into a flat structure output/legal-info/licenses/foo/, so I think that
>  Thomas> the manifest should no longer mention the 'subdir'.
>  Thomas> Of course, this may contradict with the needs of licenses.txt (the
>  Thomas> flat representation of all licenses) that does not suffer from the
>  Thomas> subdir problem.
>
>  Thomas> 3. partially related to point 2: if a package has multiple license
>  Thomas> files with the same name but in subdirectories, e.g. a/COPYING and
>  Thomas> b/COPYING, the copying of the license will copy both files on top of
>  Thomas> each other. This is the case for xenomai-forge (not yet in buildroot),
>  Thomas> which is the new strategy for xenomai [1]. I have brought up this
>  Thomas> issue with the developers [2], but maybe there is something else we
>  Thomas> can do.
>
> Do you still see this after 31aa4264d8839d0?
>
> Author: Peter Korsgaard <jacmet@sunsite.dk>
> Date:   Wed Jun 5 10:52:18 2013 +0200
>
>     pkg-utils.mk: legal-license-file: handle multiple license files with same name
>
>     Some packages (kmod, e2fsprogs, ..) contain multiple (different) license
>     files with the same file name, but in different directories.
>
>     These are currently all copied to the same filename in
>     output/legal-info/licenses/<pkg>, overwriting everything but the last file.
>
>     Fix it by recreating the same directory structure under legal-info.
>
>     Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>

Ah, I am testing this with 2013.05, so I don't have this yet. Thanks
for the pointer, I will take this commit along.
It should solve points 2 and 3 of my list.

Thanks,
Thomas

[Buildroot] Some legal-info observations/problems

[Thomas Petazzoni]

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?

> 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

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

Best regards,

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

[Buildroot] Some legal-info observations/problems

[Arnout Vandecappelle]

On 10/02/13 16:06, Thomas De Schampheleire wrote:
> Hi,
>
> I am starting to use the legal-info infrastructure now, and this
> resulted in a number of observations/problems, which I'll list below.
>
> 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.

  I don't see why this is relevant. You probably anyway want to filter 
the license results to only contain the relevant licenses (i.e. the 
licenses that require you to mention the authors and the license in the 
documentation). And you can simply set the license to PROPRIETARY and 
grep it out of the csv file.


[snip]
> 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'.

  This may indeed be relevant for private packages and for public domain 
packages.

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

  This was intentional, I think. The host packages may be part of "the 
scripts used to control compilation and installation of the executable" 
(esp. for automake and autoconf), so they may be necessary.

  It would be useful, though, if the manifest would contain a column to 
indicate if it is a host package or a target package.

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

  Actually it's not, the host packages are added explicitly to 
TARGETS_LEGAL_INFO.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Some legal-info observations/problems

[Luca Ceresoli]

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

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on 
10/02/2013 09:06:13 AM:

[...]

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

One other thing that I would like to add about the legal-info that I
would like to see added is the manifest.csv file contain the 
URL from which the source packages originated from. Is this something
that people be interested in seeing added? As part of our release 
process, we need to show where the original source file came from (URL).

Thanks,
-Ryan

------------------------------------------------------------------------------------------
Ryan J Barnett / Software Engineer / Platform SW
MS 137-157, 855 35th St NE, Cedar Rapids, IA, 52498-3161, US
rjbarnet at rockwellcollins.com
www.rockwellcollins.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131002/a45d223b/attachment.html>

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Hi Luca,

On Wed, Oct 2, 2013 at 6:33 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
> Dear ThomasDe Schampheleire,
>
> thanksfor the comments and detailed analysis.

side note: I'm seeing some weird lack of spaces throughout the e-mail,
for example 'thanksfor', 'ThomasDe'. Is this a compression strategy?

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

I re-read the original thread, specifically your answer to it:
http://lists.busybox.net/pipermail/buildroot/2012-October/059402.html

Here is an excerpt:
---------------------
A clean solution is probably to let the _LICENSE do its work, i.e. simply
describe the license, and add a new _REDISTRUBUTE parameter (defaulting to
YES), to specify if the tarball must be copied or not.
Defining the license and choosing whether or not to redistribute would
become technically independent, which is more correct.

Examples:

MYAPP_LICENSE = PROPRIETARY
would become
MYAPP_LICENSE = PROPRIETARY
MYAPP_REDISTRIBUTE = NO
or
MYAPP_LICENSE = Copyright (C) 2012 My Company # just an idea
MYAPP_REDISTRIBUTE = NO

INTEL_MICROCODE_LICENSE = PROPRIETARY
would become
INTEL_MICROCODE_LICENSE = Intel microcode license
INTEL_MICROCODE_REDISTRIBUTE = NO
---------------------

These examples would mean that PROPRIETARY is still recognized as
magic value, but this does not match with the current code in
buildroot. The examples make a lot of sense to me, and I would be in
favor in changing the code towards this: recognize PROPRIETARY and not
save any legal info in this case (and ignore REDISTRIBUTE). At the
same time, the microcode situation can still use REDISTRIBUTE=NO but
it needs a license that is different than PROPRIETARY.
This is currently not ok for b43-firmware and owl-linux, but it is for
the other packages that set REDISTRIBUTE to NO (libfslcodec,
libfslparser, libfslvpuwrap, ux500-firmware).


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

As said above, my original though would be to reintroduce PROPRIETARY.

>
>
>>> 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 is also how I see 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.

To try and extract the license in buildroot is very fragile, and
pretty complex too.
Ideally upstream should make sure there is an appropriate license text
(at least for GPL this is required).
But as it is not realistic to expect all packages to comply with this,
I think a magic value for LICENSE_FILES as ThomasP suggested
(none/NONE) is sensible. This does not conflict with the definition of
a license as specified in LICENSE.

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

Isn't it roughly sufficient to change this line in package/pkg-generic.mk:
@$(call legal-manifest,$$($(2)_RAWNAME),$$($(2)_VERSION),$$($(2)_LICENSE),$$($(2)_MANIFEST_LICENSE_FILES),$$($(2)_MANIFEST_TARBALL))

to indicate that this is a host or target package, and change
legal-manifest to save to two separate files manifest.csv and
host-manifest.csv ?

Best regards,
Thomas

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Hi Arnout,

On Wed, Oct 2, 2013 at 6:31 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 10/02/13 16:06, Thomas De Schampheleire wrote:
>>
>> Hi,
>>
>> I am starting to use the legal-info infrastructure now, and this
>> resulted in a number of observations/problems, which I'll list below.
>>
>> 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.
>
>
>  I don't see why this is relevant. You probably anyway want to filter the
> license results to only contain the relevant licenses (i.e. the licenses
> that require you to mention the authors and the license in the
> documentation). And you can simply set the license to PROPRIETARY and grep
> it out of the csv file.

While some manipulation of the manifest will be necessary anyhow,
simply grepping out PROPRIETARY is not always correct. Currently, some
firmware packages list PROPRIETARY as license but do expect them to be
in the manifest, but not in the sources (REDISTRIBUTE=NO). So
according to the original thread and my reply to Luca on this thread,
I think these LICENSEs should be changed from PROPRIETARY to an actual
license. At the same time, I think it is nice if buildroot can do the
PROPRIETARY filtering for me.

By the way: do you really trim the manifest to only contain what is
absolutely necessary? I don't see a big problem in listing everything
and even providing sources for the BSD-licensed packages.

[..]

>
>> 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.
>
>
>  Actually it's not, the host packages are added explicitly to
> TARGETS_LEGAL_INFO.

You're right, it shouldn't be this hard after all...

Thanks for your input,
Thomas

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Hi Ryan,

On Wed, Oct 2, 2013 at 8:49 PM, Ryan Barnett
<rjbarnet@rockwellcollins.com> wrote:
> Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on
> 10/02/2013 09:06:13 AM:
>
> [...]
>
>
>> 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.
>
> One other thing that I would like to add about the legal-info that I
> would like to see added is the manifest.csv file contain the
> URL from which the source packages originated from. Is this something
> that people be interested in seeing added? As part of our release
> process, we need to show where the original source file came from (URL).
>

While I don't need the URL for my process, I currently also don't need
the name of the tarball in manifest.csv (and I leave out this last
column anyway). So, I'm not opposed to adding this extra column, but
there may be some caveats: with the OVERRIDE_SRCDIR mechanism it is
possible for a project to completely change the sources of an existing
package in buildroot. Strictly speaking this could mean that there is
no relation whatsoever between the URL specified in the .mk file and
the actual sources used. This is probably very exotic, though, and
maybe it doesn't really matter for your process.

Best regards,
Thomas

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Thomas,

Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on 
10/03/2013 03:34:30 AM:

> Hi Ryan,
> 
> On Wed, Oct 2, 2013 at 8:49 PM, Ryan Barnett
> <rjbarnet@rockwellcollins.com> wrote:
> > Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on
> > 10/02/2013 09:06:13 AM:
> >
> > [...]
> >
> >
> >> 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.
> >
> > One other thing that I would like to add about the legal-info that I
> > would like to see added is the manifest.csv file contain the
> > URL from which the source packages originated from. Is this something
> > that people be interested in seeing added? As part of our release
> > process, we need to show where the original source file came from 
(URL).
> >
> 
> While I don't need the URL for my process, I currently also don't need
> the name of the tarball in manifest.csv (and I leave out this last
> column anyway). So, I'm not opposed to adding this extra column, but
> there may be some caveats: with the OVERRIDE_SRCDIR mechanism it is
> possible for a project to completely change the sources of an existing
> package in buildroot. Strictly speaking this could mean that there is
> no relation whatsoever between the URL specified in the .mk file and
> the actual sources used. This is probably very exotic, though, and
> maybe it doesn't really matter for your process.

You bring up an interesting point that I never thought of. However, in
the application of OVERRIDE_SRCDIR, I would think that it mainly intended
for company's application but I could be wrong. 

I will go ahead an propose a patch in the next couple weeks that 
implements this feature and takes the OVERRIDE_SRDIR mechanism into 
consideration.

> Best regards,
> Thomas

Thanks,
-Ryan

------------------------------------------------------------------------------------------
Ryan J Barnett / Software Engineer / Platform SW
MS 137-157, 855 35th St NE, Cedar Rapids, IA, 52498-3161, US
rjbarnet at rockwellcollins.com
www.rockwellcollins.com

[Buildroot] Some legal-info observations/problems

[Danomi Manchego]

Ryan,

On Thu, Oct 3, 2013 at 9:31 AM, Ryan Barnett
<rjbarnet@rockwellcollins.com> wrote:
>> While I don't need the URL for my process, I currently also don't need
>> the name of the tarball in manifest.csv (and I leave out this last
>> column anyway). So, I'm not opposed to adding this extra column, but
>> there may be some caveats: with the OVERRIDE_SRCDIR mechanism it is
>> possible for a project to completely change the sources of an existing
>> package in buildroot. Strictly speaking this could mean that there is
>> no relation whatsoever between the URL specified in the .mk file and
>> the actual sources used. This is probably very exotic, though, and
>> maybe it doesn't really matter for your process.
>
> You bring up an interesting point that I never thought of. However, in
> the application of OVERRIDE_SRCDIR, I would think that it mainly intended
> for company's application but I could be wrong.

FWIW, several of our projects regularly use permanent OVERRIDE_SRCDIR
settings to compile exploded copies of uboot and xloader checked into
our source control system, rather than maintain patches against some
off-upstream vendor tarball; it's just easier than educating the folks
in remote offices about patching.

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Danomi, All,

Danomi Manchego <danomimanchego123@gmail.com> wrote on
10/03/2013 08:42:55 AM:

> Ryan,
> 
> On Thu, Oct 3, 2013 at 9:31 AM, Ryan Barnett
> <rjbarnet@rockwellcollins.com> wrote:
> >> While I don't need the URL for my process, I currently also don't 
need
> >> the name of the tarball in manifest.csv (and I leave out this last
> >> column anyway). So, I'm not opposed to adding this extra column, but
> >> there may be some caveats: with the OVERRIDE_SRCDIR mechanism it is
> >> possible for a project to completely change the sources of an 
existing
> >> package in buildroot. Strictly speaking this could mean that there is
> >> no relation whatsoever between the URL specified in the .mk file and
> >> the actual sources used. This is probably very exotic, though, and
> >> maybe it doesn't really matter for your process.
> >
> > You bring up an interesting point that I never thought of. However, in
> > the application of OVERRIDE_SRCDIR, I would think that it mainly 
intended
> > for company's application but I could be wrong.
> 
> FWIW, several of our projects regularly use permanent OVERRIDE_SRCDIR
> settings to compile exploded copies of uboot and xloader checked into
> our source control system, rather than maintain patches against some
> off-upstream vendor tarball; it's just easier than educating the folks
> in remote offices about patching.

Thanks for the use case as I never though of that since I've just maintain
a large u-boot/x-loader patch set.

My thought for how this column would work is that if the OVERRIDE_SRCDIR
is used that in the column, "OVERRIDE_SRCDIR Used" would be placed instead
of the URL. This will also make sure that someone explicitly knows they 
are
using the OVERRIDE_SRCDIR feature (not that isn't already obvious in 
local.mk)

Thanks,
-Ryan

[Buildroot] Some legal-info observations/problems

[Arnout Vandecappelle]

On 10/03/13 10:24, Thomas De Schampheleire wrote:
> Hi Luca,
>
> On Wed, Oct 2, 2013 at 6:33 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
>> 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.
>
> I re-read the original thread, specifically your answer to it:
> http://lists.busybox.net/pipermail/buildroot/2012-October/059402.html
>
> Here is an excerpt:
> ---------------------
> A clean solution is probably to let the _LICENSE do its work, i.e. simply
> describe the license, and add a new _REDISTRUBUTE parameter (defaulting to
> YES), to specify if the tarball must be copied or not.
> Defining the license and choosing whether or not to redistribute would
> become technically independent, which is more correct.
>
> Examples:
>
> MYAPP_LICENSE = PROPRIETARY
> would become
> MYAPP_LICENSE = PROPRIETARY
> MYAPP_REDISTRIBUTE = NO
> or
> MYAPP_LICENSE = Copyright (C) 2012 My Company # just an idea
> MYAPP_REDISTRIBUTE = NO
>
> INTEL_MICROCODE_LICENSE = PROPRIETARY
> would become
> INTEL_MICROCODE_LICENSE = Intel microcode license
> INTEL_MICROCODE_REDISTRIBUTE = NO
> ---------------------
>
> These examples would mean that PROPRIETARY is still recognized as
> magic value, but this does not match with the current code in
> buildroot.

  Yes it does. In the example, only MYAPP_LICENSE is still PROPRIETARY 
and it doesn't carry any meaning anymore.

> The examples make a lot of sense to me, and I would be in
> favor in changing the code towards this: recognize PROPRIETARY and not
> save any legal info in this case (and ignore REDISTRIBUTE).

  +1 to this. Perhaps PROPRIETARY isn't the best name, though, but I 
can't think of anything better.

> At the
> same time, the microcode situation can still use REDISTRIBUTE=NO but
> it needs a license that is different than PROPRIETARY.
> This is currently not ok for b43-firmware and owl-linux, but it is for
> the other packages that set REDISTRIBUTE to NO (libfslcodec,
> libfslparser, libfslvpuwrap, ux500-firmware).

  gst-fsl-plugins and on2-8170-libs set PROPRIETARY as well.

  Note that for b43-firmware, the license is not specified, and for 
owl-linux, the "license" isn't a license but only a warranty disclaimer. 
So for these, perhaps a better text is something like "Do not use unless 
you are licensed by H&D Wireless AB".

[snip]

>>>> 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 is also how I see it.

  So in this situation, the proper way to deal with it is to issue a 
warning, right? Which is exactly what the current code does.

  I can think of only one situation (except for the PROPRIETARY case) 
where no license text is provided and we don't need to be warned of this, 
and that is when it is public domain. But maybe that's just a limit of my 
imagination :-).

  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. As to the naming, I think N/A is very good because the 
chance of having an N directory with an A file is very small.


  Regards,
  Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Some legal-info observations/problems

[Arnout Vandecappelle]

On 10/03/13 16:12, Ryan Barnett wrote:
> Danomi, All,
>
> Danomi Manchego <danomimanchego123@gmail.com> wrote on
> 10/03/2013 08:42:55 AM:
>
>> Ryan,
>>
>> On Thu, Oct 3, 2013 at 9:31 AM, Ryan Barnett
>> <rjbarnet@rockwellcollins.com> wrote:
>>>> While I don't need the URL for my process, I currently also don't
> need
>>>> the name of the tarball in manifest.csv (and I leave out this last
>>>> column anyway). So, I'm not opposed to adding this extra column, but
>>>> there may be some caveats: with the OVERRIDE_SRCDIR mechanism it is
>>>> possible for a project to completely change the sources of an
> existing
>>>> package in buildroot. Strictly speaking this could mean that there is
>>>> no relation whatsoever between the URL specified in the .mk file and
>>>> the actual sources used. This is probably very exotic, though, and
>>>> maybe it doesn't really matter for your process.
>>>
>>> You bring up an interesting point that I never thought of. However, in
>>> the application of OVERRIDE_SRCDIR, I would think that it mainly
> intended
>>> for company's application but I could be wrong.

  It was originally intended for temporarily testing a modified version 
of a package, which you commit by generating patches from it. But I 
expect that in companies it will indeed be mainly used for the application.


>> FWIW, several of our projects regularly use permanent OVERRIDE_SRCDIR
>> settings to compile exploded copies of uboot and xloader checked into
>> our source control system, rather than maintain patches against some
>> off-upstream vendor tarball; it's just easier than educating the folks
>> in remote offices about patching.

  Actually, BR2_TARGET_UBOOT_CUSTOM_GIT and 
BR2_TARGET_UBOOT_CUSTOM_TARBALL exist for exactly this purpose. Of 
course, there's no equivalent for xloader, but you should start using 
U-Boot SPL anyway :-)


> Thanks for the use case as I never though of that since I've just maintain
> a large u-boot/x-loader patch set.
>
> My thought for how this column would work is that if the OVERRIDE_SRCDIR
> is used that in the column, "OVERRIDE_SRCDIR Used" would be placed instead
> of the URL. This will also make sure that someone explicitly knows they
> are
> using the OVERRIDE_SRCDIR feature (not that isn't already obvious in
> local.mk)

  Sounds like a good idea to me.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Some legal-info observations/problems

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 Thomas> While I don't need the URL for my process, I currently also
 Thomas> don't need the name of the tarball in manifest.csv (and I leave
 Thomas> out this last column anyway). So, I'm not opposed to adding
 Thomas> this extra column, but there may be some caveats: with the
 Thomas> OVERRIDE_SRCDIR mechanism it is possible for a project to
 Thomas> completely change the sources of an existing package in
 Thomas> buildroot. Strictly speaking this could mean that there is no
 Thomas> relation whatsoever between the URL specified in the .mk file
 Thomas> and the actual sources used. This is probably very exotic,
 Thomas> though, and maybe it doesn't really matter for your process.

Same could be said about the other fields (license, license files). In
general, you can only expect the legal-info stuff to be (hopefully)
valid if you don't override.

But yeah, I would be OK with adding the upstream URL (as in <pkg>_SITE).

-- 
Bye, Peter Korsgaard

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Peter, Thomas, All,

Peter Korsgaard <jacmet@gmail.com> wrote on 10/03/2013 04:38:56 PM:

> >>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> 
writes:
> 
> Hi,
> 
>  Thomas> While I don't need the URL for my process, I currently also
>  Thomas> don't need the name of the tarball in manifest.csv (and I leave
>  Thomas> out this last column anyway). So, I'm not opposed to adding
>  Thomas> this extra column, but there may be some caveats: with the
>  Thomas> OVERRIDE_SRCDIR mechanism it is possible for a project to
>  Thomas> completely change the sources of an existing package in
>  Thomas> buildroot. Strictly speaking this could mean that there is no
>  Thomas> relation whatsoever between the URL specified in the .mk file
>  Thomas> and the actual sources used. This is probably very exotic,
>  Thomas> though, and maybe it doesn't really matter for your process.
> 
> Same could be said about the other fields (license, license files). In
> general, you can only expect the legal-info stuff to be (hopefully)
> valid if you don't override.
> 
> But yeah, I would be OK with adding the upstream URL (as in <pkg>_SITE).

Hopefully, if under the upstream URL if I put "OVERRIDE_SRCDIR Used" in
the column it can indicate that everything should be taken with a grain
of salt.

Thanks,
-Ryan

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Hi Arnout,

On Thu, Oct 3, 2013 at 6:40 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 10/03/13 10:24, Thomas De Schampheleire wrote:
>>
>>>>
>>>> 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 is also how I see it.
>
>
>  So in this situation, the proper way to deal with it is to issue a warning,
> right? Which is exactly what the current code does.
>
>  I can think of only one situation (except for the PROPRIETARY case) where
> no license text is provided and we don't need to be warned of this, and that
> is when it is public domain. But maybe that's just a limit of my imagination
> :-).

Probably a warning is the safe action here, because most licenses do
indeed require you to distribute the actual text, as you mentioned.
However, I dislike the current warning 'FOO_LICENSE_FILES not defined'
because it is not accurate: in such a case we _know_ that the package
does not contain a license file and intentionally provided an empty or
magic FOO_LICENSE_FILES. So the warning should rather be something
like: 'foo does not contain a license file'.

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.

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

> As to
> the naming, I think N/A is very good because the chance of having an N
> directory with an A file is very small.

The chances of having a license file called none or NONE are also
pretty small IMO :)

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

Best regards,
Thomas

[Buildroot] Some legal-info observations/problems

[Thomas Petazzoni]

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

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote on 
10/04/2013 04:07:04 AM:

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

What if the license files are only available from a website?

For example, I'm looking to add a new package, tornado (python webserver)
to buildroot- http://www.tornadoweb.org/en/stable/ . However the license
isn't apart of the distribution itself but it points me to a website for
the license.

http://www.apache.org/licenses/LICENSE-2.0.html

Would we then put N/A for the license file? Or how do we want to handle 
this?

This is the second time in about a week that I've run into this well 
adding
a new package?

Eventually in my release process, I will have to go to that website and 
get
that license, be it Apache, or whatever license it may be and package that
up so supporting a URL method of getting a license would be nice.

[...]

Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131004/da956356/attachment.html>

[Buildroot] Some legal-info observations/problems

[Thomas Petazzoni]

Dear Ryan Barnett,

On Fri, 4 Oct 2013 10:30:36 -0500, Ryan Barnett wrote:

> What if the license files are only available from a website?
> 
> For example, I'm looking to add a new package, tornado (python webserver)
> to buildroot- http://www.tornadoweb.org/en/stable/ . However the license
> isn't apart of the distribution itself but it points me to a website for
> the license.
> 
> http://www.apache.org/licenses/LICENSE-2.0.html
> 
> Would we then put N/A for the license file? Or how do we want to handle 
> this?
> 
> This is the second time in about a week that I've run into this well 
> adding
> a new package?
> 
> Eventually in my release process, I will have to go to that website and 
> get
> that license, be it Apache, or whatever license it may be and package that
> up so supporting a URL method of getting a license would be nice.

My suggestion in this case would be to use <pkg>_LICENSE_FILES = N/A
(or whatever magic value is chosen) and in parallel ask the upstream
maintainer to include the license file directly into the release
tarballs.

Best regards,

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

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote on 
10/04/2013 10:34:52 AM:

> Dear Ryan Barnett,
> 
> On Fri, 4 Oct 2013 10:30:36 -0500, Ryan Barnett wrote:
> 
> > What if the license files are only available from a website?
> > 
> > For example, I'm looking to add a new package, tornado (python 
webserver)
> > to buildroot- http://www.tornadoweb.org/en/stable/ . However the 
license
> > isn't apart of the distribution itself but it points me to a website 
for
> > the license.
> > 
> > http://www.apache.org/licenses/LICENSE-2.0.html
> > 
> > Would we then put N/A for the license file? Or how do we want to 
handle 
> > this?
> > 
> > This is the second time in about a week that I've run into this well 
> > adding
> > a new package?
> > 
> > Eventually in my release process, I will have to go to that website 
and 
> > get
> > that license, be it Apache, or whatever license it may be and package 
that
> > up so supporting a URL method of getting a license would be nice.
> 
> My suggestion in this case would be to use <pkg>_LICENSE_FILES = N/A
> (or whatever magic value is chosen) and in parallel ask the upstream
> maintainer to include the license file directly into the release
> tarballs.

I'm fine with this approach, with having the magic value there it 
will help know that these are files that I manually need to go 
pull the licenses for.

I just thought I would through this situation I ran into today
out in this discussion since it is very applicable.

Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131004/391a2f78/attachment-0001.html>

[Buildroot] Some legal-info observations/problems

[Simon Dawson]

On 4 October 2013 16:34, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> My suggestion in this case would be to use <pkg>_LICENSE_FILES = N/A
> (or whatever magic value is chosen) and in parallel ask the upstream
> maintainer to include the license file directly into the release
> tarballs.

This is an existing problem for the jquery package, where there is no
release tarball as such. It would be nice to be able to specify URLs
in the <pkg>_LICENSE_FILES variable.

[Buildroot] Some legal-info observations/problems

[Luca Ceresoli]

Hi Thomas,

Thomas De Schampheleire wrote:

> Hi Luca,
>
> On Wed, Oct 2, 2013 at 6:33 PM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
>> Dear ThomasDe Schampheleire,
>>
>> thanksfor the comments and detailed analysis.
> side note: I'm seeing some weird lack of spaces throughout the e-mail,
> for example 'thanksfor', 'ThomasDe'. Is this a compression strategy?

Of course! I plan to xz my future mail messages, be prepared th that!

No, just joking. I noticed it as well, but I'm sure i did not make so
many mistakes when typing.I'm afraid I guess it's a Thunderbird bug.

>> 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.
> I re-read the original thread, specifically your answer to it:
> http://lists.busybox.net/pipermail/buildroot/2012-October/059402.html
>
> Here is an excerpt:
> ---------------------
> A clean solution is probably to let the _LICENSE do its work, i.e. simply
> describe the license, and add a new _REDISTRUBUTE parameter (defaulting to
> YES), to specify if the tarball must be copied or not.
> Defining the license and choosing whether or not to redistribute would
> become technically independent, which is more correct.
>
> Examples:
>
> MYAPP_LICENSE = PROPRIETARY
> would become
> MYAPP_LICENSE = PROPRIETARY
> MYAPP_REDISTRIBUTE = NO
> or
> MYAPP_LICENSE = Copyright (C) 2012 My Company # just an idea
> MYAPP_REDISTRIBUTE = NO
>
> INTEL_MICROCODE_LICENSE = PROPRIETARY
> would become
> INTEL_MICROCODE_LICENSE = Intel microcode license
> INTEL_MICROCODE_REDISTRIBUTE = NO
> ---------------------
>
> These examples would mean that PROPRIETARY is still recognized as
> magic value, but this does not match with the current code in

No, the meaning of my quoted text is that there is no magic word
anymore. "PROPRIETARY" is treated just like "BSD-3c" or "Fuzzy License".
This what the current BR code does as well.

> buildroot. The examples make a lot of sense to me, and I would be in
> favor in changing the code towards this: recognize PROPRIETARY and not
> save any legal info in this case (and ignore REDISTRIBUTE). At the
> same time, the microcode situation can still use REDISTRIBUTE=NO but
> it needs a license that is different than PROPRIETARY.
> This is currently not ok for b43-firmware and owl-linux, but it is for
> the other packages that set REDISTRIBUTE to NO (libfslcodec,
> libfslparser, libfslvpuwrap, ux500-firmware).
>
>
>> 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?
> As said above, my original though would be to reintroduce PROPRIETARY.

I do not like to have a BR variable whose meaning can be either a magic
word "PROPRIETARY", that BR handles in a specific way, or a generic string,
that's just a text to carry around for BR.
Hence my proposal of splitting the whole thing in two variables:
FOO_SAVE_LEGAL_INFO = {YES|NO} and FOO_LICENSE = <plain text>. They have
two different meanings.

But this is just my opinion.

>
>>
>>>> 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 is also how I see 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.
> To try and extract the license in buildroot is very fragile, and
> pretty complex too.
> Ideally upstream should make sure there is an appropriate license text
> (at least for GPL this is required).
> But as it is not realistic to expect all packages to comply with this,

I fully agree.

> I think a magic value for LICENSE_FILES as ThomasP suggested
> (none/NONE) is sensible. This does not conflict with the definition of
> a license as specified in LICENSE.

"none" may either mean there is no license text (as Arnout noticed this 
should
be fairly rare, but who knows) or that the license text exists, but BR 
cannot
produce it as a file. We probably should these two cases visible in the
manifest.


-- 
Luca

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

Luca, all,

Let's try to summarize/conclude on these items...

On Wed, Oct 2, 2013 at 4:06 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi,
>
> I am starting to use the legal-info infrastructure now, and this
> resulted in a number of observations/problems, which I'll list below.
>
> 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.

Since Luca is not in favor of keeping a magic value like PROPRIETARY,
I'm ok with his suggestion of FOO_SAVE_LEGAL_INFO = YES/NO combined
with FOO_REDISTRIBUTE = YES/NO:

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

----

If others are too, then we can move forward with implementing it.

>
> 2. suppose FOO_LICENSE_FILES = subdir/COPYING, then the manifest also
> contains the string 'subdir/COPYING'. However, the license is copied
> into a flat structure output/legal-info/licenses/foo/, so I think that
> the manifest should no longer mention the 'subdir'.
> Of course, this may contradict with the needs of licenses.txt (the
> flat representation of all licenses) that does not suffer from the
> subdir problem.
>
> 3. partially related to point 2: if a package has multiple license
> files with the same name but in subdirectories, e.g. a/COPYING and
> b/COPYING, the copying of the license will copy both files on top of
> each other. This is the case for xenomai-forge (not yet in buildroot),
> which is the new strategy for xenomai [1]. I have brought up this
> issue with the developers [2], but maybe there is something else we
> can do.
>
> [1] http://git.xenomai.org/?p=xenomai-forge.git;a=summary
> [2] http://www.xenomai.org/pipermail/xenomai/2013-October/029262.html

Both points have been addressed properly with Peter's patch.

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

Reading the various comments I have the impression there is a
consensus to define a magic value for FOO_LICENSE_FILES, correct. The
question is: which value(s). If we want to differentiate between:
a. there is a license, it has a license text, but the text is not
provided with the sources, and
b. there is a license but there doesn't exist any license text,
then we need two magic values.

There were a few suggestions:
N/A, none, NONE (ThomasP), which would cover (b)
missing (rejected by ThomasP), not-provided, none-provided (ThomasDS),
which would cover (a)


In case of (a), I'm not sure if a warning is needed. It could for
example be that the license is 'public domain' which doesn't need a
license text.
For (b) I think a warning is a good idea.



Related to this is the question of a license URL. I personally think
it is not legally safe to only refer to a URL from a package, because
who knows someone changes the license text on the URL. They could just
alter the license of existing sources.
So although the feature of automatically downloading a license text
from its URL looks nice, I (not a lawyer) would not recommend
implementing it. I follow ThomasP's reasoning of requesting upstream
to add the effective license text to the sources, and in the meantime
using the magic value decided above for case (b).

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

This point has been addressed by my patches that split the legal info
output between host/target.

Best regards,
Thomas

[Buildroot] Some legal-info observations/problems

[Arnout Vandecappelle]

On 10/04/13 17:46, Simon Dawson wrote:
> On 4 October 2013 16:34, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> My suggestion in this case would be to use <pkg>_LICENSE_FILES = N/A
>> (or whatever magic value is chosen) and in parallel ask the upstream
>> maintainer to include the license file directly into the release
>> tarballs.
>
> This is an existing problem for the jquery package, where there is no
> release tarball as such. It would be nice to be able to specify URLs
> in the <pkg>_LICENSE_FILES variable.

  +1.

  Now to find a volunteer who implements it :-)

  Ideally, such an external license should be downloaded already with 
'make source'. Though that is perhaps stretching it a little...

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Some legal-info observations/problems

[Simon Dawson]

On 7 October 2013 23:43, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 10/04/13 17:46, Simon Dawson wrote:
>> This is an existing problem for the jquery package, where there is no
>> release tarball as such. It would be nice to be able to specify URLs
>> in the <pkg>_LICENSE_FILES variable.
>
>
>  +1.
>
>  Now to find a volunteer who implements it :-)
>
>  Ideally, such an external license should be downloaded already with 'make
> source'. Though that is perhaps stretching it a little...

This can now be achieved by using Thomas P's new <pkg>_EXTRA_DOWNLOADS
mechanism to download the license file(s); I wonder if that would be
an acceptable idiom in this situation...?

Simon.

[Buildroot] Some legal-info observations/problems

[Thomas Petazzoni]

Dear Simon Dawson,

On Wed, 9 Oct 2013 08:23:27 +0100, Simon Dawson wrote:

> >  Ideally, such an external license should be downloaded already with 'make
> > source'. Though that is perhaps stretching it a little...
> 
> This can now be achieved by using Thomas P's new <pkg>_EXTRA_DOWNLOADS
> mechanism to download the license file(s); I wonder if that would be
> an acceptable idiom in this situation...?

Potential problems:

 * <pkg>_EXTRA_DOWNLOADS downloads from the same <pkg>_SITE that is
   used to download <pkg>_SOURCE. So if your tarball and license files
   are not at the same location, it won't work. This could be fixed by
   having <pkg>_EXTRA_DOWNLOADS use a full path rather than relying on
   <pkg>_SITE.

 * <pkg>_EXTRA_DOWNLOADS = foo will download the file as "foo" in the
   download directory. However, I do expect many of the license files
   that you would download this way to have relatively similar names:
   COPYING, LICENSE, Copyright, or something like that. And therefore,
   if two different packages have <pkg>_EXTRA_DOWNLOADS =
   http://someplace/COPYING, the COPYING files would overwrite each
   other in the download directory.

Best regards,

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

[Buildroot] Some legal-info observations/problems

[Simon Dawson]

On 9 October 2013 08:29, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Simon Dawson,
>
> On Wed, 9 Oct 2013 08:23:27 +0100, Simon Dawson wrote:
>
>> >  Ideally, such an external license should be downloaded already with 'make
>> > source'. Though that is perhaps stretching it a little...
>>
>> This can now be achieved by using Thomas P's new <pkg>_EXTRA_DOWNLOADS
>> mechanism to download the license file(s); I wonder if that would be
>> an acceptable idiom in this situation...?
>
> Potential problems:
>
>  * <pkg>_EXTRA_DOWNLOADS downloads from the same <pkg>_SITE that is
>    used to download <pkg>_SOURCE. So if your tarball and license files
>    are not at the same location, it won't work. This could be fixed by
>    having <pkg>_EXTRA_DOWNLOADS use a full path rather than relying on
>    <pkg>_SITE.

Hmm, yes. It doesn't seem right to *require* a full path for
<pkg>_EXTRA_DOWNLOADS though, does it?

>  * <pkg>_EXTRA_DOWNLOADS = foo will download the file as "foo" in the
>    download directory. However, I do expect many of the license files
>    that you would download this way to have relatively similar names:
>    COPYING, LICENSE, Copyright, or something like that. And therefore,
>    if two different packages have <pkg>_EXTRA_DOWNLOADS =
>    http://someplace/COPYING, the COPYING files would overwrite each
>    other in the download directory.

Yes, agreed. So probably re-using this mechanism for license files
isn't the right way to go.

Simon.

[Buildroot] Some legal-info observations/problems

[Luca Ceresoli]

Hi Thomas,

I ack all of your report. Just a few notes below.

Thomas De Schampheleire wrote:
> Luca, all,
>
> Let's try to summarize/conclude on these items...
>

...

>> 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'.
>
> Reading the various comments I have the impression there is a
> consensus to define a magic value for FOO_LICENSE_FILES, correct. The
> question is: which value(s). If we want to differentiate between:
> a. there is a license, it has a license text, but the text is not
> provided with the sources, and
> b. there is a license but there doesn't exist any license text,
> then we need two magic values.
>
> There were a few suggestions:
> N/A, none, NONE (ThomasP), which would cover (b)
> missing (rejected by ThomasP), not-provided, none-provided (ThomasDS),
> which would cover (a)

(a) is for cases when we are unable to extract the text, so what about 
"not-extracted"?

>
>
> In case of (a), I'm not sure if a warning is needed. It could for
> example be that the license is 'public domain' which doesn't need a
> license text.
> For (b) I think a warning is a good idea.
>
>
>
> Related to this is the question of a license URL. I personally think
> it is not legally safe to only refer to a URL from a package, because
> who knows someone changes the license text on the URL. They could just
> alter the license of existing sources.
> So although the feature of automatically downloading a license text
> from its URL looks nice, I (not a lawyer) would not recommend
> implementing it. I follow ThomasP's reasoning of requesting upstream
> to add the effective license text to the sources, and in the meantime
> using the magic value decided above for case (b).

I agree with you. Regarding the legal stuff we should stay on the safe 
side. But Arnout and Simon expressed an opposite opinion on another 
branch of this thread...

-- 
Luca

[Buildroot] Some legal-info observations/problems

[Arnout Vandecappelle]

On 10/09/13 15:14, Luca Ceresoli wrote:
>> Related to this is the question of a license URL. I personally think
>> it is not legally safe to only refer to a URL from a package, because
>> who knows someone changes the license text on the URL. They could just
>> alter the license of existing sources.
>> So although the feature of automatically downloading a license text
>> from its URL looks nice, I (not a lawyer) would not recommend
>> implementing it. I follow ThomasP's reasoning of requesting upstream
>> to add the effective license text to the sources, and in the meantime
>> using the magic value decided above for case (b).
>
> I agree with you. Regarding the legal stuff we should stay on the safe
> side. But Arnout and Simon expressed an opposite opinion on another
> branch of this thread...

  If the package specifies that the license is available at a specific 
URL, then that is the license, right? It is true that the license may 
change unexpectedly, but to make sure it stays consistent we should 
download the license at the same time that the source is downloaded 
(which could be tricky, I admit).

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Some legal-info observations/problems

[Ryan Barnett]

Luca, Thomas D., All,

I also ack on all agreed upon with the following condition (see below)

Luca Ceresoli <luca@lucaceresoli.net> wrote on 10/09/2013 08:14:54 AM:

> Hi Thomas,
> 
> I ack all of your report. Just a few notes below.
> 
> Thomas De Schampheleire wrote:
> > Luca, all,
> >
> > Let's try to summarize/conclude on these items...
> >
> 
> ...
> 
> >> 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'.
> >
> > Reading the various comments I have the impression there is a
> > consensus to define a magic value for FOO_LICENSE_FILES, correct. The
> > question is: which value(s). If we want to differentiate between:
> > a. there is a license, it has a license text, but the text is not
> > provided with the sources, and
> > b. there is a license but there doesn't exist any license text,
> > then we need two magic values.
> >
> > There were a few suggestions:
> > N/A, none, NONE (ThomasP), which would cover (b)
> > missing (rejected by ThomasP), not-provided, none-provided (ThomasDS),
> > which would cover (a)
> 
> (a) is for cases when we are unable to extract the text, so what about 
> "not-extracted"?
> 
> >
> >
> > In case of (a), I'm not sure if a warning is needed. It could for
> > example be that the license is 'public domain' which doesn't need a
> > license text.
> > For (b) I think a warning is a good idea.
> >
> >
> >
> > Related to this is the question of a license URL. I personally think
> > it is not legally safe to only refer to a URL from a package, because
> > who knows someone changes the license text on the URL. They could just
> > alter the license of existing sources.
> > So although the feature of automatically downloading a license text
> > from its URL looks nice, I (not a lawyer) would not recommend
> > implementing it. I follow ThomasP's reasoning of requesting upstream
> > to add the effective license text to the sources, and in the meantime
> > using the magic value decided above for case (b).
> 
> I agree with you. Regarding the legal stuff we should stay on the safe 
> side. But Arnout and Simon expressed an opposite opinion on another 
> branch of this thread...

I would like to see that document under the "Legal notice and licensing"
be updated to reflect what was said in this discussion. Specifically
what to do when license isn't proved.

> -- 
> Luca

Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131009/7a084a82/attachment.html>

[Buildroot] Some legal-info observations/problems

[Thomas De Schampheleire]

On Wed, Oct 9, 2013 at 6:46 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 10/09/13 15:14, Luca Ceresoli wrote:
>>>
>>> Related to this is the question of a license URL. I personally think
>>> it is not legally safe to only refer to a URL from a package, because
>>> who knows someone changes the license text on the URL. They could just
>>> alter the license of existing sources.
>>> So although the feature of automatically downloading a license text
>>> from its URL looks nice, I (not a lawyer) would not recommend
>>> implementing it. I follow ThomasP's reasoning of requesting upstream
>>> to add the effective license text to the sources, and in the meantime
>>> using the magic value decided above for case (b).
>>
>>
>> I agree with you. Regarding the legal stuff we should stay on the safe
>> side. But Arnout and Simon expressed an opposite opinion on another
>> branch of this thread...
>
>
>  If the package specifies that the license is available at a specific URL,
> then that is the license, right? It is true that the license may change
> unexpectedly, but to make sure it stays consistent we should download the
> license at the same time that the source is downloaded (which could be
> tricky, I admit).

So here we have a choice between:
a. adding a feature in buildroot to download the license from a URL,
working around an upstream problem
b. warning the user at the time of legal-info, and at the same time
contacting upstream and asking them to fix their source package
(including the license text).

While a. may seem nice for the buildroot user, it is not really
solving the bigger problem, IMO.

In fact, there are so many open-source projects that don't properly indicate:
- which license the project falls under
- what the authors really expect with respect to licensing
So ideally we try to change that for some of these projects.

Best regards,
Thomas