How it is created — LEG-LST-002 Software Licence Whitelist

1. Why this artifact exists

Licensing is not a security control, which is why it usually reaches the component decision late — after the component is designed into the hardware, when the honest answer costs a re-implementation and a slipped release.

A whitelist moves that answer to the front and makes it cheap. The developer filling in the component evaluation form gets one of three responses in five minutes: proceed, escalate, or pick something else. No legal review, no waiting, no judgement call made by someone who is guessing.

There is one place where licensing and security genuinely collide, and it is worth building the list around: statically linked firmware. Licences whose obligations assume the user can relink — the LGPL family — cannot be honoured by a signed, anti-rollback-protected image without handing users the means to build and install their own. That is not a footnote; it is a direct conflict with the update-integrity control, and it is the reason a generic corporate licence policy does not transfer to embedded products.

2. Inputs

• How you actually ship: statically linked firmware, a Linux-based gateway, companion tools. Each has different obligations, and a single list that ignores the difference will be wrong for at least one of them.
• Your component policy, since the licence check is one of its knock-out criteria.
• Counsel's view on the licences you already ship — start from your existing SBOM rather than from a list of licences in the abstract.
• Your update and secure-boot design, because that is what the copyleft conflict is with.

3. Steps

1. Use exactly three categories. Approved, conditional, prohibited. More categories means a developer has to interpret, and interpretation is what the list exists to remove.
2. Populate "approved" with the permissive set and state the one obligation that still applies: notices and licence texts delivered with the product. Approved means "no approval needed", not "no obligations".
3. Put the copyleft conflict in writing, with the reason. LGPL only where dynamically linked; default answer for firmware is no. A prohibition with a stated rationale survives the argument with the developer who found a perfect library; a bare "not allowed" does not.
4. Add "no licence stated" to the prohibited list explicitly. The default is all rights reserved. This is the entry that catches the single-file utility copied from a public repository, which is how most licence problems actually enter a codebase.
5. Write the narrow exceptions narrowly. Unmodified GPL components in a Linux distribution on the gateway, with the written offer for source honoured — and say plainly that the exception does not extend to the firmware image. An exception without a stated edge becomes a precedent.
6. Define the escalation for unlisted licences, and forbid reasoning by resemblance. "It looks like MIT" is how a field-of-use restriction gets shipped.
7. Tie the check to the pinned version, and repeat it at every upgrade. Upstreams re-license. A component approved at v2 can be BUSL at v3, and the version bump is the only moment you will notice.
8. List the obligations you must actively discharge, with how each is met: notices file generated from the SBOM, written offer published and honoured for the support period, modified files published where required. An obligation with no mechanism is one you are already failing.
9. Set the retention to outlive the product. Notices and offers must survive as long as units are supported, plus the statutory tail.

4. Done when

• Three categories, each giving an unambiguous next action.
• The static-linking conflict is stated with its rationale, not just its conclusion.
• "No licence stated" is explicitly prohibited.
• Exceptions name their boundary.
• Unlisted licences escalate rather than being matched to a similar-looking entry.
• The check repeats at every version bump.
• Every obligation has a named mechanism and a retention period.

5. Common mistakes

A licence policy written for server software applied unchanged to statically linked firmware. Treating "open source" as a category. Approving a licence rather than a licence-at-a-version, so a re-license slips in at upgrade. Leaving unlicensed code to a developer's judgement. Writing exceptions without edges. And generating a notices file nobody checks against what actually shipped — the obligation is discharged by delivery, not by generation.

6. In TRA Studio

The SBOM carries a licence field, and it is one of the few fields that is easy to populate and easy to leave unverified. Treat licence approval as part of component due diligence rather than a separate legal track: the same components, the same registry, the same point in the process. A component whose licence nobody checked is a supply-chain item with an unowned obligation attached, and it will be discovered by someone outside the company.