This field is the full path to the license files (both generic and literal) for a certain package in the /build/tmp/licenses/ directory. For example, for the busybox-hwclock package: home/user/poky/build/tmp/deploy/licenses/busybox/generic_bzip2.txt home/user/build/tmp/deploy/licenses/busybox/generic_GPLv2.txt home/user/build/tmp/deploy/licenses/busybox/LICENSE.txt
Paul, any idea on how to collect this info ? Couldn't find anything relevant :(
We will need to support multiple licenses and license file paths and associations between the license file paths and licenses and know whether the license is 'generic' or 'package specific'. This suggests that just adding a package.license_path field will not solve the problem, unless we encode information in the package license and license_files, which is not a very 'normalized' approach. Adding another table license-for-package {id, type (generic or specific), license_path, package_id} would solve the many-to-one license-files-to-package problem issue and provide the necessary typing of the license required by the 1.5.1 spec.
We had a brief discussion about this, and we seem to have hit a problem with providing information about license files for packages. Although the license manifest for an image recipe is organised by package, the /build/tmp/deploy/licenses/ directory seems to group license files per recipe. We thought about providing the path to the directory where the license files are stored for a package (e.g. for busybox-hwclock /build/tmp/licenses/busybox/), but although this might be useful when Toaster is running locally, it will be pretty useless if Toaster is running remotely, which is our main use case. It was also observed that there is probably a whole design piece around licensing we should do. So the conclusion was that providing the license under which a package is distributed is the minimum requirement. We already collect that information, so we will defer providing access to package license files.