Stabilire uno standard per i beni pubblici digitali
Lo standard a nove indicatori mira a promuovere software, dati, modelli di intelligenza artificiale, standard e contenuti open source per un mondo più equo.
Nel giugno 2020, il Segretario generale delle Nazioni Unite ha pubblicato una "Roadmap per la cooperazione digitale". In questo rapporto, ha ampliato le raccomandazioni formulate un anno prima, invitando tutti gli attori, compresi gli Stati membri, il sistema delle Nazioni Unite, il settore privato e altri, a promuovere i beni pubblici digitali. Secondo lui, per realizzare i benefici di una maggiore connettività Internet, i progetti open source sotto forma di beni pubblici digitali devono essere al centro.
Sebbene il termine “bene pubblico digitale” compaia già nell’aprile 2017, questo rapporto offre la prima definizione ampiamente accettata di bene pubblico digitale:
"Software open source, dati aperti, modelli di intelligenza artificiale aperti, standard aperti e contenuti aperti che rispettano la privacy e altre leggi, standard e migliori pratiche internazionali e nazionali applicabili e non arrecano alcun danno."
La Digital Public Goods Alliance (DGPA) ha tradotto questa definizione in uno standard aperto a nove indicatori che speriamo possa servire come definizione completa e condivisa per promuovere la scoperta, lo sviluppo, l’uso e gli investimenti nei beni pubblici digitali per un mondo più equo. .
Lo standard DPG è stato sviluppato a partire dallo standard originale di 51 indicatori utilizzato dal DPGA nella revisione preliminare dei progetti di Early Grade Reading e perfezionato grazie al contributo di molti esperti. Lo standard è esso stesso un progetto open source. La versione principale risiede su GitHub ed è aperta a contributi, revisioni e suggerimenti da chiunque. Le revisioni proposte vengono regolarmente riviste in linea con i principi di governance dello standard e invitiamo chiunque utilizzi lo standard e ne tragga vantaggio a unirsi al nostro crescente elenco di sostenitori.
La Digital Public Goods Alliance prevede di coinvolgere una comunità crescente di contributori e parti interessate attorno allo standard per i beni pubblici digitali. La nostra ambizione è bilanciare la reattività al feedback con la stabilità e la prevedibilità dello standard in modo che possa essere un quadro affidabile che supporti lo sviluppo, il riconoscimento e la difesa dei beni pubblici digitali.
Standard sui beni pubblici digitali
Di seguito è riportato l'elenco completo degli indicatori e dei requisiti dello standard DPG nella versione v.1.1.2. Questi devono essere soddisfatti affinché un progetto nominato (software, dati, modello di intelligenza artificiale, standard e/o contenuto) possa essere considerato un bene pubblico digitale.
Indicator | Requirement |
---|---|
1. Relevance to Sustainable Development Goals | All projects must indicate the Sustainable Development Goals (SDGs) that they are relevant to and provide supporting links/documentation to support this relevance. |
2. Use of approved open source license | Projects must demonstrate the use of an approved open source license. For open source software, we only accept OSI approved licenses. For open content, we require the use of a Creative Commons license, while we encourage projects to use a license which allows for both derivatives and commercial reuse (CC-BY and CC-BY-SA), or dedicate content to the public domain (CC0); we also accept licenses which do not allow for commercial reuse (CC BY-NC and CC BY-NC-SA). For data, we require an Open Data Commons approved license. You can find the full license list here. |
3. Documentation of ownership | Ownership of everything that the project produces must be clearly defined and documented, i.e., through copyright, trademark, or other publicly available information. |
4. Mandatory dependencies | If the open source project has mandatory dependencies that create more restrictions than the original license, the projects must be able to demonstrate independence from the closed component and/or indicate the existence of functional, open alternatives. |
5. Documentation | The project must have some documentation of the source code, use cases, and/or functional requirements. For content, this should indicate any relevant compatible apps, software, hardware required to access the content, and instructions about how to use it. For software projects, this should be present as technical documentation that would allow a technical person unfamiliar with the project to launch and run the software. For data projects, this should be present as documentation that describes all the fields in the set and provides context on how the data was collected and how it should be interpreted. |
6. Mechanism for extracting data | If this project has non personally identifiable information, there must be a mechanism for extracting or importing non personally identifiable information (PII) data from the system in a non-proprietary format. |
Note that evidence for requirements 7 through 9 can only be given by someone authorized to speak on behalf of the project. We collect title, name, and contact information to confirm this authority. | |
7. Adherence to privacy and applicable laws | The project must state that, to the best of its knowledge, it complies with relevant privacy laws and all applicable international and domestic laws. |
8. Adherence to standards and best practices | Projects must demonstrate some adherence to standards, best practices, and/or principles, i.e., the principles for digital development. |
9. Do no harm | All projects must demonstrate that they have taken steps to ensure that the project anticipates, prevents, and does no harm. |
9a. Data privacy and security | Projects that collect data must identify the types of data collected and stored and demonstrate that the project ensures the privacy and security of this data and has taken steps to prevent adverse impacts resulting from its collection, storage, and distribution. |
9b. Inappropriate and illegal content | Projects that collect, store, or distribute content must have policies identifying inappropriate and illegal content such as child sexual abuse materials and mechanisms for detecting, moderating, and removing inappropriate/illegal content. |
9c. 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. |
Se conosci un progetto che ritieni soddisfi questi standard e debba essere considerato un bene pubblico digitale, invialo. Accogliamo con favore anche il tuo feedback sullo standard nei commenti qui sotto.
Questo articolo è adattato con il permesso del post "Definire uno standard per i beni pubblici digitali", originariamente apparso sul blog della Digital Public Goods Alliance blog e Medio canale.