fsfe-website/it/documents/commissione-meo-risposte.it...

<?xml version="1.0" encoding="iso-8859-1" ?>

<html>
  <head>
    <title>Risposte ufficiali della FSF Europe al questionario della Commissione Meo</title>
  </head>

  <body>

<center>
<h1>Indagine conoscitiva della Commissione per il software a codice sorgente aperto nella PA: le risposte della FSF Europe.</h1>
</center>

<p>
Di seguito sono pubblicate le risposte ufficiali della FSF Europe al
questionario della <a
href="http://www.governo.it/GovernoInforma/Dossier/open_source/index.html">Commissione
per il software a codice sorgente aperto nella Pubblica Amministrazione</a>,
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 <a href="commissione-meo-presentazione.html">audizione presso la
Commissione</a>.
</p>

<br></br>
<br></br>

<h2>Premessa</h2>

<h3>Cosa è il software libero</h3>

<p>
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:

<ul>
<li>libertà di utilizzo</li>
<li>libertà di studio</li>
<li>libertà di modifica</li>
<li>libertà di distribuzione</li>
</ul>
</p>

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

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

<ul>
<li>uso commerciale: il software libero si può vendere</li>
<li>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</li>
<li>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</li>
</ul>
</p>

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

<ul>
<li>rispetto delle quattro libertà fondamentali sopra citate</li>
<li>il programma eseguibile deve essere accompagnato dal codice sorgente</li>
<li>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)</li>
</ul>
</p>

<br></br>

<h2>
1 Qualità (affidabilità, documentazione, gestibilità)
</h2>

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

<p>
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.
</p>

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

<p>
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.
</p>

<h3>
1.3  Ritenete adeguata la documentazione dei pacchetti più importanti dei due
mondi?
</h3>

<p>
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.
</p>

<br></br>

<h2>
2 Manutenzione ed assistenza
</h2>

<h3>
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 ).
</h3>

<p>
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.
</p>

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

<p>
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.
</p>

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

<h3>
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?
</h3>

<p>
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.
</p>

<h3>
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?
</h3>

<p>
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.
</p>


<br></br>


<h2>
3 Sicurezza e liability
</h2>

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

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

<p>
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.
</p>

<p>
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.
</p>


<h3>
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?
</h3>

<p>
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).
</p>

<p>
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.
</p>

<p>
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.
</p>

<h3>
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?
</h3>

<p>
Una ricerca empirica (i risultati sono pubblicati sul sito
<a href="http://dweehler.com/why-os.html">http://dweehler.com/why-os.html</a>)
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.
</p>

<p>
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.
</p>

<h3>
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?
</h3>

<p>
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.
</p>


<br></br>


<h2>
4 Total cost of ownership
</h2>

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

<table>
  <tr>
    <td width="33%">&nbsp;</td>
    <td width="33%">Pacchetti proprietari</td>
    <td width="33%">Pacchetti open source</td>
  </tr>
  <tr>
    <td>Licenze software</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Hardware</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Software applicativo</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Gestione del software</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Costi per il supporto sistemistico</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Costi di formazione</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Servizi di outsourcing</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
  <tr>
    <td>Costi per interruzione del servizio</td>
    <td>&nbsp;</td>
    <td>&nbsp;</td>
  </tr>
</table>
</h3>

<p>
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.
</p>

<h3>
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è?
</h3>

<p>
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.
</p>

<p>
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.
</p>


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

<p>
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.
</p>

<h3>
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?
</h3>

<p>
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.
</p>


<br></br>


<h2>
5  Open Standard versus Open Source  Formati Aperti
</h2>

<h3>
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é?
</h3>

<p>
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).
</p>

<p>
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.
</p>

<br></br>


<h2>
6   Licensing
</h2>

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

<p>
Non abbiamo esperienze dirette.
</p>

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

<p>
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.
</p>

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

<p>
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.
</p>

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

<p>
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à.
</p>


<h3>
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?
</h3>

<p>
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.
</p>

<p>
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.
</p>

<p>
Oltre al Copyright Assignement, la FSF Europe ha recentemente attivato
un contratto simile (il <a
href="http://www.fsfeurope.org/projects/fla/fla.en.html">Fiduciary License
Agreement o FLA</a>) per affrontare e risolvere alcuni problemi e minacce per
il software libero:

<ul>
<li>per essere sicuri che il software libero sia usabile e difendibile legalmente
anche dopo che i suoi autori non siano più raggiungibili.</li>

<li>per difendere in modo efficace i programmatori minacciati e costretti su basi
legali a cambiare il nome del progetto o interrompere la distribuzione</li>

<li>per evitare che alcune aziende possano impadronirsi di codice libero scritto da
loro dipendenti e vendere versioni proprietarie di quel software</li>

<li>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.</li>
</ul>
</p>

<p>
Il FLA consente quindi di:

<ul>
<li>cambiare i termini di licenza di distribuzione del software, dovesse
rendersi necessario per questioni tecniche o legali</li>

<li>difendere il software da abusi, anche in tribunale, se necessario</li>

<li>proteggere gli autori di Software Libero, accettando di sobbarcarsi il rischio
di essere attaccati su basi legali</li>

<li>rappresentare un fattore di stabilizzazione e di armonizzazione in gruppi di
sviluppatori misti commerciali e commerciali/volontari.</li>
</ul>
</p>


<br></br>


<h2>
7   Impatto organizzativo e formazione
</h2>

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

<p>
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.
</p>

<h3>
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?
</h3>

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


<br></br>


<h2>
8 Valutazione sulle strategie di attuazione in ambito comunitario e
nazionale
</h2>

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

<p>
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.
</p>


<br></br>


<h2>
9   Università
</h2>

<h3>
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?
</h3>

<p>
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.
</p>

<h3>
9.2 Ritenete che l'OSS vada in qualche modo inserito nella scuola? In
caso affermativo specificare se come ambito di utilizzo pensate a:
<ul>
<li>A. il suo inserimento nei percorsi formativi scolastici</li>
<li>B. il suo utilizzo nella gestione delle infrastrutture tecnologiche</li>
</ul>
</h3>

<p>
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.
</p>

<p>
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.
</p>

<h3>
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)?
</h3>

<p>
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).
</p>

<h3>
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?
</h3>

<p>
Non ci sono i presupposti per una differenziazione.
</p>


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

<p>
Non abbiamo elementi per rispondere
</p>

<h3>
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?
</h3>

<p>
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.
</p>


<h3>
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?
</h3>

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

  </body>
  <timestamp>$Date$ $Author$</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->