Prova di dialogo

Mimmo Cosenza (MC): Leonardo, io e tantissimi altri (non solo italiani) ti consideriamo la più autorevole voce quando si parla di standard. In un mio post di questo stesso blog ospitato da Nova100 ho anche interpretato la tua astensione dalla votazione su OOXML con le seguenti parole:

E' una lezione di cultura, di stile e di deontologia professionale per tutti e spero vivamente che se ne accorgano anche negli altri organismi nazionali di ISO.

Adesso che i risultati complessivi della votazione sono pubblici, così come sono pubbliche anche le modalità non proprio trasparenti in cui questa votazione si è svolta, puoi aggiungere qualche ulteriore precisazione alla tua posizione o alla mia interpretazione della tua posizione?

Leonardo Chiariglione (LC): Mimmo, grazie per le parole. Penso che io e le migliaia di persone che, negli anni, si sono succedute in MPEG abbiamo in effetti contribuito a portare aria nuova nel mondo degli standard. Sono stato chiamato, come membro della commissione UNINFO JTC1, a dare il mio contributo alla creazione di una posizione italiana condivisa sul DIS 29500.

Anche se la mia formazione mi porta a dar valore preminente agli standard che sono il risultato di un processo aperto ed equo, mi piego alla realtà di un set di applicazioni proprietarie che sono usate da centinaia di milioni di persone.

Pertanto, se il proprietario di queste applicazioni decide di aprirle e farne uno standard internazionale, la cosa è per me benvenuta, purché il processo di creazione dello standard sia fatto bene ed il risultato permetta l'effettiva creazione di un mercato orizzontale di prodotti interoperabili multisorgente.

Quello che sarebbe stato desiderabile è che il proprietario di cui sopra avesse fatto quello che ha fatto un paio di anni fa quando ha presentato Open Type ad MPEG. In quel caso siamo partiti da un Working Draft che è poi diventato Committee Draft fino a diventare alla fine Final Draft International Standard con il nome Open Font Format (IISO/IEC 14496-22). Così tutti i national body hanno avuto la possibilità di rivedere il contenuto tecnico dello standard e contribuire alla sua redazione.

Così non è stato per il caso in questione e ci siamo trovati, applicando una procedura che non ho contribuito a creare ma che esiste, con un documento allo stato “finale”, il DIS 29500 appunto. Quello che ho cercato di fare in UNINFO è stato di applicare al DIS 29500 la procedura che MPEG ha sempre adottato per i suoi standard (almeno, quelli per cui la procedura aveva senso) e cioè di avere una versione dello standard in forma testuale accanto ad un'altra che tu chiameresti "reference implementation" e che ha lo stesso valore normativo dello standard scritto con parole umane. Oltre a questo ho anche chiesto che ci fossero i test di conformità, che sono necessari per dirimere le eventuali contese quando sorgono problemi di non interoperabilità.

Devo dire che i membri della commissione sono stati molto ricettivi e c'è già un gruppo di aziende che ha dichiarato l'intenzione di partecipare ai lavori di creazione della reference implementation.

Purtroppo la settimana in cui si doveva finalizzare la mozione comune io ero via per presiedere la riunione MPEG e la mozione comune non è stata raggiunta. Ho quindi deciso di non partecipare alla votazione.
Io penso che il DIS 29500 sia solo il primo grosso esempio di applicazioni proprietarie che si vogliono convertire in standard internazionali ed è quindi importante, come industria IT, che si abbandonino gli orti recintati e si pensi al bene generale dell'industria (il che vuol dire al bene di chi usa i suoi prodotti, cioè noi).  Io non so quale sarà il risultato del ballot DIS 29500. Se lo standard sarà approvato è possibile che non si riesca a creare un mercato orizzontale di prodotti interoperabili multisorgente (scusa l’ipotetica di secondo tipo, ma non ho avuto tempo di leggere le alcune migliaia di pagine del documento). Se lo standard non sarà approvato continueremo ad avere centinaia di milioni di utenti che usano applicazioni proprietarie.
Un ultimo commento. Tu parli di "modalità non proprio trasparenti" di voto.
Io non vedo dove c'è stata mancanza di trasparenza.

MC: Leonardo, affronto subito la questione della trasparenza. Mi riferisco alla contemporaneità della procedura privilegiata  (fast track) seguito per DIS29500 (possiamo chiamarlo da ora in avanti OOXML per facilitare la comprensione dei lettori?) e il grande numero di iscritti dell'ultima ora al solo scopo di influenzare il risultato della votazione e senza specifiche o addirittura senza nessuna competenza di merito su OOXML. L'altissima adesione, anche se dell'ultimo momento, SENZA fast track potrebbe essere anche positiva, ma CON la procedura di fast track, in tutta onestà, appare molto sospetta, tanto sospetta che nel national body svedese (Sis) hanno colto un dipendente di Microsoft con le mani nella marmellata e sono stati costretti ad annullare il voto svedese.

Come sai, benchè lo avessi persino annunciato nel mio blog, all'ultimo momento ho deciso di non iscrivermi a UNINFO. Adesso, in tempi non più sospetti, potrei essere disposto a farlo se UNINFO mi garantisse almeno l'impegno ad attivarsi con ISO per fare eliminare la procedura fast track. Infatti il processo incrementale che hai descritto in relazione a Open Type di MPEG mi sembra non solo ottimo, ma il migliore  possibile in questi contesti.

Allo stesso modo mi sembra necessario introdurre nel processo incrementale MPEG-like la disponibilità di una reference implementation, completa di test di conformità e rilasciata con licenza open source adatta allo scopo. Queste mi sembrano condizioni ragionevoli per avere la speranza che in futuro non si assista più al tentativo di standardizzare formati e protocolli proprietari al solo scopo di continuare a mantenere un monopolio di un mercato, soprattutto nei mercati della pubblica amministrazione. Ma a mio avviso ne manca ancora una: la liberatoria sull'uso degli eventuali brevetti contenuti nelle specifiche e/o nella reference implementation di quelle specifiche.

Ecco a tutte queste condizioni insieme darò il mio benvenuto a OOXML. Viceversa, e ho il timore che si realizzi, continuerà a non esistere un mercato orizzontale competitivo delle applicazioni d'ufficio.

Mi interessa adesso approfondire una cosa molto interessante di cui hai accennato: la disponibilità di un gruppo di aziende italiane a realizzare la reference implementation di OOXML. Ci puoi dire qualche cosa di più in proposito? La mia personale preoccupazione in proposito sono i tempi di realizzazione.

LC: Mimmo, il fast track è una cosa parecchio complicata e non vorrei dire delle cose che, per la loro incompletezza, portino a dei fraintendimenti. La scusa che viene abitualmente portata per giustificarla è che il processo ISO è molto lungo e pesante. Questo non è vero. Se la tecnologia è matura ci si mette anche solo un anno. Questa è stata all'incirca la durata dello sviluppo di  Open Font Format.

UNINFO potrebbe farsi promotore della rimozione del fast track dell'ECMA presso il JTC1.
Per la reference implementation ed il conformance testing di OOXML (che io però preferisco chiamare ISO/IEC DIS 29500, proprio per marcare il distacco dal prodotto commerciale) penso sarebbe bello vedere un gruppo nutrito di aziende, specie se membri UNINFO, farsi avanti e dichiarare il loro interesse per poi far pressione su UNINFO che diventi il portabandiera della proposta intorno a cui coagulare l'interesse di altri national body. In questo modo is potrebbe andare al ballot resolution meeting di febbraio prossimo con una proposta operativa che, spero, trovi d'accordo la maggioranza dei national body.

Per quel che riguarda la natura open source della reference implementation ed i brevetti, io penso che la "licenza MPEG" è, a tutti gli effetti, open source e dovrebbe essere accettabile. Per i brevetti non saprei perché è un tema difficile, ma io penso che anche qui la quadra si dovrebbe trovare.

MC: Leonardo, spero che sulla rimozione di fast track si possano trovare ampi consensi da entrambe le parti in gioco. Sarebbe un ottimo segnale per ridare credibilità a ISO, che nella querelle OOXML molti ritengono ne sia uscita un poco malconcia, ma anche per ritrovare uno spirito di collaborazione e negoziazione che sembrerebbe essenziale nel processo di definizione di uno standard internazionale e condiviso.

La fattibilità della reference implementation  è un punto molto delicato. Solamente con il diretto e concreto impegno di Microsoft stessa, espresso anche attraverso il supporto alle aziende che si candidassero, la tua proposta troverebbe spazi di realizzabilità in tempi opportuni e credibili. Viceversa, ho davvero il timore che sarebbe utilizzata strumentalmente solo per fare passare OOXML al prossimo ballot di febbraio: "passata la festa, gabbato lo santo".

Riguardo la licenza MPEG la conosco solamente dalle varie chiacchierate che nei mesi passati ho fatto con te quando si doveva proporre a DMP la licenza da adottare per Chillout. Da quanto mi dicevi risultava che con MPEG ti eri inventato una licenza open source ante litteram. Però da parecchi anni c'è OSI che si occupa proprio della certificazione delle licenze open source. Si potrebbe pensare di sottomettere la licenza MPEG ad OSI, ma forse sarebbe più praticabile utilizzare MPL1.1, come proponemmo con il prezioso supporto legale di Carlo Piana per Chillout.

Veniamo al problema dei brevetti software. Come ricorderai quando scegliemmo MPL1.1 lo facemmo soprattutto in considerazione della sua minore nebulosità proprio in riferimento alle eventuali violazioni di brevetti software. Personalmente ritengo che questo sarebbe un altro punto in cui Microsoft dovrebbe manifestare la sua reale volontà di collaborazione cedendo gratuitamente gli eventuali brevetti contenuti nelle specifiche di OOXML (scusami se insisto, ma sono pigro e scrivere l'intero nome della specifica mi da l'orticaria).

Adesso ti faccio una provocazione. Molto forte. Immaginati che le specifiche del DRM interoperabile di DMP avessero già ottenuto il bollino ISO, che Chillout avesse già raggiunto il livello di completezza e di ingegnerizzazione di OpenOffice e che esistessero anche altre implementazioni, magari meno complete, delle specifiche di cui sopra.

Arriva Microsoft e sottomette la sua soluzione proprietaria di DRM a ECMA e, attraverso questa,  accede al fast track per ottenere il bollino ISO.
Come reagiresti?

LC: Non reagirei. MS Office è una suite di applicazioni progettate per rispondere a precise necessità della vita d'ufficio e, di riflesso, della casa. OpenOffice è una buona suite di applicazioni che fornisce in larga parte le stesse funzionalità. Invece Windows Media DRM è certo un'ottima tecnologia, ma sostanzialmente permette di realizzare poco più che i modelli di business del passato. Chi pensa di utilizzare il DRM con la mentalità di ieri scoprirà ben presto di aver fatto male i suoi conti. Chillout invece è stato progettato per permettere a chiunque di farsi il suo DRM con un livello di granularità che Windows Media DRM, oggi, neanche si sogna.

MC: Ti provoco ancora di più: in prossimità del voto, proprio qualche ora prima della scadenza, si iscrivono ai national body moltissimi partner di Microsoft quasi tutti a digiuno di DRM. Dopo le votazioni si scopre anche che ad alcuni di questi partner sono state promesse delle ricompense da dipendenti di Microsoft, come è accaduto nel national body svedese, in cambio del loro voto favorevole.
Come reagiresti?

LC: Penso di aver dimostrato con la mia astensione dal voto che di DIS 29500 quello che mi importa davvero è che ISO si attrezzi a gestire quelli che mi aspetto saranno molti casi futuri di conversione di specifiche proprietarie in standard internazionali.  Questo va fatto con la triade: standard in linguaggio comprensibile dall'uomo (quello di cui si è parlato finora), standard in linguaggio
comprensibile da una macchina (reference implementation) e test di conformità (test suites).

MC: Ok, finalmente ho (abbiamo) capito la vera interpretazione della tua astensione, che non è solo espressione di un comportamento socialmente corretto, ma anche di strategia per il futuro che condivido, anzi ammiro per la sua lucidità.

Attrezzarsi per il prevedibile ricorso a conversioni dei protocolli da proprietari in standard internazionali significa chiedere a ISO di togliere il fast track. Forse qui c'è da approfondire un poco di più. Per esempio c'è da chiedersi se la rimozione del fast track debba limitarsi alle proposte di standardizzazione per le quali esista già uno standard internazionale di riferimento, oppure incondizionatamente.

Benissimo anche per quanto riguarda la triade. Però siccome anch'io conosco un poco i miei polli, specifichiamo di più per togliere qualsiasi ambiguità latente. La reference implementation deve essere rilasciata con una licenza open source OSI compliant non scelta dal proponente. E questo deve essere fatto come primo step del processo immediatamente dopo la proposta di standardizzazione. Nel frattempo, se proprio dovessi dirla fino in fondo, chederei a ISO di definire uno standard internazionale per le licenze open source delle reference implementation di tutti gli standard internazionali che riguardano ciò che può essere rappresentato numericamente (i.e. digitalmente)

Poi bisogna accordarsi sulla questione dei brevetti. So che a te RAND sembra una buona posizione di compromesso. A me, e a moltissimi altri come e molto meglio di me, invece no. Questo è un altro tema di discussione che tu hai già affrontato in MPEG, ma credo si possa migliorare. Che ne pensi?

LC: Riprendiamo un punto alla volta. Togliere il fast track tout court non è ragionevole. Io non ne so abbastanza, ma penso che ci siano dei casi in cui il fast track svolge un ruolo utile, ad esempio nel caso in cui la specifica è stata sviluppata con un processo aperto (e.g. DMP, anche se però il Media Streaming MAF ha seguito tutto il processo normale di votazione come per Open Font Format). Quello che si può chiedere è di togliere il fast track di ECMA (le direttive permettono ad ECMA di mettere un suo standard in fast track. Il problema è che uno standard ECMA può essere sviluppato anche se ci sono solo 5 aziende che lo sostengono.

Per quanto riguarda la reference implementation ISO/IEC 29500 ho già avuto modo di dire in altre occasioni che la licenza dovrebbe fornire il codice sorgente senza alcun costo e consentirne anche l'utilizzo commerciale e la sua modifica, mantenendo però la conformità con ISO/IEC 29500. Questa è una clausola chiave della licenza MPEG. Capisco che l’open source voglia avere libertà completa di cambiare il codice, ma questa va bilanciata con la confusione (alias mancanza di interoperabilità) che si viene a creare nel mercato.

E veniamo ai brevetti. Togliere RAND dall'ISO è come togliere l'Empire State Building da NY. Se però la clausola fosse per applicazioni proprietarie che si vogliono convertire in standard, allora penso che se ne possa parlare.

MC: Va bene Leonardo. Diciamo che il punto di debolezza procedurale, io la chiamerei la backdoor di ISO, è rappresentata dalla procedura di fast track per ECMA. E' un tema che andrà approfondito, magari coinvolgendo chi conosce bene quella procedura e chi, come Carlo Piana, può fornire supporto legale molto competente per limitarne l'applicazione ai casi appropriati.

Anche sulla liberatoria dei brevetti limitatamente ai casi da te citati mi sembra un compromesso che, senza sconvolgere gli interessi delle multinazionali, potrebbe comunque trovare un consenso presso chi, come me, è sempre stato contrario alla brevettabilità del software.

Grazie Leonardo per la tua disponibilità in questa "Prova di Dialogo". Mi sembra che i requisiti ed i paletti che abbiamo individuato meritino di essere messi a frutto per ristabilire un clima di collaborazione utile per il ballot di febbraio sul OOXML, ma in generale per proporre, dall'Italia, una soluzione prospettica ai problemi che ISO dovrà affrontare sempre più spesso nel prossimo futuro.  In questo senso, credo che l'Italia potrebbe farsi promotrice di un'iniziativa locale che sottoponga questi primi principi al giudizio di Microsoft e delle comunità di sviluppatori e sostenitori del FOSS (Free & Open Source Software) italiani per poi provare a proporla agli altri national body di ISO.