[OE-core] inconsistency with adding LICENSE lines to images

Flanagan, Elizabeth elizabeth.flanagan at intel.com
Tue Mar 3 12:54:23 UTC 2015


On 3 March 2015 at 11:25, Paul Eggleton <paul.eggleton at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Elizabeth Flanagan
Yocto Project
Build and Release



More information about the Openembedded-core mailing list