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.
Sono completamente d’accordo con l’articolo.
L’interoperabilità è un fattore fondamentale ed irrinunciabile per la creazione di un mercato non distorto, che altrimenti sarebbe a favore di un unico “competitor” (ma sarebbe più giusto chiamarlo monopolista) o di un ristretto gruppo di aziende.
Microsoft da sempre ha campato su questo, e laddove non esiste questo tipo di concorrenza sleale (in quanto standard aperti si sono imposti prima di qualunque altro standard proprietario) Microsoft è molto meno competitiva degli altri attori in gioco: come esempio basta pensare a tutto ciò che ruota attorno al Web (web server, application server, web browser), dove bigM si sogna gli share “bulgari” che ha ad esempio nel mercato dei sistemi operativi desktop.
BSA è così occupata a curare gli interessi dei suoi soci da non capire bene cos’è la Commissione Europea e l’Unione in generale.
E’ semplicemente ridicolo che venga chiesto loro di emanare specifiche pubbliche che non siano implementabili senza vincoli di royalty o di tipo economico, a meno che come riportato dallo stesso articolo 5.2.1 ciò non sia strettamente necessario.
Inoltre vorrei prorpio sapere perchè la normativa europea faccia perdere competitività e ci sfavorisca nei confronti della Cina, che tra l’altro è un paese dove la pirateria è quasi istituzionalizzata.
non è quello che viene chiesto, quello che viene chiesto è non imporre come vincolo l’ essere una specifica, libera, e la possibilità di standardizzare (quindi mettere in uso) anche standard accessibili da terzi ancorchè coperti da royalties
in pratica la garanzia che delle specifiche siano prese in considerazione sulla base del merito tecnico, e non solo su basi politiche (come è il voler essere “liberi” a tutti i costi)
quindi non è ridicolo – quello che è semplicemente ridicolo, semmai, è che su questioni tecniche come specifiche di formati e protocolli, sia chiamata in causa la politica, fatta da gente che tecnica non è nemmeno lontanamente …
proprio per questo motivo…
porre come requisito che una specifica o standard possa essere reimplementato liberamente (in quanto esente da royalty) tanto da una sw house tanto dall’ hobbysta nella cantina parentale implica sostanzialmente escludere che tutta la tecnologia allo stato dell’ arte – più o meno tutta frutto di ricerca privata e coperta da brevetti – e standardizzare il livello tecnologico mainstream su un livello molto basso, da “minimo comune denominatore”
mentre i cinesi, per i quali come dici tu stesso la pirateria, ma in effetti più ancora il copiare (all’ inizio, ma poi estendere) tecnologia sviluppata altrove è una prassi, non hanno questi problemi… dal momento che per loro prendere tecnologia standard royalty free o tecnologia proprietaria più sofisticata non fa differenza, è logico supporre che il loro livello tecnologico di base (“mainstream”) diventi quello che per noi sarebbe lo stato dell’ arte – stato dell’ arte di cui potremmo dotarci estensivamente ma di cui non vogliamo farlo perchè “maledizione non è tecnologia aperta!!11one”…
@j
Si ma se leggi bene il punto 5.2.1 (se non ti fidi della mia traduzione puoi anche vedere nell’originale) c’è scritto in maniera molto chiara:
Quello che la BSA vuole ottenere è una sorta di equiparazione tra specifiche sotto termini FRAND e specifiche realmente aperte. E tale equiparazione non può essere fatta perchè di fatto toglie di mezzo modelli di business LEGALI basati su licenze LEGALI e per di più anche molto diffuse.
Tra le altre cose nessuno obbliga che l’implementazione di una specifica aperta sia aperta a sua volta. Le aziende possono tranquillamente chiedere royalty e concedere l’utilizzo di tecnologie brevettate che implementano standard aperti.
Forse il fatto che html sia uno standard aperto e privo di royalty ha impedito l’avanzamento dello stato dell’arte dei browser?
Qual’è l’ambito tecnologico che è cresciuto maggiormente in questi ultimi anni e che ha portato innovazioni più tangibili a livello globale? Su che tipo di specifiche si basa?
ha già risposto Emanuele, se una soluzione commerciale è matura e largamente supportata può tranquillamente essere presa in esame.
E questo chi te lo ha detto? Conosci chi ha redato il documento? Conosci i consulenti che ci hanno lavorato?
Non ho voglia di scatenare flame o quant’altro, ma spero di non essere l’unico a considerare le tue parole molto lontane dalla realtà.
Da quando gli standard avrebbero frenato lo sviluppo tecnologico?! Internet si è forse sviluppata poco perchè basata su standard aperti che può implementare ” hobbysta nella cantina”?
Perchè si sostiene ancora una visione così “berlusconiana” del software secondo cui il software lo puoi fare solo se hai i miliardi?
Se una specifica è aperta saranno gli utenti a decidere liberamente qual’è la migliore e chiunque, anche l’hobbysta se si sente in grado potrà “sfidare” la migliore implementazione se pensa di saper fare meglio.
Sui brevetti software non scherziamo per favore, oggi la quasi totalità dei brevetti su cui si scannano le multinazionali (vedi Oracle contro Google) sono delle boiate assurde, che non hanno minimamente coinvolto un processo di ricerca degno di questo nome.
E comunque mi domando quali geniali brevetti occorra ideare per fare uno standard di interoperabilità…
Non ho ben capito, quindi pensi che copiare ed infrangere copyright li metta in una posizione di vantaggio?
ER
premesso che alla fine quello del sw è un mercato – e che anche le pubbliche amministrazioni, così come le società e i privati, scelgono openoffice piuttosto che office (alla fine si riduce a questo no?) in base a considerazioni di costi/benefici, TCO eccetera
e d’ altra parte il bisogno di interoperabilità nasce essenzialmente in ambienti eterogenei (ma si è visto che il problema non si pone in gran parte delle società, in uci si usa esclusivamente sw MS – o non MS ) o dalla preoccupazione che il fornitore del sw attuale (usato per archiviare la totalità dei documenti) un domani cessi di esistere o di supportare quella versione del sw (con necessità di migrare i documenti), ma questo diventa un non problema quandunque siano a disposizione le specifiche
qualcuno le consulterà, le implementerà in una nuova applicazione o programma di conversione, se dovrà versare delle royalties si farà pagare a propria volta, e l’ economia girerà – dove sta il problema?
che non ci potrà essere una versione gratuita di quella nuova applicazione o convertitore compatibile? che non potrà essere sotto licenza GPL?
se non ci può essere significa che quella parte del mercato in cui gli standard di riferimento sono coperti da royalty, è preclusa agli attori che basano il proprio core business su sw licenziato sotto gpl, e che questi si dovranno adattare per competere – ma mi sembra non sia la morte di nessuno…
Andrea
in certi casi, da almeno una ventina d’ anni…
unix svr4 e POSIX;
X86 e BIOS;
ACPI;
XML;
…eccetera…
ti sembra che internet sia un esempio lampante di alta tecnologia?
no, internet è bassa (molto bassa) tecnologia in confronto a quasi qualunque altra applicazione dell’ elettronica e dell’ informatica – ed è uno dei pochi casi in cui è giusto che sia così
perchè questo è un mercato, e il sw è uno strumento, e quello che conta di uno strumento sono i benefici che offre al’ utente finale, ivi incluse le feature – se si riesce ad ottenere gli stessi benefici senza richiedere royalties tanto meglio, ma se si sacrificano le feature in favore dell’ essere liberi da royalty e brevetti, significa che ci si sta sostanzialmente, accontentando – non c’è nulla di male a farlo, ma non si può più dire di stare implementando la tecnologia *migliore possibile*, a quel punto basta un po’ di onestà intellettuale, e ammetterlo…
quello che gli utenti sono in grado di valutare è un sunto dei costi e benefici in forma “conto della serva” (stilata da altri, capaci di leggere tecnicamente la specifica e che si spera siano obiettivi) e le feature di un prodotto che quella specifica, la implementa
ma una specifica, si è visto più volte che gli utenti finali non sono in grado di valutarla tecnicamente…
e con ciò? vuoi forse dire che i ricercatori farmaceutici possono brevettare delle molecole, gli ingegneri meccanici possono brevettare dei bulloni, ma io sviluppatore di sw non avrei il diritto di vedere tutelato il mio lavoro su algoritmi e accorgimenti tecnici (che mi può essere costato tempo, quindi denaro, studiare anche se non necessariamente li ho implementati in sbrilluccicosi prodotti per l’ utente finale) a causa di google, oracle, delle loro diatribe e dell’ abuso che eventualmente hanno fatto del sistema brevettuale?
sbagli prospettiva,
quello che dovresti chiederti è di quali feature c’è bisogno nel sw che effettivamente gli utenti useranno, e quali richiedono accorgimenti brevettati – dopodichè … dipende caso per caso
per dire, ODF mi risulta essere esente da brevetti eppure mi risulta non garantire un’ interoperabilità perfetta perchè presenta incompatibilità e idiosincrasie tra versioni diverse di sè stesso, e vi sono state ambiguità nella stesura dello standard ( cosa emersa da un articolo di cesare di mauro qualche tempo fa)
esattamente
sai, risparmiare tempo e denaro altrimenti da spendere in R&D non è che danneggi, anzi…
@J
E’ chiaro che la pensiamo un pò diversamente :), ma non capisco come uno standard neutro e generico come XML (ottimo per lo scambio dei dati) possa dare fastidio alle innovazioni.
E poi stai attento a non mischiare le pere con le mele: x86 non è uno standard ed il problema è proprio che non lo è!
x86 è una tecnologia proprietaria concessa sotto (costosa) licenza da Intel e lo sa bene AMD che deve pagare delle percentuali alla rivale per ogni processore che vende!
A costo di essere ripetitivo trovo assurdo che si debbano pagare royalties sull’ISA di un’architettura. Non sto parlando dell’imlementazione di un processore che richiede sforzi tecnologici di ricerca e sviluppo ma dell’ISA che è un semplice set di istruzioni basilari.
E chi ha detto che sono loro a doversi adattare? Abbiamo 2 business model legali e 2 possibilità:
Specifiche royalty free ==> Tutti e 2 i business model sopravvivono e possono competere.
Specifiche con royalty ==> Il business model basato su software libero è tagliato fuori in maniera sistematica dalla competizione.
Qual’è la scelta più logica per garantire un sano mercato concorrenziale? (a parità di requisiti tecnici ovviamente)
BIOS è solo uno standard de facto.
X86 è uno standard di fatto (con costosissime royalty come già detto da andrea)
ACPI stesso è uno standard de facto… ma almeno la sua apertura ha permesso la libera implementazione da parte di tutti gli attori in campo.
POSIX ha permesso da una parte interoperabilità nel mondo unix e dall’altra non ha impedito a chi non volesse reimplementare lo standard di percorrere strade alternative (o addirittura mantenere un sottosistema per la compatibilità)
XML ha portato alla nascita di linguaggi impiegati negli ambiti più disparati dell’informatica: http://en.wikipedia.org/wiki/List_of_XML_markup_languages
Andrea
non è uno standard nel senso che intendi tu, forse..
ma tieni conto che uno standard non è solo la specifica dettata da qualche comitato e imposta dall’ alto a tutti quelli che vogliono entrare in un settore e devono quindi conformarsi – uno standard è solo un modo (in mezzo magari a N possibili altri, omologhi ma differenti) di fare le cose, che una volta introdotto sul mercato in una qualche forma può diffondersi trasversalmente come può non farlo (in parecchi ambiti – meccanico, elettronico, energetico, ecc – esistono standard rimasti relegati a nicchie, settori, o territori specifici) venire formalizzato come no, venire regolamentato come no
fidati, lo so
e fidati, è uno standard industriale, di fatto, riguardante un’ architettura di cpu, ma cionondimeno è uno standard ;)
il fatto stesso che AMD e Via (ma in un futuro nemmeno troppo remoto, altri nomi come Texas Instruments, IBM, Cyrix, ST microelectronics..), così come tutti coloro che sviluppano compilatori e assemblatori, o che scrivono parti dei loro programmi in assembly x86, debbano conformarvisi per poter garantire la compatibilità, lo rende tale…
ma infatti la cosa iinteressante è che i brevetti e royalty non sono sulla ISA in sè, come si è più volte scritto su HWUpgrade e qui (vedo se riesco a recuperare il link all’ articolo), sono sugli accorgimenti tecnici necessari per implementare la versione attuale dell’ ISA in modo prestazionalmente moderno e competitivo
solo che sono tanti e tali ( http://www.intel.com/pressroom/kits/bios/crawford_bkgd.htm
http://www.intel.com/pressroom/kits/bios/sborkar_bkgd.htm
http://www.intel.com/pressroom/kits/bios/gtaylor_bkgd.htm
http://www.intel.com/pressroom/kits/bios/hinton_bkgd.htm
http://www.intel.com/pressroom/kits/bios/iyoung_bkgd.htm
…eccetera.. ) che è difficile non incapparvi
certo, teoricamente in una ISA ci possono essere delle istruzioni, che presuppongano un’ implementazione ottimizzata coperta da brevetto (è successo ad esempio nel caso di MIPS e Lexar, con istruzioni di load unaligned introdotte dalla prima e che la seconda ha “emulato” senza pagare royalty, motivo per cui non era chiaro se ci fosse stata violazione, e le due sono finite in tribunale), ma non mi pare il caso delset base x86
tanto che se non vado errato sono da poco scaduti i brevetti da cui era coperto il 486, chiunque potrebbe oggi realizzare un proprio 486 senza dovere niente a nessuno, ma… chi lo comprerebbe? ;)
ER
credo che la risposta dipenda dal mercato
certo, la situazione perfetta sarebbe quella di non aver mai bisogno di pagare royalties, al che chiunque potrebbe competere nel mercato avendo pari opportunità, e ci sarebbe spazio per tutti e due i modelli di business
ma questo in un mondo ideale, in pratica ci sono ambiti da cui quello basato su sw libero è tagliato fuori in partenza – per il semplice motivo di essere incompatibile con il modo in cui vanno le cose in quell’ ambito…
per dire, se nella grafica ed editoria (nicchia quanto vuoi, certo, ma pur sempre una nicchia di una certa rilevanza) i colori di bandiere, loghi aziendali e quant’ altro sono definiti univocamente come tinte nel sistema Pantone, e questo è uno standard del settore – un grafico non potrà usare altro che sw che lo supporti, ma sw che lo supporti può essere solo non-libero o non-del-tutto-libero, perchè Pantone licenzia le liste di dati cromatografici un tot per copia
cosa che cozza con la possibilità della GPL, di ridistribuire gratuitamente a terzi, quindi bisognerebbe come minimo tracciare, e far pagare, ogni copia del codice, e non si potrebbe usare la GPL
oppure, come mi diceva un amico che si occupava prima di segnalamento ferroviario, adesso dei sistemi informativi sugli autobus, ci sarebbe già tanta IP coinvolta, e tanto da pagare tra sottoscrizioni consortili, specifiche vere e proprie degli standard di settore, ecc da escludere categoricamente che lo sviluppo possa avvenire sotto GPL – quindi anche quei campi sarebbero preclusi all’ origine al business model basato su sw libero
il problema del sw libero è di essere arrivato per ultimo in un mondo in cui quasi ovunque è attivo e (scusa, non mi vengono termini più adatti) “entrenched”, un sistema commerciale e produttivo basato sullo scambio di IP – e in cui la gente cerca e usa (anche se non sempre consapevolmente) prodotti e servizi realizzati tramite essa
in questo senso dicevo che “è difficile”, che “il sw libero si deve adattare” e che “quello che conta sono le esigenze dell’ utente e le feature da dargli”
certo, è preferibile avere specifiche liberamente implementabili, quando possibile… ma è proprio la possibilità di farlo che non si pone in tutti i mercati – o in mercati del tutto nuovi (in cui allora ci sono più opportunità), o per componenti infrastrutturali e/o, diciamo così, “comoditizzati” (ma allora sono settori in cui la soglia tecnologica d’ ingresso, per quanto concerne il sw, è volutamente più bassa)
certo, ma il motivo per cui li ho citati era come esempio di standard, di fatto certo, non aperti certo, la cui persistenza nel settore ha scoraggiato dallo sviluppare qualcosa di meglio e impedito di affrancarsi da una piattaforma spoglia e inelegante
complesso, contorto, a tratti effettivamente assurdo (non trovo termine più adatto) molto più del necessario (come puoi renderti conto anche tu dando una letta al pdf della specifica) cosa che mi ha portato più volte a chiedermi: perchè? e a pensare che solo la forza commerciale di intel e la logica per cui ogni produttore dovesse avere la libertà di fare le cose a modo suo, potevano imporre al mercato un accrocchio del genere
quando sarebbe stato molto più semplice standardizzare la piattaforma a livello di interfacce e comandi di management – al che non ci sarebbe stato bisogno dell’ AML interpretato…
(questo dovrebbe rendere chiaro come io non sia contrario all’ apertura delle specifiche hw di componenti di basso livello, “orizzontali” e infrastrutturali… ;) )
teoricamente sì
in pratica il fatto che sia aperto non toglie che la sua implementazione da parte degli sviluppatori di OS, sia ardua al punto da poter non funzionare su HW che i produttori non testano esplicitamente con quell’ OS, ma solo con una implementazione (anche se la più diffusa, il che avrebbe senso da un certo pdv) dello standard – sto pensando alla debacle delle MB foxconn, incompatibili con l’ implementazione ACPI di linux all’ epoca mancante di alcune funzioni previste dallo standard, e al workaround che consisteva nel fare in modo che il kernel si idnetificasse al bios acpi, come windows …
oltre che essere disponibile, uno standard dev’ essere ragionevolmente implementabile, altrimenti è più una palla al piede che altro…
sì ma il punto come per la piattaforma PC, è un altro…
il punto è che posix è uno standard vecchio (descrivendo una piattaforma basata sostanzialmente sulle stesse API, semantiche e paradigmi dello unix di fine ani 80 – primi 90) e se vogliamo, nato vecchio (dal momento che su molti aspetti si formalizzò il comportamento di una o più tra le implementazioni preesistenti, come capita per gli standard di fatto, invece di creare una specifica pulita a cui tutti si sarebbero dovuti attenere) che proprio da interoperabilità e compatibilità è stato frenato nella sua evoluzione
con il risultato che anche se si continua a fare ottimizzazione e microottimizzazione degli internals, l’ aspetto esterno e globale del sistema non è diverso da quello del classico System Five (anche se passato sotto il nome di SUS)…
certo, ma come nell’ età classica, anche le strade alternative portavano a “Roma”, cioè a SVR4 – le cui api erano e sono lo “standard” che le applicazioni scritte “per unix” si aspettano, a cui quindi conformarsi in ogni caso (sia che si implementasse un kernel classico che un microkernel, exokernel o altro, di suo più o meno agnostico)
a parte un caso eccellente, chi ha percorso strade alternative è stato sistematicamente marginalizzato, quindi implementare un sottosistema di compatibilità posix è una cosa che alla fine volenti o nolenti si faceva in ogni caso…
in molti dei quali si sarebbero potuto impiegare linguaggi anche non markup based …
se già pensavo che XML sia il cancro del mondo informatico, uno dei motivi per cui questo sta perdendo di semplicità, efficienza, innovatività ed anche fascino, un po’ a tutti i livelli, così non fai che rafforzarmi quell’ impressione :)