4. Platform Independence - DPGAlliance/dpg-resources GitHub Wiki

[!NOTE]

Indicator Requirement: "When the digital public good has mandatory dependencies that create more restrictions than the original license, proving independence from the closed component(s) and/or indicating the existence of functional, open alternatives that can be used without significant changes to the core product is required."

For this indicator, your digital solution must disclose its mandatory dependencies or assets (i.e. libraries, software, or hardware), which may create more restrictions than the original license. Applicants must describe how open-source components in use are independent and/or list the open alternatives for any closed component(s). Your application should be able to demonstrate that closed components can be replaced with open alternatives with minimal configuration changes and without requiring a major overhaul of the entire solution. The sections below are guidelines for each DPG category.

Open Software

Only open software solutions with approved open licenses and well-disclosed dependencies will be considered for this category. In the case of the existence of any proprietary components, you will need to provide evidence (in the form of documentation or demo) of functional, open alternatives that someone reusing the solution can use without significant changes to the core product. Kindly read our more detailed platform independence guide for this category to learn more about why this is important, common issues potential DPGs face, frequently asked questions, and how you can provide evidence for this indicator. To summarize, a good way to indicate platform independence is to:

Declare the core dependencies used in your solution (i.e., those required to install and/or use the solution, such as programming languages, frameworks, libraries, databases, etc.) and clearly reference and attribute any external assets or sources used within your software.
If your solution’s core functionalities are built using proprietary dependencies or other dependencies that do not have approved open licenses, provide evidence that those dependencies can be replaced with open alternatives.
Submit a dependency graph (SBOM) created automatically by your source repository. To learn how to generate this, kindly read the user guide for GitHub or GitLab.

[!TIP]

A core mandatory dependency is one required to install, use, or run the core functionalities of a solution. In the case of the OpemMRS DPG, this includes the Java programming language, Spring Framework, and MySQL/MariaDB database.

A Software Bill Of Materials (SBOM) tracks all components in your software's supply chain, including the versions of all the dependencies used in building the software. Submitting this along with your answer to this question (though not mandatory) will greatly increase your chances of clearing this indicator.

Open Data

All data sets must not create mandatory dependencies on the users of the data. In case there are dependencies, users should be given an easy, no-cost way to navigate to other open technologies with clear documentation (i.e. the dependencies must have alternatives and cannot be a mandatory part of the data set).

Open AI System

Only fully open AI systems with approved open licenses and well-disclosed dependencies will be considered for this category. In the case of the existence of any proprietary components, you will need to provide evidence (in the form of documentation or demo) of functional, open alternatives that someone reusing the solution can use without significant changes to the core product. Since the data, code, and model components are required, the same principles regarding platform independence for Open Software and Open Data are applicable. To summarize, a good way to indicate platform independence is to:

Declare the core dependencies used in your solution (i.e., those required to install and/or use the solution, such as programming languages, frameworks, libraries, databases, etc.).
If your solution’s core functionalities are built using proprietary dependencies or other open dependencies that do not have approved open licenses, provide evidence that those dependencies can be replaced with open alternatives.
Clearly reference and attribute any external assets or sources used within your software.
Submit a dependency graph (SBOM) created automatically by your source repository. To learn how to generate this, kindly read the user guide for GitHub or GitLab.

[!TIP]

A core mandatory dependency is one required to install, use, or run the core functionalities of a solution. In the case of the OpemMRS DPG, this includes the Java programming language, Spring Framework, and MySQL/MariaDB database.

A Software Bill Of Materials (SBOM) tracks all components in your software's supply chain, including the versions of all the dependencies used in building the software. Submitting this along with your answer to this question (though not mandatory) will greatly increase your chances of clearing this indicator.

Open Content

All elements or assets within the content must not create more restrictions than the original license. A good way to indicate this is to clearly reference and attribute any external assets or sources used within your content. If your content collection consists of fully owned assets and IP, you do not need to provide any additional evidence.

[!TIP]

Here's a collection of extra resources and helpful links curated by the DPGA and the DPG community you can explore or contribute to.