L'utente tipico di computer possiede una discreta quantità di software che ha com prato nel tempo e che ormai non adopera più. Magari ha aggiornato il computer, o ha cambiato marca, e i vecchi programmi hanno smesso di funzionare. Magari il software è diventato obsoleto. O semplicemente il programma non lo soddisfa. For se ha comprato due o più computer e non vuole pagare per una seconda copia del software. Quale che sia la ragione, il software per cui ha pagato anni fa non è più adeguato. Tutto questo è inevitabile? Non sarebbe bello avere diritto a un aggiornamento gratuito ogni volta che il software lo richiede? Se, passando da un Mac a un PC, si potesse cambiare la versio ne del software gratis? Se, quando il software non funziona o non è abbastanza potente, si potesse migliorarlo o perfino ripararlo da soli? Se il software continuasse a essere supportato anche quando l'azienda produttrice abbia cessato l'attività? Non sarebbe bello usare il software sulla stazione di lavoro, sul computer di casa e sul por tatile, anziché su un solo computer? È probabile che, in quel caso, si starebbe anco ra usando il software pagato anni prima. Questi sono alcuni dei diritti che l'Open Source riconosce.
La Open Source Definition è una carta dei diritti dell'utente di computer. Definisce certi diritti che una licenza software deve garantire per poter essere certificata come Open Source. I produttori che non rendono Open Source il loro programmi trova no difficile competere con chi lo fa, dal momento che gli utenti imparano ad apprez zare quei diritti che avrebbero dovuto sempre essere loro. Programmi come il siste ma operativo Linux e il browser Web Netscape sono diventati popolarissimi, scal zando altro software sottoposto a licenze più restrittive. Aziende che usano software Open Source godono il vantaggio del suo rapidissimo sviluppo, spesso a opera coo perativa di numerose aziende, e in gran parte fornito da soggetti individuali che ope rano migliorie sulla base di proprie necessità.
I volontari che hanno reso possibili prodotti come Linux ci sono, e le aziende posso no cooperare, solo grazie ai diritti che vengono con l'Open Source. Il programmato re medio si sentirebbe stupido nel riversare tanto lavoro in un programma per vedere poi le sue migliorie vendute dal proprietario senza che lui ne riceva alcun ritor no. Quegli stessi programmatori contribuiscono volentieri all'Open Source perché esso assicura loro questi diritti: o il diritto di fare copie del programma e di distribuirle; o il diritto d'accesso al codice sorgente del software, condizione necessaria per poterlo modificare; o il diritto di apportare migliorie al programma. Questi diritti sono importanti per coloro che collaborano a un software perché li mantengono tutti al medesimo livello. Chiunque lo voglia è libero di vendere un programma Open Source, così i prezzi rimarranno bassi e sarà rapido lo sviluppo per raggiungere nuovi mercati. Chiunque investa il suo tempo a costruire conoscenza in un programma Open Source lo può supportare, e questo permette agli utenti l'op zione di fornire a loro volta il loro supporto, o l'economia dovuta a un gran numero di fornitori di supporto concorrenti. Qualunque programmatore può adattare un programma Open Source a misura di mercati specifici per raggiungere clienti nuo vi. Chi lo fa non è costretto a pagare diritti o concessioni di licenza. La ragione per il successo di una strategia che può suonare alquanto comunista pro prio nel momento in cui il fallimento del comunismo stesso è visibile ovunque, è nel fatto che l'economia dell'informazione è sostanzialmente diversa da quella degli altri prodotti. I costi della copia di un'informazione come un programma software è infinitesimo. L'elettricità non costa quasi nulla, l'uso dell'attrezzatura poco di più. È come, per fare un paragone, se si duplicasse una pagnotta usando un solo etto di farina.  

La storia Il concetto di free software non è nuovo. Quando le università cominciarono ad adot tare i computer, essi erano strumenti per la ricerca. Il software veniva scambiato libe ramente e i programmatori venivano pagati per l'atto della programmazione, non per i programmi in sé. Solo più tardi, quando il mondo degli affari e del commer cio adottò i computer, i programmatori cominciarono a mantenersi limitando i diritti d'uso del loro software e facendosi pagare per ogni copia. Il free software come idea politica è stato reso popolare da Richard Stallman dal 1984, allorché formò la Free Software Foundation e il progetto GNU a essa collegato. La premessa di Stall man è che la gente dovrebbe avere più libertà e dovrebbe imparare ad apprezzarla. Egli progettò un insieme di diritti che sentiva necessari a ogni utente e li codificò nella GNU Public License o GPL. Stallman battezzò scherzosamente la sua licenza copyleft in quanto lasciava intatto il diritto alla copia. Stallman stesso sviluppò lavo ri fondamentali di free software quali il compilatore C GNU e GNU Emacs, un editor di testo che alcuni hanno trovato così seducente da concepirne quasi un culto. Il suo lavoro ispirò molti altri a fornire free software sotto la GPL. Per quanto non pro mossa con il medesimo fervore libertario, la Open Source Definition include molte delle idee di Stailman, e può ben considerarsi un derivato della sua opera.

La Open Source Definition cominciò la sua vita come un documento di linea di con dotta della distribuzione Debian GNU/Linux. Debian, uno dei primi sistemi Linux, tuttora popolare, fu costruito interamente con free software. Tuttavia, dal momento che c'erano altre licenze oltre al copyleft che comportavano la gratuità, Debian ebbe qualche problema nel definire che cosa fosse gratis, e i produttori non resero mai chiara la loro politica di free software al resto del mondo. All'epoca, trovandomi a capo del progetto Debian, affrontai questi problemi proponendo un Contratto Socia le Debian e la Guida Debian del Free Software, nel luglio del 1997. Molti svilup patori Debian inviarono critiche e miglioramenti che io incorporai nei documenti. Il Contratto Sociale documentava l'intenzione di Debian di costituire il proprio sistema interamente con free software, e la Guida rendeva facilmente possibile la classificazione del software come free software o meno, confrontando la licenza software con la guida stessa. La Guida Debian oggetto di molte lodi nella comunità del free software, special mente fra gli sviluppatori Linux, che a quel tempo stavano preparando la loro pro pria rivoluzione software sviluppando il primo vero sistema operativo gratuito. Quando Netscape decise di rendere libero il suo browser Web, contattò Eric Ray mond. Raymond, la Margaret Mead del free software, è autore di numerosi articoli di taglio antropologico che illustrano il fenomeno del free software e la cultura che vi è cresciuta intorno: scritti che furono i primi di un genere e che hanno messo sot to la luce dei riflettori questo fenomeno fino ad allora oscuro. La dirigenza di Net scape rimase suggestionata in particolare dal saggio di Raymond "La cattedrale e il bazaar", la cronaca di uno sviluppo free software coronato da successo con volontari non pagati, e gli chiese una consulenza, sotto patto di riservatezza, mentre svilup pavano una licenza per il loro free software. Raymond insisté che la licenza di Net scape dovesse adeguarsi alla guida Debian per poter essere presa sul serio come free software. Raymond e io ci eravamo incontrati qualche volta all'Hacker Conference, una radu no su invito di programmatori creativi e non convenzionali. Avevamo corrisposto via email su vari argomenti. Mi contattò nel febbraio del 1997 con l'idea per l'Open Source. Raymond temeva che la mentalità conservatrice dell'ambiente degli affari venisse scoraggiata dal grado di libertà di Stallman, che era al contrario popolarissi mo fra i programmatori di mentalità più liberale. Era impressione di Raymond che ciò stesse sclerotizzando lo sviluppo di Linux nel mondo business laddove esso fio riva invece nell'ambiente della ricerca. Raymond ebbe incontri con uomini d'affari nell'industria Linux che stava muovendo solo allora i primi passi; insieme, essi concepirono un programma di marketing del free software indirizzato ai colletti bian chi. Furono coinvolti Larry Augustin di VA Research e Sam Ockman (che abban donò più tardi VA per formare Penguin Computing), nonché altri non di mia cono scenza. Alcuni mesi prima dell'Open Source, avevo elaborato l'idea dell'Open Hardware, concetto simile rivolto agli strumenti hardware e alle loro interfacce anziché ai pro grammi software. A tutt'oggi l'Open Hardware non ha avuto il successo dell'Open Source, ma il progetto è ancora attivo; se ne può sapere di più a http://www.openhardware.org. Secondo Raymond, la Guida Debian era il documento più adatto a definire l'Open Source, ma serviva una denominazione più generale e la rimozione dei riferimenti specifici a Debian. Modificai la Guida Debian fino a ricavarne la Open Source Defi nition. Avevo formato per Debian un ente chiamato Software in the Public Intere st, e mi offrii di registrare un marchio per Open Source in modo da poter associare il suo uso alla definizione. Raymond acconsent'i, e io registrai una certificazione (una forma speciale di marchio che potesse applicarsi secondo i termini ai prodotti altrui). Circa un mese dopo la registrazione del marchio, apparve chiaro che Software in the Public Interest avrebbe potuto non essere la dimora migliore per il marchio Open Source, e trasferii dunque la proprietà del marchio a Raymond. Raymond e io abbia mo da allora formato la Open Source Initiative, un'organizzazione esclusivamente destinata alla gestione della campagna Open Source e della sua certificazione di mar chio. Mentre scrivo, l'iniziativa Open Source è retta da un comitato di sei compo nenti scelti fra fornitori di free software di chiara fama, e sta cercando di espandere il suo comitato fino a una decina di persone. Al momento del suo concepimento, la campagna Open Source fu oggetto di molte critiche perfino da parte del contingente Linux che già aveva approvato il concetto di free software. Molti rilevarono che il termine Open Source era già in uso nel ramo della raccolta di dati per le campagne politiche. Altri pensarono che il termine Open fosse già usurato. Per altri ancora era preferibile il nome Free Software, già consoli dato. Io opinai che l'abuso del termine Open sarebbe stato sempre meglio dell'am biguità di free nella lingua inglese, in cui sta a significare tanto libero quanto gra tuito, la seconda accezione essendo di gran lunga la più comune nel mondo del com mercio di computer e di software. Più tardi, Richard Stallman obiettò alla mancan za di enfasi sulla libertà che secondo lui la campagna dimostrava, e al fatto che, men tre l'Open Source acquistava popolarità, il suo ruolo nella genesi del free software, e quello della sua Free Software Foundation, venivano ignorati: si lamentò di essere stato "cassato dalla storia". Peggiorò la situazione la tendenza degli operatori del set tore di contrapporre Raymond a Stailman, quasi essi proponessero filosofie concor renti anziché, sia pur con metodi diversi, propagandare lo stesso concetto. Io stesso contribuii probabilmente a esacerbare gli animi mettendo Stallman e Raymond l'uno contro l'altro in dibattiti pubblici alla Linux Expo e alla Open Source Expo. Caratterizzare i due come avversari diventò un'attività tanto consueta che una discussione via email, non destinata alla pubblicazione, apparve sul periodico on line Salon. A quel punto, chiesi a Raymond di moderare i toni di un dialogo in cui, per la verità, egli non aveva mai inteso entrare. Quando la Open Source Definition fu scritta, esisteva già un gran numero di pro dotti che potevano rientrare nella categoria. Il problema erano quei programmi che non vi rientravano, e che pure gli utenti trovavano irresistibili.  

KDE, Qt e Troil Tech Il caso di KDE, Qt e Troil Tech è pertinente a questo saggio perché il gruppo KDE e Troil Tech cercarono di porre un prodotto non-Open Source entro l'infrastruttu ra di Linux, incontrando una resistenza inattesa. Le grida di pubblico scandalo e la minaccia che il loro prodotto venisse rimpiazzato da un altro, completamente Open Source, convinse alla fine Troli Tech a convertirsi a una licenza pienamente Open Source. È un segno interessante dell'accoglienza entusiastica riservata dalla comu nità alla Open Source Definition il fatto che Troll dovette adeguare la propria licen za, pena l'insuccesso del suo prodotto. KDE fu il primo esperimento di un desktop grafico gratuito per Linux. Le appli cazioni KDE erano esse stesse sotto GPL, ma dipendevano da una libreria grafica proprietaria nota come Qt, di Troil Tech. I termini della licenza di Qt ne proibi vano la modifica o l'uso con qualunque display software che non fosse il senescen te X Window System. Ogni uso diverso richiedeva allo sviluppatore una licenza del costo di 1500 dollari. Troll Tech fornì versioni di Qt per Windows di Microsoft e per Macintosh, e questa fu la sua principale fonte d'entrate. La licenza pseudo-gra tuita per i sistemi X intendeva indirizzare i contributi degli sviluppatori Linux ver so demo, esempi e accessori per i loro costosi prodotti Windows e Mac. Per quanto i problemi della licenza di Qt apparissero evidenti, la prospettiva di un desktop grafico per Linux era così attraente che molti utenti furono disposti a chiu dere un occhio sulla sua natura non-Open Source. I promotori di Open Source tro varono che KDE fosse in difetto perché avevano l'impressione che gli sviluppatori stessero cercando di confondere la definizione di free software allo scopo di inclu dervi elementi solo parzialmente gratuiti, come Qt. Gli sviluppatori KDE replica rono che i loro programmi erano Open Source, anche se non esistevano versioni ese guibili di quei programmi che non richiedessero una libreria non-Open Source. Io e altri sostenemmo che le applicazioni KDE non erano che frammenti Open Sour ce di programmi non-Open Source, e che una versione Open Source di Qt sarebbe stata necessaria prima che ci si potesse riferire a KDE come a un Open Source. Gli sviluppatori KDE tentarono di risolvere parzialmente il problema della licenza di Qt negoziando con Troli Tech un accordo (KDE Free Qt Foundation) in cui Troil e KDE avrebbero congiuntamente controllato i rilasci delle versioni gratuite di Qt, e Troli Tech avrebbe rilasciato Qt sotto una licenza conforme a Open Source nel caso che l'azienda venisse acquisita o cessasse l'attività. Un altro gruppo diede inizio al progetto GNOME, un concorrente interamente Open Source di KDE che mirava a fornire maggiori funzioni e sofisticazioni; un gruppo separato avviò il progetto Harmony per produrre un clone di Qt completa mente Open Source che avrebbe supportato KDE. Mentre le dimostrazioni di GNOME avvenivano fra il plauso e Harmony stava per diventare usabile, Trol! Tech capì che QT non avrebbe riscosso successo nel mondo Linux se non avesse cambia to licenza. Troll Tech rilasciò dunque una licenza interamente Open Source per Qt, disinnescando il conflitto ed eliminando i motivi alla base del progetto Harmony. Il progetto GNOME continua tuttora, volto adesso a un KDE migliore in termini di funzionalità e di raffinatezza piuttosto che in termini di licenza. Prima di rilasciare la sua nuova licenza Open Source, Troll Tech me ne fece avere copia perché la verificassi, con la preghiera che rimanesse riservata finché non fosse ro in grado di annunciarla. Nel mio entusiasmo di far pace con il gruppo KDE e in un imbarazzante gesto di autoinganno, preannunciai con Otto ore di anticipo la licenza su una mailing list KDE. Quell'email, per il mio rimorso, fu raccolta imme diatamente da SlashdDt e da altre riviste online. La nuova licenza Troll Tech è notevole perché approfitta di una scappatoia nella Open Source Definition che permette ai file patch di essere trattati diversamente dall'altro software. Vorrei provvedere a chiudere questa scappatoia in una revisione a venire della Open Source Definition, ma il nuovo testo non dovrebbe tuttavia col locare Qt al di fuori dell'Open Source. Al momento in cui scrivo, i promotori di Open Source stanno crescendo in misura esponenziale. I recenti contributi Open Source di IBM e di Ericsson hanno fatto i titoli dei giornali. Due distribuzioni Linux, Yggdrasil e Debian, stanno rilasciando distribuzioni di sistemi Linux completi, ivi incluse molte applicazioni che sono inte ramente Open Source; e molte altre, fra cui Red Hat, ci sono assai vicine. Quando il sistema GNOME sarà completo, sarà stato realizzato un sistema operativo con desktop GUI Open Source in grado di competere con Microsoft NT Analisi della Open Source Definition Questa sezione presenta nella sua interezza il testo della Open Source Definition, corredata di commenti (in corsivo). La versione canonica della Open Source Defini tion si trova a http://www.opensource.org/osd.htm1. Alcuni pedanti hanno voluto trovare delle ambiguità di poco conto nella Open Source Definition. Mi sono astenuto da rivederla dal momento che ha poco più d'un anno di vita e vorrei che il pubblico la considerasse stabile. Il fl.ituro imporrà qual che adeguamento lessicale, ma quasi nessuna modifica allo scopo del documento.

La Open Source Definition Open Source non significa solo accesso al codice sorgente. I termini di distribuzio ne di un programma Open Source devono essere consoni ai criteri seguenti: Si noti che la Open Source Definition non è propriamente una licenza software. È una specifi ca di quanto è ammesso in una licenza software perché vi si possa riferire come a un'Open Sour ce. La Open Source Definition non è intesa per essere un documento di valore legale. L'inclu sione della Open Source Definition nelle licenze software, quale quella proposta per il Proget to di Documentazione di Linux, sembra suggerirmi la stesura di una versione più rigorosa che sia appropriata per quell'uso. Aifini dell'Open Source, devono applicarsi insieme tutti i termini che seguono, in tutti i casi. Per esempio, devono applicarsi alle versioni derivate di un programma così come al programma originale. Non è sufficiente applicarne alcune e non altre, e non è sufficiente se i termini non vengono applicati sistematicamente. Dopo aver dovuto affrontare delle interpretazioni partico larmente "semplici" della Open Source Definition, sono tentato di aggiungere: sto dicendo a voi! 1. Ridistribuzione libera La licenza non può impedire ad alcuna parte in causa la vendita o la cessione del software come componente di una distribuzione di software aggregato che con tenga programmi proveniente da sorgenti diverse, La licenza non può richiede re diritti o il pagamento di altre concessioni per tale vendita. Questo significa che potete fare tutte le copie che volete del software e venderle o cederle, e non dovete pagare nessuno per questo privilegio. L'espressione "distribuzione di software aggregato che contenga programmi provenienti da sorgenti diverse" era intesa a chiudere una scappatoia nella Licenza Artistica - una licen za piuttosto malfatta, a mio parere - escogitata in origine per il Peri. Oggi, quasi tutti i programmi che usano la Licenza Artistica sono disponibili anche sotto GPL Quella clau sola non è più necessaria e sarà probabilmente tolta da una futura versione della Open Source Definition. 2. Codice sorgente Il programma deve includere il codice sorgente e deve consentire la distribuzio ne tanto in codice sorgente che in forma compilata. I.addove una qualunque for ma del prodotto non sia distribuita corredata del codice sorgente, devono essere disponibili mezzi ben pubblicizzati per scaricare il codice sorgente, senza costi addizionali, via Internet. Il codice sorgente deve essere la forma preferenziale nella quale un programmatore modifichi un programma. Codice deliberata mente offuscato non è ammesso. Forme intermedie quali l'output di un prepro cessore o di un traduttore non sono ammesse. Il codice sorgente è un preliminare necessario alla riparazione o alla modifica di un pro gramma. L'intento qui è che il codice sorgente sia distribuito con l'opera iniziale e con tut te le opere derivate. 3. Opere derivate La licenza deve permettere modifiche e opere derivate e deve consentire la loro distribuzione sotto i medesimi termini della licenza del software originale. Il software serve a poco se non se ne può fare la manutenzione (riparazione dei bug, por ting su nuovi sistemi, migliorie) e la modifica è indispensabile alla manutenzione. L'in tento è qui di permettere mod d'ogni sorta. Deve essere permessa la distribuzione di un'opera modificata sotto gli stessi termini di licenza dell'opera originale. Tuttavia, non è richiesto che ogni produttore di un'opera derivata debba usare gli stessi termini di licen za, ma solo che possa farlo qualora lo voglia. Diverse licenze si esprimono diversamente materia: la licenza BSD vi permette di mantenere private le modifiche, la GPL no. Alcuni autori di software ritengono che questa clausola possa consentire a persone prive di scrupoli di mod il loro software in maniera che possa causare imbarazzo all'autore originale. Quello che temono è che qualcuno possa deliberatamente provocare un malfun zionamento del software in modo che l'autore originale appaia un programmatore scaden te. Altri paventano un possibile uso criminale del software tramite l'aggiunta di funzio ni-cavallo di Troia o di tecnologie illegali in alcuni Paesi, come la crittograjìa. Tutti que sti atti, tuttavia, sono coperti dal codice penale. Un comune fraintendimento a proposito delle licenze è che esse debbano specificare ogni cosa, per esempio "questo software non va usato per compiere delitti". Dovrebbe tuttavia essere chiaro che nessuna licenza ha esisten za valida al di fuori del corpo del diritto civile e penale. Considerare una licenza come qualcosa separato dal corpo delle leggi applicabili è tanto sciocco quanto considerare un documento in lingua inglese separato dal vocabolario di quella lingua, un caso in cui nes suna parola avrebbe un significato definito. 4. Integrità del codice sorgente dell'autore La licenza può proibire che il codice sorgente venga distribuito in forma modi ficata solo se la licenza permette la distribuzione di "patch file" con il codice sor gente allo scopo di modificare il programma al momento della costruzione. Akuni autori temevano che altri potessero distribuire codice sorgente con modifiche che sarebbero state percepite come opera dell'autore originale e quindi avrebbero potuto gettare ombra su di lui. Questa clausola da loro un modo di imporre una separazione fra le modi fiche e la loro opera, senza proibire le prime. C'è chi considera antiestetico che le modifiche debbano veslir distribuite in un file "patch" separato dal codice sorgente, anche se distri buzioni Linux come Debian e Red Hat usano questa procedura per tutte le modifiche apportate ai programmi che distribuiscono. Esistono programmi per riversare automatica mente le patch nel sorgente principale, e questi programmi si possono eseguire automatica mente quando si scampatta un pacchetto di sorgente. Questa clausola, dunque, dovrebbe causare poca o nessuna d Si noti anche che questa dausola dice che, nel caso difilepatcb, la modifica avviene quan do si fa il build del programma. Questa scappatoia è impiegata nella Licenza Pubblica di Qt per prescri vere una diversa, anche se meno restrittiva, licenza per i file patch, in con traddizione con la sezione 3 della Open Source Definition. C'è una proposta per chiudere questa scappatoia nella definizione e mantenere nello stesso tempo Qt entro i confini del l'Open Source. La licenza deve permettere esplicitamente la distribuzione di software costruito da codice sorgente modificato. La licenza può richiedere che le opere derivate vadano sotto nome o numero di versione differenti da quelli del software origi nale. Questo significa che Netscape, per esempio, può insistere per poter essa sola chiamare una versione de/programma Netscape Navigator (tm), mentre tutte le versioni gratuite del pro gramma debbano chiamarsi Mozilla o in altro modo. 5. Nessuna discriminazione contro persone o gruppi La licenza non deve discriminare alcuna persona o gruppo di persone. Una licenza fornita dai Rettori dell'Università della Caliornia a Berkeley proibiva l'u so di un programma di progettazione elettronica da parte delle forze di polizia del Sud Africa. Apprezzato come merita questo sentimento in tempi di apartheid, va detto che esso non ha più senso oggi. Alcune persone si trovano ancora con software acquistato sotto quel la licenza, e le loro versioni derivate devono portare la stessa restrizione. Le licenze Open Source non devono contenere tale clausola, indipendentemente dalla nobiltà dell'intento. 6. Nessuna discriminazione di settori. La licenza non deve proibire ad alcuno l'uso del programma in uno specifico campo o per un determinato proposito. Per esempio, non può impedire che il programma venga usato a scopi commerciali o nella ricerca genetica. Il software dev'essere impiegabile allo stesso modo in una dinica che pratichi aborti e in un'organizzazione antiabortista. Queste discussioni politiche sono di pertinenza del Con gresso degli Stati Uniti, non delle licenze del software. Alcuni trovano questa mancanza di discernimento gravemente offensiva! 7. Distribuzione della licenza I diritti relativi al programma devono applicarsi a tutti coloro ai quali il pro gramma sia ridistribuito, senza necessità di esecuzione di una licenza aggiunti va da parte di questi. La licenza a!ev'ersere au senza la richiesta di alcuna firma. Purtroppo, negli Sta ti Uniti non ci sono dati validi precedenti giudiziari del potere della licenza senza firma quandò questa venga passata da una seconda a una terza parte. Tuttavia, questo argo mento considera la licenza come facente parte della legge sul contratto, mentre qualcuno obietta che d4 essere considerata come legge di copyright, campo in cui si danno più precedenti per quel tipo di licenza. Un buon precedente ci sarà senz'altro nei prossimi anni, data la popolarità del questa licenza e il boom dell'Open Source. 8. La licenza non dev'essere specifica a un prodotto. I diritti relativi a un programma non devono dipendere dall'essere il program ma parte di una particolare distribuzione software. Se il programma è estratto da quella distribuzione e usato o distribuito entro i termini della licenza del pro gramma stesso, tutte le parti a cui il programma sia ridistribuito dovrebbero avere gli stessi diritti che vengono garantiti in unione alla distribuzione softwa re originale. Questo significa che non si può impedire a un prodotto identificato come Open Source di esse re gratuito solo se lo si usa con una marca particolare di distribuzione Linux, ecc. Deve rimanere gratuito se anche lo si separa dalla distribuzione software da cui proviene. 9. La licenza non deve contaminare altro software La licenza non deve porre restrizioni ad altro software che sia distribuito insie me a quello licenziato. Per esempio, la licenza non deve pretendere che tutti gli altrì programmi distribuiti sullo stesso media siano software Open Source. Una versione di GhostScript (programma di rendering PostScript) richiede che i media sui quali viene distribuito contengano solo programmi software gratuiti. Questo non è consen tito dalla licenza Open Source. Per fortuna, l'autore di GhostScript distribuisce un'altra versione del programma (un p0' più vecchia) sotto una licenza Open Source genuina. Si noti che c'è d fra derivazione e aggregazione. Derivazione è quande un pro gramma incorpora di fatto in sé parti di un altro programma. Aggregazione è quando due programmi vengono inclusi sullo stesso CD-ROM. Questa sezione della Open Source DeJì nition riguarda l'aggregazione, non la derivazione. La sezione 4 riguarda la derivazione. 10. Licenze esemplari Le licenze GNU GPL, BSD, X Consortium e Artistica sono esempi di licenze da considerarsi conformi alla Open Source Definition. Altrettanto dicasi della MPL. Questo sarebbe una fonte di guai nel giorno in cui una di queste licenze si modificasse e non fosse più Open Source: dovremmo pubblicare immediatamente una revisione della OpenSource Definiton. Ciò è pertinente per la verità al testo esplicativo, non alla Open Source DeJìnition in sé Analisi delle licenze e loro conformità all'Open Source

Per comprendere la Open Source Definition dobbiamo esaminare alcune pratiche comuni nelle licenze in quanto si riferiscono all'Open Source. Public Domain La diffusa convinzione che molto del free software sia di dominio pubblico è errata. Ciò avviene perché l'idea di free software o Open Source confonde molti, che quin di definiscono erroneamente questi programmi come di pubblico dominio perché è il concetto più prossimo a quanto è loro familiare. I programmi, tuttavia, sono mol to chiaramente protetti da diritti e sottoposti a licenza: solo, si tratta di una licenza che dà al pubblico più diritti di quelli a cui sia abituato. Un programma di pubblico dominio è un programma sul quale l'autore abbia rinunciato a tutti di suoi diritti di copyright. Non si può esattamente dire che sia dotato di una licenza; è proprietà personale, per usarlo come meglio si crede. Dal momento che si può trattarlo come personale proprietà, con un programma di pub blico dominio si può fare quello che si vuole. Si può perfino ri-licenziare un pro gramma di pubblico dominio, rimuovendo quella versione dal pubblico dominio, o togliendo il nome del suo autore e trattarlo come opera propria. Se si sta spendendo molto lavoro su un programma di pubblico dominio, si consi deri la possibilità di applicarvi il proprio copyright e di rimetterlo sotto licenza. Per esempio, se non si desidera che una terza parte operi delle modifiche che possa poi mantenere riservate, si applichi la GPL o una licenza simile alla propria versione del programma. La versione da cui si è partiti rimarrà nel pubblico dominio, ma la pro pria versione sarà sotto una licenza che dovrà essere osservata da chi la usa o ne deri vi altre. Un programma di pubblico dominio si rende privato facilmente, dichiarando un copyright e applicandovi la propria licenza, oppure semplicemente dichiarando "Tutti i diritti riservati". Le licenze Free Software in generale Se si ha una raccolta di free software come un disco Linux, si potrebbe credere che il programma su quel disco sia proprio. Ma questo non è del tutto vero. I programmi coperti da copyright sono proprietà di chi detiene il copyright, anche quando arri vano con una licenza Open Source come la GPL. La licenza del programma garanti sce alcuni diritti, e altri si hanno sotto la definizione di uso corretto nella legge sul copyright. È importante notare che un autore non deve necessariamente limitarsi a porre una sola licenza su un programma che pubblica. Un programma può essere posto sotto GPL, e una versione può anche essere venduta con una licenza commerciale, non Open Source. Proprio di questa strategia si valgono molti che desiderano creare un programma Open Source e allo stesso tempo guadagnarci qualche cosa. Chi non vuole una licenza Open Source può pagare per il privilegio, fornendo all'autore una fonte d'entrate. Tutte le licenze che esamineremo hanno una caratteristica comune: declinano qua lunque garanzia. Lo scopo è quello di proteggere il proprietario del software da qua lunque responsabilità connessa al programma. Appare una richiesta ragionevole, dato che il programma viene ceduto a costo zero: l'autore non riceve dal program ma una fonte d'entrata sufficiente per sostenere un'assicurazione sulle responsabilità ed eventuali spese legali. Se gli autori di free software perdessero il diritto di declinare tutte le garanzie e si trovassero a essere citati in tribunale in base alle prestazioni dei programmi che han no scritto, smetterebbero di fornire software gratuito al mondo. È nel nostro inte resse di utenti aiutare gli autori a proteggere questo diritto.

La GNU Generai Public License Si veda l'Appendice B per il testo completo della GPL. La GPL è un manifesto poli tico tanto quanto è una licenza software, e la maggior parte del testo è inteso a spie gare la motivazione teorica dietro la licenza. Questo dibattito politico ha allontana to alcuni e fornito alcune delle ragioni per cui sono state scritte altre licenze per il free software. Tuttavia, la GPL è stata stilata con l'assistenza di giuristi ed è per que sto assai meglio scritta della maggior parte delle licenza di quella famiglia. Io con siglio caldamente di usare la GPL, o la sua variante per librerie LGPL, ogni volta che sia possibile. Se si sceglie un'altra licenza, o se ne stila una nuova, ci devono esse re delle buone ragioni per farlo. Chi formula la propria licenza dovrebbe sapere bene che non è un passo da fare con leggerezza. Le complicazioni inaspettate di una licen za affrettata possono affliggere gli utenti di un software per molti anni a venire. Il testo della GPL non è a sua volta sotto GPL. La sua licenza è semplice: Chiunque può copiare e distribuire copie esatte di questo documento di licenza, ma non ne sono ammesse modifiche. Un punto importante, qui, è che il testo delle licenza di software Open Source di solito non è Open Source esso stesso. Ovviamente, una licenza non potreb be offrire protezione di alcun tipo se a chiunque fosse consentito apportarvi delle modifiche. Le clausole della GPL soddisfano la Open Source Definition. La GPL non richiede alcuna delle clausole consentite dal Paragrafo 4 della Open Source Definition, Inte grità del codice sorgente dell'autore. La GPL non permette di mantenere private le modifiche apportate. Le modifiche devono essere distribuite sotto la GPL. In questo modo, l'autore di un programma sotto GPL ha maggiori probabilità di ricevere modifiche da altri, comprese società commerciali che modificano il suo software per i propri scopi. La GPL non ammette l'incorporazione di un programma sotto GPL in un pro gramma proprietario. La definizione di GPL di programma proprietario lo indica come ogni programma con una licenza che non dia tanti diritti quanti la GPL. Esistono alcune scappatoie nella GPL che permettono di usarla in un programma non interamente Open Source. Le librerie software che vengono normalmente di stribuite con il compilatore o con il sistema operativo che si usa possono essere col legate a software GPL: ne risulta un programma parzialmente libero. Chi detiene il copyright (di norma l'autore del programma) è la persona che mette il programma sotto GPL e ha il diritto di violare la propria licenza. Questa scappatoia è stata usa ta dagli autori di KDE per distribuire il loro programma Qt prima che Troil Tech ponesse su Qt una licenza Open Source. Tuttavia, questo diritto non si estende ad alcuna terza parte che ridistribuisca il programma: esse devono seguire tutti i ter mini della licenza, anche quelli che vengono violati dal detentore del copyright, il che rende problematico ridistribuire un programma che contenga Qt sotto GPL. Gli sviluppatori KDE sembrano inclini a rimediare a questo problema applicando al loro software la LGPL piuttosto che la GPL. La retorica politica presente nella GPL non è gradita a tutti. Non manca chi ha scel to, per il suo software, licenze non altrettanto adatte per semplice avversione alle idee di Richard Stallmann, pur di non aver voluto vederle ripetute nei propri pac chetti software. La GNU Library Public License La LGPL è una derivato della GPL escogitato per le librerie software. A differenza della GPL, un programma sotto LGPL può venire incorporato entro un programma proprietario. La libreria di linguaggio C fornita con i sistemi Linux è un esempio di software sotto LGPL: essa può essere usata per costruire programmi proprietari, diversamente Linux risulterebbe utile solamente agli autori di free software. Una copia di un programma sotto LGPL può essere convertita in qualunque momen to in una sotto GPL. Una volta che ciò succede, quella copia non è più riconvertibile in un programma sotto LGPL, e altrettanto dicasi di qualunque suo derivato. Le rimanenti clausole della LGPL sono simili a quelle della GPL: di flutto essa inclu de la GPL facendovi riferimento. Le licenze X, BSD e Apache La licenza X e le sue affini BSD e Apache sono molto diverse dalla GPL e dalla LGPL. Queste licenze consentono di fare quasi tutto ciò che si vuole con il softwa re licenziato' sotto di esse, e questo perché il software originariamente coperto dal le licenze X e BSD era sovvenzionato con sussidi del Governo degli Stati Uniti. Dal momento che i cittadini statunitesi avevano già pagato il software con i soldi delle tasse, fu loro garantito il diritto di fare del software tutto ciò che volessero. La concessione più importante, assente dalla GPL, è che si può mantenere private le modifiche licenziate sotto licenza X. In altre parole, si può ottenere il codice sorgente di un programma sotto X, modificarlo e poi vendere versioni binarie del programma senza distribuire il codice sorgente delle modifiche e senza applicarvi la licenza X. Tut to ciò rimane comunque Open Source, poiché la Open Source Definition non richie de che le modifiche debbano sempre ricadere sotto la licenza originale. Molti altri sviluppatori hanno adottato la licenza X e le sue varianti, compresi i pro getti BSD (Berkeley System Distribution) e Apache Web server. Un dettaglio mole- sto della licenza BSD è costituito da una clausola che prescrive che ogni volta che si faccia cenno a una caratteristica di un programma sotto BSD in una sua pubblicità, si menzioni (generalmente in una nota a piè di pagina) il fatto che il software è sta to sviluppato all'Università della California. Ora, tener traccia di quale software abbia quella licenza in una cosa immensa come una distribuzione Linux, e ricorda re quindi di menzionare l'Università della California ogni volta che uno di questi programmi venga citato in una pubblicità, è un vero mal di testa per i gestori com merciali del progetto. Nel momento in cui scrivo, la distribuzione Debian GNU/Linux contiene oltre 2500 pacchetti software, e se anche solo una piccola par te di essi fosse sotto BSD, la pubblicità per un sistema Linux come Debian dovreb be contenere molte pagine solo di note! Tuttavia, la licenza dell'X Consortium non ha quella clausola della pubblicità. Se si pensa di usare una licenza tipo BSD, si usi invece una licenza X. La Licenza Artistica Sebbene questa licenza sia stata in origine sviluppata per il Perl, è stata dopo di allo ra adoperata per altro software. A mio parere si tratta di una licenza formulata con grande sciattezza, in quanto impone dei requisiti e fornisce poi delle scappatoie che rendono facile aggirarli. Forse è questa la ragione per cui quasi tutto il software sot to Licenza Artistica ha oggi una seconda licenza, offrendo la scelta fra la Licenza Artistica e la GPL. La Sezione 5 della Licenza Artistica vieta la vendita del software, ma permette che sia venduta una distribuzione di software aggregato di più di un programma. Inquesto modo, se raggruppate un programma sotto Licenza Artistica con un bello wor!d.c di cinque righe di codice, potete vendere il bundie. Questa caratteristica della Licenza Artistica è stata la sola causa della scappatoia delI"aggregato" nel pri mo paragrafo della Open Source Definition. Dal momento che l'uso della Licenza Artistica è in netto declino, stiamo pensando di togliere quella scappatoia. Ciò ren derebbe la Licenza Artistica una licenza non-Open Source. Non è questo un passo che faremo leggermente, e ci vorrà probabilmente più di un anno di riflessione e di dibattito primà che questo accada. La Licenza Artistica richiede che le modifiche siano rese gratuite, ma fornisce poi una scappatoia (nella Sezione 7) che permette di mantenerle private e perfino di por re sotto dominio pubblico parti del programma sotto Licenza Artistica! L Netscape Public License e la Mozilla Public License La NPL è stata sviluppata da Netscape quando rese Open Source il suo prodotto Netscape Navigator. Per la precisione, la versione Open Source si chiama Mozilla; Netscape si riserva il marchio Navigator per il suo prodotto. Eric Raymond e io agimmo come consulenti a titolo gratuito durante lo sviluppo di questa licenza. Io cercai, senza successo, di persuadere Netscape a usare la GPL, e quando essa declinò, contribuii a comporre una licenza che si conformasse alla Open Source Definition. Una caratteristica importante della NPL è che contiene privilegi speciali che si applicano a Netscape e a nessun altro. Essa dà a Netscape il privilegio di ri-licen ziare le modifiche fatte al suo software. Netscape può mantenere private quelle modifiche, migliorarle, e rifiutarsi di restituire il risultato. Questa clausola si è resa necessaria perché, quando Netscape decise per l'Open Source, aveva contratti con altre aziende che la impegnavano a fornire loro Navigator sotto una licenza non Open Source. Netscape ha creato la MPL o Mozilla Public License per rimediare a questa situa zione. La MPL è molto simile alla NPL, ma non contiene la clausola che permette a Netscape di rimettere le modifiche sotto licenza. La NPL e la MPL consentono di mantenere private le modifiche apportate. Molte aziende hanno adottato per i loro programmi una variante della MPL. Non è una buona cosa, perché la NPL era stata progettata per la particolare situazione con trattuale in cui Netscape si trovava nel momento in cui la licenza veniva scritta, e non è detto che sia altrettanto adatta a usi diversi. Dovrebbe restare la licenza di Netscape e di Mozilla, e altri dovrebbero usare le licenze GPL o X.
Scegliere una licenza Non conviene formulare una licenza nuova se è possibile usarne una di quelle qui elencate. La propagazione di molte licenze diverse e incompatibili opera a detri mento del software Open Source, perché frammenti di un programma non possono essere usati in un altro programma sotto licenza incompatibile. Ci si tenga alla larga dalla Licenza Artistica, a meno che non si intenda studiarla a fondo ed eliminarne le scappatoie. Fatto ciò, è tempo di prendere delle decisioni. 1. Si vuole che il pubblico possa mantenere private le modifiche, o no? Se si vuole che chi ha apportato modifiche al proprio software ne rimandi il codice sorgen te, si applichi una licenza che lo prescriva. La GPL e la LGPL sono delle buone scelte. Se non dispiace che il pubblico mantenga private le modifiche, si usino le licenza X o la licenza Apache. 2. Si vuole consentire a qualcuno di far confluire il proprio programma nel suo software proprietario? Se sì, si usi la LGPL, che lo permette esplicitamente sen za consentire al pubblico di rendere privato il codice, oppure si usi le licenza X o Apache, che permettono che le modifiche siano mantenute private. 3. Si desidera che chi lo voglia possa comprare sotto licenza commerciale versioni non-Open Source del proprio programma? Se sì, si doti il software di doppia licenza. Io consiglio la GPL come licenza Open Source; si può trovare una licen za commerciale adatta all'uso in libri come "Copyright Your Software" edito da Nolo Press. 4. Si vuole che chiunque usi il proprio software debba pagare per il privilegio? Se le cose stanno così, forse l'Open Source non è adatta. Se basta che solo alcune per sone paghino, si può mantenere Open Source il programma. La maggior parte degli autori Open Source considerano i loro programmi come contributi al bene pubblico, e non badano al fatto di essere pagati oppure no. Il Futuro Al momento in cui questo saggio andava in stampa, IBM è entrata nel mondo Open Source e la comunità dei venture capital lo sta scoprendo. Intel e Netscape hanno investito in Red Hat, un distributore Linux. VA Research, integratore di server Linux e hardware per workstation, ha annunciato l'ingresso di un investitore ester no. Sendmail Inc., creata per commercializzare l'onnipresente programma di posta elettronica Sendmail, ha annunciato la disponibilità di fondi per sei milioni di dol lari. L'applicazione di posta protetta Postfix di IBM ha una licenza Open Source, e un altro prodotto IBM, il compilatore Java Jikes, ha una licenza che, nel momento in cui scrivo, mira, per il momento con parziale successo, a soddisfare le specifiche dell'Open Source Definition. Parrebbe che IBM intenda modificare la licenza di J ikes perché sia per intero Open Source, e che a questo scopo stia raccogliendo pare ri nella comunità. Due promemoria interni della Microsoft, noti sotto il nome di Halloween Docu ments, sono trapelati al pubblico online. Questi promemoria mostrano in modo me quivocabile come Microsoft si senta minacciata da Open Source e da Linux, e che MS lancerà un'offensiva contro di loro per proteggere i suoi mercati. È chiaro che dobbiamo prepararci a vivere tempi interessanti. Credo che vedremo Microsoft usa re due principali strategie: interfacce sotto copyright e brevetti. Microsoft estenderà i protocolli di rete, che contengono caratteristiche proprietarie Microsoft in quelli che non verranno resi disponibili al free software. Essa, con altre aziende, farà ricer ca aggressivamente in nuove direzioni dell'informatica e brevetterà tutto quanto potrà prima che noi si possa sfruttare quelle tecniche nel free software; quindi ci chiuderà fuori con le concessioni sui diritti di brevetto. Sono autore di un saggio per la webzine Linux World su come si possano battere i nemici dell'Open Source sul fronte dei brevetti. La buona notizia è che Microsoft è spaventata! Nel secondo degli I-Ialloween Docu ments, un membro dello staif Microsoft racconta della sua sensazione d'euforia nel vedere come poteva modificare facilmente parti del sistema Linux perché facesse esattamente quello che voleva, e com'era più facile per un impiegato Microsoft fare questo su Linux di quanto non lo fosse modificare NT!
I tentativi di nuocerci provenienti dall'interno sono i più pericolosi. Credo che vedremo altri sforzi per diluire la definizione di Open Source fino a includervi pro dotti parzialmente gratuiti, come abbiamo visto avvenire con la libreria Qt in KDE prima che Troli tech vedesse la luce e rilasciasse una licenza Open Source. Microsoft e altri potrebbero danneggiarci rilasciando un sacco di software gratuito quel tanto da attrarre utenti, ma senza avere le piene libertà dell'Open Source. Non è impen sabile che essi possano stroncare lo sviluppo di certe categorie di software Open Source rilasciando soluzioni "abbastanza valide", "abbastanza quasi-gratis". Tuttavia, la forte reazione che si è avuta contro il progetto KDE prima che la libreria Qt divenisse completamente Open Source, non è di buon augurio per imprese analoghe di MS e compagnia. Finora abbiamo scampato i cavalli di Troia. Supponiamo che qualcuno che ci vuoi male fornisca del software che contiene un cavallo di Troia (un espediente per scon figgere la protezione in un sistema Linux). Supponiamo, poi, che la medesima per sona resti in attesa che il software con il cavallo di Troia sia largamente distribuito e quindi ne pubblicizzi la vuinerabilità agli attacchi alla sicurezza. Il pubblico si sarà per allora accorto che il nostro sistema Open Source può lasciarci più vulnerabili a questa sorta di attacchi che non il sistema chiuso di Microsoft; questo potrebbe ridurre la fiducia generale nel software Open Source. Potremmo obiettare che Microsoft ha la sua parte di bug di sicurezza anche se non lascia possibilità di inse rirli a persone esterne e che il modello a codice sorgente aperto dell'Open Source ren de più facile scoprire questi bug. Qualunque bug del genere che comparisse in Linux sarebbe riparato il giorno dopo essere stato scoperto, mentre un omologo in Win dows o non sarebbe mai scoperto o dovrebbe aspettare il rimedio per anni. Ma dob biamo rinforzare ancora la nostra difesa contro i cavalli di Troia. Identificare con sicurezza chi contribuisce alla creazione di software e delle modifiche è la difesa migliore di cui disponiamo, dai momento che ci permette di valerci del diritto pena le contro chi escogita cavallì di Troia. Quando ero dirigente della distribuzione GNU/Linux di Debian, istituimmo un sistema che consentiva di identificare in modo affidabile tutti i manutentorì del software e permetteva loro di partecipare a loro volta a una rete a crittografia a chiave pubblica che ci avrebbe consentito di veri ficare da chi proveniva il nostro software. Questo tipo di sistema si deve espandere fino a comprendere tutti gli sviluppatori Open Source. Enormi sono i miglioramenti da intraprendere prima che Linux sia davvero alla por tata dell'utente medio. L'interfaccia grafica per gli utenti è chiaramente qualcosa che manca, e a questo sono rivolti i progetti KDE e GNOME. La prossima frontiera è l'ammìnistrazione di sistema; linusconf vi sta parzialmente provvedendo, ma si tro va ben lungi dall'essere uno strumento completo d'amministrazione di sistema per l'utente sprovveduto. Se il sistema COAS di Caldera avrà successo, potrebbe diven tare la base per una soluzione completa al problema dell'amministrazione di siste ma. Tuttavia, Caldera ha avuto dei problemi nel mantenere un'allocazione di risor se sufficienti a COAS per terminame lo sviluppo, e altri sviluppatori hanno abban donato la partita perché non notavano progressi. La pletora di distribuzioni Linux appare oggi in pieno rivolgimento, con Red Hat percepita come vincitrice e Caldera come seconda. Red Hat ha mostrato finora un solido impegno verso il concetto di Open Source, ma un nuovo presidente e voci di un'offerta pubblica iniziale (Initial Pubblic Offering, IPO) potrebbero significare un indebolimento di quest'impegno, specialmente se concorrenti come Caldera, molto più tiepidi verso l'Open Source, riusciranno a inserirsi nel mercati di Red Hat. Se l'impegno delle distribuzioni Linux commerciali verso l'Open Source diventerà pro blematico, questo genererà probabilmente uno sforzo per rimpiazzarle con tentativi Open Source simili al GNU/Linux di Debian ma più diretti al mercato commercia le di quanto non sia stata Debian. Malgrado queste sfide, io predico la vittoria dell'Open Source. Linux è divenuto lo strumento di test per gli studenti d'informatica, che, una volta laureati, porteranno con sé quegli strumenti nei loro posti di lavoro. Molti labàratori di ricerca hanno adottato il modello Open Source in quanto la condivisione delle informazioni è essenziale al metodo scientifico, e l'Open Source consente al software di essere con- diviso facilmente. Il mondo business sta adottando il modello Open Source perché consente a gruppi di aziende di collaborare nella risoluzione di un problema senza la minaccia di una causa anti-trust, e per l'impulso di cui gode quando i contributi pubblici di programmazione rendono gratuite le migliorie al software. Alcune gran di società hanno adottato l'Open Source come strategia per combattere Microsoft e per scongiurare l'avvento di un'altra Microsoft a dominare il settore informatico. Ma l'indicazione più affidabile sul futuro dell'Open Source viene dal suo passato: in pochi anni, dal niente siamo arrivati ad avere un robusto corpus di software che è in grado di risolvere tanti problemi diversi e che si avvia a raggiungere il milione di utenti. Non c'è ragione di rallentare la corsa proprio adesso.