Sovereignty score methodology
The Sovereign Web Stack score is a 100-point editorial model for comparing how much practical control an open-source project leaves with its operator.
What the score measures
A high score means an organization can plausibly inspect, run, adapt, back up, export, replace, and govern the tool without depending on a vendor-controlled data plane. It does not mean the project is perfect, legally certified, or the right choice for every deployment.
The model is intentionally stricter than "is there a GitHub repository?" Open source is necessary for this index, but it is not sufficient. A project can be open and still hard to operate, difficult to leave, overly dependent on a proprietary service, or unclear about telemetry.
The 100-point model
| Criterion | Points | Question | Public test |
|---|---|---|---|
| Open rights and license | 15 | Can users legally inspect, run, modify, fork, and redistribute the software under a recognized open-source license? | Repository license, contributor terms, trademark limits, and whether important features are outside the open distribution. |
| Self-hostability and runtime independence | 18 | Can an ordinary operator run the project without mandatory proprietary services or a vendor-controlled control plane? | Install path, minimum dependencies, offline behavior, documented backups, upgrade path, and whether managed cloud is optional. |
| Data control and portability | 16 | Can users decide where data lives, export it, back it up, and migrate away without vendor permission? | Open export formats, database access, documented retention, backup/restore process, importers, and API coverage. |
| Privacy by default and telemetry control | 12 | Does the project minimize data collection and make telemetry, cookies, tracking, and external calls explicit and controllable? | Default telemetry posture, cookie behavior, analytics/proxy calls, DNT/GPC behavior, admin controls, and privacy docs. |
| Interoperability and open standards | 8 | Does the project work with open protocols, standard formats, and portable integrations rather than closed connectors? | Standards support, API design, import/export formats, identity integrations, webhooks, and protocol compatibility. |
| Operational resilience and maintainability | 14 | Can a small team operate the project safely for years? | Release cadence, security policy, update path, documented scaling limits, backup/restore, monitoring, and dependency footprint. |
| EU hosting and procurement fit | 12 | Does the project help European organizations meet residency, procurement, accessibility, and governance expectations? | Region choice, European hosting options, GDPR documentation, accessibility posture, public-sector references, and vendor transparency. |
| Governance and supply-chain clarity | 5 | Is it clear who controls the project, how decisions are made, and how users can assess supply-chain risk? | Foundation/company governance, contributor model, security disclosures, signed releases, SBOMs, and dependency transparency. |
Review process
Each project is reviewed from public materials first: source repository, license file, installation docs, hosting docs, privacy/security docs, export/API docs, release history, and governance material. If a claim is not publicly verifiable, it gets less credit even when it is probably true.
- Confirm the project belongs in a web-stack category and has usable public source.
- Check the current license and whether core functionality is open, source-available, or commercial-only.
- Run the self-hosting and data-control review against published install, backup, export, and migration docs.
- Review telemetry, cookies, external services, privacy defaults, and optional tracking.
- Evaluate standards support, APIs, identity integrations, and documented import/export paths.
- Assess maintenance signals: release cadence, upgrade docs, security policy, and operational footprint.
- Record evidence and caveats so the score can be challenged later.
How to read scores
Scores above 85 are strong sovereignty candidates. Scores from 72 to 84 are good fits with known tradeoffs. Scores from 60 to 71 are mixed: they may be right for a specific workflow, but buyers should read the caveats. Scores below 60 need more evidence or have structural limits for sovereignty-sensitive use.
Category fit matters. A focused analytics tool and a broad product analytics platform should not be judged as if they had the same job. The score measures control posture, not feature breadth.
EU policy context
The model is informed by EU policy themes: technological sovereignty, open source, interoperability, digital rights, data portability, and cyber resilience. Those themes point toward practical controls: reusable public software, transparent code, switching rights, secure maintenance, and user control over digital services.
- The EU Open Source Strategy - Frames open source as a practical lever for technology sovereignty, reuse, transparency, security, and collaboration across public services.
- EU Open Source Strategy fact page - Summarizes the Commission strategy and its open-source actions, including knowledge sharing and a more open digital administration.
- Digital Decade policy programme 2030 - Sets Europe-level digital targets and governance context for infrastructure, skills, public services, and business digitalization.
- European Declaration on Digital Rights and Principles - Establishes user control, safety, privacy, freedom of choice, and human-centric digital transformation as public commitments.
- Data Act - Useful for the scoring lens on portability, switching, data access, and avoiding lock-in around connected data and cloud services.
- Cyber Resilience Act - Provides security and supply-chain context for software products, including the need to evaluate maintenance and vulnerability handling.
- Interoperable Europe Act - Connects sovereignty to interoperability, reusable public-sector solutions, and cross-border public-service delivery.
- European Interoperability Framework - Provides long-running interoperability principles that inform the index criteria for standards, portability, and organizational fit.
Limitations
This is a public research index, not a certification body. It cannot verify private contracts, undisclosed infrastructure, internal incident response, or all customer-specific deployment choices. Scores should be treated as a starting point for technical and procurement review.
The score can change when projects improve exports, publish better telemetry documentation, simplify self-hosting, change licenses, add EU hosting options, or clarify governance. The most useful outcome is not ranking a project permanently; it is making the improvement path visible.