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: Laureando:
Marco Ronchetti 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
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
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
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

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
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
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
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
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
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
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
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
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
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=".">',
'<div class="user-wrapper">',
'<div class="user-item user-{login}">',
'{name} {surname}',
'</div>',
'</div>',
'</tpl>'
);
// 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.
<?php
echo json_encode($response);
?>
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.
<?php
class Feedback extends AppModel{

var $name = 'Feedback';
var $belongsTo = 'User';
}
?>
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
<?php
class FeedbacksController extends AppController {

var $name = 'Feedbacks';
function beforeFilter() {
parent::beforeFilter();
$this->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

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
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
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:
<?php
$config = array(
'App.name' => ' 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
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 </TITLE>.
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
“MarioRossi@test.com”.
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
Il template dei nuovi components è il seguente:
<?php
class MyNewComponent extends Object {
public function connecttoserver($myuser, $password) {

}
public function getuserdn() {

}
public function getusergroups() {

}
?>
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
<?php
class DummyauthComponent extends Object {
protected $defaultuser = "admin";

protected $0 = "admin";
function connecttoserver($myuser, $password) {

if ($myuser == $this->defaultuser && $password == $this->defaultpass)
return true;
else
return false;
}

}

}
?>
Codice 11: La classe di autenticazione Dummyauth.php
44
<?php
class LdapauthComponent extends Object {
protected $ldaphost = "test";

protected $ldapport = 999;
protected $myuser = "";
protected $dn = "OU=USERS,DC=pc,DC=FBK,DC=com";
protected $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;
}

$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;
}

$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
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
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 $name = 'Accounts';

var $helpers = array('Html','Form','Javascript');
var $uses = array('User','Widget');
var $components = array();
var $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
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
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
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
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
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
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
“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
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
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
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
“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
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
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
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
<http://www.gnu.org/licenses/>.
61
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 <http://www.gnu.org/licenses/>.
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
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 in the program
NAMEOFTHEPROGRAM written by NAMEOFTHEAUTHOR.
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) <year> <copyright holders>
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
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
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
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 1.0
License (CDDL)
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 3.0
License (LGPL)
Jabber Open Source License 1.0
MIT License (As listed in file MIT- -
License.txt)
Mozilla Public License (MPL) 1.0/1.1
Open Software License 2.0
OpenSSL license (with original SSLeay "2003" ("1998")
license)
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
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
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-oppressing-
the-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-azienda-
dialoga-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-your-
lot/
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

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

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

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

Caricato da

Copyright:

Formati disponibili

UNIVERSITÀ DEGLI STUDI DI TRENTO

Facoltà di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea (triennale) in Informatica

Analisi dell'evoluzione dei Web Desktop

Anno Accademico 2007 – 2008

Contributo personale allo sviluppo dell'applicazione....................................................................39

Recentemente si è assistito ad un'evoluzione, più filosofica che non tecnica e strutturale,

All'interno di tale contesto si colloca la creazione dell'applicazione Taolin, con l'obiettivo di

Struttura della tesi

Nel capitolo 3 viene presentata la piattaforma web sviluppata.

Infine il capitolo 5 contiene le conclusioni del lavoro svolto in questa tesi.

Capitolo 2: Stato dell'arte

Illustrazione 1: Un'immagine simbolica del Web2.0: gli utenti

contenuto è iterativo, in quanto le persone scrivono e riscrivono il lavoro di ognuno.

intranet già esistenti per adattarle ad un sistema di reti sociali.

Illustrazione 3: il modello FLATNESSES per l'Enterprise 2.0

Rich Internet Application (RIA)

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

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

Il linguaggio di programmazione utilizzato è Java, pertanto l'applicazione risulta essere

Cosa è la Fondazione Bruno Kessler?

Strategie di ricerca e di sviluppo in SoNet

Le principali strategie su cui si base il progetto SoNet sono:

● “Always in beta”: (tradotto “sempre in beta”) questa è la strategia comune adottata

L'applicazione web: Taolin

Use cases, screenshots, spiegazione del sistema

Illustrazione 8: ExtJS Portal

La barra laterale è un componente sociale molto importante: ogniqualvolta un utente clicca

Illustrazione 10: Taolin: visione generale

Architettura del sistema

Architettura 2-tier: back end e front end

JavaScript). Quest'ultimo è un framework JavaScript client-side e cross-browser

Si è scelto di sviluppare un'applicazione web per vari motivi, quali ad esempio:

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

La piattaforma gira su un server interno alla fondazione, in un contesto di Intranet, ed è

Back end: CakePHP

Illustrazione 12: Back end: CakePHP

Front end: ExtJS

Comparazione con jQuery

Illustrazione 13: Front end: ExtJS

Database e procedure di log

Comunicazione tra back end e front end: JSON

Esempio di una risposta JSON

if ($n > 30) $n = 30;

In seguito, grazie all'interfaccia REST messa a disposizione da CakePHP, possiamo

Il risultato è la pagina HTML in codice 2 la quale è un unica riga di codice JSON.

Codice 3: users.js widget

Debug tra back end e front end

Guida alla creazione di una widget per feedback

N.B.: Il seguente tutorial fa riferimento alla struttura delle cartelle sviluppata

Generalmente le widget sono composte di due parti:

Aggiunta di una nuova view

linguaggio JSON, usando la funzione PHP json_encode.

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

Aggiunta di un nuovo model

class Feedback extends AppModel{

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

Aggiunta di un nuovo controller

Il controller contiene il codice PHP che estrae informazioni dal database e

successivamente le mostra attraverso la view definita precedentemente.

class FeedbacksController extends AppController {

function add() {

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