[Gfoss] Fwd: [geo-discuss] Another license for geodata: PGL (Public Geodata License)

Bud P. Bruegger bud at comune.grosseto.it
Thu Feb 16 14:49:27 CET 2006


At 12.23 16/02/2006 +0100, strk wrote:
>On Thu, Feb 16, 2006 at 11:49:16AM +0100, Bud P. Bruegger wrote:
> > At 17.30 15/02/2006 +0100, strk wrote:
>
> > >Grazie per l'interessamento, e' raro trovare qualcuno
> > >all'interno delle istituzioni che prenda a cuore la liberta'
> > >dei dati.
> >
> > Ogni tanto qualcuno del mono open source finisce in una istituzione
> > ;-).  Aparte di questo, ho fatto un gran parte della mia esperienza GIS 
> nei
> > Stati Uniti dove dati sono molto piu' accessibile di qui--e ho visto gli
> > vantaggi con i miei occhi...
>
>Questo ti rende un ottimo candidato per scrivere qualcosa sull'argomento :)
>
> > * in riassunto, dati geografici sono molto piu' incassinati che software e
> > il concetto di un singolo "sorgente" e difficile applicare.
>
>In generale, l'attivita' che la licenza GPL tenta di impedire e'
>la redistribuzione proprietaria di un derivato da un "software" libero.

Questo, perche la compilazione in un binario "chiude" molti aspetti 
fondamentali del sw che sono sempre contenuti (come comportamento), ma non 
piu' ispezionabile.

Mi chiedo se dati geografici abbiano una caratteristica del genere.  Mi 
sembra difficile di "chiudere" dati in un modo--al meno se non si tenta di 
trasformare dati in software (che incorpora il dati ma puo essere compilato 
in modo che i dati non siano piu' accessibile come dati).

>Faccio un esempio: qualcuno prende dei vettori distribuiti con una
>licenza libera, li rasterizza e distribuisce i raster senza licenza
>di redistribuzione. Certo, il processo di rasterizzazione puo'
>essere molto complesso ed aggiungere molto valore al dato originale,
>tuttavia probabilmente si puo' ancora parlare di prodotto "derivato".
>Una licenza "virale" al pari della GPL dovrebbe imporre la stessa
>licenza libera a tutti i prodotti intermedi, laddove distribuiti.

Il "virale" come "policy action" mi sembra vada molto bene per tanti 
scopi:  aumenta la disponibilità di dati e l'uso di dati per decisioni 
migliori.  Pero' a questo punto, si deve rendersi conto che "virale senza 
compromesso"  limita' gli possibili usi.

Un esempio e' che si fa una analisi che prende due insieme di dati come 
input:  uno libero virale, uno chiuso proprietario (per decisione del 
producente dei dati, non del analista).  Una viralita' assoluta' divieta di 
fare tali analisi che combinano dati liberi con quelli chiusi.

Questo puo' essere un problema.  Ad esempio, se una Ente Pubblica ha il 
monopolio (istituzionale) di produrre un certo dato, non e' proponibile di 
limitare i suoi usi alla combinazione solo con altri dati liberi.  Molti 
analisi importanti e urgenti magari includono dati proprietari per forza.

Una via di uscita e' mettere a disposizione i dati sotto due licenze:  una 
a pagamento che permette combinazione con dati proprietari, una libero per 
combinazione con dati liberi.

Anche questo puo' pero' avere effetti indesiderati.  Assumiamo che qualche 
gruppo di ricercatori vorrebbe usare dati geografici a scopi nobili, senza 
lucro, ecc.  Assumiamo anche che per forza devono includere qualche dato 
proprietario.  A questo punto sarebbero puniti per la decisione di terzi di 
tenere i loro dati proprietari.

Non so come risolvere questo problema, ma il puramente virale non mi sembra 
l'approccio proponibile a Enti Pubblici.

>Ovvero: rilascia i prodotti derivati con licenza libera o non usare
>questi dati affatto.
>Ovviamente un'azienda che faccia trattamento di dati geografici potrebbe
>tenere per se' (non distribuire) i prodotti delle fasi intermedie, ma
>comunque il prodotto *distribuito* dovrebbe essere libero (modificabile,
>ridistribuibile, utilizzabile).

Ok, solo quando si distribuisce forse va bene.  Penso di applicarlo solo 
per distribuzione ha la radice nel fatto che le licenze di sw libero si 
basano sul copyright law che non parla del uso..  Molto probabilmente, si 
deve seguire la stessa strada per dati geografici.

>Il sorgente davvero serve soltanto per rendere possibile la "modifica",
>ovvero l'adattamento a specifiche esigenze. Va da se' che una mappa
>topografica, con strade e punti d'interesse rappresentati da simboli
>non puo' essere modificata se non si hanno i vettori. In questo caso
>quale sia il sorgente dovrebbe essere piu' facile dirlo.

Ma a questo punto magari bastano metadati che puntano sul sorgente dei dati 
da quale e' stato derivato il prodotto.  Vedi commento su metadati e 
lineage nel altra mail..

>Un'altra cosa sono le foto aeree. In quel caso si potrebbe applicare
>una licenza diversa, che non preveda l'esistenza di "sorgenti".
>
>Ti rifaccio la domanda (o ho dimenticato di fartela prima):
>Che tipo di dati produce il comune di Grosseto ?
>Credo sia utile discutere di un caso specifico.

Un Comune puo avere una cartografia di base che proviene da un volo 
fotogrammetrico.  In caso nostro e' stato gestito dalla regione e devo 
verificare che il copyright sia veramente nostro.

Poi produciamo dati come zonificazioni (piano regolatore ..), ecc. fino a 
dati sulle infrastrutture che noi gestiamo direttamente (ad es., fognature..)

Alcuni sono (penso, che non mi intendo dei aspetti legali) per forza 
pubblici  (ad es. zonificazione), altri non necessariamente (reti 
tecnologici) e magari in alcuni casi ci sarebbero oppure preoccupazioni di 
sicurezza di pubblicare la posizione preciso di entita' vulnerabili...  (ma 
spero che quest'ultimo e' un ragionamento puramente academico).

saluti
-b


>--strk;


-------------------------------------------------------------------------------------------------
Ing. Bud P. Bruegger, Ph.D.                 +39-0564-488577 
(voice),  -21139 (fax)
Servizio Elaborazione Dati                    e-mail:  bud at comune.grosseto.it
Comune di Grosseto                            jabber:  bud at jabber.no
Via Ginori, 
43                                      http://www.comune.grosseto.it/cie/
58100 Grosseto (Tuscany, 
Italy)           http://www.comune.grosseto.it/interopEID/ 




More information about the Gfoss mailing list