Analisi Dell'evoluzione Dei Web Desktop E Rilascio Di Un'alternativa Open Source

UNIVERSITÀ DEGLI STUDI DI TRENTO Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea (triennale) in Informatica ________________________________________________________________________________ Elaborato finale

Analisi dell'evoluzione dei Web Desktop e rilascio di un'alternativa open source

Relatore: Marco Ronchetti

Laureando: Michele Dalla Torre

Correlatore: Paolo Massa

Anno Accademico 2007 – 2008

Indice generale Capitolo 1: Introduzione.......................................................................................................................4 Contesto...........................................................................................................................................4 Contributi.........................................................................................................................................5 Struttura della tesi............................................................................................................................5 Capitolo 2: Stato dell'arte.....................................................................................................................7 Concetti............................................................................................................................................7 Web 2.0.......................................................................................................................................7 Enterprise 2.0..............................................................................................................................9 Rich Internet Application (RIA) ..............................................................................................12 Sistemi esistenti ............................................................................................................................12 iGoogle......................................................................................................................................12 Netvibes....................................................................................................................................14 Liferay Portal ...........................................................................................................................15 Capitolo 3: Taolin...............................................................................................................................17 Contesto.........................................................................................................................................17 Cosa è la Fondazione Bruno Kessler?.......................................................................................17 Cosa è SoNet?...........................................................................................................................17 Obiettivi di SoNet.....................................................................................................................17 Strategie di ricerca e di sviluppo in SoNet................................................................................18 Mashup.................................................................................................................................19 L'applicazione web: Taolin............................................................................................................19 Use cases, screenshots, spiegazione del sistema.......................................................................19 Header..................................................................................................................................20 Barra laterale........................................................................................................................21 Photo manager.................................................................................................................22 Widget..................................................................................................................................22 Chat......................................................................................................................................23 Architettura del sistema.................................................................................................................23 Architettura 2-tier: back end e front end...................................................................................23 Back end: CakePHP .................................................................................................................25 Caratteristiche principali .....................................................................................................26 Alternative............................................................................................................................26 Front end: ExtJS........................................................................................................................26 Caratteristiche.......................................................................................................................26 Comparazione con jQuery....................................................................................................27 Database e procedure di log......................................................................................................28

Protocolli di comunicazione......................................................................................................29 REST....................................................................................................................................29 Comunicazione tra back end e front end: JSON..................................................................29 JSON e XML........................................................................................................................29 Esempio di una risposta JSON.............................................................................................30 Debug tra back end e front end.................................................................................................31 Guida alla creazione di una widget per feedback..........................................................................32 Back end....................................................................................................................................33 Aggiunta di una nuova view.................................................................................................33 Aggiunta di un nuovo model................................................................................................34 Aggiunta di un nuovo controller..........................................................................................34 Front end...................................................................................................................................36 Capitolo 4: Modifiche all'applicazione e rilascio in open source.......................................................39 Contributo personale allo sviluppo dell'applicazione....................................................................39 Strumenti utilizzati....................................................................................................................40 Subversion.................................................................................................................................40 Generalizzazione del codice......................................................................................................41 Aggiunta di un file di configurazione in CakePHP...................................................................41 Creazione delle classi relative a vari metodi di autenticazione.................................................42 Modifiche al controller in CakePHP per gestire dinamicamente il metodo di autenticazione. 46 Versione demo..........................................................................................................................48 Guida all'installazione dell'applicazione...................................................................................48 Analisi delle licenze.......................................................................................................................49 Licenze software.......................................................................................................................49 Licenze proprietarie..............................................................................................................49 Licenze open source.............................................................................................................49 Licenze open source e applicazioni web...................................................................................51 Il problema dell'ASP loophole.............................................................................................51 Il caso di Facebook e la licenza Common Public Attribution License (CPAL)...................53 Critiche alla licenza CPAL ed a Facebook...........................................................................54 Le risposte di Facebook........................................................................................................59 Licenza Affero General Public License (AGPL).................................................................60 Come licenziare sotto GNU GPL, LGPL, AGPL..........................................................................60 Licenze dei componenti del sistema..............................................................................................63 CakePHP...................................................................................................................................63 ExtJS.........................................................................................................................................64 Altri componenti.......................................................................................................................67 Discussione sulla licenza da adottare e scelte finali......................................................................67 Capitolo 5: Conclusioni......................................................................................................................69

Capitolo 1: Introduzione

Capitolo 1: Introduzione L'obiettivo di questa tesi consiste nel rilascio, sotto licenza open source, di una piattaforma web Enterprise 2.0, sviluppata nell'ambito dell'istituto di ricerca Fondazione Bruno Kessler di Trento. Per fare ciò è stata necessaria un'attenta comprensione e generalizzazione del codice sorgente al fine di rendere l'applicazione indipendente ed utilizzabile su qualsiasi rete, quindi un'analisi teorica di alcune licenze software open source in vista della scelta finale relativa alla licenza sotto cui rilasciare l'intera piattaforma web. Questa piattaforma, denominata Taolin, si propone di migliorare la collaborazione e più in generale la diffusione del sapere tra gli impiegati ed i ricercatori della fondazione stessa, destinatari finali di tale progetto.

Contesto Il mondo tecnologico, ed in particolare internet, è una realtà imperfetta ed in continuo divenire al servizio dell'umanità, che si evolve progressivamente con il nobile intento di fornire soluzioni ed aiuti sempre migliori ai problemi della vita quotidiana di ogni essere umano. Recentemente si è assistito ad un'evoluzione, più filosofica che non tecnica e strutturale, riguardo al mondo web. Tale evoluzione, denominata “Web 2.0”, si propone di accrescere la creatività, la diffusione delle informazioni e non per ultimo la collaborazione tra gli utenti, trasformando le vecchie pagine web, ormai statiche e non più capaci di attirare l'attenzione dei navigatori, in nuovi servizi realmente interattivi e collaborativi. Il web quindi non è più soltanto un luogo dove reperire le informazioni, ma diventa esso stesso un nuovo punto di partenza per la creazione e la diffusione di queste ultime, invitando ogni singolo individuo a partecipare a questa missione universale. E' proprio questo forse l'aspetto più interessante del Web 2.0: la rivoluzione nel rapporto tra utente e servizi web, con la quale viene posta al centro dell'attenzione la persona che non è più una mera fruitrice di contenuti ma ne è essa stessa anche l'autrice. Ogni strumento quindi che renda più semplice l'aggiornamento di informazioni e la condivisione delle stesse, o in altre parole che permetta un elevato livello di interazione utente-servizio web, è in qualche modo correlato al Web 2.0. In stretta relazione con il concetto di Web 2.0 è anche quello di Enterprise 2.0 che fa riferimento alle situazioni in cui viene usato social software in contesti aziendali. Il fine principale dell'Enterprise 2.0, similmente a quello del Web 2.0, è favorire la comunicazione e più in generale la diffusione della conoscenza all'interno delle aziende, adattando le tecnologie esistenti ad un sistema di reti sociali. All'interno di tale contesto si colloca la creazione dell'applicazione Taolin, con l'obiettivo di 4

Capitolo 1: Introduzione diventare reale portatrice dei principali valori dell'Enterprise 2.0 all'interno della Fondazione Bruno Kessler. La decisione di sviluppare ex novo una piattaforma web Enterprise 2.0, invece di adottare un qualche strumento già esistente, è stata presa principalmente perché non erano presenti, al momento dell'avvio del progetto, applicazioni open source di questo tipo. Proprio per questo motivo, appare subito evidente l'importanza di un'applicazione come Taolin ed in modo particolare il suo rilascio sotto licenza open source.

Contributi Lo sviluppo del software è iniziato nel mese di marzo 2008 ed è stato realizzato, in parte anche dal sottoscritto, durante lo stage presso la Fondazione Bruno Kessler. In questa tesi si riportano i contributi relativi al rilascio in open source del software stesso; in particolare i contributi personali apportati sono suddivisi in due parti. La prima parte descrive innanzitutto gli strumenti utilizzati durante il progetto; poi il lavoro svolto sulla generalizzazione del codice, ovvero lo sforzo fatto per rendere lo stesso indipendente dall'ambiente su cui è eseguito e quindi utilizzabile su qualsiasi rete; la creazione di un file di configurazione per personalizzare in modo immediato e totalmente automatico alcuni parametri; la creazione e la gestione dinamica di diversi metodi di autenticazione per poter utilizzare l'applicazione con varie tipologie di database; la creazione di una versione demo dimostrativa ed infine la redazione di una guida per l'installazione della piattaforma web. La seconda parte presenta invece una spiegazione sulle licenze software e la differenza che intercorre tra le licenze software proprietarie e le licenze software open source; un'analisi teorica di alcune licenze open source, in particolare della licenza Common Public Attribution License (CPAL) e della licenza Affero General Public License (AGPL); una guida con le operazioni da effettuare per licenziare del software sotto licenza open source, quindi le licenze dei vari componenti del sistema sviluppato ed infine le decisioni prese riguardo alla scelta della licenza dell'intera piattaforma.

Struttura della tesi Nel capitolo 2 vengono presentati alcuni concetti chiave relativi al contesto in cui si colloca Taolin, quali quello di Web 2.0 e di Enterprise 2.0. Sono poi brevemente descritte alcune applicazioni web esistenti, ovvero iGoogle, Netvibes e Liferay Social Portal. Nel capitolo 3 viene presentata la piattaforma web sviluppata. Inizialmente viene illustrato l'ambiente in cui la piattaforma si è venuta a creare, descrivendo in particolar modo il gruppo di lavoro e gli obiettivi alla base di tale progetto. Viene poi mostrata ed analizzata la web application creata, spiegando in concreto le caratteristiche principali e le funzionalità offerte all'utente. 5

Capitolo 1: Introduzione Segue quindi una descrizione dell'architettura del sistema che presenta i programmi usati ed il modo in cui sono correlati tra loro. Infine, tramite una guida redatta dal sottoscritto, si introduce una nuova widget nel sistema, descrivendo passo passo le operazioni necessarie per raggiungere tale obiettivo. Nel capitolo 4 viene presentato il contributo personale apportato allo sviluppo della piattaforma, suddiviso in due parti: la prima, pratica, con le modifiche effettuate al codice sorgente dell'applicazione; la seconda, teorica, con un'analisi di alcune licenze open source e la scelta della licenza da adottare per l'applicazione sviluppata. Infine il capitolo 5 contiene le conclusioni del lavoro svolto in questa tesi.

6

Capitolo 2: Stato dell'arte

Capitolo 2: Stato dell'arte Taolin vuole essere un ambiente Enterprise 2.0 all'interno della Fondazione Bruno Kessler. Prima di analizzare nei dettagli la sua struttura ed il suo sviluppo è opportuno considerare la filosofia sulla quale è basato. Pertanto viene presentata ora una breve spiegazione riguardo all'Enterprise 2.0 ed i principi sui quali quest'ultimo fa a sua volta riferimento, vale a dire il Web 2.0. In seguito sono presentati alcuni web desktop.

Concetti Web 2.0 Con il nome di Web 2.0 si fa riferimento alla nuova generazione di servizi web offerti su internet; “2.0” sta ad indicare infatti questa seconda generazione così come il nuovo modo di pensare che è alla base di questa rivoluzione nel mondo virtuale.

Illustrazione 1: Un'immagine simbolica del Web2.0: gli utenti sono i veri autori che hanno reso possibile questa evoluzione E' importante però notare come il Web 2.0 non sia però un cambiamento da un punto di vista tecnico, nonostante vi sia stato chiaramente anche uno sviluppo in tal senso, quanto piuttosto il nuovo modo di porre in relazione l'utente con internet. Infatti il punto centrale attorno a cui si creano i servizi è l'utente, il quale ricerca in internet un nuovo e più alto livello di interazione. Si sono venuti pertanto a creare molti strumenti nuovi per favorire la diffusione di conoscenza, la collaborazione e il social networking, come per esempio i blog (dei diari virtuali), i wiki (delle piattaforme web che permettono a tutti gli utenti di modificare ed aggiornare i contenuti, in una sorta di partecipazione diretta alla diffusione di conoscenza), ecc. Il Web 2.0 si propone di accrescere la creatività, la diffusione delle informazioni e non per 7

Capitolo 2: Stato dell'arte ultimo la collaborazione tra gli utenti, trasformando le vecchie pagine web statiche in nuovi servizi realmente interattivi. Un'ulteriore definizione del Web 2.0 è “internet per le persone”: il web appunto non è più solamente un posto dove reperire le informazioni ma diventa esso stesso un punto di partenza per la creazione e la diffusione delle stesse, invitando ogni singolo individuo a partecipare in questa missione universale. Sono gli utenti stessi che creano contenuti e contribuiscono attivamente alla realizzazione dei servizi web. E' proprio questo forse l'aspetto più interessante del Web 2.0: la rivoluzione nel rapporto tra utente e servizi web, con la quale viene posta al centro di tutto la persona che non è più una mera fruitrice di contenuti ma ne è anche essa stessa l'autrice. Ogni strumento quindi che renda più semplice l'aggiornamento di informazioni e la condivisione delle stesse, o in altre parole che permetta un elevato livello di interazione utente-servizio web, è in qualche modo correlato al Web 2.0. Questa possibilità di creare, modificare e condividere contenuti direttamente sul web è una caratteristica peculiare del Web 2.0 ed è attuata tramite una serie di strumenti online che in qualche modo rendono internet stessa un'unica applicazione. In altre parole, nel Web 2.0 l'utente può usare molti servizi che svolgono le stesse funzioni svolte, fino a poco tempo fa, da programmi da installare sui singoli computer. Un'altra caratteristica propria del Web 2.0 è la pubblicazione istantanea e la relativa indicizzazione dei contenuti. In questo modo l'informazione è resa subito disponibile a tutta la comunità in maniera pressoché immediata. Da un punto di vista prettamente tecnologico il Web 2.0 è in tutto e per tutto simile al Web 1.0 poiché usa la stessa infrastruttura di rete, ovvero HTTP e TCP/IP e l'ipertesto rimane sempre l'elemento dominante sul web. Nonostante non vi sia stata quindi una vera e propria rivoluzione in tal senso, è possibile comunque riscontrare alcune caratteristiche comuni nei servizi Web 2.0. Si fa sempre più uso di nuove tecnologie, in particolar modo di Ajax, REST e librerie JavaScript di vario genere, al fine di fornire all'utente delle interfacce intuitive, leggere e comode da usare. Da un punto di vista prettamente grafico i colori usati, per esempio nei loghi dei servizi web, sono vivaci ed attraenti; spesso si fa uso di effetti grafici per simulare riflessioni e di effetti “glossy” (letteralmente “lucido”). La chiave di tutto, in una sola parola, è la semplicità, senza per questo penalizzare l'estetica, ma rendendola anzi ancora più accattivante. I siti web 2.0 contengono generalmente alcuni dei seguenti elementi riuniti sotto l'acronimo di SLATES, coniato da Andrew McAfee: 1. Search: (ricerca) la capacità di trovare in modo intuitivo ed istantaneo, tramite parole chiave, le informazioni desiderate dando quindi un valore aggiunto alla piattaforma web. 2. Links: (collegamenti) riferimenti alle informazioni giudicate più importanti; le pagine migliori sono molto spesso quelle verso le quali sono presenti più collegamenti. 3. Authoring: (gestione dei contenuti) la capacità di creare contenuti costantemente aggiornabili da ogni utente tramite un lavoro condiviso. Per esempio nei wiki il 8

Capitolo 2: Stato dell'arte contenuto è iterativo, in quanto le persone scrivono e riscrivono il lavoro di ognuno. Nei blog il contenuto è invece cumulativo, poiché gli articoli ed i relativi commenti sono accumulati nel tempo. 4. Tags: (etichette) categorizzazione dei contenuti sotto forma di semplici etichette, parole chiave per descrivere informazioni, per permettere una ricerca veloce e facile, evitando rigide categorie pre-costruite. 5. Extensions: (estensioni) automazione di alcuni processi e pattern matching tramite particolari algoritmi. 6. Signals: l'uso di RSS (Really Simple Syndication) per notificare agli utenti i cambiamenti dei contenuti per mezzo di e-mail e non solo.

Illustrazione 2: Il modello SLATES di Andrew McAfee

Enterprise 2.0 L'Enterprise 2.0, conosciuto anche con il nome di Enterprise social software, fa riferimento alle situazioni in cui viene usato social software in contesti aziendali. Una definizione comunemente accettata è la seguente: “l’uso in modalità emergente di piattaforme di social software all’interno delle aziende o tra le aziende ed i propri partner e clienti.” Si differenzia dai programmi Enterprise in quanto, contrariamente a questi ultimi che impongono spesso una struttura ben definita e stabilita a priori, tende ad incoraggiare l'uso rispetto alla struttura. L'obiettivo dell'Enterprise 2.0, similmente al Web 2.0, è favorire la comunicazione e più in generale la diffusione di conoscenza all'interno delle aziende, modificando per esempio le 9

Capitolo 2: Stato dell'arte intranet già esistenti per adattarle ad un sistema di reti sociali. Nella pratica una piattaforma può essere definita Enterprise 2.0 se fa uso dei componenti analizzati nella sezione precedente, vale a dire quelli del modello SLATES: meccanismi di ricerca, presenza di link, possibilità di contribuire modificando i contenuti, gestione delle etichette, meccanismi automatici di suggerimento, notifiche riguardo agli aggiornamenti. Tuttavia alcuni esperti hanno contestato questa definizione in quanto convinti del fatto che non tiene conto in modo completo di tutti i principi alla base dell'Enterprise 2.0. Infatti nonostante gli SLATES facciano riferimento in sostanza alle funzionalità di un'applicazione, non considerano tuttavia i concetti principali quali la socialità, l'emergenza e la mancanza di struttura. Inoltre non viene dato sufficiente rilievo al fatto che l'applicazione sia network based: non basta che la piattaforma sia accessibile tramite internet, è necessario che il contenuto sia suddiviso in pezzi di codice accessibile tramite indirizzi (URL) diretti e progettato appositamente per il web. Questo ha portato ad una nuova definizione di Enterprise 2.0, coniata da Dion Hinchcliffe sotto l'acronimo di FLATNESSES. I quattro nuovi punti aggiunti sono: 1. Freeform: (letteralmente “forma libera”) significa che la piattaforma non ha una struttura definita a priori bensì una struttura libera, che viene creata e continuamente modificata dagli utenti stessi tramite l'uso di wiki, aggregatori di link, ecc. Questo risponde all'idea di un'esperienza egualitaria e democratica tra utenti, nella quale ognuno diviene autore di un'opera più grande, nessuno escluso. Un'ulteriore interpretazione da un punto di vista tecnico potrebbe essere il fare uso di tecnologie quali AJAX, PHP, Silverlight e non solo per costruire interfacce semplici orientate veramente alla rete ed all'utente finale. 2. Network-oriented: (orientato alla rete) significa che i contenuti devono essere completamente web oriented, cioè sviluppati per la rete con la possibilità di indicizzarli, rintracciarli e riusarli. 3. Social: (sociale) significa mettere in collegamento gli utenti tra loro e dare loro soluzioni sociali, permettendo di interagire secondo le più disparate modalità (per esempio dando loro la possibilità di salvare una lista di preferiti, di cambiare il proprio status personale per comunicare messaggi ad altri, di mostrare gli ultimi cambiamenti effettuati da ogni utente, ecc.). 4. Emergence: (nel senso di “emersione”) significa fare emergere qualcosa di complesso da numerose e relativamente semplici interazioni. Per fare un esempio pratico, un documento è un prodotto che “emerge” da un wiki: grazie alle tante modifiche, spesso molto semplici o brevi, di ogni utente viene creato un documento (molte volte più completo che non se fosse stato scritto da un'unica persona) dai contenuti più che validi.

10

Capitolo 2: Stato dell'arte

Illustrazione 3: il modello FLATNESSES per l'Enterprise 2.0 secondo Dion Hinchcliffed Alla luce di queste considerazioni appare evidente che la struttura delle piattaforme Enterprise 2.0 non è verticale o gerarchica, bensì orizzontale, piatta, nella quale le informazioni fluiscono liberamente tra gli utenti e sono raggiungibili da tutti (si pensi al caso degli RSS). Un ulteriore aspetto importante riguarda l'adozione dei servizi Enterprise 2.0. Essi tendono ad emergere in modo autonomo, senza essere imposti dall'alto, e riescono a migliorarsi e ad assolvere ai loro obiettivi tanto più facilmente quanto più utenti li usano. Il loro stesso valore intrinseco dipende dalla qualità e dalla quantità di informazioni che riescono a mettere a disposizione, e questo chiaramente è pesantemente influenzato dal numero di utenti che ne fanno parte. I contenuti creati vengono poi messi in relazione uno con l'altro grazie all'uso di link ma soprattutto di etichette: questa rete di relazioni viene creata dal basso in maniera attiva e viene poi a sostituire la vecchia struttura imposta dai vecchi modelli di programmi Enterprise 2.0.

Illustrazione 4: grado di “emergenza”di piattaforme tipiche dell'Enterprise 2.0 11

Capitolo 2: Stato dell'arte

Rich Internet Application (RIA) Con il termine Rich Internet Application (RIA) si indicano applicazioni web che sono simili, per funzionalità e caratteristiche, alle tradizionali applicazioni software, ma al contrario di queste non necessitano né del disco fisso né di alcuna installazione. Per accedere alle RIA si fa uso generalmente di un comune web browser, generando in questo modo un tipo di interazione remota tra utente ed applicazione. Inoltre le RIA sono divise in due parti: una che si occupa di elaborare i dati forniti ed interagire con l'utente tramite un'interfaccia grafica, un'altra invece che gestisce l'applicazione vera e propria e mantiene la maggior parte dei dati sul server, velocizzando in questo modo la risposta data all'utente.

Sistemi esistenti In questa sezione sono presentati alcuni esempi di Software as a Service (SaaS). Con questo termine si fa riferimento ad un modello di sviluppo di software secondo il quale un'applicazione viene distribuita come un servizio web a richiesta per gli utenti. Le caratteristiche principali di un SaaS sono: ●

disponibilità del sistema via rete, generalmente internet, risparmiando in tal modo all'utente la necessità di un'installazione del software sul proprio sistema operativo e permettendo inoltre una maggiore fruibilità essendo il sistema in remoto e pertanto accessibile da qualunque tipo di macchina connessa alla rete;

●

significativa riduzione dei costi di licenza e di gestione;

●

scalabilità del prodotto che permette di realizzare soluzioni ad hoc;

●

gestione dell'applicazione secondo il modello uno a molti;

●

gestione centralizzata degli aggiornamenti che evita la necessità di scaricare patch e upgrade.

iGoogle iGoogle [1] è un servizio di Google che permette di creare una pagina web personalizzabile tramite un'interfaccia basata sulla tecnologia AJAX; tale pagina generalmente viene impostata per essere la pagina di avvio del web browser, in quanto raccoglie al suo interno le informazioni giudicate più interessanti ed utili da ogni utente. All'utente è data la possibilità di scegliere tra diversi gadget che sono stati implementati facendo uso delle Google Gadgets API che sono pubbliche e liberamente utilizzabili, permettendo così a chiunque di sviluppare nuovi gadget. I gadget comprendono una vastissima raccolta di applicazioni: vi sono gadget per integrare in iGoogle tutti gli altri servizi di Google come Gmail (servizio di posta elettronica), Google Reader (servizio di feed RSS), Google Blocco Note (servizio che 12

Capitolo 2: Stato dell'arte permette di salvare online delle note testuali ed eventualmente condividerle con altri utenti), Google Maps ed altri, servizi di feed RSS (alcuni predefiniti con le ultime notizie dei più importanti siti web giornalistici, altri personalizzabili) ed utility di ogni tipo (orologi, calendari, meteo, mappe, giochi, ecc.). Proprio per la grandissima varietà e moltitudine di gadget, è facile riempire in fretta tutta la pagina. Per questo motivo vi è la possibilità di ordinare i gadget su tre colonne, trascinandoli e rilasciandoli nella posizione desiderata. Da qualche tempo è stata poi introdotta la possibilità di aggiungere delle “schede”: queste non sono altro che nuove pagine web, accessibili dalla pagina principale, ognuna contenente gadget, permettendo così un'organizzazione migliore del contenuto (ad esempio è possibile creare una scheda e chiamarla “notizie” per raccogliere al suo interno tutti i feed RSS giudicati interessanti). Sono poi presenti diversi temi, anche questi personalizzabili a discrezione. Alcuni sono dinamici e cambiano a seconda delle condizioni del tempo di un certa località, impostata precedentemente (per esempio compaiono delle nuvole se fuori è nuvoloso e così via), o dell'ora.

13

Capitolo 2: Stato dell'arte

Illustrazione 5: Esempio di pagina iGoogle con alcune widget inserite e personalizzate

Netvibes Similmente ad iGoogle anche Netvibes [2] è una pagina iniziale personalizzabile e basata su tecnologia AJAX. Il contenuto, come già visto per il servizio analizzato precedentemente, è organizzato in schede chiamate tab, ognuna suddivisa in tre colonne dove vengono inseriti i gadget. A differenza però di iGoogle, dove è possibile soltanto trascinare e rilasciare i gadget in colonne diverse, Netvibes si distingue per una funzionalità particolare: è possibile infatti trascinare le stesse colonne ridimensionandole a piacimento. I gadget predefiniti di Netvibes includono feed RSS, meteo, calendari, note, segnalibri, liste di cose da fare, motori di ricerca, lettura email tramite POP3 ed IMAP4, foto di Flickr e radio.

14

Capitolo 2: Stato dell'arte Anche Netvibes fa uso di API, le Netvibes Universal Widget API (UWA), per permettere ai suoi utenti di sviluppare applicazioni e nuovi moduli. E' poi possibile scegliere tra una vasta lista di temi e sfondi o addirittura crearne di propri. A differenza di altri servizi simili, come Pageflaker, My Yahoo! e Microsoft Live giusto per citarne alcuni, Netvibes è forse il più orientato ad attirare gli utenti tramite una grafica molto curata per la semplicità, i colori e soprattutto gli effetti realizzati tramite AJAX. Inoltre è molto orientato verso l'utente: il servizio mette infatti a disposizione diverse funzionalità per aggiungere amici e condividere con loro gadget e tab.

Illustrazione 6: La pagina principale di Netvibes con le widget predefinite

Liferay Portal Liferay Portal Standard Edition (SE) [3] è un insieme di strumenti pronti all'uso per permettere ad amministratori ed utenti di creare in modo facile e veloce un sito web, sia per intranet che per extranet, una piattaforma di collaborazione, un social network o altro. Gli strumenti a disposizione comprendono oltre 60 applicazioni e più di 20 temi personalizzabili; tra le altre cose si possono usare wiki, blog, chat e calendari condivisi. Modificare il portale è un'operazione facile, infatti non è necessario essere dei programmatori grazie all'interfaccia drag&drop che permette l'inserimento e lo spostamento delle varie widget all'interno della pagina principale. 15

Capitolo 2: Stato dell'arte Il linguaggio di programmazione utilizzato è Java, pertanto l'applicazione risulta essere multi piattaforma. Per quanto riguarda la licenza sotto la quale è rilasciato il software, Liferay si è avvalsa del modello dual licensing; è possibile pertanto scaricare ed utilizzare la piattaforma Liferay Portal Standard Edition (SE) con licenza MIT, o in alternativa comprare una licenza commerciale, la quale dà diritto inoltre a numerosi servizi di assistenza, per la piattaforma Liferay Portal Enterprise Edition (EE). Le differenze principali tra la edizione SE e quella EE sono, a parte la licenza, il target verso cui la piattaforma è indirizzata (utenti e sviluppatori che vogliono contribuire ad un nuovo progetto open source la prima, organizzazioni ed aziende commerciali che necessitano di una versione stabile la seconda) ed il supporto offerto (una comunità di sviluppatori la prima, gli sviluppatori di Liferay la seconda).

Illustrazione 7: Liferay Portal Standard Edition (SE): homepage con alcune applicazioni inserite

16

Capitolo 3: Taolin

Capitolo 3: Taolin In questo capitolo viene spiegato il contesto all'interno del quale è stata sviluppata la piattaforma Enterprise 2.0 Taolin, quindi si mostrano le caratteristiche che offre ed infine l'architettura di tale applicazione.

Contesto Cosa è la Fondazione Bruno Kessler? La Fondazione Bruno Kessler (in breve FBK), è un importante centro di ricerca scientifica situato a Trento, nel nord Italia. La “Fondazione Bruno Kessler - con più di 350 ricercatrici e ricercatori - svolge attività di ricerca principalmente negli ambiti delle Tecnologie dell'Informazione, dei Materiali e Microsistemi, degli Studi Storici italo-germanici e delle Scienze Religiose. Grazie ad una fitta rete di alleanze e collaborazioni, FBK opera anche negli ambiti della fisica nucleare teorica, delle reti e telecomunicazioni e delle scienze sociali (ricerca valutativa sulle politiche pubbliche). Gli obiettivi di FBK sono: ●

svolgere ricerca riconosciuta a livello internazionale;

●

perseguire risultati applicativi in aree selezionate di valenza strategica per il territorio;

●

sviluppare, valorizzare e disseminare i risultati di ricerca;

●

promuovere l’innovazione a livello territoriale.” [4]

Cosa è SoNet? Il gruppo SoNet è stato fondato nei primi mesi del 2008 sotto la guida di Maurizio Napolitano e Paolo Massa. Il nome “SoNet” ha origine da “Social Networking”.

Obiettivi di SoNet Gli obiettivi del gruppo SoNet sono fare ricerca, sia teorica che pratica. La prima si propone di raccogliere dati per poterli analizzare e capire le esigenze all'interno di FBK; la seconda invece si propone di rendere più semplice ed intuitiva la collaborazione tra scienze umanistiche e scientifiche, apportando innovativi contributi alla caratterizzazione delle reti sociali e della loro costante evoluzione nel tempo. In concreto il gruppo SoNet ha intenzione di fornire nuovi servizi avanzati a tutti gli utenti, sviluppando un vero sistema di social networking all'interno della fondazione FBK per 17

Capitolo 3: Taolin mezzo di un portale web. Questo portale è stato e continuerà ad essere sviluppato sulle reali esigenze dei ricercatori in FBK, chiedendo loro di cosa abbiano veramente bisogno e di cosa pensino sarebbe utile per migliorare il loro lavoro. Un'altra idea poi è di offrire questo strumento ai giovani per indirizzarli verso il mondo tecnologico e della ricerca. E' un dato di fatto che i giovani sono i principali attori alla base dell'enorme successo dei social network in tutto il mondo; per SoNet è quindi molto importante ed interessante studiare questo fenomeno che è in continua crescita e sta cambiando la nostra società. Infine SoNet si propone di pubblicizzare la ricerca e condividere il lavoro con altre entità internazionali come centri di ricerca ed aziende in modo da far emergere la fondazione FBK in questa particolare area di ricerca.

Strategie di ricerca e di sviluppo in SoNet Il progetto SoNet si fonda principalmente sugli stessi valori alla base del web 2.0, ovvero aggregazione, condivisione, collaborazione e disseminazione. Aggregazione significa aggregare, riunire, raccogliere dati in una singola pagina con lo scopo di migliorare il flusso lavorativo evitando di perdere troppo tempo a cercare le informazioni che servono. Condivisione significa condividere la conoscenza, per esempio usando una licenza creative common. Collaborazione significa collaborare tra persone per aiutarsi reciprocamente a sviluppare un compito. Disseminazione significa distribuire i risultati di uno studio su internet, in un'ottica di condivisione della conoscenza con ogni singolo individuo in tutto il mondo, nessuno escluso. Le principali strategie su cui si base il progetto SoNet sono: ●

“eating your own dog food”: (tradotto letteralmente “mangiare il cibo del proprio cane”) significa usare il software sviluppato dalla propria azienda, FBK nel nostro caso, all'interno dell'azienda stessa, dando così un senso di fiducia agli impiegati verso i prodotti sviluppati dalla propria ditta e rendendo anche possibile l'individuazione immediata di bug o problemi ancora prima che vengano scoperti dagli utenti finali.

●

Champions: (letteralmente “campioni”) è stato scelto inizialmente un ristretto numero di persone, chiamate “campioni”, per una fase di testing dell'applicazione e per raccogliere feedback prima di dare l'accesso a tutti i lavoratori di FBK. La speranza è quella che i “campioni” troveranno il progetto molto utile e tramite passaparola inviteranno altri ricercatori a fare richiesta di accesso alla piattaforma web.

●

Diffusione virale controllata: dando accesso inizialmente ad un numero limitato di utenti è risultato particolarmente utile per controllare la diffusione dell'uso della piattaforma web all'interno di FBK. 18

Capitolo 3: Taolin ●

“Always in beta”: (tradotto “sempre in beta”) questa è la strategia comune adottata da tutti i principali servizi web 2.0 e consiste nell'avere un prodotto in continuo sviluppo migliorandolo nel tempo via via che gli utenti lo provano e danno suggerimenti.

●

Prosumer: questa figura, che è divenuta l'attore più importante nel web 2.0, è, come l'unione di un “consumer” (consumatore) con un “producer” (produttore). L'utente infatti non è più un mero consumatore di un servizio, vale a dire un attore passivo, bensì contribuisce attivamente al miglioramento della piattaforma diventando in tal modo esso stesso un produttore.

●

Open source: l'applicazione sviluppata sarà rilasciata sotto una licenza open source.

●

Widget: una widget è un pezzo di codice che può essere inserito in una pagina web, aggiungendo del contenuto dinamico a quest'ultima. Le widget sono molto utili perché possono essere usate in diverse applicazioni; per questo motivo in genere sono sviluppate da terze parti, nonostante questo non sia un requisito fondamentale. Nel nostro caso infatti sono state sviluppate personalmente.

Mashup

Taolin si propone di aggregare le informazioni provenienti da posti differenti in un unico spazio, integrando anche servizi già esistenti, laddove presenti. Un esempio dei più interessanti è l'aggregazione delle pubblicazioni dei ricercatori: ci siamo collegati ad un database, interno a FBK ma allo stesso tempo esterno al gruppo SoNet, per raccogliere informazioni, aggregarle e visualizzarle infine su Taolin. Questo è stato fatto creando un nuovo controller CakePHP che è interfacciato con il database delle pubblicazioni. Il risultato delle query è poi codificato in JSON e spedito ad una widget (un file JavaScript) che lo legge e lo visualizza sul portale, mostrando il titolo di ogni pubblicazione e creando un link alla stessa.

L'applicazione web: Taolin Use cases, screenshots, spiegazione del sistema Le nostre intenzioni originali riguardavano lo sviluppo di un portale, ovvero di qualcosa di simile a iGoogle o Netvibes, ma il più possibile orientato ad un contesto Enterprise 2.0 visto l'utilizzo previsto all'interno della fondazione Bruno Kessler. Dopo numerose ricerche che non hanno dato risultati conformi alle aspettative, si è deciso di implementare un nuovo portale da zero. A questo proposito è stato trovato un interessante esempio di questo tipo sul sito internet di ExtJS, chiamato “Portal”. Come si può vedere dall'immagine 8, la finestra del browser è divisa in tre parti: 19

Capitolo 3: Taolin 1. l'header, il quale può contenere il logo del sito internet ed una casella di scelta multipla per selezionare il tema desiderato per il portale; 2. il pannello di sinistra, il quale contiene diverse “tab”, utile per mostrare informazioni correlate alle widget; 3. la finestra centrale dei contenuti che ha al suo interno molte widget di diversi tipi. Abbiamo iniziato a sviluppare l'applicazione introducendo nuove caratteristiche ed adattandola ai nostri scopi.

Illustrazione 8: ExtJS Portal Header

Abbiamo aggiunto il logo di sulla sinistra, mentre sulla destra è mostrato il nome utente, un collegamento per modificare il profilo personale, un altro per aggiungere nuove widget, un terzo per impostare Taolin come homepage, una pagina con le domande più frequenti (FAQ) ed infine un pulsante per disconnettersi dal sistema. Al centro dell'header è stato poi aggiunto un messaggio casuale che visualizza alcuni consigli utili e caratteristiche del portale; tale messaggio può essere nascosto dall'utente.

20

Capitolo 3: Taolin Barra laterale

La barra laterale, chiamata “Manager Panel”, viene usata per mostrare informazioni relative agli utenti. Essa è formata da due tab: ●

“User profile” (profilo utente): quando l'applicazione viene caricata, questa tab è quella mostrata in modo predefinito. Contiene informazioni riguardo all'utente al momento connesso al sistema, quali la sua foto (modificabile a piacimento come vedremo in seguito), due collegamenti per modificare il profilo e la foto, il nome utente (modificabile anche questo), la login, l'e-mail, il sito web personale e l'unità FBK (il gruppo in FBK di cui fa parte l'utente).

●

“Edit profile” (modifica profilo): questa tab, visualizzata quando si clicca sul simbolo “+” nella parte inferiore della barra laterale, permette all'utente di modificare ed aggiornare i propri dati personali quali la data di nascita, l'e-mail, il numero telefonico, il sito web personale ed una descrizione di se stesso. Nella parte inferiore sono presenti alcuni collegamenti per salvare le modifiche, cancellarle, modificare la foto o visualizzare il proprio profilo personale.

Illustrazione 9: Taolin: il pannello personale sulla sinistra e la finestra per aggiungere nuove widget al centro

La barra laterale è un componente sociale molto importante: ogniqualvolta un utente clicca sul nome utente di un'altra persona presente in alcune widget, visualizza informazioni 21

Capitolo 3: Taolin relative all'utente selezionato. Per esempio è possibile effettuare una ricerca tra altri colleghi di FBK attraverso la widget “Search user”, poi cliccando sul nome di ognuno sarà possibile visualizzare il profilo (fotografia, nome, numero telefonico, ecc.) direttamente nella barra laterale.

Photo manager

Ad ogni utente viene data la possibilità di caricare sulla piattaforma web quante fotografie desidera attraverso un semplice photo manager. Si può aggiungere in seguito una descrizione alle immagini e, cliccando su una di queste, la fotografia può diventare la foto predefinita associata al profilo utente. Altre azioni possibili consistono nel rinominare la foto oppure nell'impostare la visibilità (pubblica o privata) delle immagini.

Widget

Il centro dell'intero sistema è basato sulle widget, le quali possono essere aggiunte alla piattaforma cliccando sul collegamento “add widgets” situato nella parte superiore destra dello schermo. Questa azione fa comparire una finestra modale contenente una lista di tutte le widget così come una descrizione, un indice di popolarità, un'immagine, ecc. Cliccando sull'icona contrassegnata dal simbolo “+”, come descritto nella finestra, fa sì che la nuova widget venga caricata all'interno del portale senza bisogno di aggiornare l'intera pagina web. Alcune widget offrono poi altre opzioni di configurazioni, tra le altre la possibilità di selezionare il numero di articoli da mostrare. Ci sono diverse tipologie di widget: ●

widget di ricerca: queste servono per cercare informazioni su Google, Wikipedia o altri motori di ricerca. E' possibile limitare la ricerca anche ad un solo tipo di contenuto, come per esempio ai video. E' stata poi sviluppata una widget che esegue una ricerca interna sul database FBK per mostrare i colleghi o cercare all'interno dei wiki FBK.

●

Widget RSS: queste sono usate in combinazione con un collegamento RSS per mostrare informazioni. Poiché al giorno d'oggi quasi tutti i siti internet sono dotati di un feed RSS, la rilevanza di una tale widget appare evidente: è sufficiente cambiare il collegamento RSS (chiaramente ogni utente può inserire quante widget RSS vuole, una per ogni feed differente) per visualizzare i dati più diversi, dalle previsioni del tempo alle ultime notizie di attualità, dal più recente video di YouTube all'ultimo articolo inserito sul blog dell'amico. Sono state sviluppate anche alcune widget RSS già configurate, come quella contenente le ultime conferenze in FBK (ottenute tramite un calendario condiviso in internet) o gli ultimi video di FBK caricati su YouTube.

●

Altre tipologie di widget: di questa categoria generale fanno parte le widget statiche (ad esempio gli ultimi sviluppi di Taolin oppure una lista di collegamenti utili) e le widget di “utilità”, che forniscono cioè un particolare servizio (per esempio la widget 22

Capitolo 3: Taolin note che permette di salvare del testo a piacimento oppure la widget feedback che permette di spedire suggerimenti o segnalazioni di malfunzionamento agli sviluppatori).

Chat

Il widget più popolare in assoluto è sicuramente la chat. Questa widget permette agli utenti di essere in contatto in tempo reale con tutti i colleghi FBK; questo è molto utile per scambiare informazioni tra differenti aree di ricerca, per mantenere saldi i contatti tra diversi gruppi ed in generale per migliorare il lavoro di ognuno attraverso i principi della collaborazione e della disseminazione.

Illustrazione 10: Taolin: visione generale

Architettura del sistema Architettura 2-tier: back end e front end L'applicazione SoNet può essere classificata come un'architettura 2-tier (a due livelli, vedi illustrazione 11), ovvero divisa in: ●

back end: il livello back end è gestito da CakePHP, un framework PHP largamente usato per sviluppare applicazioni per il web;

●

front end: il livello front end consiste di JavaScript, in particolare ExtJS (Extended 23

Capitolo 3: Taolin JavaScript). Quest'ultimo è un framework JavaScript client-side e cross-browser usato per costruire applicazioni internet di nuova generazione. Si è scelto di sviluppare un'applicazione web per vari motivi, quali ad esempio: ●

●

●

facilità di distribuzione e aggiornamento: l'applicazione risiede interamente sul server, quindi la messa in rete di questo costituisce di fatto l'accessibilità e la distribuzione dell'applicazione stessa. Inoltre in caso di aggiornamento del sistema è sufficiente aggiornare solamente il computer server e non ogni singola macchina di ciascun utente. Accesso universale e multipiattaforma: l'accesso alla piattaforma non dipende dal tipo di hardware usato né dal sistema operativo utilizzato dagli utenti; per accedervi è sufficiente usare un qualsiasi browser. Scalabilità e modularità: l'applicazione può essere estesa ed aggiornata, inserendo nuove funzionalità, in modo modulare e scalabile al passo con le esigenze e le richieste degli utenti.

Illustrazione 11: Architettura 2-tier: front end e back end 24

Capitolo 3: Taolin La piattaforma gira su un server interno alla fondazione, in un contesto di Intranet, ed è accessibile tramite protocollo HTTP, inizialmente solo HTTPS, da qualsiasi browser all'interno del luogo del lavoro; all'esterno non è accessibile principalmente per motivi di sicurezza.

Back end: CakePHP

Illustrazione 12: Back end: CakePHP

25

Capitolo 3: Taolin Caratteristiche principali

“CakePHP è un rapido framework di sviluppo PHP che mette a disposizione un'architettura estensibile per sviluppare e mantenere applicativi. Usando design pattern ben conosciuti come MVC e ORM […], CakePHP riduce i costi di sviluppo ed aiuta gli sviluppatori a scrivere meno codice.” [5] CakePHP è basato sul pattern MVC (Model-View-Controller); in un'architettura MVC la comunicazione è triangolare: la View (“vista”) trasmette i dati al Controller (“controllore”), il Controller aggiorna il Model (“modello”), e la View viene aggiornata direttamente dal Model. CakePHP è licenziato sotto licenza MIT. Per estendere un'applicazione CakePHP bisogna creare una view, un model ed un controller. Il model definisce le relazioni tra le nuove tabelle del database e le altre preesistenti; il controller contiene il codice che viene chiamato per restituire dati e la view è usata per far sapere a CakePHP come visualizzare le informazioni. E' sempre necessario creare tutti questi tre file all'interno delle rispettive cartelle; più avanti si potrà trovare una spiegazione pratica nella sezione tutorial.

Alternative

Ci sono molte altre alternative che sono state considerate prima di iniziare a sviluppare l'applicazione, come ambienti di sviluppo Java, rails [6], symfony [7] e zend [8]. Innanzitutto è stata scartata l'idea di usare un ambiente di sviluppo Java a causa della pesantezza e della complessità: Java è sicuramente una delle scelte migliori nello sviluppo di un'applicazione stand-alone, ma nelle applicazioni web è suggerito solamente quando l'applicazione da sviluppare risulta essere molto complessa, per esempio nel caso di siti internet indirizzati a negozi nei quali è necessario avere a che fare con pagamenti tramite carte di credito ed analizzare i privilegi di ogni utente per evitare spiacevoli problemi di sicurezza. Questo non era però il nostro caso. Gli altri framework PHP, come simphony, rails e zend, sono tutti indirizzati all'uso del pattern architetturale MVC. Sono molto simili a CakePHP che è stato scelto anche perché sembrava essere uno dei più usati e ben documentati.

Front end: ExtJS Caratteristiche

“ExtJS è una libreria JavaScript cross-browser per costruire Rich Internet Applications.” [9] ExtJs può essere usato stand-alone oppure assieme ad altre librerie JavaScript come jQuery [10] o Prototype [11].

26

Capitolo 3: Taolin Comparazione con jQuery

JQuery è un framework open source in JavaScript che permette principalmente di applicare in modo intuitivo cambiamenti al DOM di un sito internet attraverso chiamate Ajax e JavaScript, al contrario ExtJS mette a disposizione un grande insieme di componenti per permettere di creare una RIA (Rich Internet Application). JQuery è pertanto una base, un punto di partenza sul quale lo sviluppatore può costruire applicativi più complessi, nonostante abbia molte librerie, chiamate “plugin”, che aggiungono funzionalità.

Illustrazione 13: Front end: ExtJS

27

Capitolo 3: Taolin La scelta tra ExtJS e jQuery è determinata dal tipo di piattaforma che si intende sviluppare: per un'applicazione complessa ExtJS è sicuramente raccomandato poiché mette a disposizione una libreria completa di componenti, simile alle tante disponibili per sviluppare applicazioni desktop. Questo d'altra parte comporta un carico non indifferente in termini di velocità a causa della pesantezza delle librerie. Un ulteriore aspetto negativo di ExtJS è il fatto che un utente che ha disabilitato JavaScript sul suo browser non può visualizzare il sito internet. Al contrario uno dei valori più evidenti di jQuery è proprio la sua leggerezza. Per questa ragione è forse la soluzione migliore qualora lo sviluppatore voglia solamente aggiungere nuove funzionalità ad un sito internet già esistente o voglia creare un sito internet seguendo la strategia del Progessive Enhancement (letteralmente “miglioramento progressivo”): ciò significa usare JavaScript esclusivamente come un mezzo per aggiungere nuove funzionalità per aiutare l'utente, invece di costruire un sito internet su un framework JavaScript, permettendo quindi all'utente che avesse disabilitato JavaScript di vedere ugualmente il sito. E' comunque possibile, aggiungendo i plugin giusti, costruire una Rich Internet Application anche con jQuery, ma tale procedimento risulta essere piuttosto complesso poiché non è per questo che jQuery è stato pensato. Nello sviluppo di Taolin si è scelto di usare ExtJS perché è risultato essere molto usato e suggerito nella creazione di Rich Internet Application. D'altra parte ExtJS, come è stato già spiegato, ha l'effetto negativo, a causa delle sue potenti funzionalità, di essere molto lento in termini di caricamento. Tuttavia questa mancanza può essere facilmente non tenuta in considerazione all'interno di una Intranet, e questo è esattamente il caso che ci si è presentato, mentre in internet questo potrebbe essere un problema da non sottovalutare. Ci sono poi alcuni metodi per limitare quantomeno questo comportamento negativo, per esempio usando lo YUI compressor: questa è un'applicazione sviluppata da Yahoo che analizza il codice JavaScript e CSS, capisce come è strutturato e restituisce il codice migliorato, generato omettendo quanti più possibili caratteri di “spazio” e sostituendo tutti i simboli con un simbolo letterale di lunghezza uno (poi di lunghezza due, tre, ecc.) ogni qual volta questa sostituzione sia possibile. In questo modo il codice generato non contiene caratteri di “a capo”, quindi è tutto in un'unica lunghissima riga, e nel caso di migliaia di righe di codice si può notare un significativo miglioramento in termini di velocità di interpretazione da parte del browser. Infine è bene ricordare che ExtJS è dotato di un'ottima documentazione.

Database e procedure di log Al fine di tenere le informazioni organizzate e strutturate e per interagire facilmente con esse, un database è una scelta obbligata. Si è scelto di usare MySQL per diverse ragioni, principalmente per il fatto che lavora bene con CakePHP ed era sufficiente per le nostre esigenze. Un problema che si è presentato è stato quello poi di mantenere aggiornato il nostro database MySQL con il database MSSQL interno di FBK. Per fare ciò è stato sviluppato uno script in Java che, per mezzo di un crontab (un'applicazione che permette lo scheduling di programmi), si connette periodicamente al database MSSQL ed aggiorna il 28

Capitolo 3: Taolin database MySQL. Nel database vengono salvate anche informazioni relative agli utenti ed alle loro preferenze. Per esempio sono salvate le widget che ogni utente utilizza, la posizione dove sono collocate ed altri parametri. Questo ci permette di pubblicare statistiche interessanti (“Quale è la widget più utilizzata?”, “A chi appartiene il profilo visualizzato più volte?”) e capire veramente le reali necessità che gli utenti hanno. Questa analisi dei dati è particolarmente importante e per questo sono state fatte diverse ricerche teoriche su queste informazioni.

Protocolli di comunicazione REST

REST [12] è l'acronimo di Representational Transfer State ed è un paradigma nello sviluppo di applicazioni web orientato al fatto di permettere manipolazioni di dati attraverso le chiamate POST e GET ed altre chiamate HTTP. In altre parole il sistema REST permette in modo semplice di identificare e descrivere le risorse web, ponendole al centro dell'attenzione. Nella pratica questo significa che è possibile chiamare una funzione attraverso un URL, come vedremo nel prossimo esempio di una risposta JSON.

Comunicazione tra back end e front end: JSON

JSON [13] (JavaScript Object Notation) è un formato largamente usato di scambio dati, molto semplice da leggere e scrivere, sia per le macchine che per gli uomini. JSON è un puro formato di testo e pertanto è particolarmente leggero, rendendolo di fatto quasi il linguaggio per eccellenza nello scambio dei dati. JSON è costruito su due strutture: 1. una collezione di coppie nome-valore. In diversi linguaggi, questo è realizzato tramite un oggetto, un record, una struct, un dizionario, una hash table, una keyed list o un array associativo. 2. Una lista ordinata di valori. Nella maggior parte dei linguaggi, questo è realizzato tramite un array, un vettore, una lista o una sequenza.

JSON e XML

JSON, grazie alle sue particolari caratteristiche sopra specificate, è un formato di scambio dati che punta ad essere “testuale, minimo ed un sottoinsieme di JavaScript.” [14] XML è un linguaggio di markup più complesso usato per descrivere dati strutturati e per serializzare oggetti. Nello sviluppo di Taolin si è scelto di usare JSON principalmente perché era già 29

Capitolo 3: Taolin necessario lavorare con JavaScript (ExtJS); pertanto in questo modo si poteva spedire direttamente il codice JSON al codice JavaScript. Nel caso fosse stato scelto di usare XML invece, sarebbe stato necessario implementare anche un parser.

Esempio di una risposta JSON

JSON è stato usato per esempio per restituire informazioni in un semplice form e successivamente per visualizzarle. Attraverso l'interfaccia REST descritta sopra, implementare una query JSON è molto semplice. Analizziamo la widget “random users” (utenti casuali). Nel controller CakePHP users_controller.php è stata aggiunta la funzione visualizzata nel codice 1 che estrae in modo casuale cinque utenti dal database:

function getrandomusers($n=5) { Configure::write('debug', '0'); $this->layout = 'ajax'; if ($n > 30) $n = 30; $this->User->recursive = 0; $users = $this->User->find('all', array( 'fields' => array('id', 'name', 'surname', 'login'), 'order' => 'RAND()', 'limit' => $n ) ); $users = Set::extract($users, '{n}.User'); $this->set('users', $users); }

Codice 1: users_controller.php In seguito, grazie all'interfaccia REST messa a disposizione da CakePHP, possiamo chiamare questa funzione semplicemente digitando il suo URL: http://taolin.fbk.eu/users/getrandomusers/5/ Il risultato è la pagina HTML in codice 2 la quale è un unica riga di codice JSON.

30

Capitolo 3: Taolin [{"id":"242","name":"Galileo","surname":"Galileo","login":"ggalilei"}, {"id":"456","name":"Giovanni","surname":"Keplero","login":"gkeplero"}, {"id":"329","name":"Niccolò","surname":"Copernico","login":"ncopernico"}, {"id":"577","name":"Isaac","surname":"Newton","login":"inewton"}, {"id":"108","name":"Albert","surname":"Einstein","login":"aeinstein"}]

Codice 2: risposta JSON

Questo codice identifica un array di cinque oggetti, ognuno di essi contenente un ID, un nome, un cognome ed una login. Il codice JSON è spedito alla widget users.js (vedi codice 3) che lo carica all'interno di uno “store” (una particolare struttura usata in JavaScript per memorizzare dati), lo legge e finalmente lo visualizza all'interno di un pezzo di codice HTML nell'applicazione web.

UsersPortlet = function(json){ var store = new Ext.data.JsonStore({ url: json.url+'/5/'+json.showPhoto, root: '', fields: ['id', 'name', 'surname', 'login'] }); store.load(); var resultTpl = new Ext.XTemplate( '<tpl for=".">', '', '' ); // code omitted because of no interest in this example }; Ext.extend(UsersPortlet, Ext.Panel);

Codice 3: users.js widget

Debug tra back end e front end A causa delle caratteristiche originali di un'applicazione web, non è possibile fare debug attraverso unit testing o altri comuni strumenti di programmazione di debug ed in generale risulta molto difficile. E' stato usato pertanto FireBug che è uno strumento molto utile. Più precisamente si tratta di un'estensione di Firefox che permette di controllare il codice JavaScript a runtime e di vedere esattamente cosa fa. E' possibile poi modificare direttamente il codice sorgente, 31

Capitolo 3: Taolin così come il codice HTML e CSS, e vedere i cambiamenti immediatamente senza dover ricaricare l'intera pagina.

Guida alla creazione di una widget per feedback In questa sezione viene spiegato in modo dettagliato e pratico come funziona l'intero sistema, espandendolo con una nuova semplice widget. Verrà aggiunta una widget per feedback, ovvero una widget contenente un'area testuale dove gli utenti possono scrivere i loro commenti ed in seguito spedirli al server. N.B.: Il seguente tutorial fa riferimento alla struttura delle cartelle sviluppata nell'applicazione Taolin, come mostrato in codice 4; l'applicazione si trova all'interno della cartella /cake/desktop, i controller sono in /cake/desktop/controller e similmente le view e i model. All'interno di /cake/desktop/webroot ci sono differenti cartelle per i file CSS, le immagini (come la favicon, il logo, ecc.) e i file JavaScript. Le widget ExtJS (file JavaScript) sono tutte all'interno della cartella /cake/desktop/webroot/ js/portal/widget. Tenetene conto quando sviluppate la vostra applicazione ed avete cartelle differenti.

/cake /desktop /config /controllers feedbacks_controller.php /models feedback.php /vendors /views /feedbacks add.ctp /webroot /css /img /js /portal /widget feedbacks.js

Codice 4: struttura (parziale) delle cartelle di Taolin, con mostrata la locazione per i file della widget feedback di questo tutorial

32

Capitolo 3: Taolin Generalmente le widget sono composte di due parti: ●

back end (server-side), scritto in CakePHP;

●

front end (client-side), scritto in ExtJS.

E' di vitale importanza decidere subito se sono richieste tabelle del database, in tal caso quali e come devono essere relazionate rispetto alle tabelle già esistenti. Se viene specificata la relazione, CakePHP automaticamente fornirà tutti i metodi rilevanti, come vedremo più avanti in questo tutorial. Poi bisogna creare model, view e controller all'interno di CakePHP. Generalmente si crea una view molto semplice per ogni metodo del controller e questa serve a visualizzare i dati restituiti dal metodo del controller associato. Per quanto riguarda il front end, è buona cosa decidere come mostrare le informazioni e di conseguenza quindi quale oggetto ExtJS utilizzare. La widget per feedback che è stata sviluppata ha lo scopo di creare una semplice finestra all'interno della quale l'utente può scrivere le sue idee, commenti o qualsiasi altra cosa voglia. Nei particolari, la widget per feedback è divisa in due parti principali: 1. la barra del titolo, che visualizza il titolo della widget, la relativa icona e, sulla destra, tre icone rispettivamente per ridurre/espandere la widget, visualizzarla a schermo interno o chiuderla; 2. il corpo, il quale contiene un testo per invitare l'utente a scrivere il proprio feedback e la relativa area di testo dove il feedback andrà inserito; sulla parte inferiore è presente un bottone per inviare le informazioni al database. Iniziamo ora con il back end, ovvero il codice necessario a CakePHP per capire cosa fare e restituirci le informazioni di cui abbiamo bisogno.

Back end Aggiunta di una nuova view

Incominciamo creando una nuova view nella cartella /desktop/views/feedbacks/ e chiamiamola add.ctp. L'estensione “ctp” sta per “Cake templates”. Infatti è possibile avere diversi template, non solo codice HTML ma anche PDF, AJAX, ecc. Questa view (vedi codice 5) è usata quando viene chiamato il relativo controller. Quello che fa è restituire semplicemente il contenuto della variabile PHP $response scritto in 33

Capitolo 3: Taolin linguaggio JSON, usando la funzione PHP json_encode.

Codice 5: add.ctp (view di CakePHP della widget per feedback)

Aggiunta di un nuovo model

Bisogna definire in seguito un nuovo model (si veda il codice 6) in CakePHP affinché questo conosca le relazioni tra la widget per feedback e le altre tabelle del database. Per fare questo è sufficiente creare un nuovo file feedback.php in /desktop/models/ Questa è una nuova classe che estende AppModel, la classe di base di CakePHP contenente le funzioni più usate. La chiamiamo “Feedback” ed aggiungiamo la relazione “belongsTo” con il model precedentemente creato “User”, in modo che le tabelle del database del model Feedback e del model User siano tra loro in relazione, permettendoci di eseguire query su di esse. In altre parole, facendo un'operazione di ricerca (find) sul model Feedback, automaticamente il sistema andrà a prendere anche un record collegato al model User, ovviamente soltanto nel caso in cui questo esista.



Codice 6: feedback.php (model CakePHP della widget per feedback)

Aggiunta di un nuovo controller

Infine, aggiungiamo il controller feedbacks_controller.php (vedi codice 7) nella cartella /desktop/controllers/ Il controller contiene il codice PHP che estrae informazioni dal database e 34

Capitolo 3: Taolin successivamente le mostra attraverso la view definita precedentemente. La classe FeedbacksController estenderà la classe AppController di CakePHP, similmente alla classe Feedback nel model che estende AppModel. La funzione beforeFilter è realmente utile perché sarà eseguita prima di ogni azione. E' stata usata in particolare per controllare la sessione, ovvero controllare se un utente è loggato ed in questo modo se ha i privilegi necessari per eseguire determinate azioni, oppure se non lo è. Poi è definita una funzione add che è la funzione principale del widget per feedback. La funzione configure::write è necessaria per impostare la variabile di debug definita all'interno di CakePHP a 0 (zero), cambiando di conseguenza il livello di debug su “produzione”. this->layout = ‘Ajax’ imposta il layout a quello ajax, uno tra quelli già presenti in CakePHP. Questo layout, al contrario di quello predefinito, visualizzerà i dati senza aggiungere alcuna riga di codice HTML. Pertanto l'uso di questo tipo di layout si rende necessario perché il modo di visualizzare i dati sarà deciso nel frontend attraverso ExtJS. Il resto del codice controlla se la casella di testo di nome text contiene dei messaggi, in tal caso li salva insieme all'id di sessione dell'utente sul database, impostando la variabile PHP $response['success'] a true. Altrimenti significa che è accaduto un errore, quindi la variabile PHP $response['success'] è impostata a false e viene aggiunto del testo per informare l'utente del problema. Infine con la seguente riga di codice: $this->set('response', $response); la variabile response viene ad assumere il valore del contenuto della variabile PHP con lo stesso nome. Questa funzione è usata per passare i dati dal controller alla view, dove sarà poi possibile leggerli ed in un secondo momento visualizzarli a video.

35

Capitolo 3: Taolin checkSession();     }     function add() {         Configure::write('debug', '0');             $this->layout = 'ajax';                 if (!empty($this->params['form']['text'])){             $data['text'] = $this->params['form']['text'];             $data['user_id'] = $this->Session->read('id');             $this->Feedback->save($data);             $response['success'] = true;                   }         else {             $response['success'] = false;             $response['errors']['text'] = 'Write a message, please';         }         $this->set('response', $response);     } } ?>

Codice 7: feedbacks_controller.php (controller CakePHP della widget per feedback)

Front end Fino a questo momento abbiamo esteso l'applicazione di CakePHP aggiungendo un nuovo model, controller e view che ci danno come risultato uno stream di dati. Poiché non vogliamo semplicemente scrivere dati come codice HTML ma fare una widget ExtJS, è necessario creare un nuovo file JavaScript che mostri una finestra ExtJS contenente i dati ricavati precedentemente. Innanzitutto creiamo un nuovo file Javascript feedback.js (vedi codice 8) all'interno della cartella: webroot/js/portal/widget Definiamo poi una nuova funzione, chiamata Feedback, che definisce la widget. E' necessario quindi estendere il Feedback con Ext.Panel per ereditare le funzionalità della superclasse. All'interno della funzione Feedback definiamo un nuovo Ext.form.FormPanel che rappresenta un tipo di pannello particolare di ExtJS. Impostiamo feedback_widget come baseCls; ciò significa che feedback_widget sarà la classe CSS applicata a questo elemento del pannello. Impostiamo alcune proprietà come altezza, stile del corpo 36

Capitolo 3: Taolin ed allineamento dei vari pulsanti. Aggiungiamo quindi alcuni oggetti al pannello, quali ad esempio una label (letteralmente “etichetta”), ovvero un semplice testo statico visualizzato all'interno della widget, ed un'area di testo per permettere all'utente di scrivere i propri commenti. Infine aggiungiamo il pulsante di invio, il quale ha associata una funzione che viene chiamata ogniqualvolta il pulsante è premuto, spedendo i dati ad un'altra pagina; se l'azione è stata eseguita correttamente, mostriamo un messaggio per informare l'utente del successo dell'invio. Lo scope di questa funzione è l'oggetto pulsante. Vincoliamo quindi il pulsante al form per far sì che questo sia attivo solamente nel caso in cui il form abbia passato con successo la validazione. E' interessante notare che quando l'applicazione parte, carica dal database in modo automatico le widget che sono attive per l'utente corrente, e dispone ognuna di esse in una portlet, una semplice finestra contenente dati. Il titolo delle portlet è ottenuto anch'esso dal database, così come la posizione nella pagina di ogni portlet.

37

Capitolo 3: Taolin Feedback = function(){ this.form = new Ext.form.FormPanel({ baseCls: 'feedback_widget' ,autoHeight: true ,bodyStyle:'padding:10px' ,buttonAlign: 'center' ,items: [ { xtype: 'label', cls: 'feedback_label', text: "Your suggestions and feedback are very important for us!                    Please, write here below any kind of suggestion (in Italian or English, as you prefer),                    even quick one word suggestions are perfect! Thank you!" ,anchor: '0 30%' },{ xtype: 'textarea', hideLabel: true, cls: 'feedback_text', grow: true, name: 'text' ,anchor: '0 50%' // anchor width by percentage and height by raw adjustment }], buttons: [{ text: 'Submit', handler: function(){ this.form.getForm().submit( { url:'feedbacks/add', waitMsg:'Saving Data...', success: function(form,action){ Ext.example.msg('Sent, thanks for your message!', form.getValues().text); form.reset();} } ); }, scope: this, formBind: true } ] }); Feedback.superclass.constructor.call(this, { autoHeight: true, autoWidth: true, defaults: { autoScroll: true }, items: this.form ,layout: 'fit' }); }; Ext.extend(Feedback, Ext.Panel);

Codice 8: feedback.js (codice ExtJS della widget per feedback) 38

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Capitolo 4: Modifiche all'applicazione e rilascio in open source In questo capitolo vengono presentate le modifiche apportate all'applicazione, finalizzate ad una generalizzazione ed astrazione del codice per rendere l'applicazione usufruibile su qualsiasi rete, quindi vengono analizzate alcune licenze open source ed infine discusse le decisioni prese riguardo alla licenza sotto cui rilasciare l'applicazione Taolin.

Contributo personale allo sviluppo dell'applicazione Ho iniziato a lavorare al progetto SoNet come stagista fin dalla sua creazione, nel mese di marzo 2008, assieme ai ricercatori Maurizio Napolitano e Paolo Massa. Ho partecipato attivamente a tutte le riunioni e contribuito personalmente alle scelte prese. In seguito si sono aggiunti altri due sviluppatori al gruppo SoNet ed il mio lavoro si è concentrato sull'obiettivo di rilasciare la piattaforma in open source. Per fare ciò, è stata essenziale un'attenta rilettura e comprensione di tutto il codice, per capire quanto era stato fatto anche da altri ed intervenire ove necessario. Nel frattempo, mentre io provvedevo ad effettuare le modifiche al codice per “generalizzarlo” ed eliminare le parti strettamente correlate alla fondazione, lo sviluppo continuava. Poi usando SVN e creando un nuovo branch dal trunk dell'applicazione, ho avuto l'incarico di creare un file di configurazione in CakePHP dove poter definire vari parametri, dal titolo della pagina alla scelta del metodo di autenticazione (LDAP, MySQL o un un'utenza demo) e di separare tutti gli elementi correlati alla fondazione Bruno Kessler (quali ad esempio le immagini del personale FBK o il codice relativo all'interfacciamento con il database LDAP) dal codice originale. Dopo aver fatto questo ho provveduto a fare un merge del branch nel trunk, che nel frattempo era stato modificato e si era evoluto in modo significativo. E' stata anche creata una versione dimostrativa (demo) con un database popolato da personaggi antichi per permettere all'utente di entrare immediatamente nel sistema ed avere un'idea delle funzionalità e caratteristiche che offre. Come ultima cosa ho scritto una breve guida all'installazione dell'applicazione, in modo che chiunque la scarichi possa riuscire ad utilizzarla seguendo alcuni passi. Infine ho analizzato le licenze di tutti i componenti utilizzati e, dopo uno studio approfondito su varie licenze e relativi vantaggi e/o svantaggi di ognuna, di comune accordo ho rilasciato l'intero codice sotto licenza GNU Affero General Public License (AGPL) secondo le modalità definite dalla Free Software Foundation (FSF). Nel seguito di questo capitolo verranno trattate due parti: la prima relativa ad alcune delle modifiche introdotte, in particolare quelle riguardo all'aggiunta di un file di configurazione e la possibilità di autenticazione con metodi diversi; la seconda relativa invece all'analisi delle licenze, alle operazioni effettuate per rilasciare il codice sotto una licenza open source ed infine alle decisioni finali in merito alla scelta di tale licenza.

39

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Strumenti utilizzati Nello sviluppo del progetto sono stati usati solamente strumenti open source. Nello specifico è stato usato come sistema operativo Linux e come editor per la programmazione sostanzialmente Vim. Per organizzare il lavoro e dividersi i compiti si è adottato il sistema Trac [15] abbinato al sistema di controllo versione Subversion [16].

Subversion Subversion [16] (SVN) è uno dei più diffusi sistemi di controllo versione, ovvero un sistema per gestire in modo efficiente la continua evoluzione del codice sorgente del software. Le modifiche ai file vengono identificate con un numero univoco che è incrementato ogni volta e prende il nome di “numero di versione”, oltre al nome della persona che ha apportato tali modifiche. Il codice è depositato su un “repository”, ovvero una cartella remota su un server; in questo modo è possibile scaricare i sorgenti del programma, per chi gode dei diritti necessari a tale operazione, su qualsiasi computer connesso al server tramite un'azione chiamata “check-out”, la quale effettua una copia locale del lavoro salvato sul repository. Ogni volta che le modifiche effettuate sui file locali vengono spedite al server, si effettua un “commit”. Un “changeset” identifica infine un insieme di modifiche effettuate con un unico commit. Per quanto riguarda lo sviluppo di Taolin, come si può vedere nell'immagine 14, ho effettuato un branch (“ramo”), ovvero una copia del codice sorgente, al changeset 1166 all'inizio del mese di dicembre 2009. Mentre lavoravo sul branch creato, di nome “demo”, lo sviluppo sul trunk, cioè il ramo principale, continuava ad opera di altri sviluppatori. Dopo circa tre mesi ho ricongiunto il branch nel ramo principale, al changeset 1566. Tale operazione si è rivelata abbastanza complicata in quanto, nei tre mesi di sviluppo del trunk, erano state apportate numerose modifiche che hanno dato luogo a parecchi conflitti. E' stato quindi necessario risolvere questi conflitti uno alla volta per inserire le modifiche da me effettuate sul branch demo nel trunk e rendere il tutto nuovamente funzionante.

Illustrazione 14: SVN: creazione di un branch dal trunk al changeset 1166 e successivo merge nel trunk al changeset 1566 40

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Generalizzazione del codice Un grande sforzo è stato fatto per rendere il codice dell'applicazione indipendente e quindi usabile su qualsiasi computer e più in generale rete, non soltanto all'interno della Fondazione Bruno Kessler. Per fare questo è stata necessaria un'attenta rilettura e comprensione dell'architettura dell'applicazione (back end e front end) e soprattutto del codice, scritto da persone diverse in momenti diversi e quasi interamente sprovvisto di commenti. Nello specifico una gran parte del lavoro ha avuto a che fare con il distacco dal database Ldap usato all'interno di FBK e con la creazione e gestione dinamica di vari metodi di autenticazione, come sarà mostrato dettagliatamente in seguito. Inoltre, essendomi imbattuto numerose volte nella sostituzione degli stessi pezzi di codice in parti diverse o in file diversi (per esempio sostituire ogni volta il nome della cartella “fbkimages” con “userimages”), ho pensato di creare un file di configurazione con vari parametri, come descritto nel prossimo paragrafo, per rendere tale processo completamente personalizzabile ed automatico.

Aggiunta di un file di configurazione in CakePHP Per rendere configurabile l'applicazione, anche in vista del rilascio esterno, si è pensato di aggiungere un file di configurazione contenente alcune variabili modificabili a piacimento. Per caricare il file è stato aggiunto al file bootstrap.php situato nella cartella config le seguenti righe (la prima è un commento): // load the file config.php located in /app/config/ Configure::load('config'); Il file bootstrap.php è chiamato automaticamente da CakePHP all'avvio dell'applicazione, e tramite questa chiamata carica, cioè importa, il file config.php situato anch'esso nella cartella config. Il file config.php è il seguente: ' DESKTOP.FBK.EU ', 'App.addtomail' => '@yoursite.com', 'App.defaultgroupname' => 'Group', 'App.imagefoldername' => 'user_images/', 'App.publications' => '1', 'App.auth' => 'Dummy', ); ?>

Codice 9: Il file di configurazione config.php 41

Capitolo 4: Modifiche all'applicazione e rilascio in open source Come si può vedere, il file contiene un array, anch'esso di nome config, a cui sono associati diversi valori per indici differenti. La parola “App” sta ad indicare “Application”, cioè “applicazione”, per distinguere questi campi da altri, eventualmente implementabili in futuro, che andassero a modificare strutture differenti (per esempio parametri di debug o altre configurazioni). Nel dettaglio, App.name indica il titolo che comparirà nella pagina HTML dell'applicazione, ovvero il testo all'interno dei tag <TITLE> e . App.addtomail indica il codice da appendere ai nomi utenti, qualora questi non abbiamo associata una mail nel database. Per esempio, definendo App.addtomail a “@test.com”. se l'utente MarioRossi non avesse una mail nel relativo campo del database, quando nell'applicazione viene mostrata l'e-mail questa avrà valore “[email protected]”. App.defaultgroupname indica l'etichetta associata al gruppo di ogni utente, mostrata nella sidebar dell'applicazione. All'interno di FBK per esempio questo campo è stato associato al valore “FBK GROUP”, mentre un utente normale vorrebbe probabilmente usare il testo “Group”. App.imagefoldername indica il nome della cartella contenente le immagini relative agli utenti. Queste immagini comprendono le foto del profilo e tutte le altre immagini caricate da ogni utente. App.publications è un tipo di campo booleano, quindi assume il valore 1 per indicare vero, 0 per falso. All'interno di FBK si è usato il valore 1 per connettersi al database interno delle pubblicazioni dei ricercatori, mentre un utente che non volesse usare questa opzione potrebbe disabilitarla impostandone il valore a 0. App.auth infine indica il metodo di autenticazione, modificabile a scelta tra quelli che vedremo nel prossimo paragrafo. Per esempio impostando Ldap come valore, si userà la classe relativa al collegamento ad un database di tipo LDAP.

Creazione delle classi relative a vari metodi di autenticazione Per gestire i vari metodi di autenticazione, configurabili come appena visto tramite App.auth definita nel file config.php, ho implementato dei components di CakePHP. Questi sono dei pezzi di codice che vengono riutilizzati dai vari controller. Usando i components quindi viene mantenuta la modularità dell'applicazione, uno dei principi base della programmazione ad oggetti, in quanto non viene copiato lo stesso codice più volte in differenti controllers, ma viene creato in un file a parte, un component appunto, e caricato dai diversi controllers. Pertanto utilizzare i components mantiene il codice dei vari controller pulito e permette di riutilizzare codice in file e progetti diversi. CakePHP contiene già alcuni components predefiniti, quali ad esempio quelli relativi alla sicurezza, al controllo della sessione e dei cookies. Noi invece creeremo alcuni nuovi components nella cartella controllers/components/auth/. In realtà sarebbe sufficiente metterli nelle cartella controllers/components/, ma per logica, riferendosi tutti al metodo di autenticazione, è scelto scelto di inserirli in un'ulteriore sottocartella di nome auth. 42

Capitolo 4: Modifiche all'applicazione e rilascio in open source Il template dei nuovi components è il seguente:

Codice 10: Template per l'aggiunta di un nuovo component per l'autenticazione

Come si può notare non è altro che una nuova classe PHP il cui nome deve terminare per “Component” e deve estendere Object. Le funzioni che devono essere implementate sono tre. La prima, connecttoserver(), prende in input due variabili, nome utente e password, controlla che corrispondano ai valori da verificare e restituisce TRUE se l'autenticazione è avvenuta, FALSE altrimenti. La seconda, getuserdn(), restituisce alcune informazioni relative all'utente prese dal database. La terza, getusergroups(), restituisce alcune informazioni relative al gruppo dell'utente ricavate dal database. Come esempio si veda il codice 11 in cui viene presentata la classe Dummyauth.php, una classe di autenticazione implementata come test per verificare il corretto funzionamento dell'applicazione. Come si può notare è stata implementata unicamente la funzione connecttoserver che banalmente controlla se il nome utente e la password passati come parametri corrispondono a quelli definiti all'interno della classe, vale a dire “admin” “admin”. Se sono uguali, viene restituito TRUE, altrimenti FALSE.

43

Capitolo 4: Modifiche all'applicazione e rilascio in open source defaultuser && $password == $this->defaultpass) return true; else return false; } public function getuserdn() { } public function getusergroups() { } } ?>

Codice 11: La classe di autenticazione Dummyauth.php

44

Capitolo 4: Modifiche all'applicazione e rilascio in open source
$ldaphost = "test"; $ldapport = 999; $myuser = ""; $dn = "OU=USERS,DC=pc,DC=FBK,DC=com"; $addtologin = "FBK\\";

public function connecttoserver($myuser, $password) { $this->myuser = $myuser; $ldapconn = ldap_connect($this->ldaphost, $this->ldapport); $login = $this->addtologin.$myuser; $bd = ldap_bind($ldapconn, $login, $password); return $bd; } public function getuserdn() { $ldapconn = ldap_connect($this->ldaphost, $this->ldapport); $result = ldap_search($ldapconn, $this->dn, '(&(objectClass=person) (uid='.$this->myuser.'))', array('distinguishedName')); $entries = ldap_get_entries($ldapconn, $result); $member_dn = $entries[0]['distinguishedname'][0]; return $member_dn; } public function getusergroups() { $ldapconn = ldap_connect($this->ldaphost, $this->ldapport); $result = ldap_search($ldapconn, $dn, '(objectClass=group)', array('member', 'cn')); $entries = ldap_get_entries($ldapconn, $result); $session_groups = array(); for ($i=0; $i < $entries["count"]; $i++) { $group = $entries[$i]; if ($group['member']) { for ($j=0; $j < $group['member']['count']; $j++) { $member = $group['member'][$j]; if ($member == $member_dn) { $session_group['name'] = $group['cn'][0]; $session_groups[] = $session_group; } } } } return $session_groups; } } ?>

Codice 12: La classe di autenticazione Ldapauth.php Sono state implementate poi altre classi, in particolare quella relativa alla connessione tramite database LDAP (si veda il codice 12) e si è pensato in seguito di sviluppare altri metodi relativi ad autenticazione tramite database MySQL, PostgreSQL o tramite OpenID. 45

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Modifiche al controller in CakePHP per gestire dinamicamente il metodo di autenticazione Una volta ultimato il component, per usarlo in qualche controller dell'applicazione è sufficiente inserire il nome del component, senza la parte finale “Component”, nell'array $components definito nel controller. In questo modo nel controller verrà automaticamente creato un nuovo attributo con lo stesso nome del component, a cui sarà possibile accedere tramite una sua istanza. Per esempio con il seguente codice: var $components = array('Dummyauth', 'Session'); sarà possibile accedere ai due components Dummyauth e Session tramite $this->Dummyauth e $this->Session. Tuttavia nel caso di Taolin, il metodo di autenticazione deve essere gestito dinamicamente, ovvero deve essere caricato solamente il component che viene definito nel file di configurazione. Per fare ciò, si faccia riferimento al codice 13 che mostra un controller in cui è stata implementata questa funzionalità, sono stati dichiarati un array di nome $components che legge il component scelto dal file di configurazione ed una variabile $mycomponent con cui si accederà poi al component specificato. Quindi nel costruttore, che come ricordiamo viene chiamato per prima cosa, salviamo nella prima posizione dell'array $components il nome del component scelto nel file di configurazione, leggendolo tramite la funzione Configure::read che prende in input il parametro relativo all'array $config (in questo caso “App.auth” perché appunto stiamo leggendo il metodo di autenticazione) ed aggiungiamo poi il testo “auth” affinché il nome sia quello del component (per esempio nel file di configurazione si può scegliere l'autenticazione “Ldap” mentre il nome del component è “Ldapauth”). A questo punto tramite la funzione App::import che prende in input il tipo di oggetto da importare (un component) ed il relativo nome (che abbiamo appena ricavato) importiamo il component all'interno del controller. Quindi inizializziamo la variabile inizialmente definita $mycomponent associandola ad una nuova instanza del component scelto. Infine richiamiamo il costruttore della sovraclasse; è necessario richiamarlo perché altrimenti eseguiamo un override e quindi non verrebbe più chiamato il costruttore originale, ma soltanto il nuovo riscritto in questa sottoclasse. Una volta fatto questo, definiamo all'interno del controller le tre funzioni relative al component, che come abbiamo visto precedentemente sono doconnection(), getuserdn() e getusergroups(). Ognuna di queste funzioni richiamerà la funzione con lo stesso nome associata al component scelto, tramite la seguente sintassi, per esempio:

46

Capitolo 4: Modifiche all'applicazione e rilascio in open source

function doconnection($myuser, $password) { return $this->mycomponent->connecttoserver($myuser, $password); } All'interno del codice quindi, per verificare se la connessione è avvenuta con successo, basterà usare la seguente riga: $conn = $this->doconnection($myuser, $password); che richiama la funzione doconnection() definita sopra.

class AccountsController extends AppController { var var var var var

$name = 'Accounts'; $helpers = array('Html','Form','Javascript'); $uses = array('User','Widget'); $components = array(); $mycomponent;

function __construct() { $this->components['0'] = Configure::read('App.auth').'auth'; $name = $this->components['0']; App::import('Component', $name); $cn = $name . 'Component'; $this->mycomponent = new $cn(); parent::__construct(); } […] function doconnection($myuser, $password) { return $this->mycomponent->connecttoserver($myuser, $password); } function getuserdn() { return $this->mycomponent->getuserdn(); } function getusergroups(){ return = $this->mycomponent->getusergroups(); } […]

Codice 13: Parte della classe accounts_controller.php dopo le modifiche per gestire dinamicamente il metodo di autenticazione

47

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Versione demo Sempre con l'intenzione di rendere l'applicazione open source ed i sorgenti disponibili per il download, si è pensato di creare una versione dimostrativa (demo) per permettere agli utenti interessati di provare subito la piattaforma anche in locale, sul proprio computer. Per fare questo ho creato la classe di autenticazione Dummyauth.php (si veda il codice 11) per far sì che sia possibile entrare nell'applicazione con un'utenza precedentemente stabilita. Inoltre è stato creato un database apposito chiamato “demo” per l'appunto contenente, invece che gli utenti della fondazione, i nomi di alcuni personaggi famosi antichi divisi in due gruppi: antica Grecia ed antica Roma. Per esempio è possibile “trovare” Lucio Anneo Seneca, Marco Tullio Cicerone e Tito Lucrezio per quanto riguarda i romani; Aristotele, Platone e Socrate per quanto concerne invece i greci. Ogni utente è correlato di immagine personale (vale a dire una rappresentazione tratta da dipinti o sculture) e dati anagrafici, per quanto possibile. In questo modo quando l'utente accede per la prima volta all'applicazione in versione demo non trova una comunità vuota, bensì popolata da numerosi personaggi antichi con i quali può interagire e farsi un'idea immediata delle caratteristiche e funzionalità che offre il portale sviluppato.

Guida all'installazione dell'applicazione Per guidare l'utente nell'installazione della versione demo di Taolin ho redatto una guida con i comandi necessari. Per motivi di spazio è mostrato soltanto l'indice di tale guida nel codice 14.

************************** INSTALLATION INSTRUCTIONS ************************** *************** I N D E X *************** 1. Requirements 2. Installation 2.1 Installing Apache and PHP5 2.2 Installing MySQL 2.3 Installing CakePHP 2.4 Installing Taolin 2.5 Installing Taolin database 2.6 Configuring Taolin 2.7 Access to Taolin [...]

Codice 14: L'indice del file INSTALL.txt contenente le istruzioni per l'istallazione dell'applicazione

48

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Analisi delle licenze Licenze software Una licenza software è un contratto relativo ad un software che specifica le modalità di utilizzo di tale prodotto, garantendo dei diritti ed imponendo certi obblighi all'utente finale. La licenza viene imposta dall'autore del prodotto software, vale a dire da chi detiene il copyright su di esso. In un certo senso quindi una licenza software può essere vista come una "promessa" da parte dell'autore di non fare causa all'utente finale riguardo alla possibilità di usare una o più copie del prodotto in certi modi che normalmente costituirebbero una violazione stessa del copyright. Vi sono sostanzialmente due tipi di licenze software che si contraddistinguono per i diritti che concedono all'utente finale: le licenze proprietarie e le licenze open source.

Licenze proprietarie

Le licenze proprietarie permettono all'utente di usare una o più copie del software, ma la proprietà di tali copie rimane al produttore (da qui il termine "proprietarie"). Questo fa sì che tutti i diritti che riguardano il software rimangano nelle mani del produttore, il quale concede all'utente solamente alcuni diritti ben definiti; molto spesso accade che il proprietario del software includa molte proibizioni nell'uso del prodotto stesso, addirittura proibendo azioni che sarebbero perfettamente legali secondo il copyright. Un'altra importante conseguenza del fatto che la proprietà del software rimane al produttore è il fatto che l'utente è costretto ad accettare la licenza per poter utilizzare il software. Per esempio la licenza di Microsoft Windows impone numerose restrizioni come la possibilità di fare "reverse engineering", l'uso contemporaneo del software da persone diverse e la pubblicazione di test di performance.

Licenze open source

Le licenze open source, contrariamente a quelle proprietarie, attestano che la proprietà di una particolare copia del software non rimanga al produttore, bensì venga trasferita all'utente finale. In questo modo l'utente detiene tutti i diritti che sono concessi dalla legge sul copyright a chi detiene una copia. E' importante notare che il diritto trasferito è soltanto quello sulla proprietà di una particolare copia (quella detenuta appunto dall'utente), non il copyright che invece rimane al proprietario. Inoltre le licenze open source tipicamente permettono altri diritti che normalmente sarebbero riservati al produttore di software. La licenza open source pertanto non obbliga l'utente ad accettarla per poter usare il software, ma lo "invita" a farlo garantendogli dei diritti addizionali (uno tra tutti la possibilità di ridistribuire il software) che altrimenti non potrebbe esercitare. Una delle licenze open source più conosciute è la GPL (GNU General Public License). 49

Capitolo 4: Modifiche all'applicazione e rilascio in open source Il suo principio base è che nessuno dovrebbe essere limitato dal software che usa. Le libertà che ogni utente dovrebbe avere sono: ●

libertà di usare il software per qualsiasi scopo;

●

libertà di cambiare il software secondo le proprie esigenze;

●

libertà di condividere il software con i tuoi amici e vicini;

●

libertà di condividere le modifiche apportate al software.

Un programma che tuteli queste libertà è definito software libero. Un software è open source se rispetta i seguenti criteri: 1. ridistribuzione libera: la licenza non deve vietare ad alcuno la vendita o la cessione del software; ognuno ha il diritto di fare tutte le copie che desidera, venderle o cederle, senza pagare nulla ad altri per poterlo fare. 2. Codice sorgente: il codice sorgente, necessario per apportare modifiche al programma, deve essere incluso. 3. Opere derivate: la licenza deve dare la possibilità di effettuare modifiche ed opere derivate, consentendo la loro distribuzione con la stessa licenza del programma originale. 4. Integrità del codice sorgente dell'autore: la licenza può vietare modifiche al codice sorgente soltanto se la licenza ammette la possibilità di creare delle patch (con il codice sorgente incluso) al fine di aggiornare e migliorare il programma. 5. Nessuna discriminazione contro persone o gruppi: la licenza non deve discriminare nessuno in alcun modo, nemmeno terroristi o criminali. 6. Nessuna discriminazione di settori: la licenza non può essere negata ad alcun settore, per quanto deplorevole possa essere, per esempio sviluppo di armi di distruzione di massa. 7. Distribuzione della licenza: la licenza si applica in modo automatico a tutti coloro cui viene distribuito il programma. 8. La licenza non dev'essere specifica di un prodotto: i diritti di un programma non devono dipendere dal fatto che questo sia parte di una particolare distribuzione di software. 9. La licenza non deve contaminare altro software: la licenza non può porre limiti ad altro software distribuito insieme a quello licenziato. 10. La licenza deve essere tecnologicamente neutra: nessuna clausola della licenza deve fare riferimento ad una singola tecnologia o stile di interfaccia. I vantaggi che derivano dall'utilizzo di licenze open source, a detta dei sostenitori delle stesse, sono sostanzialmente tre: 1. innovazione: è stato ampiamente dimostrato che i programmatori desiderano contribuire a progetti open source senza alcuna ricompensa, se non la soddisfazione di migliorare un programma. Più programmatori possono contribuire, 50

Capitolo 4: Modifiche all'applicazione e rilascio in open source più alto sarà probabilmente il valore del software prodotto. 2. Affidabilità: nel caso un utente riscontri un bug in un programma, la comunità di sviluppatori generalmente è più interessata a correggerlo che non un impiegato al servizio di un'azienda, che magari ha priorità diverse. 3. Longevità: i programmi open source anche se cadono in disuso, possono essere sempre riscoperti, adattati e tornare in vita, magari con un utilizzo completamente diverso dall'originale. Al contrario un software proprietario difficilmente sarà aggiornato od adattato una volta che non è più supportato dal suo autore.

Licenze open source e applicazioni web Il problema dell'ASP loophole

Il problema dello “ASP loophole” (dove ASP indica Application Service Provider, ovvero un'azienda di software che fornisce servizi web a clienti tramite una rete) è piuttosto recente e si è venuto a creare con la diffusione e l'inaspettato successo di applicazioni web che sono venute via via a sostituire molte concorrenti installabili sul disco fisso e non utilizzabili via web. Il problema sta nel fatto che al momento in cui sono nate le più famose licenze open source (si pensi per esempio alla GNU GPL), non si è tenuto conto, proprio perché tale questione ancora non era venuta alla luce, della diffusione via web di un software. Se uno sviluppatore modifica del codice licenziato sotto GPL, chiaramente dovrà poi distribuire i sorgenti modificati quando distribuirà il software; ma – e qui sta il problema dello ASP loophole – se lo sviluppatore è una Application Service Provider (ASP), cioè qualcuno che fornisce un servizio via web usando software libero (per esempio licenziato sotto GNU GPL), in tal caso non sta distribuendo il software e quindi non è tenuto a distribuire anche le modifiche al codice sorgente usato. Il nocciolo della questione è quindi nel termine “distribuire” che non comprende la diffusione di un servizio tramite web. Questo fatto ha provocato forti reazioni nel movimento del software libero, il quale fa notare che aziende molte grandi (si pensi a Google per esempio) fanno larghissimo uso di software open source, ma senza essere tenute a distribuire alla comunità le modifiche effettuate, e questo va contro i principi dell'open source. D'altra parte tali compagnie rivendicano il fatto che non sono obbligate a rilasciare le modifiche ai sorgenti perché non stanno ridistribuendo il codice per uso commerciale ma semplicemente forniscono un servizio ai loro utenti. Per risolvere la questione è stata creata la licenza Affero GPL (AGPL) che corregge questo “buco” introducendo una nuova clausola alla licenza GNU GPLv2. Con la AGPL, se un ASP usa software libero per fornire servizi o altro, deve rendere pubblicamente disponibile il codice sorgente tramite rete (HTTP) a chiunque. In questo modo il principio della redistribuzione delle modifiche alla base delle licenze open source rimane valido, in quanto il codice rimane aperto sia se usato in locale sia se usato all'interno di una rete. 51

Capitolo 4: Modifiche all'applicazione e rilascio in open source La AGPL non è ancora però particolarmente diffusa, anche perché la sua introduzione è piuttosto recente, infatti risale al 19 novembre 2007. Ciononostante è stata adottata da alcune grandi aziende, seppur in numero molto esiguo. Google, sul suo sito dedicato a progetti open source, non permette di caricare codice licenziato sotto AGPL. Vi sono state molte lamentele da parte di numerosi utenti che sostenevano l'introduzione di tale licenza sia perché intendevano usarla per i loro progetti, sia perché ritenevano fosse una buona idea. Google ha replicato [17] sostenendo di essere fortemente preoccupata riguardo al problema della proliferazione delle licenze aperte, che viene infatti giudicato dalla stessa comunità open source un problema piuttosto serio in grado di confondere gli utenti ed ostacolare la condivisione ed il riutilizzo del codice, specialmente nel caso in cui uno sviluppatore cerchi di mettere insieme diverse componenti ognuna con licenza differente. In tal caso infatti diventa veramente complesso capire ed essere a conoscenza dei diritti legali del prodotto finale e in particolar modo se è possibile rilasciare il software e sotto quale licenza (ricordiamo infatti che non tutte le licenze open source sono compatibili tra loro). Pertanto inizialmente ha permesso soltanto sette licenze per i progetti caricati su Google Code, aggiungendo poi l'ottava (la nuova GPLv3). La strategia aziendale è sempre stata quella quindi di limitare al massimo il numero di licenze possibili ed introdurne di nuove solamente dopo che siano state approvate dall'OSI e che risulti evidente che siano usate a livello popolare. Per ovviare alla mancanza della licenza AGPL su Google Code, vi è stato chi ha scelto pubblicamente una licenza tra le otto disponibili, salvo poi inserire nel codice sorgente la vera licenza AGPL: questo comportamento non ha fatto altro che aumentare la confusione sui diritti legali in possesso dell'utente ed è stato quindi sanzionato dall'azienda con l'allontanamento dal servizio. La questione che si è venuta a creare è pertanto la seguente: Google rifiuta la licenza AGPL perché davvero vuole limitare la proliferazione delle licenze open source, oppure perché – come obiettato da alcuni sostenitori della AGPL – tale licenza potrebbe risultare molto fastidiosa e dannosa da un punto di vista economico, e non solo, per i servizi che offre via web? Da un lato è comprensibile e degno di apprezzamento il voler limitare il numero di licenze disponibili, d'altra parte non si capisce perché escludere la AGPL che è molto simile alla GPLv3 con l'unica differenza chiave che riguarda la diffusione via rete; inoltre è stata redatta in modo da essere compatibile con le altre licenze, quindi non è proprio una licenza completamente diversa dalle altre. Pertanto vi sono molti dubbi, o perlomeno sospetti, sul perché Google non accetti questa licenza. Infatti è bene ricordare che Google utilizza moltissimo software open source, cercando di non usare alcun software commerciale ove possibile. Quindi se la AGPL dovesse diventare popolare dovrebbero pubblicare sotto AGPL tutte le modifiche fatte al codice dei servizi che offre via web, e questo non sarebbe certamente gradito all'azienda. E' tuttavia bene ricordare che Google è anche uno dei maggiori sostenitori della comunità open source, sebbene in linea con i propri interessi. La risposta a questa questione rimane per ora in sospeso, ma potrà essere facilmente svelata qualora la licenza AGPL guadagni una larga diffusione e venga usata in numerosi 52

Capitolo 4: Modifiche all'applicazione e rilascio in open source progetti (quali i moltissimi progetti disponibili su SourceForge e RubyForge): a questo punto si scopriranno le vere intenzioni di Google.

Il caso di Facebook e la licenza Common Public Attribution License (CPAL)

Facebook ha rilasciato recentemente una parte del suo codice sotto licenza open source. Tale piattaforma è denominata Facebook Open Platform ed è “un'istantanea dell'infrastruttura che gira sulla piattaforma Facebook. Include l'infrastruttura API, il parser FBML, il parser FQL e FBJS così come l'implementazione di molti metodi comuni ed etichette.” [18] La licenza scelta da questa azienda è stata la Common Public Attribution License (CPAL): questa è stata inizialmente sviluppata dall'azienda di social enterprise wiki Socialtext ed è stata approvata in data 25 luglio 2007 dall'Open Source Initiative (OSI). Da allora non ha avuto particolare successo, nonostante sia stata adottata da alcune aziende piuttosto importanti. E' basata sulla Mozilla Public License (MPL), usata da Firefox ed altre famose compagnie di software, a cui sono state aggiunte due sostanziali modifiche. In primo luogo la licenza CPAL include un requisito di attribuzione, ovvero il software che viene licenziato sotto CPAL può mostrare informazioni riguardo allo sviluppatore originale. Questo messaggio di informazioni specifica che “[...] ogni volta che un Eseguibile e Codice Sorgente oppure un'Opera Più Grande è lanciata o eseguita, deve comparire un messaggio di rilievo dell'Avviso di Attribuzione dello Sviluppatore Originale (come definito in seguito) sull'interfaccia grafica (che può includere un messaggio su uno splash screen) [...]“. [19] Nel caso specifico di Facebook, la licenza CPAL obbliga ad esporre il seguente messaggio: Attribution Copyright Notice: Copyright © 2006-2008 Facebook, Inc. Attribution Phrase (not exceeding 10 words): Based on Facebook Open Platform Attribution URL: http://developers.facebook.com/fbopen Graphic Image as provided in the Covered Code: http://developers.facebook.com/fbopen/image/logo.png Nonostante questo possa sembrare ragionevole per riconoscere il lavoro svolto dagli sviluppatori di Facebook, non si può fare a meno di notare che è anche una clausola molto forte che serve a prevenire altri dal clonare semplicemente Facebook sui loro siti, o quantomeno coloro che non hanno alcuna intenzione di fare pubblicità gratuita a Facebook, magari proprio perché loro rivali. In secondo luogo, l'ulteriore differenza tra la licenza MPL e la licenza CPAL è nella sezione “15. ADDITIONAL TERM: NETWORK USE.” [19], che serve a tutelarsi dal famoso ASP loophole. Tale clausola recita: 53

Capitolo 4: Modifiche all'applicazione e rilascio in open source “Il termine “Sviluppo Esterno” indica l'uso, la distribuzione o la comunicazione del Codice Originale o delle Modifiche in ogni modo tale che il Codice Originale o le Modifiche possano essere usate da chiunque all'infuori di Te, nel caso in cui queste opere siano distribuite o comunicate a tali persone o rese disponibili come un'applicazione destinata all'uso su una rete. [...]” [19] In altre parole, se qualcuno costruisce un sito web basato sul codice di Facebook, questi deve rendere disponibile il codice sorgente assieme alle modifiche effettuate non appena permette agli utenti di entrare nel sito ed usare quindi l'applicazione, indipendentemente dal fatto che lo sviluppatore invii il proprio codice come un prodotto separato. Un'altra considerazione importante a proposito della licenza CPAL è il fatto che, essendo basata sulla licenza MPL, non è compatibile con la licenza GNU GPL. Inoltre Facebook non si è avvalsa delle clausole della licenza CPAL relative alla possibilità di doppia licenza, il cosiddetto dual licensing model, utilizzato per esempio da ExtJS come vedremo in seguito, implicando in tal modo che ogni pezzo di codice di Facebook licenziato sotto CPAL non può essere legalmente usato insieme a codice sotto GNU GPL. Poi chiunque volesse usare il codice di Facebook come parte di un'applicazione web preesistente, dovrebbe rilasciare anche il codice sorgente di tale programma.

Critiche alla licenza CPAL ed a Facebook

La licenza CPAL è stata fortemente criticata da molti sviluppatori e marcata addirittura come “falsa licenza open source”. Questo perché da certi punti di vista assomiglia molto alle licenze BadgeWare che impongono tra l'altro una sorta di attribuzione da mostrare in ogni copia sull'autore del codice sorgente. Questa clausola è fortemente correlata alla possibilità di fatto proibita di fare fork di applicazioni licenziate in questo modo, e questo è un diritto fondamentale del software open source. Con “proibire di fatto” si intende che, poiché in ogni pagina dell'applicazione deve essere mostrato il logo e le clausole dello sviluppatore originale, lo spazio che rimane a disposizione è molto esiguo. Il logo sotto licenza CPAL non può essere chiaramente rimosso, né rimpicciolito o oscurato in ogni modo e deve sempre essere visibile su ogni pagina dell'applicazione. Pertanto – secondo i sostenitori di questa visione – appare evidente che aggiungendo un proprio logo non rimarrebbe più spazio per l'applicazione. Il rischio è quindi che si vengano a creare delle pagine piene di loghi ed immagini, a discapito di nuove web application. A questo proposito Mayfield ha commentato: “Ora abbiamo un'opportunità per scoprire se questi incubi nel mercato sono realmente veri.” [20] Naturalmente poi un utente che volesse prendere un'applicazione sotto licenza CPAL ed installarla all'interno della propria azienda si troverebbe negato il diritto di sostituire il logo con quello della propria compagnia, anche se il software è usato solamente all'interfaccia dell'azienda, e questo non è ben visto da molti. Il problema quindi non è discutere se e quanto la licenza CPAL sia open source, e lo è in 54

Capitolo 4: Modifiche all'applicazione e rilascio in open source quanto è stata approvata dalla OSI, ma è relativo alla possibilità di adozione che viene fortemente scoraggiata dalla clausola “badgeware”. Infatti i rivali di Facebook, si pensi per esempio a MySpace, non implementeranno mai un'applicazione che li obblighi a mostrare un logo di Facebook su ogni pagina del sito web. Tutto questo quindi appare controproduttivo se gli intenti sono in linea con i principi alla base dell'open source, poiché di fatto scoraggia altri network dall'adottare ed usare questa piattaforma. Dall'altra parte i sostenitori della licenza CPAL dicono che non è “né buona né cattiva, ma è come è”, ovvero un accordo per onorare certi termini d'uso. Se non piace a qualcuno – dicono – basta che questo non la usi. Inoltre pongono l'accento sul fatto che è molto positivo che Facebook abbia rilasciato gran parte del proprio codice con una licenza open source che chiunque può prendere ed usare, e questo è proprio uno dei principi dell'open source. La licenza CPAL potrebbe essere un brutto colpo per i service provider nel caso guadagnasse una larga adozione. A questo proposito è interessante riportare qui il parere Chris DiBona, program manager dell'open source presso Google: “Abbiamo abbastanza risorse ingegneristiche tali che, se la licenza impone obblighi a cui non vogliamo sottostare, semplicemente non la useremo.” [20] Questo per dire che nel caso di una diffusione inaspettata di codice protetto da licenza CPAL, Google lo svilupperà da sé, invece di usare del codice già esistente, per non incorrere in clausole non gradite. Sono state poi rivolte molte critiche a Facebook anche per i Terms Of Contents (TOS) [21] che utilizza ed il rapporto che ne consegue con la privacy dei suoi utenti. Innanzitutto i termini possono cambiare a discrezione di Facebook in qualunque momento; questo è probabilmente normale per un sito internet, ma è interessante analizzare il disclaimer che compare all'inizio dei TOS: “We reserve the right, at our sole discretion, to change, modify, add, or delete portions of these Terms of Use at any time without further notice.” ovvero “Ci riserviamo il diritto, a nostra sola discrezione, di cambiare, modificare, aggiungere o cancellare parti di questi termini d'uso in qualsiasi momento senza alcuna ulteriore notifica.” Poiché le regole quindi possono essere modificate in qualsiasi momento, continuando ad usare il sito (Facebook) l'utente viene implicitamente ritenuto d'accordo a sottostare a queste regole, anche qualora non ne fosse a conoscenza, essendo appunto state modificate senza darne comunicazione alcuna. Facebook si suppone venga usato solamente per uso personale: “You understand that except for advertising programs offered by us on the Site (e.g., 55

Capitolo 4: Modifiche all'applicazione e rilascio in open source Facebook Flyers, Facebook Marketplace), the Service and the Site are available for your personal, non-commercial use only.” ovvero, “Tu capisci che eccetto per pubblicizzare programmi offerti da noi sul Sito (per esempio Facebook Flyers, Facebook Marketplace), il Servizio ed il Sito sono disponibili solamente per il tuo uso personale, non commerciale.” Questo da un punto di vista teorico implica che solo persone reali possano creare un profilo, e che non debbano guadagnarci da esso. D'altra parte non si può negare che molte organizzazioni di beneficenza, per non parlare dei partiti ed altre associazioni, abbiano un loro profilo su Facebook, e questo non corrisponde certamente al requisite di “personale” enunciato sopra. In ogni caso bisogna prestare attenzione al fatto che se un utente volesse crearsi un profilo per i propri affari o per la propria ditta potrebbe essere bandito da Facebook. Similmente, si suppone che ad ogni profilo corrisponda una persona individuale, non un'organizzazione: “In addition, you agree not to use the Service or the Site to: […] register for more than one User account, register for a User account on behalf of an individual other than yourself, or register for a User account on behalf of any group or entity;” ovvero, “Inoltre, tu sei d'accordo di non usare il Servizio o il Sito per: […] registrare più di un account utente, registrare un account utente a nome di un individuo diverso da te stesso o registrare un account utente a nome di qualsiasi gruppo o entità;”. Questo implica chiaramente che non si possono avere due account su Facebook, come qualcuno fa (per esempio registrandone uno a nome proprio ed uno a nome del proprio animale domestico). Facebook prospera, almeno in parte, e deve una buona fetta del suo successo ai contenuti inviati dagli utenti. Ma alcuni hanno criticato il modo in cui Facebook gestisce il diritto d'autore dei contenuti inviati, applicando ad essi una licenza che di fatto permette ai responsabili di Facebook di fare quello che vogliono: “By posting User Content to any part of the Site, you automatically grant, and you represent and warrant that you have the right to grant, to the Company an irrevocable, perpetual, non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense) to use, copy, publicly perform, publicly display, reformat, translate, excerpt (in whole or in part) and distribute such User Content for any purpose on or in connection with the Site or the promotion thereof, to prepare derivative works of, or incorporate into other works, such User Content, and to grant and authorize sublicenses of the foregoing.” ovvero, “Inviando del contenuto da parte di un utente in qualsiasi parte del Sito, tu concedi automaticamente alla Compagnia, e tu rappresenti e garantisci che hai il diritto di concedere, una licenza irrevocabile, perpetua, non esclusiva, trasferibile, compiutamente pagata, a livello mondiale (con diritto di sottolicenza) per usare, copiare, rappresentare in pubblico, esporre pubblicamente, adattare, tradurre, citare (per intero od in parte) e distribuire tali contenuti da parte di un utente per qualsiasi scopo o in connessione al Sito o con la promozione dello stesso, per preparare opere derivate, per incorporare in altre 56

Capitolo 4: Modifiche all'applicazione e rilascio in open source opere, tali contenuti da parte di un utente, e concedere ed autorizzare sottolicenze dei precedenti.” In altre parole, quello che viene stabilito in queste righe è che l'utente che invia del contenuto al sito rinuncia di fatto al controllo del copyright sul proprio materiale. Per fare un esempio, se un utente carica una foto su Facebook, i responsabili del sito possono rivendere copie di questa foto senza pagare all'autore alcunché, oppure se un utente scrive una nota sul suo profilo – o perfino se importa gli articoli del suo blog – Facebook può prendere quanto scritto, trasformarlo in un libro, vendere milioni di copie e non dare un centesimo all'autore. Appare quindi evidente come sia necessario prestare la massima attenzione a quanto si carica sul sito, visto quali conseguenze, o perlomeno possibilità, può comportare questa azione. Le applicazioni non sono sicure: “[...] while we have undertaken contractual and technical steps to restrict possible misuse of such information by such Platform Developers, we do not screen or approve Developers, and we cannot and do not guarantee that all Platform Developers will abide by such restrictions and agreements.” ovvero, “Nonostante abbiamo intrapreso passi contrattuali e tecnici al fine di restringere il possibile abuso di tali informazioni da tali Sviluppatori della Piattaforma, non selezioniamo o approviamo gli Sviluppatori, e non possiamo e non garantiamo che tutti gli Sviluppatori della Piattaforma rispetteranno tali restrizioni ed accordi.” Questo significa che l'utente deve prestare attenzione a quali applicazioni aggiunge al suo profilo: nel caso in cui uno sviluppatore malintenzionato volesse violare i protocolli di sicurezza di Facebook e ad esempio scoprire le informazioni personali di un utente, questo molto probabilmente sarebbe molto difficile da fare, Facebook non avrebbe alcuna colpa né responsabilità. Alcuni giuristi americani hanno poi contestato il seguente punto: se Facebook commettesse qualche scorrettezza ed un utente volesse citare l'azienda in giudizio, nella maggior parte dei casi in pratica non potrebbe. Questo perché accettando i TOS si accetta una “final and binding arbitration”, cioè un “arbitrato finale e fissato” per risolvere la maggior parte delle vertenze con Facebook. In altre parole, senza addentrarci troppo nell'aspetto prettamente giuridico della questione, è sufficiente notare che molto probabilmente un utente non trascorrerà un singolo giorno in tribunale contro Facebook, ma se questo dovesse accadere, sarebbe secondo certe regole precedentemente – ed accuratamente – fissate dall'azienda stessa, come per esempio il fatto che il processo sarebbe in California e la corte seguirebbe le leggi del Delaware. Un'altra questione molto dibattuta ha a che fare con i feedback, vale i dire i commenti e le idee rilasciate dagli utenti per migliorare Facebook: 57

Capitolo 4: Modifiche all'applicazione e rilascio in open source “You acknowledge and agree that any questions, comments, suggestions, ideas, feedback or other information about the Site or the Service (”Submissions”), provided by you to Company are non-confidential and shall become the sole property of Company.” ovvero “Tu riconosci e concordi che qualsiasi domanda, commento, suggerimento, idea, feedback o altra informazione sul Sito o sul Servizio (“Sottomissione”), fornita da te alla Compagnia non è confidenziale e diventerà di sola proprietà della Compagnia.” Questo probabilmente è un atteggiamento comune per una grande azienda, tuttavia prima di spedire qualsiasi idea è opportuno tenere in considerazione quanto appena esposto, tenendo magari celate le migliori idee. Di sicuro se gli utenti fossero a conoscenza di questa clausola, non sarebbero entusiasti di sapere che le loro opinioni e suggerimenti diventano proprietà di Facebook. Questa politica si pone quindi in contrasto con i principi di diffusione e condivisione della conoscenza del Web2.0 e non invoglia certamente gli utenti a condividere le loro idee con l'azienda stessa. Infine la critica più feroce è stata fatta riguardo alla gestione della privacy, che non viene tutelata a dovere. Infatti nella Privacy Policy è scritto: “[...] we cannot and do not guarantee that User Content you post on the Site will not be viewed by unauthorized persons. We are not responsible for circumvention of any privacy settings or security measures contained on the Site.” ovvero, “Noi non possiamo e non garantiamo che il contenuto da parte di un utente che pubblichi sul Sito non sarà visto da persone non autorizzate. Noi non siamo responsabili per la circonvenzione di qualsiasi configurazione della privacy o misure di sicurezza contenute sul Sito.” Questo significa che se qualcuno riesce a penetrare illegalmente nel tuo profilo di Facebook, ruba tutti i contenuti o i tuoi dati personali, poi ne fa un uso scorretto, non puoi rivalerti su Facebook. Oltretutto, gli stessi imprenditori di terze parti di Facebook possono abusare delle tue informazioni: “We may provide information to service providers to help us bring you the services we offer. […] Where we utilize third parties for the processing of any personal information, we implement reasonable contractual and technical protections limiting the use of that information to the Facebook-specified purposes.” ovvero “Noi possiamo fornire informazioni ai service providers per facilitarci a darti i servizi che offriamo. […] Ogniqualvolta utilizziamo [applicazioni di] terze parti per processare qualsiasi informazione personale, noi implementiamo ragionevoli protezioni contrattuali e tecniche al fine di limitare l'uso di queste informazioni agli scopi specificati da Facebook.” Ma soprattutto, Facebook non garantisce la tua privacy: “Please keep in mind that if you disclose personal information in your profile or when posting comments, messages, photos, videos, Marketplace listings or other items, this information may become publicly available.” ovvero, “Per cortesia tieni a mente che se rendi pubbliche informazioni personali nel tuo 58

Capitolo 4: Modifiche all'applicazione e rilascio in open source profilo o quando invii commenti, messaggi, foto, video, elenchi Marketplace o altre cose, queste informazioni potrebbero diventare di pubblico dominio.” Come a dire, se per qualche motivo tutti i tuoi dati personali venissero rubati, nessuno è responsabile e l'unico a rimetterci sarai tu.

Le risposte di Facebook

Una risposta ufficiale a queste critiche non vi è mai stata, tuttavia numerosi esperti del settore hanno fatto notare che tutte queste norme servono a Facebook solamente per quello che è, e non per prendersi poteri sulla privacy e le informazioni dei suoi utenti. Una delle caratteristiche tipiche di Facebook è la possibilità di aggiungere numerose applicazioni che in automatico ricavano informazioni sull'utente, come ad esempio la foto del profilo. Questa azione in qualsiasi applicazione web deve essere espressamente accettata dall'utente interessato, ma appare evidente come questo comporterebbe un impedimento della diffusione di tutte queste applicazioni: l'utente infatti sarebbe costretto a cliccare decine di volte per scegliere cosa effettivamente condividere e cosa no con l'applicazione scelta. In questo modo quindi Facebook rende più facile la vita per gli sviluppatori di tali applicazioni, che non devono più preoccuparsi di richiedere i dati all'utente espressamente, ma possono utilizzarli avendo l'utente precedentemente accettato i termini di Facebook. Un'altra opinione comune è poi relativa al fatto che Facebook, pur potendo secondo i termini sopra citati, non prenderà mai, per esempio, le foto di un utente per usarle a fini commerciali o di lucro. Infatti questo sarebbe controproducente per l'azienda stessa, che deve la sua fama ai contenuti degli utenti, poiché questi ultimi molto probabilmente si lamenterebbero non tanto della legalità dell'azione quanto della moralità, e facilmente si sposterebbero verso altre applicazioni rivali, decretando la fine del successo di Facebook. A sostegno di questa tesi, ovvero che Facebook tiene molto in considerazione l'opinione dei propri utenti, vi è un recente caso: poche settimane fa il management aveva deciso di modificare i TOS, introducendo una nuova clausola che sanciva che tutto il materiale caricato da un utente sarebbe rimasto conservato per sempre sui server dell'azienda, anche qualora l'utente decidesse di chiudere il proprio account. La reazione immediata, netta e planetaria degli utenti non ha tardato a farsi sentire, lamentandosi in modo deciso riguardo a tale decisione. A questo punto è quindi intervenuto il fondatore Mark Zuckerberg che ha difeso sul suo blog le nuove modifiche introdotte ai TOS, sostenendo che “[...] quando una persona condivide qualcosa come un messaggio con un amico, vengono create due copie di questo messaggio: una nella casella di posta inviata del mittente e l'altra nella casella di posta ricevuta del destinatario. Anche se il mittente cancella il proprio account, il destinatario (o i destinatari) hanno ancora una copia di tale messaggio. Noi pensiamo che è questa la via corretta di lavorare per Facebook, e che è in linea con quanto fanno altri servizi come i servizi email. Una delle ragioni per cui abbiamo aggiornato i nostri termini era per fare chiarezza in merito. [...]” [22] 59

Capitolo 4: Modifiche all'applicazione e rilascio in open source L'utenza però, per nulla convinta da questa spiegazione, ha continuato la protesta, con il risultato che le nuove modifiche sono state ritirate. Sebbene la conclusione non sia una vera e propria ammissione d'errore, quanto piuttosto una resa temporanea, rimane il fatto che la discussione che si è generata è stata condotta in modo limpido e diretto tra i manager di Facebook e gli utenti dell'applicazione, in un rapporto nuovo tra utenti-clienti che è insito nel messaggio rivoluzionario del web2.0. Viene ora trattata la licenza Affero General Public License (AGPL) che è un'altra possibilità, oltre alla licenza CPAL appena vista, di licenza open source particolarmente indicata per applicazioni web.

Licenza Affero General Public License (AGPL)

La licenza GNU Affero General Public License (AGPL) v3 [23] è una licenza open source e copyleft. Essa deriva dalla GNU GPLv3 a cui è stato aggiunto un ulteriore paragrafo alla sezione 13 in modo da risolvere il già citato ASP loophole e permettere agli utenti che interagiscono tramite una rete con il software licenziato sotto AGPL di ricevere il codice sorgente del programma. Tale clausola infatti obbliga a mostrare su ogni pagina dell'applicazione web un qualche mezzo per accedere al codice sorgente, tipicamente tramite un link, e poterlo liberamente scaricare. La nascita di questa licenza è dovuta infatti proprio a questo buco che si è venuto a creare con la distribuzione web e si fonda sul fatto che la comunità di utenti e sviluppatori dovrebbe avere certi diritti verso il software con cui interagiscono. Poiché però l'interazione avviene solo tramite network, la GNU GPL non prevede la distribuzione dei sorgenti. Essa è pertanto la scelta adatta per ogni applicazione open source che offre tipicamente dei servizi tramite una rete, in modo particolare tramite internet. Degno di nota è il fatto che la licenza GNU AGPLv3 non è compatibile con la licenza GNU GPLv2. Inoltre tecnicamente non è neppure totalmente compatibile con la licenza GNU GPLv3, ovvero non è possibile prendere del codice sotto GNU AGPL e modificarlo e distribuirlo tramite GNU GPLv3, e viceversa. Tuttavia è compatibile in senso lato con la GPLv3, ovvero è possibile combinare assieme diverse parti di programmi rilasciati sotto entrambe le licenze in oggetto, riunirli in un unico programma e distribuire questo ultimo che sarà licenziato in parte sotto AGPLv3 ed in parte sotto GPLv3.

Come licenziare sotto GNU GPL, LGPL, AGPL Per poter licenziare il proprio software sotto licenza GNU General Public License, Lesser General Public License oppure Affero General Public License è necessario seguire una serie di procedure [24]. Innanzitutto bisogna aggiungere due elementi ad ogni file sorgente del proprio programma: una nota di copyright ed una dichiarazione che attesti il permesso di copia ed affermi che il programma è distribuito sotto i termini della GNU General Public License. 60

Capitolo 4: Modifiche all'applicazione e rilascio in open source La nota di copyright, per esempio “Copyright 2009 Mario Bianchi”, deve sottostare alle seguenti indicazioni: ●

deve contenere l'anno in cui si è finito di preparare il rilascio del software (quindi se per esempio si è finito nel 2008 ma non si è aggiunta alcuna licenza fino al 2009, bisogna usare come anno il 2008);

●

deve contenere l'anno relativo ad ogni rilascio, per esempio “Copyright 2008, 2009 Mario Bianchi” se alcune versioni sono state finite nel 2008 ed altre nel 2009;

●

deve contenere il nome di tutte le persone che hanno contribuito alla stesura del codice;

●

nel caso di software con diversi rilasci in anni differenti, è meglio scrivere espressamente ogni anno per intero senza usare abbreviazioni o intervalli di tempo (ad esempio 2008-09) come specificato sopra;

●

è necessario usare sempre la parola inglese “Copyright”, usata in tutto il mondo secondo le convenzioni internazionali, anche per materiale in lingua differente;

●

il simbolo di copyright “©” può essere incluso a piacimento e se il set di caratteri usato lo supporta, ma non è necessario. Non c'è alcun significato legale nell'usare la sequenza di tre caratteri “(C)”, sebbene non faccia male;

●

se il programma contiene codice copiato da altri programmi che usano la stessa licenza, si deve copiare anche questa nota di copyright e mettere tutte le note di copyright assieme, all'inizio di ogni file.

La dichiarazione attestante il permesso di copia che affermi che il programma è distribuito sotto i termini della GNU General Public License deve stare all'inizio di ogni file sorgente, vicino alla nota di copyright. Quando si usa la licenza Lesser GPL oppure la licenza Affero GPL, si deve sostituire ad ogni occorrenza della scritta “GNU General Public License” la scritta “GNU Lesser Public License” o similmente “GNU Affero Public License” nel testo all'inizio di ogni file sorgente. Nel caso di programmi interattivi è buona norma far sì che il programma mostri un breve avviso relativo al copyright ed ai permessi di copia quando viene lanciato. La dichiarazione attestante il permesso di copia dovrebbe essere inserita subito dopo l'avviso relativo al copyright; nel caso di un programma di un solo file, la dichiarazione (per la licenza GPL) deve essere come la seguente: This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see .

61

Capitolo 4: Modifiche all'applicazione e rilascio in open source Nel caso invece di programmi con più di un file, è meglio sostituire alla scritta “il programma” il nome del programma ed iniziare la dichiarazione con una riga che dica “Questo file è parte di NOMEDELPROGRAMMA”, come ad esempio: This file is part of Foobar. Foobar is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Foobar is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with Foobar. If not, see . E' poi necessario includere una copia della stessa licenza da qualche parte all'interno del programma che si vuole distribuire. Tutti i programmi, sia che siano rilasciati sotto GPL, sia sotto LGPL, dovrebbero includere la versione testuale della licenza GPL. Generalmente tale testo, all'interno dei programmi GNU, si trova in un file chiamato COPYING. Se il programma viene rilasciato sotto LGPL, è necessario includere anche la versione testuale della licenza LGPL, generalmente in un file chiamato COPYING.LESSER. Questo perché, dato che la LGPL è un insieme di permessi aggiuntivi rispetto alla GPL, è importante includere entrambe le licenze in modo che l'utente abbia a disposizione tutto il materiale che serve per capire i diritti di cui gode. Nel caso invece il codice del programma sia rilasciato sotto GNU AGPL, basta includere la versione testuale della licenza GNU AGPL. E' molto importante aggiungere, perlopiù per ragioni pratiche, informazioni relative a come contattare gli sviluppatori, generalmente in un file chiamato README, nonostante questa pratica non abbia nulla a che fare con gli aspetti legali relativi all'applicazione di una licenza. Se il programma poi è rilasciato sotto licenza GNU AGPL e può interagire con gli utenti attraverso una rete, tale programma deve offrire il suo codice sorgente agli utenti in qualche modo. Ad esempio, nel caso il programma sia un'applicazione web, l'interfaccia potrebbe mostrare un collegamento di nome “Source” che conduca gli utenti ad un archivio del codice. La licenza AGPL è abbastanza flessibile sulla scelta delle modalità adatte al proprio programma con cui mostrare il codice sorgente agli utenti, come descritto dettagliatamente alla sezione 13. Non c'è alcun requisito legale per registrare il proprio copyright con alcun ente o persona: la semplice diffusione del programma lo rende di fatto protetto da copyright. Tuttavia è buona norma registrare il copyright presso il registro americano dei copyright (US Registry of Copyrights) perché in questo modo si è in una posizione più forte rispetto a chiunque violi la licenza negli USA. Questo procedimento andrebbe attuato in ogni paese del 62

Capitolo 4: Modifiche all'applicazione e rilascio in open source mondo; d'altra parte bisogna notare che la maggior parte dei paesi non hanno un sistema di registrazione dei copyright. Infine è saggia cosa chiedere ad ogni sviluppatore, azienda o altre persone che abbiano contribuito allo sviluppo del programma, di firmare un disclaimer relativo al copyright del lavoro svolto, in modo tale che non possano rivendicare in seguito alcun diritto su di esso. Un esempio di disclaimer è il seguente (utilizzare i propri nomi relativi all'azienda ed al programma): Google, Inc., hereby disclaims all copyright interest NAMEOFTHEPROGRAM written by NAMEOFTHEAUTHOR.

in

the

program

SIGNATURE, DATE

Licenze dei componenti del sistema CakePHP CakePHP è rilasciato sotto licenza MIT che è una licenza approvata sia dalla Free Software Foundation (FSF) sia dalla OSI (Open Source Initiative). La licenza MIT, che prende il nome dal Massachussets Institute of Technology dove venne ideata, è chiamata anche licenza X11. Questa è una licenza molto permissiva perché permette di combinare assieme sia software proprietario che software open source, purché la licenza venga distribuita assieme al nuovo software creato. La licenza MIT è anche compatibile con la licenza GNU GPL, ovvero è possibile rilasciare software sotto licenza GNU GPL contenente altro software sotto licenza MIT. Il testo della licenza è il seguente: “Copyright (c) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT 63

Capitolo 4: Modifiche all'applicazione e rilascio in open source HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ”

ExtJS ExtJS segue il modello business della doppia licenza (Dual License business model) permettendo quindi di scegliere tra due licenze differenti: una necessaria per sviluppare software commerciale, l'altra per sviluppare software open source. Questo modello è basato sul principio del “Quid pro quo”, ovvero “qualcosa per qualcosa”: o l'azienda sceglie di sviluppare la propria applicazione con la licenza che vuole, anche proprietaria, e per fare ciò deve comperare una licenza commerciale ExtJS, oppure l'azienda sceglie di contribuire con la comunità open source rilasciando il codice dell'applicazione sviluppata sotto una licenza open source (GPL v2, GPL v3, ecc.) permettendo quindi a chiunque voglia di accedere al codice sorgente, modificarlo e distribuirlo liberamente. ExtJS versione 2.2 o superiore è rilasciato sotto licenza GPL v3, così chiunque può usare la libreria ExtJS per sviluppare una nuova applicazione, premesso che l'intero lavoro derivato sia licenziato ancora sotto GPL v3. Ci sono comunque altre possibilità per sviluppare un'applicazione open source che è distribuita sotto una licenza FLOSS differente dalla GPL v3. Per far questo, ExtJS ha aggiunto una specifica eccezione alla licenza. Questa eccezione è destinata alle applicazioni sviluppate da utenti e non a librerie software di vario tipo, framework o toolkit che sono coperti da un'altra specifica eccezione. L'eccezione dà il diritto di distribuire il lavoro derivato, vale a dire la propria applicazione, formato dalla libreria ExtJS ed altre opere coperte da licenze FLOSS sotto una o più licenze FLOSS scelte da una determinata lista (vedi tabella 1) sottostando alle seguenti condizioni [25]: 1. “tu rispetti la GPL in ogni aspetto relativo alla Libreria [ExtJS] ed all'Opera Derivata [l'applicazione sviluppata], eccetto per le sezioni identificabili dell'Opera Derivata che non sono derivate dalla Libreria e che possono essere ragionevolmente considerate indipendenti ed opere separate in se stesse. 2. Tutte le sezioni identificabili dell'Opera Derivata che non sono derivate dalla Libreria e che possono essere ragionevolmente considerate indipendenti ed opere separate in se stesse, 1. sono distribuite sotto una delle licenze FLOSS indicate sotto, e 2. il codice oggetto o la forma eseguibile di queste sezioni sono accompagnate dal codice sorgente corrispondente completo in forma leggibile da una macchina per quelle sezioni sullo stesso mezzo e non sotto la stessa licenza FLOSS come il corrispondente codice oggetto o le forme eseguibili di quelle sezioni, e 3. qualsiasi opera che è aggregata con la Libreria o con un'Opera Derivata su un mezzo di distribuzione o di memoria in accordo con la GPL, può essere 64

Capitolo 4: Modifiche all'applicazione e rilascio in open source ragionevolmente considerata un'opera indipendente ed un'entità a parte che non deriva né dalla Libreria, né da un'Opera Derivata né da un'Opera FLOSS. 4. L'Opera Derivata può essere ragionevolmente considerata un'opera indipendente e separata che è destinata per l'uso degli utenti finali e non come una libreria per scopi di sviluppo di programmi software.”

65

Capitolo 4: Modifiche all'applicazione e rilascio in open source Nome della licenza

Versione(i)/Data del copyright

Academic Free License

2.0

Apache Software License

2.0

Apple Public Source License

2.0

Artistic license

From Perl 5.8.0

BSD license

"July 22 1999"

Common Development and Distribution License (CDDL)

1.0

Common Public License

1.0

Eclipse Public License

1.0

Educational Community License

2.0

GNU General Public License (GPL)

2.0

GNU Library or "Lesser" General Public License (LGPL)

3.0

Jabber Open Source License

1.0

MIT License (As listed in file MITLicense.txt)

-

Mozilla Public License (MPL)

1.0/1.1

Open Software License

2.0

OpenSSL license (with original SSLeay license)

"2003" ("1998")

PHP License

3.0

Python license (CNRI Python License)

-

Python Software Foundation License

2.1.1

Sleepycat License

"1999"

University of Illinois/NCSA Open Source License

-

W3C License

"2001"

X11 License

"2001"

Zlib/libpng License

-

Zope Public License

2.0

Tabella 1: Lista di licenze open source Pertanto è possibile combinare assieme diverse opere rilasciate sotto varie licenze FLOSS (tra quelle che compaiono nella tabella 1) con la libreria ExtJS, ammesso che l'intera opera derivata sia poi licenziata sotto GPL v3. 66

Capitolo 4: Modifiche all'applicazione e rilascio in open source

Altri componenti Come icone sono state usate le famfamfam [26] licenziate sotto Creative Commons Attribution 2.5 License. Questo implica che possono essere usate e modificate per qualsiasi scopo, l'unica clausola è che venga chiaramente indicato, tramite un collegamento web, l'autore delle icone nella pagina dei “credits”. Lo sfondo ed altre immagini sono stati creati ad hoc o in parte usate quelle contenute all'interno di alcune distribuzioni linux in modo particolare sfondi di KDE. La chat è stata creata con Yakalope, a “multi-protocol web-based chat client with logging and continual presence support. It is being built upon solid existing technologies such as Jabber, Django, Ext.js, JSJaC, and others.” [27] La licenza di tale componente è la GNU GPLv2 o superiore, che risulta compatibile con GNU AGPLv3. Per quanto riguarda i feed RSS, è stato usato SimplePie, a “very fast and easy-to-use class, written in PHP, that puts the “simple” back into “really simple syndication”. Flexible enough to suit beginners and veterans alike, SimplePie is focused on speed, ease of use, compatibility and standards compliance.” [28] La licenza usata è BSD, anch'essa compatibile con GNU AGPLv3. Infine altri componenti usati di importanza minore sono libIcal, licenziato sotto GPLv2 o superiore ed alcuni file JavaScript per gestire colori e suoni, licenziati sotto BSD.

Discussione sulla licenza da adottare e scelte finali Per decidere la licenza sotto la quale rilasciare l'intera applicazione sviluppata, abbiamo fatto una riunione per capire quali fossero esattamente i nostri obiettivi e le nostre necessità. Innanzitutto abbiamo deciso di usare una licenza open source, in quanto rispondeva ai nostri principi di condivisione della conoscenza, in accordo con gli obiettivi che si propone per l'appunto l'applicazione sviluppata. Le nostre decisioni in particolare riguardavano sostanzialmente due punti: 1. attribuzione, cioè riconoscimento del lavoro da noi svolto; chiunque scarichi e modifichi il nostro codice deve quindi esplicitare che gli autori siamo noi; 2. redistribuzione delle modifiche, ovvero le modifiche ed i miglioramenti fatti al codice sorgente devono essere restituiti alla comunità open source. La scelta è stata limitata, dopo un'analisi relativa alla compatibilità delle licenze del codice delle varie librerie usate nello sviluppo dell'applicazione, alla MIT, alla GNU General Public License v3 (GPLv3) ed alla Affero General Public License (AGPL). Abbiamo poi analizzato i possibili scenari che si sarebbero potuti presentare in futuro, con i relativi vantaggi e svantaggi associati alla scelta di una o dell'altra licenza. In particolare, la scelta della licenza AGPL favorirebbe la diffusione del codice modificato, 67

Capitolo 4: Modifiche all'applicazione e rilascio in open source grazie appunto alle sue peculiari caratteristiche che impongono la presenza ben visibile in ogni pagina di un collegamento al codice, ma probabilmente scoraggerebbe l'adozione della piattaforma da parte di aziende interessate a trarne profitto, visto l'obbligo del rilascio delle modifiche. Queste potrebbero comunque contattarci per chiedere di licenziare il software sotto un'altra licenza, tuttavia è facile che queste potenziali utenze rinuncino a farlo e vadano piuttosto alla ricerca di altre applicazioni a loro più convenienti. Pertanto possiamo ipotizzare che, in linea generale, da una parte la licenza AGPL favorisce la diffusione delle modifiche e contribuisce in modo evidente alla circolazione ed alla diffusione del software libero, d'altra parte sfavorisce l'adozione di tale software da parte delle aziende interessate a ricavarne un guadagno. Per quanto concerne invece la licenza MIT, questa incoraggia indubbiamente l'adozione del codice da parte di enti interessati a trarne profitto, favorendo un'ampia diffusione del programma, in quanto non impone vincoli sul rilascio delle modifiche né sulla licenza sotto la quale rilasciare il software modificato. Tutto questo va però a scapito del rilascio delle modifiche apportate ai sorgenti che rimarrebbero di proprietà dell'azienda e non di tutta la comunità del software libero. Quello che è emerso pertanto è che vi è una relazione inversamente proporzionale tra la diffusione del proprio software, cioè l'adozione possibile da parte di altri, ed il ritorno dalla comunità, ovvero il rilascio delle modifiche al codice sorgente effettuate da altri. E' stata quindi scartata la licenza MIT, che pur essendo molto libera, non avrebbe obbligato i futuri sviluppatori che avessero modificato il nostro codice a rilasciare le loro modifiche, e questo non era in linea con i principi base del Web 2.0 quali sono la diffusione, la condivisione e la disseminazione della conoscenza. Inoltre avendo usato nello sviluppo dell'applicazione dei componenti licenziati sotto GNU GPL, a causa della caratteristica di questa licenza, vale a dire la “contaminazione” del codice, avremmo dovuto rilasciare tutto sotto GNU GPL oppure non usare, quindi riscrivere o ricercare altre soluzioni, software licenziato sotto GNU GPL. Infine tra la licenza GNU GPL e la licenza AGPL si è scelto di usare quest'ultima perché più adatta ad una piattaforma web quale è Taolin, nonostante si debba riconoscere che la licenza AGPL finisca, per i motivi sopra esposti, col rendere più difficile per altri l'adozione del nostro software. Nel caso riscontrassimo significativi motivi per cambiare licenza, o ricevessimo numerose richieste in merito, una riconsiderazione sulla licenza GNU GPL sarebbe certamente possibile. Anche in vista di questo ripensamento la scelta di usare, almeno inizialmente, AGPL ci è parsa corretta, in modo da passare eventualmente da una licenza più restrittiva (AGPL) ad una meno restrittiva (GNU GPL), e non il contrario che non avrebbe senso (in quanto il codice rilasciato sotto GPL rimarrebbe comunque disponibile, per chi lo avesse scaricato ed usato, con quella licenza).

68

Capitolo 5: Conclusioni

Capitolo 5: Conclusioni Il lavoro svolto ha comportato uno studio preliminare del contesto odierno nell'evoluzione delle web application, in modo particolare relativo all'Enterprise 2.0. Sono state analizzate e confrontate tra loro alcune delle migliori e più diffuse piattaforme esistenti sul web, nello specifico iGoogle, Netvibes e Liferay Social Portal. In seguito si è deciso di implementare una nuova applicazione web open source, denominata Taolin, con lo scopo di migliorare la collaborazione e più in generale la diffusione della conoscenza all'interno di un ambito lavorativo, costituito da realtà differenti tra loro ma ciò nonostante compresenti e necessitanti di una più attiva comunicazione reciproca, quale è la Fondazione Bruno Kessler. Questa tesi ha analizzato il lavoro svolto dal sottoscritto sull'applicazione Taolin, suddiviso in due parti, una pratica ed una teorica. La prima parte è consistita innanzitutto in un'attenta comprensione del codice sorgente per generalizzarlo ed astrarlo dal contesto specifico della Fondazione Bruno Kessler, rendendolo di fatto usufruibile su qualsiasi rete. Quindi si è creato un file di configurazione al fine di poter personalizzare alcuni parametri e gestire dinamicamente diversi metodi di autenticazione tra l'applicazione e varie tipologie di database. Infine è stata realizzata una versione demo dimostrativa ed una guida per l'installazione della stessa. La seconda parte invece ha comportato un'analisi dettagliata delle licenze software e nello specifico delle differenze tra le licenze software proprietarie e le licenze software open source. In seguito, in vista del successivo rilascio alla comunità intera, sono state trattate la licenza Common Public Attribution License (CPAL) e la licenza Affero General Public License (AGPL) ed è stata redatta una guida riguardante le modalità per licenziare software sotto licenza open source. Infine, dopo aver analizzato le varie licenze dei componenti della piattaforma sviluppata, sono state evidenziate le decisioni prese per quanto concerne la scelta della licenza open source relativa al programma. A conclusione del lavoro svolto, il codice sorgente è stato quindi rilasciato pubblicamente sotto licenza GNU Affero General Public License (AGPL). Degna di interesse sarà l'attenta osservazione della diffusione di Taolin: le speranze infatti sono che venga scelta ed adottata da molti utenti, in particolar modo per un uso all'interno delle aziende ed in un contesto di Enterprise 2.0, proprio per le caratteristiche uniche che presenta.

69

Bibliografia 1. iGoogle, marzo 2009, http://www.google.it/ig 2. Netvibes, marzo 2009, http://www.netvibes.com 3. Liferay Portal, marzo 2009, http://www.liferay.com/web/guest/products/portal 4. Fondazione Bruno Kessler: About us, marzo 2009, http://www.fbk.eu/about 5. CakePHP: the rapid development PHP framework, marzo 2009, http://cakephp.org/ 6. Ruby on Rails, marzo 2009, http://www.rubyonrails.org/ 7. Symfony: Web PHP Framework, marzo 2009, http://www.symfony-project.org/ 8. Zend Framework, marzo 2009, http://framework.zend.com/ 9. Ext: a foundation you can build on, marzo 2009, http://extjs.com/ 10. JQuery: The Write Less, Do More, JavaScript Library, marzo 2009, http://jquery.com/ 11. Prototype JavaScript Framework: Easy AJAX and DOM manipulation for dynamic web applications, marzo 2009, http://prototypejs.org/ 12. Representational State Transfer, Wikipedia, the free encyclopedia, 13 marzo 2009, http://en.wikipedia.org/wiki/Representational_State_Transfer 13. JSON, marzo 2009, http://www.json.org/ 14. InfoQ: Debate: JSON vs. XML as a data interchange format, marzo 2009, http://www.infoq.com/news/2006/12/json-vs-xml-debate 15. The Trac Project, marzo 2009, http://trac.edgewall.org/ 16. Subversion, marzo 2009, http://subversion.tigris.org/ 17. Is Google Oppressing the AGPL?, marzo 2009, http://ostatic.com/blog/is-google-oppressingthe-agpl 18. Facebook Developers, Facebook Open Platform, 3 marzo 2009, http://developers.facebook.com/ fbopen/ 19. Common Public Attribution License Version 1.0 (CPAL), Open Source Initiative, marzo 2009, http://opensource.org/licenses/cpal_1.0 20. OSI approves 'badgeware' license, The Register, marzo 2009, http://www.theregister.co.uk/2007/07/25/osi_socialtext_cpla/ 21. Facebook, Terms Of License, 13 marzo 2009, http://www.facebook.com/terms.php 22. Facebook TOS story: quando l'azienda dialoga davvero con gli utenti e torna sui suoi passi, Blogs4biz.info, 10 marzo 2009, http://blogs4biz.libero.it/2009/facebook-tos-story-quando-aziendadialoga-con-gli-utenti/ 23. GNU Affero General Public License, Free Software Foundation, 10 marzo 2009, http://www.fsf.org/licensing/licenses/agpl.html 24. How to use GNU licenses for your own software, GNU Project, Free Software Foundation (FSF), 8 marzo 2009, http://www.gnu.org/licenses/gpl-howto.html 25. Ext, Open Source License Exception for Applications, marzo 2009, http://extjs.com/products/floss-exception.php 26. Famfamfam silk icons, marzo 2009, http://www.famfamfam.com/archive/silk-icons-thats-yourlot/ 27. Yakalope, Google Code, marzo 2009, http://code.google.com/p/yakalope/ 28. SimplePie: Super-fast, easy-to-use, RSS and Atom feed parsing in PHP, marzo 2009, http://simplepie.org/

70