Aggiornamento: commento da Andrea Valboni (Microsoft) in fondo.

Traduzione a cura di Simone Aliprandi, che ringrazio

OOXML, ovvero – come è meno conosciuto – ISO/IEC DIS 29500, si sta pian piano avvicinando al Ballot Resolution Meeting in cui si valuterà se esso può assurgere allo status di Standard Internazionale. Ora ECMA, l’ente che (a dir poco) precipitosamente ha deciso di renderlo uno standard industriale e lo ha presentato all’ISO attraverso una procedura a “corsia preferenziale”, ha raccolto i commenti degli enti nazionali e ha redatto una proposta per fronteggiarli.

Ebbene, dopo aver letto le prime pagine della proposta mi sono reso conto che non valeva la pena di leggere l’intero documento. Io ero più che altro interessato ai commenti di alcuni membri di ISO in merito alle condizioni di licenza (brevetti e copyright) dell’OOXML. Come avvocato, sono profondamente convinto che la Open Specification Promise sia infatti tutt’altro che sufficiente ad assicurare che questo standard sia realmente uno standard indipendente.

La risposta? La questione Non sarà oggetto di trattazione.

  <h2>

La questione dei brevetti

ECMA considera quello degli IPR (Intellectual Property Rights, diritti di privativa intellettuale) un non-problema. Bene, io credo che invece sia proprio il contrario. Sarebbe un suicidio ammettere uno standard in cui un singolo produttore sia autorizzato a fare giochetti come ad esempio dire: “Sapete una cosa? Adesso mi pagate una royalty per ogni implementazione dello standard”, oppure “sorpresa sorpresa, non avete licenza per questo brevetto, dunque siete pregati di cessare ed evitare di usare il nostro formato”. Tralasciamo per un secondo la mia opinione che i brevetti software non dovrebbero esistere; d’altronde esistono, e sono applicati. State dicendo che quanto non accadrà? Allora, se fate caso, anche relativamente a standard veramente multi-vendor (cioè con contributi da più operatori), troverete una vasta quantità di questioni brevettuali sollevate su standard apparentemente liberi o implementabili con condizioni ragionevoli e non discriminatorie: basti pensare all’MP3 e alle relative “patent ambushes” (letteralmente “imboscate brevettuali”) che anche operatori come Microsoft hanno dovuto subire. Qui abbiamo a che fare con uno standard promosso unilateralmente da un singolo produttore che ha sostanzialmente deciso, sulla base della sua iniziativa e non del consenso generale, l’architettura e le specifiche dello standard. I giochi sono differenti, qui, e quindi più accorta del solito deve essere la gestione delle questioni relative ai diritti. Che cosa abbiamo invece? La Open Specification Promise. In sostanza un impegno unilaterale di evitare azioni legali. Pensare che ciò possa essere una garanzia sufficiente per garantire un’implementazione senza problemi da parte di terzi dell’OOXML è davvero ingenuo.

Un non-problema? Può anche essere un non-problema per le attuali norme ISO, ma lo è per coloro chiamati a decidere se tale standard possa meritarsi di completare la procedura di corsia preferenziale, e sarebbe il momento per l’ISO anche di riconsiderare la propria policy. “Standard ISO” significa: “dovete adottarlo per questo ambito di utilizzo; dovete fare così perché questo è uno standard internazionale; dovete fare così perché il settore pubblico sempre di più richiede documenti archiviati in formati standard”. Sostenere che l’OOXML sia un possibile standard implica che, grazie alla diffusione capillare del binomio Microsoft Windows e Microsoft Office, l’OOXML diventerà lo standard per eccellenza. Se questo sarà lo standard affibbiato a tutto il genere umano, esso almeno deve essere libero da ogni possibile problema e implementabile liberamente al cento per cento. E con “liberamente” intendo senza che alcuno possa unilateralmente trovarsi in una posizione di controllo o possa vantare qualche ascendente di natura legale. Uno standard per documenti non è cosa di poco conto: i file di documento raccolgono gran parte delle informazioni che produciamo.

  <h2>

Perché un altro standard? Uno è più che sufficiente!

Io non sto dicendo che lo standard è male giusto perché è Microsoft ad imporlo, ma mi sto chiedendo la ragione per cui Microsoft lo voglia imporre, e si affretta a farlo ora, dal momento che esiste un altro standard appropriato, che nessuno ha tuttora dimostrato essere inferiore e che non soffre dei vari difetti dell’OOXML, così di natura legale come di natura tecnica. Ho detto tecnica? Giusto, andiamo a guardare le migliaia di commenti che ha generato. Pare che la maggior parte dei commenti sia stati semplicemente accettati, compresi alcuni (non tutti) fra i più crudeli. Ad esempio, sono stati apparentemente rimossi quelli che fanno riferimento a specifiche funzionali (“fai questa cosa come la fa Word 97”). Questo potrebbe implicare che tutte le specifiche funzionali “legacy” sono state tenute separate dallo standard e non verrebbero comunque mai più incluse in esso. Esse saranno solo un’estensione.

“Ottimo”, starete pensando. I commenti sono stati accettati , i problemi sono stati risolti, dunque ora non ci sono più ostacoli tecnici, giusto?! E invece no! Le cose si sono fatte ora ancora più oscure. Quando ci si è trovati davanti all’interrogativo “perché un secondo standard? ne abbiamo già uno, l’ODF”, la risposta più o meno è sempre stata che l’OOXML ha due peculiarità che invece mancano all’ODF: compatibilità con i vecchi formati (“legacy”) (vecchi documenti in formato binario possono essere trasformati in formato OOXML senza perdere affidabilità) e adozione plausibilmente massiccia dello standard stesso, derivante dalla ampissima diffusione del nuovo Office 2007, destinato a diventare presto l’applicativo dominante. Dove sono quelle due motivazioni adesso? Puff! Svanite, non esistono più. La parte legacy è un’estensione, anche l’ODF supporta le estensioni. Office 2007 non è compatibile con la nuova versione dell’OOXML, senza poi contare il fatto che nemmeno l’OOXML dell’ECMA è stato implementato, non ci sarà una reale implementazione per anni. Per comprendere che cosa intendo per “reale”, vi invito a leggere il blog di Bob Weir.

L’OOXML è migliore dell’ODF? Non sono in grado di valutare. Nessuno finora ha però portato prove convincenti . Ho letto un rapporto sull’argomento a firma del Burton Group, ma era così lacunoso che la ODF Alliance ha potuto tranquillamente usare toni sarcastici nel confutarlo. Di certo l’OOXML non è proprio il massimo per giustificare un secondo standard. E – scusate il francesismo – con quale faccia l’ECMA verrebbe a dirci che lo standard è ancora in fase di approvazione, quando dopo la consultazione lo hanno modificato e di molto? Questa evidente inversione di rotta è la prova più concreta che innanzi tutto lo standard non dovrebbe mai essere approvato dall’ECMA, e che non dovrebbe nemmeno essere fatto approvare dall’ISO attraverso una procedura a “corsia preferenziale”. Questo vuol dire abusare del processo di standardizzazione, cari miei!

  <h2>

I test di conformità

Ad ogni modo, cos’è successo ai commenti dell’Italia? L’unico commento che abbiamo fatto oltre all’astensione dal voto è stato che noi vogliamo una implementazione di riferimeno indipendente e con condizioni open-source. Il commento è stato raggruppato assieme ad altri simili – si fa per dire – commenti sulla mancanza di test di conformità, o di test suites (il che è diverso da una implementazione di riferimento in cui si possa visionare il codice sorgente di un’implementazione e in certi casi anche utilizzare frammenti per l’applicazione concreta). Ciò è già abbastanza fastidioso. Ma non è nulla in confronto alla risposta: “Benché non siano ad oggi disponibili una implementazione di riferimento o una test suite d’interoperabilità, sta via via aumentando il numero delle implementazioni del ECMA-379 disponibili […]. Se l’esigenza di una test suite d’interoperabilità o di una implementazione di riferimento è avanzata e condivisa dagli Enti Nazionali, SC 34 potrebbe attivarsi opportunamente come suggerito in questo commento”. Come cavolo dovrei interpretarla? Una test suite non è una implementazione di riferimento. Una implementazione commerciale non è una test suite, è piuttosto come lo sviluppatore crede che lo standard dovrebbe essere implementato. Come si è visto, non sempre il principale sostenitore dello standard lo implementa in maniera veramente aderente. Non c’è modo di verificare con certezza se un’implementazione sia veramente aderente allo standard, poiché il test di conformità previsto dallo standard è semplicemente troppo lasso. E' giusto un modo elegante per dire: “No, grazie. per ora niente; vedremo quando lo standard sarà approvato”. Così i commenti italiani sono passati in fanteria: ne prendo atto.

Sono più che mai perplesso per l’atteggiamento dell’ECMA. L’esigenza di un affidabile test di conformità non è una questione marginale. È proprio al centro dell’utilità industriale di un standard. Tralasciare specifiche richieste su questo punto è sconcertante. Rob Weir, ancora, rileva qual è il requisito minimo perché un’applicazione sia rispondente allo standard, in base a quanto previsto nella documentazione di OOXML. Io non sono un informatico, ma la mia opinione sul test è aderente a quella di Rob, e abbastanza sbigottita. Se dobbiamo semplicemente notariziamente mettere un timbro su uno standard inconsistente solo perché Microsoft ha bisogno di poter chiamare le sue applicazioni e i suoi formati “standard”, pur non disturbandosi ad usare standard internazionali, per favore ditelo chiaramente. Senza di me, però.

Ribadirò – in modo ancora più fermo – il mio voto negativo e insistero nel mio Ente Nazionale (UNINFO JTC1) affinché cambi il suo voto da “astenuto” a “contrario”; e così dovrebbe fare ogni persona ragionevole.

Tipo di Entry:&nbsp;




  <a href="/storie">Notizie</a>






Canali:&nbsp;




  <a href="/taxonomy/term/35">Normazione</a>



  <a href="/taxonomy/term/37">Interoperabilità</a>






Argomento:&nbsp;




  <a href="/taxonomy/term/23">Software Libero, libertà digitali</a>