[Proposal] Sharpening the "Goods" language in the Standard

[Lucyeoh]

Background

The DPGA secretariat has established an operationalized definition of Digital Public Goods that allows for the assessment of open software, data, content and AI models to determine whether they are digital public goods. As the stewards and hosts of this open standard, our goal is to identify projects that conform to the UNSG’s description of DPGs described in the roadmap.

Within this definition there is already a distinction between the “goods” aka. the open software, the data, the models, the content, with the “project” the purposeful design and deployment of these goods in adherence with laws, best practices and for the attainment of the SDGs.

Today, we frequently conflate goods & projects in the standard.

As a result - assessing and evaluating an individual good, a piece of data, content, or even a piece of software, against the DPG standard today would be very difficult. Even when they are licensed in a way that makes them adaptable and adoptable they are still often “neutral” and could be used for harm or to the SDGs.

It is only when they are designed or deployed with the intention of creating a specific effect that we are able to compare them against the DPG Standard as it is written today.

Assuming our goal is to have a consistent interpretation of what is a Digital Public Good, I see three options:

Option 1: Separate the Goods from the Project

In this scenario any digital, openly licensed software, standard, content, data would be considered a digital public good. As digital goods with appropriate licensing they would address non-rivalry and non-excludability.

We would then additionally try and identify and promote projects that use DPGs to help attain the SDGs.

Implications:

• All open source projects would be considered DPGs
• We would need to shift our wording to try and support projects that leverage DPGs to advance the SDGs,
• We need a name for projects that leverage DPGs to advance SDGs i.e. “DPGs for SDGs” more like “open source for social good”.
• The brand “DPG” will carry less weight - the need for an alternate term from "open source" is not clear.

Option 2: Explicitly focus on Goods NOT Projects (PREFERRED)

In this scenario the DPGA explicitly focuses on goods as openly licensed software, data, AI models, content and standards that have been designed or deployed in a way that advances the SDGs

We would update the language in the standard to explicitly focus on goods (remove reference to projects) being careful to acknowledge that while we can assess a tool (data set/content collection/AI model) based on how it was designed and how it is currently being deployed it doesn’t have active intent or control over the future the way a project does (it is just a tool).

Implications:

• The standard and questions which currently reference “projects” would be re-written in order to explicitly focus on goods. Aka. What category best describes this good?: Select all that apply - Open Source Software, Open Data Set, Open AI Model, Open Standard, Open Content Collection
• Goods can be software, collections of content and/or data sets as long as they’re able to meet the requirements of the standard.
  Technically a single piece of content or data could be a DPG if it was able to show relevance to the SDG in it’s design/deployment (though would likely be difficult).
  We would break “projects” down into their components and review a DPG that was both a platform and a collection of content/data as the platform and the collection separately i.e. MET Norway would contain the DPG: MET Norway software platform, and the MET Norway data set. However the individual pieces of data in the set would not be DPGs (only the collection).
  Similarly we would screen GDL as a platform and a content collection. However every individual piece of content would only be a DPG in so far as it was part of the collection.

Option 3: Focus on projects not goods.

We screen and accept DPG “projects” where projects are defined as a planned undertaking that use open source open software, content, data, AI models to do no harm and advance the SDGs.

In keeping with the standard today DPG projects would require data/software/content/standards to have:
Planned Intent (that is relevant to the SDGs, a commitment to doing no harm)
Accountability (clear ownership and documentation) at the project level

Implications:

• We risk brand confusion highlighting projects but calling them “digital public goods”
• We would not consider individual pieces of content/data/software/standards outside of a designed project to advance the SDGs as DPGs
• We’ll have to update the standard/questions to better reflect projects that encompass multiple individually licensed components
• We need to update Indicator 1 - to make it designed intent

[Lucyeoh]

Next Steps:

• Do a PR with all of the language from the google docs (once the rest of the language is landed).

Prioritization:

• not burning can be done in parallel with the others

[Lucyeoh]

Final language proposal: replace "projects" with "digital solutions"

[Lucyeoh]

If accepted create a PR with this

[lacabra]

This is being addressed by #75

[prajectory]

Linking #75 here since its related to "project" as used the language of the current standard.

[prajectory]

Indicative text to incorporate these changes?

1. Indicating the Sustainable Development Goals (SDGs) that are relevant to the digital solution along with (/and) supporting links/documentation that support their relevance.
2. The digital solution must demonstrate the use of an approved open license. (An approved open license must be in active use by the digital solution) 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 dedicate content collections 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 datasets, an Open Data Commons approved license is required. See The full license list for reference.
3. Ownership of everything the digital solution produces must be clearly defined and documented. For example, through copyright, trademark or other publicly available information.
   If the digital solution has mandatory dependencies that create more restrictions than the original license, demonstrating independence from the closed component(s) and/or indicating the existence of functional, open alternatives is mandatory/required.
4. Documentation of the source code, use cases, and/or functional requirements must be undertaken by the digital solution. For content collections, this should include all relevant/compatible apps, software, or hardware required to access the content collection, and instructions regarding how to use it. For software solutions, 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 dataset was collected, and how it should be interpreted.
5. If the digital solution has non personally identifiable information (PII) there must be a mechanism (in/by design?) for extracting or importing non-PII data and content from the system in a non-proprietary format.
   The digital solution must be designed and developed to comply with relevant privacy laws, and all applicable international and domestic laws.
6. Digital solutions must be designed and developed to align with relevant standards, best practices, and/or principles. For example, the Principles for Digital Development.

(indicator 7 and 8 have no changes)

All digital solutions must be designed to anticipate, prevent, and do no harm by design
9a Digital solutions designed to collect data must indicate the types of data they were designed to collect and store. Solutions must also demonstrate how they have been designed to ensure the privacy and security of this data in addition to how to design of the solution prevents adverse impacts resulting from its collection, storage and distribution.
9b Digital solutions designed to collect, store or distribute content collections must have mechanisms for identifying inappropriate and illegal content collections such as child sexual abuse materials in addition to mechanisms for detecting, moderating and removing inappropriate/illegal content.
9c If the digital solution was designed to facilitate 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 solution must have a mechanism to address the safety and security of underage users.

[prajectory]

#97 This change will also be executed with #57 since it also deals with sharpening the language.

[prajectory]

New language that sharpens the "projects" language and makes it clear that the entity here is a 'digital public good'. We are opening this for a 2 week Community Discussion Period after which we will be deploying these changes.

1. Relevance to Sustainable Development Goals | Digital public goods must be designed and developed to advance the Sustainable Development Goals (SDGs) and demonstrate such by providing links/documentation that support their relevance.

2. Use of Approved Open Licenses | Digital public goods must demonstrate the use of an approved open license. For open-source software, only OSI approved licenses are accepted. For open content collections, the use of a Creative Commons license is required. DPGs are encouraged 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 assets that the digital public good produces must be clearly defined and documented. For example, through copyright, trademark or other publicly available information.

4. Platform Independence | 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.

5. Documentation | Digital public goods require documentation of the source code, use cases, and/or functional requirements. For content collections, this should include all relevant/compatible apps, software, or hardware required to access the content collection, and instructions regarding how to use it. For software solutions, 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 the dataset was collected, and how it should be interpreted.

6. Mechanism for Extracting Data and Content | Digital Public Goods with non personally identifiable information (PII) must design for possibility of extracting or importing non-PII data and content from the system in a non-proprietary format.

7. Adherence to Privacy and Applicable Laws | Digital Public Goods must be designed and developed to comply with applicable privacy laws.

8. Adherence to Standards & Best Practices | Digital Public Goods must be designed and developed to align with relevant standards, best practices, and/or principles. For example, the Principles for Digital Development.

9. Do No Harm By Design | Digital Public Goods must be designed to anticipate, prevent, and do no harm by design
   9a) Data Privacy & Security | Digital Public Goods that collect data must indicate the types of data collected and stored. DPGs must demonstrate how they are designed to ensure that the privacy and security of this data, in addition to how the design of the DPG mitigates and prevents adverse impacts that can result from data collection, storage and distribution.
   9b) Inappropriate & Illegal Content | Digital Public Goods designed to collect, store or distribute content collections must have policies for identifying inappropriate, harmful and illegal content collections (i.e child sexual abuse materials) in addition to mechanisms for detecting, moderating and removing inappropriate/illegal content.
   9c) Protection from Harassment | When Digital Public Goods facilitate interactions with or between users or contributors, they are required to have a mechanism for users and contributors to protect themselves against grief, abuse, and harassment. In addition, DPGs must have a mechanism to address the safety and security of underage users.

[prajectory]

@llsandell we have resolved the above mentioned issues by you in the draft text we intend to incorporate into the standard. This text is now open for community discussion period. We look forward to hearing from you. Some of the other issues you have mentioned are yet to be resolved. Thanks!

[prajectory]

This has been executed through the following PR: #108

Closing this issue. Thanks!