image.bbclass: allow override of image LICENSE
PATCH 1/1 image.bbclass: allow override of image LICENSE
Currently the LICENSE of every image is hard set to MIT. This allows this to be overriden in derived images.
--- meta/classes/image.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/image.bbclass +1 -1
@@ -9,7 +9,7 @@ TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}" TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY}" POPULATE_SDK_POST_TARGET_COMMAND += "rootfs_sysroot_relativelinks; " -LICENSE = "MIT" +LICENSE ?= "MIT" PACKAGES = "" DEPENDS += "${MLPREFIX}qemuwrapper-cross depmodwrapper-cross" RDEPENDS += "${PACKAGE_INSTALL} ${LINGUAS_INSTALL}"
Signature · 1 line
2.1.4
Hi Pascal,
Quoted 2 lines · NZDT Pascal Bach
Currently the LICENSE of every image is hard set to MIT. This allows this to be overriden in derived images.
Sorry to dredge this up, but when do you see the need to specify a different image LICENSE?
Logically, an image recipe's LICENSE can only refer to the recipe itself and whatever files might be pulled in by it directly (usually none, but some people re-enable do_fetch and do_unpack to allow this), since otherwise the contents of the image are covered by the licenses of all of the recipes that build the packages that go into it, and we already assemble a license manifest for the image to cover those. Does that match your interpretation?
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 4 lines · Paul Eggleton
Sorry to dredge this up, but when do you see the need to specify a different
image LICENSE?
Quoted 10 lines
Logically, an image recipe's LICENSE can only refer to the recipe itself and
whatever files might be pulled in by it directly (usually none, but some people re-enabledo_fetchanddo_unpackto allow this), since otherwise the contents of the image are covered by the licenses of all of the recipes that
build the packages that go into it, and we already assemble a license manifest
for the image to cover those. Does that match your interpretation?
In the general case this is true but I guess rootfs postinstall hooks can create file which are not covered by the package licenses.
Ross