Chiaramente, se c'è un atteggiamento ideologico contro OpenOffice.org, anche le migliori argomentazioni tecniche sono destinate a non essere considerate.
Secondo me bisognerebbe puntare - ancora una volta - sulla possibilità di re-investire il denaro delle licenze, di non incorrere in citazioni in tribunale da parte di Assoli 
e dell'aumento della produttività individuale dei dipendenti che utilizzano OpenOffice.org come largamente dimostrato.
... e mi stavo dimenticando dell'aggiornamento dell'art. 68 del CAD, che, chissà quando, dovranno pur iniziare a tenere in considerazione!!!
Ciao,
attachment.htm (967 Bytes)
Provo a guardare il tema da un altro punto di vista.
La Prov.TN si è schierata con il Software Libero e i Formati Aperti con
la L.P. n.16/2012 del 27.07.2012.
Tutto molto bello, abbiamo esultato in molti.
A questa norma però occorre dare attuazione e in questo a TN dovranno
individuare Partner solidi per seguire questo cammino.
Qualcuno a aggiornamenti in merito? Qualche referente in Prov.TN con cui
parlare?
diego maniacco
2012/8/29 Maniacco, Diego <Diego.Maniacco(a)provinz.bz.it>:
Provo a guardare il tema da un altro punto di vista.
La Prov.TN si è schierata con il Software Libero e i Formati Aperti con
la L.P. n.16/2012 del 27.07.2012.
Tutto molto bello, abbiamo esultato in molti.
A questa norma però occorre dare attuazione e in questo a TN dovranno
individuare Partner solidi per seguire questo cammino.
Qualcuno a aggiornamenti in merito? Qualche referente in Prov.TN con cui
parlare?
Come sai la legge 16 (dove pero' software libero, formati e dati aperti sono di
contorno ad altri contenuti) vede la nascita - a 120 giorni dalla
pubblicazione -
di un comitato di coordinamento.
Quindi, visto che la legge e' stata approvata a metà agosto, fra quattro mesi
ci sarà il giusto interlocutore con cui parlare che dovrà anche "smazzare"
la questione che avete aperto.
Ringrazio invece la lista per questo bellissimo thread.
Sempre sul tema CAD, oltre alla modifica dell'articolo 68, stanno bollendo
in pentola altre modifiche che hanno a che vedere sui dati e formati.
L'attuale definizione su formato aperto non mi garba proprio perchè, di
fatto, permette l'uso di OOXML (si parla di formato di cui sia disponile
esauriente documentazione sulla sua implementazione).
Anzi, avete qualche suggerimento per una definizione di formato aperto
che non dia spazio a OOXML ?
Ciao
Maurizio Napolitano <napoogle(a)gmail.com> ha scritto:
Ciao Maurizio, ciao lista!
L'attuale definizione su formato aperto non mi garba proprio perchè, di
fatto, permette l'uso di OOXML (si parla di formato di cui sia
disponile
esauriente documentazione sulla sua implementazione).
Anzi, avete qualche suggerimento per una definizione di formato aperto
che non dia spazio a OOXML ?
Sinceramente la definizione mi sembra buona (sempre ammesso che non ci siano problematiche di royalties lasciate in sospeso), ci aggiungerei semplicemente qualcosa tipo:
"[... implementazione], e che escluda esplicitamente derivati o estensioni che non rispettino le stesse caratteristiche".
Non credo che il punto sia di non lasciare spazio a OOXML (o a qualsiasi altro formato che dovesse nascere), quanto di non lasciare spazio a formati che aperti non sono...
Ciao,
Daniele
Ciao 
Sinceramente la definizione mi sembra buona (sempre ammesso che non ci siano problematiche di royalties lasciate in sospeso), ci aggiungerei semplicemente qualcosa tipo:
"[... implementazione], e che escluda esplicitamente derivati o estensioni che non rispettino le stesse caratteristiche".
Non credo che il punto sia di non lasciare spazio a OOXML (o a qualsiasi altro formato che dovesse nascere), quanto di non lasciare spazio a formati che aperti non sono...
Concordo, io considero OOXML un caso estremo.
Comunque, attualmente, ho proposto questa definizione:
"per formato aperto si intende un formato reso pubblico e documentato
esaustivamente e con assenza di vincoli nella sua implementazione"
Come ti/vi sembra?
Ciao
Ciao Maurizio, grazie per i contributi alla discussione "al Nord di Salorno"
Pensando ad una panorama in cui vi siano + formati realmente aperti (supponiamo che OOXML lo sia): quale di questi va posto come vincolo?
A mio vedere quello che soddisfa ai requisiti di chi deve scegliere (e qui i requisiti dell'Ente vanno scritti a monte) è pone meno vincoli.
Tra i due formati in discussione pare che ODF (event. v.1.2 anche se ancora non è ISO?) sia il più semplice (da dimostrare, forse il nr. di pagine di documentazione non è un criterio solido) ma sufficiente.
Il passo successivo è la scelta della soluzione software: deve supportare pienamente il formato scelto.
Per scartare una soluzione ti/vi pare sufficiente portare almeno un caso reale di mancato supporto?
diego
attachment.htm (2.92 KB)