Skip to contentSkip to conversation

image.bbclass: allow override of image LICENSE

PATCH In review Pascal Bach 3 participants 3 messages May 3, 2017 – Oct 11, 2017

lore
Share & tools
lore
#0 lore raw

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
index 405fd73..0fc8752 100644
@@ -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
#1 lore raw

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
#2 lore raw
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-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?

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