inconsistency with adding LICENSE lines to images
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
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 35 lines · 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.bbit *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} \ "
Quoted 5 lines
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
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 48 lines · Paul Eggleton
Quoted 35 lines · 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.bbit *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} \ "Quoted 5 lines
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.
Quoted 6 lines
On the other hand, if you re-enable
do_fetchand add files toSRC_URIwithin 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
Quoted 13 lines
Cheers,
Paul--
Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 3 lines
Elizabeth Flanagan Yocto Project Build and Release