Digital public goods vs digital public infrastructure: what the DPG label guarantees, and what it does not

Analysis · Published 2026-10-26

A small white lighthouse lit at dusk on a rocky headland, above a misty sea and dark rocks under a cloudy sky — Photo: Luke Porter, CC0, via Wikimedia Commons.

"Digital public goods" and "digital public infrastructure" are often used as if they meant the same thing, sometimes in the same sentence. They do not. One describes a product that anyone may reuse; the other describes a working system that a country runs for its population. Confusing them leads governments to expect from a registry listing what only governance, funding and operations can deliver.

Two terms, two origins

The term digital public good (DPG) was given its now-standard definition by the UN Secretary-General's Roadmap for Digital Cooperation, published in June 2020. It calls for investment in "open source software, open data, open AI models, open standards and open content that adhere to privacy and other applicable laws and best practices, do no harm, and help attain the SDGs". The definition is about what an asset is: open, reusable, lawful and relevant to the Sustainable Development Goals.

Digital public infrastructure (DPI) came to prominence through India's G20 presidency. The New Delhi Leaders' Declaration of September 2023 describes DPI as an evolving concept and "a set of shared digital systems" built and leveraged by both the public and private sectors, and it welcomed a voluntary G20 Framework for Systems of DPI. That definition is about what a system does: identity, payments and data exchange that operate at the scale of a society, with rules that let many parties build on them. We look at how such systems are judged in what makes DPI good, not just big.

Put simply: a DPG is something you can download and reuse. DPI is something that has to be run, every day, by someone accountable for it.

How the DPG label works

The Digital Public Goods Alliance, launched in 2019 as a multi-stakeholder initiative, maintains the DPG Standard and a public registry of products that meet it. The standard itself is open, published under a Creative Commons Attribution-ShareAlike 4.0 licence, maintained by the Alliance's secretariat, with changes proposed publicly through GitHub. It has nine indicators:

Relevance to the Sustainable Development Goals.
Use of an approved open licence.
Clear ownership of the asset.
Platform independence: no mandatory dependency on a closed component.
Documentation sufficient for others to use it.
A mechanism for extracting data and content in non-proprietary formats.
Compliance with privacy and other applicable laws.
Adherence to standards and best practices.
Do no harm by design, split into three parts: data privacy and security, handling of inappropriate and illegal content, and protection from harassment.

The registry covers four kinds of asset: software, open data, open content and AI systems. According to the Alliance's 2025 ecosystem report, more than 220 digital public goods had been verified by 2025 and the Alliance had reached 50 members; the registry listed 256 entries when we consulted it on 26 October 2026. Status is not permanent. The health information platform DHIS2, developed at the University of Oslo, for instance, is listed as a DPG since 30 November 2020 under the BSD-3-Clause licence, with its most recent completed evaluation dated 22 January 2025 and a renewal application filed in January 2026 (DPG Registry entry, consulted October 2026).

Several components discussed on this site carry the label, including Estonia's X-Road and the identity platform MOSIP, whose code is published under the Mozilla Public License 2.0.

What a DPG listing tells a government

A listing is useful evidence on a narrow set of questions, and those questions matter:

The licence is genuinely open. The state can use, study, modify and redistribute the software without negotiating with an owner, which removes one classic source of lock-in.
Ownership is clear. Someone identifiable holds the rights and has made them available under that licence, so there is less risk of a later claim.
There is no hidden closed dependency. The platform independence indicator means the product should not quietly require a proprietary database or service to function.
Data can leave. The data extraction indicator matters for exit: a government can move its records to another system.
Basic harm questions have been asked. Applicants must show how privacy, illegal content and harassment risks are addressed in the product.

What it does not tell you

The standard assesses a product. It cannot assess a deployment that has not happened yet, and most of what makes infrastructure succeed or fail happens in deployment.

Security of your installation

An open codebase can be reviewed by anyone, but that does not mean it has been reviewed by someone competent, or that a given installation is configured, patched and monitored. Security depends on the operator: hosting, key management, access control, incident response and independent audits. None of that is in the registry.

Performance at national scale

A product that works for a district health system or a pilot may not handle tens of millions of users or peak loads. Scale has to be tested in the target environment, with load tests and reference deployments that can be visited and questioned.

Sustainability of the project

Open licences protect the right to keep using code; they do not pay for its maintenance. Who funds the core developers, how security fixes are issued, and what happens if the main sponsor withdraws are questions for due diligence, not for the label. We discuss these trade-offs in open source or proprietary?

Governance and safeguards

The "do no harm" indicators look at how the product is designed and documented. They cannot decide how a government will use it: which agencies may access data, whether there is independent oversight, how people complain, whether enrolment is made compulsory for essential services. Those choices are made in law and institutions, which is why the UN's Universal DPI Safeguards work focuses on governance rather than on code, as covered in who governs digital public infrastructure.

Lock-in through people and contracts

Open-source software can still be locked in by the system integrator who installed and customised it, if only that firm understands the configuration, or if the contract leaves the state without documentation, administrator access or the right to bring in another supplier. The licence is necessary for exit, not sufficient.

The reverse is also true: DPI without DPGs

Being a DPG is not a condition of being DPI. Many systems described as digital public infrastructure run largely on code that is not public. India's Unified Payments Interface, for example, is built on interface specifications that banks and payment apps implement, while the central switch operated by the National Payments Corporation of India is not open-source software. What makes such systems public infrastructure is their mandate, their open rules of access and their interoperable interfaces, not the licence of every component. Conversely, a country can deploy a fully listed DPG and still end up with a closed, poorly governed system.

Practical questions before choosing a DPG

Which indicators of the standard matter most for this use, and what evidence did the listing rely on?
Where is the product already running at comparable scale, and can those operators be contacted?
Who maintains the core code, how is that funded, and how are security vulnerabilities reported and fixed?
What skills will the government need in-house to run, configure and audit it, and how will they be built?
Does the integration contract guarantee source code for customisations, documentation, administrator access and data export?
Which legal safeguards, oversight body and redress channels will apply to the deployed system, whatever the software?

Treat the DPG label as a well-made entry ticket: it rules out some risks early and makes others easier to manage. The infrastructure is what you build, govern and pay for after you pass through the gate.

Sources

United Nations, Roadmap for Digital Cooperation, Report of the Secretary-General (June 2020).
G20, New Delhi Leaders' Declaration (9-10 September 2023), section on digital public infrastructure.
Digital Public Goods Alliance, DPG Standard (CC BY-SA 4.0), and DPG Registry, consulted 26 October 2026.
Digital Public Goods Alliance, 2025 ecosystem report (summary on digitalpublicgoods.net).
DPG Registry, entry for DHIS2, consulted October 2026.