Identify the release the inventory actually describes
Consider an illustrative arrangement, not a reported project: a Shenzhen partner develops firmware, a Hong Kong team works with an overseas brand, and another supplier develops the app. A working device does not establish that the parties understand each other's software composition. A prototype inventory may not describe the production firmware being delivered.
Start with the handover boundary. Identify who provides device firmware, mobile applications, supporting tools and cloud services, and which are included. Associate the inventory with a specific product version and build identifier instead of repeatedly overwriting a file called final. This is an engineering method, not a prescribed official format.
An SBOM exchanges facts; it does not decide the law
SPDX provides a framework for communicating supply-chain metadata. Its principles emphasise collecting and communicating facts, without making legal interpretations of licences or compliance. An inventory can help partners explain what is included; it cannot independently establish that the proposed use and distribution meet every condition. SPDX overview
Composition scanning can be a starting point, but check coverage. Was the source repository scanned, or the delivered package? Is there information for supplier-provided binary components? Who resolves uncertain identifications? A tool's silence is not evidence that an issue cannot exist.
An SBOM is also different from a hardware BOM. A purchasing list of batteries, chips and mechanical parts does not replace firmware composition information. Conversely, software metadata does not establish electrical safety, radio approval or other market-access requirements for the finished device.
Consistent identifiers help partners find the actual licence
The SPDX License List supplies standard short identifiers, full names, licence texts and permanent links. It supports identification, not unconditional permission to distribute anything appearing in the list or certification of a product using those identifiers. SPDX License List
Ask the software owner to explain identification and retain the relevant original files and source locations. Do not replace missing or ambiguous information with a familiar-looking licence name. Scope, modifications, distribution and any applicable notices or source-related obligations need review against the actual circumstances. This article gives no legal conclusion about a particular component combination.
Connect the inventory to delivery responsibilities
| Handover item | What to reconcile | Responsibility to establish |
|---|---|---|
| Component inventory | Product version and actual delivery scope | Who creates and confirms it, and what it covers |
| Origins and licensing | Versions, source locations and licence texts | Who resolves unknown or conflicting information |
| Recipient materials | Reviewed notices, documents or other applicable materials | Who prepares, delivers and records them |
| Later changes | Firmware releases and component substitutions | Who rechecks and updates the materials |
| Unresolved issues | Specific gap, owner and next decision | Who pauses the relevant handover or seeks advice |
This is an editorial coordination table, not a legal clearance form or a requirement to publish all proprietary source code. An NDA, a software licence and a customer contract address different matters; none automatically substitutes for the others.
Governance is an ongoing process, not a product certificate
OpenChain's public explanation of ISO/IEC 5230 concerns organisational processes, roles and sustainable management of open-source licensing requirements. It does not certify the device or supplier in this illustrative discussion. OpenChain licence-compliance explanation
For a small team, identify a responsible person and a route between engineering, procurement, customer delivery and legal review. A supplier saying it handles software should translate into identifiable materials and a response process. A brand requesting an SBOM should specify the relevant release and coverage.
After firmware updates or substitutions, do not ship new software while continuing to supply an old inventory. Keeping the release differences makes affected handover materials easier to reassess. This shares the version discipline of component-substitution change control, but addresses software composition and licensing information.
Coordinate Hong Kong and Shenzhen around one handover
Shenzhen engineering can explain actual builds and component origins. Hong Kong commercial counterparts can clarify the overseas recipient's information needs. Sales colleagues need not decide every issue, but there should be a traceable route to an answer. Record unresolved matters rather than promise zero risk.
Licence review is separate from EU CRA security-reporting responsibilities. An inventory can provide supporting information without completing vulnerability assessment, reporting or remediation. Nor does its presence settle rights involving AI models, training data or cloud services in the same product.
Jimhang Capital can discuss non-confidential product information, engineering roles and overseas partner requirements as part of Greater Bay Area resource coordination. It does not replace legal licence review or a certification body. Initial discussions need no proprietary code, credentials or customer data.
Contact Justin Zhan · About Jimhang Capital · Justin Zhan profile
Sources reviewed on 22 October 2026. AI-assisted website editorial analysis, not a verbatim statement by Justin Zhan. This is not legal advice, product certification or a guarantee of licence compliance. Assess actual components, licences and delivery arrangements using the relevant evidence and professional advice.