Mimmo Cosenza, nel suo blog pubblica un interessante articolo in cui intervista Leonardo Chiariglione, il “padre” dell’MPEG e una delle personalità più influenti e competenti nel mondo della standardizzazione, in Italia e nel mondo. Proviamo a ragionare e a estenderne i concetti.

Come sempre negli articoli di Mimmo Cosenza non mancano gli spunti interessanti, e su molto di quanto si è detto sono d’accordo, su altre cose mi riservo di pronunciarmi in seguito. Le opinioni su quanto è avvenuto nelle procedure di standardizzazione dei formati per le applicazioni office e le prese di posizione mie e di altri riguardano obiezioni di fondo, non sono per partito preso. Anzi la prima volta che ho sentito parlare di standardizzazione XML dei formati di Microsoft Office pensavo francamente a una svolta positiva, salvo poi radicalmente ricredermi, et pour cause! Per cui io — come penso molti — sono disponibile a iniziare un dialogo sereno e aperto, in cui però alcuni macigni devono essere rimossi.

  <h2>

Macigni sulla strada del dialogo

Il primo macigno, bello grande, si chiama brevetti software. Non sto parlando della discussione in generale sui brevetti software, di cui pure la mia opione è conosciuta, sto parlando dei brevetti “necessarily infringed” da chi implementi lo standard proposto. Come già segnalato da molti, la promessa di non far causa a chi infranga i brevetti per implementare lo standard di Microsoft non è sufficientemente ampia da garantire i concorrenti un’implementazione che vada al di là della traduzione da un formato all’altro. Dunque quello che dovrebbe fare Microsoft per ottenere un via libera è: individuare quali suoi brevetti o brevetti dalla stessa controllati, promettere di non fare causa per quei brevetti a chi li usa per aderire a uno standard (dunque per creare un’applicazione d’ufficio, la quale “parli anche OOXML”). A maggior ragione se, come Andrea Valboni (Microsoft) scrive nella replica al post di Mimmo Cosenza, Microsoft ritiene non ci siano problemi di brevetti.

In realtà il timore è che Andrea Valboni abbia ragione e torto allo stesso tempo. Nello standard un brevetto può venire in considerazione se la particolare rivendicazione viene indicata come obbligatoria dallo standard, e quindi dipende da quanto restrittivo sia tale standard. Se è consentito prendere strade diverse, allora la rivendicazione, pur essendo stata utilizzata in una particolare implementazione, non è a stretto rigore ricompresa nello standard. Tutto sta a verificare come sia possibile per un’altra implementazione rispettare lo standard, evitare il brevetto, mantenere l’interoperabilità con l’implementazione (proprietaria) di riferimento (con quel procedimento che si chiama “invent around“). Un’implementazione che rispetti lo standard ma che non fosse in grado di interoperare a livello di formato documentale con Office, che per coincidenza ha il 95% del mercato, non sarebbe “standard” in senso commerciale, dunque lo standard ufficiale avrebbe ben poco senso.

Senza la precondizione che i brevetti necessari (nella nozione più ampia) a usare lo standard e a interoperare con l’implementazione di riferimento — ovvero le applicazioni Office di Microsoft, autrice dello standard e operatore dominante — siano veramente esentati (o alternativamente un impegno a non usare mai i brevetti software in senso offensivo, ma solo in senso difensivo) non mi pare si possa fare molta strada.

Nemmeno il problema che nello standard ci siano “flaws” (inesattezze, errori, problemi) può essere passato sotto silenzio. Certo, nessuna specifica ne è esente, come nessun tipo di software è esente da bug, ma è una questione di proporzioni. Il fatto che gli enti nazionali abbiano prodotto qualche centinaio di commenti (critiche) tecnici allo standard, non depone affatto bene per la qualità della proposta. Io non sono un tecnico e dunque non mi permetto di pormi come autorità in proposito, ma qualcuno dovrebbe spiegarmi perché in uno standard ISO si dovrebbero accettare errori come quelli di arrotondamento, solo perché questo è il comportamento (anomalo) dell’implementazione di riferimento. Tuttavia i problemi tecnici hanno una soluzione tecnica, non dubito che Microsoft abbia tutto l’interesse e le possibilità di rimediarvi, laddove siano fondati, per cui questa parte del problema non mi pare irrisolvibile, se siamo in buona fede. Certo di lavoro pare esservene molto, dato che da quanto ho potuto vedere la qualità di progettazione dello standard è molto scarsa in vari punti e inaccettabile in altri, come laddove descrive il comportamento corretto di un’applicazione facendo riferimento a come si comporta un’applicazione di Microsoft.

  <h2>

Scusi, “fast track” a chi?

Resta il fatto del come si faccia a conciliare una tale mole di rifacimenti con una procedura di fast track. Per pura coincidenza, proprio oggi ho letto un documento pubblico di IEC (che con ISO ha formato il JTC1, ovvero il Joint Technical Committee ISO/IEC, che deve esprimersi tra l’altro sullo standard OOXML), nel quale si legge:

2. The purpose of fast-track is also, and in this case I maintain that it is also an absolute rule, to make into an IS a specification which can be used as it is as a useful contribution to the world community. This to me is a sine qua non of a fast track. Any other situation (e.g. preconditions, constraints, extra work needed etc. before being able to use the results) seems to disqualify the fast track. This follows from the fundamental purpose of an IS, which is to help world trade, as well as from the rules of ISO and IEC, which are democratic and transparent. If any other work was required, this would have to be done in the ISO/IEC system and not by each user separately, and therefore we would be back to the five-stage process.

Per essere precisi, questa dichiarazione non ha nulla a che fare, almeno ufficialmente, con il processo di standardizzazione di cui ci occupiamo, e per questo non mi pare possa essere accusata di partigianeria.

Non ho dubbi che la procedura “Fast Track” debba essere convertita in procedura ordinaria, e per il futuro debba essere presa in considerazione l’opportunità di dare sempre e comunque tale procedura agli standard proposti da ECMA.

  <h2>

Reference implementation

Un contributo interessante che il dialogo socratico tra Cosenza e Chiariglione ha portato è quello della reference implementation indipendente. Non è un punto da poco. Spunti in tal senso si sono avuti in un post di un blog curato da Geir Isene, riprendendo uno dei requisiti di IETF (Internet Engineering Task Force), ma ancora prima vi è stata una proposta in tal senso da parte di Chiariglione, fatta propria da UNINFO e allegata come commento nella propria dichiarazione di astensione (a cui io stesso ho già dato parere positivo in sede di JTC1, con la precisazione che non dovesse trattarsi dell’unico requisito posto dall’Italia per la non approvazione dello standard).

Con una reference implementation è possibile avere un esempio di applicazione, magari non ottimizzata e ingegnerizzata, che produce un file conforme allo standard, in modo che gli sviluppatori abbiano un esempio di codice aderente allo stesso, e un algoritmo tradotto in codice sorgente — mi dicono — è molto più comprensibile

Nel discorso tra le due menti pensanti protagoniste del dialogo, c’è qualcosa di più interessante. Ad oggi la reference implementation è solo quella di Microsoft, ma ovviamente di essa possiamo vedere solo il prodotto finale, ovvero il file, perché del resto sappiamo ben poco. Se come proposto la reference implementation ha una licenza di Software Libero (open source) come ad esempio la MPL (Mozilla Public License, ovvero una licenza con copyleft “debole”), gli autori di un’applicazione potrebbero adottare e modificare direttamente il software della reference implementation. Questo a condizione che si dichiari espressamente clausola di compatibilità con la GNU GPL, facoltà prevista dalla licenza MPL-tipo (escludere la licenza principe del Software Libero suonerebbe come un insulto, e la MPL è incompatibile proprio perché restrittiva). Inoltre, se ci fossero brevetti che coprono tale codice, questi verrebbero da un lato esposti, dall’altro esplicitamente o implicitamente rinunciati. L’utilizzo di una reference implementation funzionante serve ovviamente anche a testare sul campo come un file prodotto da quest’ultima venga letto dall’implementazione proprietaria, e viceversa.

E' chiaro, spero, da queste poche considerazioni come la reference implementation e l’implementazione proprietaria di riferimento (MS Office) non possano affatto essere la stessa cosa, il che equivarrebbe — come avverrebbe con l’approvazione dello standard come proposto — a definire “standard” una semplice traduzione di un formato proprietario in un altro formato proprietario sostanzialmente e funzionalmente identico al primo, questa volta XML.

  <h2>

Conclusioni

È tutto qui?

No, non lo è. O almeno, non penso che lo sia. Quelli che ho elencato all’inizio sono solo una parte dei dubbi sullo standard OOXML, quelli “risolvibili”. Ce n’è uno irrisolvibile, la duplicazione di uno standard esistente. Ed è — come mi fanno notare — quasi la prima volta che si creano due standard interazionali nel campo dei formati per domini applicativi esattamente sovrapponibili. Citando un famoso film degli anni ‘80, “alla fine ne rimarrà uno solo”: sarà il migliore, quello che consente un numero maggiore di implementazioni indipendenti (il che è se vogliamo la ragione per standardizzare) o quello che emerge per bruta forza di chi lo impone? La duplicazione degli standard, se ci sarà, imporrà incertezza, inefficieza e costi inutili: se c’è un campo dove la concorrenza è deleteria, questo è quello degli standard. Temo che questo sia uno “show stopper“, un inciampo non aggirabile, perché la sua risoluzione impone o l’abbandono della proposta di Microsoft (e allora che parliamo a fare?) o l’unione dei due standard, che pare improponibile, almeno per il momento.

Ma se ci troviamo su un terreno comune di questo tipo, tenendo ben presenti le superiori obiezioni filosofiche, penso che si possa giungere a una soluzione di compromesso. Non la pace, ma un cessate-il-fuoco parziale. È una posizione del tutto personale, certo, ma penso di esprimere in un modo o nell’altro un sentire comune.

Tipo di Entry:&nbsp;




  <a href="/articoli">Articoli</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>