Ciampa
Nel documento si parla di free-software, software libero e open source. I primi due termini sono equivalenti. Chiarendo che software libero è la traduzione italiana di free-software, direi di usare il termine inglese solo per chiarire la traduzione e poi continuare con quello italiano.
Ciampa
Nel documento si parla di free-software, software libero e open source. I primi due termini sono equivalenti. Chiarendo che software libero è la traduzione italiana di free-software, direi di usare il termine inglese solo per chiarire la traduzione e poi continuare con quello italiano.
Visto che il termine software libero è piu ‘ristretto’ e (e all’atto pratico equivalente) forse anche più adatto per la PA, direi che si evita confusione ad adottare solo quest’ultimo. Sostituirei quindi il termine ‘filosofia open source’ con ‘filosofia del software libero’.
Idem come sopra per la frase: “free software e open source significano:” -> “software libero significa:”
aggiungerei alla frase “Francia e Germania” anche la Spagna, visto l’esempio della regione di Extremadura
articolato (id2) capo 3 -> rif. art.5
Che significa ‘detenere il codice sorgente’? Se detenere significa averne una copia con il diritto di modifica e divulgazione, la frase va bene. Se esprime proprietà, no. La proprietà non da’ alcuna garanzia aggiuntiva ma semmai ne toglie. E’ sufficente che il codice sia libero senza detenerlo.
Mauro
Sono d’accordo con Marco, a mio avviso nel testo andrebbe utilizzato solo il termine “Software Libero” senza duplicazioni e fraintendimenti, nessun riferimento a Open Source o Free Software, chiamiamo le cose col loro nome. Inoltre discutendo con i miei colleghi abbiamo rilevato la totale assenza di riferimenti a una standardizzazione dei formati (naturalmente liberi).
Dovrebbero innanzitutto essere definiti dei formati liberi per le rappresentazioni dei dati piu’ comuni come documenti, immagini, disegni tecnici, pagine web ecc., dei protocolli di comunicazione e dei file di interscambio (xml piuttosto che hl-7).
Una commissione tecnica potrebbe prendersi carico di valutare i formati esistenti e trovare quelli piu’ adatti, il software adottabile da una PA deve necessariamente permettere la lettura di questi formati, nel caso vengano in futuro adottati dei formati diversi il software deve fornire i mezzi per la conversione nei nuovi formati, non basta dire che i formati siano liberi, ma devono essere anche standard.
Inoltre non esiste che vengano utilizzati dei formati proprietari, si puo’ in alcuni casi (se non c’e’ libero non c’e’:) utilizzare del codice proprietario ma il formato dei dati deve essere libero.
Ci sono anche degli errori nei riferimenti degli articoli e un paio di frasi poco chiare, ne possiamo discutere in riunione, li ho segnati su carta;)
es: all’art.5 comma 1 Capo III si dice che il fornitore deve consentire la modificabiltà del codice sorgente senza costi aggiuntivi per l’amministrazione, cosa si vuol dire? in un’altro punto si parla di gratuità, credo sia scorretto.
Oltre alle esperienze europee (e citerei il fatto che sono europee:) aggiungerei altri esempi pratici nel mondo.
Quando si parla giustamente di pubblicare in formato elettronico gli atti specificherei anche che i siti devono attenersi agli standard di fruibilita’, probabilmente ci sono gia’ delle indicazioni a livello nazionale, sarebbe il caso di prendere spunto da altre iniziative simili potremmo farne riferimento in questa pagina per poterle consultare, ad esempio:
Marco (mercutio)
Necessaria premessa, IANAL. Tuttavia, mi sembra fondamentale che il LT si proponga su queste tematiche come interlocutore serio e preparato. Le competenze giuridiche (forse) ci mancano – ma direi che non è questo il nostro ruolo – non certo le competenze sul dominio e, credo, le buone idee in questo campo.
Di seguito delle note, più che dei commenti, alla proposta di legge.
Cronologia
Una delle prime proposte di legge in questa direzione (la prima?) sembra essere quella del senatore Cortiana, datata 26/2/2002. E’ seguita dopo poco da un disegno di legge presentato alla Camera a firma Folena, datato 20/3/2002. Questo è sostanzialmente identico alla proposta Cortiana, con un paio di aggiunte interessanti. A livello locale, ho rintracciato una proposta della regione Emilia-Romagna, datata 7/6/2002, che è essenzialmente una versione sfrondata di alcuni passi delle due precedenti.
Il DDL di Bondi è sostanzialmente una riproposizione della proposta Emilia-Romagna e quindi della proposta Cortiana e Folena. Da Folena sono riproposti anche alcune parti della relazione accompagnatoria.
Domanda ovvia: nei due anni che intercorrono tra la proposte originarie e quella qui in esame, è cambiato qualcosa? Che lezioni sono state prese dalle esperienze passate? Cosa ha funzionato? Cosa no? Come tradurlo nella proposta di legge?
Aspetti generali
Non si accenna alla questione dell’e-voting sulla quale tanto si dibatte di questi tempi negli US (basta dare un’occhiata su Slashdot ogni tanto) e che probabilmente presto o tardi verrà proposta anche da noi. E’ evidente che soprattutto in questo caso si deve usare software libero.
Non mi dispiacerebbe vedere una norma che preveda che software sviluppato da enti pubblici debba essere rilasciato con licenze compatibili col free software. La logica dietro questo è che software sviluppato con soldi pubblici dovrebbe tornare utile all’intera comunità. Un esempio/precedente è il sistema di licensing adottato dalla Università della California. Nota che questo è diverso da quanto proposto all’articolo 6.
Aspetti particolari
Nella relazione accompagnatrice si dice che “la diffusione di sistemi operativi liberi andrà sostenuta…”. Perché solo dei sistemi operativi, termine che nell’accezione comune identifica solo alcuni componenti di un sistema informatico?
Dall’articolo 1, sparisce il cenno a particolari diritti di cui gode la cessione gratuita di software libero che invece è presente in Folena. Cosa diceva in particolare? Perché eliminata?
Nell’articolo 2, comma 3, viene fornita la definizione di “programma per elaboratore a codice sorgente aperto”. Nota che, nonostante l’apparente somiglianza, il concetto è ben diverso da quello di software open source! Attenzione quindi a interpretare correttamente il seguito.
L’articolo 3 di Folena (“Diritto allo sviluppo portabile”) è assente. Sembra invece estremamente importante, soprattutto alla luce di politiche aggressive di certi produttori software. Per esempio, se il diritto allo sviluppo portabile non è garantito, potrebbe risultare impossibile passare da un software proprietario ad un analogo libero perché illegale svilupparlo o distribuirlo. Insomma, la parte di “diritto allo sviluppo portabile” annunciate nel titolo del capo è del tutto assente nel testo della legge.
Articolo 4, comma 4: importante capire cosa dice l’art. 33 Dlgs 30/6/2003 n 196. Per esempio, se richiede certificazione estremamente onerosa, determinata struttura societaria…
Articolo 5, comma 1: basta detenere il codice del programma che si usa? Che diritti si hanno garantiti? Così come è la proposta, nessuno. Articolo 5, comma 2, aggiunge il diritto alla modificabilità senza costi aggiuntivi. Ci basta? Scenario: una grande azienda monopolistica fornisce alla PAT un software proprietario e il corrispettivo codice insieme al diritto alla modificabilità ma nessun altro diritto. Ci sta bene? Che succede se dopo N anni il fornitore toglie diritto alla modificabilità? Che possibilità ci sono di trovare un equivalente sistema libero? Qui sembra particolarmente importante la presenza dell’articolo 3 di Folena (sviluppo portabile).
Perché è stato tagliato l’articolo 6, comma 3, di Folena (obbligo di motivazione analitica di scelta di software non libero)? Perché tagliato l’articolo 6, comma 4, di Folena (risposta patrimoniale del responsabile della scelta non appropriata di software non libero)? In questo modo, sono state eliminate le già fragili misure minime di responsability e accountability previste in Folena.
Un altro articolo interessante presente in Folena e non riproposto è l’11, che prevede l’istituzione di un “fondo per la diffusione del software libero”. Perché non prevedere anche azioni di incentivo per chi rilascia proprio prodotto con licenza free (sconti fiscali, etc.). Nota che questo mi sembra diverso da quanto affermato nell’articolo 6.
Mario A. Santini
Articolo 2 Eviterei di usare definizioni specifiche quali “software libero”, “software a sorgente aperto”, “software proprietario”… Io direi che il software utilizzato dalla provincia deve corrispondere alla definizione di software libero, riportando però i 4 principi della GPL, ma non la sua definizione. L’etichetta potrebbe apparire discriminatoria, mentre i singoli punti sono sostenibili da ragioni valide e possono essere spiegati dando una panoramica più concreta del concetto.
Articolo 3.1 Non si dà una definizione di formato libero.
Articolo 3.2 Pare ovvio che i formati utilizzati principalmente, per la diffusione e l’archiviazione, devono essere formati liberi. Non è pensabile che uffici o enti utilizzino formati proprietari. Rimane altresì ovvio che quanto c’è non è possibile modificarlo dall’oggi al domani e che occorra approntare un gruppo di lavoro a livello provinciale al fine di favoride la migrazione.
Articolo 5.2 Io credo che vada detto chiaro che i programmi utilizzabili dalla pubblica amministrazione devono essere :
- a sorgente aperto.
- a sorgente modificabile
- redistribuibile
- le modifiche eventuali sono redistribuibili
Il resto sul privilegio o meno non ha senso, almeno per lo scopo di questa legge.