If a layer adds new licenses by appending to LICENSE_PATH, it will cause any recipe that inherits "license.bbclass" to fail because that class expands the AVAILABLE_LICENSE variable by scanning all paths listed in LICENSE_PATH. This results in a signature mismatch for the recipe. As an example when running yocto-check-layers on one of our internal layers which adds a custom license file, we got the following error: 71 signatures changed, initial differences (first hash before, second after): libdevmapper:do_configure: 82c851ad59f13117fc0f9cf68732d3e4b187f150baa08af99c4d6ebad5d56b8a -> cd43c102864ed6ee6a8727d002e59a68b8898cdabff801dfffcbf1f237c9fddf bitbake-diffsigs --task libdevmapper do_configure --signature 82c851ad59f13117fc0f9cf68732d3e4b187f150baa08af99c4d6ebad5d56b8a cd43c102864ed6ee6a8727d002e59a68b8898cdabff801dfffcbf1f237c9fddf NOTE: Starting bitbake server... basehash changed from c09082cab215faf830a4bd4cc68275b97fd408eda66668723874095268701964 to 2542be418520358049adb0a46e46166f7d614fd2756175b0544b1fa4b964717b Variable AVAILABLE_LICENSES value changed: "... {+Module-License-Fraunhofer+} ..." There appear to be two recipes that currently inherit license.bbclass: libdevmapper and lvm2 (both of which get it from lvm2.inc)
Moved en masse from 4.2 to 4.3 by Randy.
We dropped AVAILABLE_LICENSES in 2022 (commit bf08d9ccb9cbc749a571af3d33140bcae0e252a6), and LICENSE_PATH is included in BB_HASHEXCLUDE_COMMON. So this should no longer be an issue. I tested with meta-raspberrypi which includes a custom license directory added to LICENSE_PATH in layer.conf, this currently passes yocto-check-layer (without the --machines argument). So, I think we can close this issue.