Francamente, non avrei mai pensato che un giorno mi sarebbe toccato difendere Google da delle accuse di opportunismo e di appropriazione indebita. Meno che mai avrei potuto immaginare che mi sarebbe toccato difenderla dalle accuse mosse dal direttore editoriale di Linux&C. D’altra parte, viviamo in tempo in cui Tremonti vuole tassare i petrolieri ed in cui Bersani fa la guerra ai tassisti. Forse bisogna abituarsi a questi ribaltamenti di ruolo.
BigG, SaS e Affero
Nella vita professionale, mi occupo (anche) di sviluppo software. Roba server-side, in PHP, Python e altri linguaggi. In alcuni casi, il mio gruppo ed io abbiamo sviluppato anche dei web-service (SOAP, XML-RPC e roba simile) e delle piccole web-application. In questi casi ci siamo quindi trovati nella stessa posizione di Google (ma con mooolti meno soldi in tasca).
Nel nostro caso, come in quello di Google, il software espone all’esterno una serie di servizi che dipendono dal nostro hardware e dal nostro codice. L’accesso a questi servizi è regolato da una apposita API (Application Programming Interface). Nel caso di Google (ma non nel nostro) l’accesso alle API è libero e gratuito: chiunque voglia utilizzare quei servizi non deve fare altro che invocarli attraverso Internet (via http) inviando una apposita richiesta ai server. La richiesta deve essere conforme a quanto previsto dalle API.
Francamente, questo è (quasi) tutto quello di cui una azienda partner, un appassionato sviluppatore od un cliente può avere bisogno. Anzi: è proprio questa API ciò che rende la vita relativamente semplice a questi signori. Nessuna installazione, nessun aggiornamento locale, solo una API affidabile e sempre disponibile da invocare quando necessario. La manutenzione del codice resta completamente a carico del produttore. Non mi sembra un regalo di poco conto.
Questo modello si chiama “Software as a Service” (SaS o SaaS, come preferite) ed ha una serie di vantaggi anche per il produttore. Prima di tutto, lo sviluppo e la manutenzione del codice avvengono solo sul server (“localmente”). Niente package.DEB o.RPM da creare, niente installazioni da collaudare, etc. In secondo luogo, è possibile includere nel codice dei componenti che non potrebbero essere distribuiti in quanto sono coperti da copyright.
L’unico limite di questo modello è che l’utente non può scaricare ed installare il codice su di un suo server ed esporre (con poca o nessuna fatica) un servizio identico o molto simile a quello originale. In altri termini, questo software non può essere usato per fare concorrenza diretta all’azienda che lo ha sviluppato.
Se questo software fosse stato sviluppato con soldi pubblici da una università (come è accaduto a suo tempo per NCSA Mosaic e NCSA HTTPD) forse sarebbe stato lecito scandalizzarsi per il fatto che esista questo limite. Se una cosa viene sviluppata con i soldi pubblici, è giusto che sia liberamente utilizzabile. Lo stesso vale anche per lo sviluppo da parte delle comunità Open Source (come Mozilla e PostgreSQL, per esempio). Se il “contratto sociale” tra gli sviluppatori è che ognuno ci mette del suo, a patto di poter liberamente utilizzare ciò che producono gli altri, allora è lecito aspettarsi che il codice sia liberamente utilizzabile (almeno da tutti gli sviluppatori e, per una inevitabile estensione, da tutti gli interessati).
Ma il software prodotto da BigG, così come quello sviluppato da noi, è stato sviluppato con i soldi degli investitori. Quei soldi sono stati investiti nella speranza di ottenere un ritorno (Return of Investment, o ROI). Non sono stati regalati .
Francamente, mi sembra eccessivo pretendere che BigG rilasci come codice open source anche la parte di software da cui dipende la creazione dei suoi servizi esclusivi. Questo permetterebbe a chiunque (a partire da un certo Tronchetto dell’Infelicità…) di creare una nuova Google, in grado di fornire gli stessi identici servizi, semplicemente noleggiando una batteria di server ed installando questo software. Per quale motivo una azienda che opera sul libero mercato a fini di lucro dovrebbe fare un simile regalo ai suoi concorrenti?
Peggio ancora: in quale modo questo suicidio commerciale potrebbe favorire gli utenti?
In realtà, nemmeno FSF, che ha creato la licenza Affero, si augura un simile atto di stupidità. Ciò che FSF si augura è qualcosa di molto diverso. FSF si augura che chi utilizza sui propri server del software coperto da licenza “Open” (GPL, MIT e roba simile) rilasci al pubblico le modifiche che apporta a quel software open source. Mi spiego: se si utilizza sui propri server il sistema di Instant Messagging Open Source “Jabber” e si apportano dei miglioramenti ad esso, è sicuramente auspicabile che queste modifiche vengano rilasciate come software GPL a loro volta, in modo che contribuiscano allo sviluppo del progetto a vantaggio di tutti. Detto in altri termini, è auspicabile che le patch vengano fatte confluire nel progetto originale.
Diverso è il caso in cui si utilizza del software open source come piattaforma . Se installate Apache e Python su un server, e su questo server sviluppate (in Python) il search engine di Google (come è effettivamente successo), si può forse pretendere che vi sentiate in obbligo di rilasciare il codice del search engine come Open Source? Dovreste forse inserirlo come patch nel source tree di Apache? O di Python? L’assurdità di questa ipotesi dovrebbe essere evidente.
Google si trova spesso in questa posizione. Gran parte del suo codice è rappresentato da applicazioni sviluppate in Python e che girano su Apache (più esattamente, su delle versioni custom di Apache). Che obbligo (morale o legale) dovrebbe avere Google di rilasciare questo codice?
AFL e le versioni custom di Apache
Google viene anche accusata di “appropriazione indebita” a causa delle versioni custom di Apache usate sui suoi server. Anche questo lascia un po’ perplessi. La licenza (AFL) di Apache non prevede nessun obbligo in questo senso. La AFL, come la MIT e la BSD, consente l’uso del codice “libero” a cui è applicata all’interno di progetti closed source. Lo si può verificare da soli a questi indirizzi:
http://it.wikipedia.org/wiki/Apache_License
http://www.apache.org/licenses/LICENSE-2.0
Quindi, di cosa diavolo stiamo parlando? La volontà degli sviluppatori di Apache è stata pienamente rispettata, nella lettera e nella sostanza. Se Apache fosse stato coperto da una licenza che obbligava al rilascio delle modifiche, probabilmente Google avrebbe usato un’altra piattaforma (o se la sarebbe sviluppata in casa).
Ma, anche al di là degli obblighi di licenza, che senso avrebbe pretendere di potere accedere a quelle modifiche? Nella misura in cui il codice di Apache resta disponibile sui server di Apache.Org, non viene fatto nessun danno agli altri “attori” presenti sul mercato. Chiunque può svilupparsi le versioni custom di Apache che preferisce, a sue spese . Viene solo negato ai concorrenti di Google la possibilità di accedere gratuitamente e liberamente ad una parte delle risorse tecniche sviluppate al proprio interno, e per il proprio uso e consumo, da una azienda (Google) che opera sul libero mercato e con fini di lucro. In altri termini, viene negata agli altri attori del mercato la possibilità di fare concorrenza a costo zero all’azienda che ha sviluppato il software. C’è forse motivo di scandalizzarsi per questo?
Il posto dell’Open Source e quello del Closed Source
Francamente, quando si muovono critiche di questo tipo, vuol dire che si sta perdendo di vista un fatto fondamentale: le aziende che producono software commerciale devono poter sopravvivere a fianco delle comunità open source. Entrambe queste categorie di produttori di software svolgono un ruolo importante nella ecologia generale del nostro settore e vanno salvaguardate. In altri termini, rilasciare i sorgenti del codice verso il pubblico dominio deve essere una scelta , non certo un obbligo .
Ovviamente, il modello “standard” di sviluppo dovrebbe essere quello aperto (Open Source). Ogni volta che una comunità di utenti abbastanza ampia riesce ad identificare chiaramente una sua specifica esigenza software, dovrebbe tentare di svilupparla in proprio seguendo questo modello. La ragione di questo consiglio è ovvia: in questo modo si mantiene il controllo dello sviluppo software nelle mani dei suoi utenti finali, con tutto quello che comporta in termini di rispondenza alle esigenze degli utenti, di disponibilità di modifiche ed aggiornamenti, di contenimento dei costi e via dicendo. Un esempio da manuale di questo modello di sviluppo è stato PHP. Gli sviluppatori di siti web avevano bisogno di uno strumento adatto allo sviluppo di web application e lo hanno creato a proprio (ed altrui) uso e consumo.
Questo non può però voler dire che le aziende commerciali debbano chiudere. In molti settori la comunità degli utenti non è abbastanza ampia, o non include abbastanza programmatori, per procedere allo sviluppo in proprio del software che le occorre. In altri casi, la comunità degli utenti non ha una percezione chiara delle sue esigenze software finché qualcuno non inizia ad offrire sul mercato un prodotto realmente utilizzabile. In tutti questi casi, è necessaria un’azienda commerciale che possa farsi carico della progettazione e dello sviluppo (cioè una “software house”), diversamente gli utenti resterebbero completamente senza software. Pensate cosa sarebbe successo se Visicalc (il primo spreadsheet della storia) non avesse mai potuto raggiungere il mercato in quanto “non kosher”. Pensate cosa sarebbe successo se gli utenti di MS Office avessero dovuto sviluppare la corrispondente suite Open Source OpenOfficeOrg prima di scrivere il loro primo documento.
Questo è ancora più vero quando si tratta di aziende che, come Google, usano il software per fornire servizi. Pretendere che queste aziende rilascino i loro sorgenti vorrebbe dire condannarle a chiudere. Peggio ancora, vorrebbe dire creare un mercato in cui sarebbero presenti moltissime aziende in grado di fornire lo stesso servizio senza però che nessuna di esse sia in grado di sostenersi economicamente e di garantire la continuità del servizio all’utente e/o lo sviluppo del sistema.
Si noti che nessuno vieta di sviluppare codice in questo modo. EyeOS , ad esempio, è una comunità che sviluppa in modalità Open Source un web desktop molto ricco, potente e complesso, in grado di competere ad armi pari con Google Apps (Gmail, Gdocs e via dicendo). Chiunque può installare EyeOS su un server ed iniziare ad offrire questo servizio ai suoi utenti. Ovviamente, nessuno lo fa: non ci sarebbe nessun modo di trarne un ritorno economico e di sostenere l’impresa.
Il ruolo delle aziende e quello dei volontari
La quasi totalità del software Open Source di oggi viene sviluppata (quasi solo) grazie a dei massicci investimenti da parte delle aziende. Questo è il caso, ad esempio, di Mozilla (Netscape), di OpenOfficeOrg (Sun) e di Qt/KDE (Trolltech).
Da un lato questo vuol dire che è del tutto legittimo pretendere di più da questo software. Non ci si può più barricare dietro alle scuse degli anni ’80, quando gli sviluppatori del mondo Open Source rispondevano alle critiche degli utenti invitandoli a partecipare allo sviluppo. Questo software è sviluppato da programmatori pagati dalle aziende, seguendo criteri industriali ed a fini industriali. Deve funzionare. Deve fare ciò che serve all’utente, deve farlo bene e deve essere bello da guardare. Punto.
Dall’altro lato, questo vuol dire che non ci si può più aspettare un totale disinteresse da parte degli sviluppatori (aziende). Le aziende sviluppano ciò che serve loro e rilasciano al pubblico dominio ciò che per loro è utile rilasciare. Non solo: anche i volontari sviluppano software soprattutto per fini di autopromozione. Non sono rari i casi in cui le esperienze maturate nel mondo open source finiscono a rinforzare i curriculum di neolaureati e giovani programmatori. La beneficenza è sempre meno diffusa come motivazione fondamentale per lo sviluppo software. Questo non dovrebbe sorprendere né, tanto meno, scandalizzare. Stiamo pur sempre parlando di software, non di riso e farmaci anti-AIDS.
Al giorno d’oggi è anche evidente una divisione dei ruoli tra aziende e volontari nello sviluppo del software open source: le aziende investono grandi quantità di soldi, pagano fior di programmatori e sviluppano la parte più impegnativa del codice (il “kernel”). I volontari, dal canto loro, sviluppano le estensioni, scrivono e traducono la documentazione, creano applicazioni che girano su queste piattaforme, si occupano della grafica, partecipano alle attività di marketing e promozione, collaudano il software e partecipano alla raccolta dei “desiderata” per le release successive. I volontari sono quindi spesso condannati ad un ruolo secondario, vuoi per ragioni di tempo, vuoi per ragioni di competenza tecnica. Di conseguenza, il loro potere decisionale è in continuo calo. Mantengono il controllo su sezioni secondarie dei progetti e non possono più decidere il destino della parte più importante. Questa situazione può non piacere ma è ciò che permette al software open source di crescere a questa velocità.
Se si vuole invertire questa tendenza, non c’è che una strada: tornare a produrre in prima persona software “di base”, in maniera del tutto volontaria. Questo è ciò che sta cercando di fare, ad esempio, Andrew Tanenbaum con la nuova versione di Minix. Minix3, per inciso, è coperto da una licenza ultra-liberista BSD, simile a quella di Apache (vedi http://www.minix3.org/ ). Solo riappropriandosi della parte più dura e più impegnativa dei progetti software open source e del loro processo di sviluppo si può sperare di ottenere più spazio all’interno di questo ecosistema (e di sviluppare competenze realmente rivendibili). Se si lascia la parte difficile del lavoro nelle mani delle aziende, saranno loro a dettare le regole.
Personalmente, mi auguro che Patrizio Tassone dia ampio spazio a Minix3 ed a progetti simili sulla sua rivista. Sarà un contributo sicuramente più utile alla causa dell’open source di qualunque lamentela, più o meno fondata, a danno di Google.
PS: Compro e leggo Linux&C dal primo numero e continuerò a farlo anche in seguito. La mia stima per Tassone ed il suo team non può certo essere incrinata da qualche divergenza di vedute di secondaria importanza.
Ti potrebbe interessare
6 giu 2008