Indagine conoscitiva della Commissione per il software a codice sorgente aperto nella PA: le risposte della FSF Europe.

Di seguito sono pubblicate le risposte ufficiali della FSF Europe al questionario della Commissione per il software a codice sorgente aperto nella Pubblica Amministrazione, istituita in Italia dal Ministro per l'Innovazione e le Tecnologie. È disponibile anche la trascrizione della presentazione svolta dalla FSF Europe nel corso della sua audizione presso la Commissione.

Premessa

Cosa è il software libero

Il software libero propone un modello commerciale per la distribuzione dell'informazione che aiuta a conservare e ad estendere il patrimonio intellettuale attraverso i quattro principi che esso rispetta:

• libertà di utilizzo
• libertà di studio
• libertà di modifica
• libertà di distribuzione

Requisito essenziale per l'applicazione di queste libertà è l'accesso al codice sorgente.

Si può in tranquillità affermare che il software libero si compone dei seguenti aspetti che lo rendono una realtà commerciale efficace:

• uso commerciale: il software libero si può vendere
• sviluppo commerciale: il software libero può essere modificato in base alle esigenze di uno specifico utilizzo e non esistono divieti alla retribuzione degli interventi di modifica
• distribuzione commerciale: personalizzazioni, servizi di supporto all'utente, manualistica sono solo alcuni esempi del valore aggiunto che può completare un'offerta legata al software libero. Il modello commerciale del software libero non si basa sulla vendita della licenza, come nel caso del software proprietario

Il vincolo alla diffusione del software libero è il mantenimento delle seguenti caratteristiche:

• rispetto delle quattro libertà fondamentali sopra citate
• il programma eseguibile deve essere accompagnato dal codice sorgente
• laddove presente, rispetto del copyleft (permesso d'autore, vincolo secondo il quale un programma che sia la modifica di uno precedente deve mantenerne la licenza)

1 Qualità (affidabilità, documentazione, gestibilità)

1.1 Quali sono i criteri di qualità che orientano la vostra scelta tra pacchetti software OS e commerciale?

Tutela degli investimenti e controllo degli strumenti software in uso, oltre alla corrispondenza con i principi etici di accesso alle informazioni e alla conoscenza. Il software rilasciato con licenze libere garantisce sempre queste caratteristiche.

1.2 Ritenete che i processi di produzione del software OS e di quello proprietario siano diversi? Come ritenete che impattino sulla qualità?

I processi creativi e di gestione del progetto non dipendono dalla licenza con cui questi programmi software vengono rilasciati. Quello che cambia notevolmente è il rapporto con l'utente/cliente: nel caso degli utenti di software proprietario il rapporto è di vassallaggio e di dipendenza dal fornitore monopolista, nel caso di software libero l'utente è libero di scegliere e di cambiare fornitore. La qualità non dipende dalla licenza con cui viene rilasciato il software.

1.3 Ritenete adeguata la documentazione dei pacchetti più importanti dei due mondi?

Come per la gran parte degli aspetti tecnici, non ci sono fondamentali differenze fra software libero e proprietario. I più noti e diffusi programmi, sia liberi che proprietari, hanno solitamente una documentazione adeguata. Non è possibile generalizzare.

2 Manutenzione ed assistenza

2.1 Ritenete che la diffusione di competenze tecniche per manutenzione ed assistenza sia adeguata alle esigenze del mercato dei pacchetti OS? (Se possibile e se necessario differenziare il caso del sistemista-gestore e quello del programmatore di una nuova applicazione ).

Attualmente il mercato delle piccole reti e dei prodotti da ufficio è orientato verso l'uso dei prodotti Microsoft, per cui è più facile trovare competenze a basso livello in questi campi con prodotti Microsoft.

Il contrario avviene nel mercato delle grosse reti e server, dove c'è una predominanza del software libero.

Tuttavia, questo tipo di competenze è estremamente volatile, e i tecnici del settore hanno bisogno di continui aggiornamenti, tanto che si può dire che un tecnico riscostruisce buona parte delle proprie competenze pratiche nell'arco di tre anni, mentre le conoscenze di base sono comuni a tutti i prodotti e hanno durata molto maggiore.

Di conseguenza, il mercato della manutenzione segue molto da vicino l'evoluzione del mercato, e le competenze seguono la richiesta.

2.2 Ritenete che la disponibilità del codice sorgente di un pacchetto da parte dell'utente finale sia un fattore di facilitazione per la manutenzione ed assistenza del software?

Sicuramente rappresenta un'opportunità in più, anche se avere accesso al codice sorgente è solo un prerequisito per godere dei diritti summenzionati. La manutenzione e l'assistenza su pacchetti software è possibile in regime concorrenziale soltanto se il sorgente è accompagnato dal diritto di uso, studio, modifica e ridistribuzione del codice.

2.3 Per quanto di vostra conoscenza, quali tutele sono offerte agli utenti di pacchetti nel caso in cui il fornitore non fornisca più la manutenzione e l'assistenza necessarie? Quali sono le vostre esperienze al riguardo?

Nel caso di software proprietario gli utenti dipendono soltanto dalle strategie commerciali del fornitore originario. Le licenze libere garantiscono invece la possibilità di affrancarsi dal monopolio di un produttore sul pacchetto acquistato e affidarsi anche a terzi per interventi di manutenzione, assistenza e aggiornamento. Non è possibile generalizzare.

3 Sicurezza e liability

3.1 Rispetto alle questioni sotto indicate, ritenete ci siano differenze tra i pacchetti OSS e quelli proprietari, e se si quali?

• Garanzia dell'assenza di back-door.
• Garanzia dell'assenza di funzionalità e modalità realizzative dannose e/o pericolose dal punto di vista della sicurezza.
• Garanzia di protezione dalle intrusioni, contaminazioni ed attacchi esterni.
• Rispondenza tra il software rilasciato ed i requisiti dellutente.

Non ci sono differenze tra i due tipi di licenze (libere o proprietarie) in esame: in entrambi i casi si tratta di software, sviluppato da esseri umani e passibile di ogni tipo di errore di programmazione e malfunzionamento.

Tuttavia punti a favore del software libero sono: la visibilità dell'intero codice sorgente, e la possibilità di esaminarlo, ricompilarlo, confrontarlo con il binario, apportarvi modifiche per la correzione e verifica.

3.2 Relativamente alla qualità del software dal punto di vista della sicurezza, quali ritenete siano i punti di forza e di debolezza dei pacchetti software commerciali e di quelli OS?

In questa domanda il software commerciale viene considerato qualcosa di diverso dal software libero. Respingiamo la posizione che il software libero non sia anche sfruttabile commercialmente (come specificato nella premessa).

Non ci sono differenze di principio tra software proprietario e libero, se non quelle citate sopra. Attualmente, la miglior difesa contro i difetti del software sembra essere la più ampia diffusione possibile del codice e la sua modificabilità. Queste caratteristiche consentono l'esame da parte di una vasta comunità di esperti e studiosi di sicurezza del software.

Il software libero inoltre può essere migliorato ed eventuali malfunzionamenti corretti, non solo dal produttore monopolista, ma anche da terzi, autonomamente da chi li scopre o anche dal produttore originario.

3.3 Quali ritenete siano le differenze nei pacchetti OSS e in quelli proprietari in relazione alla tempestività delle correzioni a seguito di alert di sicurezza?

Una ricerca empirica (i risultati sono pubblicati sul sito http://dweehler.com/why-os.html) ha misurato il tempo medio di reazione tra la pubblicazione di una vulnerabilità e il rilascio di una patch; RedHat è risultata essere stata la più veloce nell'anno delle misurazioni con una media di 6 giorni, seguita da Microsoft e Sun Microsystems.

Benché questo studio potrebbe essere poco rigoroso, restano segnali forti che la tempestività dei maggiori e più importanti progetti liberi rispetto a segnalazioni di insicurezze sia più elevata.

3.4 Nell'eventualità si verificasse una vulnerabilità del software quali ritenete siano le differenze per la gestione e risoluzione del problema nei pacchetti OSS e in quelli proprietari?

Non è possibile generalizzare, ma la differenza fondamentale tra software libero e non è che, nel caso di software libero, se gli autori originari o i reponsabili del software non sono abbastanza tempestivi o accurati è possibile rivolgersi a terze parti.

4 Total cost of ownership

4.1 Sulla base della vostra esperienza quanto pensate incidano percentualmente, le seguenti voci relative all'ownership di pacchetti software?

	Pacchetti proprietari	Pacchetti open source
Licenze software
Hardware
Software applicativo
Gestione del software
Costi per il supporto sistemistico
Costi di formazione
Servizi di outsourcing
Costi per interruzione del servizio

Non è possibile rispondere a questa domanda, se non facendo delle generalizzazioni significative. I costi di licenze possono essere significativi nelle strutture scolastiche o insignificanti in aziende dove i costi di outsourcing e consulenze sono altissimi.

4.2 Siete in grado di specificare se il TCO di un pacchetto OSS sia mediamente più alto o più basso del TCO di un pacchetto proprietario di pari funzionalità? Di quanto e perchè?

Non si può calcolare il TCO di un solo pacchetto, ma deve essere calcolato sull'intero sistema informativo aziendale, nell'arco di 3/5 anni (tempi standard di ammortamento) considerando che in tale arco di tempo le condizioni di licensing possono variare considerevolmente nel caso di software non libero.

Vale la considerazione che in un mercato aperto e concorrenziale i prezzi sono fisiologicamente più bassi che in mercati chiusi e monopolistici. Solo con il software libero è possibile realizzare un mercato aperto e concorrenziale, per cui riteniamo che nel medio periodo sicuramente il TCO di sistemi basati su software libero sarà più basso.

4.3 Su quali voci e quanto pensate incidano i costi ed i tempi di migrazione da un pacchetto all'altro?

Incidono sulla formazione del personale, sia utente che addetto alla manutenzione. Tali voci di costo sul breve periodo, si trasformano in valore per l'azienda (maggiore capacità e indipendenza nella risoluzione di problemi) i cui frutti si mantengono nel tempo: l'utente/cliente diventa infatti "proprietario" del software acquisito e decide autonomamente le politiche di aggiornamento, manutenzione.

4.4 Come ritenete di realizzare il ritorno degli investimenti qualora decidiate di migrare da un pacchetto ad un altro? Ritenete ci siano ulteriori costi da tenere in considerazione in caso di migrazione? Quali?

Il ROI (Return Of Investment) dipende molto dal tipo di soluzione che si sta implementando. La possibilità di rendersi indipendenti dal produttore monopolista e attingere ad un mercato concorrenziale di fornitori di servizi è un fattore a favore di un rapido ROI.

5 Open Standard versus Open Source ­ Formati Aperti

5.1 Ritenete che la disponibilità del codice sorgente di un pacchetto sia un valore aggiunto rilevante per garantire l'interoperabilità delle applicazioni interamministrative? Perché?

Sì, anche in mancanza di tutte le libertà summenzionate, perchè permette comunque di verificare la corrispondenza tra lo standard così come documentato e l'implementazione particolare. Senza accesso al codice sorgente ci si può solo affidare a costose operazioni di reverse-engineering (a volte impossibili tecnicamente).

Ciò che è importante è che il formato di interscambio di dati sia documentato e liberamente utilizzabile da chiunque senza limitazioni per poter garantire interoperabilità anche legale, oltre che tecnica.

6 Licensing

6.1 Quali sono le vostre esperienze nella gestione delle problematiche di licensing per pacchetti proprietari (per esempio, trasferibilità delle licenze)?

Non abbiamo esperienze dirette.

6.2 Quali sono a vostro avviso le forme di licensing che potrebbero essere adottate per l'acquisizione di pacchetti su licenza?

La pubblica amministrazione dovrebbe sempre reclamare il possesso di tutto il software in uso presso di essa, per tutelare la res publica: possesso dei sorgenti leggibili e modificabili, con annessa documentazione e permesso legale di modifica e distribuzione interna.

6.3 Quali sono i vantaggi e gli svantaggi di una estensione del brevetto al comparto del software come recentemente deliberato negli USA?

I vantaggi sarebbero delle aziende d'oltreoceano e giapponesi che vedrebbero il loro portfolio di brevetti legalizzato anche in Europa e potrebbero completare il processo di distruzione delle imprese europee ed italiane.

Gli svantaggi per le aziende nazionali sono legati alla ingiustificabilità razionale del brevetto sulle idee astratte, ampiamente illustrato nell'articolo che alleghiamo.

Vale la pena sottolineare come invece negli USA il sistema brevettuale sia sottoposto a pesanti critiche da parte di economisti indipendenti che hanno dimostrato la nocività del brevetto sulle idee (software e pratiche commerciali), mentre mancano completamente studi economici altrettanto indipendenti che ne dimostrino la validità.

6.4 Nel caso di acquisizione/manutenzione di software custom su commessa, i contratti da voi siglati prevedono l'acquisizione della proprietà piena (anche se magari non esclusiva) del codice sorgente prodotto?

Affinché un pacchetto software venga incorporato nel progetto GNU, l'autore o gli autori originali devono cedere volontariamente il copyright e i diritti di sfruttamento esclusivo dell'opera alla Free Software Foundation. Attraverso un contratto noto come Copyright Assigment gli autori di software libero assicurano volontariamente manutenibilità legale al proprio programma.

Diversamente dal software proprietario, i cui diritti esclusivi sono detenuti da una sola azienda e solitamente lo stesso software ha una durata limitata a pochi anni, con il software libero la titolarità dei diritti è distribuita tra gli autori; lo stesso progetto GNU ha anche lo scopo di durare a lungo nel tempo. Queste esigenze fanno sì che sia necessario avere un controllo centralizzato per poter manutenere legalmente nel tempo i pacchetti software più importanti. La FSF si impegna a non rendere mai proprietario il software di cui acquisisce i diritti.

Oltre al Copyright Assignement, la FSF Europe ha recentemente attivato un contratto simile (il Fiduciary License Agreement o FLA) per affrontare e risolvere alcuni problemi e minacce per il software libero:

• per essere sicuri che il software libero sia usabile e difendibile legalmente anche dopo che i suoi autori non siano più raggiungibili.
• per difendere in modo efficace i programmatori minacciati e costretti su basi legali a cambiare il nome del progetto o interrompere la distribuzione
• per evitare che alcune aziende possano impadronirsi di codice libero scritto da loro dipendenti e vendere versioni proprietarie di quel software
• per garantire la libertà del software per 20 e più anni, dato che nessun'azienda potrebbe mai garantire altrettanto, visto che potrebbe fallire o essere costretta da dinamiche di mercato a modficare le sue policy.

Il FLA consente quindi di:

• cambiare i termini di licenza di distribuzione del software, dovesse rendersi necessario per questioni tecniche o legali
• difendere il software da abusi, anche in tribunale, se necessario
• proteggere gli autori di Software Libero, accettando di sobbarcarsi il rischio di essere attaccati su basi legali
• rappresentare un fattore di stabilizzazione e di armonizzazione in gruppi di sviluppatori misti commerciali e commerciali/volontari.

7 Impatto organizzativo e formazione

7.1 Ritenete che l'adozione di pacchetti OSS imponga alle organizzazioni coinvolte un particolare riassetto organizzativo delle strutture ICT?

Non meno e non di più dell'adozione di pacchetti genericamente diversi da quelli usati abitualmente dal personale della PA. Diverso è invece il discorso per l'acquisizione di servizi di aggiornamento e manutenzione: nel caso di software libero essi saranno disponibili da fornitori in un mercato concorrenziale. Di questo fattore dovranno tenere conto i bandi per l'acquisizione di software per la PA.

7.2 Ritenete che l'adozione di pacchetti OSS rispetto al software proprietario imponga specifiche attività formative nell'ambito delle pubbliche amministrazioni e delle aziende coinvolte? Quali?

Proprietario o libero non ci sono differenze se si tratta di fare formazione su strumenti nuovi o diversi per gli utenti.

8 Valutazione sulle strategie di attuazione in ambito comunitario e nazionale

8.1 A vostro giudizio, quale potrebbe essere il ruolo del software OS nei programmi comunitari e nazionali?

Ci auguriamo che il software libero in Italia e in Europa continui ad avere il ruolo di locomotiva trainante per la creazione di un mercato di competenze locali; che continui ad essere considerato un obiettivo primario come nel VI Programma Quadro comunitario e nelle Raccomandazioni del MIUR, per il rilancio di un'industria tecnologica d'avanguardia locale.

9 Università

9.1 La valenza dell'ICT nell'ambito della cultura scientifica è un tema controverso. Ritenete che lo sviluppo dell'OSS comporti una qualche implicazione nella cultura scientifica e nei meccanismi di trasmissione di essa o sia esclusivamente un fatto tecnologico?

Il software libero è un'esigenza culturale oltre che tecnologica. Si dibatte sulla doppia valenza del software, sia strumento che informazione pura: pensiamo che, al di là dei sofismi, non sia oggetto di dibattito l'assunto che per il progresso è assolutamente necessaria la diffusione di conoscenza. Nel campo tecnologico e del software in particolare, solo il software libero consente un vasto flusso di conoscenza che si trasforma in progresso e innovazione. Nel progetto GNU e più ampiamente come software libero, si possono reperire programmi che hanno realizzato innovazioni non solo incrementali, ma anche radicali. Ad esempio, il compilatore gcc (GNU Compiler Collection) è l'unico compilatore esistente sul mercato in grado di accettare decine di linguaggi di programmazione in input e produrre codice macchina per quasi tutte le piattaforme hardware esistenti. Il progetto Mozilla (benché noto solo per il browser) ha innovato radicalmente, realizzando ex-novo qualcosa che prima non esisteva: un framework cross-platform per la realizzazione di applicazioni basate su internet. La stessa Internet è nata e prospera come fenomeno commerciale, grazie alla conoscenza diffusa dei protocolli, delle applicazioni e alle implementazioni libere degli stack TCP/IP. Le implementazioni di protocolli di rete proprietarie, pur migliori tecnicamente, non hanno mai trovato spazio e non si sono mai imposte sul mercato.

9.2 Ritenete che l'OSS vada in qualche modo inserito nella scuola? In caso affermativo specificare se come ambito di utilizzo pensate a:

• A. il suo inserimento nei percorsi formativi scolastici
• B. il suo utilizzo nella gestione delle infrastrutture tecnologiche

Il software libero deve essere inserito nei percorsi formativi scolastici per i motivi succitati e per accellerare il processo di creazione del pool di esperti cui il mercato può attingere.

Dal punto di vista formativo, poi, nelle aree didattiche tecnologiche il software libero è l'unico che consente di apprendere le basi tecniche del funzionamento di: sistemi operativi, compilatori, interpreti, interfacce grafiche, database e tutti i componenti di un sistema informativo, dato che le licenze con cui è distribuito consentono espressamente lo studio e l'adattamento alle esigenze dell'utente.

9.3 Quali i punti di forza e/o di debolezza dell'uso dell'OSS nella scuola (specificare con riferimento all'ambito A e B)?

Se gli ambiti A e B sono riferiti ai punti della domanda 9.2, allora non ci sono motivi per scegliere software proprietario nella scuola. Siamo convinti che l'uso di software proprietario nella scuola sia in realtà una forma di "ammaestramento", ovvero una sostituzione alla formazione su strumenti specifici e non creazione di cultura (che è invece il compito di una scuola moderna in uno stato altrettanto moderno).

9.4 Ritenete che gli interventi di formazione su OSS debbano essere diversi da quelli previsti altrimenti? In caso affermativo in cosa ritenete si debbano differenziare?

Non ci sono i presupposti per una differenziazione.

9.5 Nell'ambito della vostra università sono previsti programmi di ricerca sul software OS? Se si', con quali obiettivi scientifici?

Non abbiamo elementi per rispondere

9.6 La diffusione del software OS potrebbe favorire, ostacolare o essere sostanzialmente marginale rispetto alla crescita di un'industria nazionale del software ? Per quali motivi?

Non può che favorire una crescita del settore tecnologico nel suo complesso. L'abbassamento delle barriere all'ingresso sul mercato sfruttando l'enorme quantità di software di alta qualità esistente favorisce l'aumento di soggetti in grado di differenziarsi per copertura geografica, qualità di servizi. Sarebbe comunque interessante studiare la situazione attuale del mercato del software in Italia, che basandoci su esperienze dirette, sembra essere formata principalmente da due tipi di aziende: quelle che sviluppano software su commessa o sviluppano soluzioni verticali e quelle che distribuiscono soluzioni in scatola vendendo servizio. Se fosse dimostrata tale situazione, con la diffusione di software libero entrambi i tipi di aziende potrebbe continuare a fare affari senza mutare considerevolmente il proprio modello commerciale, con l'effetto positivo di ridurre considerevolmente il drenaggio di capitali verso gli USA dovuto al pagamento sterile di licenze.

9.7 Siete favorevoli all'avvio di un programma nazionale di ricerca applicata sull'OSS, in particolare il programma dovrebbe focalizzarsi sui modelli di business per sw OS ovvero sullo sviluppo di nuove linee di strumenti sw OS?

Siamo favorevoli e ci candidiamo fin da ora a seguirne i passi in qualità di esperti in materia.