AGPL: quando l'open source si fa 2.0

L'avvento delle applicazioni Web sta rivoluzionando il modo in cui l'utente utilizza il software, ma il software-as-a-service introduce alcuni nuovi problemi per privacy e sviluppo open source. Marco Barulli e Richard Stallman propongono una nuova ricetta
L'avvento delle applicazioni Web sta rivoluzionando il modo in cui l'utente utilizza il software, ma il software-as-a-service introduce alcuni nuovi problemi per privacy e sviluppo open source. Marco Barulli e Richard Stallman propongono una nuova ricetta

Solo fino a qualche anno fa in pochi si sarebbero aspettati che il web potesse andare oltre la semplice veicolazione di informazioni e diventare una piattaforma che ospitasse vere e proprie applicazioni. La cosa ha cambiato le regole sia nel mercato del software proprietario sia in quello del software libero e open source.

Negli ultimi giorni ha avuto un’enorme eco l’appello di Marco Barulli per una più decisa presa di posizione da parte degli sviluppatori open source (e dei suoi utenti) per tutelare l’effettiva libertà del codice (e, di nuovo, dei suoi utenti). Infatti nel caso di servizi online e applicazioni web, in cui il software non viene redistribuito all’utente, le aziende possono alterare e adattare il codice senza rendere pubbliche le modifiche, come solitamente previsto ad esempio dalla General Public License, e senza violarne la licenza. Questa possibilità deriva da quella che Tim O’Reilly, esponente di spicco della comunità open, definì già due anni fa l’obsolescenza delle licenze open source nei confronti del Web 2.0.

La soluzione a tale problema è arrivata con la licenza AGPL (Affero General Public License) la quale prevede appunto che il codice rilasciato sotto tale licenza e poi modificato debba essere a sua volta reso pubblico in ogni caso, anche se il programma gira in remoto, che è proprio il caso delle applicazioni Web 2.0.

Molte aziende utilizzano software open source modificato per creare applicazioni e servizi e un utilizzo massiccio della licenza AGPL da parte degli sviluppatori costringerebbe la pubblicazione di tali modifiche e questa è un’evenienza che alcune società non vedrebbero di buon occhio. Non sembra quindi un caso che proprio Marco Barulli che aveva scelto Google Code per ospitare i sorgenti che sono alla base del progetto Clipperz (sviluppato assieme a Giulio Cesare Solaroli) si sia visto recapitare un messaggio che lo invitava a spostare il progetto su di un altro sito, poiché «non è OK ospitare su code.google.com un programma coperto dalla AGPL».

Marco Barulli non è solo in questo appello ma è affiancato da Richard Stallman in persona. Il fondatore del progetto GNU appoggia in pieno i tre punti che vengono elencati nell’appello. Oltre al consiglio destinato agli sviluppatori web di preferire la licenza AGPL, viene proposto l’utilizzo di un paradigma zero-knowledge che permetta una maggiore tutela della privacy degli utenti. Le applicazioni web solitamente memorizzano dati e documenti degli utenti su server remoti. A tal proposito Barulli dice: «Quando sposto la mia applicazione verso il Web, […] mi piacerebbe conservare il controllo sui miei dati. Sono ancora i miei dati». Il paradigma zero-knowledge prevede la cifratura dei dati prima dell’invio al server, rendendo così il provider del servizio incapace di accedervi. Il terzo punto, infine, auspica un miglioramento degli attuali browser al fine di avere un maggiore controllo sul codice JavaScript che viene eseguito sul computer dell’utente: l’utente dovrebbe essere in grado sia di utilizzare una diversa versione del codice, personalizzando così il comportamento dell’applicazione, sia di avere la possibilità di confrontare le diverse versioni ed essere avvisato nel caso il browser stia caricando una versione aggiornata o comunque del codice JavaScript. Questa soluzione, su cui lo stesso Stallman insite parecchio, potrebbe essere realizzata tramite estensioni e plugin da applicare agli attuali browser.

L’iniziativa ha raccolto anche il consenso di Fabrizio Capobianco, presidente di Funambol, che si dice «completamente d’accordo con Marco sulla necessità della AGPL» consigliando agli sviluppatori di «adottare la AGPL fin dall’inizio, così che la comunità venga protetta e che tutte le modifiche fatto sul vostro codice vengano restituite alla comunità».

Abbiamo quindi contattato Marco Barulli il quale gentilmente ci ha concesso una breve intervista.

Come definiresti in poche righe il paradigma Zero-Knowledge e perché è così importante per gli utenti?

Marco Barulli: «È un’architettura, o forse solo delle linee guida, per consentire lo sviluppo di servizi online che non sanno nulla dei loro utenti, nemmeno il loro username. È importante perche’ oggi, quasi senza accorgercene, stiamo gradualmente traslocando molti nostri dati dall’harddisk dei nostri pc alla rete. Ma questo non deve farci dimenticare che si tratta dei nostri dati e che solo noi dovremmo averne il controllo, completo ed esclusivo. Purtroppo spesso non è così: la comodità dei servizi web (word processor, calendar, chat, wiki, …) è talmente grande che questo aspetto non viene considerato. Una applicazione zero-knowledge appare in tutto e per tutto come una qualunque applicazione web, ma ogni dato che inseriamo viene criptato localmente dal browser stesso prima di venire registrato sul server. Oltre a questo approccio (noto anche come host-proof hosting) vi sono altre cose che differenziano una applicazione zero-knowledge. Tra queste segnalo il fatto che tutto il codice Javascript che governa l’applicazione viene trasferito sul browser dell’utente in unico momento prima ancora che l’utente faccia il login. Questo consente di verificare l’integrità e la genuinità del servizio prima di iniziare ad utilizzarlo».

Molti servizi online permettono di effettuare ricerche all’interno dei propri dai (si pensi alle web mail): questo approccio non rischia di limitare alcune funzioni delle applicazioni web?

Marco Barulli: «Di certo diventa tutto più complicato, ma sono complessità risolvibili. La prossima release del password manager online di Clipperz consentirà appunto la ricerca, i tag e la condivisione. Anche il processo di autenticazione dell’utente è molto piu’ sofisticato. Noi abbiamo scelto SRP, un protocollo sviluppato dalla Stanford University che offre una sicurezza molto maggiore e non rivela nessuna delle credenziali di accesso dell’utente al server. Il costo da pagare è quello di un pò di matematica da masticare per lo sviluppatore e un paio di secondi di attesa per l’utente,ma vi è la certezza che nessuno potrà rubare nulla di interessante dai server di Clipperz, tantomeno la password di accesso».

Per ora questi sono tutti vantaggi per gli utenti. Chi mette online un servizio spesso ricava degli introiti proprio dall’analisi statistica dei dati sui suoi server (si pensi a Google che associa le pubblicità al contenuto dei messaggi su GMail). In che modo lo Zero-Knowledge potrebbe avvantaggiare i provider di servizi online?

Marco Barulli: «Innanzitutto li metterebbe al riparo da molte problematiche legali in quanto il loro ruolo si ridurrebbe a quello di conservare ed erogare dati criptati che solo sul browser diventano leggibili. Inoltre consentirebbe loro di proporre servizi online che altrimenti non sarebbero proponibili. Penso al nostro password manager, ma anche a wiki dove le aziende possano conservare dati strategicamente rilevanti. Già oggi è abbastanza normale pagare un provider per un servizio, se sapessi che con i miei dati non ci può fare nulla lo pagherei ancor più volentieri».

Passiamo al lato “sviluppatori”. Con l’utilizzo della licenza Affero, lo sviluppatore fa in modo che anche chi utilizzi il suo software per erogare servizi (quindi senza effettivamente redistribuire tale software) debba pubblicarne il codice sorgente, incluse le eventuali modifiche. Una licenza che sembra fatta apposta per software dedicato alle applicazioni web: ritieni che la AGPL possa essere d’aiuto anche ad altri progetti meno legati al mondo del Web 2.0?

Marco Barulli: «Nel caso di Clipperz, mi sento di contestare quando dici “senza effettivamente redistribuire tale software”. Infatti ogni applicazione zero-knowledge carica sul browser dell’utente il 99% del codice di cui è costituita l’applicazione prima ancora del login, mentre il restante 1% è il codice eseguito sul server finalizzato solo a leggere e scrivere dati criptati. Quindi chi eroga un servizio web basato su architettura zero-knowledge effettua una vera distribuzione di codice. E quindi per noi è stato naturale scegliere AGPL come licenza. Personalmente condivido comunque la lettura più ampia del concetto di distribuzione di software che la FSF ha voluto tutelare rilasciando la AGPL v3. Mi pare che sia uno strumento indispensabile per ampliare al web le dinamiche ed i valori del free software, altrimenti confinati ai programmi che girano solo sul computer locale. La proposta formulata insieme a Stallman e pubblicato sul blog di Clipperz punta a combinare AGPL e architettura zero-knowledge per salvaguardare sia la libertà del nostro codice che dei nostri dati».

Sempre più aziende e provider usano programmi open source, basti pensare a Google. E proprio Google ha sempre avuto un comportamento di riguardo nei confronti del software a codice aperto. Tuttavia è stata proprio Mountain View a chiudervi le porte del suo Google Code per via della licenza Affero. Ritieni possa essere un semplice buco normativo oppure Google ha volutamente escluso la AGPL?

Marco Barulli: «Di certo Google ha rilasciato tanto codice e tanti strumenti alla comunità FLOSS. Ma mi pare di poter dire che ha sempre mantenuto il controllo su cosa, come e quando rilasciare. AGPL è una licenza dagli effetti “drastici” e non mi aspetto quindi che venga adottata da Google (o Yahoo, Facebook, …). Non credo però che vi sia una vera ostilità perché comunque chi sviluppa software per il web ha sempre la strada del “dual licensing”, ovvero di avere versioni con licenza commerciale ed altre con licenza open. E se a Google interessa poter utilizzare codice AGPL senza rilasciare prodotti derivati con la medesima licenza penso che abbia la possibilità di aprire trattative con qualunque gruppo di sviluppatori che abbia scelto AGPL. (Google can you hear me? :-) ). Nel nostro caso abbiamo dovuto spostare il repository di Clipperz da Google Code a Sourceforge in quanto AGPL non è tra le licenze contemplate al momento. Google dichiara che sia una scelta mirata a combattere la proliferazione di licenze, ma non credo che Google possa accusare la FSF di aver inquinato l’ambiente pubblicando molte licenze. Anzi! AGPL sarebbe servita qualche anno fa!»

La Affero è infatti abbastanza giovane e per ora pochi progetti l’hanno abbracciata: oltre a Clipperz e Ajax Chat ci sono altri progetti che potrebbero abbracciare la AGPL nel breve termine?

Marco Barulli: «Direi che il più grande tra i progetti AGPL è certamente Funambol, che oltre ad adottare la licenza Affero ha contribuito a farle avere l’approvazione dell’OSI, ma che soprattutto ha in Fabrizio Capobianco un efficace promotore. Non so se i progetti AGPL aumenteranno in modo rapido, ma di certo auspico che il movimento Free Software smetta di guardare alle applicazioni web con sospetto, ma che le inizi a considerare una grande opportunità oggi resa concreta dalla disponibilità di AGPL. La spinta del progetto GNU/Linux per lo sviluppo di una grande suite di software GPL dovrebbe trovare un equivalente per il web e AGPL. Ed è quello che insieme a Stallman abbiamo proposto: una suite AGPL di applicazione web “di base” che poi vengano migrate all’architettura zero-knowledge».

Ti consigliamo anche

Link copiato negli appunti