INTRODUZIONE. – Iniziamo con questo capitolo ad entrare nel merito delle implicazioni giuridiche attinenti alla distribuzione dell’opera software in generale e successivamente ai risvolti peculiari (e per certi versi atipici) che la rivoluzione Opensource ha innestato in tale ramo del diritto industriale.
Premettiamo che d’ora innanzi si useranno le espressioni ‘copyright’ e ‘diritto d’autore’ a seconda che ci si riferisca rispettivamente ad una realtà internazionale (o comunque di matrice common law) oppure ad una realtà legata al diritto d’autore continentale e più specificamente al quadro normativo italiano.[56]

1. LA TUTELA GIURIDICA DEL SOFTWARE. – Come abbiamo già potuto vedere nell’evoluzione storica dell’informatica, l’idea di una tutela giuridica su un’opera software non si è affatto affermata in modo parallelo e graduale rispetto alla diffusione del software stesso; anzi, possiamo dire che la prassi della tutela giuridica sia stata direttamente proporzionale non tanto allo sviluppo della produzione software, quanto piuttosto all’interesse che il mercato ha man mano dimostrato verso questo settore.[57]
La scelta – nei nostri tempi di ‘boom informatico’ è ben intuibile – fu determinata dai crescenti interessi economici che necessariamente si andavano a formare attorno al mercato del software. Bisogna ricordare infatti che la funzione primaria di tutti gli apparati giuridici di proprietà intellettuale è quella di creare dei diritti esclusivi di sfruttamento in modo da poter da un lato garantire un profitto al titolare di tali diritti, dall’altro (in una più ampia prospettiva di politica del diritto) di incentivare la creatività e l’inventiva in generale. Tutelare un frutto dell’ingegno e della creatività, sia esso un’invenzione o un’opera espressiva, significa soprattutto tutelare ed incoraggiare gl’investimenti compiuti per la sua realizzazione.[58]

1.1. IN GENERALE. – Le aziende d’informatica, che verso la fine degli anni ’70 iniziarono a voler tutelare i loro cospicui investimenti, potevano servirsi dei meccanismi tradizionali del diritto industriale, facenti capo ai due diversi modelli del diritto d’autore e del brevetto: il primo concepito originariamente per le creazioni di tipo artistico-espressivo[59], il secondo invece per le invenzioni di carattere tecnico-industriale. Mentre il diritto d’autore mira a proteggere solo la forma espressiva dell’opera (ovvero la modalità con cui l’autore trasmette un messaggio, sia esso in forma letteraria, musicale, figurativa, multimediale etc.), la tutela brevettuale mira a proteggere il contenuto dell’invenzione (ovvero l’idea o il procedimento che sta alla base dell’invenzione). Questo principio, già comune a tutti gli ordinamenti, è stato chiaramente ribadito nei TRIPs[60], in cui all’art. 9, n. 2 si stabilisce che “la protezione del diritto d’autore copre le espressioni e non le idee, i procedimenti, i metodi di funzionamento o i concetti matematici in quanto tali”.[61]
Coerentemente con quanto fin qui detto, per individuare quale tipo di tutela sarà possibile applicare, è necessario preventivamente raggiungere una sicura classificazione dell’opera in esame; se ne dovranno analizzare le caratteristiche e, a seconda che esse risultino compatibili con i requisiti che il piano normativo prevede per l’una o per l’altra modalità di tutela, si deciderà quale delle due applicare. Ciò, tuttavia, non significa che ad una stessa opera non possano essere applicate in sovrapposizione entrambe le tutele; esse infatti non si escludono a vicenda, ma anzi apportano diversi gradi e meccanismi di protezione: per esempio, il diritto d’autore ha una maggior durata nel tempo ed è applicabile automaticamente a partire dal mero atto della creazione; il brevetto ha una durata minore, richiede una formalizzazione, ma una volta perfezionato può consentire una protezione più efficace a causa della sua estensione al contenuto e al procedimento.
In via teorica, dunque – restringendo il tutto al quadro normativo italiano – la soluzione al dilemma starebbe in una lampante dicotomia: nel caso di opera artistico-espressiva, si applica il diritto d’autore ex Legge 633/1941 (“Protezione del diritto d’autore e di altri diritti connessi al suo esercizio”; d’ora in poi “l. a.”); nel caso di invenzione industriale, si applica la normativa brevettuale ex Regio Decreto 1127/1939 (“Testo delle disposizioni legislative in materia di brevetti per invenzioni industriali”; d’ora in poi “l. inv.”). Nella realtà dei fenomeni giuridici, però, la situazione non è così ben definita, a causa della comparsa (avvenuta negli ultimi anni grazie alle nuove tecnologie) di opere atipiche, che spesso incontrano alcuni requisiti di entrambe le categorie, ma senza soddisfare appieno quelli di nessuno dei due.
E’ questo il caso controverso del software[62]. Fino al momento della sua comparsa, il confine fra opere tecnico-funzionali e opere espressive era sempre stata piuttosto pacifica; con il nuovo arrivo, però, il mondo del diritto si trovò di fronte ad un’entità molto più difficile da inquadrare e che si collocava proprio a cavallo delle due categorie di opere dell’ingegno[63]. A livello dottrinale più che a livello pratico, infatti, a creare dubbi era proprio una caratteristica peculiare del software: la sua funzionalità, ovvero la sua vocazione di opera destinata alla soluzione di problemi tecnici; caratteristica questa che lo avvicinerebbe ineluttabilmente alla categoria delle invenzioni dotate d’industrialità. D’altro canto, però, il software appare carente del requisito della materialità considerato da alcuni come ‘condicio sine qua non’ per la brevettabilità.[64]
Storicamente, inoltre, la tutela brevettuale venne vista con diffidenza dalle aziende produttrici di hardware, che temevano che tale prospettiva avrebbe attribuito uno eccessivo potere alle aziende di software e reso il mercato dell’hardware schiavo delle loro scelte di mercato[65]. Si riproponeva in versione speculare lo stesso problema che si era posto pochi anni prima quando compagnie come la IBM o la Apple preferirono (con grande saggezza e illuminazione) non brevettare il PC per non soffocare un business ancora in emersione.

1.2. LA TUTELA D’AUTORE. – Fu in questo contesto di notevoli e intricati interessi economici che il legislatore statunitense nel 1980 fece la coraggiosa quanto necessaria scelta di politica legislativa di stabilire dall’alto quale disciplina applicare al software, ovvero la tutela per mezzo di copyright (non a caso l’atto legislativo in questione fu chiamato ‘Software Copyright Act’). Nell’arco di un lustro quasi tutti i principali paesi tecnologicamente avanzati si mossero nella stessa direzione: l’Australia nel 1984 (con il Copyright Amendment Act), la Francia e la Germania nel 1985 (entrambe con legge ordinaria per la riforma della normativa preesistente sul diritto d’autore), la Gran Bretagna anch’essa nel 1985 (con il Copyright Computer Software Amendment)[66].
Come spesso accade, il legislatore italiano si distinse per inerzia e si dovette attendere la direttiva europea n. 91/250/CEE (del 1991) che appunto mirava ad un’armonizzazione delle norme comunitarie in fatto di protezione del software; la direttiva invitava gli stati membri ad applicare al software la normativa del diritto d’autore. La nuova opera doveva essere considerata alla stregua di un’opera letteraria (di carattere scientifico) ai sensi della Convenzione di Berna, ratificata dallo Stato italiano nel 1978; la legge italiana di attuazione della direttiva (ovvero il d. lgs. 518/1992) inserì nella legge sul diritto d’autore una serie di articoli ad hoc per il software (artt. 64 bis, ter, quater) costituenti una nuova apposita ‘Sezione VI’ del ‘Capo IV’, intitolata proprio “Programmi per elaboratore”.[67]
In effetti, se si pensa a quanto detto nel capitolo introduttivo sulle peculiarità tecniche del software, la sua assimilazione ad un’opera letteraria non pare nemmeno molto forzata; possiamo infatti equiparare (come acutamente osservano alcuni autori[68]) il programma in forma di codice sorgente ad un manuale d’istruzioni tecniche redatte in un preciso linguaggio e destinate alla macchina (o, al massimo, ad altri sviluppatori che conoscono quel linguaggio). La rilevanza dei requisiti di creatività e di originalità (tipici del diritto d’autore) tende quindi a prevalere sulla peculiarità della vocazione funzionale del software; infatti, la soluzione tecnica cui un programma è preposto può essere raggiunta dal programmatore in diversi modi a seconda del linguaggio prescelto e di come le istruzioni sono disposte all’interno del codice.[69]
Una volta stabilita la normativa applicabile, deduciamo dai principi cardine del diritto d’autore quali diritti l’autore possa vantare sull’opera in base a tale tutela. Il diritto continentale europeo, e in particolar modo quello italiano, avverte la distinzione fra diritti morali d’autore, legati alla sfera personale dell’autore e quindi inalienabili (principalmente il diritto al riconoscimento della paternità dell’opera), e diritti patrimoniali d’autore, ovvero tutto il fascio di diritti passibili di una valutazione economica (quindi alienabili) che ruotano attorno alla gestione e alla diffusione dell’opera. Nella nostra analisi prenderemo in maggiore considerazione quest’ultima sfera per due motivi: sia a causa della dimensione di politica economica in cui abbiamo più volte inquadrato le scelte in materia di tutela del software, sia perché gli ordinamenti di common law come gli U.S.A. – quindi gli ordinamenti che più hanno influito sulla regolamentazione del software – non presentano una simile dicotomia, considerando il diritto d’autore come sempre rilevante dal punto di vista patrimoniale.[70]
Nel nostro sistema normativo, questi diritti di stampo patrimoniale sono quelli sanciti dall’art. 12 l.a., che recita: “L’autore ha il diritto esclusivo di pubblicare l’opera. Ha altresì il diritto esclusivo di utilizzare economicamente l’opera in ogni forma e modo originale o derivato, nei limiti fissati da questa legge, ed in particolare con l’esercizio dei diritti esclusivi indicati negli articoli seguenti. E’ considerata come prima pubblicazione la prima forma di esercizio del diritto di utilizzazione.” E’ palese il reiterato riferimento al concetto di diritto esclusivo, che successivamente viene ribadito per esempio nell’art. 13 (diritto esclusivo di riproduzione) e nell’art. 17 (diritto esclusivo di distribuzione). Questa categoria di diritti mira a conferire all’autore una possibilità d’azione (nei confronti dell’opera) preclusa a qualunque altro soggetto: si cita spesso, per mostrarne la portata, l’espressione latina ‘ius excludendi alios’, cioè il diritto di escludere gli altri da una determinata sfera d’azione, la possibilità da parte del titolari di tali diritti di vietare condotte da lui non autorizzate.[71]
Come vedremo in questo capitolo, saranno proprio questi diritti ad entrare maggiormente in gioco nell’ambito della distribuzione del software.

2. FUNZIONE E CONTENUTO DELLE LICENZE D’USO. – Data la sussistenza dei diritti esclusivi derivante dalla tutela d’autore, in base ai cardini del diritto privato è necessario che l’autore del software stipuli un contratto con l’utente nel quale definisca di quali prerogative si spogli e di quali quindi possa essere investito l’utente, ovviamente per contro di un corrispettivo (stante la patrimonialità di tali diritti). Una prassi di questo tipo, basata cioè su contratti stipulati ad hoc per ogni situazione o soggetto, poteva aver ragion d’essere solo nell’era “primordiale” dell’informatica, quando la figura del programmatore era assimilabile ad un libero professionista chiamato alla progettazione di un sistema informatico specifico per un centro di ricerca. Dal momento dell’ingresso del software nella schiera dei beni di consumo, gli autori iniziarono a stilare dei contratti di portata generale in cui esprimevano i termini della distribuzione e della riproduzione del software su cui essi vantavano i suddetti diritti esclusivi: nacque così il tipo contrattuale della licenza d’uso di software.
La scelta del termine licenza è dovuta probabilmente alla funzione autorizzativa del contratto, anche se – come molti giusprivatisti fanno notare[72] – non sarebbe pienamente appropriata. In realtà la definizione autentica di ‘licenza’ implicherebbe un contratto di concessione da parte di un soggetto (licenziante) ad un altro soggetto (licenziatario) “non solo della facoltà di godere di una certa idea creativa, ma anche di sfruttarla economicamente”[73]. Ma nella maggior parte dei casi l’oggetto del contratto si limita al solo godimento personale del bene software, non estendendosi ai diritti di sfruttamento economico che restano invece in capo all’autore originario[74]. E’ per questo che la dottrina giusprivatistica maggioritaria opterebbe per qualificare il rapporto fra autore e utente del software come una locazione, dato che con il tipo contrattuale che si usa chiamare impropriamente ‘licenza d’uso’ “non si cede alcun diritto di sfruttamento economico sul bene, ma ci si limita a concedere il solo godimento personale del programma.”[75]
Per quanto riguarda invece i diritti di proprietà sul software è il caso di distinguere fra proprietà del software in quanto bene materiale (supporto) e proprietà del software in quanto opera dell’ingegno[76]. La seconda rileva per il diritto d’autore (è detta infatti ‘proprietà intellettuale’) e si fonda sul meccanismo dei diritti esclusivi licenziati; la prima invece rimane nella sfera d’influenza del diritto privato, risolvendosi in un normale contratto di compra-vendita. Così come d’altronde succede quando ci si reca da un rivenditore di materiale informatico per comprare un pacchetto software; anche se spesso perfezionati nello stesso momento, vengono eseguiti due contratti separati e di diversa natura: quello con il rivenditore (che ha per oggetto la proprietà materiale del supporto su cui il software è venduto) e quello con la compagnia produttrice del software (che ha per oggetto i diritti di proprietà intellettuale dell’opera software). La piena proprietà del supporto e degli “accessori” del bene è indiscussa; a creare maggiori perplessità e a diventare oggetto centrale di questa nostra analisi giuridica, è invece la portata dei diritti di proprietà intellettuale derivanti dai diritti esclusivi di sfruttamento economico in capo all’autore dell’opera.

3. DIVERSE TIPOLOGIE DI DISTRIBUZIONE DEL SOFTWARE. – Il software, a seconda del grado di libertà che il titolare dei diritti di tutela decide di attribuire agli utenti della sua opera, può essere classificato all’interno di un prospetto di definizioni[77], che sono ovviamente da intendersi in modo piuttosto elastico ma ci aiutano a raggiungere una certa dimestichezza con le tipologie di distribuzione dell’opera software.
In una scala di valore che parte da un grado minimo di libertà per l’utente verso il grado massimo, al primo scalino abbiamo prevedibilmente il software proprietario, con le sue molteplici e sovrapposte forme di distribuzione; le più diffuse sono: il software commerciale proprietario, che prevede l’acquisto della licenza d’uso del prodotto o per avviarne l’uso (solitamente per mezzo di parole-chiave che permettono di superare i meccanismi di crittazione) o addirittura per entrare in possesso del supporto materiale (CD-ROM o floppy-disk)[78]. Ci sono poi le versioni di prova, chiamate in gergo trial version (lett. versioni di prova) o demo, nelle quali il programma si presenta privo di alcune funzionalità, oppure completo ma con una possibilità di utilizzo limitata nel tempo (in questo caso di parla anche di shareware); tutto ciò sempre attuato mediante meccanismi automatici di crittazione[79]. Scaduto il periodo di prova, solitamente il programma invita l’utente ad acquistare la licenza per poterne continuare l’uso. Abbiamo anche il caso - sicuramente meno diffuso - dei programmi AD-ware, i quali mostrano durante l’uso alcuni banner pubblicitari; i costi di licenza quindi sono coperti in via indiretta dalle aziende inserzioniste. Infine si parla di freeware, riferendosi a un software commerciale completo che però viene ceduto in uso gratuito[80] per motivi promozionali[81], o in base a contratti che puntano più che altro sull’aspetto della manutenzione e della customizzazione.
Sul secondo scalino - quello centrale - sta invece il fenomeno di cui questo saggio si occupa: il software libero e aperto, basato sul meccanismo del copyleft, con le peculiarità proprie delle due denominazioni di ‘free software’ e ‘opensource software’[82]. Possiamo effettuare un’ulteriore graduazione anche all’interno di questa che abbiamo volutamente considerato come un’unica categoria: nel modo in cui abbiamo già spiegato nell’evoluzione storica del fenomeno, se ci focalizziamo sulla libertà in senso ideologico lo scalino più alto spetta al ‘free software’ caro alla FSF; se però ci limitiamo alle implicazioni pratiche del concetto di libertà ci accorgiamo che è molto difficile tracciare un confine fra le due definizioni.
Sul terzo e ultimo scalino, quello col massimo grado di libertà per l’utente, troviamo infine il public domain software (software di pubblico dominio), ovvero un software non solo distribuito gratuitamente e liberamente, ma addirittura privo di ogni annotazione di copyright, tanto da occultarne anche la paternità (il cosiddetto aspetto ‘morale’ del diritto d’autore). Uno strumento dunque regalato alla conoscenza, di cui chiunque è libero di fare ciò che vuole senza alcun limite derivante da licenza[83].

4. IL CONCETTO DI COPYLEFT. – Prendendo le mosse dalla classificazione appena riportata, a rigor di logica la scelta del public domain dovrebbe essere quella che garantisce la maggior libertà di diffusione e di malleabilità e perciò dovrebbe rappresentare il modello più calzante con l’apparato etico sbandierato dalla FSF. E infatti è così, ma solo in linea di principio.
Proviamo a riflettere su una cosa: lasciare il software in un regime di pubblico dominio comporta – come abbiamo detto poco fa – che chiunque possa farne ciò che vuole; ma pubblico dominio in questo caso non vuol dire ‘proprietà di tutti’ intendendo ‘tutti’ come ‘comunità organizzata’, bensì intendendo ‘tutti’ come ‘ciascuno’. Di conseguenza, ciascuno potrebbe anche attribuirsi arbitrariamente i diritti esclusivi di tutela e iniziare a distribuire il software da lui modificato come se fosse software proprietario, criptando il sorgente e misconoscendo la provenienza pubblica del software, senza che nessuno possa agire nei suoi confronti.
Una simile prospettiva avrebbe presto vanificato gli scopi del progetto GNU, con il rischio oltretutto di vedere defraudato il lavoro dei numerosi sviluppatori che vi avevano aderito con spirito di dedizione e gratuità. Bisognava escogitare una soluzione per far sì che ogni affiliato del progetto fosse a sua volta tenuto a mantenere lo stesso grado di libertà sul lavoro da lui svolto. Qui s’innesta la trovata forse più geniale ed interessante di Stallman: egli capì che l’arma più efficace per difendersi dalle maglie troppo strette del copyright (così come si è evoluto negli ultimi anni) stava nel copyright stesso. Per rendere dunque un software veramente e costantemente libero è sufficiente dichiararlo sotto copyright e poi riversare le garanzie di libertà per l’utente all’interno della licenza, ribaltando così il ruolo della stessa e creando un vincolo di tipo legale fra la disponibilità del codice e le tre libertà fondamentali: di utilizzo, di modifica e di ridistribuzione[84].
Stallman descrive in modo efficace questa prassi (lasciando come sempre trasparire dalle sue parole una vena ideologica): “Gli sviluppatori di software proprietario ricorrono al copyright per rubare agli utenti la propria libertà; noi usiamo il copyright per tutelare quella libertà.”[85] Come già aveva fatto per l’etimologia di ‘GNU’, cercò di attribuire a questo criterio (banale e rivoluzionario allo stesso tempo) un nome emblematico; e lo fece sfruttando un gioco di parole, anzi un doppio gioco di parole. Scelse l’espressione ‘copyleft’ che, a seconda dei significati che si danno alla parola ‘left’, trasmette una duplice idea: un’idea di ‘ribaltamento’ degli stereotipi del copyright tradizionale, se s’intende ‘left’ (sinistra) come contrario di ‘right’ (destra); ma anche e soprattutto un’idea di ‘libertà d’azione’ dato che ‘left’ è il participio passato di ‘leave’, cioè ‘lasciare’, ‘permettere’.
Qualcuno si è avventurato in una forzata traduzione di ‘copyleft’ in ‘permesso di copia’ o ‘permesso d’autore’, anche se a mio avviso questa è una di quelle espressioni tipiche dello slang hacker che rimangono intraducibili per la loro innata efficacia[86]. Infatti, nella traduzione italiana si perde irrimediabilmente il senso del duplice gioco di parole, dato che non si può cogliere l’idea di ribaltamento.
Quest’ultima sfumatura semantica è stata poi evidenziata dai seguaci della FSF con un’ulteriore distorsione linguistica: alcuni di loro amavano apporre ironicamente sui loro lavori una nota sul copyright il cui testo letterale è
- - - - - - “copyleft (?) - all rights reversed”[87] - - - - - -
ovvero, “copyleft - tutti i diritti rovesciati” con una ‘C’ rovesciata invece del canonico “copyright (C) - all rights reserved” (cioè, “copyright - tutti i diritti riservati”). Dopo tale annotazione venivano poi elencati (alla stregua di una licenza d’uso) tutte le libertà di cui l’utente era ufficialmente investito e veniva rimarcato l’obbligo di mantenerle intatte in futuro nei confronti degli altri utenti.
A conti fatti, dunque, il copyleft consiste nel convertire le licenze d’uso, da decalogo degli obblighi dell’utente[88], in una sorta di “statuto” dei suoi diritti[89], intoccabili nel tempo e invariabili presso terzi[90].

5. LA GENERAL PUBLIC LICENSE: SCOPI, CONTENUTI E RISVOLTI GIURIDICI. – Stallman stesso, con la consulenza di alcuni colleghi hacker e giuristi[91], volle redigere il testo base della licenza da apporre ai programmi GNU. Lo fece lasciando immancabilmente trasparire gli intenti ideologici del progetto anche nelle parole di quello che invece sarebbe potuto rimanere un testo di tipo tecnico-giuridico, franco da certe connotazioni[92]. Ad ogni modo, il passo fu determinante e molti guardarono con occhi affascinati quella nuova “creatura”[93]: era il 1989 e venne chiamata GNU General Public License, più conosciuta per il suo acronimo GPL. Coerentemente con quanto appena detto sulla traduzione di ‘copyleft’, è opportuno notare che la versione italiana ‘Licenza pubblica generica GNU’ rischia di distorcere il significato dell’espressione, soprattutto riguardo all’aggettivo ‘pubblico’ che ad un’attenta analisi semantica non coincide con il concetto di ‘public’ tipico dei paesi di common law[94].
Analizziamone il contenuto, seguendo il testo della licenza nella più recente versione 2 (giugno 1991) tradotta in italiano[95]. Per una lettura attenta e precisa del documento si rimanda all’appendice con i testi delle principali licenze.
Già dalle prime righe si può notare che – a conferma di quanto detto poc’anzi sul fondamento giuridico del copyleft – si tratta di un documento che basa tutta la sua essenza ed efficacia sul copyright, a differenza di ciò che si può pensare comunemente. Lo si coglie pure dal fatto che lo stesso testo della GPL viene dichiarato inequivocabilmente tutelato da copyright da parte della Free Software Foundation Inc., organizzazione identificata inequivocabilmente con tanto di città, via e numero civico. Successivamente si riporta una nota, che è poi l’essenza del concetto di copyleft inteso però solamente come ‘permesso di copia’: “chiunque può copiare e distribuire copie letterali di questo documento, ma non ne è permessa la modifica.” Quest’annotazione preliminare è ovviamente resa necessaria al fine di evitare che il destinatario della licenza ne possa stravolgere la funzione primaria cambiandone i contenuti e alterandone la disciplina a suo piacimento; quindi, sotto questo aspetto, unico soggetto autorizzato a rilasciare modifiche o addirittura nuove versioni è la FSF, in posizione di detentrice dei diritti di copyright.
Il documento procede con un ‘Preambolo’, che si presenta – lo abbiamo già accennato – come una summa dei principi etici e giuridici di cui la FSF si fa massima portavoce. Sette paragrafi per chiarire l’intento programmatico della licenza, la sua funzione tecnico-giuridica, il suo corretto utilizzo e i rapporti di responsabilità e garanzia nel sistema GNU di distribuzione del software; tutti aspetti che si ripercorrono subito dopo nella lettura delle tredici sezioni (o commi [96]) della “licenza vera e propria”.
La ‘Sezione 0’ dà alcune definizioni (per es. i concetti di “programma”, “opera basata sul programma” e “modifica”) per una corretta interpretazione dei punti successivi e delimita l’ambito d’azione della licenza, precisando quali attività relative al programma essa copra: l’esecuzione, la copiatura, la distribuzione e la modifica[97]; quindi altre attività non sono da intendersi contemplate e quindi tutelate dalla GPL.
La ‘Sezione 1’ si sofferma sulle condizioni che rendono lecita la distribuzione e la copia del programma: si ribadiscono in pratica i paradigmi del copyleft relativi all’obbligo di trasmettere (mediante “un’appropriata nota sul copyright”) gli stessi diritti ricevuti.
La ‘Sezione 2’ scende nello specifico del concetto di modifica e delle sue delicate implicazioni giuridiche; si entra infatti nel terreno accidentato che porta alla configurazione del software nato da modifica di altro software come ‘opera derivata ai sensi della legge sul copyright’. Questa sezione – per le ragioni che abbiamo esaminato parlando di libertà e disponibilità del codice sorgente – è sicuramente una delle più decisive ed innovative alla luce degli scopi pratici della GPL; infatti è proprio la possibilità di modifica che distingue un software libero e opensource da un normale software commerciale distribuito gratuitamente (come le versioni trial o freeware).
La ‘Sezione 3’, a completamento di quanto detto poco prima, mira ad assicurare la disponibilità del codice sorgente e stabilisce le condizioni della sua diffusione. Successivamente effettua un utilissimo chiarimento del concetto di “codice sorgente completo”, prima in senso concettuale (“la forma preferenziale usata per modificare un’opera software”), poi in senso strettamente tecnico (al quale si rimanda[98]).
La ‘Sezione 4’ riguarda la validità della licenza e si presenta come una sorta di “norma di chiusura” con la quale si escludono dalla copertura della GPL (con un meccanismo di decadenza automatica dai diritti licenziati) le attività diverse da quelle esplicitamente previste dalla licenza.
La ‘Sezione 5’ e la ‘Sezione 6’ sono dedicate ad alcuni aspetti pratici della distribuzione di prodotti sotto GPL: l’acquirente di un programma di questo tipo è libero di non accettare i termini della licenza (e quindi di non usare quel prodotto), ma qualora lo modificasse o lo distribuisse ciò significherebbe l’accettazione tacita e automatica della licenza, e di conseguenza l’assunzione degli obblighi di trasferimento dei diritti licenziati. Queste due sezioni – per così dire – fungono da “collante” fra la licenza e il prodotto distribuito nei termini in essa determinati: in parole povere, ci dicono che chi non vuole accettare le condizioni della GPL, può benissimo lavorare su un altro tipo di software; qualora però volesse un prodotto di ‘software libero’, deve accettarne in toto le peculiarità giuridiche e di distribuzione.
Molto interessanti risultano invece le ‘Sezioni 7 e 8’ che prevedono alcune cautele per ovviare al rischio di eventuali modifiche ai termini della licenza imposte da statuizioni di autorità giudiziarie o da peculiari regimi legislativi. Nel caso tali obblighi “istituzionali” dovessero contrastare con i dettami fondamentali della GPL, allora il prodotto in questione non potrebbe più essere distribuito. Come esempio, la ‘Sezione 7’ porta - non a caso - l’eventuale contrasto dei termini della licenza con la normativa brevettuale in alcuni paesi.[99]
La ‘Sezione 9’ si riferisce ai diritti di copyright sul testo stesso della licenza (vedi poco sopra) e si configura come una norma di apertura, dato che con essa la Free Software Foundation si riserva la possibilità di pubblicare revisioni o nuove versioni della GPL (identiche nello spirito ma più precise nei dettagli), “al fine di coprire nuovi problemi e nuove situazioni.”
La ‘Sezione 10’ prevede la possibilità di armonizzare i differenti regimi giuridici nel caso in cui un programma coperto da GPL sia incorporato in altri programmi liberi coperti però da altri tipi di licenze.
Le ‘Sezioni 11 e 12’ rappresentano invece la parte più determinante dal punto di vista del diritto civile in generale, trattandosi di uno “scarico di responsabilità” per coloro che hanno partecipato allo sviluppo e alla distribuzione del software libero. La ‘Sezione 11’, incentrata sull’assenza di garanzia (sia essa implicita o esplicita), specifica che “l’intero rischio concernente la qualità e le prestazioni del programma è dell’acquirente”; la ‘Sezione 12’ contempla invece l’assenza di responsabilità per danni (“generici, speciali o incidentali”), menzionando alcune fattispecie esemplari di “danni che conseguono dall’uso o dall’impossibilità di usare il programma” (perdita dei dati o difficoltà nell’interazione con altri programmi).
E’ una scelta pacificamente condivisibile quella di inserire queste due sezioni, dato che la singolare modalità di sviluppo dell’opera solo per assurdo potrebbe configurare una responsabilità in capo ad un soggetto così indefinito! E’ opportuno quindi che chiunque decida di usare un software libero sia informato chiaramente di tale sua natura (non a caso le due sezioni in esame sono scritte in carattere ‘tutto maiuscolo’, risultando così maggiormente visibili).
Dopo la ‘Fine dei termini e delle condizioni’, è apposta un’appendice esemplificativa su come servirsi in modo corretto della General Public License, contenente un fac-simile delle annotazioni di copyright che si necessitano affinché una nuova opera software sia considerata coperta a tutti gli effetti da tale licenza.[100]

6. IL PROBLEMA DELLA ‘VIRALITÀ’ E LA LESSER GPL. – Le prime applicazioni della GPL hanno fatto però emergere un problema di tipo pratico, derivante proprio da una caratteristica specifica e peculiare della licenza: la sua ‘viralità’[101]. Cioè la sua capacità di trasmettere presso un numero indefinito di utenti una certa serie di diritti e responsabilità; “in pratica tutto il codice sviluppato per funzionare in associazione con software GPL dev’essere a sua volta coperto da GPL”[102], pena la caducazione dell’intera licenza ex ‘Sezione 5’. Lo dice chiaramente il periodo finale dell’appendice esemplificativa per la corretta applicazione della GPL: “I programmi coperti da questa Licenza Pubblica Generica non possono essere incorporati all'interno di programmi non liberi.”
Ma bisogna tenere presente che il software non è un’entità statica e monolitica, bensì un insieme fittissimo di altri software, se per software intendiamo una serie di istruzioni impartite al computer Perciò è possibile che nel modello “a cascata” di ridistribuzione del software libero, grazie alla disponibilità del codice sorgente completo e alla possibilità di modifica garantite dalla GPL, qualche sviluppatore voglia scorporare il pacchetto software e rielaborarne solo una parte (che potremmo chiamare “microsoftware”), oppure decida di fare interagire un software di derivazione libera con un software proprietario.
E’ il tipico caso delle librerie[103]: esse sono delle “raccolte di funzioni” precompilate (dette routine)[104] a disposizione del computer, di cui possono “servirsi” i programmi veri e propri che vengono eseguiti, pur non facendo realmente parte dei programmi stessi. In questo modo può facilmente verificarsi che un software libero si appoggi su un libreria di origine proprietaria e viceversa. Quindi un’eccessiva rigidità (come per certi versi è quella della GPL) può risultare controproducente allo sviluppo di software libero: uno sviluppatore GNU che volesse creare una libreria sotto i parametri del copyleft saprebbe che poi molti utenti di software proprietario potrebbero avere dei problemi ad usarla.
Fu per questo che, dopo che molti collaboratori del progetto GNU fecero notare questa difficoltà, la FSF decise (nel 1991) di stilare una seconda licenza, chiamata LGPL, Library General Public License[105]. E’ dunque una licenza apposita per il caso delle librerie, che si presenta come una versione della GPL alleggerita però di alcune restrizioni (per questo infatti è stata recentemente rinominata ‘Lesser GPL’, ovvero ‘GPL minore’). Ovviamente la FSF “diffida” chiunque ad usare questa licenza per software che non siano librerie, pena l’esclusione del programma così distribuito dalla “famiglia” del software libero.

7. ALTRE IMPORTANTI LICENZE PER SOFTWARE. – Sulla scia dei segnali di successo raccolti nell’ambito della comunità hacker (e non solo) dalla licenza di Stallman, cominciarono a diffondersi altre licenze per software che – pur con funzioni e criteri diversi – si ispiravano al modello individuato dalla FSF. Ne vediamo alcune con maggiore attenzione.

7.1. LA BSD LICENSE. – La BSD License ha le sue radici, negli anni d’oro della scienza informatica, in un progetto che potrebbe essere considerato addirittura come precedente al progetto GNU. L’acronimo BSD si riferisce alla Berkley Standard Distribution, ovvero la versione di Unix sviluppata negli anni 70 dalla prestigiosa università californiana con il modello di libera condivisione tipico dell’epoca[106]. Quando poi (alla fine degli anni 80) la compagnia produttrice di software AT&T decise di commercializzare Unix ci fu un’inversione di tendenza e ovviamente le nuove versioni del sistema operativo contenevano codice BSD inframmezzato da codice proprietario. Dunque gli sviluppatori originari della BSD separarono il proprio codice dal resto del sistema operativo; si impegnarono poi a ‘riempire i buchi’ e, una volta trasformata la BSD in un sistema operativo completo e indipendente, iniziarono a ridistribuirla sotto una nuova singolare licenza rilasciata dalla University of California (appunto la BSD license). Costoro dopo qualche anno (nel 1993) si organizzarono nel “FreeBSD Project” con lo scopo di coordinare lo sviluppo del software e di rilasciarne le versioni aggiornate. La prima versione (1.0) risale al 1993, mentre nel 1999 si era già giunti alla versione 3.0.[107]
Si tratta questa di una licenza piuttosto asciutta, senza componenti ideologiche o programmatiche e parti esemplificative, i cui termini risultano sintetici e essenziali e la cui applicazione si risolve nell’inserimento di una breve nota standard da inserire nei file che s’intendono tutelare con la licenza. La nota (detta ‘template’, ovvero ‘sagoma’) deve riportare il nome di chi detiene il copyright (owner), l’organizzazione a cui egli appartiene e l’anno di realizzazione. Il testo della licenza prosegue poi specificando che, del software così tutelato, sono permesse la ridistribuzione e l’utilizzo in forma sorgente o binaria, con o senza modifiche, ma solo se vengono rispettate tre condizioni:
- le ridistribuzioni del codice sorgente devono mantenere la nota sul copyright;
- le ridistribuzioni in forma binaria devono riprodurre la nota sul copyright, l’elenco delle condizioni e la successiva avvertenza nella documentazione e nell’altro materiale fornito con la distribuzione;
- il nome dell’autore non potrà essere utilizzato per sostenere o promuovere prodotti derivati dal software licenziato, senza un apposito permesso scritto dell’autore.
In fine si trovano gli avvertimenti (disclaimer) sull’assenza di garanzia e sullo scarico di responsabilità, che ricalcano grossomodo lo schema dei loro corrispondenti all’interno della GPL[108]. Un attento osservatore dell’Opensource come strategia commerciale qual è Brian Behlendorf cristallizza in modo efficace e colorito lo spirito della BSD: “Ecco il codice, fateci quello che volete, non c'interessa; solo, se lo provate e lo vendete, datacene credito”.[109]
E’ il caso invece di mettere in luce la caratteristica più problematica di tale licenza, ovvero la possibilità di usare il codice da essa tutelato per sviluppare software proprietari: aspetto che la pone al di fuori del paradigma di ‘copyleft’, poiché non è garantita la trasmissione all’infinito dei diritti da essa concessi, i quali si interrompono nel momento in cui il codice diventa proprietario. Tuttavia, storicamente, le dispute più accese riguardanti la BSD non derivavano da questa caratteristica (d’altronde l’importante era che venisse dichiarato esplicitamente che non si trattava di ‘software libero’ nel senso voluto dalla FSF), bensì quella che venne chiamata la “clausola pubblicitaria”. La clausola obbligava l’utente a “dare esplicito riconoscimento all’Università [Berkeley] nelle eventuali inserzioni pubblicitarie previste per i programmi derivati”[110]. Ma col tempo alcuni sviluppatori aggiunsero alla clausola i nomi di altre organizzazioni che avevano sostenuto lo sviluppo del software, comportando che dovessero essere citati sempre più soggetti nelle inserzioni.[111]
Questo ingombrante effetto a catena portò nel 1999 l’università californiana a decidere di eliminare quella clausola dalla versione ufficiale della licenza. Da quel momento cessò anche “l’ostracismo” dimostrato da Stallman nei confronti della BSD license, la quale nonostante tutto vanta una discreta diffusione (probabilmente grazie anche al fatto di essere strettamente connessa con il sistema Unix[112] e con il sistema Apache).

7.2. LA MOZILLA PUBLIC LICENSE. – Quella del progetto Mozilla[113] è una storia altrettanto interessante e per inquadrarne la dinamica è necessario ricollegarsi a quanto detto nel capitolo precedente riguardo alla scelta rivoluzionaria compiuta per la distribuzione del software Netscape Navigator[114]. Quando infatti la Netscape decise di diffondere il sorgente del suo prodotto di punta, dovette fare i conti con una situazione abbastanza diversa da quella in cui si trovava il progetto GNU: quest’ultimo infatti aveva degli intenti propagandistici e no-profit che non potevano armonizzarsi invece con la realtà di una grande azienda. Bisognava quindi “liberare il sorgente” senza però rendere il software un effettivo software libero, nel senso voluto dalla FSF, dato che non si voleva precludere la possibilità di inframmezzarlo con codice di natura proprietaria; bisognava anche appurare se qualcuna delle licenza già comparse sul mercato fosse stata adeguata al tal fine.
I grandi nomi impegnati in questo progetto (ovvero Torvalds, Raymond e O’Reilly) consultarono esperti di informatica, diritto e marketing, prendendo in esame le caratteristiche delle licenze GPL, LGPL e BSD. La prima venne subito esclusa per la sua rigidità nel proibire la contaminazione con codice di derivazione proprietaria e per il cosiddetto problema della “effetto virale” di questa sua rigidità; la seconda, in quanto versione più aperta e permissiva della sua “sorella maggiore”, poteva essere più appetibile, “ma conteneva ancora troppi dei tranelli della GPL”[115]; la BSD pur nella sua semplicità ed elasticità, fu però giudicata insufficiente allo sviluppo del progetto.
Non c’erano dubbi: era giunto il momento di stilare una nuova apposita licenza, che, a detta dei loro promotori, si sarebbe posta come un primo tentativo di compromesso fra i criteri giuridico-ideologici del software libero tradizionale e lo sviluppo a livello aziendale di software a sorgente aperto. Nacque così la Netscape Public License (NPL), il cui testo venne diffuso a titolo informativo in un newsgroup telematico per testare il livello di gradimento da parte degli utenti: era il 5 marzo 1998[116]. Da subito il feedback ricevuto da tutta la comunità Opensource si rivelò estremamente critico: la licenza infatti, con una certa contraddittorietà, riservava alcuni privilegi al detentore originario dei diritti nella distribuzione del codice sorgente; essa dava a Netscape il privilegio di porre sotto un’altra licenza le modifiche fatte al suo software, perciò l’azienda poteva tenere come private quelle modifiche, approfittarne per migliorare il software e rifiutarsi di ridistribuire il risultato[117]; per di più veniva riservata a Netscape anche la possibilità di redigere versioni aggiornate della NPL, alla stregua di quanto faceva la FSF con la GPL (con la differenza che la FSF era un’organizzazione no-profit e non un’impresa con interessi economici).
Preso atto di questa “falsa partenza” da archiviare, i coordinatori del progetto però riconfermarono strenuamente e prontamente la loro vocazione per l’Opensource e nell’arco di due settimane seppero rivisitare la loro impostazione. Il 21 marzo infatti venne diffusa una nuova licenza, libera da quei privilegi che avevano generato tante critiche: la Mozilla Public License (MPL), che prese il suo nome stravagante da un nomignolo[118] usato scherzosamente dagli sviluppatori della Netscape; essa era stata predisposta per operare “all’interno della NPL” ed era identica a quest’ultima tranne che nella mancanza dei privilegi. Il codice di Navigator fu dunque pubblicato per la prima volta il 31 marzo 1998 sotto licenza NPL; il codice da qui derivato poteva invece essere sotto MPL (o sotto ogni altra licenza compatibile) e quindi poteva essere inserito (in grado variabile) all’interno di un pacchetto di software commerciale. In questo modo il Progetto Mozilla riusciva finalmente ad assecondare il duplice intento di diffusione a sorgente aperto e di proficua strategia aziendale.
Ancora Behlendorf ci fa perspicacemente notare una particolarità di tipo giuridico nella nuova licenza: infatti, in essa più che in altre licenze anteriori, sono presenti alcune rilevanti clausole (precisamente nella ‘Sezione 2’)[119] mirate a tutelare gli sviluppatori del progetto Mozilla dalla malafede di coloro che avrebbero potuto approfittare della elasticità della licenza, inserendo tacitamente parti di codice coperte da brevetto, per poi rivendicarne per vie legali il pagamento. “La licenza […] prescrive che l'azienda o l’individuo che contribuisca con codice al progetto rinunci ad ogni possibile pretesa a diritti di brevetto a cui il codice potrebbe dare adito.”[120]
La licenza Mozilla[121], tuttora usata per i browser Netscape, resta incompatibile con la GPL - per i motivi già esposti a proposito della NPL - ma può essere finalmente qualificata come licenza Opensource, nel senso in cui tale concetto proprio in quegli anni andava delineandosi[122].

8. UNA SORTA DI “PATROCINIO” SULLE LICENZE. – Come abbiamo già rilevato nella dinamica storica e antropologica del movimento Opensource, nel 1998 la diffusione di software sotto licenze diverse dal concetto tradizionale di licenza d’uso era diventata una prassi ormai radicata e la scelta “illuminata” di Netscape rappresentò l’avvenuta maturazione dei tempi per una – per così dire – istituzionalizzazione dell’Opensource.
Le più rappresentative e carismatiche personalità della comunità emergente cominciarono a cogliere la necessità di fare chiarezza (anche da un punto di vista giuridico) sul fenomeno che avevano strenuamente sostenuto e pensarono di organizzarsi in gruppi di lavoro e associazioni che coordinassero i vari progetti e ne mantenessero alta la visibilità. Una volta costituite tali organizzazioni e confermata la loro credibilità a livello internazionale, esse iniziarono un’opera di cernita, commento e consulenza sui testi delle licenze che via via si trovavano in circolazione, segnalando quali fossero le più indicate a determinate finalità: una sorta di “patrocinio”, una certificazione di conformità allo spirito dei vari progetti.

8.1. LA OPEN SOURCE DEFINITION. – I primi a muoversi in questo senso furono proprio alcuni degli artefici di Mozilla, i quali sotto la guida di Eric Raymond costituirono la Open Source Initiative (di cui abbiamo già parlato) con lo scopo appunto di farsi supremi custodi e garanti del concetto di ‘software Open Source’. Come base per questo progetto, la OSI raccolse i suoi esperti di informatica e di diritto per stilare una sorta di documento-decalogo in cui venissero delineati gli standard secondo i quali un software potesse essere definito Open Source: la Open Source Definition, ovvero la ‘definizione di open source’.
Fedele alla sua vocazione di “statuto dei diritti dell’utente” questo testo focalizza la centralità di tre diritti primari che la tipologia di distribuzione del software deve rispettare:
- il diritto di fare copie del programma e di ridistribuirle liberamente,
- il diritto di accesso al codice sorgente,
- il diritto di poter intervenire sul programma e modificarlo.[123]
Dunque la Open Source Definition (OSD) non è un modello di licenza per software opensource (come qualcuno potrebbe pensare) bensì una “specifica di quanto è ammesso in una licenza software perché possa essere considerata Open Source” [124]; può esser vista, in un certo senso, come una “licenza per le licenze”.
Dopo una breve introduzione che ammonisce il lettore a non considerare ‘Open Source’ come semplice sinonimo di ‘disponibilità del sorgente’, il documento si estrinseca in 10 sezioni che da un lato chiariscono e riconfermano alcuni principi cardine del software libero, dall’altro ne creano alcuni indipendenti ed appositi per il concetto di Open Source. Per esempio, nel primo gruppo, ovvero quello coerente a grandi linee con quanto abbiamo già incontrato a proposito della GPL, possiamo inserire la ‘Sezione 1’ (sulla libertà della ridistribuzione), la ‘Sezione 2’ (sulla disponibilità del codice sorgente), la ‘Sezione 3’ (sulla possibilità di apporre modifiche e realizzare così opere derivate), le ‘Sezioni 5 e 6’ (sul divieto di discriminazione di persone o settori di applicazione).
Altre disposizioni sembrano invece allontanarsi dalle finalità della GPL: basti pensare alla ‘Sezione 9’ (sui rapporti fra diversi regimi di licenza), la quale stabilisce che “la licenza non deve contaminare altro software”: letto così, tale imperativo sembrerebbe concepito solo ed appositamente per contrapporsi alla ‘viralità’ della GPL, ma ad un’attenta lettura si può notare che la sezione in esame si riferisce non alla derivazione ma alla mera aggregazione; cioè non si riferisce alla miscelazione di codice libero/aperto con codice proprietario (derivazione), bensì alla distribuzione su un unico media (CD-ROM o floppy-disk) di un software Open Source e di uno proprietario (aggregazione).[125]
Molto interessante dal punto di vista giuridico la ‘Sezione 7’, che sottolinea la trasposizione automatica degli effetti della licenza a tutti coloro ai quali il programma è ridistribuito senza necessità di alcuna firma o di necessità di una ulteriore licenza per ogni “gradino” della distribuzione.[126]
Un discorso a parte merita invece la ‘Sezione 10’, recentemente novellata per intero a causa dei problemi di poca lungimiranza ed elasticità che il suo dettato denotava. Nella versione originale[127] essa faceva cenno ad alcune “licenze esemplari” da considerarsi modelli conformi alla OSD, che erano la GNU GPL, la BSD, la X Consortium e la Licenza Artistica; questa elencazione avrebbe però creato problemi di interpretazione della OSD nel caso (nemmeno molto improbabile) che una di queste fosse stata modificata così da risultare invece incompatibile col concetto di Open Source. Si è deciso così di eliminare ogni richiamo preciso ad alcune licenze e di sostituirlo con una nuova sezione del tutto diversa ma stavolta molto lungimirante e scaltra: s’introduce il concetto (finora non ufficialmente contemplato dai “manifesti” del movimento Opensource) della neutralità della tecnologia. Si proibisce infatti di usare la licenza di un software Open Source per creare eventuali privilegi in ambito hardware; la libertà del software diventa quindi un by-pass per toccare un altro tema scottante: le implicazioni col diritto industriale fra hardware, software e disciplina antitrust. Infatti, per il già citato fenomeno delle network externalities[128], i diritti di proprietà d’intellettuale possono avere ‘effetti di rete’ limitativi della libertà di scelta del consumatore. Questa dunque la breve enunciazione della ‘Sezione 10’: “La licenza dev’essere tecnologicamente neutrale. Nessuna condizione della licenza può essere prevista per qualche particolare tecnologia o tipo di interfaccia.”
Eliminato dunque dalla OSD ogni richiamo formale ed esplicito ad alcune licenze, la OSI però intraprese comunque – come abbiamo già accennato – un’opera di cernita e monitoraggio delle licenze in circolazione, definendo nel sito ufficiale del progetto quali di queste andassero intese come “Open Source compatibili”.
L’obbiettivo della OSI, a dire il vero, è molto più ambizioso: cioè addirittura trasformarsi in una specie di “consorzio” che vigili sulla corretta interpretazione e applicazione della Open Source Definition, attribuisca una certificazione ai prodotti che ne rispettavano i principi e apponga su di essi un marchio di garanzia. Inizialmente è stata richiesta la registrazione dell’espressione “Open Source” come marchio, ma l’autorità americana a ciò preposta non l’ha accettata poiché troppo generica e descrittiva; la OSI ha dunque optato per il meno equivocabile “OSI certified”, cioè “certificato dalla OSI”.[129]
La OSI quindi non solo consente l’uso dell’espressione Open Source per i software che rispettino i criteri della OSD, ma autorizza su di essi l’apposizione ufficiale del marchio registrato; si crea così un riconoscimento più forte di quello che abbiamo simbolicamente chiamato “patrocinio”, espressione più calzante per la prassi utilizzata dalla FSF.
Sul sito ufficiale della OSI si trova un’apposita pagina web[130] contenente i termini e le formalità utili per perfezionare il procedimento di apposizione del marchio e i file d’immagine in diversi formati con lo stemma grafico da inserire sui supporti stampati: la formula ufficiale è “ This software is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative” (cioè, “Questo software è un software Open Source certificato dalla OSI. ‘OSI certified’ è un marchio di certificazione della Open Source Initiative”). Nel sito, inoltre è presente un elenco costantemente aggiornato di tutte le licenze che hanno appunto ricevuto tale riconoscimento, così da consentire all’utente di verificare in tempo reale l’effettiva corrispondenza di un software ai requisiti della OSD ed ovviare eventuali abusi.
Tornando all’analisi esplicativa e comparativa compiuta da Perens nel suo saggio-manifesto, è possibile rileggere le principali licenze di software che abbiamo fin qui esaminato alla luce dei criteri della Open Source Definition, rilevando quattro fondamentali aspetti:
- la possibilità che il codice (sotto quella particolare licenza) venga miscelato con codice di matrice commerciale;
- la possibilità che le modifiche apportate al codice siano mantenute, senza quindi essere restituite all’autore originale;
- la possibilità che il codice così realizzato venga liberamente ri-licenziato da chiunque;
- la permanenza di alcuni privilegi speciali sulle modifiche per chi detiene il copyright originale.
E’ possibile ora costruire un tabella a doppia entrata che metta in relazione questi parametri con le caratteristiche delle sei modalità di distribuzione che abbiamo esaminato: ovvero la GNU GPL, la GNU LGPL, la BSD license, la Netscape Public License, la Mozilla Public License e infine il dominio pubblico[131].

N.B.: La tabella riprende la schematizzazione effettuata da Perens
nel saggio The Open Source Definition.

8.2. IL RUOLO DELLA FREE SOFTWARE FOUNDATION. – Come abbiamo già accennato, anche la Free Software Foundation, dall’alto della sua posizione privilegiata (e unanimemente riconosciuta) di prima custode della libertà nel software, ha da sempre sfruttato la visibilità e la credibilità derivatele da un a personalità come Stallman per guidare gli utenti di software verso una corretta qualificazione del concetto di software libero. I meccanismi con cui questa organizzazione ha conferito il suo benestare (oppure ancora “patrocinio”) alle diverse licenze in circolazione, sono però piuttosto diversi da quelli prescelti dalla Open Source Initiative.
Per prima cosa la FSF non usa come modello di riferimento un documento-manifesto quale può essere considerato la OSD, bensì una vera e propria licenza che funge – ma solo in seconda battuta – anche da manifesto: ovvero la GPL, che viene “solennemente” elevata al grado di licenza del ‘free software’ per eccellenza. Essa diventa in tal modo l’unica vera licenza che realizza appieno le quattro libertà basilari previste dalla ‘free software definition’ (d’ora in poi FSD):
- la libertà di eseguire il programma, per qualsiasi scopo (libertà 0);
- la libertà di studiare come funziona il programma e adattarlo alle proprie necessità (libertà 1);
- la libertà di ridistribuire copie in modo da aiutare il prossimo (libertà 2);
- la libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti, in modo tale che tutta la comunità ne possa trarre beneficio (libertà 3). Ovviamente l’accesso al codice sorgente è considerato come prerequisito essenziale alla ‘libertà 1’ e alla ‘libertà 3’.[132]
Inoltre, coerentemente con i principi di libertà “totale” da essa strenuamente difesi, la FSF non avrebbe mai potuto condividere la scelta di registrazione di un marchio di certificazione; senza poi calcolare che, se la OSI ha incontrato problemi nella richiesta di registrazione a causa della eccessiva descrittività e genericità dell’espressione Open Source, tanti più se ne avrebbero a voler definire giuridicamente un concetto così ampio come quello di ‘libertà’. Lo stesso Stallman, che già dai primi passi della OSI aveva esternato le sue aspre critiche per l’intera impostazione del progetto, si è sempre palesato contrario ad un simile meccanismo di controllo giuridico sul rispetto dei criteri dell’Opensource. Uno dei suoi più significativi saggi[133] contiene non a caso un paragrafo intitolato “Un marchio registrato può aiutare?” in cui l’hacker sostiene l’inutilità della mossa di Raymond e Perens, comprovata – a suo dire – sia dal tentativo fallito di registrare ‘Open Source’ come marchio, sia dal fatto che alcune aziende sono riuscite spesso a presentare come open source dei programmi non OSD-compatibili, pur senza usare nel materiale divulgativo la precisa espressione ‘Open Source’ e creando in tal modo ulteriore confusione nel pubblico.[134]
In definitiva, Stallman (e quindi la FSF) è di gran lunga più propenso a conferire quella sorta di “patrocinio” a progetti o licenze, sfruttando fin dove possibile quella storica e monolitica tradizione di valori etici e di esperienza sul campo che solo la FSF può vantare; senza quindi “impantanarsi” nelle insidie della burocrazia e mantenendo una più opportuna elasticità e informalità nel procedimento. La lista delle licenze di software prese in considerazione nel sito della FSF[135] è più semplicemente divisa in licenze per software non libero (quindi di per sé incompatibili con la GPL e con la FSD) e licenze per software libero; quest’ultima categoria è a sua volta bipartita in ‘licenze di software libero compatibili con la GPL’ e ‘licenze di software libero incompatibili con la GPL’. Ovviamente il concetto di compatibilità usato in questo caso, non si riferisce solamente ad una coerenza con i principi della GPL ma più tecnicamente alla possibilità di combinare il codice così tutelato con codice sotto licenza GPL.
In base a questa classificazione e ad alcune annotazioni sui principali parametri presi in esame, è possibile anche in questo caso compilare una tabella a doppia entrata riferita alle stesse licenze prese in considerazione nello scorso paragrafo.

------------------------------------------

NOTE AL CAPITOLO III

[56]- Per questa differenziazione v. L.C. UBERTAZZI, I diritti d’autore e connessi. (Scritti, quaderni di AIDA n.5), Giuffrè, Milano, 2000, cap. II.
[57]- v. supra cap. II, par. 3.
[58]- “Ben presto si ebbe una crescita enorme degli investimenti in software e la partecipazione a questi investimenti degli stessi produttori di hardware, cosicché la valutazione negativa sulla proteggibilità dei programmi venne meno, ed anzi a tale valutazione si sostituì una valutazione positiva così favorevole alla protezione del risultato del lavoro intellettuale del programmatore così da considerare preferibile la protezione della forma di espressione del programma, come tipicamente è quella del diritto d’autore, alla protezione del contenuto del programma, come invece è quella brevettuale.” Cfr. FLORIDIA, Le creazioni intellettuali a contenuto tecnologico, (Cap. I, par. 5), in AA.VV., Diritto Industriale - Proprietà intellettuale e concorrenza, Giappichelli, Torino, 2001, p. 205.
[59]- Le creazioni oggetto del diritto d’autore, secondo la definizione preliminare effettuata dalla legge italiana sul diritto d’autore (L. 633/1941: d’ora innanzi “l.a.”) sono le opere dell’ingegno di “carattere creativo”. Per una chiara presentazione di tale nozione, v. AUTERI, Diritto d’autore, in AA.VV., Diritto Industriale - Proprietà intellettuale e concorrenza, Giappichelli, Torino, 2001, pp. 490 ss.; inoltre v. diffusamente L.C. UBERTAZZI, I diritti d’autore e connessi (cit.).
[60]- Agreement on Trade Related Intellectual Property rihgts, accordi internazionali firmati a Marrakech nel 1994 nell’ambito dell’Uruguay Round per la costituzione del WTO (World Trade Oragnization).
[61]- L’estratto è riportato anche da AUTERI, op. cit., pp. 496 ss; l’autore, in questo stesso paragrafo, analizza anche l’importante distinzione fra forma esterna, forma interna e contenuto di un’opera dell’ingegno.
[62]- Questa nuova categoria di opere dell’ingegno comprende anche il design industriale e le banche dati; v. AUTERI, op. cit., Cap. II, par. 7, pp. 501 ss.
[63]- Per una trattazione approfondita di questa natura giuridicamente ambigua del software, v. FRASSI, Creazioni utili e diritto d’autore, Giuffrè, Milano, 1997.
[64]- Per una schematica presentazione degli elementi portati a favore o a detrimento della brevettabilità del software v. CIAMPI, Profili comparatistici della protezione del software nella legislazione e nella prassi contrattuale, in ALPA e ZENO-ZENCOVICH (a cura di), I contratti d’informatica, Giuffrè, Milano, 1987, p. 339.
[65]- Così FLORIDIA, op. cit., Cap. I, par. 5, p. 205.
[66]- v. CIAMPI, op. cit., pp. 340-341; per una ancor più approfondita visuale comparatistica della tutela legislativa del software v. FRASSI, op. cit. (par. 2.2. e par. 2.4.).
[67]- Fu introdotto anche un secondo comma all’art. 1 della legge sul dir. d’autore, che recita: “Sono altresì protetti i programmi per elaboratore come opere letterarie ai sensi della Convenzione di Berna sulla protezione delle opere letterarie ed artistiche ratificata e resa esecutiva con l. 20 giugno 1978, n. 399.” Il numero 8 introdotto invece nell’art. 2 l.a. ci fornisce la definizione legislativa di software, precisando che fra le opere tutelate dalla stessa legge si annoverano anche “i programmi per elaboratore, in qualsiasi forma espressi purché originali quali risultato di creazione intellettuale dell’autore. […]”
[68]- Fra questi AUTERI, op. cit., p. 505.
[69] - “Ciò consente, da un lato, di ammettere che i programmi possano avere carattere creativo in un senso non molto diverso da quello che questo concetto ha in generale in materia di diritto d’autore, dall’altro lato, consente di limitare la tutela alla forma ‘espressiva’ […] senza investire il contenuto […]. Cfr. AUTERI, op. cit., p. 505.
[70]- v. a tal proposito AUTERI, op. cit., pp. 543-545.
[71]- Velia Maria Leone approfondisce così la portata giuridica del concetto di esclusiva: “La succitata esclusiva esplica i suoi effetti in due principali direzioni, di cui l’una è la conseguenza dell’altra: la prima consentendo al titolare di vantare un diritto allo sfruttamento della creazione di cui è autore; la seconda, quale espressione della prima, consistente nel potere autorizzativo-inibitorio dell’autore nei confronti dello sfruttamento dell’opera da parte di terzi.” LEONE, La concessione del software fra licenza e locazione, in ALPA e ZENO-ZENCOVICH (a cura di), I contratti d’informatica, Giuffrè, Milano, 1987, p. 354.
[72]- Per un approfondimento onnicomprensivo degli aspetti contrattuali relativi all’informatica, si consiglia la lettura integrale del volume (per molti aspetti ancora attuale) curato da ALPA e ZENO-ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1987.
[73]- Cfr. LEONE, op. cit., p. 355.
[74]- A complicare la questione (già abbastanza oscura a livello di puro diritto privato) sopraggiunge il diritto d’autore, che (con l’art. 64 bis, lettera ‘c’) applica al diritto di distribuzione del software il cosiddetto principio dell’esaurimento, in base al quale il titolare dei diritti non mantiene il diritto di controllare la circolazione dell’opera una volta che l’abbia destinata al mercato. A tal proposito, v. SARTI, Esaurimento ed utilizzazione del software, in L.C. UBERTAZZI (a cura di), La legge sul software, Giuffrè, Milano, 1994; oppure SANTO, Le licenze pubbliche GNU, tesi di laurea, Università degli Studi di Pavia, Fac. di Giurisprudenza, aprile 2003; cap. I, par. 4.
[75]- Cfr. LEONE, op. cit., p. 359.
[76]- Per maggior chiarezza su questa dicotomia, v. la differenziazione in corpus mechanicum (software come bene materiale) e corpus mysticum (software come opera dell’ingegno) sostenuta anche in LEONE, op. cit., p. 359.
[77]- La serie di definizioni segue il modello proposto da RAGUSA, op. cit.; gli stessi concetti sono riportati anche da BASSI, op. cit., pp. 2 ss. (par. 1.2.); e da SISTO, Le diverse modalità di distribuzione del software: freeware, shareware e trial version in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1058 ss.
[78]- “Alcune volte, il solo fatto di aprire la confezione esterna, in plastica trasparente del packaging, equivale ad accettazione [dei termini] della licenza, leggibile all’interno della scatola, senza attendere l’accettazione esplicita durante l’installazione del prodotto.” Cfr. RAGUSA, op. cit., par. 3.3.4. Nel caso portato dalla Ragusa, si parla di shrink-wrap licenses: per un approfondimento, v. SARTI, op. cit., pp. 146-149. Gran parte della dottrina italiana ne esclude la validità e assimila queste “licenze a strappo” alla categoria delle clausole vessatorie: in questo senso v. D’ARRIGO, Prospettive della c.d. licenza a strappo nel nostro ordinamento, in Dir. Inf. 1996, pp. 462-468.
[79]- Una delle più comuni occupazioni degli hacker è proprio l’elusione di questi meccanismi, riuscendo così a trasformare le versioni di prova in versioni perfettamente funzionanti (senza alcuna spesa per l’acquisizione della licenza, ma violando così le norme sul copyright).
[80]- In questo caso l’aggettivo ‘free’ è usato nel significato puro e semplice di ‘gratuito’, a differenza che nell’espressione ‘free software’. Per questi risvolti semantici v. supra: cap. II, par. 8 e relative note.
[81]- Una diffusa strategia di mercato, chiamata network externalities e applicata soprattutto all’impresa del software, mira a creare con la diffusione gratuita di programmi o di file in determinati formati una rete di distribuzione da sfruttare con la vendita del prodotto di punta. Consideriamo il caso esemplare dei software Acrobat Reader e Adobe Acrobat, dedicati alla lettura (il primo) e alla composizione (il secondo) dei file in formato PDF. L’azienda Acrobat prima ha cercato di diffondere l’uso del formato PDF distribuendo gratuitamente (freeware) il lettore; successivamente ha potuto avvantaggiarsi della vendita del compositore (software commerciale) di cui gli utenti hanno bisogno per creare a loro volta file PDF.
A tal proposito, v. LEMLEY e MCGOWAN, Legal implications of Network Economics Effects, in California L. Rev.,1998.
[82]- Per una definizione del concetto di ‘software libero’ vedi POTORTÌ, Che cos’è il software libero, Ass. Software Libero, 2002; disponibile alla pagina web http://www.linux.it/GNU/softwarelibero.shtml oppure alla pagina web http://softwarelibero.it/documentazione/softwarelibero.html. Per la definizione di software opensource invece v. PERENS, The Open Source Definition, in AA.VV., Open Sources (cit.).
[83]- Bassi parla anche di altre categorie (free software non-copylefted e semi-free software) che però a ben vedere si possono intendere come già comprese nei tre modelli qui esposti; v. BASSI, op. cit., p. 4 (par. 1.2.).
[84]- “Per trasformare un programma in copyleft, prima lo dichiariamo sotto copyright; poi aggiungiamo i termini di distribuzione, strumento legale onde garantire a chiunque il diritto all'utilizzo, alla modifica e alla ridistribuzione del codice di quel programma o di qualsiasi altro da esso derivato, ma soltanto nel caso in cui i termini della distribuzione rimangano inalterati. Così il codice e le libertà diventano inseparabili a livello legale.” Tratto da Che cos’è il copyleft? (scritto nel 1996) in STALLMAN, Software libero, pensiero libero (cit.); la versione originale di questo saggio è disponibile su http://www.gnu.org/licenses/licenses.html#WhatIsCopyleft .
[85]- Cfr. STALLMAN, Che cos’è il copyleft? (cit.). Gli stessi principi espressi nel saggio sono condensati nel preambolo della licenza GPL, di cui parleremo fra poco e disponibile in versione integrale e tradotta in appendice. Ne segnaliamo qui una frase in particolare: “[…]chi distribuisce copie di un programma coperto da GPL, sia gratis che in cambio di un compenso, deve concedere ai destinatari tutti i diritti che ha ricevuto.”
[86]- Riguardo le singolari etimologie del gergo hacker, v. supra cap. II, par. 2.
[87]- v. anche l’emblematica grafica di copertina di questa nostra opera.
[88]- Obblighi che poi rientrano nella tradizionale classificazione civilistica di obblighi di dare, di fare e di non fare.
[89]- Bruce Perens, uno dei padri della Open Source Initiative, dice proprio che “la Open Source Definition è una carta dei diritti dell’utente del computer.” Cfr. PERENS, The Open Source Definition, in AA.VV., Open Sources (cit.), introduzione.
[90]- Per una generale analisi giuridica (basata sul diritto statunitense) del fenomeno copyleft v. HILL, Fragmenting the copyleft movement: the public will not prevail, in Utah L. Rev. 1999, 797; PATTERSON, Copyright misuse and modified copyleft: new solutions to the challenges of internet standardization, in Mich. L. Rev. 2000, 1351.
[91]- Il principale consulente giuridico del progetto GNU è Eben Moglen, docente presso la Columbia Law School; un suo dettagliato curriculum e una sua completa bibliografia sono disponibili sul sito http://emoglen.law.columbia.edu/.
[92]- “La retorica politica presente nella GPL non è gradita a tutti. Non manca chi ha scelto, per il suo software, licenze non altrettanto adatte per semplice avversione alle idee di Richard Stallmann, pur di non voler vederle ripetute nei propri pacchetti software.” Cfr. PERENS, The Open Source Definition, in AA.VV., Open Sources (cit.), par. La GNU General Public License.
[93]- “E’ così che la GPL rimane una delle migliori creature partorite da Stallman. Grazie ad essa, venne a crearsi un sistema di proprietà condivisa all’interno dei normali confini della legislazione sul copyright.” Cfr. WILLIAMS, op. cit. (cap. 9 – La GNU General Public License).
[94]- In Inglese infatti ‘public’ può assumere un significato esteso di ‘democratico’, ‘aperto a tutti’ che invece nella nostra tradizione linguistica non si coglie appieno.
[95]- Traduzione curata da Gruppo Pluto, da Italian Linux Society e dal gruppo italiano di traduzione GNU (aggiornata al 19 aprile 2000), disponibile sul sito http://www.softwarelibero.it/gnudoc/gpl.it.txt .
[96]- La versione originale in Inglese riporta “section”, che è stato tradotto (forse un po’ troppo liberamente) in “commi” nella traduzione italiana di riferimento (v. nota precedente). Qui manterremo la traduzione più neutrale “sezione”.
[97]- Lo stesso titolo della parte che abbiamo informalmente chiamato “licenza vera e propria” fa esplicito riferimento a queste tre attività. Cfr. testo della licenza in appendice.
[98]- Per i lettori più esperti di informatica, si riporta la definizione: “Per un programma eseguibile, ‘codice sorgente completo’ significa tutto il codice sorgente di tutti i moduli in esso contenuti, più ogni file associato che definisca le interfacce esterne del programma, più gli script usati per controllare la compilazione e l'installazione dell'eseguibile.” Cfr. testo integrale in appendice.
[99]- “Se non è possibile distribuire un prodotto in modo che soddisfi simultaneamente gli obblighi dettati da questa licenza e altri obblighi pertinenti, il prodotto non può essere affatto distribuito. Per esempio, se un brevetto non permettesse a tutti quelli che lo ricevono di ridistribuire il programma senza obbligare al pagamento di diritti, allora l’unico modo per soddisfare contemporaneamente il brevetto e questa licenza è non distribuire affatto il programma.”
[100]- Per un commento strettamente giuridico della GPL, si veda PERRI, I sistemi di licenza open source, in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, pp. 1091-1094.
[101]- A parlare di “viralità” è un famoso saggio dedicato al progetto Mozilla: HAMERLY e PAQUIN, con WALTON, Liberare il sorgente: la storia di Mozilla (par. Creazione della licenza), in AA.VV., Open Sources (cit.). Su questa singolare caratteristica si sofferma anche SANTO, op. cit., cap. V, par. 3.
[102]- Cfr. HAMERLY e PAQUIN, con WALTON, Liberare il sorgente: la storia di Mozilla (par. Creazione della licenza), in AA.VV., Open Sources (cit.).
[103]- Libreria è il tipico esempio di una traduzione un po’ forzata di un termine tecnico; ‘library’ ha infatti una valenza molto più ampia di quanto può apparire nella versione italiana. In Inglese ‘library’ può far riferimento anche al concetto di archivio, raccolta, collezione.
[104]- v. la definizione di ‘libreria’ riportata in glossario da DIDONÈ, op. cit.; inoltre v. la definizione data dalla ‘sezione 0’ della LGPL.
[105]- Nella sezione esemplificativa che appare in coda al testo GPL, si legge infatti: “Se il proprio programma è una libreria di funzioni, può essere più utile permettere di collegare applicazioni proprietarie alla libreria. In questo caso consigliamo di usare la Licenza Generica Pubblica GNU per Librerie (LGPL) al posto di questa Licenza.”
[106]- Per un approfondimento della storia del sistema operativo BSD, v. MCKUSICK, (op. cit.); cfr. anche supra cap. II, par.1 e relative note.
[107]- v. BASSI, op. cit. (App. B.2.).
[108]- Cfr. le ‘Sezioni 11 e 12’ della GPL nel testo integrale riportato in appendice. Vedremo che tale schema sarà poi preso a modello da gran parte delle licenze esaminate in questo saggio, sia quelle per opere software che quelle per opere non software.
[109]- Cfr. BEHLENDORF, Open Source come strategia commerciale in AA.VV., Open Sources (cit.), par. Copyright di tipo BSD. L’autore prosegue spiegando che “di solito il credito viene riscosso in diverse forme: sulla pubblicità, in un file README, nella documentazione cartacea, ecc.”
[110]- Cfr. WILLIAMS, op. cit. (cap. 9 – La Gnu General Public License).
[111]- “Quella ‘odiosa clausola pubblicitaria’ della University of California in seguito si sarebbe rivelata un problema. Alla ricerca di un’alternativa meno restrittiva della GPL, alcuni hacker ricorsero a tale clausola, sostituendo la dicitura “University of California” con il nome della propria istituzione. Risultato: i programmi di software libero che utilizzavano parti prese da decine di altri programmi dovevano citare decine di entità. Nel 1999, dopo circa dieci anni di insistenze da parte di Stallman, la University of California si trovò d’accordo a eliminare quella clausola.” cfr. WILLIAMS, op. cit. (nota n. 90).
[112]- Così PERRI, op. cit., p. 1097.
[113]- Per gli scopi e le attività del progetto v. il sito ufficiale http://www.mozilla.org/.
[114]- v. supra cap. II, par. 7.
[115]- Cfr. HAMERLY e PAQUIN, con WALTON, op. cit. (par. Creazione della licenza): gli autori si riferiscono molto probabilmente all’apparato di principi etici che – come abbiamo già visto – risulta spesso ingombrante nel testo di una licenza.
[116]- La ricostruzione storica segue il percorso presentato nel saggio Liberare il sorgente: la storia di Mozilla (cfr. nota precedente).
[117]- v. PERENS, op. cit. (par. La Netscape Public License e la Mozilla Public License); Perens precisa che “questa clausola si e resa necessaria perché, quando Netscape decise per l'Open Source, aveva contratti con altre aziende che la impegnavano a fornir loro Navigator sotto una licenza non Open Source.”
[118]- “Il nucleo del codice sorgente di Communicator, alla Netscape era chiamato Mozilla. Si trattava di un termine dapprima inventato da Jamie Zawinsky e dal suo gruppo durante lo sviluppo di Navigator. Il team stava lavorando ad un passo altrettanto frenetico per creare una "bestia" di gran lunga più potente di Mosaic e quella paroletta divenne il "code name" ufficiale di Navigator. Più tardi, il grosso dinosauro verde divenne uno scherzo fra addetti ai lavori, quindi una mascotte dell'azienda e infine un simbolo pubblico. Ora il nome comincio ad essere usato come termine generico in riferimento ai browser Web open source che sarebbero derivati dal codice sorgente di Netscape Navigator. L'intento era "liberare la Lucertola".” Cfr. HAMERLY e PAQUIN, con WALTON, op. cit.
[119]- v. testo originale della licenza.
[120]- Cfr. BEHLENDORF, op. cit. (par. La licenza pubblica Mozilla).
[121]- v. testo originale della licenza.
[122]- La nascita della Open Source Initiative era avvenuta proprio verso la fine del 1998. Cfr. supra cap. II, par. 9.
[123]- Questa è a grandi linee la schematizzazione compiuta da Perens, uno dei padri fondatori della OSI, nonché principale autore della Open Source Definition. PERENS, op. cit. (par. La Netscape Public License e la Mozilla Public License).
[124]- Cfr. PERENS, op. cit. (par. La Open Source Definition).
[125]- Così Perens nella nota di commento alla ‘Sezione 9’: v. PERENS, op. cit. (par. La Open Source Definition).
[126]- “La licenza dev’essere automatica, senza la richiesta di alcuna firma. Purtroppo, negli Stati Uniti non ci sono dati validi precedenti giudiziari del potere della licenza senza firma quando questa venga passata da una seconda a una terza parte. Tuttavia, questo argomento considera la licenza come facente parte della legge sul contratto, mentre qualcuno obietta che dovrebbe essere considerata come legge di copyright, campo in cui si danno più precedenti per quel tipo di licenza.” Cfr. PERENS, op. cit. (par. La Open Source Definition).
[127]- Ci si riferisce alla versione che si trova nel saggio di Perens, come riportato nel libro Open Sources, quindi risalente almeno al 1999 (anno di edizione del libro).
[128]- v. infra, par. 3 e relative note.
[129]- Lo stesso stemma-distintivo del progetto (che si può vedere sul sito www.opensource.com) denota una marcata efficacia grafica.
[130]- http://www.opensource.org/docs/certification_mark.php .
[131]- Sia i parametri d’analisi che la tabella, ripercorrono lo schema riportato da PERENS, The Open Source Definition (cit.).
[132]- Cfr. la pagina italiana del sito GNU dedicata alla ‘free software definition’ http://www.gnu.org/philosophy/free-sw.it.html oppure cfr. il saggio La definizione di software libero, in STALLMAN, Software libero, pensiero libero (cit.). v. anche WILLIAMS, op. cit. (cap. 8 - Sant’Ignucius, nota n.80).
[133]- STALLMAN, Perchè “software libero” è da preferire a “open source”, in Software libero, pensiero libero (cit.).
[134]- Nel paragrafo sopra citato, l’autore riporta un esempio concreto: “Ho sentito, talvolta di persona, molte aziende chiamare "open source" i loro pacchetti software anche se questi non rientravano, per le loro caratteristiche, nella definizione ufficiale. […] Le aziende inoltre hanno fatto annunci che danno l'impressione che un programma sia "software open source" senza dirlo esplicitamente. Ad esempio, un annuncio di IBM riguardo ad un programma che non rientrava nella definizione ufficiale diceva questo: "Come è comune fare nella comunità open source, gli utenti della ... tecnologia saranno inoltre in grado di collaborare con IBM ..." Questa frase non dice che il programma è "open source", ma molti lettori non hanno notato quel dettaglio.”
[135]- v. http://www.fsf.org/licenses/licenses-list.html .