What You Will Learn

Prerequisites

Why License Auditing Isn’t Optional

Open-source licenses range from permissive (MIT, BSD — almost no obligations) to copyleft (GPL, LGPL — obligations that can include providing source code to anyone who receives the binary). Shipping a GPL-licensed component inside a closed firmware image without honoring the license’s source-availability requirement is a real legal exposure, not a theoretical one. Because a Yocto image can easily pull in 200+ packages transitively through dependencies you never directly requested, manual tracking is not realistic — you need the build system to tell you.

Where Yocto Stores License Data

During every build, BitBake copies a license text for each package into a per-package directory under tmp/deploy/licenses/:

tmp/deploy/licenses/<package-name>/

In addition, once an image finishes building, a per-image summary directory is generated, named after the image, the machine, and a build timestamp:

$ ls tmp/deploy/licenses/ep-diag-image-beaglebone-20260815041500
license.manifest  package.manifest

Reading license.manifest

Each entry lists the package, version, and declared license expression. A trimmed example:

PACKAGE NAME: ep-diag-tool
PACKAGE VERSION: 1.2
RECIPE NAME: ep-diag-tool
LICENSE: MIT

PACKAGE NAME: busybox
PACKAGE VERSION: 1.36.1
RECIPE NAME: busybox
LICENSE: GPL-2.0-only

You can grep this file directly to surface every copyleft component in one command:

$ grep -B3 "GPL" tmp/deploy/licenses/ep-diag-image-beaglebone-20260815041500/license.manifest

Recipe LICENSE vs. What Actually Ships

It’s easy to confuse two different things that both use the word “license.” The LICENSE variable inside an image recipe (as seen in the previous lecture) describes the license of that recipe file itself — it has nothing to do with the packages the image installs. The real per-package licensing data always comes from license.manifest, generated from each individual recipe’s own LICENSE declaration and license-checksum verification during the build.

Automating a Simple Compliance Check

A minimal script to fail a CI build if a disallowed license shows up, kept deliberately simple so you can extend it:

#!/bin/sh
MANIFEST="$1"
DISALLOWED="GPL-3.0 AGPL"

for lic in $DISALLOWED; do
    if grep -q "LICENSE: .*$lic" "$MANIFEST"; then
        echo "BLOCKED: disallowed license $lic found in $MANIFEST"
        exit 1
    fi
done
echo "License check passed"

Expected output on a clean build:

$ ./check_licenses.sh tmp/deploy/licenses/ep-diag-image-beaglebone-20260815041500/license.manifest
License check passed

Real-World Use Case

Teams shipping consumer devices commonly wire a script like the one above into their CI pipeline as a required gate before a release build is allowed to be tagged. Legal or compliance teams are then handed the license.manifest for the exact shipped build, rather than being asked to trust a spreadsheet someone updated manually months earlier.

Common Mistakes and Troubleshooting

• Auditing the wrong manifest — always use the one matching your final shipped image name, machine, and build timestamp, not an old one left over from a previous build.
• Assuming LICENSE = “MIT” on your image recipe covers everything — it only covers the recipe file, not the 200+ packages installed inside it.
• Ignoring LICENSE_FLAGS — some recipes require an explicit opt-in (for licenses needing manual review) via LICENSE_FLAGS_ACCEPTED; without it the build refuses to include that package at all.

Best Practices

• Archive the license.manifest for every release build alongside the firmware image itself, not just the source code.
• Run a license-compliance check automatically as part of CI, not as a manual pre-release step someone might forget.
• Review new copyleft components at the point they’re added to an image recipe, not after the fact.

Security Considerations

License auditing during the build also functions as a lightweight supply-chain check: an unexpected new GPL or unusual license appearing in a diff of consecutive license.manifest files is often the first visible sign that a dependency pulled in an unexpected transitive package — worth investigating even outside of pure legal compliance.

Summary and Key Takeaways

license.manifest and package.manifest give you an authoritative, automatically generated record of exactly what licenses and packages shipped in a specific image build. Treat them as a release artifact, automate checking them in CI, and never confuse an image recipe’s own LICENSE variable with the licensing of the packages it installs.

Conclusion

License auditing closes the loop on the image-customization and SDK-building skills covered earlier in this free linux device drivers course series — you now know how to build exactly what you want, hand it to other developers, and prove exactly what’s inside it. That wraps up this chapter of EmbeddedPathashala’s free embedded systems course.

FAQ