Open Software Guide
This is a support document to guide open-software digital projects to submit an application for digital public good recognition by the DPGA.
♥️ Helpful Tips:
Please make sure that all your documentation (not just the application form, but also the code, websites, repos) is in English. We do not accept other languages since we don't have the expertise to process them.
All documentation provided should be available through public links such as Github links or website pages. We do not accept google drive documents, sheets or pages.
Software documentation should be comprehensive enough that it enables a lay person to run, deploy and contribute to the project. It should not be limited to those with high tech knowledge.
Simply answering 'No' to the question on platform independence doesn't clear the indicator. This is the indicator where most apps fail. Please see this section to know how you can clear it.
Digital public goods must be designed and developed to advance the Sustainable Development Goals (SDGs). A good way to provide evidence of this is:
State a clear couple of sentences that explain the relationship between your software and the selected SDG(s) pointing to the specific targets you help accomplish.
Provide any link(s) of a blog post, media post, or public communication (organisation mission statement or similar) that talks about any social, public, or relevant contribution to society. It is not necessary that these mention SDGs as long as it relates to the previous explanation.
📌 You can use this SDG tracker tool to get an idea of the targets, initiatives, and data around each SDGs
📌 The SDG Academy provides free, open educational resources from the world’s leading experts on the sustainable development goals.
<Project name> helps advance SDG 3: Good Health and Wellbeing by providing integrated health services to the last mile population by <insert method>
Collaboration with X local government to advance healthcare - “www.link-to-the-article.com”
For open software applications, you need to have one of the licenses listed here.
In case you have a non-OSI approved license, you can do one of the following:
Create a patch, abstraction layer, or similar within the solution that provides an open alternative (OSI-approved) to these components or features. Of course, this only works if there are OSI-approved alternatives in the first place.
If this is not a core dependency, technically prove the software can be used without these components or features.
A good way to provide evidence of the licence used is to have it listed as a footer on your website and have it in the root repository of your Github page.
The software is licensed under the MIT License <link to license file on github> and is free for use and sharing.
It is important to clearly define the ownership of different software solutions.
A good way to do so is to mention their name of the Github readme page, as the owner of the software license, and / or on the Website.
The owner of an open software solution can be an individual or an organisation.
📌 Ownership is important because it defines accountability.
<Project name> is owned by <organisation name>. You can find proof of ownership here <insert link 1> and here <insert link 2>
Digital public goods with elements or assets within the software that create more restrictions than the original license must indicate them. A good way to indicate this is to clearly reference and attribute any external assets or sources used within your software.
📌 TIP!
A Software Bill Of Materials (SBOM) traces all the versions of all the applications used in building your software. You can read more about it here.
Submitting this along with your answer to this question (though this is not mandatory) will greatly increase your chances of clearing this indicator.
You can also submit a Dependency Graph created automatically by Github. Simply go to your Repository > Insights > dependency graph. This also gives you the option to download a ready-made SBOM doc on the top right hand side corner.
Mongo DB
If your software uses an application such as Mongo DB, it may fail this indicator of platform independence.
In order to comply with platform independence, please provide an open alternative to this dependency. For example; migrating all database requirements to something like PostgreSQL (PostgreSQL License), CouchDB (Apache License 2.0) or MongoDB versions released prior to October 16, 2018 published under AGPL license.
To navigate this, you can either:
[1] Refactor the code to use an open alternative to MongoDB with an OSI approved license
[2] Create an abstraction layer for the features that use MongoDB that allows implementers choose between this and other open alternative (i.e. CouchDB)
[3] Create a patch that technically demonstrates the possibility to use/ swap MongoDB for an open alternative and that is documented in the repository.
* Compliance with only one of this options is enough.
Elastic Search
If your solution uses Elastic Search, please check for your answers to the following questions:
Is it a version below 7.11 that is under Apache 2.0 license? (it should be explicitly documented in the installation docs)
If not, are you using any of the new features introduced on versions 7.10+ and newer?
Can ElasticSearch be easily swapped by OpenSearch?
Unity
Please note that due to lack of open alternatives available for Unity, digital solutions that have Unity as a core component will most likely fail this indicator and not become a DPG.
For software solutions, documentation could include an open repo, technical specifications, functional requirements.
It is important that the documentation shows the following aspects (non-exhaustive list):
The exhaustive documentation for <project name> can be found on <link>
Digital public goods must have the possibility of extracting data from the system in a non-proprietary format. A good way to provide evidence of this is to state the mechanisms from which data can be downloaded or exported publicly.
📌 List of non-proprietary file formats.
📌 Open API Specifications
Data can be directly exported and/ or downloaded into the following open formats: CSV, XML, JSON
Digital public goods must be designed and developed to comply with applicable privacy laws. A good way to provide evidence of this is:
Provide a link to your project/organisation's privacy policy.
State any privacy laws you comply with.
📌 Data Protection and Privacy Legislation Worldwide.
📌 Privacy policy generator and example.
<Project name> complies with laws like the GDPR, CCPA, CalOPPA and U.S. Federal Children’s Online Privacy Protection Act of 1998. You can also access our privacy policy at www.project-website.org/privacy
Digital public goods must be designed and developed to align with relevant standards, best practices, and/or principles. A good way to provide evidence of this is to state all relevant data, technology or related best practices/ open standards
📌 HINT:
For best practices regarding open source software solutions, particularly for organisations involved in in developing and maintaining software and policy together, please refer to The Standard For Public Code
<Project name> adheres to HL7/FHIR. Evidence of this compliance can be found here <insert link>
Digital public goods must be designed to anticipate, prevent, and do no harm by design. A good way to provide evidence of this is to provide any links relevant to user terms and conditions, privacy policy, code of conduct or similar.
📌 Definition for personal data (PII data).
These are reference docs for specific purposes:
Child Protection guidelines
Mobile Security Testing guidelines
Data protection impact assessment guidelines + template
You can access our privacy policy at www.project-website.org/privacy, code of conduct at www.project-website.org/code-of-conduct and terms of use at www.project-website.org/terms-of-use.“
Last updated