#OpenLaw

Standard e open standard, il diavolo si annida nei dettagli

lente ingrandimento

“Sono uomo di mondo, ho fatto tre anni di militare a Cuneo” – Principe Antonio De Curtis (in arte Totò)

Come il più noto commediante italiano, anch’io ho fatto la mia parte per servire la Patria in quel della Provincia Granda, anche se solo per qualche settimana. Lì ho imparato che senza gli 1, in ambito militare le cose si possono fare veramente difficili. Cominciamo con “Alfa, Bravo, Charlie, Delta, Echo, Foxtrot, Golf, Hotel, India, Juliett, Kilo, Lima, Mike, November, Oscar, Papa, Quebec, Romeo, Sigma, Tango, Uniform, Victor, Whisky, X-ray, Yankee, Zulu”. È l’ABC degli standard, anzi, lo standard dell’ABC. È l’alfabeto fonetico, standard NATO. Se non lo conosci a memoria, non puoi comunicare via radio; così è per quasi tutto quanto accade nella vita militare: se sei un militare non hai spazio per ambiguità. Dai gradi (per sapere chi comanda su chi) fino al calibro delle pallottole, tutto è standard.

“Standard”, effettivamente, viene dal francese antico “estandart” o “estandard”, stendardo, bandiera, che in effetti richiama i campi di battaglia e gli eserciti schierati in file ordinate. Ma sbaglieremmo a pensare che solo in ambito militare esistono standard. Come misuriamo il tempo dipende da uno standard, come scriviamo il tempo dipende da uno standard. Come misuriamo qualsiasi cosa dipende da uno standard. È importante ovviamente che le misure siano conosciute e che qualsiasi necessità di conversione tra uno standard e l’altro sia precisa e dichiarata, altrimenti succedono disastri. Se non dico che l’ora in cui fisso una conferenza telefonica corro al massimo il rischio di perdere qualche partecipante; ma se non dico che una pressione è in libbre per pollici quadrati e l’altro pensa che sia (come dovrebbe) in kilogrammi per metro quadro, succedono disastri ben peggiori. Nel 1999 il Mars Polar Orbiter si schiantò al suolo perché alcuni dati di volo vennero inviati in libbre/secondo invece che in newton/secondo, buttando a mare quasi 330 milioni di Dollari USA. La stessa cosa capiterebbe anche a noi se nell’aviazione non ci fossero centinaia di standard, da quelli di sicurezza a quelli sulla navigazione e ai sistemi di identificazione e atterraggio.

Quasi tutto ciò che facciamo, in realtà, si basa sugli standard. È standard la presa con cui colleghiamo il computer alla corrente, è standard la corrente, è standard la codifica dei file, è standard il cavo di rete, è standard la presa di rete (o se usiamo il Wi-Fi, è standard pure quello), è standard il protocollo che stabilisce la connessione e assegna l’identificativo Internet; tutta Internet, da un punto di vista logico, non è che una somma di standard. È standard il formato di file con cui scriviamo il documento che contiene questo articolo. Se guardiamo la televisione, via satellite (DVB), via satellite (DVBT) è tutto uno standard; se guardiamo un filmato su Youtube, pure quello è uno standard (anzi due, uno per il video e uno per l’audio, anzi, tre, uno per il contenitore, WebM, anzi quattro, perché il se e il come il filmato viene mostrato dipende da un altro standard, HTML).

C’è standard e

Chi fa gli standard? Fornire una risposta a questa domanda è praticamente impossibile. Abbiamo standard formali e standard informali (la posta elettronica e molti degli standard di Internet sono delle RFC, mai adottati formalmente e gestiti in larga parte dall’IETF). Esistono poi enti di standardizzazione formale “istituzionali” a livello nazionale (ad esempio UNI in Italia, DIN in Germania, BSI nel Regno Unito, ANSI negli Stati Uniti), a livello europeo (ETSI, CEN), e internazionale (ISO, ITU, IEC). E poi vi sono quelli su base consortile (OASIS, ECMA, Bluetooth, W3C). Un bel guazzabuglio.

Ma a noi, in questa sede, non importa più di tanto come gli standard sono formati e da chi (se non quando succede un problema, come vedremo poi con il famigerato OOXML). Ci importa sapere cosa accomuna gli standard. Tutti gli standard, ufficiali e formalizzati (de jure) o non ufficiali e informali (de facto) si caratterizzano per essere una norma, e infatti un sinonimo dell’attività di creazione degli standard è “normazione” e così si specificano gli enti che se ne occupano. Si tratta di un norma di per sénon cogente, se non quando vi fa espresso riferimento una legge o un atto normativo dello stato o internazionale. Gli standard vengono rispettati perché e in quanto sono diffusamente adottati e non adottarli comporta problemi difficilmente insuperabili. La norma diventa “cogente” se non posso fare altrimenti che seguirla, salvo trovarmi a mal partito (o peggio, violare la legge). Se entro in un ristorante francese e non so il francese, probabilmente non mangio, o corro il rischio di mangiare cose che non volevo.

Norma, dicevamo, dunque regola. Chi di solito fa le regole? Come nello sport, non è mai uno dei giocatori, o almeno non dovrebbe. E come seguire le regole se non le conosco? E mettiamo che le conosco, ma se una volta che le ho imparate, mi si cambiano le carte in tavola, e io non faccio in tempo a prepararmi, ma qualcun altro sì, perché lo sapeva prima? E se ancora, si impone di usare un pallone speciale, ma io non posso allenarmi con quel pallone, salvo poi trovarmelo in campo contro le altre squadre?

Le regole, devono essere fatte in un certo modo, altrimenti qualcuno è nei guai, e qualcun altro ci marcia. Entrano in campo gli standard veramente imparziali e non distorsivi, ovvero gli standard aperti. Siccome ci piace usare l’inglese “Open Standard”.

Standard Aperti

Non esiste una definizione di open standard. Quando si cerca di adottarne una, ci si trova un fuoco di sbarramento fatto di lobbying selvaggio, disinformazia, agenti doppi, non un quadro edificante. Lo dico per esperienza personale, per esserci entrato in occasione di OOXML (ci arriviamo, ci arriviamo…) e in occasione di vari dibattiti in cui si è tentato di trovare una definizione efficace, come nel caso dell’European Interoperability Framework, che in effetti adottò una formulazione quasi accettabile di open standard, e infatti quando si è passati alla versione 2, quella parte è stata rimossa perché contro di essa si sono mossi mari e monti.

Ma chi è intellettualmente onesto non può che rinvenire alcuni tratti fondamentali su cosa definisce uno standard aperto. A partire dal fatto che uno standard aperto è… aperto alla sua adesione da parte di tutti e non crea indebiti vantaggi o posizioni di dominio da parte di qualcuno su qualcun altro. Qui do alcune indicazioni su ciò che uno standard aperto debba rispettare, nella definizione che ho contribuito a fissare per FSFE

Uno standard è aperto quando è accessibile

Questa è facile. Lo standard è una norma, la norma deve essere conosciuta per essere osservata. Lo standard deve essere dunque pienamente conoscibile. Per cui deve essere compiutamente documentato. Gli standard non debbono completamente documentare tutto, ma quello che non documentano deve essere facilmente derivabile da altri standard. Anzi, gli standard devono riutilizzare gli altri standard, dove possibile, e non inventare nuovi modi per parti di esso che siano già standardizzate.

Corollario a questo principio è che uno standard non può fare riferimento a un prodotto, un servizio una tecnologia non standard, o peggio, proprietaria. Uno standard che dovesse indicare “fai questa cosa qui come la fa l’applicazione X del produttore M” non sarebbe uno standard aperto, e non sarebbe uno standard completo.

Tali documenti, poi, debbono essere resi “pubblici”. Ciò non significa che essi non possono essere coperti da copyright e ceduti sotto condizioni proprietarie: tali condizioni non debbono essere discriminatorie o eccedere i costi di formazione dello standard e di produzione del documento, ovvero costi nominali dell’opera. Se munirsi di una copia dello standard dovesse costare eccessivamente, solo chi ha sufficienti disponibilità economiche potrebbero accedervi. Se solo chi ha una qualifica particolare può accedere il documento, questo sarebbe discriminatorio. L’accesso pubblico significa “a chiunque sia disposto a pagare una ragionevole somma, non eccessiva, se richiesta, e senza che qualcuno possa opporre un rifiuto”.

Uno standard è aperto quando è gestito imparzialmente

La partecipazione alla formazione degli standard da parte delle imprese e degli altri operatori interessati è una elemento essenziale nella formazione degli stessi. Solo chi conosce un campo di applicazione può avere idea di cosa può essere standardizzato e come. Di solito si adottano le scelte operative più intelligenti dei primi che hanno affrontato il problema. Il principio base è dunque quello del raggiungimento di un consenso tra tutti gli operatori.

Uno standard “buono” è normalmente uno standard formato democraticamente, in cui tutti gli interessati hanno avuto modo di dire la loro e nessuno prevale in modo abnorme sugli altri partecipanti. In realtà questa non è una regola necessaria. Esistono buoni standard in cui la tecnologia è stata fornita unilateralmente da un operatore, il quale la ha compiutamente descritta in maniera standard (esiste uno standard su come si scrivono gli standard) e ha concesso a tutti il permesso di usare tale tecnologia. È il caso del PDF, che è stato “donato” da Adobe e formalizzato in uno standard ISO (ISO 19005). Qui la genesi non è certo imparziale, ma una volta che il formato è stato proposto come standard aperto, la conduzione ulteriore dello stesso è affidata a comitati tecnici in sede ISO, la cui partecipazione – come per tutti i comitati tecnici di ISO – è aperta a tutti.

Dunque, originalmente o successivamente a una “donazione”, lo standard è affidato a un ente imparziale, non legato o dominato da un attore dominante, ad accesso democratico.

Uno standard è aperto quando non discrimina

Uno standard dovrebbe essere il tecnologicamente neutro possibile, ovvero non privilegiare ingiustificatamente una piattaforma rispetto a un’altra, una tecnologia rispetto a un’altra, un’impresa piuttosto che un’altra, per quanto possibile. Dunque dovrebbe osservare un principio di prudenza nel non prevedere l’adozione di tecnologie esterne e non standard, o peggio, la necessità di ottenere il permesso da qualcuno per utilizzare tutta o parte della tecnologia necessaria.

Condizione necessaria e sufficiente per implementare uno standard dovrebbe essere necessario unicamente conoscere lo standard (e gli standard di riferimento sui cui lo stesso si basa). Il resto dovrebbe essere solo “delivery”.

Standard e brevetti: questo matrimonio non s’ha da fare (rinvio)

Siccome uno standard diventerà una norma, e soprattutto negli standard tecnologici più uno standard è utilizzato, più tende ad essere utilizzato (effetto di rete) a prescindere anche da quanto merito tecnico esso abbia, sono ovvie le interazioni tra standard e concorrenza. Pertanto, per quanto possibile, gli standard dovrebbero essere privi di condizioni legali che tendano a privilegiare le offerte di alcuni a scapito di altri, e soprattutto dovrebbero evitare quella che si chiama “patent holdup”, ovvero la posizione di supremazia di chi ha brevetti essenziali per l’implementazione di uno standard.2

E qui, sovente, casca l’asino. In difetto di una precisa politica che consenta l’utilizzo degli standard a tutti, indipendentemente dal modello di business e di licenze, occorre che vi siano chiare regole sia per chi contribuisce agli standard (dichiarare l’esistenza di propri brevetti, impegnarsi a licenziarli sotto determinate regole), sia per chi approfitta delle lacune o delle imprecisioni degli enti di standardizzazione per porsi in posizione di controllo, spesso identica a quella dei famigerati troll.

Questo è un campo di indagine molto complesso, che sospendiamo solo momentaneamente.

OOXML e altri orrori

OOXML è lo standard documentale XML spinto (per usare un eufemismo) da Microsoft. La storia è molto lunga ed è anche in certo modo la summa di ciò che non si dovrebbe fare in una standardizzazione. Lo standard serve a codificare i documenti di Microsoft Office in formato XML (altro standard).

Lo standard soprattutto evidenzia difetti in tutte le aree di cui ho parlato sopra, forse (e dico forse) con l’unica esclusione dell’interferenza di brevetti.

Andiamo in ordine sparso. Il primo peccato capitale è che si tratta di uno standard che viene adottato su proposta di una e una sola azienda, senza che vi sia una che sia una implementazione di esso che sia in qualche modo completa. E ciò non lo è stato per diversi anni. Soprattutto quando esiste un diverso standard (ISO IEC IS 26300 – ODF) per esattamente lo stesso dominio. Le buone pratiche vorrebbero che Microsoft si mettesse in gioco e spingesse perché tale standard evolva fino a coprire le esigenze non coperte dallo stesso. Invece lo rimpiazza con un secondo standard completamente nuovo.

Lo standard poi si limita a riflettere pari-pari il comportamento delle applicazioni di Microsoft, non a descrivere le funzioni in astratto e a risolverle in modo astratto e imparziale. Arriva persino a codificare gli errori, fenomenale fu quello di ripetere l’omissione dell’anno non bisestile negli anni zero dei secoli non divisibili per quattrocento, che è la modalità in cui si contano le date nel calendario Gregoriano (che è anch’esso uno standard: ISO 8601.3 Ciò solo per un bug mai corretto di Microsoft Excel.

Lo standard venne proposto con una procedura accelerata (“Fast Track”) nonostante ci fossero molte perplessità sull’esperibilità di tale procedura e in vari enti nazionali (ISO è un ente “federato” in cui partecipano gli enti nazionali, in Italia l’ente nazionale competente era Uninfo, in seno a UNI) si sollevarono centinaia di osservazioni, che vennero risolte in modo molto grossolano in un “Ballot Resolution Meeting” in quel di Ginevra, segno che lo standard doveva essere approvato più o meno ad ogni costo. Le stesse procedure nazionali lasciarono molti perplessi, me compreso. In Italia, ad esempio, nei mesi precedenti alla votazione, si osservò un’impennata di iscrizioni ad Uninfo a cui molti hanno attribuito un significato preciso: quello di un tentativo di modificare gli equilibri in gioco per far passare (o non passare, ma in misura assai minore) lo standard, al di là del suo merito tecnico. Lo standard stesso era composto da circa 6000 pagine, che probabilmente nessuno dei partecipanti (se mai qualcuno) ha letto integralmente.

Ma al di là di tali episodi, su cui ognuno manterrà le proprie opinioni, è il concetto stesso che si possa standardizzare a partire da un’applicazione singola per creare uno standard che non è condiviso, ma replica in maniera ossessivamente pedissequa ciò che fa un’applicazione, a detrimento di tutte le altre, a fare a pugni con la stessa concezione di standard. Il fatto che il principale sponsor di quello standard fosse una società che proprio in quel periodo era stata condannata per condotte abusive esattamente per la creazione di standard di fatto usati in modo anticoncorrenziale, anche se in ambiti non sovrapponibili, lascia alquanto perplessi circa tale standard.

Non che gli altri siano indenni da critiche. Lo vedremo nella prossima puntata.


  1. Per ulteriori letture in tema di standard, vedi i vari contributi su Techeconomy da parte, tra gli altri, di Italo Vignoli. Vedi anche di Simone Aliprandi “Apriti Standard”.
  2. Per un’ottima analisi, si veda Dolmans, Maurits (2010) ‘A Tale of Two Tragedies – A plea for open standards, and some comments on the RAND report’, IFOSS L. Rev., 2(2), pp 115 – 138 DOI: 10.5033/ifosslr.v2i2.46 con una mia introduzione.
  3. Per un’interessante disamina, se interessati, si può consultare la pagina di Wikipedia.
Carlo Piana

Carlo Piana

Avvocato, si occupa dal 1995 di diritto delle nuove tecnologie. Nel 2008 fonda Array, una non-law-firm (“Array è un array”) orizzontale tra esperti di IT law ‒ focalizzata in particolar modo su e mondo open.

General Counsel della Free Software Foundation Europe, è membro del Board di euroITcounsel euroITcounsel , circolo di qualità tra alcuni dei più prestigiosi studi legali IT in Europa, e del Comitato Editoriale dell’International Free and Open Source Software Law Review [http://ifosslr.org], l’unica rivista internazionale peer-reviewed dedicata a Software Libero e a tutto il mondo open.

Ha partecipato alla commissione dell’Agenzia per l’Italia Digitale per il Regolamento Applicativo dell’Articolo 68 del Codice dell’Amministrazione Digitale ed è co-autore di “Ensuring utmost transparency — Free Software and Open Standards under the Rules of Procedure of the European Parliament, e di “Legal aspects of free and open source software”.

Clicca per commentare

Commenti e reazioni su:

Loading Facebook Comments ...

Lascia una replica

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

No Trackbacks.

TechEconomy è il portale di informazione dedicato a manager, imprenditori e professionisti che vogliono approfondire e comprendere l’impatto delle tecnologie nello sviluppo del business nelle PMI come nell’industria, nella finanza, nei servizi.
Si rivolge insomma a tutti coloro che vogliono capire come le nuove realtà dell'Information Technology - Web 2.0, e-Business, net economy - stiano cambiando l’economia, e con essa la società.
Inizio
Shares
Share This