The Digital Public Goods Standard is a set of specifications and guidelines designed to maximise consensus about whether a project conforms to the definition of digital public goods set by the UN Secretary-General in the 2020 Roadmap for Digital Cooperation.
The DPG Standard establishes a baseline that must be met in order to earn recognition as a digital public good by the Digital Public Goods Alliance and the broader community. The DPG Standard itself is an open project and therefore open to contribution. With that, the DPGA supports the 5 Core Principles of OpenStand in the development of the DPG Standard. We invite anyone who uses and benefits from the DPG Standard to join our growing list of endorsers.
Below are the 9 indicators and requirements that determine if nominated software, data, AI models, standards and/or content (described in the chart below as the “project”) can be considered a digital public good and therefore recognised as such on the DPG Registry.
|1. Relevance to Sustainable Development Goals||All projects must indicate the Sustainable Development Goals (SDGs) they are relevant to and provide supporting links/documentation to support their relevance.|
|2. Use of Approved Open Licenses||Projects must demonstrate the use of an approved open license. For open source software, only OSI approved licenses are accepted. For open content, the use of a Creative Commons license is required. While we encourage projects to use a license that allows for both derivatives and commercial reuse (CC-BY and CC-BY-SA) or dedicates content to the public domain (CC0); licenses that do not allow for commercial reuse (CC-BY-NC and CC-BY-NC-SA) are also accepted. For open data, an Open Data Commons approved license is required. See the full license list here for reference.|
|3. Clear Ownership||Ownership of everything the project produces must be clearly defined and documented. For example, through copyright, trademark, or other publicly available information.|
|4. Platform Independence||If the project has mandatory dependencies that create more restrictions than the original license, the project(s) must be able to demonstrate independence from the closed component(s) and/or indicate the existence of functional, open alternatives.|
|5. Documentation||The project must have documentation of the source code, use cases, and/or functional requirements. For content, this should include all relevant/compatible apps, software, or hardware required to access the content, and instructions regarding how to use it. For software projects, this should be technical documentation that would allow a technical person unfamiliar with the project to launch and run the software. For data projects, this should be documentation that describes all the fields in the set, and provides context on how data was collected, and how it should be interpreted.|
|6. Mechanism for Extracting Data||If the project has non personally identifiable information (PII) there must be a mechanism for extracting or importing non-PII data from the system in a non-proprietary format.|
|7. Adherence to Privacy and Applicable Laws||The project must state to the best of its knowledge that it complies with relevant privacy laws, and all applicable international and domestic laws.|
|8. Adherence to Standards & Best Practices||Projects must demonstrate adherence to standards, best practices, and/or principles. For example, the Principles for Digital Development.|
|9. Do No Harm||All projects must demonstrate that they have taken steps to ensure the project anticipates, prevents, and does no harm.|
|9.a) Data Privacy & Security||Projects collecting data must identify the types of data collected and stored. Projects must also demonstrate how they ensure the privacy and security of this data in addition to the steps taken to prevent adverse impacts resulting from its collection, storage, and distribution.|
|9.b) Inappropriate & Illegal Content||Projects that collect, store or distribute content must have policies identifying inappropriate and illegal content such as child sexual abuse materials in addition to mechanisms for detecting, moderating, and removing inappropriate/illegal content.|
|9.c) Protection from Harassment||If the project facilitates interactions with or between users or contributors there must be a mechanism for users and contributors to protect themselves against grief, abuse, and harassment. The project must have a mechanism to address the safety and security of underage users.|
Application of the DPG Standard
We encourage creators, maintainers, funders, implementers, and consumers to recognise and use the DPG standard to support digital public goods. Digital public goods that meet the described standards are found on the DPG Registry. To see how they meet the DPG Standard, you can click on the DPG icon in the DPG Registry.
You can view the full list of questions that are used to assess each of the indicators here.
We apply the DPG Standard to projects on the DPG Registry that have either been nominated directly or have been pulled together from databases maintained by our partners. Projects that are submitted to our platform will undergo three stages of review to ensure they meet the requirements set in the DPG Standard. As a project undergoes various reviews it will move from nominee to candidate, to a fully reviewed digital public good.
Movement through the process is transparently displayed on GitHub and can be viewed here.
Contribute to the DPG Standard
The DPG Standard was developed through an iterative process, building off of the original 51 indicator standard used by the DPGA in the preliminary review of Early Grade Reading projects, and refined through contributions by many experts. The DPG Standard is free for anyone to use and adapt and is licensed under a Creative Commons Attribution ShareAlike 4.0 International License.
One of the most meaningful ways you can contribute is by nominating a digital public good.