Publish the list of strategic third-party components of our solution with their governance jurisdiction#
What this is, concretely#
This commitment consists of publishing on your website, in a format accessible to clients and prospects, the named list of strategic third-party components of your solution — that is, the components whose failure, licence flip, or withdrawal would block your product or impose a major adaptation effort. For each component, you indicate its name, its publisher or the foundation that governs it, its governance jurisdiction, its model (single-vendor open source, neutral multi-vendor foundation, closed proprietary), and ideally the licence version in force as well as recent history.
The format may take several shapes: a simple web page, a structured table, a document included in a wider Sovereignty Profile (in particular domain 1), a SBOM (Software Bill of Materials) document in CycloneDX or SPDX format. The expected precision is sufficient for a buyer to assess their own exposure via your solution.
The commitment does not require exhaustiveness — it targets strategic components, not every transitive library. A list of 10 to 30 components is typical for a SaaS product of medium complexity.
Why this commitment matters#
This commitment is the direct embodiment of thesis 6 of the manifesto: “the technological sovereignty of a piece of software is measured against its entire chain.” Without visibility on the components, your clients cannot assess their own exposure. And the chain propagates: if your solution depends on Redis, and your client uses your solution, your client too depends on Redis — even if not directly aware. Transparency on components allows your clients to integrate your solution into their own sovereignty mapping.
The commitment naturally reinforces pub-001-publish-sovereignty-profile (domain 1 of the Profile carries precisely this information) and pub-004-qualify-commercial-discourse (honest qualification of components presupposes that they are named). Together, these three commitments form a coherent core of transparency.
It also anticipates regulatory requirements under way in the European Union. The Cyber Resilience Act and the NIS 2 directive impose visibility on the software supply chain in a cybersecurity logic. Publishing the list of strategic components ahead of time prepares your compliance while extending the practice beyond compliance.
A concrete example#
A French SaaS publisher of 28 people, offering a ticket-management platform for industrial-maintenance services, takes this commitment in June 2026 with a 9-month horizon. The technical team inventories the strategic components starting from the execution chain: database (PostgreSQL 16, distributed foundation), cache (Valkey 7.2.4, Linux Foundation), message queue (RabbitMQ, Broadcom since 2024), search (PostgreSQL full-text in front line, OpenSearch as an option for high-volume clients), orchestration (Kubernetes via OVHcloud Managed Kubernetes), authentication (Keycloak, Red Hat / IBM), monitoring (Grafana under AGPL since April 2024, Grafana Labs Inc.), CI/CD (self-hosted GitLab CE), container registry (self-hosted Harbor mirroring Docker Hub).
The inventory produces a list of 24 strategic components, published on a dedicated page of the website with a structured table. For each component, jurisdiction and model are indicated, along with a short pedagogical commentary on recent licence developments where relevant (e.g. mention of the Broadcom acquisition of RabbitMQ). The page is also available in JSON format for automated integration. The sales team integrates the reference to this page in commercial proposals and in responses to procurement-listing questionnaires.
Anti-pattern to avoid#
A list without jurisdiction qualification (just component names) misses half the commitment. An exhaustive list of every transitive library in an unreadable technical format drowns the useful information. An internal list classified “confidential” does not fulfil the publication commitment. The value lies in concision (10 to 30 strategic components), in qualification (jurisdiction and model), and in accessibility (a readable web page).
Success indicators#
By the 9-month horizon, you can reasonably consider this commitment fulfilled if a public page on your website lists the strategic components with their jurisdiction and governance model, if the list is updated annually or whenever a substantial change occurs, and if reference to the list is integrated into your Sovereignty Profile and commercial materials. A machine-readable format (JSON, CycloneDX) alongside the web page increases its usefulness.
→ Documented in the dossier#
JSON schema category: publication. Default horizon: 9 months. Applicable to: businesses.