Your product contains hundreds of components you did not write and cannot currently list.
Open source licences carry obligations, and meeting them requires knowing what is in the software. A bill of materials documents composition and licensing, and ISO/IEC 5230 sets out what a compliance programme needs around it.
- ISO/IEC 5230The open source compliance programme standard
- ISO/IEC 5962The SPDX specification as an ISO standard
- IdentifiersA curated list for licences and exceptions
- Past and futureProducts the programme has to cover
Open source compliance becomes urgent at three moments, and all of them have deadlines.
Very few organisations start this work because somebody read a licence. It starts because a transaction, a customer or a notice forces it.
- A customer asks for a software bill of materials as a condition of the contract. Enterprise and public sector buyers increasingly require one in a standard format, and producing it retrospectively for a product built over years is considerably harder than producing it continuously.
- Due diligence during a funding round or an acquisition. Buyers examine what the product is built from and whether the obligations attached to those components have been met, because unmet obligations transfer with the code.
- A notice from a rights holder or a community project. These are rare and they are extremely disruptive, because the response requires knowing exactly which version of which component was distributed in which release, which is precisely what a bill of materials records.
- In all three cases the organisation needs the same thing: an accurate picture of composition and licensing per release. Building that under time pressure, across a codebase nobody has inventoried, is the expensive version of this work.
Eight things an assessment establishes.
A bill of materials is the foundation
The SPDX specification is an open standard designed to facilitate communication of bill of materials information across software, artificial intelligence, datasets and system components. Without one, every licence question becomes an investigation.
There is a standard for the programme itself
ISO/IEC 5230 sets out the key requirements of a quality open source licence compliance programme, and helps organisations manage open source licensing requirements for past, current and future products or services.
It identifies where processes belong
The standard identifies the key places to have licence compliance processes, how to assign roles and responsibilities, and how to ensure sustainability of the processes. Those three questions are usually unanswered rather than answered badly.
SPDX is itself an ISO standard
SPDX 2.2.1 became ISO/IEC 5962:2021. That matters commercially, because a customer asking for a bill of materials in a standard format is asking for something with an international standard behind it rather than a vendor specific export.
Licensing information is structured
A bill of materials includes comprehensive licensing information, including a curated list of licence identifiers and exceptions. Structured identifiers are what make automated checking possible, rather than parsing free text licence names.
It carries provenance and integrity
Alongside composition it covers creator, supplier and distributor identity, provenance, integrity checksums and cryptographic hashes. That makes the same document useful for supply chain security as well as for licence compliance.
Composition goes to file and snippet level
Software composition is covered across packages, files and snippets, which matters because a licence obligation can attach to code copied into your own files rather than only to a dependency your package manager resolved.
Adoption is self certified or partnered
The compliance standard is described as lightweight and easy to read, with adoption available through self-certification or through collaboration with a partner. That makes it approachable for organisations that have never had a programme.
The content areas, and why each one matters commercially.
| Content area | Why it matters | |
|---|---|---|
| Software composition across packages, files and snippets | Obligations can attach below package level | |
| Build information and configurations | Reproducing what was actually shipped | |
| Creator, supplier and distributor identity | Who you would contact about a component | |
| Provenance | Where the component actually came from | |
| Integrity checksums and cryptographic hashes | Proving the component is the one you assessed | |
| Licence identifiers and exceptions | Structured, so obligations can be checked automatically | |
| Security vulnerability and quality data | The same document serves security questions | |
| Component relationships | Transitive dependencies, not just direct ones | |
| Lifecycle information | What is current, deprecated or abandoned | |
| AI models and datasets | Covered by the specification alongside software |
Four things that make open source compliance sustainable.
We generate the bill of materials in the build
A document produced by hand describes the software on the day somebody ran the tool. Generating it as part of the build means every release has one, which is exactly what a customer or an acquirer asks for and what a retrospective effort cannot provide.
We separate the technical from the legal
Identifying components and licences is technical work we do. Interpreting what a licence requires in your distribution model is legal work, and we scope the engagement so that split is explicit rather than blurred into a single opinion.
We place process where components enter
The compliance standard identifies the key places to have licence compliance processes. Putting checks at dependency addition and at release is what keeps the picture accurate, rather than a periodic review that is always looking backwards.
We assign the role explicitly
Compliance sits between engineering, legal and procurement, which usually means it sits with nobody. The standard addresses assigning roles and responsibilities directly, and naming an owner is frequently the change that makes everything else stick.
Three phases across roughly six to ten weeks.
- 01Weeks 1 to 4
Establish composition
What the products are actually built from, including transitive dependencies, vendored code and anything copied into your own files. Composition is covered across packages, files and snippets, and the last of those is where surprises live.
- Component inventory per product and release
- Transitive dependencies resolved and recorded
- Vendored and copied code identified
- Licence identifiers assigned per component
- 02Weeks 5 to 7
Assess obligations and gaps
What each licence requires in the way your product is distributed, and where those requirements are currently unmet. This phase is where legal input matters, since licence interpretation is a legal question rather than a technical one.
- Obligations mapped per licence and distribution mode
- Unmet obligations identified and prioritised
- Attribution and notice requirements assembled
- Components flagged for legal review
- 03Weeks 8 to 10
Build the programme
Processes at the points where components enter the product, roles and responsibilities assigned across engineering, legal and procurement, and sustainability so the picture stays accurate as the product changes.
- Compliance processes placed at entry points
- Roles and responsibilities assigned and documented
- Bill of materials generation automated in the build
- Customer facing document format agreed
Six situations that make compliance urgent.
A UAE software vendor asked for an SBOM
Enterprise and government buyers increasingly require a software bill of materials in a standard format. Producing one from a specification with an ISO standard behind it is a stronger answer than a spreadsheet assembled for the occasion.
A company going through investment due diligence
Buyers and investors examine what a product is built from and whether the obligations attached have been met, because those obligations travel with the code. Composition that cannot be evidenced becomes a diligence finding and a price adjustment.
A manufacturer shipping software in a device
Embedded distribution frequently triggers obligations that hosted delivery does not, and firmware images accumulate components from several suppliers. Composition at package, file and snippet level is what makes those obligations knowable.
An organisation that received a compliance notice
Responding requires knowing precisely which component version was in which distributed release. Organisations with per release bills of materials answer in hours. Those without spend weeks reconstructing history from source control.
A team that also needs vulnerability visibility
The same document carries security vulnerability and quality data alongside licensing, so a single accurate inventory serves both the compliance question and the question about which components carry known vulnerabilities.
A group standardising across several product teams
Different teams using different tools produce incomparable answers. Standard identifiers and a common format give a group level view, which is what makes portfolio wide policy decisions possible rather than aspirational.
How UAE software businesses stand on open source compliance.
| Feature | Programme with automated bill of materials | Scanner run when asked | No visibility |
|---|---|---|---|
Composition known per release | Yes | Current build only | No |
Transitive dependencies included | Yes | Usually | No |
Vendored and copied code covered | Yes | Rarely | No |
Licence identifiers structured | Yes | Free text | None |
Obligations assessed | Per distribution mode | Superficially | No |
Attribution assembled automatically | Yes | Manually | Missing |
Producible for a customer on request | Same day | Days to weeks | No |
Survives due diligence | Yes | With effort | A finding |
Ownership assigned | Named roles | Ad hoc | None |
Effort to reach | Weeks, then automated | Per request | None |
A bill of materials generated once is an artefact. A programme is what keeps it true.
The compliance standard is about the programme precisely because the document goes stale the moment a dependency updates.
- The standard identifies the key places to have licence compliance processes. In practice that means the points where components enter the product: dependency addition, build, release and acquisition of third party code, rather than an annual review.
- It addresses how to assign roles and responsibilities. Open source compliance regularly sits between engineering, legal and procurement, which in most organisations means it sits with nobody and surfaces only when somebody outside asks.
- And it addresses how to ensure sustainability of the processes. A compliance effort that depends on one enthusiastic engineer produces an accurate picture for about six months and an inaccurate one indefinitely afterwards.
- The standard is described as lightweight and easy to read, which is unusual for this kind of document and makes it a realistic target for a mid sized UAE software business rather than only for large enterprises with dedicated compliance teams.
Five steps, from inventory to a programme that maintains itself.
- 1
Inventory what the products are built from
Direct and transitive dependencies, vendored code, and anything copied into your own source. The specification covers composition at package, file and snippet level, and the last two are where a dependency scanner alone gives an incomplete answer.
- 2
Assign structured licence identifiers
Using the curated list of identifiers and exceptions rather than free text licence names. Structure is what allows automated checking, portfolio comparison and machine readable delivery to a customer who asked for exactly that.
- 3
Assess obligations against your distribution model
What the licences require given how the software actually reaches users, whether hosted, distributed, embedded or delivered as a container image. This is where legal review is scoped, since interpretation is a legal question.
- 4
Close the gaps
Attribution and notices assembled and included where required, components flagged for replacement where the obligations do not suit the product, and a policy recorded on which licences are acceptable in which contexts.
- 5
Embed the programme
Processes at the points where components enter, roles assigned across engineering, legal and procurement, bill of materials generation automated in the build, and sustainability designed in so the picture stays accurate without depending on one person.
What organisations ask about open source compliance.
Fifteen questions about what your software is made of.
Composition
- Can we list every component in a release?Including transitive ones.
- Do we know the licence of each?By identifier, not by name.
- Is any code vendored or copied in?Snippet level obligations.
- Do we track components per release?Not just current main.
- Are AI models and datasets included?The specification covers them.
Obligations
- Do we distribute or only host?It changes the obligations.
- Are attributions included in the product?A common requirement.
- Do we provide required notices?Per licence terms.
- Has legal reviewed the licence set?Interpretation is legal.
- Do we know which licences we avoid?A policy decision.
Programme
- Where do components enter the product?Put process there.
- Who owns compliance?Engineering, legal or both.
- Is the bill of materials automated?Manual ones go stale.
- Can we produce one for a customer today?Increasingly requested.
- What happens when a licence changes?Projects do relicense.
Ask your team for a complete component list, with licences, for the version a customer installed last year.
Not the current build. A specific shipped release. The difficulty of that request is the clearest measure of where your compliance programme actually stands.
Related Services
Explore more solutions that work great with this service
Secure SDLC assessment
Assess the process that produces the vulnerabilities.
Software Asset Management Audit
What is installed against what you own
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
Microsoft Licence Audit
Assigned, used and entitled, compared properly
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
IT Risk Assessment
A short register with an owner against every risk
Gap Assessment
Distance to a target you actually have to meet
VAPT Testing
CREST-certified vulnerability assessment and penetration testing