What this domain covers#
The first domain of the Sovereignty Profile asks the declarant to identify the third-party components — open source software, proprietary bricks, managed services, distributed solutions — on which the proposed solution depends in a non-substitutable way. Non-substitutable does not mean impossible to replace in absolute terms; it means that a replacement would require substantial effort and that the absence of the component would deprive the solution of a critical functionality.
For each component retained, the declarant indicates its name, its version, its license, the publisher or foundation that ensures its governance, the jurisdiction of that governance, and its essential or peripheral character within the solution. The aim is not exhaustiveness — a typical project has hundreds of transitive dependencies, and an exhaustive list of them brings nothing to a buyer. The aim is the list of strategically determining components, which typically counts in a few dozen.
Why this domain matters#
This domain is the starting point of any serious sovereignty analysis. Thesis 6 of the manifesto sets it out: “the technological sovereignty of a piece of software is measured on its entire chain: production, maintenance, distribution, governance, funding, skills. None of these links is sufficient; each can be enough to break it.” Without visibility on the components, the buyer cannot assess its own exposure through the solution. And dependency propagates: if the solution depends on Redis 7.4 under BSL/SSPL since March 2024, the client of the solution depends too on that situation, whether aware of it or not.
At an aggregate scale, the massive publication of strategic component lists by European providers feeds the manifesto’s observatory of gaps. Concentrations of dependency become visible: such-and-such single-vendor component used simultaneously by hundreds of organisations, such-and-such critical cryptographic brick whose maintenance rests on a single unpaid maintainer. This collective visibility orients public and private investment toward the most structurally significant risk zones.
For the declarant itself, the exercise of filling in domain 1 is often a trigger for internal work. Many providers discover, while filling in this section, dependencies they had not made conscious, components they had not thought strategic but which prove so on examination, or recent license flips that their teams had not been alarmed by.
What is asked, by category of declarant#
For a software publisher. List of third-party software components (open source or proprietary) integrated in the solution or indispensable to its execution: databases, caches, message queues, cryptographic libraries, structuring frameworks, third-party services connected via API. Twenty to fifty entries is typical for a SaaS product of medium complexity.
For a hosting or cloud provider. List of the underlying technical bricks of the infrastructure: hypervisor (VMware, Proxmox VE, KVM), container orchestrator (Kubernetes, OpenShift), managed databases offered as a service, object storage services, node operating systems. The nature of the publisher or foundation that governs each brick is central — VMware under Broadcom, OpenShift under Red Hat / IBM, Kubernetes under CNCF do not have the same sovereignty profile.
For a distributor or integrator. List of distributed solutions whose original publisher is non-European, with the share of revenue associated and the nature of the distribution agreement (simple resale, white label, packaging with added value). This category is politically the most sensitive because it reveals the actual share of “sovereign” activity in the manifesto’s sense.
An example of an honest, well-done answer#
A European B2B SaaS publisher of 28 staff, offering a ticket management platform for industrial maintenance, identifies 24 strategic components in its domain 1. For each one, the list is precise. PostgreSQL 16 (PostgreSQL Global Development Group, distributed governance with a European leaning, neutral foundation, essential). Valkey 7.2.4 (Linux Foundation, United States, multi-vendor neutral foundation, essential — alternative adopted to Redis following the BSL/SSPL flip of March 2024). RabbitMQ (Broadcom Inc., United States, single-vendor, essential — under watch since the VMware-Broadcom acquisition of November 2023). PostgreSQL full-text search (with OpenSearch as an option for high-volume clients, OpenSearch Software Foundation / Linux Foundation since September 2024, essential in the high-volume scenario). Keycloak (Red Hat / IBM, United States, single-vendor open source, essential). Grafana 11 (Grafana Labs Inc., United States, single-vendor open source under AGPL since April 2024, peripheral).
The publisher also publishes, alongside its sovereignty.json, an SBOM file in CycloneDX format, which allows clients to integrate the list into their own analysis tools. The list is revised annually and on each major evolution of the technical stack.
An anti-pattern to avoid#
A domain 1 that boils down to “our solution relies on the open source standards of the industry” without naming components gives no useful information. Symmetrically, an exhaustive list of all transitive dependencies in an unreadable technical format drowns the strategic information. A list that omits problematic components (for example, that does not mention that the Redis used is in version 7.4+ under BSL/SSPL) undermines the credibility of the whole Profile.
Articulation with the other domains and commitments#
Domain 1 is the prerequisite for domain 2 (which asks, for each strategic component, for a workaround plan) and feeds into domain 7 (which assumes the identified blind spots). It is articulated directly with the commitment pub-006-publish-component-jurisdiction-list: a provider that has taken on this commitment already has a large part of the content of domain 1. It is also the mirror, on the provider side, of the user commitment user-001-audit-dependencies: what the provider declares in its domain 1 directly feeds the audit that its client conducts.
How to fill in the form#
The form first proposes a library of commonly used components (PostgreSQL, Kubernetes, Redis, etc.) that you can select with one click. For each component retained — from the library or freely added — here is how to fill in the fields.
Identification of the component#
- Name and version: name precisely, including the version when it conditions the rights or the governance (e.g.: Redis 7.4 — flip under BSL/SSPL — vs Redis 6.2 — still BSD).
- Category: a short label that helps to understand the role (hypervisor, ORM, database, JS runtime, search engine, etc.).
- Publisher or foundation: the entity that effectively controls the roadmap (e.g.: PostgreSQL Global Development Group, Linux Foundation, MongoDB Inc., Oracle Corporation).
- Jurisdiction of governance: country under whose law this entity operates. Plain ISO code (FR, US, DE, NL…).
Criticality and sources#
- Criticality: three levels. Essential = without this component, activity stops within 24 hours. Important = major degradation but a workaround is possible. Secondary = replaceable without strong disruption. Be sober with “essential” — if everything is essential, nothing is.
- Public source (URL): a link that proves the declared jurisdiction or control (project “About” page, Wikipedia article, legal filing, official document). Useful so that your readers can verify.
Governance model#
Two distinct fields, because the divergence between the two is itself information.
- Formal: what the official documentation announces (“501(c)(3) foundation with elected board”, “single-vendor”, “consortium of publishers”).
- Effective practice: what you observe on the ground (“80% of commits come from a single publisher”, “board chaired in fact by X”, “technical decisions taken outside the official governance”). A short but honest mention.
Free comment#
Anything that does not fit in the boxes but that the reader needs to know: a license change under way, a stable fork maintained in parallel, a critical non-substitutable dependency identified as a blind spot, etc.