Intel ha un progetto denominato UDI: Uniform Driver Inteface.L'idea è quella di definire una singola interfaccia tra kernel ed i device driver. Che cosa può ricavare la comunità del free software da questa idea?
Immaginando un certo numero di sviluppatori di sistemi operativi e di hardware che collaborano tutti su di una base egualitaria, UDI (ammesso che sia tecnicamente possibile) sarebbe una idea molto buona. Ci permetterebbe di sviluppare un solo driver per ogni device, e quindi di farlo condividere a tutti. Questo renderbbe possibile un livello di cooperazione alto.
Applicando questa idea al mondo reale, che contiene sia sviluppatori appartenenti alla comunità del Free Software più indirizzati verso la cooperazione, sia sviluppatori di software proprietario indirizzati piuttosto verso il dominio, il risultato sarebbe molto differente. Non c'è possibilità che l'uso di UDI possa portare benefici al movimento del Free software. Se porta qualcosa, questa e' quella di dividerci e di indebolirci.
Quali sarebbero le conseguenze se Linux supportasse UDI, e se iniziassimo a sviluppare nuovi driver per comunicare con Linux attraverso UDI?
* La gente potrebbe usare i driver di Linux, coperti dalla GPL, con i sistemi Windows.
Questo aiuterebbe solo gli utenti Windows; non porterebbe vantaggi per noi utenti di sistemi operativi Free. Anche se questo non ci colpisce direttamente; tuttavia gli sviluppatori dei driver coperti dalla GPL sarebbero scoraggiati dal vederli utilizzare in quella maniera. E questo sarebbe molto male. Potrebbe esserci anche essere una violazione della GNU - GPL nel caso di un link dei driver dentro un kernel proprietario.
Aumentare questa tentazione significa andarsi a cercare dei guai.
* La gente potrebbe utilizzare driver Windows non-Free su sistemi GNU/Linux.
Anche se questo non sfavorisse direttamente l'hardware supportato dal software Free. Tenderebbe indirettamente a diminuirne la quantità, offrendo una tentazione ai milioni di utilizzatori di GNU/Linux che non hanno imparato ad insistere sulla libertà nel loro stesso interesse. Col pericolo che la comunità cominci ad accettare questa tentazione, spostandoci verso l'uso di driver non free piuttosto che scriverne di nuovi free.
UDI da sola non dovrebbe creare problemi per lo sviluppo dei driver free. Cosicché se un buon numero di noi non dovesse aderirvi, ci sarebbe ancora la possibilità di sviluppare driver free malgrado l'UDI, come avviene ora
Ma perché incoraggiare la comunità ad essere più debole di quanto ha bisogno di essere? Perché porre difficoltà inutili sul futuro del software libero? Meglio rifiutare UDI se non ci porta benefici.
Viste le possibili conseguenze, non è strano che Intel abbia cominciato a "guardare alla comunità Linux per supportarla con UDI". Perché una società ricca e self-seeking si avvicina ad una comunità cooperativa? Per elemosinare, naturalmente. Non hanno nulla da perdere chiedendo, e noi potremmo abbassare la guardia e dire si.
La cooperazione con Intel è fuori discussione. Non vogliamo etichettare Intel, o chiunque altro, come il Grande Satana. Ma prima di partecipare a qualsiasi progetto proposto, bisogna valutarlo attentamente, per essere sicuri che sia vantaggioso per la comunità del software libero, non solo per gli sviluppatori di software per sistemi proprietari. In questo caso particolare, significa che dobbiamo richiedere che la collaborazione ci avvicini al nostro obiettivo ultimo per i driver ed i kernel free: supportare tutto l'hardware importante con driver free.
Un modo di rendere UDI una buona idea sarebbe quella di modificare il progetto stesso. Eric Raymond ha proposto che i driver UDI siano free software. Questo sarebbe l'ideale, ma anche altre alternative potrebbero funzionare. Solo richiedendo la pubblicazione del sorgente, e non un segreto registrato, potrebbe funzionare, perchè se il driver non è free, ci potrebbero almeno dire di cosa dobbiamo sapere per scrivere un driver free.
Intel potrebbe fare anche qualcos'altro, a parte UDI, per aiutare la comunità del software libero per risolvere questo problema. ci potrebbe essere una sorta di certificazione dell'hardware per la ricerca degli sviluppatori, che Intel giochi un ruolo nella garanzia. Se così, Intel potrebbe essere d'accordo ad effettuare la certificazione più difficoltosa se le specifiche dell'hardware sono segrete. Questa potrebbe essere non una soluzione completa al problema, ma potrebbe aiutare un po'.
Una difficoltà con qualsiasi progetto che comprenda UDI è che noi faremmo la nostra parte all'inizio, ma il ritorno economico di Intel potrebbe durare a lungo. In effetti estenderemmo il credito per Intel. Ma continuerà Intel a ripagare il suo loan? Probabilmente si, se ci gettiamo nello sviluppo e non ci sono loopholes; d'altra parte, non ci possiamo contare. Le corporations sono notoriamente ben poco affidabili; le persone con le quali collaboriamo possono avere una integrità, ma potrebbero essere sopraffatti dai superiori, oppure sostituiti in qualunque momento con altre persone. Quando si fa un progetto con una corporation, bisogna ottenere sempre un accordo vincolante scritto.
Dato il coinvolgimento di Intel in I2O, un vasto pianto mirante a mantenere le specifiche hardware segrete, è molto improbabile che possa accettare un progetto che ci porti quello di cui abbiamo bisogno.
Infine, non è pericolo mantenere la porta non chiusa a chiave, fintanto che stiamo attenti se c'è Intel dentro.
fonte: Pluto
Screenshots.
Nessun commento:
Posta un commento
Non inserire link cliccabili altrimenti il commento verrà eliminato. Metti la spunta a Inviami notifiche per essere avvertito via email di nuovi commenti.