L'asp Loophole Ed Alcune Soluzioni

L’ASP loophole ed alcune soluzioni Michele Dalla Torre Facolt`a di Scienze MM. FF. NN. Universit`a di Trento

1

Introduzione

Lo sviluppo e la diffusione virale negli ultimi anni delle applicazioni web, si pensi in modo particolare ai social network, ha generato nuove problematiche inaspettate. Tra queste, una delle pi`u importanti e` senza dubbio il cosiddetto problema dell’ASP loophole, che si verifica quando un’azienda fa uso di software libero licenziato sotto GNU GPL, la licenza open source pi`u diffusa, per creare web application. Infatti, a causa di un “buco” legislativo in tale licenza, l’azienda in questione pu`o usare e modificare il codice sorgente senza dover distribuire le modifiche effettuate, violando di fatto, seppur non legalmente, lo spirito del software open source che e` volto alla diffusione della conoscenza. In questo articolo viene presentata la problematica dell’ASP loophole. In seguito sono discusse alcune soluzioni possibili, in particolare la licenza GNU Affero GPLv3, la licenza CPAL ed il modello dual licensing.

2

ASP & SaaS

In questa prima sezione vengono date alcune definizioni che saranno utilizzate nel seguito dell’articolo. Con ASP, sigla che sta per Application Service Provider, si fa generalmente riferimento ad una compagnia che fornisce servizi informatici a clienti attraverso una rete. La sigla SaaS, acronimo di Software as a Service, e` riferita di solito al software prodotto secondo il modello ASP. Tale software non e` venduto o fornito

direttamente al cliente, bens`ı ne e` permesso soltanto l’utilizzo tramite una rete. L’utente pertanto paga esclusivamente per fruire delle funzionalit`a del software. In realt`a, tali definizioni non sono accettate da tutti. Alcuni esperti infatti ritengono che il modello ASP e il modello SaaS si differenzino per le modalit`a di gestione del prodotto software. Secondo questa argomentazione, nel modello ASP l’applicazione e` in genere eseguita in uno spazio dati condiviso dai vari utenti, mentre nel modello SaaS e` presente una sola istanza del software ma ogni utente fruisce di uno spazio dati non condiviso bens`ı dedicato. Tuttavia e` bene sottolineare che, in materia cos`ı complessa ed in continua e rapida evoluzione, e` difficile trovare un’opinione comune: le opinioni dei vari esperti del settore infatti sono diverse tra loro e mutano costantemente.

3

L’ASP loophole

Il problema dello “ASP loophole” e` piuttosto recente e si e` venuto a creare con la diffusione virale di applicazioni web che sono venute via via a sostituire molte concorrenti installabili sul disco fisso e non utilizzabili per l’appunto attraverso il web. Tali applicazioni web, ovvero applicazioni accessibili tramite un web browser, si sono diffuse principalmente per i seguenti motivi: • facilit`a di distribuzione ed aggiornamento: essendo l’applicativo residente su un unico server, e` sufficiente per il programmatore aggiornare tale macchina affinch´e ogni uten-

del software libero, il quale ha fatto notare come numerose aziende facciano larghissimo uso di software open source, ma senza essere appunto tenute a distribuire alla comunit`a le modifiche effettuate. Il movimento del software libero rivendica quindi certi diritti che la comunit`a di utenti e sviluppatori dovrebbe avere verso il software con cui interagisce, anche qualora l’interazione avvenga solo tramite network. Da parte loro tali compagnie rivendicano il fatto che non sono obbligate a rilasciare le modifiche ai sorgenti proprio perch´e non stanno ridistribuendo il codice per uso commerciale ma semplicemente forniscono un servizio ai loro utenti.

te, connesso all’applicazione tramite il server, possa godere istantaneamente delle nuove implementazioni; • accesso multipiattaforma: per accedere all’applicazione e` sufficiente un web browser: in tal modo, l’accesso e` indipendente dal sistema operativo utilizzato dal singolo utente; • scalabilit`a: queste applicazioni web sono sviluppate secondo una logica modulare che permette loro di adattarsi facilmente e rapidamente ad un aumento del numero di utenti o ad un cambiamento improvviso della topologia delle rete su cui operano; • riduzione dei costi di gestione: questo modello di sviluppo software consente un risparmio complessivo nei costi di gestione del prodotto, grazie all’utilizzo efficace di ogni parte coinvolta in tale processo.

4

La licenza GNU Affero GPL

Per risolvere la questione e` stata creata la licenza Affero GPL (AGPL) che corregge questo “buco” normativo introducendo una nuova clausola alla licenza GNU GPL. Con la AGPL, se un ASP usa software libero per fornire servizi o altro, deve rendere pubblicamente disponibile il codice sorgente tramite rete (generalmente 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.

Il problema di fondo sta nel fatto che, al momento in cui sono nate le pi`u famose licenze open source (si pensi per esempio alla GNU GPL), non si e` tenuto conto, proprio perch´e tale questione ancora non era venuta alla luce, della diffusione via web di un software. Se uno sviluppatore modifica del codice licenziato sotto GPL, conformemente alle regole sancite dalla licenza dovr`a poi distribuire i sorgenti modificati quando distribuir`a il software; ma – e qui sta il problema dell’ASP loophole – se lo sviluppatore e` un Application Service Provider, cio`e un ente che fornisce un servizio via web, che usa software libero (per esempio licenziato sotto GNU GPL), in tal caso non sta distribuendo il software e quindi non e` tenuto a distribuire anche le modifiche apportate al codice sorgente. Questa possibilit`a deriva da quella che Tim O’Reilly, esponente di spicco della comunit`a open source, defin`ı gi`a alcuni anni fa come l’obsolescenza delle licenze open source nei confronti del Web 2.0. [12] Il nocciolo della questione e` quindi nel termine “distribuire” che non comprende la diffusione di un servizio tramite web.

4.1

La nascita della licenza AGPL

La licenza Affero GPL e` presente in tre diverse versioni: 1. AGPLv1 [15], pubblicata da Affero S.P.A. nel marzo 2002 e basata sulla licenza GNU GPLv2 2. AGPLv2 [16], pubblicata da Affero S.P.A. nel novembre 2007 3. AGPLv3 [9], pubblicata dalla Free Software Foundation [8] nel novembre 2007 e successivamente approvata dalla Open Source Initiative [11] nel 2008, basata sulla licenza GNU GPLv3 L’origine di tale licenza ha inizio da un incontro tra Henry Poole e Richard Stallman, entrambi noti esponenti del movimento del software libero, nel

Questo comportamento, che viola in pratica i principi su cui si basa il software open source, ha provocato forti reazioni all’interno del movimento 2

4.2

2000 ad Amsterdam, dove discussero il problema dell’ASP loophole nella licenza GNU GPLv2. Un anno dopo, nel 2001, Poole fond`o la compagnia Affero S.P.A., una compagnia che realizzava servizi web, ed ebbe la necessit`a di creare una licenza che imponesse la ridistribuzione delle modifiche al codice sorgente a chi avesse utilizzato il codice prodotto da Affero S.P.A. per creare opere derivate.

AGPL: caratteristiche principali

In questa sezione e` trattata esclusivamente la licenza AGPLv3 [9], la pi`u recente e pi`u usata delle tre licenze descritte precedentemente. La licenza GNU Affero General Public License v3 (AGPLv3) [9] e` una licenza open source e copyleft. Essa deriva dalla licenza GNU GPLv3 a cui e` stato aggiunto un ulteriore paragrafo alla sezione 13 in modo da risolvere il gi`a 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 recita: “13. Remote Network Interaction; Use with the GNU General Public License.

Dopo altri dibattiti con alcuni membri della Free Software Foundation venne deciso, a fine febbraio 2002, di aggiungere alla licenza GNU GPLv2 una nuova sezione, la 2(d), che obbligasse gli sviluppatori di opere derivate a fornire il codice sorgente completo. Finalmente, dopo aver chiesto ed ottenuto il permesso dalla Free Software Foundation di pubblicare una licenza derivata della GNU GPLv2 per questi motivi, Poole pubblic`o la licenza Affero GPLv1 nel marzo 2002, al fine di poterla usare nell’ambito della Affero S.P.A. e renderla chiaramente disponibile ad altri sviluppatori di SaaS.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Nel 2007, al momento della stesura della licenza GNU GPLv3, la Free Software Foundation discusse la possibilit`a di includere la clausola speciale della licenza Affero GPLv1 nella licenza GNU GPLv3. Per vari motivi per`o si decise di pubblicare la licenza GNU GPLv3 come una licenza a se stante, sprovvista cio`e di tale clausola. Si rese quindi necessaria la pubblicazione di un’ulteriore licenza, basata sulla nuova GNU GPLv3, che contenesse una clausola simile per scopo alla 2(d) della licenza AGPLv1. Questa nuova licenza venne chiamata GNU Affero GPLv3: si decise di mantenere il nome “Affero” per ricordare la licenza storica AGPLv1 e si introdusse il numero “3” per indicare la correlazione con la licenza GNU GPLv3. La versione definitiva della licenza GNU AGPLv3 venne pubblicata dalla Free Software Foundation in data 19 novembre 2007 e pochi mesi pi`u tardi approvata dalla Open Source Initiative.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.” [9]

Infine, Affero S.P.A. decise di creare la licenza Affero GPLv2 nel mese di novembre 2007, al fine di permettere agli sviluppatori di codice licenziato sotto AGPLv1 di cambiare licenza e passare alla nuova licenza GNU AGPLv3. Questo si rese necessario per motivi di incompatibilit`a tra le varie licenze, in particolare tra la GNU AGPLv3 e la GNU GPLv2.

Come si pu`o notare, questa condizione obbliga a mostrare su ogni pagina dell’applicazione web un qualche mezzo, tipicamente un collegamento ipertestuale, per accedere al codice sorgente e 3

adozione da parte di aziende di software, e` quello di Google Code [10].

poterlo liberamente scaricare. Sempre nella sezione 13, viene sancita la possibilit`a di combinare assieme opere licenziate sotto GNU GPLv3 e AGPLv3. Tecnicamente quindi la licenza AGPLv3 non e` totalmente compatibile con la licenza GNU GPLv3, ovvero non e` possibile prendere del codice sotto GNU AGPL, modificarlo e distribuirlo sotto GNU GPLv3, o viceversa. Tuttavia e` compatibile in senso lato con la GPLv3, ovvero e` 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`a licenziato in parte sotto AGPLv3 ed in parte sotto GPLv3, secondo le regole dettate dalle due licenze. E’ importante poi ricordare che la licenza AGPLv3 non e` compatibile in alcun modo con la licenza GNU GPLv2. La licenza AGPLv3 inoltre e` una licenza strong copyleft, ovvero le clausole relative al copyleft sono efficacemente imposte su tutti i tipi di opere derivate. Non e` quindi possibile che la caratteristica copyleft vada persa in alcuna opera derivata, al contrario delle licenze weak copyleft dove il fatto che l’opera derivata sia soggetta o no alle clausole copyleft dipende dalla maniera in cui e` stata derivata. Per le caratteristiche descritte, la licenza AGPLv3 e` pertanto la scelta adatta per ogni applicazione open source che offre tipicamente dei servizi tramite una rete, in modo particolare tramite internet. Tale consiglio e` ribadito nel preambolo della stessa licenza: “The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.” [9] Bisogna per`o sottolineare come la AGPLv3 non sia ancora particolarmente diffusa, anche perch´e la sua introduzione e` piuttosto recente, infatti risale al 19 novembre 2007. Ciononostante e` stata gi`a adottata da alcune grandi aziende, seppur in numero molto esiguo.

5

Google Code e` un sito web, sviluppato e mantenuto da Google, che fornisce hosting per progetti open source. In altre parole Google Code permette, all’utente che si registra, di caricare il proprio progetto open source e di utilizzare alcuni strumenti che favoriscono lo sviluppo del progetto stesso, come ad esempio un sistema di versioning ed un wiki. Su Google Code e` possibile per`o utilizzare soltanto un ristretto numero di licenze per il proprio progetto, vale a dire: 1. Apache License 2.0 2. Artistic License/GPL 3. Eclipse Public License 1.0 4. GNU General Public License v2 5. GNU General Public License v3 6. GNU Lesser General Public License 7. MIT License 8. Mozilla Public License 1.1 9. New BSD License Come si pu`o notare, la licenza AGPL non e` contemplata all’interno di tale elenco, ovvero non e` possibile caricare codice licenziato sotto AGPL su Google Code. Numerosi utenti si sono quindi mossi per chiedere alla compagnia di introdurre la licenza AGPL per vari motivi, principalmente perch´e la ritenevano una licenza utile ed erano interessati ad usarla per i progetti da loro sviluppati. E’ nata quindi un’interessante discussione [1], nella quale Google sostiene di essere fortemente preoccupata riguardo al problema della proliferazione delle licenze aperte, che viene infatti giudicato dalla stessa comunit`a open source un problema piuttosto serio in grado di confondere gli utenti ed ostacolare la condivisione ed il riutilizzo del codice. In realt`a, la proliferazione delle licenze open source non e` un problema di per s`e, quanto piuttosto la complessit`a che si viene a creare su quali licenze

Google Code e la licenza AGPL

Un caso interessante, esaminato in questa sezione, per quanto riguarda la licenza AGPL e la relativa 4

the license to code.google.com. But that’s an absurdly high number. Until then, it’s gut feeling about popularity of the license.” [1] Le risposte di Di Bona per`o non hanno soddisfatto alcuni esponenti del movimento open source, i quali pongono l’interrogativo se Google rifiuta la licenza AGPL perch´e davvero vuole limitare la proliferazione delle licenze open source, oppure piuttosto perch´e tale licenza potrebbe risultare molto fastidiosa e dannosa da un punto di vista economico, e non solo, per i servizi che offre via web. Secondo la loro opinione, Google rifiuterebbe la AGPL perch´e la considera una vera e propria minaccia diretta al modo dell’azienda di fare business. E’ 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, Google dovrebbe 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 doveroso ricordare che Google e` anche uno dei maggiori sostenitori della comunit`a open source, sebbene in linea con i propri interessi. Inoltre, se da un lato e` comprensibile e degno di apprezzamento il voler limitare il numero di licenze disponibili, d’altra parte non si capisce perch´e escludere la AGPL che e` molto simile alla GPLv3 con l’unica differenza chiave che riguarda la diffusione via rete; inoltre e` stata redatta in modo da essere compatibile con le altre licenze, quindi non e` proprio una licenza completamente diversa dalle altre. Per questi motivi, dicono alcuni esperti, non si capisce perch´e Google non accetti subito la licenza AGPL. Interessante a questo proposito e` il parere di Marco Barulli, co-sviluppatore insieme a Giulio Cesare Solaroli di Clipperz [3], un’applicazione web open source che permette di salvare e gestire in modo totalmente anonimo e gratuito le proprie password online. Volendo rilasciare Clipperz in AGPL su Google Code, e` stato costretto a cambiare hosting per poter usufruire di tale licenza. Marco Barulli afferma: “Di certo Google ha rilasciato tanto codice e tanti strumenti alla comunit`a FLOSS. Ma mi pare di poter dire che ha sempre mantenuto il controllo su cosa, come e quando rilasciare. AGPL e` una licenza

siano compatibili con le altre. Nel caso infatti in cui uno sviluppatore cerchi di mettere insieme diverse componenti ognuna con licenza differente, diventa veramente complesso capire ed essere a conoscenza dei diritti legali del prodotto finale e in particolar modo se e` possibile rilasciare il software e sotto quale licenza, non essendo tutte le licenze open source compatibili fra loro. Per questo motivo, cio`e per limitare la proliferazione delle licenze open source, Google Code ha inizialmente permesso soltanto sette licenze per i progetti caricati sul sito, aggiungendo in un successivo momento due ulteriori licenze, ovvero la recente GNU GPLv3 e la Eclipse Public License 1.0. La strategia aziendale e` sempre stata quella quindi di limitare al massimo il numero di licenze possibili ed introdurne di nuove solamente dopo che si fossero verificati due requisiti fondamentali: • essere approvate dall’OSI; • essere risultato in modo evidente il loro utilizzo a livello popolare. Tuttavia tali motivazioni, a detta dei sostenitori della licenza AGPL, sono soltanto delle scuse per evitare o quantomeno ritardare l’accettazione della licenza. Infatti, nonostante la AGPLv3 sia stata approvata nel 2008 dall’OSI, Google non ha ritenuto di includerla non essendo evidente, a suo avviso, la diffusa adozione della licenza. Interpellato a rendere conto del limite secondo il quale la AGPL verrebbe considerata sufficientemente diffusa, Chris Di Bona, open source program manager di Google, ha risposto: “Basically the answer is when I, Fitz, Greg or the team think it is popular enough. I know you guys think we don’t like it for nefarious reasons, but what you’re missing is we dislike -all- new licenses that are unpopular.” [1] In tal modo ha ribadito cio`e il fatto che tale limite sia completamente soggettivo ed a discrezione sua e dei suoi colleghi. Nuovamente interpellato per fare pi`u chiarezza sul limite a cui Google inizierebbe a pensare alla diffusione della licenza AGPL, Di Bona ha spiegato: “If you want a firm number, then when AGPL passes BSD + Apache 2.0, I will unconditionally add 5

wiki Socialtext ed e` stata in seguito 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. La finalit`a della licenza CPAL e` quella di essere una licenza piuttosto generica, indicata per software distribuito attraverso una rete (SaaS). 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`o mostrare informazioni riguardo allo sviluppatore originale. Questo messaggio di informazioni specifica che “[...] each time an Executable and Source Code or a Larger Work is launched or run, a prominent display of the Original Developer’s Attribution Notice (as defined below) must occur on the graphic user interface (which may include display on a splash screen) [...]”. [17] Il requisito di attribuzione non deve comunque superare le dieci parole e deve essere mostrato soltanto all’avvio dell’applicazione e non su ogni schermata, come richiesto da altre licenze simili. Nel caso in cui non sia disponibile un’interfaccia grafica, il vincolo di mostrare il requisito di attribuzione viene a cadere. Nel caso specifico di Facebook, la licenza CPAL obbliga ad esporre il seguente messaggio:

dagli effetti “drastici” e non mi aspetto quindi che venga adottata da Google (o Yahoo, Facebook, ...). Non credo per`o che vi sia una vera ostilit`a perch´e comunque chi sviluppa software per il web ha sempre la strada del dual licensing, ovvero di avere versioni con licenza commerciale ed altre con licenza open. E se a Google interessa poter utilizzare codice AGPL senza rilasciare prodotti derivati con la medesima licenza penso che abbia la possibilit`a di aprire trattative con qualunque gruppo di sviluppatori che abbia scelto AGPL. (Google can you hear me? :-) ). Nel nostro caso abbiamo dovuto spostare il repository di Clipperz da Google Code a SourceForge in quanto AGPL non e` tra le licenze contemplate al momento. Google dichiara che sia una scelta mirata a combattere la proliferazione di licenze, ma non credo che Google possa accusare la FSF di aver inquinato l’ambiente pubblicando molte licenze. Anzi! AGPL sarebbe servita qualche anno fa!” [2] Nel frattempo, per ovviare alla mancanza della licenza AGPL su Google Code, vi e` stato anche chi ha scelto pubblicamente una licenza tra le nove disponibili, salvo poi inserire nel codice sorgente la licenza AGPL: questo comportamento non ha fatto altro che aumentare la confusione sui diritti legali in possesso dell’utente ed e` stato quindi sanzionato dall’azienda con l’allontanamento dal servizio, la quale ha invitato gli utenti in questione a caricare i loro progetti, licenziati sotto AGPL, su altri siti quali SourceForge.net [14] e Savannah [13].

6

c 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

Facebook e la licenza CPAL

Facebook ha rilasciato recentemente una parte del suo codice sotto licenza open source. Tale piattaforma e` denominata Facebook Open Platform ed e` “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 e` stata la Common Public Attribution License (CPAL) [17]: questa e` una licenza free software che e` stata inizialmente sviluppata dall’azienda di social enterprise

Nonostante questo possa sembrare ragionevole per riconoscere il lavoro svolto dagli sviluppatori di Facebook, non si pu`o fare a meno di notare che e` 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`a gratuita a Facebook, magari proprio perch´e loro rivali. In secondo luogo, l’ulteriore differenza tra la li6

cenza MPL e la licenza CPAL e` nella sezione “15. ADDITIONAL TERM: NETWORK USE.” [17], che serve a tutelarsi dal famoso ASP loophole. Tale clausola recita: “The term “External Deployment” means the use, distribution, or communication of the Original Code or Modifications in any way such that the Original Code or Modifications may be used by anyone other than You, whether those works are distributed or communicated to those persons or made available as an application intended for use over a network. [...]” [17] 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 e` il fatto che, essendo basata sulla licenza MPL, non e` compatibile con la licenza GNU GPL. Inoltre Facebook non si e` avvalsa delle clausole della licenza CPAL relative alla possibilit`a di doppia licenza, il cosiddetto dual licensing model, utilizzato per esempio dalla compagnia ExtJS come vedremo in seguito, implicando in tal modo che ogni pezzo di codice di Facebook licenziato sotto CPAL non pu`o essere legalmente usato insieme a codice sotto GNU GPL. Infine chiunque volesse usare il codice di Facebook come parte di un’applicazione web preesistente, dovrebbe rilasciare anche il codice sorgente di tale programma.

6.1

to” si intende che, poich´e alcune licenze badgeware (ma non la CPAL) impongono che in ogni pagina dell’applicazione sia mostrato il logo e le clausole dello sviluppatore originale, lo spazio che rimane a disposizione e` molto esiguo. Per quanto riguarda la licenza CPAL, il logo dello sviluppatore non pu`o essere rimosso, pena violazione della licenza, n´e rimpicciolito od oscurato in alcun modo. Al contrario di altre licenze badgeware simili per`o, la CPAL impone soltanto che il logo sia visibile all’avvio dell’applicazione e non su ogni pagina dell’applicazione stessa. In quest’ultimo caso per`o – secondo coloro schierati contro le licenze badgeware – appare evidente che aggiungendo un proprio logo non rimarrebbe pi`u spazio per l’applicazione. Il rischio e` 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`a per scoprire se questi incubi nel mercato sono realmente veri.” [19] 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 e` usato solamente all’interno dell’azienda, e questo non e` ben visto da molti sviluppatori. Il problema quindi non e` discutere se e quanto la licenza CPAL sia open source, e di fatto lo e` in quanto e` stata approvata dalla OSI, ma e` relativo alla possibilit`a 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 obblighi loro a mostrare un logo di Facebook al caricamento del sito web. Tutto questo quindi appare controproduttivo se gli intenti sono in linea con i principi alla base dell’open source, poich´e di fatto scoraggia altri network dall’adottare e diffondere questa piattaforma. Dall’altra parte i sostenitori della licenza CPAL dicono che non e` “n´e buona n´e cattiva, ma e` [cos`ı] come e` ” [4], 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 e` molto positivo che Facebook abbia rilasciato gran parte del proprio codice con una licenza open source che

Critiche alla licenza CPAL

La licenza CPAL e` stata fortemente criticata da molti sviluppatori e marcata addirittura come “falsa licenza open source”. Questo perch´e 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, cio`e il criterio di attribuzione, e` fortemente correlata alla possibilit`a, di fatto proibita, di fare fork di applicazioni licenziate in questo modo, nonostante questo sia un diritto fondamentale del software open source. Con “proibire di fat7

re in cambio del prodotto sotto licenza proprietaria un certo corrispettivo di denaro. Si vengono cos`ı a creare due diversi gruppi interessati al prodotto: da una parte gli utenti comuni, che beneficiano del prodotto offerto gratuitamente sotto licenza open source, dall’altra parte le aziende commerciali che comprano la licenza proprietaria al fine di modificare il software secondo i propri scopi, per esempio incorporandolo con gli strumenti gi`a esistenti all’interno della propria azienda, e senza dover rilasciare il codice sorgente modificato o sottostare a clausole non gradite. Queste aziende non intendono rilasciare il codice sorgente principalmente per ragioni di competizione con altre aziende rivali, mantenendolo quindi segreto. Tra le modifiche infatti che vengono spesso effettuate si contano cambiamenti all’interfaccia grafica, per esempio per utilizzare i propri trademarks; cambiamenti volti ad implementare protocolli di sicurezza segreti o di crittazione dei dati; cambiamenti volti all’integrazione di servizi utilizzati e strumenti esistenti all’interno dell’azienda stessa, sui quali vi sono tra le altre cose problemi di compatibilit`a con altre licenze qualora siano sviluppati, come spesso avviene, da altre aziende. Il modello dual licensing e` particolarmente interessante perch´e permette di aiutare sia la comunit`a del software libero sia le compagnie commerciali. La caratteristica infatti di rilasciare il codice sotto licenza open source permette di godere delle modifiche effettuate dalla comunit`a; il ricavato della vendita delle licenze proprietarie aiuta a finanziare il progetto stesso. Vi sono tuttavia altri metodi utilizzati dalle aziende produttrici di software open source per effettuare guadagni. Questi includono la fornitura di servizi quali l’installazione, la personalizzazione, il supporto e l’assistenza del prodotto open source.

chiunque pu`o prendere ed usare liberamente, e questo e` 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 e` interessante riportare qui il parere di Chris Di Bona, 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.” [19] Questo per dire che nel caso di un’ampia diffusione di codice protetto da licenza CPAL, Google lo svilupper`a da s´e, invece di usare del codice gi`a esistente, per non incorrere in clausole non gradite.

7

Il modello dual licensing

Le licenze fin qui trattate, vale a dire la licenza AGPL e la licenza CPAL, potrebbero dissuadere alcune compagnie dall’adottare software rilasciato secondo queste regole in quanto sarebbero costrette, per esempio, a rilasciare i sorgenti modificati. Inoltre, le aziende che rilasciano un prodotto come software libero, spesso trovano difficile realizzare un profitto, se non attraverso consulenze o soluzioni ad hoc realizzate per utenti con particolari esigenze. Per questi motivi e non solo, da alcuni anni si sta diffondendo un nuovo modello di business all’interno delle compagnie che producono software: il cosiddetto modello dual licensing. Con dual licensing si intende la consuetudine secondo la quale il prodotto software e` licenziato in due modi differenti. Questo significa, come avviene nella maggior parte dei casi, due diverse licenze. L’utente pu`o quindi scegliere quale delle due licenze adottare, a seconda delle proprie esigenze di uso e di distribuzione del software. Generalmente, le due licenze adottate sono di due tipi diversi: la prima e` una licenza proprietaria, che permette quindi di creare opere derivate con codice a sorgente chiuso, mentre la seconda e` una licenza open source, tipicamente strong copyleft, che obbliga quindi a rilasciare l’opera derivata alle stesse condizioni alle quali e` soggetta. L’azienda che sviluppa il prodotto software, ovvero la detentrice del copyright, e` solita fornire il prodotto sotto licenza open source gratuitamente, mentre e` solita chiede-

7.1

Un esempio di dual licensing: ExtJS

Vi sono numerose compagnie che hanno adottato il modello dual licensing, le pi`u famose delle quali sono MySQL e Mozilla Firefox. In questa sezione e` analizzato il caso di ExtJS [7], una libreria JavaScript cross-browser che permette di realizzare pagine web dinamiche.

8

for those sections on the same medium and under the same FLOSS license as the corresponding object code or executable forms of those sections, and

ExtJS offre due licenze diverse per scopi differenti: sviluppo commerciale oppure open source. La licenza commerciale e` indicata per l’utente che ha intenzione di sviluppare un’applicazione proprietaria e non vuole distribuire e condividere il codice sotto licenza GPL. Per fare questo, lo sviluppatore deve comprare un adeguato numero di licenze commerciali da Ext: ogni licenza e` infatti valida per un solo sviluppatore. Inoltre la licenza include tutti gli aggiornamenti delle revisioni minori (per esempio, acquistando una licenza 2.0 si ha diritto a tutti gli aggiornamenti inclusi 2.0, 2.1, e cos`ı via), e` royalty-free e non sancisce alcun obbligo di rilasciare il codice sorgente sotto licenza GPL. La licenza open source utilizzata da ExtJS e` la nota GNU General Public License v3. Pertanto chiunque volesse creare un’applicazione open source e rilasciarla con una licenza compatibile con la GPLv3, pu`o utilizzare tale licenza open source per la libreria ExtJS. Infine ExtJS ha previsto anche la possibilit`a di utilizzare la propria libreria in progetti open source che sottostanno a una licenza diversa dalla GPLv3. Per fare ci`o, sono state create delle eccezioni ad hoc per lo sviluppo di applicazioni e di estensioni. Nel caso delle applicazioni, tali eccezioni [5] sono state concepite per permettere di sviluppare software open source che utilizza la libreria Ext nel caso in cui si utilizzi una licenza non compatibile con la GPLv3. Tali condizioni impongono che:

3. any works which are aggregated with the Library or with a Derivative Work on a volume of a storage or distribution medium in accordance with the GPL, can reasonably be considered independent and separate works in themselves which are not derivatives of either the Library, a Derivative Work or a FLOSS Work. 4. the Derivative Work can reasonably be considered independent and separate work that is intended for use by end-users and not as a library for software development purposes.” [5] E’ quindi possibile combinare assieme prodotti software rilasciati sotto diverse licenze open source (purch´e nella lista specificata [5]) con la libreria Ext, purch´e l’opera derivata sia rilasciata sotto GNU GPLv3. Similmente sono presenti altre eccezioni [6] per fare in modo che uno sviluppatore possa realizzare estensioni, toolkits, framework, traduzioni e temi grafici per la libreria Ext e distribuirli sotto una licenza meno restrittiva della GPLv3 tra quelle specificate [6], nonostante la licenza GPLv3 obblighi appunto a distribuire l’opera derivata sotto la stessa licenza.

1. “You obey the GPL in all respects for the Library and the Derivative Work, except for identifiable sections of the Derivative Work which are not derived from the Library, and which can reasonably be considered independent and separate works in themselves

Riferimenti bibliografici [1] Agpl license - hosting at google code. http://groups.google.com/ group/google-code-hosting/browse_ thread/thread/1714c5c0ef5d9f9f/ 7d59a938d295bb8f.

2. all identifiable sections of the Derivative Work which are not derived from the Library, and which can reasonably be considered independent and separate works in themselves,

[2] Agpl: quando l’open source si fa 2.0. http: //www.webnews.it/news/leggi/8829/ agpl-quando-lopen-source-si-fa-20/ 3.

are distributed subject to one of the FLOSS licenses listed below, and

[3] Clipperz online password manager. http:// www.clipperz.com/.

the object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code

[4] Cpal? what’s that? http://ostatic.com/ blog/cpal-whats-that. 9

[5] Ext - open source license exception for applications. http://extjs.com/products/ floss-exception.php. [6] Ext - open source license exception for development. http://extjs.com/products/ ux-exception.php. [7] Extjs. http://extjs.com. [8] Free software foundation. fsf.org/.

http://www.

[9] Gnu affero general public license, free software foundation. [10] Google code. http://code.google.com/. [11] Open source initiative. opensource.org/.

http://www.

[12] Open source licenses are obsolete - o’really radar. http://radar. oreilly.com/archives/2006/08/ open-source-licenses-are-obsol. html.

[13] Savannah. http://savannah.gnu.org/. [14] Sourceforge.net: Find and build open source software. http://sourceforge.net/. [15] Affero general public license v1, affero inc., marzo 2002. http://www.affero.org/ oagpl.html. [16] Affero general public license v2, affero inc., novembre 2007. http://www.affero. org/agpl2.html. [17] Common public attribution license version 1.0 (cpal), open source initiative, marzo 2009. http://opensource.org/ licenses/cpal_1.0. [18] Facebook developers, facebook open platform, 3 marzo 2009. http://developers. facebook.com/fbopen/. [19] Osi approves badgeware license, the register, marzo 2009. http://www.theregister. co.uk/2007/07/25/osi_socialtext_ cpla.

10