inconsistency with adding LICENSE lines to images

inconsistency with adding LICENSE lines to images

[Robert P. J. Day]

  just noticed the following ... in OE image definition files under
recipes-core:

core-image-base.bb
core-image-minimal.bb
core-image-minimal-dev.bb
core-image-minimal-initramfs.bb
core-image-minimal-mtdutils.bb

it *seems* to make sense that image definitions that require or
include other core image bb files don't need to add the line:

LICENSE = "MIT"

as they pick it up from the include'd or require'd file, but image
recipe files that

inherit core-image

*do* need to define their own license.

  but if one then goes under recipes-extended/images, it looks a bit
strange as, for example, here's core-image-full-cmdline.bb:

DESCRIPTION = "A console-only image with more full-featured Linux system \
functionality installed."

IMAGE_FEATURES += "splash ssh-server-openssh"

IMAGE_INSTALL = "\
    packagegroup-core-boot \
    packagegroup-core-full-cmdline \
    ${CORE_IMAGE_EXTRA_INSTALL} \
    "

inherit core-image

  so ... what's the licensing there? this image inherits directly from
core-image, but doesn't define a license? am i misunderstanding the
need for a license?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: inconsistency with adding LICENSE lines to images

[Paul Eggleton]

On Friday 27 February 2015 15:58:32 Robert P. J. Day wrote:
>   just noticed the following ... in OE image definition files under
> recipes-core:
> 
> core-image-base.bb
> core-image-minimal.bb
> core-image-minimal-dev.bb
> core-image-minimal-initramfs.bb
> core-image-minimal-mtdutils.bb
> 
> it *seems* to make sense that image definitions that require or
> include other core image bb files don't need to add the line:
> 
> LICENSE = "MIT"
> 
> as they pick it up from the include'd or require'd file, but image
> recipe files that
> 
> inherit core-image
> 
> *do* need to define their own license.
> 
>   but if one then goes under recipes-extended/images, it looks a bit
> strange as, for example, here's core-image-full-cmdline.bb:
> 
> DESCRIPTION = "A console-only image with more full-featured Linux system \
> functionality installed."
> 
> IMAGE_FEATURES += "splash ssh-server-openssh"
> 
> IMAGE_INSTALL = "\
>     packagegroup-core-boot \
>     packagegroup-core-full-cmdline \
>     ${CORE_IMAGE_EXTRA_INSTALL} \
>     "
> 
> inherit core-image
> 
>   so ... what's the licensing there? this image inherits directly from
> core-image, but doesn't define a license? am i misunderstanding the
> need for a license?

There shouldn't be a need to set this for image recipes whether they inherit 
image or core-image, since recipes don't generally distribute any files other 
than those that come from packages that they include (which have their own 
licenses) - it wouldn't be practical to list all of the licenses for all of 
the components of the image, that is what we produce the license manifest for. 

On the other hand, if you re-enable do_fetch and add files to SRC_URI within 
the image recipe (which should generally be avoided but is done in rare cases 
- build-appliance-image is one example) then you probably ought to be 
concerned with the LICENSE value. Having said that I don't know if the license 
manifest logic actually looks at the LICENSE value for the image at all, I 
suspect it does not.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: inconsistency with adding LICENSE lines to images

[Flanagan, Elizabeth]

On 3 March 2015 at 11:25, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> On Friday 27 February 2015 15:58:32 Robert P. J. Day wrote:
>>   just noticed the following ... in OE image definition files under
>> recipes-core:
>>
>> core-image-base.bb
>> core-image-minimal.bb
>> core-image-minimal-dev.bb
>> core-image-minimal-initramfs.bb
>> core-image-minimal-mtdutils.bb
>>
>> it *seems* to make sense that image definitions that require or
>> include other core image bb files don't need to add the line:
>>
>> LICENSE = "MIT"
>>
>> as they pick it up from the include'd or require'd file, but image
>> recipe files that
>>
>> inherit core-image
>>
>> *do* need to define their own license.
>>
>>   but if one then goes under recipes-extended/images, it looks a bit
>> strange as, for example, here's core-image-full-cmdline.bb:
>>
>> DESCRIPTION = "A console-only image with more full-featured Linux system \
>> functionality installed."
>>
>> IMAGE_FEATURES += "splash ssh-server-openssh"
>>
>> IMAGE_INSTALL = "\
>>     packagegroup-core-boot \
>>     packagegroup-core-full-cmdline \
>>     ${CORE_IMAGE_EXTRA_INSTALL} \
>>     "
>>
>> inherit core-image
>>
>>   so ... what's the licensing there? this image inherits directly from
>> core-image, but doesn't define a license? am i misunderstanding the
>> need for a license?
>
> There shouldn't be a need to set this for image recipes whether they inherit
> image or core-image, since recipes don't generally distribute any files other
> than those that come from packages that they include (which have their own
> licenses) - it wouldn't be practical to list all of the licenses for all of
> the components of the image, that is what we produce the license manifest for.
>
> On the other hand, if you re-enable do_fetch and add files to SRC_URI within
> the image recipe (which should generally be avoided but is done in rare cases
> - build-appliance-image is one example) then you probably ought to be
> concerned with the LICENSE value. Having said that I don't know if the license
> manifest logic actually looks at the LICENSE value for the image at all, I
> suspect it does not.

It doesn't. It actually should in this case (and probably all cases).
Once Aníbals patches that fix some of the performance issues we've
been seeing in license.bbclass hit master, let's fix that. That said,
there are other license manifest issues with build-appliance.

Example from the build-appliance recipe:

cp -RpL ${DL_DIR}/* ${IMAGE_ROOTFS}/home/builder/poky/build/downloads/

Right there, as we're not necessarily building out all those downloads
in that build run, we're not getting all of that captured within the
manifest. So, essentially, the manifest for ba is inaccurate unless
DL_DIR is completely empty.

I think build-appliance is going to have to be a very special case
when it comes to creating a manifest for it.

-b

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Elizabeth Flanagan
Yocto Project
Build and Release