Source files of fsfe.org, pdfreaders.org, freeyourandroid.org, ilovefs.org, drm.info, and test.fsfe.org. Contribute: https://fsfe.org/contribute/web/ https://fsfe.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

commissione-meo-risposte.it.xhtml 24KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766
  1. <?xml version="1.0" encoding="iso-8859-1" ?>
  2. <html>
  3. <head>
  4. <title>Risposte ufficiali della FSF Europe al questionario della Commissione Meo</title>
  5. </head>
  6. <body>
  7. <center>
  8. <h1>Indagine conoscitiva della Commissione per il software a codice sorgente aperto nella PA: le risposte della FSF Europe.</h1>
  9. </center>
  10. <p>
  11. Di seguito sono pubblicate le risposte ufficiali della FSF Europe al
  12. questionario della <a
  13. href="http://www.governo.it/GovernoInforma/Dossier/open_source/index.html">Commissione
  14. per il software a codice sorgente aperto nella Pubblica Amministrazione</a>,
  15. istituita in Italia dal Ministro per l'Innovazione e le Tecnologie. È
  16. disponibile anche la trascrizione della presentazione svolta dalla FSF Europe
  17. nel corso della sua <a href="commissione-meo-presentazione.html">audizione presso la
  18. Commissione</a>.
  19. </p>
  20. <br></br>
  21. <br></br>
  22. <h2>Premessa</h2>
  23. <h3>Cosa è il software libero</h3>
  24. <p>
  25. Il software libero propone un modello commerciale per la distribuzione
  26. dell'informazione che aiuta a conservare e ad estendere il patrimonio
  27. intellettuale attraverso i quattro principi che esso rispetta:
  28. <ul>
  29. <li>libertà di utilizzo</li>
  30. <li>libertà di studio</li>
  31. <li>libertà di modifica</li>
  32. <li>libertà di distribuzione</li>
  33. </ul>
  34. </p>
  35. <p>
  36. Requisito essenziale per l'applicazione di queste libertà è l'accesso al
  37. codice sorgente.
  38. </p>
  39. <p>
  40. Si può in tranquillità affermare che il software libero si compone dei
  41. seguenti aspetti che lo rendono una realtà commerciale efficace:
  42. <ul>
  43. <li>uso commerciale: il software libero si può vendere</li>
  44. <li>sviluppo commerciale: il software libero può essere modificato in base
  45. alle esigenze di uno specifico utilizzo e non esistono divieti alla
  46. retribuzione degli interventi di modifica</li>
  47. <li>distribuzione commerciale: personalizzazioni, servizi di supporto
  48. all'utente, manualistica sono solo alcuni esempi del valore aggiunto
  49. che può completare un'offerta legata al software libero. Il modello
  50. commerciale del software libero non si basa sulla vendita della
  51. licenza, come nel caso del software proprietario</li>
  52. </ul>
  53. </p>
  54. <p>
  55. Il vincolo alla diffusione del software libero è il mantenimento delle
  56. seguenti caratteristiche:
  57. <ul>
  58. <li>rispetto delle quattro libertà fondamentali sopra citate</li>
  59. <li>il programma eseguibile deve essere accompagnato dal codice sorgente</li>
  60. <li>laddove presente, rispetto del copyleft (permesso d'autore, vincolo
  61. secondo il quale un programma che sia la modifica di uno precedente
  62. deve mantenerne la licenza)</li>
  63. </ul>
  64. </p>
  65. <br></br>
  66. <h2>
  67. 1 Qualità (affidabilità, documentazione, gestibilità)
  68. </h2>
  69. <h3>
  70. 1.1 Quali sono i criteri di qualità che orientano la vostra scelta tra
  71. pacchetti software OS e commerciale?
  72. </h3>
  73. <p>
  74. Tutela degli investimenti e controllo degli strumenti software in uso,
  75. oltre alla corrispondenza con i principi etici di accesso alle
  76. informazioni e alla conoscenza. Il software rilasciato con licenze
  77. libere garantisce sempre queste caratteristiche.
  78. </p>
  79. <h3>
  80. 1.2 Ritenete che i processi di produzione del software OS e di quello
  81. proprietario siano diversi? Come ritenete che impattino sulla qualità?
  82. </h3>
  83. <p>
  84. I processi creativi e di gestione del progetto non dipendono dalla
  85. licenza con cui questi programmi software vengono rilasciati. Quello
  86. che cambia notevolmente è il rapporto con l'utente/cliente: nel caso
  87. degli utenti di software proprietario il rapporto è di vassallaggio e
  88. di dipendenza dal fornitore monopolista, nel caso di software libero
  89. l'utente è libero di scegliere e di cambiare fornitore. La qualità
  90. non dipende dalla licenza con cui viene rilasciato il software.
  91. </p>
  92. <h3>
  93. 1.3 Ritenete adeguata la documentazione dei pacchetti più importanti dei due
  94. mondi?
  95. </h3>
  96. <p>
  97. Come per la gran parte degli aspetti tecnici, non ci sono fondamentali
  98. differenze fra software libero e proprietario. I più noti e diffusi
  99. programmi, sia liberi che proprietari, hanno solitamente una
  100. documentazione adeguata. Non è possibile generalizzare.
  101. </p>
  102. <br></br>
  103. <h2>
  104. 2 Manutenzione ed assistenza
  105. </h2>
  106. <h3>
  107. 2.1 Ritenete che la diffusione di competenze tecniche per manutenzione ed
  108. assistenza sia adeguata alle esigenze del mercato dei pacchetti OS? (Se
  109. possibile e se necessario differenziare il caso del sistemista-gestore e
  110. quello del programmatore di una nuova applicazione ).
  111. </h3>
  112. <p>
  113. Attualmente il mercato delle piccole reti e dei prodotti da ufficio è
  114. orientato verso l'uso dei prodotti Microsoft, per cui è più facile
  115. trovare competenze a basso livello in questi campi con prodotti
  116. Microsoft.
  117. </p>
  118. <p>
  119. Il contrario avviene nel mercato delle grosse reti e server, dove c'è
  120. una predominanza del software libero.
  121. </p>
  122. <p>
  123. Tuttavia, questo tipo di competenze è estremamente volatile, e i tecnici
  124. del settore hanno bisogno di continui aggiornamenti, tanto che si può
  125. dire che un tecnico riscostruisce buona parte delle proprie competenze
  126. pratiche nell'arco di tre anni, mentre le conoscenze di base sono comuni
  127. a tutti i prodotti e hanno durata molto maggiore.
  128. </p>
  129. <p>
  130. Di conseguenza, il mercato della manutenzione segue molto da vicino
  131. l'evoluzione del mercato, e le competenze seguono la richiesta.
  132. </p>
  133. <h3>
  134. 2.2 Ritenete che la disponibilità del codice sorgente di un pacchetto da
  135. parte dell'utente finale sia un fattore di facilitazione per la manutenzione
  136. ed assistenza del software?
  137. </h3>
  138. <p>
  139. Sicuramente rappresenta un'opportunità in più, anche se avere accesso
  140. al codice sorgente è solo un prerequisito per godere dei diritti
  141. summenzionati. La manutenzione e l'assistenza su pacchetti software è
  142. possibile in regime concorrenziale soltanto se il sorgente è
  143. accompagnato dal diritto di uso, studio, modifica e ridistribuzione
  144. del codice.
  145. </p>
  146. <h3>
  147. 2.3 Per quanto di vostra conoscenza, quali tutele sono offerte agli utenti
  148. di pacchetti nel caso in cui il fornitore non fornisca più la manutenzione e
  149. l'assistenza necessarie? Quali sono le vostre esperienze al riguardo?
  150. </h3>
  151. <p>
  152. Nel caso di software proprietario gli utenti dipendono soltanto dalle
  153. strategie commerciali del fornitore originario. Le licenze libere
  154. garantiscono invece la possibilità di affrancarsi dal monopolio di un
  155. produttore sul pacchetto acquistato e affidarsi anche a terzi per
  156. interventi di manutenzione, assistenza e aggiornamento. Non è
  157. possibile generalizzare.
  158. </p>
  159. <br></br>
  160. <h2>
  161. 3 Sicurezza e liability
  162. </h2>
  163. <h3>
  164. 3.1 Rispetto alle questioni sotto indicate, ritenete ci siano differenze tra
  165. i pacchetti OSS e quelli proprietari, e se si quali?
  166. <ul>
  167. <li>Garanzia dell'assenza di back-door.</li>
  168. <li>Garanzia dell'assenza di funzionalità e modalità realizzative dannose e/o pericolose dal punto di vista della sicurezza.</li>
  169. <li>Garanzia di protezione dalle intrusioni, contaminazioni ed attacchi esterni.</li>
  170. <li>Rispondenza tra il software rilasciato ed i requisiti dellutente.</li>
  171. </ul>
  172. </h3>
  173. <p>
  174. Non ci sono differenze tra i due tipi di licenze (libere o
  175. proprietarie) in esame: in entrambi i casi si tratta di software,
  176. sviluppato da esseri umani e passibile di ogni tipo di errore di
  177. programmazione e malfunzionamento.
  178. </p>
  179. <p>
  180. Tuttavia punti a favore del software libero sono: la visibilità
  181. dell'intero codice sorgente, e la possibilità di esaminarlo,
  182. ricompilarlo, confrontarlo con il binario, apportarvi modifiche per la
  183. correzione e verifica.
  184. </p>
  185. <h3>
  186. 3.2 Relativamente alla qualità del software dal punto di vista della
  187. sicurezza, quali ritenete siano i punti di forza e di debolezza dei
  188. pacchetti software commerciali e di quelli OS?
  189. </h3>
  190. <p>
  191. In questa domanda il software commerciale viene considerato qualcosa
  192. di diverso dal software libero. Respingiamo la posizione che il
  193. software libero non sia anche sfruttabile commercialmente (come
  194. specificato nella premessa).
  195. </p>
  196. <p>
  197. Non ci sono differenze di principio tra software proprietario e
  198. libero, se non quelle citate sopra. Attualmente, la miglior difesa
  199. contro i difetti del software sembra essere la più ampia diffusione
  200. possibile del codice e la sua modificabilità. Queste caratteristiche
  201. consentono l'esame da parte di una vasta comunità di esperti e
  202. studiosi di sicurezza del software.
  203. </p>
  204. <p>
  205. Il software libero inoltre può essere migliorato ed eventuali
  206. malfunzionamenti corretti, non solo dal produttore monopolista, ma
  207. anche da terzi, autonomamente da chi li scopre o anche dal produttore
  208. originario.
  209. </p>
  210. <h3>
  211. 3.3 Quali ritenete siano le differenze nei pacchetti OSS e in quelli
  212. proprietari in relazione alla tempestività delle correzioni a seguito di
  213. alert di sicurezza?
  214. </h3>
  215. <p>
  216. Una ricerca empirica (i risultati sono pubblicati sul sito
  217. <a href="http://dweehler.com/why-os.html">http://dweehler.com/why-os.html</a>)
  218. ha misurato il tempo medio di reazione tra la pubblicazione di una
  219. vulnerabilità e il rilascio di una patch; RedHat è risultata essere stata la
  220. più veloce nell'anno delle misurazioni con una media di 6 giorni, seguita da
  221. Microsoft e Sun Microsystems.
  222. </p>
  223. <p>
  224. Benché questo studio potrebbe essere poco rigoroso, restano segnali
  225. forti che la tempestività dei maggiori e più importanti progetti
  226. liberi rispetto a segnalazioni di insicurezze sia più elevata.
  227. </p>
  228. <h3>
  229. 3.4 Nell'eventualità si verificasse una vulnerabilità del software quali
  230. ritenete siano le differenze per la gestione e risoluzione del problema nei
  231. pacchetti OSS e in quelli proprietari?
  232. </h3>
  233. <p>
  234. Non è possibile generalizzare, ma la differenza fondamentale tra
  235. software libero e non è che, nel caso di software libero, se gli
  236. autori originari o i reponsabili del software non sono abbastanza
  237. tempestivi o accurati è possibile rivolgersi a terze parti.
  238. </p>
  239. <br></br>
  240. <h2>
  241. 4 Total cost of ownership
  242. </h2>
  243. <h3>
  244. 4.1 Sulla base della vostra esperienza quanto pensate incidano
  245. percentualmente, le seguenti voci relative all'ownership di pacchetti
  246. software?
  247. <table>
  248. <tr>
  249. <td width="33%">&nbsp;</td>
  250. <td width="33%">Pacchetti proprietari</td>
  251. <td width="33%">Pacchetti open source</td>
  252. </tr>
  253. <tr>
  254. <td>Licenze software</td>
  255. <td>&nbsp;</td>
  256. <td>&nbsp;</td>
  257. </tr>
  258. <tr>
  259. <td>Hardware</td>
  260. <td>&nbsp;</td>
  261. <td>&nbsp;</td>
  262. </tr>
  263. <tr>
  264. <td>Software applicativo</td>
  265. <td>&nbsp;</td>
  266. <td>&nbsp;</td>
  267. </tr>
  268. <tr>
  269. <td>Gestione del software</td>
  270. <td>&nbsp;</td>
  271. <td>&nbsp;</td>
  272. </tr>
  273. <tr>
  274. <td>Costi per il supporto sistemistico</td>
  275. <td>&nbsp;</td>
  276. <td>&nbsp;</td>
  277. </tr>
  278. <tr>
  279. <td>Costi di formazione</td>
  280. <td>&nbsp;</td>
  281. <td>&nbsp;</td>
  282. </tr>
  283. <tr>
  284. <td>Servizi di outsourcing</td>
  285. <td>&nbsp;</td>
  286. <td>&nbsp;</td>
  287. </tr>
  288. <tr>
  289. <td>Costi per interruzione del servizio</td>
  290. <td>&nbsp;</td>
  291. <td>&nbsp;</td>
  292. </tr>
  293. </table>
  294. </h3>
  295. <p>
  296. Non è possibile rispondere a questa domanda, se non facendo delle
  297. generalizzazioni significative. I costi di licenze possono essere
  298. significativi nelle strutture scolastiche o insignificanti in aziende
  299. dove i costi di outsourcing e consulenze sono altissimi.
  300. </p>
  301. <h3>
  302. 4.2 Siete in grado di specificare se il TCO di un pacchetto OSS sia
  303. mediamente più alto o più basso del TCO di un pacchetto proprietario di pari
  304. funzionalità? Di quanto e perchè?
  305. </h3>
  306. <p>
  307. Non si può calcolare il TCO di un solo pacchetto, ma deve essere calcolato
  308. sull'intero sistema informativo aziendale, nell'arco di 3/5 anni (tempi
  309. standard di ammortamento) considerando che in tale arco di tempo le
  310. condizioni di licensing possono variare considerevolmente nel caso di
  311. software non libero.
  312. </p>
  313. <p>
  314. Vale la considerazione che in un mercato aperto e concorrenziale i
  315. prezzi sono fisiologicamente più bassi che in mercati chiusi e
  316. monopolistici. Solo con il software libero è possibile realizzare un
  317. mercato aperto e concorrenziale, per cui riteniamo che nel medio
  318. periodo sicuramente il TCO di sistemi basati su software libero sarà
  319. più basso.
  320. </p>
  321. <h3>
  322. 4.3 Su quali voci e quanto pensate incidano i costi ed i tempi di migrazione
  323. da un pacchetto all'altro?
  324. </h3>
  325. <p>
  326. Incidono sulla formazione del personale, sia utente che addetto alla
  327. manutenzione. Tali voci di costo sul breve periodo, si trasformano in
  328. valore per l'azienda (maggiore capacità e indipendenza nella
  329. risoluzione di problemi) i cui frutti si mantengono nel tempo:
  330. l'utente/cliente diventa infatti "proprietario" del software acquisito
  331. e decide autonomamente le politiche di aggiornamento, manutenzione.
  332. </p>
  333. <h3>
  334. 4.4 Come ritenete di realizzare il ritorno degli investimenti qualora
  335. decidiate di migrare da un pacchetto ad un altro?
  336. Ritenete ci siano ulteriori costi da tenere in considerazione in caso di
  337. migrazione? Quali?
  338. </h3>
  339. <p>
  340. Il ROI (Return Of Investment) dipende molto dal tipo di soluzione che
  341. si sta implementando. La possibilità di rendersi indipendenti dal
  342. produttore monopolista e attingere ad un mercato concorrenziale di
  343. fornitori di servizi è un fattore a favore di un rapido ROI.
  344. </p>
  345. <br></br>
  346. <h2>
  347. 5 Open Standard versus Open Source ­ Formati Aperti
  348. </h2>
  349. <h3>
  350. 5.1 Ritenete che la disponibilità del codice sorgente di un pacchetto
  351. sia un valore aggiunto rilevante per garantire l'interoperabilità
  352. delle applicazioni interamministrative? Perché?
  353. </h3>
  354. <p>
  355. Sì, anche in mancanza di tutte le libertà summenzionate, perchè
  356. permette comunque di verificare la corrispondenza tra lo standard così
  357. come documentato e l'implementazione particolare. Senza accesso al
  358. codice sorgente ci si può solo affidare a costose operazioni di
  359. reverse-engineering (a volte impossibili tecnicamente).
  360. </p>
  361. <p>
  362. Ciò che è importante è che il formato di interscambio di dati sia
  363. documentato e liberamente utilizzabile da chiunque senza limitazioni
  364. per poter garantire interoperabilità anche legale, oltre che tecnica.
  365. </p>
  366. <br></br>
  367. <h2>
  368. 6 Licensing
  369. </h2>
  370. <h3>
  371. 6.1 Quali sono le vostre esperienze nella gestione delle problematiche
  372. di licensing per pacchetti proprietari (per esempio, trasferibilità
  373. delle licenze)?
  374. </h3>
  375. <p>
  376. Non abbiamo esperienze dirette.
  377. </p>
  378. <h3>
  379. 6.2 Quali sono a vostro avviso le forme di licensing che potrebbero
  380. essere adottate per l'acquisizione di pacchetti su licenza?
  381. </h3>
  382. <p>
  383. La pubblica amministrazione dovrebbe sempre reclamare il possesso di
  384. tutto il software in uso presso di essa, per tutelare la res publica:
  385. possesso dei sorgenti leggibili e modificabili, con annessa
  386. documentazione e permesso legale di modifica e distribuzione interna.
  387. </p>
  388. <h3>
  389. 6.3 Quali sono i vantaggi e gli svantaggi di una estensione del
  390. brevetto al comparto del software come recentemente deliberato negli
  391. USA?
  392. </h3>
  393. <p>
  394. I vantaggi sarebbero delle aziende d'oltreoceano e giapponesi che
  395. vedrebbero il loro portfolio di brevetti legalizzato anche in Europa e
  396. potrebbero completare il processo di distruzione delle imprese europee
  397. ed italiane.
  398. </p>
  399. <p>
  400. Gli svantaggi per le aziende nazionali sono legati alla
  401. ingiustificabilità razionale del brevetto sulle idee astratte,
  402. ampiamente illustrato nell'articolo che alleghiamo.
  403. </p>
  404. <p>
  405. Vale la pena sottolineare come invece negli USA il sistema brevettuale
  406. sia sottoposto a pesanti critiche da parte di economisti indipendenti
  407. che hanno dimostrato la nocività del brevetto sulle idee (software e
  408. pratiche commerciali), mentre mancano completamente studi economici
  409. altrettanto indipendenti che ne dimostrino la validità.
  410. </p>
  411. <h3>
  412. 6.4 Nel caso di acquisizione/manutenzione di software custom su
  413. commessa, i contratti da voi siglati prevedono l'acquisizione della
  414. proprietà piena (anche se magari non esclusiva) del codice sorgente
  415. prodotto?
  416. </h3>
  417. <p>
  418. Affinché un pacchetto software venga incorporato nel progetto GNU,
  419. l'autore o gli autori originali devono cedere volontariamente il
  420. copyright e i diritti di sfruttamento esclusivo dell'opera alla Free
  421. Software Foundation. Attraverso un contratto noto come Copyright
  422. Assigment gli autori di software libero assicurano volontariamente
  423. manutenibilità legale al proprio programma.
  424. </p>
  425. <p>
  426. Diversamente dal software proprietario, i cui diritti esclusivi sono
  427. detenuti da una sola azienda e solitamente lo stesso software ha una
  428. durata limitata a pochi anni, con il software libero la titolarità dei
  429. diritti è distribuita tra gli autori; lo stesso progetto GNU ha anche
  430. lo scopo di durare a lungo nel tempo. Queste esigenze fanno sì che
  431. sia necessario avere un controllo centralizzato per poter manutenere
  432. legalmente nel tempo i pacchetti software più importanti. La FSF si
  433. impegna a non rendere mai proprietario il software di cui acquisisce i
  434. diritti.
  435. </p>
  436. <p>
  437. Oltre al Copyright Assignement, la FSF Europe ha recentemente attivato
  438. un contratto simile (il <a
  439. href="http://www.fsfeurope.org/projects/fla/fla.en.html">Fiduciary License
  440. Agreement o FLA</a>) per affrontare e risolvere alcuni problemi e minacce per
  441. il software libero:
  442. <ul>
  443. <li>per essere sicuri che il software libero sia usabile e difendibile legalmente
  444. anche dopo che i suoi autori non siano più raggiungibili.</li>
  445. <li>per difendere in modo efficace i programmatori minacciati e costretti su basi
  446. legali a cambiare il nome del progetto o interrompere la distribuzione</li>
  447. <li>per evitare che alcune aziende possano impadronirsi di codice libero scritto da
  448. loro dipendenti e vendere versioni proprietarie di quel software</li>
  449. <li>per garantire la libertà del software per 20 e più anni, dato che
  450. nessun'azienda potrebbe mai garantire altrettanto, visto che potrebbe fallire o
  451. essere costretta da dinamiche di mercato a modficare le sue policy.</li>
  452. </ul>
  453. </p>
  454. <p>
  455. Il FLA consente quindi di:
  456. <ul>
  457. <li>cambiare i termini di licenza di distribuzione del software, dovesse
  458. rendersi necessario per questioni tecniche o legali</li>
  459. <li>difendere il software da abusi, anche in tribunale, se necessario</li>
  460. <li>proteggere gli autori di Software Libero, accettando di sobbarcarsi il rischio
  461. di essere attaccati su basi legali</li>
  462. <li>rappresentare un fattore di stabilizzazione e di armonizzazione in gruppi di
  463. sviluppatori misti commerciali e commerciali/volontari.</li>
  464. </ul>
  465. </p>
  466. <br></br>
  467. <h2>
  468. 7 Impatto organizzativo e formazione
  469. </h2>
  470. <h3>
  471. 7.1 Ritenete che l'adozione di pacchetti OSS imponga alle
  472. organizzazioni coinvolte un particolare riassetto organizzativo delle
  473. strutture ICT?
  474. </h3>
  475. <p>
  476. Non meno e non di più dell'adozione di pacchetti genericamente diversi
  477. da quelli usati abitualmente dal personale della PA. Diverso è invece
  478. il discorso per l'acquisizione di servizi di aggiornamento e
  479. manutenzione: nel caso di software libero essi saranno disponibili da
  480. fornitori in un mercato concorrenziale. Di questo fattore dovranno
  481. tenere conto i bandi per l'acquisizione di software per la PA.
  482. </p>
  483. <h3>
  484. 7.2 Ritenete che l'adozione di pacchetti OSS rispetto al software
  485. proprietario imponga specifiche attività formative nell'ambito delle
  486. pubbliche amministrazioni e delle aziende coinvolte? Quali?
  487. </h3>
  488. <p>
  489. Proprietario o libero non ci sono differenze se si tratta di fare
  490. formazione su strumenti nuovi o diversi per gli utenti.
  491. </p>
  492. <br></br>
  493. <h2>
  494. 8 Valutazione sulle strategie di attuazione in ambito comunitario e
  495. nazionale
  496. </h2>
  497. <h3>
  498. 8.1 A vostro giudizio, quale potrebbe essere il ruolo del software OS
  499. nei programmi comunitari e nazionali?
  500. </h3>
  501. <p>
  502. Ci auguriamo che il software libero in Italia e in Europa continui ad
  503. avere il ruolo di locomotiva trainante per la creazione di un mercato
  504. di competenze locali; che continui ad essere considerato un obiettivo
  505. primario come nel VI Programma Quadro comunitario e nelle
  506. Raccomandazioni del MIUR, per il rilancio di un'industria tecnologica
  507. d'avanguardia locale.
  508. </p>
  509. <br></br>
  510. <h2>
  511. 9 Università
  512. </h2>
  513. <h3>
  514. 9.1 La valenza dell'ICT nell'ambito della cultura scientifica è un
  515. tema controverso. Ritenete che lo sviluppo dell'OSS comporti una
  516. qualche implicazione nella cultura scientifica e nei meccanismi di
  517. trasmissione di essa o sia esclusivamente un fatto tecnologico?
  518. </h3>
  519. <p>
  520. Il software libero è un'esigenza culturale oltre che tecnologica. Si
  521. dibatte sulla doppia valenza del software, sia strumento che
  522. informazione pura: pensiamo che, al di là dei sofismi, non sia oggetto
  523. di dibattito l'assunto che per il progresso è assolutamente necessaria
  524. la diffusione di conoscenza. Nel campo tecnologico e del software in
  525. particolare, solo il software libero consente un vasto flusso di
  526. conoscenza che si trasforma in progresso e innovazione. Nel progetto
  527. GNU e più ampiamente come software libero, si possono reperire
  528. programmi che hanno realizzato innovazioni non solo incrementali, ma
  529. anche radicali. Ad esempio, il compilatore gcc (GNU Compiler
  530. Collection) è l'unico compilatore esistente sul mercato in grado di
  531. accettare decine di linguaggi di programmazione in input e produrre
  532. codice macchina per quasi tutte le piattaforme hardware esistenti. Il
  533. progetto Mozilla (benché noto solo per il browser) ha innovato
  534. radicalmente, realizzando ex-novo qualcosa che prima non esisteva: un
  535. framework cross-platform per la realizzazione di applicazioni basate
  536. su internet. La stessa Internet è nata e prospera come fenomeno
  537. commerciale, grazie alla conoscenza diffusa dei protocolli, delle
  538. applicazioni e alle implementazioni libere degli stack TCP/IP. Le
  539. implementazioni di protocolli di rete proprietarie, pur migliori
  540. tecnicamente, non hanno mai trovato spazio e non si sono mai imposte
  541. sul mercato.
  542. </p>
  543. <h3>
  544. 9.2 Ritenete che l'OSS vada in qualche modo inserito nella scuola? In
  545. caso affermativo specificare se come ambito di utilizzo pensate a:
  546. <ul>
  547. <li>A. il suo inserimento nei percorsi formativi scolastici</li>
  548. <li>B. il suo utilizzo nella gestione delle infrastrutture tecnologiche</li>
  549. </ul>
  550. </h3>
  551. <p>
  552. Il software libero deve essere inserito nei percorsi formativi
  553. scolastici per i motivi succitati e per accellerare il processo di
  554. creazione del pool di esperti cui il mercato può attingere.
  555. </p>
  556. <p>
  557. Dal punto di vista formativo, poi, nelle aree didattiche tecnologiche
  558. il software libero è l'unico che consente di apprendere le basi
  559. tecniche del funzionamento di: sistemi operativi, compilatori,
  560. interpreti, interfacce grafiche, database e tutti i componenti di un
  561. sistema informativo, dato che le licenze con cui è distribuito
  562. consentono espressamente lo studio e l'adattamento alle esigenze
  563. dell'utente.
  564. </p>
  565. <h3>
  566. 9.3 Quali i punti di forza e/o di debolezza dell'uso dell'OSS nella
  567. scuola (specificare con riferimento all'ambito A e B)?
  568. </h3>
  569. <p>
  570. Se gli ambiti A e B sono riferiti ai punti della domanda 9.2, allora
  571. non ci sono motivi per scegliere software proprietario nella scuola.
  572. Siamo convinti che l'uso di software proprietario nella scuola sia in
  573. realtà una forma di "ammaestramento", ovvero una sostituzione alla
  574. formazione su strumenti specifici e non creazione di cultura (che è
  575. invece il compito di una scuola moderna in uno stato altrettanto
  576. moderno).
  577. </p>
  578. <h3>
  579. 9.4 Ritenete che gli interventi di formazione su OSS debbano essere
  580. diversi da quelli previsti altrimenti? In caso affermativo in cosa
  581. ritenete si debbano differenziare?
  582. </h3>
  583. <p>
  584. Non ci sono i presupposti per una differenziazione.
  585. </p>
  586. <h3>
  587. 9.5 Nell'ambito della vostra università sono previsti programmi di
  588. ricerca sul software OS? Se si', con quali obiettivi scientifici?
  589. </h3>
  590. <p>
  591. Non abbiamo elementi per rispondere
  592. </p>
  593. <h3>
  594. 9.6 La diffusione del software OS potrebbe favorire, ostacolare o
  595. essere sostanzialmente marginale rispetto alla crescita di
  596. un'industria nazionale del software ? Per quali motivi?
  597. </h3>
  598. <p>
  599. Non può che favorire una crescita del settore tecnologico nel suo
  600. complesso. L'abbassamento delle barriere all'ingresso sul mercato
  601. sfruttando l'enorme quantità di software di alta qualità esistente
  602. favorisce l'aumento di soggetti in grado di differenziarsi per
  603. copertura geografica, qualità di servizi. Sarebbe comunque
  604. interessante studiare la situazione attuale del mercato del software
  605. in Italia, che basandoci su esperienze dirette, sembra essere formata
  606. principalmente da due tipi di aziende: quelle che sviluppano software
  607. su commessa o sviluppano soluzioni verticali e quelle che
  608. distribuiscono soluzioni in scatola vendendo servizio. Se fosse
  609. dimostrata tale situazione, con la diffusione di software libero
  610. entrambi i tipi di aziende potrebbe continuare a fare affari senza
  611. mutare considerevolmente il proprio modello commerciale, con l'effetto
  612. positivo di ridurre considerevolmente il drenaggio di capitali verso
  613. gli USA dovuto al pagamento sterile di licenze.
  614. </p>
  615. <h3>
  616. 9.7 Siete favorevoli all'avvio di un programma nazionale di ricerca
  617. applicata sull'OSS, in particolare il programma dovrebbe focalizzarsi
  618. sui modelli di business per sw OS ovvero sullo sviluppo di nuove linee
  619. di strumenti sw OS?
  620. </h3>
  621. <p>
  622. Siamo favorevoli e ci candidiamo fin da ora a seguirne i passi in
  623. qualità di esperti in materia.
  624. </p>
  625. </body>
  626. <timestamp>$Date$ $Author$</timestamp>
  627. </html>
  628. <!--
  629. Local Variables: ***
  630. mode: xml ***
  631. End: ***
  632. -->