Risultati
239 risultati
-
italia
Policy del catalogo del software open source di Developers Italia
Regole per la pubblicazione di software nel catalogo di Developers Italia. Questo documento si pone l’obiettivo di rendere più trasparente e condivisa la modalità di valutazione del software candidato ad entrare nel catalogo di Developers Italia ...
-
italia
Ammissione del software a catalogo
Nel catalogo del software di Developers Italia non sono ammessi:. I repository ospitati in uno strumento di code hosting non conforme ai requisiti espressi nell’allegato A delle linee guida. I repository che contengono:. software incompleto;. software non compilabile / installabile;. software privo di documentazione relativa alla compilazione o all’installazione;. software che non rientra nella definizione di cui all’art. 1.2 delle linee guida;. software che non raggiunge un livello sufficiente di unità funzionale. I repository che violano delle regole di diritto:. software privi di licenza aperta;. repository contenenti licenze tra loro incompatibili;. software che violano diritti di proprietà intellettuale o altri diritti di terzi;. repository con contenuti illegali, commerciali o che violano norme di legge. I repository contenenti un file publiccode.yml non valido:. non rispondente alle specifiche (descritte qui);. che non permette di capire lo scopo, le finalità e i requisiti del software;. I gestori della piattaforma Developers Italia si riservano il diritto di rimuovere dal catalogo i repository che violano queste regole. In caso di esclusione i gestori della piattaforma Developers Italia comunicheranno le motivazioni al gestore del repository attraverso i canali di comunicazione disponibili. A seguito della eventuale correzione delle violazioni segnalate e della relativa comunicazione ai gestori di Developers Italia, il software potrà essere incluso nuovamente nel catalogo ...
-
italia
Il Catalogo di Developers Italia
La seguente policy si applica all’inserimento di soluzioni software open source all’interno del catalogo di Developers Italia. Il catalogo di Developers Italia contiene due aree:. La seconda è dedicata a soluzioni open source, la cui titolarità sia attribuita a soggetti terzi, che potrebbero essere di interesse di una PA. L’aggiunta di software al catalogo avviene in automatico tramite una scansione periodica notturna di diverse fonti:. Gli spazi di code hosting inseriti attraverso una procedura di Pull Request nel file di whitelist presente sul repo GitHub. Questi software entrano nella seconda area del catalogo (B). Altri spazi di code hosting individuati dai gestori del catalogo di Developers Italia con mezzi manuali o automatizzati. Questi software entrano nella seconda area del catalogo (B) ...
-
italia
Limitazione di responsabilità
AgID e il Team per la Trasformazione Digitale non sono responsabili per il software pubblicato, per la sua rispondenza alle normative e per la sua sicurezza. L’acquisizione e la messa in opera di tale software avvengono sotto la responsabilità di ciascun ente secondo le disposizioni e le limitazioni di responsabilità indicate nella relativa licenza. L’inclusione delle soluzioni nel catalogo avviene con mezzi automatizzati come sopra descritto e pertanto i gestori della piattaforma Developers Italia non svolgono attività di verifica preventiva ...
-
italia
2. Country-Specific Extensions
All the extensions listed below are specific for Italy and, as such, they must be inserted in a section named with the it code. Every Country is specified using a two letters country code following the ISO 3166-1 alpha-2 standard. 2.1.1. Key countryExtensionVersion. Type: string. Presence: mandatory. Example: "1.0". This key specifies the version to which the current extension schema adheres to, for forward compatibility. Please note how the value of this key is independent from the top-level publiccodeYmlVersion one (see The Standard (core)). In such a way, the extensions schema versioning is independent both from the core version of the schema and from every other Country. 2.1.2. Key conforme. This section contains the keys for auto-declaring the compliance with the current legislation, with respect to the following sections. Not including these keys implies that the compliance is not known or not declared. 2.1.2.1. Key conforme/lineeGuidaDesign. Type: boolean. Presence: optional. If present and set to yes, the software is compliant with the Italian accessibility laws (L. 4/2004), as further explained in the linee guida di design (Italian language). 2.1.2.2. Key conforme/modelloInteroperatibilita. Type: boolean. Presence: optional. If present and set to yes, the software is compliant with the linee guida sull’interoperabilità. Regulatory reference: Art. 73 del CAD (Italian language). 2.1.2.3. Key conforme/misureMinimeSicurezza. Type: boolean. Presence: optional. If present and set to yes, the software is compliant with the Misure minime di sicurezza ICT per le Pubbliche amministrazioni (Italian language). 2.1.2.4. Key conforme/gdpr. Type: boolean. Presence: optional. If present and set to yes, the software respects the GDPR. 2.1.3. Section piattaforme. 2.1.3.1. Key piattaforme/spid. Type: boolean. Presence: optional. If present and set to yes, the software interfaces with SPID - il Sistema Pubblico di Identità Digitale. 2.1.3.2. Key piattaforme/cie. Type: boolean. Presence: optional. If present and set to yes, the software interfaces with the Italian electronic ID card (Carta di Identità Elettronica). 2.1.3.3. Key piattaforme/anpr. Type: boolean. Presence: optional. If present and set to yes, the software interfaces with ANPR. 2.1.3.4. Key piattafome/pagopa. Type: boolean. Presence: optional. If present and set to yes, the software interfaces with pagoPA. 2.1.4. Section riuso. This section contains a set of keys related to the publication of the software inside the reuse catalog of Developers Italia. 2.1.4.1. Chiave riuso/codiceIPA. Type: string (iPA code). Presence: mandatory if repoOwner is a Public Administration. Example: c_h501. This key represents the administration code inside the Public Administration index (codice IPA) ...
-
italia
4. List of software categories
accounting. agile-project-management. applicant-tracking. application-development. appointment-scheduling. backup. billing-and-invoicing. blog. budgeting. business-intelligence. business-process-management. cad. call-center-management. cloud-management. collaboration. communications. compliance-management. contact-management. content-management. crm. customer-service-and-support. data-analytics. data-collection. data-visualization. digital-asset-management. digital-citizenship. document-management. donor-management. e-commerce. e-signature. email-management. email-marketing. employee-management. enterprise-project-management. enterprise-social-networking. erp. event-management. facility-management. feedback-and-reviews-management. financial-reporting. fleet-management. fundraising. gamification. geographic-information-systems. grant-management. graphic-design. help-desk. hr. ide. identity-management. instant-messaging. inventory-management. it-asset-management. it-development. it-management. it-security. it-service-management. knowledge-management. learning-management-system. marketing. mind-mapping. mobile-marketing. mobile-payment. network-management. office. online-booking. online-community. payment-gateway. payroll. predictive-analysis. procurement. productivity-suite. project-collaboration. project-management. property-management. real-estate-management. remote-support. resource-management. sales-management. seo. service-desk. social-media-management. survey. talent-management. task-management. taxes-management. test-management. time-management. time-tracking. translation. video-conferencing. video-editing. visitor-management. voip. warehouse-management. web-collaboration. web-conferencing. website-builder. workflow-management ...
-
italia
publiccode.yml
Table of contents ...
-
italia
Italy
This section contains a set of keys related to the publication of the software inside the reuse catalog of Developers Italia. Chiave riuso/codiceIPA. Type: string (iPA code). Presence: mandatory if repoOwner is a Public Administration. Example: c_h501. This key represents the administration code inside the Public Administration index (codice IPA) ...
-
italia
3. Forks and variants
A software variant is a fork that is offered as an alternative to the original upstream software. It contains modifications that are still not part of the upstream version, like more features, different dependencies, optimizations, etc. By marking a fork as a variant, the author indicates that they believe that the variant includes a complete and working set of modifications that might be useful to other people. Marking a fork as a variant does not relate to the willingness of contributing upstream; the author might still plan to contribute the modifications upstream, or even being in the process of doing so. Thus, even if the fork will eventually be merged upstream, it might make sense to mark it as a variant during the process, so that others might discover it and benefit from it. 3.2.1. Parsers. Parsers SHOULD identify a variant by noticing that the top-level url key matches to the repository in which the publiccode.yml is found, AND a top-level isBasedOn exists and points to a different repository. Parsers should expect and analyze other differences in publiccode.yml between variants of the software. Specifically description/features is designed to be compared across variants to identify and show user-visible differences. 3.2.2. Authors. Authors that are willing to publish a fork as a variant MUST at least:. add a key isBasedOn pointing to one or more upstream repositories from which this variant is derived. Change the value for url to point to the repository holding the variant. Change the value for legal/repoOwner to refer to the themselves (the authors of the variant). Revisit the maintenance section to refer to the maintenance status of the variant. Moreover, authors SHOULD evaluate the following changes:. add the features that differentiate the variant to the description/features key. Existing features SHOULD NOT be edited or removed from this list unless they have been removed from the variant, to allow parsers to easily compare feature lists ...
-
italia
5. Scope list
agriculture. culture. defence. education. emergency-services. employment. energy. environment. finance-and-economic-development. foreign-affairs. government. healthcare. infrastructures. justice. local-authorities. manufacturing. research. science-and-technology. security. society. sport. tourism. transportation. welfare ...
-
italia
6. Esempi
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138. publiccodeYmlVersion: "0.2" name: Medusa applicationSuite: MegaProductivitySuite url: "https://example.com/italia/medusa.git" landingURL: "https://example.com/italia/medusa" isBasedOn: "https://github.com/italia/otello.git" softwareVersion: "1.0" releaseDate: "2017-04-15" logo: img/logo.svg monochromeLogo: img/logo-mono.svg inputTypes: - text/plain outputTypes: - text/plain platforms: - android - ios categories: - content-management - office usedBy: - Comune di Firenze - Comune di Roma roadmap: "https://example.com/italia/medusa/roadmap" developmentStatus: development softwareType: "standalone/desktop" intendedAudience: scope: - science-and-technology countries: - it - de unsupportedCountries: - us description: en: localisedName: Medusa genericName: Text Editor shortDescription: > This description can have a maximum 150 characters long. We should not fill the remaining space with "Lorem Ipsum". End longDescription: > Very long description of this software, also split on multiple rows. You should note what the software is and why one should need it. documentation: "https://read.the.documentation/medusa/v1.0" apiDocumentation: "https://read.the.api.doc/medusa/v1.0" features: - Very important feature - Will run without a problem - Has zero bugs - Solves all the problems of the world screenshots: - img/sshot1.jpg - img/sshot2.jpg - img/sshot3.jpg videos: - https://youtube.com/xxxxxxxx awards: - 1st Price Software of the year legal: license: AGPL-3.0-or-later mainCopyrightOwner: City of Chicago repoOwner: City of Chicago authorsFile: AUTHORS maintenance: type: "contract" contractors: - name: "Fornitore Privato SPA" email: "dario.bianchi@fornitore.it" website: "https://privatecompany.com" until: "2019-01-01" contacts: - name: Francesco Rossi email: "francesco.rossi@comune.reggioemilia.it" affiliation: Comune di Reggio Emilia phone: "+3923113215112" localisation: localisationReady: yes availableLanguages: - en - it - fr - de dependsOn: open: - name: MySQL versionMin: "1.1" versionMax: "1.3" optional: yes - name: PostgreSQL version: "3.2" optional: yes proprietary: - name: Oracle versionMin: "11.4" - name: IBM SoftLayer hardware: - name: NFC Reader optional: yes it: countryExtensionVersion: "0.2" conforme: lineeGuidaDesign: yes modelloInteroperabilita: yes misureMinimeSicurezza: yes gdpr: yes piattaforme: spid: yes cie: yes anpr: yes pagopa: yes riuso: codiceIPA: c_h501 ...
-
italia
1. The Standard (core)
1.2.1. Dependency. A dependency is a complex object. The properties are the following:. name - mandatory - The name of the dependency (e.g. MySQL, NFC Reader). versionMin - the first compatible version. versionMax - the latest compatible version. version - the only major version for which the software is compatible. It assumes compatibility with all patches and bugfixes later applied to this version. optional - whether the dependency is optional or mandatory. 1.2.2. Complex versioning. It is of course possible to use the various keys to specify a complex compatibility matrix. Ex. 1. - name: PostgreSQL version: "3.2" optional: yes. This snippet marks an optional dependency on PostgreSQL exactly version 3.2. Ex. 2. - name: MySQL versionMin: "1.1" versionMax: "1.3". This snippet marks a mandatory dependency on MySQL, allowing any version between 1.1 and 1.3. 1.2.3. Contact. A Contact is an object with the following properties:. name - mandatory - This key contains the full name of one of the technical contacts. It must be a real person; do NOT populate this key with generic contact information, company departments, associations, etc. email - This key contains the e-mail address of the technical contact. It must be an email address of where the technical contact can be directly reached; do NOT populate this key with mailing-lists or generic contact points like “info@acme.inc”. The e-mail address must not be obfuscated. To improve resistance against e-mail collection, use \x64 to replace @, as allowed by the YAML specification. phone - phone number (with international prefix). This has to be a string. affiliation - This key contains an explicit affiliation information for the technical contact. In case of multiple maintainers, this can be used to create a relation between each technical contact and each maintainer entity. It can contain for instance a company name, an association name, etc. 1.2.4. Contractor. A Contractor is an object with the following properties:. name - mandatory - The name of the contractor, whether it’s a company or a physical person. until - mandatory - This is a date (YYYY-MM-DD). This key must contain the date at which the maintenance is going to end. In case of community maintenance, the value should not be more than 2 years in the future, and thus will need to be regularly updated as the community continues working on the project. email - This key contains the e-mail address of the technical contact. It must be an email address of where the technical contact can be directly reached; do NOT populate this key with mailing-lists or generic contact points like “info@acme.inc”. The e-mail address must not be obfuscated. To improve resistance against e-mail collection, use \x64 to replace @, as allowed by the YAML specification. website - This key points to the maintainer website. It can either point to the main institutional website, or to a more project-specific page or website. 1.2.5. Dates. All dates in publiccode.yml must follow the format “YYYY-MM-DD”, which is one of the ISO8601 allowed formats. This is the only allowed format though, so not the full ISO8601 is allowed for the date keys. 1.2.6. Encoding. publiccode.yml MUST be UTF-8 encoded ...