Apriti Standard!/Capitolo primo

by Simone Aliprandi

Capitolo primo

../Prefazione ../Capitolo secondo IncludiIntestazione 31 marzo 2024 100% Da definire

Questo testo è stato riletto e controllato.

Simone Aliprandi - Apriti Standard! (2010)

Capitolo primo

◄

Prefazione

Capitolo secondo

►

Capitolo primo

Apertura, interoperabilità, neutralità:

i semi dell’innovazione

1. Tecnologie libere... da che cosa?

È ormai dagli anni 80 che si sente parlare di software libero e più generalmente della “libertà” come valore da perseguire in fatto di sviluppo tecnologico e più specificamente informatico. Ma in che senso si parla di libertà? Da che cosa dovrebbero essere “liberati” l’ideazione e lo sviluppo di soluzioni tecnologiche?

L’ambito tecnologico è quello in cui maggiormente si fa sentire la pregnanza della tutela giuridica. Se pensiamo infatti agli strumenti tipici del diritto industriale (ovvero diritto d’autore, brevetto, tutela del marchio, segreto aziendale, norme sulla concorrenza) ci rendiamo conto che il settore ICT è l’unico nel quale queste tutele vengono applicate contemporaneamente e in sovrapposizione; un settore, tra l’altro, nel quale esse vengono difese con la massima strenuità e determinazione da parte dei loro titolari, anche a causa degli elevati interessi economici in gioco.

Senza entrare nel merito dell’opportunità e della legittimità di questa prassi (tema su cui sono già state scritte innumerevoli pagine e di cui si farà cenno diffusamente nei capitoli di questo libro), non vi è dubbio che essa si sia consolidata proporzionalmente alla rilevanza degli interessi commerciali degli operatori del settore. Fin tanto che lo sviluppo di tecnologia è attività di pura ricerca riservata quindi ad appositi centri ed operatori specializzati, difficilmente viene percepita l’esigenza di tutelare e controllare il frutto della proprio attività di sviluppo con strumenti di natura giuridica. Può sussistere al massimo un’esigenza alla loro segretezza, o più generalmente ad un riconoscimento della paternità intellettuale di una creazione, di una invenzione, di una soluzione tecnico-scientifica.

Pensiamo al caso emblematico del software, che appunto è attualmente una di quelle creazioni intellettuali che godono di una tutela giuridica multipla e sovrapposta. Esso nasce come opera tendenzialmente libera da tutela industriale; tuttavia quando la sua produzione è arrivata ad un sufficiente livello di maturità, il software ha iniziato ad acquisire una sua autonomia rispetto alle componenti hardware e ad essere considerato un prodotto da distribuire e commercializzare indipendentemente. Ecco, è in questa fase cruciale che le aziende impegnate in questo nuovo mercato sentono l’esigenza di tutelare i loro investimenti con strumenti di tutela giuridica; e il mondo del diritto (quello degli studiosi prima e quello dei legislatori poi) si trova a dover fornire delle risposte a questa esigenza che siano praticabili e sostenibili.

Si aprì dunque un dibattito in seno alla comunità scientifica di giuristi ed economisti su quale fosse il modello di tutela più adatto e si pensò che non fosse necessario creare un modello ad hoc ma che invece fosse sufficiente guardare ai modelli di tutela classici del diritto industriale: il copyright e il brevetto. Sulla base di riflessioni (per altro illuminate) che non è il caso di approfondire in questa sede¹, la scelta ricadde sul copyright. Si pensò infatti di considerare il software (specificamente nella sua forma di codice sorgente) alla stregua di un’opera letteraria, trattandosi in effetti di un testo dotato di una sua sintassi e di una sua valenza espressiva (anche se comprensibile solo a chi conosce i linguaggi di programmazione). Il legislatore statunitense emise dunque una legge (il Software Copyright Act del 1980) che poneva i principi per l’applicazione del copyright ai programmi per elaboratore; e nell’arco di pochi anni tutti i principali paesi tecnologicamente avanzati seguirono l’esempio (Australia nel 1984, Gran Bretagna, Francia e Germania nel 1985, Comunità Europea con direttiva del 1991, Italia nel 1992 in attuazione della direttiva europea).

Di riflesso, i produttori di software iniziarono a distribuire software coperto da copyright, accompagnandovi dei documenti in cui indicavano una serie di restrizioni per l’utente dell’opera: si tratta delle cosiddette licenze d’uso, nuovo tipo contrattuale attualmente molto diffuso nel settore ICT. Tuttavia, oltre a questa barriera di natura giuridica, essi pensarono che fosse opportuno porne una ulteriore, questa volta di natura tecnologica. Così per evitare che gli utenti del software ne facessero usi che andassero al di là di quelli consentiti nelle licenze d’uso, si iniziò a distribuire il software unicamente sotto forma di codice binario (ovvero il codice leggibile solo dal calcolatore), senza quindi il relativo codice sorgente.

Questo non è tutto. La deriva iper-protezionistica² delle creazioni a carattere informatico proseguì e arrivò nel giro di non molti anni dalla nascita di questo settore industriale a trovare nuove forme per controllare gli utilizzi non autorizzati delle creazioni. E ancora una volta si cercò di far leva su fattori di natura giuridica e di natura tecnologica, ad esempio spingendo verso la possibilità di brevettare algoritmi e piccoli frammenti di software (già coperto da copyright) e implementando meccanismi digitali di controllo delle copie distribuite (i cosiddetti Digital Rights Management systems, o DRMs)

Un quadro come questo non poteva essere però tollerato da coloro che avevano fatto dello sviluppo di software una specie di missione intellettuale: i cosiddetti hacker, nel senso originario (e più corretto) del termine³. Alcuni di essi, capitanati dal ricercatore del MIT di Boston Richard M. Stallman, pensarono che fosse necessario trovare un escamotage per continuare a condividere e a sviluppare liberamente il software come avevano fatto fino a quel momento. Nacque così l’idea di free software (con free nel senso di libero e non di gratuito) e la soluzione del copyleft: un particolare meccanismo giuridico di inversione degli effetti del copyright, basato su licenze d’uso che, invece di vietare usi dell’opera, trasmettessero una serie di libertà ai suoi utenti.

Da quel momento si iniziò a diffondere l’idea di libertà come un valore etico fondamentale per lo sviluppo di tecnologie informatiche: libertà dai vincoli giuridici della cosiddetta proprietà intellettuale, libertà dalle ottiche prettamente economiche che svilivano il software da oggetto di innovazione tecnologica a prodotto commerciale, libertà dalle valutazioni meramente strategiche delle aziende produttrici che andavano a scapito di una virtuosa condivisione delle conoscenze informatiche.

2. Aperto in che senso? L’idea di openness

A metà degli anni 90 si aprì un dibattito su come rendere più appetibile alle imprese dell’ICT (e quindi non più solo alla comunità degli hackers) lo sviluppo di software in uno spirito per l’appunto libero dalle ormai tradizionali barriere di natura tecnica e giuridica che abbiamo brevemente illustrato nel paragrafo precedente. Alcuni attivisti del settore proposero una nuova definizione che potesse porre l’accento non tanto sull’aspetto etico della libertà quanto sull’aspetto tecnico dell’apertura del codice sorgente.

Si iniziò così a parlare di “open source” e tale termine ebbe un notevole successo grazie alla sua particolare efficacia semantica e comunicativa. Superata la fase della scelta terminologica, bisognava stendere le linee guida di questa nuova realtà. Uno dei suoi massimi fautori, Bruce Perens, si preoccupò di redigere la Open Source Definition (OSD), una sorta “decalogo” di riferimento per chiarire a priori cosa potesse essere ricondotto al concetto di Open Source.⁴

Il nuovo termine “open source”, anche se sulle prime fu osteggiato dai puristi del movimento, ebbe un notevole successo. Molti giornalisti e saggisti, volendo sempre più spesso rivolgersi ad un target di non addetti ai lavori e dovendo perciò cercare di non rendere la materia (già di per sé tecnica) troppo ostica, il più delle volte scelsero di utilizzare “open source” proprio per l’efficacia semantica di cui abbiamo già fatto cenno.

Tuttavia tale scelta continuava a generare critiche da parte di chi da più di dieci anni aveva invece combattuto per la diffusione del concetto di “software libero” (inteso nel suo senso originario). Il dilemma era (e forse è tuttora) abbastanza sterile, dato che nella maggior parte dei casi tali autori impegnati nell’opera di divulgazione parlavano dello stesso fenomeno; e di certo non poteva essere loro imposto di allegare sempre ai propri testi un noioso preambolo con le dovute precisazioni terminologiche e la citazione delle due definizioni.

Ecco che nei primi anni 2000 qualcuno si adoperò per coniare un ulteriore termine che risultasse più neutrale e nello stesso tempo rendesse il giusto tributo a tutte le frange del movimento. Si cercò non solo una neutralità “ideologica” ma anche linguistica, con uno sguardo alle principali lingue dei paesi industrializzati. Nacque così nel 2001 nell’ambito di un progetto di ricerca della Commissione europea⁵ l’acronimo “FLOSS” che sta per “Free/Libre/Open Source Software”.

La L in FLOSS vuole enfatizzare il significato di “libero” della parola “free”, piuttosto che quello di “gratuito”: equivoco piuttosto diffuso che aveva spinto alla ricerca del nuovo termine “open source”. Alcuni non anglofoni preferiscono questo acronimo perché traducibile nelle loro lingue madri; la F può stare per “Frei” in tedesco mentre la L sta per “Libre” in francese e spagnolo, “Livre” in portoghese, e “Libero” in italiano.

In alcuni casi è anche comparso l’acronimo FOSS, nel quale però si perdeva la neutralità linguistica e culturale di cui si è parlato. Ad esso è tendenzialmente preferibile il più completo FLOSS, come d’altronde sostenuto dallo stesso Stallman.⁶

Ad ogni modo, a prescindere da simili elucubrazioni tassonomiche interne al movimento, è ormai dato storico che l’aggettivo “open” abbia visto allargare negli ultimi anni il suo ambito semantico fino ad altri campi non strettamente informatici e sia stato utilizzato per individuare un movimento culturale, uno nuovo approccio, per certi versi addirittura una filosofia.⁷

Infine si noti che, a ben vedere, di “apertura” in un’accezione più ampia di quella strettamente legata allo sviluppo di software si parlava già prima che il termine “open source” iniziasse a circolare massicciamente e che l’aggettivo “aperto” venisse sdoganato in altri ambiti. Si legga ad esempio che cosa scriveva nel 1998 Giorgio De Michelis a proposito della progettazione di artefatti:

«L’apertura è una qualità importante degli artefatti se si vuole che essi siano usabili in contesti sociali ad alta variabilità, come sono quelli che sempre più frequentemente si presentano ai nostri giorni. [...] Un artefatto può essere aperto in molti modi diversi e da molti punti di vista diversi. In primo luogo esso può essere aperto, dal punto di vista del numero di utenti che ammette, se non esclude nessuno, se non richiede procedure complesse per accedervi, se imparare ad usarlo è facile. In secondo luogo, dal punto di vista della sua capacità di combinarsi con altri artefatti, se esso si integra negli ambienti in cui viene situato, se si può comporre con altri artefatti per dare vita a nuovi artefatti più complessi. In terzo luogo, dal punto di vista delle modalità di uso, se offre ai suoi utenti ampi margini di libertà nell’uso che ne possono fare, se offre loro la possibilità di inventarsi il loro modo di usarlo.»⁸

3. L’interoperabilità: alcune definizioni

L’interoperabilità è a detta di molti una delle chiavi di volta della libertà in campo informatico. Senza di essa, infatti, gran parte delle libertà su cui si fonda il sistema del FLOSS rischierebbero di divenire evanescenti e di perdere efficacia nella realtà del mercato dell’informatica e della tecnologia.⁹ Avremo modo di analizzarne con precisione le implicazioni, ma cerchiamo di fornire fin da subito le dovute premesse concettuali.

Rimanendo ad un livello di definizione generica ed enciclopedica, possiamo dire che l’interoperabilità è la predisposizione di un prodotto tecnologico a cooperare con altri prodotti senza particolari difficoltà, con affidabilità di risultato e con ottimizzazione delle risorse.¹⁰ Obiettivo dell’interoperabilità è dunque facilitare l’interazione fra applicazioni software differenti, nonché lo scambio e il riutilizzo delle informazioni anche fra sistemi informativi non omogenei.

Se, alla luce di questa definizione, pensiamo all’evoluzione e alla situazione attuale del mercato dell’informatica di massa, è agevole percepire l’importanza di garantire l’interoperabilità affinché si verifichi una reale concorrenza fra i soggetti in gioco. Le aziende di informatica che detengono le più grosse fette di mercato possono tranquillamente strutturare i loro prodotti in modo tale da non consentire ai concorrenti di competere ad armi pari, integrando così la condotta che il diritto della concorrenza qualifica come “abuso di posizione dominante”.

Pensiamo al caso più lampante di un’azienda di dimensione globale che produce il più diffuso sistema operativo e, servendosi degli strumenti classici del diritto industriale (segreto industriale, copyright, brevetto), non consente ad altre aziende di conoscere le informazioni necessarie per realizzare gli applicativi che funzionino correttamente su quel sistema operativo.¹¹ In questo modo la stessa azienda può accaparrarsi anche il mercato degli applicativi, forte del vantaggio competitivo derivante dalla disponibilità interna di quelle informazioni. Comportamenti simili dovrebbero essere (e per fortuna sono) monitorati e opportunamente sanzionati dalle autorità antitrust.

Proprio per la delicatezza e la centralità per l’economia attuale di tutti questi aspetti, il tema dell’interoperabilità ha assunto negli ultimi anni una particolare rilevanza e anche gli organi politici gli hanno riservato sempre maggiore attenzione. Attualmente, infatti, possiamo disporre di una definizione di interoperabilità decisamente più articolata e completa, nata grazie ad uno studio promosso e concluso nel 2004 da IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens¹² per conto della Commissione Europea con uno sguardo particolare verso le implicazioni di tale problematica in fatto di e-government e rapporti cittadino-pubblica amministrazione. Il frutto di questa ricerca è stato un documento contenente appunto una più precisa definizione del concetto di interoperabilità e la fissazione degli obbiettivi più importanti da perseguire da parte degli stati dell’Unione: il titolo del documento è “European Interoperability Framework for pan-European eGovernment Services”, denominato anche con l’acronimo EIF e con la meno conosciuta versione italiana “Quadro europeo per l’interoperabilità” (QEI).¹³

Al paragrafo 1.1.2. dell’EIF si trova una definizione introduttiva del concetto di interoperabilità, che ricalca a grandi linee quella più generica che si incontra anche in altre fonti meno specialistiche e il cui testo letterale è:

«Interoperability means the ability of information and communication technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge.»

Successivamente, addentrandosi nelle problematiche applicative di tale concetto, l’EIF ci fornisce maggiori elementi definitori, distinguendo tre diverse accezioni di interoperabilità: organizzativa, semantica e tecnica. Lo stesso schema viene tra l’altro riportato da un altro documento, di pari rilevanza e disponibile anche in versione italiana ufficiale, che funge in sostanza da documento attuativo dei principi fissati nell’EIF: il suo titolo italiano è “Interoperabilità per servizi paneuropei di eGovernment” (Comunicazione della Commissione al Consiglio ed al Parlamento europeo del 13 febbraio 2006).

«Si possono individuare tre settori chiave dell’interoperabilità che dovranno essere considerati in sede di attuazione dei servizi di eGovernment, vale a dire l’organizzativo, il semantico e il tecnico:

• l’interoperabilità organizzativa riguarda la capacità di individuare i soggetti interessati e i processi organizzativi coinvolti nella fornitura di uno specifico servizio di eGovernment in vista del raggiungimento di un accordo fra tali soggetti su come strutturare le loro interazioni, vale a dire sulla definizione delle loro “interfacce commerciali”;

• l’interoperabilità tecnica riguarda l’integrazione dei sistemi informatici e del software nonché la definizione e l’uso di interfacce aperte, norme e protocolli per sviluppare sistemi d’informazione affidabili, efficaci ed efficienti;

• l’interoperabilità semantica riguarda il modo per far sì che il significato delle informazioni scambiate non venga perso nel processo, bensì conservato e compreso dalle persone, applicazioni e istituzioni coinvolte.

Il coordinamento è necessario sia all’interno di ciascuno di questi tre settori sia tra l’uno e l’altro di essi.»¹⁴

Anche in ambito italiano sono stati prodotti alcuni interessanti documenti in tema di interoperabilità, specialmente in un senso strettamente connesso al mondo della pubblica amministrazione digitale.¹⁵

A livello nazionale, si segnala fra tutti il numero 38 dei “Quaderni” a cura del CNIPA intitolato “Linee guida allo sviluppo di software riusabile multiuso nella Pubblica Amministrazione”¹⁶, dove l’interoperabilità viene definita come segue:

«La capacità di un sistema software di interagire con uno o più sistemi specificati, scambiando dati mediante un determinato insieme di funzionalità. I dati scambiati sono definiti da un formato standard accettato dai sistemi che interagiscono tra loro e la comunicazione avviene tramite un protocollo concordato.»¹⁷

A livello locale invece risulta particolarmente riuscito ed efficace un documento prodotto specificamente su questo tema dalla Provincia Autonoma di Trento, ovvero la Relazione finale della Task Force Interoperabilità e Open source del 2005, nella quale si legge:

«la Task Force riconosce massima priorità al tema dell’interoperabilità. In particolare, la Task Force individua nelle prassi di impiego ed adozione di formati di scambio dati proprietari chiusi, o gravati da vincoli brevettuali, un impedimento all’effettiva interoperabilità dei sistemi informatici, ed una violazione del principio di libertà nella scelta degli ambienti operativi. Fa pertanto proprio il seguente principio di igiene informatica: “la scelta dell’ambiente operativo non deve influire sulla scambiabilità dei dati”.»¹⁸

Il documento, dopo questa affermazione di principio, entra nel dettaglio del concetto di interoperabilità fornendone un’interessante definizione articolata in due categorie: l’interoperabilità operativa e l’interoperabilità comportamentale. In questo passo emerge già la stretta connessione tra interoperabilità e standard aperti, sulla quale avremo modo di dilungarci.

«Per interoperabilità intenderemo la capacità di sistemi diversi di leggere e scrivere stessi formati di dati e/o di interagire secondo protocolli stabiliti. In questo contesto varrà distinguere tra la capacità di parlare la stessa lingua (intelligibilità del formato dei dati) dalla capacità di aderire ad un medesimo modello comportamentale (adozione di un qualche protocollo definito). Questo secondo tipo di interoperabilità (che diremo operativa) va assumendo una sempre maggiore importanza pratica, via via che l’interazione tra sistemi informatici viene sempre più spesso definita in termini di servizio erogato piuttosto che di dato scambiato (e.g., i cosiddetti Web Service). L’interoperabilità operativa può dunque essere realizzata senza che sussista l’interoperabilità del dato. [...] L’adozione di standard aperti, siano essi riferiti ai formati di dati od ai protocolli, resta comunque condizione necessaria (per quanto non sufficiente) per l’interoperabilità.»¹⁹

Infine è utile citare un’opportuna riflessione del divulgatore informatico Bob Sutor il quale parla di interoperabilità in un’accezione più articolata, come concetto da non confondere con quello di “intraoperabilità”: ovvero una sorta di falsa interoperabilità, in cui permane comunque la predominanza di un prodotto, di uno standard, di una piattaforma rispetto agli altri equivalenti. Così si esprime Sutor sul suo blog:

«I think the word “interoperability” is being similarly abused. When a single vendor or software provider makes it easier to connect primarily to his or her software, this is more properly called intraoperability. In the intraoperability situation, one product is somehow central and dominant, either by marketshare, attitude, or acquiescence.»²⁰

A tal proposito si pensi all’esempio più rappresentativo, cioè quello dei prodotti Apple: secondo la visione di Sutor, potremmo dunque dire che essi realizzano un livello elevatissimo di intraoperabilità ma non di interoperabilitಹ. Lo stesso si può affermare a proposito degli applicativi di una medesima suite: ovvero, a titolo di esempio, nei rapporti fra Word ed Excel di Microsoft, o fra Photoshop e InDesign di Adobe. In questi casi appunto Sutor parlerebbe di “intraoperabilità”.

Fig. 1 - Raffigurazione della distinzione concettuale effettuata da Sutor (fonte: www.sutor.com/newsite/blog-open/?p=1260)

4. Neutralità tecnologica

Per inquadrare con chiarezza questo concetto davvero centrale per tutta la nostra analisi, è opportuno fare idealmente un passo indietro, rispolverare la Open Source Definition (d’ora in poi OSD) di cui si è fatto cenno poco sopra e mettere a fuoco il contenuto di alcune sue parti specifiche.

La OSD dedica infatti un apposito punto alla neutralità: il punto 10, intitolato “Neutralità rispetto alle tecnologie” ed inserito nel testo ufficiale del documento successivamente rispetto agli altri nove. In esso si legge laconicamente:

«La licenza non deve contenere clausole che dipendano o si basino su particolari tecnologie o tipi di interfacce.»

Questo punto va in un certo senso ad ampliare e completare quanto indicato nei punti 5 e 6 della OSD, rispettivamente riferiti al divieto di discriminazione contro persone o gruppi e al divieto di discriminazione per campo di applicazione. Esso non è sempre stato di pacifica interpretazione e ha suscitato nella comunità un interessante dibattito.²²

Inoltre, da qualche anno a questa parte, nei dibattiti legati al tema delle libertà digitali, si sente sempre più parlare di neutralità della rete (net neutrality), ossia di un principio cardine relativo all’architettura delle reti telematiche. In base a questo principio le reti (Internet e le altre reti telematiche) devono funzionare in modo neutrale rispetto al tipo di informazioni che vi circolano. Si tratta a ben vedere di un principio sui cui si è fondata e si è sviluppata Internet come la conosciamo noi oggi ma che è stato negli ultimi anni messo in secondo piano da discutibili scelte sia da parte del mondo politico sia da parte degli operatori del settore per filtrare, incanalare, monitorare i dati a seconda della loro destinazione, della loro natura, dell’applicazione utilizzata per lo scambio.

Una dichiarazione rilasciata da Susan Crawford, membro del consiglio direttivo di ICANN e docente alla Yale Law School, ci aiuta a cogliere al meglio il senso di questo principio:

«Lo strato di trasporto di Internet non dovrebbe essere modellato in accordo con applicazioni particolari ma dovrebbe fornire solo il servizio di trasporto basilare dei pacchetti IP, nella modalità cosiddetta “first come, first served”, sul modello della tecnologia originale di Internet, creata nei primi anni ’70. La discriminazione nella consegna dei pacchetti sulla base del tipo di traffico (tra cui le pratiche che vanno sotto il nome di “quality of service”), rappresenta invece una forma di non neutralità.»²³

Infine in seno alla Comunità Europea si parla da alcuni anni di technological neutrality in riferimento ad alcuni principi sanciti per la prima volta dalla Communications Review del 1999 e ripresi dal Regulatory framework for electronic networks and services (ECNS) adottato con direttiva 2002/21/EC. Lo spirito di questi interventi è quello di armonizzare e conformare le scelte legislative degli stati europei al principio per cui le leggi e i regolamenti degli stati dovrebbero preoccuparsi di fissare gli obbiettivi da raggiungere, senza però imporre o discriminare (e tantomeno esprimersi a favore di) una specifica tecnologia, in modo da garantire di riflesso una maggiore concorrenza e un maggiore pluralismo degli operatori.²⁴

Come si può notare, tutte le succitate declinazioni del concetto di neutralità hanno come comune denominatore la non discriminazione a priori di una tecnologia rispetto ad un’altra. Tuttavia, si tratta di un aspetto davvero complesso ed estremamente pregnante per la regolamentazione dello sviluppo tecnologico e queste declinazioni rappresentano solo alcuni dei modi con cui è possibile intenderlo.

D’altro canto, secondo alcuni la neutralità può essere addirittura intesa in un senso ancor più ampio, riferito allo sviluppo di tecnologie in generale. Si legga ad esempio come si esprime Lawrence Lessig (uno dei più influenti autori su queste tematiche) in un paragrafo del suo fondamentale libro “Il futuro delle idee” intitolato proprio “Piattaforme neutrali”:

«Lo strato critico da proteggere se si vuole garantire l’innovazione nella Rete è lo strato di codice, lo spazio in cui il codice stabilisce il flusso dei contenuti e delle applicazioni. È a questo livello che originariamente Internet adottò il principio dell’end-to-end. Quel principio assicurava che il controllo agisse dal basso verso l’alto; che ciò che succedeva, accadeva perché erano gli utenti a richiederlo; e che ciò che gli utenti richiedevano fosse libero di essere raggiunto. Un compromesso su questo principio è la minaccia più grave all’innovazione. E la pressione al compromesso giunge da coloro che userebbero il proprio potere sull’architettura per proteggere un’eredità monopolistica. Il pericolo si presenta quando il controllo della piattaforma può tradursi in capacità di difesa dall’innovazione».²⁵

In questi termini, la neutralità tecnologica diventa un prerequisito per poter garantire da un lato un vero pluralismo per coloro che sviluppano tecnologia (lato attivo) e dall’altro una vera libertà di scelta per coloro che sono semplici fruitori di tecnologie (lato passivo). E ciò ci riporta a quanto poco fa rilevato in materia di interoperabilità.²⁶

5. Tecnologie ed effetti di rete

Come avremo modo di mostrare diffusamente nei prossimi capitoli, il mondo dello sviluppo di tecnologie è per sua caratteristica particolarmente soggetto a quelli che in gergo vengono chiamati “effetti di rete” (in Inglese “network externalities”).

Gli economisti definiscono “economie di rete” quelle forme di interdipendenza tecnologica, economica, giuridica e psicologica per le quali «l’utilità che un consumatore trae dal consumo di un bene dipende (in modo positivo o negativo) dal numero di altri individui che consumano lo stesso bene (o che lo abbiano acquistato).»²⁷

L’esempio più classico cui si può fare riferimento è quello del telefono, in cui l’utilità di possedere una linea e un apparecchio telefonico è direttamente proporzionale al numero di altri utenti che dispongono della stessa strumentazione (quindi dalla dimensione della rete).²⁸ Che senso avrebbe infatti essere gli unici al mondo ad avere un telefono? A chi potremmo telefonare?

Come vedremo specificamente, in ambito tecnologico è molto facile che, in assenza di regole e di opportuni sistemi di monitoraggio, questi effetti di rete si trasformino in meccanismi di irrigidimento del mercato, fino ad arrivare a veri e propri casi di monopolio, passando per numerosi casi di abuso di posizione dominante.²⁹

In generale, si tenga presente che queste dinamiche, oltre a risultare controproducenti dal punto di vista della libera concorrenza, instaurano meccanismi di lock-in tecnologico, ovvero situazioni che prevedono un costo non marginale a carico di quegli utenti che intendessero passare da una tecnologia all’altra. In molti casi, se non vengono garantiti valori come l’interoperabilità e la neutralità tecnologica, è piuttosto elevato il rischio che l’utente di una tecnologia perda un’ampia fetta della sua possibilità di scelta e si crei una forma di dipendenza da uno specifico fornitore di tecnologia, che tendenzialmente sarà quello che detiene la tecnologia dominante sul mercato.³⁰ Allontanarsi da quella tecnologia per passare ad un’altra comporterà per il singolo utente dei costi (cosiddetti switching costs) troppo elevati; e non ci si riferisce ai soli costi diretti per acquisire la nuova tecnologia, ma anche a tutti gli altri costi indiretti per realizzare effettivamente il passaggio (abbandonando del tutto la tecnologia precedente): formazione del personale, adattamento dell’intero sistema produttivo dell’azienda, cambio dei fornitori e dei consulenti, etc.

A questo si unisca anche un ulteriore aspetto - per così dire - psicologico e cioè riferito a quella specie di “affezione” che noi uomini digitali sviluppiamo verso una tecnologia che ci risulta particolarmente congeniale, intuitiva, performante; o a volte più banalmente verso una tecnologia cui siamo avvezzi da molto tempo, tanto avvezzi che scostarci da essa per avvicinarci ad una soluzione nuova, più evoluta e magari anche più vicina alle nostre esigenze ci comporterebbe uno sforzo intellettuale che non sempre siamo disposti a fare.

Note

1. «A livello dottrinale più che a livello pratico, infatti, a creare dubbi è proprio una caratteristica peculiare del software: la sua funzionalità, ovvero la sua vocazione di opera destinata alla soluzione di problemi tecnici; caratteristica questa che lo avvicina ineluttabilmente alla categoria delle invenzioni dotate d’industrialità. D’altro canto, però, il software appare carente del requisito della materialità considerato da alcuni giuristi come condicio sine qua non per la brevettabilità. Storicamente, inoltre, la tutela brevettuale venne vista con diffidenza dalle aziende produttrici di hardware: esse temevano che tale prospettiva avrebbe attribuito un eccessivo potere alle aziende di software e reso il commercio dell’hardware schiavo delle loro scelte di mercato.» Aliprandi S., Capire il copyright. Percorso guidato nel diritto d’autore, PrimaOra, 2007 (p. 82), disponibile on-line al sito www.aliprandi.org/books.
2. A parlare di “iper-protezione” della proprietà intellettuale nella dottrina giuridica italiana sono nomi autorevoli, fra cui si segnala principalmente Auteri P., Iperprotezione dei diritti di proprietà intellettuale?, in AIDA 2007, Giuffrè, 2008.
3. Al contrario di quanti molti pensano il termine hacker non ha un’accezione di per sé negativa e non individua un pirata informatico, bensì solo un appassionato di programmazione che fa della conoscenza dei segreti della scienza informatica una vera sfida intellettuale. Come infatti sottolinea Sergio A. Dagradi «il termine hacker ha invece una valenza positiva - come già sottolineava Steven Levy all’inizio degli anni ottanta [nel libro Hackers. Eroi della rivoluzione informatica del 1984] - e in tal senso viene assunto da Himanen, riprendendo inoltre le osservazioni che uno di questi stessi hacker, Linus Torvalds [ovvero l’inventore del sistema operativo Linux), riassume anche nel prologo del libro in questione: l’hacker è una persona che programma con entusiasmo, credendo nel potere positivo della diffusione dell’informazione, e cercando di conseguenza di creare software che siano free e possano facilitare a tutti e ovunque l’accesso all’informazione e alle risorse di calcolo.» Dagradi S. A., Informazionalismo, etica hacker e lavoro immateriale, in Jori M. (a cura di), Elementi di informatica giuridica, Giappichelli, Torino, 2006 (p. 30).
4. La Open Source Definition deriva da un precedente documento (sempre ad opera di Perens) chiamato “Linee guida del software Debian”, il cui testo completo è disponibile al sito www.debian.org/social_contract#guidelines.
5. II progetto, coordinato da Rishab Ghosh, ha avuto inizio nel giugno del 2001 e si è chiuso nell’ottobre dell’anno successivo. Per maggiori informazioni si veda il sito del progetto: http://flossproject.org.
6. «There are many people, who, for instance, want to study our community, or write about our community, and want to avoid taking sides between the Free Software movement and the Open Source movement. Often they have heard primarily of the Open Source movement, and they think that we ali support it. So, I point out to them that, in fact, our community was created by the Free Software movement. But then they often say that they are not addressing that particular disagreement, and that they would like to mention both movements without taking a side. So I recommend the term Free/Libre Open Source Software as a way they can mention both movements and give equal weight to both. And they abbreviate FLOSS once they have said what it stands for» (estratto di un’intervista resa da R. M. Stallman presso l’Università di Edimburgo nel maggio del 2004; cfr. www.gnu.org/philosophy/audio/rms-interview-edinburgh-040527.txt).
7. «Openness is a very general philosophical position from which some individuals and organizations operate, often highlighted by a decision-making process recognizing communal management by distributed stakeholders (users/producers/contributors) rather than a centralized authority (owners, experts, boards of directors, etc.).» http://en.wikipedia.org/wiki/Openness. Per un approfondimento del tema si veda invece Cooksey R., I Walk the Open Road: Toward an Open Source Philosophy, tesi di master disponibile on line alla pagina http://opensource.mit.edu/papers/cooksey.pdf.
8. De Michelis G., Aperto molteplice continuo. Gli artefatti alla fine del Novecento, Masson, Milano, 1998 (p. 52).
9. «Open source advocates claim that open source software is the only way to guarantee interoperability and interchangeability, as they are considered synonyms of open standard. This is not true, as there can be closed implementations of open standards, as well as open source programs using their own protocols and formats. [...] The issue of the relationships between open source software and open standards is important and deserves careful consideration. It is necessary to guarantee that an open standard remains really open and is not jeopardized by anybody.» Cerri D. e Fuggetta A., Open standards, open formats, and open source; disponibile on-line al sito www.davidecerri.org/sites/default/files/artopenness-jss07.pdf.
10. Si confronti questa definizione con quella fornita dall’IEEE (ente internazionale che comprende tecnici, ingegneri e ricercatori di tutto il mondo nel settore elettrotecnico ed elettronico, impegnato nella certificazione e nella standardizzazione): «The interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged.» http://en.wikipedia.org/wiki/lnteroperability.
11. A tal proposito si legga quanto scrive Pierluigi Sabbatini a proposito del caso Microsoft: «Ciascuna rete virtuale è caratterizzata da uno standard d’interconnessione tramite il quale comunicano (cioè possono essere utilizzati congiuntamente) gli elementi della rete. Tra reti virtuali e standard di connessione vi è un’evidente relazione biunivoca. In alcuni casi lo standard è definito congiuntamente dalle imprese, in altri può essere frutto dell’intervento di una qualche agenzia pubblica. Nel caso che qui ci interessa esso è invece stabilito da un’unica impresa che ne è proprietaria o, come si dice di solito, ne è sponsor. Nell’ambito della rete virtuale costituita da Windows e i relativi programmi applicativi è la Microsoft che definisce lo standard di connessione: ogni programma applicativo per poter funzionare su Windows deve rispettare uno standard di connessione che è di proprietà della Microsoft». Sabbatini P., La concorrenza come bene pubblico. Il caso Microsoft, Laterza, 2000 (p. 196).
12. «IDABC is a Community Programme managed by the European Commission’s Directorate General for Informatics. IDABC supports the implementation of EU legislation, from internal market regulations to consumer and health policies, by facilitating the exchange of information between public administrations across Europe through the use of information technology.» http://ec.europa.eu/idabc/en/document/2586/10#What.
13. II testo integrale dell’EIF si trova all’indirizzo http://ec.europa.eu/idabc.
14. www.aiccre.it/pdf/COM%20Interoperabilit%C3%A0.pdf
15. Si veda la raccolta presente sul sito del CNIPA alla pagina www.cnipa.gov.it/site/itit/La_Documentazione/Pubblicazioni/.
16. II documento è disponibile on-line all’indirizzo www.cnipa.gov.it/html/docs/cnipa_quad_38_int_a.pdf
17. Subito dopo, il documento si preoccupa anche di fornire alcuni indicatori quantitativi per la misurazione del livello di interoperabilità. «L’interoperabilità è misurabile considerando gli altri sistemi software noti con i quali il sistema in sviluppo deve poter dialogare, e i relativi formati di scambio dati e protocolli. Le principali metriche applicabili alla misura della interoperabilità sono le seguenti. 1. Sia B il numero dei formati dei dati dei sistemi software con i quali l’applicazione deve poter scambiare dati; sia A il numero dei formati dei dati correttamente implementati (ovvero che abbiano superato i relativi test] all’interno dell’applicazione. La proporzione A/B misura l’interoperabilità rispetto al formato dei dati. I valori ammissibili variano tra 0 ed 1, che rappresenta il valore desiderabile. 2. Sia B il numero dei protocolli di comunicazione dei sistemi software con i quali l’applicazione deve poter colloquiare; sia A il numero dei protocolli di comunicazione correttamente implementati (ovvero che abbiano superato i relativi test) all’interno dell’applicazione. La proporzione A/B misura l’interoperabilità rispetto ai protocolli di comunicazione. I valori ammissibili variano tra 0 ed 1 che rappresenta il valore desiderabile.»
18. Comitato Tecnico di esperti per l’E-Society, Relazione finale della Task Force Interoperabilità e Open Source, Provincia Autonoma di Trento, 2005 (par. 3.1.1); documento disponibile on-line al sito www.giunta.provincia.tn.it/binary/pat_giunta_09/XIII_legislatura/relazione_finale_task_force_interoperabilita_os.H34128198.pdf.
19. ibidem. Questa interessante distinzione è approfondita al par. 3.1.5 dello stesso documento.
20. www.sutor.com/newsite/blog-open/?p=1260
21. Di conseguenza, dicendo che “un iPhone è altamente interoperabile con un MacBook” oppure che “la piattaforma di iTunes è interoperabile con il software dell’iPod” non stiamo dando delle informazioni false però stiamo usando il concetto di “interoperabilità” in un senso limitato.
22. Si legga a tal proposito la ricostruzione compiuta dallo stesso Bruce Perens in Di Bona C., Ockman S., Stone M. (a cura di), Open Sources. Voci dalla rivoluzione Open Source, Apogeo, Milano, 1999; accessibile anche on-line dal sito www.copyleft-italia.it/pubblicazioni.
23. Tratta da http://it.wikipedia.org/wiki/Neutralità_della_Rete.
24. «According to the text of the 1999 Communications Review, technological neutrality means that legislation should define the objectives to be achieved, and should neither impose, nor discriminate in favour of, the use of a particular type of technology to achieve those objectives. This basic explanation however leaves quite some room for interpretation, which is illustrated by the fact that market parties, policymakers and legislators seem to adhere to different meanings of the principle, as they see fit.» Van Der Harr I., Technological neutrality; what does it entail?, TILEC discussion paper, No. 2007-009 (p. 2); disponibile in rete su SSRN: http://ssrn.com/abstract=985260.
25. Lessig L., Il futuro delle idee, Feltrinelli, Milano, 2006 (pp. 228-229).
26. A conferma di ciò si legga ancora Van Der Haar (pp. 12-13): «When consumers no longer have a choice however, the regulator could go as far as opening up possibilities to be able to choose again, for example by imposing interoperability standards on companies, or the un-tying of their products.»
27. http://it.wikipedia.org/wiki/Economie_di_rete.
28. «Robert Metcalfe [...] ha fotografato la crescita dell’utilità coniando una legge di particolare interesse, che esprime in modo chiaro il potenziale diffusivo delle tecnologie digitali [...]. La legge di Metcalfe evidenzia che l’utilità che una tecnologia a rete presenta per ogni singolo utente della rete è pari al quadrato del numero di utenti che utilizza quella tecnologia». Verona G., Evoluzione e gestione della tecnologia digitale, in Vicari S. (a cura di), Il management nell’era della connessione, Egea, Milano, 2001.
29. Si pensi ad esempio alla frequente diffusione di standard de facto come risultato di una precisa strategia commerciale: altro aspetto che avremo modo di approfondire più avanti.
30. Si legga anche l’interessante riflessione di Francesca Martini a proposito del modello free software/open source e dei virtuosi effetti di rete che esso può innescare: «È un modello che favorisce il progresso tecnologico, poiché incentiva la trasformazione e l’implementazione degli elementi già esistenti e liberamente disponibili e si caratterizza per i cosiddetti effetti a rete [...]. È su questo piano che ha progressivamente scalzato la tendenza alla standardizzazione fino ad oggi generata dai modelli di diffusione del software proprietario che hanno fortemente ristretto la concorrenza sui mercati sfruttando il diritto di proprietà intellettuale in chiave protezionistica. La libera disponibilità del programma modificabile e utilizzabile da chiunque incentiva i produttori di programmi ad interagire e a migliorare il prodotto, può essere uno strumento di differenziazione delle imprese e, in ultima analisi, può svolgere un’importante funzione pro-concorrenziale. Martini F., Open Source, pubblica amministrazione e libero mercato concorrenziale, in Il diritto dell’economia, 3/4-2009, p. 686.»