L’interoperabilità nel mondo dell’informatica è sempre stato un argomento centrale. Non credo che ci sia bisogno di spendere parole su come spesso tale caratteristica sia stata messa in secondo piano sia per ragioni economiche che tecniche. Ragioni che possono essere discusse ma vanno comunque accettate. È nel pieno diritto di chi produce software compiere scelte di questo tipo, e dovrebbe essere dovere di chi le tecnologie le utilizza tenere in considerazione il valore dell’interoperabilità (insieme ad altri parametri ovviamente) e capire di volta in volta se vale la pena legarsi a doppio filo ad un determinato produttore.
Tale scelta però ha un peso ben diverso quando passiamo dall’ambito privato a quello pubblico, per di più a livello Europeo. Per sensibilizzare le pubbliche amministrazioni sui temi dell’interoperabilità è stato redatto un documento non tecnico contenente alcune linee guida. L’obbiettivo dichiarato di tale documento è quello di favorire un miglioramento del mercato interno attraverso una maggiore interoperabilità tra le Pubbliche Amministrazioni Europee. Una bozza della seconda versione del documento è liberamente scaricabile e consultabile.
Pochi giorni fa Free Software Foundation Europe ha intercettato e pubblicato una lettera della Business Software Alliance indirizzata alla Commissione Europea che si scaglia in particolar modo sull’articolo 5.2.1 dell’European Interoperability Framework.
Per capire di cosa si tratta ho deciso di fare una traduzione (abbastanza libera per motivi di tempo) del punto di cui si parla nella lettera della BSA:
5.2.1
Specifiche, apertura e riuso
La possibilità di condividere e riusare componenti di servizi basati su una specifica formalizzata dipende dall’apertura della stessa.
Se il principio di apertura è applicato pienamente:
- Tutti gli stakeholders possono contribuire all’elaborazione della specifica e viene predisposta una public review
- Il documento contenente la specifica è liberamente disponibile per lo studio e per la condivisione
- La specifica può essere implementata con diversi approcci di sviluppo (Per esempio utilizzando tecnologie e software Open Source o proprietario. Questo permette tra l’altro di distribuire sotto diversi modelli di Business prodotti, tecnologie e servizi basati sulle specifiche formalizzate)
È responsabilità di chi crea una determinata specifica la decisione riguardo a quanto tale specifica debba essere aperta.
A causa del loro effetto positivo per l’interoperabilità, l’utilizzo di specifiche aperte, caratterizzate dai tre punti esposti sopra, così come la condivisione e il riuso, sono state promosse in molte direttive e sono incoraggiate nell’ambito della fornitura degli European Public Services.
Tuttavia. le amministrazioni pubbliche possono decidere di utilizzare specifiche meno aperte, specialmente nel caso in cui specifiche aperte non garantiscano i requisiti funzionali di interoperabilità o quelle disponibili non siano mature e/o sufficientemente supportate dal mercato, o ancora dove tutte le organizzazioni cooperanti già utilizzino o siano in accordo nell’usare le stesse tecnologie.Raccomandazione 22:
A parità di condizioni, le pubbliche amministrazioni dovrebbero preferire specifiche aperte per la distribuzione degli European Public Services
I punti in cui è possibile analizzare l’attacco della BSA sono molteplici e svariano dallo spauracchio di una possibile perdita di competitività Europea alla sempre in voga minaccia Cinese ma il vero e proprio motivo può essere riassunto facilmente con una singola sigla: FRAND.
Nella lettera la BSA chiede espressamente di citare nel European Interoperability Framework la possibilità di inserire all’interno degli standard delle specifiche che richiedono il pagamento di royalty per l’implementazione sotto termini “Fair, Reasonable And Non Discriminatory”. I problemi di questo approccio sono principalmente due e sono stati evidenziati da FSFE.
- Un azienda che riuscisse a far entrare una propria specifica non libera da royalty in uno standard godrebbe di un flusso praticamente inarrestabile di entrate dalla propria invenzione solo grazie alla sua standardizzazione, rendendo di fatto poco “fair” la competizione.
- I termini “Fair, Reasonable And Non Discriminatory” in realtà sono discriminatori. Secondo la FSFE infatti circa l’85% dei progetti di software libero sono rilasciati con licenze (GNU GPL, MPL, Apache…) non compatibili con regimi non royalty free per via della loro stessa natura (possibilità di redistribuzione del codice sorgente del software).
Personalmente trovo che le linee guida della Commissione Europea siano ampiamente condivisibili (oltre ad essere pragmatiche e moderate al punto giusto) e le preoccupazioni della FSFE altrettanto fondate. Sono convinto che l’abbattimento delle barriere all’ingresso sia l’unico modo per arrivare ad un mercato sano e pienamente concorrenziale e che i modelli di business legati alle licenze libere (licenze legalmente riconosciute) non possano e non debbano essere in alcun modo ostacolati da una qualsiasi normativa nazionale o internazionale.
