Skip to content
UPSTREAM
GOVERNANCE

Open-source governance: rules, licences, ownership.

Last updated: · ALVPHA Tech GmbH

The building blocks

  • Policy: which licences and sources are allowed and who approves
  • Inventory: which components are in which products and releases, ideally as an SBOM
  • Licence obligations: fulfil notices, licence texts and source code offers depending on the licence
  • Security: monitor, assess and handle vulnerabilities
  • Ownership: named owners for components and escalations
  • Evidence: document review status and decisions for customers and auditors

Licences: permissive and copyleft

Permissive licences such as MIT, BSD or Apache-2.0 mainly require attribution and passing on the licence text. Copyleft licences such as the GPL require derivative works to be distributed under the same terms; weaker variants such as LGPL or MPL limit this depending on how code is combined. Standard SPDX licence identifiers make this information machine-readable and verifiable.

OSPO and OpenChain

Larger organisations bundle these tasks in an Open Source Program Office (OSPO). The OpenChain standards have become the established process standards: ISO/IEC 5230 for licence compliance programmes and ISO/IEC 18974 for security assurance programmes for open source. Both describe which processes should be in place, not which tools to use.

Link to the Cyber Resilience Act

The Cyber Resilience Act requires manufacturers to exercise due diligence when integrating third-party components, explicitly including free and open-source software (Article 13(5) of Regulation (EU) 2024/2847). Working open-source governance is the practical way to demonstrate that diligence.

Frequently asked questions

Do we need our own OSPO?

Not necessarily. What matters are clear rules, named owners and a maintained inventory; an OSPO is one organisational form for this.

What does an OpenChain self-certification mean?

An organisation declares that its programme meets the requirements of ISO/IEC 5230 or ISO/IEC 18974. It is not a third-party certification by an audit body.

SOURCES

This article provides technical orientation and is not legal advice. The linked primary sources in their current version are authoritative.

Where does your team stand?

The free Trust Check classifies your self-assessment across seven dimensions, from component inventory to evidence capability. For specific cases, we arrange an introductory call.

Start your free Trust Check Book an introductory call

Related service: Open-source governance and SBOM management

More articles

All articles →
SBOM

What is an SBOM and what must it contain?

An SBOM (Software Bill of Materials) is a machine-readable inventory of all components in a piece of software, with version, origin and dependencies. It is the basis for knowing quickly whether a product is affected when a new vulnerability appears. The Cyber Resilience Act requires manufacturers to maintain an SBOM covering at least the top-level dependencies.

Read article TRIAGE

Vulnerability triage: from CVE report to decision.

Triage means assessing a vulnerability finding in a structured way: is our product actually affected, how urgent is it, and what do we decide? Severity (CVSS) alone is not enough; likelihood of exploitation (EPSS), evidence of exploitation (KEV) and how the component is actually used in the product all matter. The outcome is documented traceably, for example as a VEX statement.

Read article CRA

Cyber Resilience Act: what manufacturers should know about open source.

The Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements made available in the EU. For manufacturers this means, among other things: document components (SBOM), handle vulnerabilities, provide security updates and report actively exploited vulnerabilities on time. The reporting duties have applied since 11 September 2026, the remaining requirements apply from 11 December 2027.

Read article CRA REPORTING

CRA reporting obligations since 11 September 2026: what manufacturers must report now.

Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents (Article 14 CRA). Reports go through ENISA's single reporting platform simultaneously to the CSIRT designated as coordinator and to ENISA: early warning within 24 hours, notification within 72 hours, then a final report. The obligation also covers products placed on the market before 11 December 2027.

Read article