# Open source, software libero e altre libertà/Standard e open standard, il diavolo si annida nei dettagli

../Ponti, torri, vele e lo strano caso della libertà di panorama ../Open standard e brevetti IncludiIntestazione 13 maggio 2019 100% Da definire
Open source, software libero e altre libertà Carlo Piana 2018 CC BY-SA 3.0 GFDL Indice:Carlo Piana - Open source, software libero e altre libertà.pdf //it.wikisource.org/w/index.php?title=Open_source,_software_libero_e_altre_libert%C3%A0/Standard_e_open_standard,_il_diavolo_si_annida_nei_dettagli&oldid=- 20190513173811 //it.wikisource.org/w/index.php?title=Open_source,_software_libero_e_altre_libert%C3%A0/Standard_e_open_standard,_il_diavolo_si_annida_nei_dettagli&oldid=- 20190513173811
[p. 83
“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 standard, in ambito militare le cose possono farsi 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 [p. 84 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 comunico correttamente 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 [p. 85 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 dipendono da un altro standard, HTML, e così via).
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
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 conosca, ma se una volta che le ho imparate mi si cambino le carte in tavola e io non faccia in tempo a prepararmi, ma qualcun altro sì, perché lo sapeva prima? E ancora se 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”.
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 [p. 87 dell’Europe-an 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 la Free Software Foundation Europe.
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 aperto non può fare riferimento a un prodotto, un servizio una tecnologia non standard, o peggio, proprietaria. Uno standard che dovesse indicare “fai
Tali documenti, poi, debbono essere resi “pubblici”. Ciò non significa che essi non possono essere coperti da copyright e diffusi sotto condizioni proprietarie (anche dietro il pagamento di un prezzo): 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 potrebbe accedervi. Se solo chi ha una qualifica particolare può accedere al 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”.
La partecipazione alla formazione degli standard da parte delle imprese e degli altri operatori interessati è un 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 [p. 89 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 l’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, ISO 32000). 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 controllato da un attore dominante, ad accesso democratico.
Uno standard dovrebbe essere il più neutro possibile sul piano tecnologico, 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 richiedere l’adozione di tecnologie esterne non standard, o peggio, non dovrebbe implicare la necessità di ottenere il permesso da qualcuno per utilizzare tutta o parte della tecnologia necessaria.
Condizione necessaria e sufficiente per implementare uno standard è conoscere lo standard (e gli [p. 90 standard di riferimento su cui lo stesso si basa). Il resto dovrebbe essere solo “delivery”.
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.
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
Questo è un campo di indagine molto complesso, che sospendiamo solo momentaneamente. Ne parleremo nel prossimo capitolo.
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é quest’ultimo standard evolvesse fino a coprire le esigenze non coperte dallo stesso. Invece lo rimpiazza con un secondo standard completamente nuovo.
Lo standard poi si limita a mimare e coprire pari-pari il comportamento delle applicazioni di Microsoft, non a descrivere in astratto le funzioni che il software deve implementare e a risolverle in modo [p. 92 altrettanto astratto e imparziale. Arriva persino a codificare come parte dello standard gli errori delle applicazioni, 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). 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 seimila 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 [p. 93 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 standard siano indenni da critiche. Lo vedremo nel prossimo capitolo
* ↑ Per ulteriori letture in tema di standard, vedi i vari contributi su Techeconomy da parte, tra gli altri, di Italo Vignoli http:// www.techeconomy.it/author/italo-vignoli/. Vedi anche di Simone Aliprandi “Apriti Standard” http://www.aliprandi.org/apriti-standard/.
* ↑ https://ietf.org/.
* ↑ http://ec.europa.eu/idabc/en/document/2319/5938.html.
* ↑ http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pd
* ↑ https://fsfe.org/activities/os/def.en.html.
* ↑ 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 (http://dx.doi.org/10.5033/ifosslr. v2i2.46) con una mia introduzione. Si veda inoltre uno studio affrontato dalla Commissione Europea in tema di Standard Essential Patents (SEP) e condizioni di licenza (in generale): https://ec.europa.eu/growth/industry/intellectual-property/patents/standards_it.
* ↑ Per un’interessante disamina, se interessati, si può consultare la pagina di Wikipedia https://it.wikipedia.org/wiki/ISO_8601.
* ↑ http://www.uninfo.it/