Ai confini della Licenza

Dove finisce la ODbL e dove iniziano le linee guida della Comunità

In principio…

OpenStreetMap (OSM) è, nel suo nucleo, un database globale di informazioni geografiche e ha una licenza, la Open Database Licence (ODbL), che è stata progettato da zero per garantire la libertà per i database rilasciati pubblicamente. Nello spirito, è molto simile alla licenza Creative Commons “Attribuzione-Condividi allo stesso modo” (CC-BY-SA), che è stata progettato per le opere creative, o la GNU General Public License (GPL), che è stata  progettata per coprire il codice sorgente del computer.

Sia la CC-BY-SA sia la GPL sono esistite per molti anni e sono costruite sulle leggi legate ai “diritti d’autore”, che consentono all’autore o gli autori di un lavoro di controllare a quali condizioni esso può essere duplicato e distribuito. Queste leggi sono diffuse, in una forma o nell’altra, da oltre 300 anni e, a causa della loro lunga storia, sono state esaminate da legislatori, avvocati, giudici e giurie molte volte. Questo processo di controllo si traduce in decisioni legislative o giudiziarie, e ciascuna di queste decisioni aiuta a costruire un corpo di “giurisprudenza” e di precedenti giudizi di tribunale che possono essere utilizzate in seguito per formare un parere sulla questione se un uso particolare rischia di essere messo in discussione o no. E’ importante sapere che le decisioni sono considerate prese solo quando i giudici o giurie abbiano emesso un verdetto, il che significa che spesso è impossibile prendere una qualsiasi decisione definitiva senza giurisprudenza precedente e e senza casi precedenti.

I confini e i poteri del diritto d’autore sono stati messi alla prova in tribunale molte volte, e sembrerebbe ragionevole basare la licenza di OSM su di esso, tuttavia, non è affatto chiaro che il copyright si applichi a un database di informazioni geografiche e così la nostra licenza si basa sul diritto d’autore, diritto contrattuale e il “diritto sui database”, che per la prima volta sancito dalla legge nel 1996 come parte della direttiva europea sui database. Purtroppo per noi, i dati aperti, come oggetto distinto dai campi più affermati legati al codice sorgente aperto per computer e alle creazioni artistiche altamente libere, portano con se una serie di sfide diverse, soprattutto quando sono coinvolte licenze con clausole di tipo Share-Alike. La “giovane” natura dei diritti sui database significa proprio che c’è molta poca storia, giurisprudenza e pochi precedenti, cosa che porta incertezza circa le implicazioni della ODbL. Questa incertezza si traduce in rischio per gli utenti di dati OSM, cosa che può impedire ad OSM di essere più ampiamente utilizzato e che ostacola uno degli obiettivi primari del progetto: permettono che i dati vengano utilizzati in “modi creativi, produttivi o imprevisti”.

Fino a quando la giurisprudenza e i precedenti potranno essere deciso da casi giudiziari e delle decisioni giudiziarie possiamo ridurre l’incertezza chiarendo le intenzioni di coloro che hanno rilasciato i dati (cioè: la comunità OSM). La nostra opinione di consenso ha un grande peso e può contribuire a plasmare la direzione di eventuali decisioni future riguardanti l’uso di OSM, ed eventualmente altri dati aperti.

Le nuove linee guida

Il Gruppo di lavoro Licensing (Licence Working Group – LWG) ha lavorato duramente per assicurare che l’incertezza per gli utilizzatori di dati venisse ridotta, mentre l’intento della comunità venisse, al tempo stesso, protetto. Dopo molte discussioni, a giugno di quest’anno, la prima serie di linee guida è stata approvato.

Sostanziale

Così come il diritto d’autore prevede delle eccezioni legate al “Fair Use” quando il campione non è sostanziale, così è per i diritti sui database. Se un estratto sia sostanziale o meno in base al diritto d’autore dipende dal rapporto dell’estratto con l’opera originale, come avviene nel diritto sui database. Purtroppo, questo crea incertezza per gli utenti di dati sul fatto che il loro uso sia sostanziale o meno. Queste linea guida cercano di definire il termine “sostanziale” più precisamente nel contesto di OSM. Per maggiori dettagli, consultare le “Linee Guida su Sostanziale“.

Lavoro Derivato

“Lavoro Derivato” è un termine usato dalla ODbL per definire a grandi linee qualcosa di separato creato a partire da un database ma non un database esso stesso. Poiché la clausola Condividi allo stesso modo della ODbL si applica solo ai database e non ai “lavori derivati” chiaramente è importante fare una distinzione fra i due in maniera il più inequivocabile possibile. Per maggiori dettagli, consultare le “Linee Guida su Lavoro Derivato“.

Trasformazioni Triviali

Ci sono situazioni in cui i dati OSM possono essere manipolati o “trasformati”, ma in modo tale che la manipolazione in realtà non aggiunge o migliora i contributi fatti dalla comunità OSM. Pertanto, non vi è alcun bene comune che venga servito forzando la pubblicazione del risultato di tali manipolazioni. Un esempio di questo potrebbe essere il caricare un database di rendering PostGIS con osm2pgsql – nessun valore è stato aggiunto da questa trasformazione, perquesto chiamiamo la trasformazione, “triviale”. Per maggiori dettagli, vedere le “Linee Guida su Trasformazioni Triviali“.

Tagli Regionali

Ci sono molti luoghi nel mondo in cui i dati OSM sono i migliori dati cartografici disponibili, e alcuni dove non è così. Nelle regioni in cui non è così, molti utenti vorrebbero utilizzare una fonte alternativa, invece, ma sono incerti sul fatto che questo farebbe scattare requisiti Share-Alike su tutto il dataset. Questa incertezza impedisce, in alcuni casi, qualsiasi utilizzo dei dati OSM, anche nelle regioni in cui la qualità è superiore. Questa linea guida adotta e formalizza il principio stabilito che i dati OSM possono essere utilizzati per alcune regioni e non altri, a patto che alcune condizioni siano soddisfatte. Per maggiori dettagli, vedere la sezione “Linee Guida su Tagli Regionali“.

Strati Orizzontali

Così come ci sono molte regioni del mondo per le quali OSM è la migliore base dati disponibile, ci sono anche molti “strati” tematici, ad esempio ristoranti, per i quali i dati OSM sono superiori in qualità. Tuttavia, la questione per cui l’uso di strati supplementari da altre fonti sia accettabile impedisce di fatto l’uso di OSM in alcuni casi. Queste linee guida adottano e formalizzano un altro principio assodato: che gli strati isolati in una mappa possono provenire da OSM o no, a patto che siano soddisfatte determinate condizioni. Per maggiori dettagli, consultare le “Linee Guida sugli Strati Orizzontali“.

Come procediamo da qui?

Queste sono solo le prime linee guida e c’è ancora molto lavoro da fare per chiarire le zone grigie che circondano il corretto utilizzo dei dati OSM. In particolare, è necessario lavorare per contribuire a rendere coerenti le linee guida su:

  • Livelli di metadati – Se un livello metadati raccolto esternamente (non-OSM) è fatto e mantenuto completamente separatamente, ma abbinato a numeri identificativi generati dal database per identificare i singoli elementi in OSM, quando è esso diventa derivato e quindi deve essere condiviso?
  • Indicizzazione - Se i dati OSM vengono indicizzati, ad esempio, da un motore di ricerca, ci troviamo di fronte ad una banca dati derivata che avrebbe bisogno di essere condivisa?
  • Geocoding - Se si trovano i luoghi associati agli indirizzi, o vengono generate descrizioni per le posizioni, in un processo di “geocoding”, questa cosa fa scattare la clausola di “share-alike” e richiede la condivisione dei dati che vengono sottoposti a geocoding?
  • “Fall Back” - In un servizio che prima tenti di trovare una risposta, cercando in dati OSM e, se la risposta non può essere trovata, “ripieghi” a cercare in un altro database, sono, questi database separati o il fare questo processo significa che li avete combinati e, pertanto, siete tenuti a condividere l’unione di essi?
  • dati dinamici - Se i fornitori di dati dinamici, come ad esempio valori di occupazione di un parcheggio, usano dati OSM come fonte di riferimento sottostante, va richiesta la condivisione dei dati dinamici?
  • file di modifica - Quando si condivide un database, la ODbL dice che occorre rendere disponibile “un file contenente tutte le modifiche… “, ma non è specifico. Che formato dovrebbe avere questo file?

Il LWG continuerà a lavorare sodo e discutere tali questioni con la comunità e i fruitori di dati. Se ritieni che di voler contribuire, ti chiediamo di contattare il LWG, aderire alla OSM Foundation e discutere lì, o partecipare alla discussione sulla mailing list giuridica. Saremo lieti di accogliere la opinione e portare avanti la conversazione.

traduzione di https://blog.openstreetmap.org/2014/08/06/at-the-edge-of-the-license/

mapgive a RadioMonteCarlo

Kay Rush ha parlato di Mapgive e Openstreetmap su RadioMonteCarlo. Mapgive è il progetto di sensibilizzazione nei confronti della preparazione alle emergenze a cura del Dipartimento di Stato USA, la cui traduzione e adattamento in italiano è stata curata da Cristian Consonni (con aiuto mio e della comunità italiana).

#code4italy SPARQL dati camera e scheda deputati

Sono convinto che i dati delle pubbliche amministrazione debbano essere accessibili in maniera chiara, il sito dati.camera.it rende disponibili 160M di dati, tramite un database interrogabile, una interfaccia SPARQL Virtuoso, essa è però difficilmente utilizzabile da non addetti ai lavori, questo è il motivo per cui ho scritto questa guida, semplice, per estrarre alcuni dati da tale database.

Come parte del mio contributo all’hackathon organizzata alla Camera dei Deputati il weekend del 17-18 Maggio 2014, ho estratto da dati.camera.it l’elenco degli attuali membri della Camera dei Deputati e ho fatto una mappa georiferita dei loro luoghi di nascita.

L’esercizio si propone di estrarre dati da SPARQL, leggerli in OpenRefine, fare geocoding delle città di nascita dei Deputati, effettuare una riconciliazione dei nomi usando con wikipedia tramite l’API di SpazioDati, poi pubblicare il tutto in una mappa umap su base OpenStreetMap.

Dettaglio: si parte da una chiamata SPARQL sul sito di dati.camera.it

SELECT DISTINCT 
  ?persona ?cognome ?nome ?dataNascita ?nato ?luogoNascita ?genere ?foto WHERE { ?persona ocd:rif_mandatoCamera ?mandato; a foaf:Person. ## deputato ?d a ocd:deputato; ocd:aderisce ?aderisce; ocd:rif_leg <http://dati.camera.it/ocd/legislatura.rdf/repubblica_17>; ocd:rif_mandatoCamera ?mandato. ##anagrafica ?d foaf:surname ?cognome; foaf:gender ?genere;foaf:firstName ?nome; foaf:depiction ?foto. 
    OPTIONAL{ ?persona <http://purl.org/vocab/bio/0.1/Birth> ?nascita. ?nascita <http://purl.org/vocab/bio/0.1/date> ?dataNascita; rdfs:label ?nato; ocd:rif_luogo ?luogoNascitaUri. ?luogoNascitaUri dc:title ?luogoNascita. 
    } 
}

eseguita su questo endpoint (otterrete un CSV – per visualizzare in HTML).

Creiamo un nuovo progetto OpenRefine, e alla sezione dati, facciamo cut&paste dell’URL sopra.

Come prima cosa, facciamo geocoding dei luoghi di nascita dei deputati: Posizioniamoci nella colonna “luogoNascita”, scegliamo di aggiungere una colonna alla tabella refine, ‘Add column…’ –> ‘Add column by fetching URLs ‘, e inserendo questo codice GREL:

'http://open.mapquestapi.com/nominatim/v1/search.php?' + 
'format=json&q=' + escape(value, 'url')

OpenRefine si collega al sistema di geocoding di openstreetmap e restituisce un JSON con le coordinate, inserendolo automaticamente nella colonna appena creata (a destra di quella selezionata).

Ora, estraiamo due colonne, una contentente la latitudine e l’altra contenente la longitudine. “Add column based on this column…”, ripetiamo due volte,

usando la prima volta:

value.parseJson()[0].lat

Questo la seconda:

value.parseJson()[0].lon

Otterremo il solo valore contenuto nella corretta struttura JSON e rappresentante latitudine e longitudine.

Posizioniamoci sulla colonna ‘dataNascita’ e facciamo click su  ‘Add column…’ –> ‘Add column based on this column… ‘, scegliamo un nome per la nuova colonna e inseriamo il seguente codice GREL, che formatterà in maniera opportuna la data di nascita, dal formato 19770704 al formato 04/07/1977:

value.slice(6, 8) + '/' + value.slice(4, 6) + '/' + value.slice(0, 4)

Ora separiamo il file in due, mettendo in un primo CSV solo deputati donna, e nell’altro i soli deputati uomo.

Utilizzando il tutorial di Matteo Brunati, usiamo le potenti funzionalità di estrazione semantica di SpazioDati per estrarre le pagine wikipedia relative ai singoli deputati. Dato un testo come input, il sistema trova le entità presenti (luoghi, persone, organizzazioni, etc.) e le collega alla corrispondente pagina Wikipedia. Potere dei linked data.

Infine caricando i dati ottenuti su umap, escportati in csv, su umap, si ottiene questo:

Visualizza a schermo intero

Otterremo una mappa con le due categorie uomo/donna selezionabili in maniera distinta, un picoclo motore di ricerca e link a pagina wikipedia.