MAURO SANTO

1

MAURO SANTO Le licenze pubbliche GNU

Tesi di laurea in giurisprudenza dell'Università di Pavia

discussa nell’anno accademico 2001-2002

MAURO SANTO

2

INDICE

Introduzione ……………………………………………………………………………………….

CAPITOLO PRIMO

LA TUTELA DEL SOFTWARE MEDIANTE DIRITTO D’AUTORE 1. La protezione del software. Evoluzione della disciplina e tutele diverse da quelle d’autoree di brevetto ………………………………………………………………………………….2. La tutela d’autore ……………………………………………………………………….3. I diritti esclusivi …………………………………………………………………………4. L’esaurimento ed il problema delle licenze …………………………………………….5. Le utilizzazioni libere del software ……………………………………………………..6. La durata di protezione …………………………………………………………………

CAPITOLO SECONDO LA TUTELA DEL SOFTWARE MEDIANTE BREVETTO

1. La brevettabilità del software …………………………………………………………..2. Le decisioni dell’UEB ………………………………………………………………….3. La proposta di direttiva comunitaria ……………………………………………………4. Il panorama internazionale ……………………………………………………………..

CAPITOLO TERZO LE LICENZE GNU: CONSIDERAZIONI INTRODUTTIVE

1. Le licenze pubbliche GNU ……………………………………………………………..2. Codice sorgente e codice oggetto ………………………………………………………

CAPITOLO QUARTO ORIGINE ED EVOLUZIONE DEL PROGETTO GNU

1. Prima di GNU: il sistema operativo UNIX …………………………………………….2. La nascita del progetto GNU e la GPL …………………………………………………3. La OSI, Open Source initiative …………………………………………………………4. Free software ed open source ………………………………………………………….5. Situazione attuale e prospettive future …………………………………………………

CAPITOLO QUINTO

IL FUNZIONAMENTO DELLE LICENZE GNU 1. Struttura della GPL ……………………………………………………………………..2. Le licenze pubbliche GNU e le licenze d’uso dei software …………………………….3. Il contenuto della GPL e la LGPL ………………………………………………………4. L’essenza della GPL: i §§ 4,5,6 …………………………………………………………5. Il rapporto tra la GPL e gli artt. 1469 bis ss. cod. Civ. ......................................................6. La GPL come nuovo paradigma di proprietà intellettuale ………………………………

p. 4 p. 5 p. 7 p. 9 p. 12 p. 13 p. 14 p. 15 p. 16 p. 18 p. 21 p. 23 p. 24 p. 26 p. 26 p. 28 p. 28 p. 30 p. 32 p. 32 p. 35 p. 36 p. 37 p. 38

MAURO SANTO

3

CAPITOLO SESTO I DIRITTI LICENZIATI DALLE LICENZE GNU

1. Il diritto di caricamento, copia e distribuzione (§§ 0-1) ………………………………..2. Il diritto di modificare la copia del programma (§ 2) …………………………………..3. Le disposizioni sul codice sorgente (§ 3) ………………………………………………

CAPITOLO SETTIMO

I DIRITTI NON LICENZIATI 1. I diritti non licenziati come categoria ricavabile “in negativo” ………………………..2. Il divieto di distribuzione del § 7 ………………………………………………………

CAPITOLO OTTAVO I TITOLARI DEI DIRITTI PATRIMONIALI E MORALI D’AUTORE

1. La GPL nel sistema di diritto d’autore ………………………………………………….2. Il software licenziato sotto GPL: opera collettiva ………………………………………3. Segue: opera composta omogenea ……………………………………………………..4. Segue: elaborazione creativa …………………………………………………………...5. I diritti morali …………………………………………………………………………..Conclusione ………………………………………………………………………………. BIBLIOGRAFIA …………………………………………………………………………. DOCUMENTI: GNU General Public License, version 2, June 1991 …………………….

p. 41 p. 42 p. 43 p. 45 p. 46 p. 47 p. 47 p. 48 p. 49 p. 50 p. 51 p. 52 p. 60

MAURO SANTO

4

INTRODUZIONE

Questo lavoro analizza le licenze pubbliche GNU, ovvero una particolare categoria di licenze d’uso di software che si caratterizza per il suo contenuto, molto diverso da quello delle comuni licenze poiché, a differenza di queste ultime, invece di restringere i diritti del licenziatario, li amplia notevolmente, purché siano però rispettate determinate condizioni. Tale modello di licenze software è sorto all’interno di un più ampio progetto – il progetto GNU – volto a sviluppare ed a diffondere il software cosiddetto open source; e le licenze pubbliche GNU rappresentano, a nostro parere, l’archetipo della licenza di un software open source, poiché garantiscono la libera riproduzione di un software e soprattutto, permettendo l’accesso al codice sorgente (da qui la corrente definizione di open source – sorgente aperto, appunto) rendono possibile modificarne il contenuto; ma, e questo è il tratto veramente innovativo, permettono l’ulteriore distribuzione del software, purché a tutti i destinatari siano garantiti i diritti previsti dalla GPL, diritti che non possono in alcun modo essere ristretti o modificati.

Si crea dunque in concreto un modello di sviluppo e di diffusione dei software totalmente diverso da quelli attuati fino ad ora, il cui scopo principale è, oltre ad un ampio sfruttamento del software da parte dei suoi utenti, creare un modello di sviluppo “dal basso”, in cui ciascuno possa essere al contempo utilizzatore ed autore del proprio software. In tal modo un programma per elaboratore si svilupperà in modo più celere e più completo rispetto a quanto possano fare invece le software houses.

Studiare ed approfondire le licenze pubbliche GNU significa occuparsi dello strumento giuridico attraverso cui si diffonde il software open source, e ciò diviene tanto più importante e necessario quanto più tali software si espandono; espansione che attualmente è notevole e degna di attenzione, a causa dell’aumento della domanda di prodotti informatici legata alla capillare diffusione di Internet e della crescente diffusa alfabetizzazione informatica, alfabetizzazione che giova indubbiamente ai software open source, a causa dell’autonomia e della libertà che essi garantiscono agli utenti.

I capitoli iniziali di questo lavoro sono dedicati alla tutela del software, poiché, essendo quest’ultimo l’oggetto delle licenze pubbliche GNU, è parso opportuno offrire una panoramica di un tema costantemente in evoluzione, soprattutto a seguito delle recenti significative aperture alla sua brevettabilità. Successivamente si introdurrà alle licenze pubbliche GNU, con una parentesi di natura “tecnica” dedicata alla distinzione tra codice sorgente e codice oggetto di un software; si è ritenuto meritassero una certa attenzione, soprattutto perché la nozione di codice sorgente è fondamentale nell’architettura complessiva delle licenze pubbliche GNU, licenze di cui sarà esposta l’origine e la nascita, mostrando come in realtà il modello open source non sia sorto improvvisamente dal nulla, ma abbia avuto una gestazione più che ventennale. Verrà offerta anche una prospettiva più generale delle licenze pubbliche GNU all’interno del più ampio movimento open source, ridimensionandone la portata rivoluzionaria, per il diritto d’autore e la circolazione delle opere dell’ingegno, che taluno vi attribuisce.

Sarà poi studiata la struttura e lo schema complessivo delle licenze pubbliche GNU, osservando inoltre il loro rapporto con le altre licenze ed il loro inserimento tra le norme dell’ordinamento, nonché la validità dello schema da esse previsto; il loro contenuto sarà poi analizzato dettagliatamente, evidenziando in particolare i diritti licenziati e quelli non licenziati.

Infine saranno esaminati i problemi e le questioni che sorgono nei confronti del diritto d’autore, per la cui risoluzione appare decisivo e fondamentale capire che tipo di opera rappresenti un software sviluppato secondo lo schema delle licenze pubbliche GNU.

Tutto ciò tenendo conto costantemente della dottrina statunitense, mentre sono del tutto assenti le decisioni giurisprudenziali e rarissimi sono i contributi della dottrina italiana.

MAURO SANTO

5

CAPITOLO I LA TUTELA DEL SOFTWARE MEDIANTE DIRITTO D’AUTORE

SOMMARIO: 1. La protezione del software. Evoluzione della disciplina e tutele diverse da quelle d’autore e di brevetto. – 2. La tutela d’autore. – 3. I diritti esclusivi. – 4. L’esaurimento ed il problema delle licenze. – 5. Le utilizzazioni libere del software. – 6. La durata di protezione. 1. Fin dalla sua apparizione il software1 ha suscitato vivaci confronti e dibattiti circa la più efficace

forma di tutela da apprestare a questa entità essenzialmente nuova nel campo dei beni immateriali; e tutto era reso alquanto controverso dall’incertezza che circondava l’opera software, in particolare se fosse possibile equipararlo alle altre opere dell’ingegno o se invece ne era assolutamente esclusa la tutelabilità mediante il diritto d’autore a causa di un aspetto che era anche la principale peculiarità del software: la sua utilità e la sua vocazione tecnica. Questo requisito rendeva tra l’altro insicura anche l’applicazione delle norme sui brevetti, poiché non sempre era ravvisabile quell’industrialità che è l’elemento fondamentale delle invenzioni oggetto di tutela brevettuale.

Invero sulla reale natura del software si era ben lontani da una visione comune: indubbiamente la totale novità del software tra le opere dell’ingegno recava con sé incertezze che destabilizzavano soprattutto i fondamentali istituti giuridici del diritto d’autore; in particolare era l’ontologica destinazione funzionalistica propria di ogni software (il fatto cioè che ogni programma fosse creato per uno specifico scopo pratico) la caratteristica principale di questa opera dell’ingegno; ma non solo: anche la sua destinazione ad una macchina ed il fatto che fosse creato secondo un linguaggio specifico (incomprensibile ai più) rendevano ancor più estraneo il software alle altre comuni opere dell’ingegno, ponendolo in una zona intermedia con le invenzioni industriali2.

Va comunque evidenziato il fatto che l’intensità del dibattito sulla tutela più adatta ai software e le tutele di volta in volta apprestate sono dipese soprattutto dall’importanza e dalla diffusione che i programmi per elaboratore hanno avuto nella nostra società. Così, se durante gli anni ’50 e’60 i software non avevano alcuna significativa diffusione, poiché il loro uso era limitato solo a particolari settori o a precisi ambienti accademici, e di conseguenza, essendo ristretto il numero di soggetti che vi avevano a che fare, erano sufficienti gli strumenti di tutela previsti dal codice civile (come la concorrenza sleale o la disciplina del segreto), è con gli anni ’70 ed i progressi delle imprese produttrici di hardware che il software acquista un po’ più di importanza, alla cui tutela si riteneva però fosse sufficiente il diritto d’autore nonché la disciplina della concorrenza sleale, a causa della strettissima connessione che vi era tra gli hardware ed i software, spesso prodotti come un unicum inscindibile dalle medesime imprese. Ma è con gli anni ’80 ed i primi anni ’90 che la diffusione dei software aumenta in modo esponenziale, soprattutto a causa della diffusione dei personal computer; si crea di conseguenza un autonomo mercato dei software, con una netta distinzione tra imprese produttrici di hardware ed imprese esclusivamente produttrici di software; queste ultime dunque organizzano beni e risorse al fine esclusivo di creare programmi per elaboratore, diffusi spesso mediante contratti standardizzati denominati licenze d’uso; la cresciuta importanza acquisita dai software in un settore di mercato ormai divenuto di massa rende necessaria una tutela che sia, all’interno del sistema di diritto d’autore, ad hoc. Oltre naturalmente alla tutela che le imprese si garantiscono mediante le clausole contenute nei contratti di distribuzione dei programmi. Ma è dopo l’inizio degli anni ’90, soprattutto a causa dei significativi progressi nel settore informatico e della diffusione di Internet, che i software acquisiscono

1 Il software, o programma per elaboratore, ha due accezioni: una prima, di natura tecnica, contrapposta ad hardware, che identifica tutte le funzioni di un elaboratore che non siano, appunto, hardware; la seconda, invece, che è quella usata in questi capitoli introduttivi, identifica nel software i programmi per elaboratore, ovvero l’insieme di determinate istruzioni logiche create mediante appositi linguaggi di programmazione, destinate a sortire un qualche effetto sull’elaboratore. Per un approfondimento v. infra cap. III.2 dedicato alle definizioni di codice sorgente e codice oggetto. 2 Sui problemi e le difficoltà poste dalle creazioni aventi utilità tecnica v. SENA, Opere dell’ingegno, in Dig. comm., X, UTET, Torino, 1994, 362-365, il quale definisce questo tema uno “dei problemi più delicati ed importanti nella fase attuale di sviluppo della proprietà intellettuale”. Approfondisce il tema anche FRASSI, Creazioni utili e diritto d’autore, Giuffrè, Milano, 1997, 1 ss. e, segnatamente, 337-369.

MAURO SANTO

6

una diffusione capillare e sempre più vasta; da qui un’ulteriore esigenza di protezione, soprattutto a seguito della diffusione di strumenti che rendono estremamente semplice la duplicazione dei software: esigenza cui paiono rispondere le crescenti aperture, nei confronti dei programmi per elaboratore, delle esclusive brevettuali.

Ma il fatto che sia stata posta una notevole tutela mediante diritto d’autore e, nei limiti che si vedranno, mediante brevetto, non rende affatto superate né inefficaci le altre forme di tutela possibili, quali le norme relative alla concorrenza sleale ed al segreto.

Iniziando da quest’ultimo aspetto3, l’eventuale vincolo che vieta ai terzi la divulgazione o la comunicazione di notizie o dati relativi al software, di cui siano venuti a conoscenza, può essere la conseguenza di diverse situazioni: innanzitutto può derivare da un accordo contrattuale in tal senso, oppure da specifiche norme (come per esempio l’art. 2105 oppure le norme penali che tutelano i segreti conosciuti e rivelati in rapporto a specifiche situazioni): in tutti questi casi il software è oggetto di un obbligo di non fare, che non ha però valore erga omnes: quindi, qualora il segreto sia violato, l’autore o il suo avente causa potrà solo ottenere una tutela risarcitoria, mentre non potrà impedire ai terzi di usufruire delle notizie una volta tutelate dal segreto.

In particolare, qualora ne ricorrano i requisiti, non sembra potersi escludere neppure l’applicabilità dell’art. 2105 cod.civ.: infatti un programma per elaboratore è senza dubbio parte delle notizie attinenti l’organizzazione di un’impresa nonché parte dei suoi metodi di produzione, la cui ingiustificata divulgazione da parte del prestatore di lavoro sarà causa di sanzioni4.

Per quanto attiene invece le norme sulla concorrenza sleale, ed in particolare l’art. 2598 cod.civ., ebbene esse possono benissimo fornire una efficace tutela agli autori di programmi per elaboratori, i quali potranno agire nei confronti dei terzi che abbiano posto in essere gli atti tipici previsti dall’art. 2598 cod.civ.5; rileva in special modo la previsione del n. 1, che prevede tre distinte condotte, tutte potenzialmente riferibili ai software: una prima condotta consistente nell’uso di nomi o segni distintivi idonei a produrre confusione con i nomi o i segni distintivi legittimamente usati da altri; ma è soprattutto la seconda condotta ad avere una particolare importanza per i programmi per elaboratore, poiché qualifica come concorrenza sleale l’imitazione servile dei prodotti di un concorrente: e ciò assume notevole importanza per i software, prodotti suscettibili in modo relativamente semplice di essere imitati; l’imitazione dovrà comunque vertere sull’aspetto esterno e sulla rappresentazione del software (che tipicamente equivale alla c.d. interfaccia)6; appare infatti condivisibile la posizione che esclude la presenza di atti di imitazione servile qualora ad essere imitate siano solo le funzioni proprie di un software; vi è infine una terza condotta consistente in qualsiasi altro atto idoneo ad ingenerare confusione.

Va segnalato che è stato ritenuto applicabile anche il n. 3, che qualifica come concorrenza sleale gli atti di colui che si vale direttamente o indirettamente di ogni altro mezzo non conforme ai principi della correttezza professionale; in particolare si è sostenuto che in tale condotta rientrino atti riproduttivi od imitatori di software, i quali consentirebbero ad un imprenditore di risparmiare le spese di ricerca e di programmazione7. Peraltro non pare condivisibile questa interpretazione così estensiva: l’art. 2598 cod.civ.

3 In particolare prospettano una tutela del software anche mediante le norme a tutela del segreto CARNEVALI, Sulla tutela giuridica del software, in Quadrimestre 1984, 251 ss.; GHIDINI, La natura giuridica dei software, in ALPA e ZENO ZENCOVICH, I contratti d’informatica , Giuffrè, Milano, 1986, 325; Giov.GUGLIELMETTI, Contenuto del diritto – analisi e decompilazione dei programmi, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 162-165. 4 Cfr. al riguardo BIANCHI, Programmi applicativi per elaboratori elettronici ed aspetti della disciplina del segreto, in IDA 1988, 1 ss., il quale ricomprende nella categoria tutelata sia la forma espressiva del software sia il suo contenuto ideativo. 5 È pacifica in dottrina la possibilità di applicare le norme sulla concorrenza sleale anche ai programmi per elaboratore: in particolare cfr. CARNEVALI, Sulla tutela giuridica del software, in Quadrimestre 1984, 251 ss.; RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92, CEDAM, Padova, 1993, 56 ss.; D’AIETTI, Il decreto legislativo 29 dicembre 1992 n. 518 ed il suo inserimento nella difesa delle opere d’ingegno. La tutela giudiziaria civile e penale, in Dir. Inf. 1994, 222 e 223; RINALDI, La tutela del software nel dlgs. 518/1992, in Dir. inf. 1994, 271. 6 Sulla necessità di un riscontro nel solo aspetto formale del software, tale da ingenerare confusione cfr. RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92, CEDAM, Padova, 1993, 58. 7 Sono giunte a queste conclusioni Pret. Bari, 11-2-1991; Pret. Roma, 4-7-1988; Pret. Roma, ord. 25-5-1982; tutte in RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92, CEDAM, Padova, 1993, 80 ss.

MAURO SANTO

7

non ricopre infatti in modo generico ed onnicomprensivo tutti i comportamenti che non siano conformi alla correttezza professionale8.

Tutte queste previsioni di concorrenza sleale saranno comunque applicabili nei confronti di soggetti – appunto – concorrenti, e quindi a loro volta imprenditori; sono escluse quindi le condotte dei singoli, che potranno invece ricadere nello spettro delle previsioni delle norme a tutela del diritto d’autore. Tuttavia i software possono essere creati non solo dalle imprese, ma anche da programmatori singoli, i quali potrebbero benissimo compiere taluno degli atti elencati nell’art. 2598 cod.civ.; affinché la tutela sia veramente efficace, ecco allora che appare preferibile l’opinione di chi intende in modo ampio la nozione di impresa culturale, ricomprendendovi dunque anche i singoli professionisti9.

Infine un autore potrà comunque ricorrere ai comuni rimedi che lo tutelano da eventuali inadempienze contrattuali, nei casi, ovviamente, in cui tra le parti intercorra un rapporto contrattuale, che per i software assume nella maggior parte dei casi la veste delle c.d. licenze d’uso software10.

2. Il dibattito e le incertezze in realtà non sono mai state sopite malgrado i provvedimenti normativi

adottati e a livello nazionale e a livello internazionale. Attualmente, nonostante vi siano parametri che in apparenza forniscono sicuri riferimenti per il giurista, come la convenzione di Monaco sulla concessione di brevetti europei, entrata in vigore l’1 dicembre 1978, la quale vieta di brevettare programmi per elaboratori in quanto tali, e la direttiva 14 maggio 1991 (91/250/CEE), attuata in Italia con il dlgs. 28 dicembre 1992 n. 518, la quale detta una specifica disciplina per i software all’interno del diritto d’autore, la situazione concreta è molto più differenziata di quanto non possa apparire da questi provvedimenti legislativi.

La qualificazione dei programmi per elaboratore come opere dell’ingegno e la loro tutela mediante la l. 22 aprile 1941 n. 633 (d’ora innanzi l.a.) era già stata attuata tra gli anni ’70 ed ’80 non solo da qualche rara pronuncia giurisprudenziale, ma anche da alcuni ordinamenti stranieri (primi fra tutti gli Stati Uniti d’america). Sebbene ciò non avvenne immediatamente, anche la nostra giurisprudenza giunse infine a porre senza alcun dubbio i software tra le opere dell’ingegno11 previste dall’art.2 l.a., stante il carattere esemplificativo dell’elenco in esso contenuto12.

Nonostante infatti qualche pronuncia contraria13, le decisioni favorevoli all’inclusione fra le opere dell’ingegno con conseguente applicazione della l.a. trovarono la loro definitiva conferma in una sentenza della Cassazione, in cui fu affermato che i software presentavano l’originalità necessaria per la tutela

8 v. CARNEVALI, Sulla tutela giuridica del software, in Quadrimestre 1984, 251 ss., il quale nega decisamente la validità dell’orientamento assunto dalla giurisprudenza precedentemente citata. 9 Estende anche ai professionisti la nozione di imprenditore BERTANI, Impresa culturale e diritti esclusivi, Giuffrè, Milano, 1998, 1 ss.. 10 Assumono rilevanza in particolare le clausole di non divulgazione, in base a cui un contraente si impegna a non comunicare in alcun modo le notizie di carattere tecnico relative ad un software di cui sia venuto a conoscenza; cfr. BIANCHI, Programmi applicativi per elaboratori elettronici ed aspetti della disciplina del segreto, in IDA 1988, 14-17. 11 Una completa rassegna della giurisprudenza anteriore al dlgs. 518/92 è in RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993, 75 ss. 12 Si discute se l’elenco contenuto nell’art. 1 l.a. abbia carattere esemplificativo o tassativo. Nel senso qui accolto del carattere esemplificativo si esprimono: AULETTA e MANGINI, Marchio - Diritto d'autore sulle opere dell'ingegno, in Commentario del codice civile, a cura di SCIALOJA e BRANCA, 148; ALGARDI, Il plagio letterario e il carattere creativo dell’opera, Padova, CEDAM, 1971, 360; GRECO e VERCELLONE, I diritti sulle opere dell’ingegno, UTET, Torino, 1974, 55; V.M.DESANCTIS, Il carattere creativo delle opere dell’ingegno, Giuffrè, Milano, 1971, 71; L.C.UBERTAZZI, Raccolte elettroniche di dati e diritto d’autore, in ALPA, La tutela giuridica del software, 51ss.; SENA, Opere dell’ingegno, cit., 361; V. FRANCESCHELLI, Tutela giuridica dei programmi per elaboratore, in NLCC 1995, 267; FRASSI, Creazioni utili e diritto d’autore, Milano, Giuffrè, 1997, 34 ss.; L.C.UBERTAZZI, I diritti d’autore e connessi, cit., 16; Cass. 20 maggio 95 n. 908, in AIDA 1995, 345; Cass. 30-6-1993 n. 11953, ivi 94, 333; Trib. Cuneo, 19 ottobre 1999, ivi 2000, 705; Trib. Cuneo, ord. 23 giugno 1997, ivi 97, 500. Ritengono invece che l’art. 1 abbia carattere tassativo: FABIANI, Il diritto d’autore, in Trattato di diritto commerciale, diretto da RESCIGNO, 132; FLORIDIA, La tutela del software, in Dir. inf. 1989, 71ss.; App. Milano, 2 ottobre 1981, in IDA 1983, 204; Trib. Roma, 30 giugno 1978, ivi 79, 43; Trib. Roma, 4 settembre 1963, ivi 64, 51. È invece pacifico che l’elenco di opere contenuto nell’art. 2 l.a. abbia carattere esemplificativo: per tutti v. L.C.UBERTAZZI, I diritti d’autore e connessi, cit., 12. 13 Pret. Torino, 25 maggio 1982, in RISTUCCIA e ZENO ZENCOVICH, op. cit., 80.

MAURO SANTO

8

mediante diritto d’autore, e che essi erano espressi in un linguaggio tecnico-convenzionale14, e dunque pienamente assimilabili alle altre opere dell’ingegno15.

La dottrina invece registrava contrapposizioni fra i diversi punti di vista, che consistevano nel condividere la tutela mediante diritto d’autore, nell’escluderla (invocando la tutela brevettuale) oppure nel favorire una posizione intermedia, per la quale le due tutele sarebbero state complementari e sarebbero in concreto dipese dalle caratteristiche concrete e dalle funzionalità del software16.

In realtà pare di capire che il vero momento fondamentale del dibattito non riguardava la tutelabilità mediante diritto d’autore dei programmi per elaboratore, ammessa sostanzialmente da tutti gli autori; la questione era invece se a fianco del copyright approach dovesse esservi spazio anche per ulteriori modalità di tutela che proteggessero in particolare le idee sottostanti ai software: in breve se vi era spazio, a fianco del diritto d’autore, anche per una tutela brevettuale.

Su questo punto si concentravano infatti le divergenze tra i vari autori, alcuni dei quali mettevano in luce che il diritto d’autore era sì applicabile ai software, ma era inidoneo a tutelare adeguatamente tali opere, la cui importanza risiedeva spesso non nella loro espressione bensì nelle idee e nelle sequenze logiche alla base di essi17.

Quando ormai anche i maggiori paesi europei (tranne il nostro) avevano apprestato un’esplicita tutela mediante diritto d’autore a favore dei programmi per elaboratore18, chi prevedendo una disciplina ad hoc (come la Francia), chi invece semplicemente includendo nell’elenco delle opere dell’ingegno tutelate i software (come la Gran Bretagna), venne emanata la direttiva 91/250/CEE, la quale aveva lo scopo di armonizzare le varie legislazioni nazionali in materia di protezione dei software.

Essa prevedeva una disciplina che, all’interno della normativa di diritto d’autore, per alcuni aspetti fosse applicabile in modo particolare al software. A dire il vero il legislatore comunitario, prima e dopo l’emanazione di questa direttiva, non fu esente dalle critiche di alcuni autori, i quali sostanzialmente accusavano la direttiva di snaturare e manipolare istituti giuridici fondamentali all’interno del sistema di diritto d’autore e frutto di elaborazioni secolari19.

Nel nostro paese la direttiva è stata attuata dal dlgs. 518/92, il quale ha aggiunto una nuova sezione (la VI) al capo IV l.a., strutturata in tre articoli: 64 bis, ter e quater ed ha espressamente previsto (art. 1 l.a. comma 2) la qualificazione del software come opera dell’ingegno di carattere creativo proteggibile come opera letteraria ai sensi della convenzione di Berna. L’art.2 l.a. sancisce poi che “in particolare sono comprese nella protezione:.....8) i programmi per elaboratore, in qualsiasi forma espressi purché originali quale risultato di creazione intellettuale dell’autore. Restano esclusi dalla tutela accordata dalla l.a. le idee ed i principi che stanno alla base di qualsiasi elemento di un programma, compresi quelli alla base delle sue interfacce. Il termine programma comprende anche il materiale preparatorio per la progettazione del programma stesso.”

14 Cass. 24 novembre 1986 n.1956, in RISTUCCIA e ZENO ZENCOVICH, op. cit., 164; ed in Foro it. 1987, II, 289 15 Sugli effetti pratici di tale assimilazione con riguardo alla tutela del software (processuale in particolare) v. L.C.UBERTAZZI, La protezione dl software nei rapporti italo tedeschi, in L.C.UBERTAZZI, I diritti d’autore e connessi, Giuffrè, Milano, 2000, 361-371; ed in IDA 1991, 347 ss. 16 Insistono su quest’aspetto e sulla complementarietà delle tutele, a seconda delle concrete caratteristiche del software ULMER e KOLLE, Copyright protection of computer programs, in IIC 1983, 159 ss. 17 Sull’importanza fondamentale delle idee e degli algoritmi all’interno dei software, con conseguente insufficienza da parte del solo diritto d’autore a tutelare adeguatamente i programmatori v. in particolare GHIDINI, La natura giuridica dei software, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 323-329; PARDOLESI, Software, property rights e diritto d’autore: il ritorno dal paese delle meraviglie, in Foro it. 1987, II, 289 ss.; ID., Software di base e diritto d’autore: una tutela criptobrevettuale?, in Foro it. 1988, I, 3133 ss.; le medesime considerazioni sono svolte anche da autori stranieri: cfr. SAMUELSON, DAVIS, KAPOR e REICHMAN, A manifesto concerning the legal protection of computer programs, in Colum. L. Rev. 1994, 2308 ss.; DESSEMONTET, La protection des programmes d’ordinateur, in AA.VV., Le logiciels et le droit, Cedidac, Lausanne, 1986, 11 ss. 18 Per una completa rassegna delle soluzioni adottate dai vari paesi v. CIAMPI, Profili comparatistici della protezione del software nella legislazione e nella prassi contrattuale, in ALPA e ZENO ZENCOVICH, I contratti d’informatica , Giuffrè, Milano, 1986, 331-347. Sul diritto tedesco v. invece LEHMANN, La tutela dei programmi per computer in Germania. Un profilo attuale, in Foro it. 1988, V, 527. 19 Evidenziano la manipolazione degli istituti tipici del diritto d’autore adattati al software, svolgendo considerazioni particolarmente critiche ZENO ZENCOVICH, L’apprendista stregone: il legislatore comunitario e la proposta di direttiva sui programmi per elaboratore, in Dir. inf. 1990, 77 ss.; V.FRANCESCHELLI, La direttiva CEE sulla tutela del software: trionfo e snaturamento del diritto d'autore, in Riv. dir. ind. 1991, I, 169 ss.

MAURO SANTO

9

Dunque, aldilà delle opinioni dottrinali, vi sono delle precise norme con cui è necessario rapportarsi: di fatto al software è applicabile l’intera disciplina della l.a., salvo quanto sia specificamente disposto; inoltre il riferimento alla convenzione di Berna rende ad esso applicabile il principio dell’assimilazione20.

Spostando l’attenzione sugli elementi cui viene assicurata protezione, è indubbio che il software sia tutelato sia nel suo codice sorgente che nel suo codice oggetto; per essere protetti il giudizio sull’originalità deve comunque prescindere da valutazioni tecniche, risolvendosi invece nella constatazione della configurabilità del software quale risultato della creazione intellettuale dell’autore. La soglia della tutela accordabile ai software mediante l.a. risulta dunque più bassa di quella che sarebbe necessaria se essi fossero qualificabili come invenzioni industriali. Tuttavia questa tutela è limitata alla forma ed all’espressione del software, non estendendosi invece ai principi ed alle idee di un software, e cioè ai suoi processi logici ed ai suoi algoritmi.

Infatti la l.a., equiparando il software alle opere letterarie, ne tutela specificamente la forma espressiva: se ne ricava che la protezione sarà accordata ai programmi per elaboratore così come essi vengono espressi dal loro autore, ovvero nella concreta serie di istruzioni scritte secondo un particolare linguaggio di programmazione.

In particolare, tutelare mediante diritto d’autore il software vuol dire che quest’ultimo è visto come la successione di enunciati fra loro connessi; la tutela verterà quindi sulla specifica combinazione di questi enunciati e sulla loro costruzione, e non invece su ciò che essi rappresentano (in particolare l’algoritmo); il loro significato sarà riproducibile da chiunque, non invece lo schema ed il susseguirsi dei comandi, oggetto di esclusiva da parte dell’autore. Ne risulta un sistema di protezione facilmente accessibile, ma che tutela gli autori dalle sole contraffazioni e dalle duplicazioni, lasciando invece liberi i terzi di sfruttare le idee sottostanti (contrariamente a quanto avviene nella disciplina delle invenzioni industriali).

3. Il dlgs. 518/92 ha principalmente aggiunto una nuova sezione (la VI) al capo IV l.a., strutturata in tre

articoli: 64 bis, ter e quater; essi prevedono una disciplina ad hoc per quanto riguarda i diritti esclusivi dell’autore di un software.

In particolare i diritti esclusivi riservati all’autore hanno subito un notevole ampliamento rispetto a quelli tradizionalmente riconosciuti dalla l.a.; la lettera a) dell’art. 64 bis specifica infatti che tali diritti esclusivi comprendono il diritto di effettuare, ma soprattutto, di autorizzare attività quali: la riproduzione permanente o temporanea, totale o parziale, del programma per elaboratore con qualsiasi mezzo o in qualsiasi forma. Nella misura in cui operazioni quali il caricamento, la visualizzazione, l’esecuzione, la trasmissione o la memorizzazione del programma per elaboratore richiedano una riproduzione, anche tali operazioni sono soggette all’autorizzazione del titolare dei diritti.

Questa descrizione così dettagliata è resa necessaria dalla peculiare natura del software, il cui utilizzo avviene mediante modalità del tutto differenti da quelli delle altre opere dell’ingegno; la nozione di riproduzione inoltre non corrisponde a quella comune tra le norme di diritto d’autore, ovvero la moltiplicazione in copie di un’opera (art. 13 l.a., in cui il concetto di riproduzione si risolve sostanzialmente in quello di duplicazione), bensì indica le specifiche attività necessarie per l’uso di un software21. Nel concetto di riproduzione rientrano un ampio spettro di attività, che contemplano ed esauriscono sostanzialmente tutte le possibili utilizzazioni di un programma per elaboratore; soprattutto risultano importanti le previsioni riguardanti la riproduzione anche solo temporanea, riproduzione il cui significato va inteso in senso molto lato, poiché include il solo caricamento del programma come anche la sua esecuzione (peraltro l’elenco di queste attività deve ritenersi meramente esemplificativo)22. Di fatto ogni applicazione del software che serva a sfruttarne il contenuto è soggetta all’autorizzazione del suo autore.

Ecco allora che all’autore sono riservati in esclusiva diritti che non hanno a che fare solo con la produzione dell’opera, ma che si risolvono essenzialmente nel riservare in capo all’autore anche la possibilità di mantenere un’esclusiva sull’utilizzo del programma da egli creato. Infatti, essendo i vari diritti esclusivi

20 cfr. CAVANI, Oggetto della tutela, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 1 ss. 21 cfr. su quest’aspetto CARTELLA, Contenuto del diritto – le attività di riproduzione riservata, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 47 ss.; CAPPELLARO, sub art. 64 bis l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998. 22 Così CAPPELLARO, sub art. 64 bis l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998.

MAURO SANTO

10

indipendenti tra di loro23, l’autore potrà stabilire in concreto le modalità attraverso cui debba o possa essere riprodotto un programma; il contenuto dei diritti esclusivi spettanti all’autore di un software risulta di conseguenza più ampio di quelli spettanti agli autori delle altre opere dell’ingegno. Non è mancato chi ha criticato tale impostazione, sostenendo che in sostanza si è introdotta un’esclusiva dal contenuto analogo a quello delle privative industriali24. Indubbiamente è innegabile che la protezione offerta agli autori di software è particolarmente estesa e penetrante.

La lettera b) riserva all’autore i diritti relativi alla traduzione, adattamento, trasformazione ed ogni altra modificazione del programma, nonché la riproduzione dell’opera che ne risulti, senza pregiudizio dei diritti di chi modifica il programma.

Anche in questo caso, per quel che riguarda la modificazione di un’opera e la sua eventuale elaborazione, le norme riguardanti i diritti riservati all’autore di un software sono più ampie rispetto alle norme relative alle modifiche delle altre opere: per queste ultime è infatti necessario il consenso dell’autore dell’opera originaria (ex art. 18 l.a), qualora un soggetto crei una nuova opera che di quella sia un’elaborazione o qualora vi apporti modifiche secondo l’art. 4 l.a.; nel caso dell’art. 64 bis lett. b) l’autore ha diritti in un certo senso più vasti, poiché egli ha il diritto esclusivo di effettuare o autorizzare anche attività che si risolvono in meri adattamenti del software, non qualificabili come modificazioni o elaborazioni, poiché qualitativamente inferiori a queste ultime (nel senso che per adattamento si dovrebbe intendere un’attività minima e marginale di manipolazione del software)25: non a caso la lettera b) prevede altre attività che si risolvano comunque in “ogni altra modificazione del programma”; quindi nessuno, se non con il consenso del titolare dei diritti d’autore, potrà minimamente intervenire sul programma.

La successiva lettera c) prevede inoltre l’esclusiva per l’autore di qualsiasi forma di distribuzione al pubblico, compresa la locazione del programma o di sue copie. Questa lettera tratta anche ( e segnatamente) della disciplina dell’esaurimento, di cui si tratterà in seguito.

A norma dell’art. 64 ter non sono invece soggette all’autorizzazione del titolare dei diritti, salvo patto contrario, le attività indicate nelle lettere a) e b) dell’art. 64 bis, allorché tali attività sono necessarie per l’uso del programma conformemente alla sua destinazione da parte del legittimo acquirente, inclusa la correzione degli errori.

Al riguardo si può notare innanzitutto che l’inciso “salvo patto contrario” favorisce indubbiamente le parti contrattualmente più forti, le quali potranno così stabilire liberamente i diritti cui autorizzare gli utenti di un software26. A parte ciò, ne viene fuori una disciplina globale in cui il licenziatario di un software potrà effettuare tutte le attività previste dalle lettere a) e b) art. 64 bis, e quindi liberamente riprodurre, adattare e modificare un software, purché siano però rispettate due condizioni: una prima, consistente nell’assenza di eventuale patto contrario; ed una seconda, che limita tali attività alla loro necessità per l’uso del programma “conformemente alla sua destinazione”. Quest’ultimo requisito corrisponde alla realizzazione dello scopo contrattualmente previsto27: se ne deduce che qualora un soggetto sia licenziatario di un software di cui intende sfruttare le funzionalità, potrà compiere le attività previste dall’art. 64 bis lett. a) e b) solo al fine di garantirsi la funzionalità, appunto del software.

Il comma 2 prevede che comunque non può essere impedito per contratto, a chi ha il diritto di usare una copia del programma di effettuare una copia di riserva, qualora essa sia necessaria per l’uso. Anche in tal caso, deve ammettersi la possibilità di effettuare la copia di riserva (c.d. copia di back up) solo per il fine di

23 Questa considerazione deriva dall’estensione analogica dell’art. 19 l.a. (che prevede per l’appunto l’indipendenza tra di loro dei singoli diritti esclusivi) all’art. 64 bis; cfr. CAPPELLARO, sub art. 64 bis l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998. 24 Cfr. R ISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993, 40, per i quali è stata introdotta di fatto una disciplina molto restrittiva del tutto simile a quella delle privative industriali: con conseguente difficoltà nel coordinare tali aspetti con il resto della disciplina prevista dal diritto d’autore. Perplessità nel medesimo senso sono espresse anche da CAVANI, Oggetto della tutela, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 1 ss. 25 cfr. MUSSO, Contenuto del diritto – elaborazioni creative del software e programmi derivati, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 62 ss., per il quale, appunto, il concetto di adattamento riferito ai software deve necessariamente essere inteso diversamente da quanto avviene per le comuni opere dell’ingegno.. 26 Paventano che ciò possa portare ad un significativo squilibrio a favore delle software houses RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92, CEDAM, Padova, 1993, 44-45. 27 Cfr. SARTI, Contenuto del diritto – esaurimento ed utilizzazione del software, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 129 ss.; l’A. riconduce peraltro questa disposizione alla Zweckubertragungstheorie, per dedurne le anomalie degli artt.64 bis ss. con il principio dell’esaurimento.

MAURO SANTO

11

garantirsi l’utilizzo del software; quindi, qualora ciò possa avvenire mediante altre modalità (perché per esempio, sono stati forniti supporti di riserva) sarà escluso il diritto alla copia di riserva (implicitamente ammettendo il divieto di effettuare qualsiasi copia “privata”)28.

Infine il comma 3 di questo articolo stabilisce che chi ha il diritto di usare una copia del programma può, senza l’autorizzazione del titolare dei diritti, osservare, studiare o sottoporre a prova il funzionamento del programma, allo scopo di determinare le idee ed i principi su cui è basato ogni elemento del programma stesso, qualora egli compia tali atti durante operazioni di caricamento, visualizzazione, esecuzione, trasmissione o memorizzazione del programma che egli ha il diritto di eseguire. Questa attività si risolve in pratica nella possibilità di osservare e studiare il funzionamento del software per capirne i principi ed i metodi utilizzati; l’utente deve però limitarsi ad effettuare deduzioni (la c.d. black box analysis), non potendo invece prefiggersi gli stessi scopi esaminando il software dal suo interno, magari decompilandolo29. L’inciso finale prevede che eventuali clausole contrattuali pattuite in violazione dei commi 2 e 3 sono nulle; risulta peraltro arduo immaginare ulteriori clausole che arrivino a vietare di effettuare una copia di riserva o addirittura di osservare il funzionamento del programma.

L’art. 64 quater dispone invece che l’autorizzazione del titolare dei diritti non è richiesta qualora la riproduzione del codice del programma e la traduzione della sua forma in base all’art. 64 bis lettere a) e b), compiute al fine di modificare la forma del codice, siano indispensabili per ottenere le informazioni necessarie per conseguire l’interoperabilità, con altri programmi, di un programma per elaboratore creato autonomamente purché siano soddisfatte le seguenti condizioni: a) le predette attività siano eseguite dal licenziatario o da altri che abbia il diritto di usare una copia del programma oppure, per loro conto, da chi è autorizzato a tal fine; b) le informazioni necessarie per conseguire l’interoperabilità non siano già facilmente e rapidamente accessibili ai soggetti indicati nella lettera a); c) le predette attività siano limitate alle parti del programma originale necessarie per conseguire l’interoperabilità.

Il comma 2 di questo articolo prevede poi che le disposizioni del comma 1 non consentono che le informazioni ottenute in virtù della loro applicazione: a) siano utilizzate a fini diversi dal conseguimento dell’interoperabilità del programma creato autonomamente; b) siano comunicate a terzi, fatta salva la necessità di consentire l’interoperabilità del programma creato autonomamente; c) siano utilizzate per lo sviluppo, la produzione o la commercializzazione di un programma sostanzialmente simile nella sua forma espressiva, o per ogni altra attività che violi il diritto d’autore. Come per l’art. 64 ter, anche qui vi è un comma 3 che sancisce la nullità delle clausole contrattuali pattuite in violazione dei commi 1 e 2.

Il complesso delle disposizioni dell’art. 64 quater è il risultato di due tendenze opposte: una volta a favorire la decompilazione, in modo da rendere disponibile le idee ed i principi di un programma, onde evitare che le reali innovazioni apportate dai software rimangano segrete; ciò è particolarmente importante nel campo dei programmi per elaboratore, la cui creazione ed il cui sviluppo è più simile a quello delle comuni invenzioni che non a quello delle opere letterarie, cui i software sono equiparati in forza della conv. di Berna e dell’art. 1 l.a.; risulta allora particolarmente interessante conoscere lo stato di evoluzione dei vari metodi di programmazione e delle eventuali soluzioni prospettate per determinati problemi. D’altro lato, la volontà di evitare che ciò potesse tradursi in una indiscriminata possibilità di appropriarsi, sostanzialmente, dei software creati da altri, ha imposto di prescrivere precise limitazioni ai diritti concessi dall’art. 64 quater, dando luogo così ad una disciplina vagamente simile a quella del segreto industriale30.

La decompilazione è stata dunque limitata alla necessità di rendere il software interoperabile con un programma autonomamente creato; tale decompilazione consiste essenzialmente nel risalire al codice sorgente di un software, in modo che esso sia intelligibile da un soggetto; successivamente questo codice sorgente verrà eventualmente modificato (vengono infatti richiamate anche le attività della lettera b) dell’art. 64 bis), proprio al fine di assicurare l’interoperabilità con un altro programma; tutto cio purché essa non sia comunque realizzabile tramite un facile e rapido reperimento delle informazioni necessarie: quindi se fosse questo il caso, un soggetto potrebbe effettuare l’interoperabilità modificando il software da egli autonomamente creato; in ogni caso la decompilazione deve avvenire solo sulle parti la cui osservazione ed eventuale modifica sia necessaria per l’interoperabilità; di conseguenza non si potrà addurre come giustificazione la necessità di interoperabilità tra due software, per assicurarsi la conoscenze del generale funzionamento di un software.

28 Così pure SARTI, op. cit., 149-151. 29 v. CAPPELLARO, sub art. 64 bis l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998. 30 Su quest’aspetto e sulla similarità alla disciplina del segreto industriale cfr. le considerazioni svolte supra cap. I.1, nonchè RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993, 46-47; nello stesso senso pure Giov.GUGLIELMETTI, Contenuto del diritto – analisi e decompilazione dei programmi, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 152-159.

MAURO SANTO

12

Il comma 2 tutela l’autore del software decompilato vietando lo sfruttamento e la comunicazione delle informazioni acquisite a seguito della decompilazione; e si avrà sfruttamento ogniqualvolta le informazioni siano utilizzate per scopi differenti dal mero conseguimento dell’interoperabilità.31

Vi è infine una disposizione, il comma 4, di chiusura, relative all’interpretazione di queste norme: essa, conformemente alla convenzione di Berna sulla tutela delle opere letterarie ed artistiche, deve essere effettuata in modo tale da evitare che la loro applicazione arrechi indebitamente pregiudizio agli interessi legittimi del titolare dei diritti o sia in conflitto con il normale sfruttamento del programma.

4. L’art. 64 bis lettera c) detta, nel paragrafo finale, la seguente norma: la prima vendita di una copia del programma nella CEE da parte del titolare dei diritti, o con il suo consenso, esaurisce il diritto di distribuzione di detta copia all’interno della comunità, ad eccezione del diritto di controllare l’ulteriore locazione del programma o di una copia dello stesso.

Quindi essa prevede anche per il software l’applicabilità del principio dell’esaurimento, in base al quale il titolare dei diritti non conserva il diritto di controllare l’ulteriore circolazione di un’opera una volta che egli l’abbia destinata al mercato.

Tuttavia la norma si riferisce esclusivamente alla prima vendita di una copia del programma: ne consegue che, qualora non si abbia una vendita, l’autore non vedrà esaurito il proprio diritto; diviene di conseguenza fondamentale capire quando si sia in presenza di una distribuzione del software mediante vendita.

Ebbene, di solito nella prassi dei contratti relativi ai software, essa non viene prevista, ricorrendosi invece ad un altro schema denominato licenza d’uso software, sulla cui natura non vi è però consenso32; delle licenze d’uso di software è stata infatti spesso evidenziata l’improprietà della definizione nonché l’atipicità del suo contenuto; molte di queste licenze infatti contengono clausole che restringono l’utilizzo del software, e proprio da questo elemento molti hanno escluso la configurabilità della vendita, in base a cui invece il destinatario di un software avrebbe un diritto pieno esclusivo di godimento e disposizione del software.

Dunque il controllo sul godimento di un software effettuato dall’autore anche successivamente alla cessione è stato visto come l’elemento principale secondo cui escludere la configurabilità della vendita, ed ammettere invece quella di un rapporto di locazione di cosa mobile. Entrambi questi tipi legali mostrano comunque lacune più o meno vaste, poiché qualunque sia la scelta vi sono sempre elementi estranei se non addirittura incompatibili con una delle due fattispecie codicistiche; per adeguare tali fattispecie alle norme della direttiva 250/91 ed al dlgs. 518/92 è stata evidenziata l’atipicità dei contratti di cessione di software, e la definizione oggi maggiormente condivisa è quella che inquadra la licenza d’uso software nello schema della locazione atipica.

In base ad essa, avendo sempre chiara la qualificazione del software come opera dell’ingegno oggetto di proprietà intellettuale, ciò che viene trasferito è il diritto alla singola riproduzione del software inteso come bene immateriale, ferma restando l’eventuale proprietà del mero supporto acquistato (floppy disk o cd-rom). Ogni altro diritto sul software resta invece in capo all’autore (il diritto, in particolare, di sfruttamento economico dell’opera software).

Proprio questa visione è alla base dell’impostazione delle licenze software, molte delle quali ormai standardizzate. Numerose limitazioni sono infatti poste al comportamento dell’utente, cui di solito è permesso riprodurre il programma ed a cui sono comunque garantiti i diritti di copia e decompilazione previsti dagli artt. 64 bis e quater.

Per quel che qui rileva, ammettendo tale conclusione che prevede si sia in presenza di uno schema simile ad una locazione atipica, ne risulta che, quando il software venga distribuito mediante licenze d’uso, l’autore conserverà il proprio diritto a controllare la successiva circolazione del software; quindi, salvo che sia a ciò autorizzato, un soggetto non potrà liberamente disporre della propria copia di un software.

È stato correttamente osservato che una situazione tale è del tutto anomala nel sistema di diritto d’autore33, e che in ogni caso sarebbe comunque applicabile la disciplina dell’esaurimento. Analizzando le ragioni dell’istituto dell’esaurimento, sono state rilevate le anomalie dell’attuale situazione; in particolare appare condivisibile la tesi secondo cui si è in presenza di licenze, con conseguente esclusione dell’esaurimento, per i soli casi in cui l’utilizzazione del software risulta strumento di affermazione

31 Per un’approfondita ed esaustiva disamina dei temi concernenti l’art. 64 quater, in particolare sugli aspetti tecnici connessi al tema dell’interoperabilità, v. Giov.GUGLIELMETTI, op. cit.,152-202. 32 cfr. pure infra, il cap. V.2 dedicato al rapporto tra licenze GNU e le altre licenze software. 33 Così RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993, 34-38.

MAURO SANTO

13

commerciale; mentre qualora il software sia destinato ad utenti finali, le cosiddette licenze d’uso saranno invece qualificabili come vendite, ed allora sarà applicabile il principio dell’esaurimento ex art. 64 bis c)34. È comunque opportuno soffermarsi su questo aspetto.

Le considerazioni circa l’applicabilità dell’esaurimento ai programmi per elaboratore possiedono un’importanza notevole in materia di licenze d’uso dei software, poiché è soprattutto nel rapporto tra queste ultime ed il principio dell’esaurimento che emergono notevoli contraddizioni.

Innanzitutto è evidente l’anomalia, all’interno del sistema, della possibilità (conseguenza dell’inapplicazione dell’esaurimento) che un autore controlli e stabilisca eventualmente anche il successivo utilizzo da parte dei terzi della propria opera. Inoltre il principio dell’esaurimento è da considerarsi un principio di ordine pubblico, come tale quindi inderogabile dalle parti: di conseguenza esso troverà applicazione nonostante qualsiasi previsione contraria da parte dell’autore di un software; questo assunto è molto importante, in quanto rende inapplicabili molte delle previsioni contenute nelle licenze software, idonee a restringere la successiva utilizzazione del programma. Come accennato, infatti, la prassi commerciale ha sviluppato per i software un modello di distribuzione che si autodenomina licenza, con conseguente inapplicabilità del principio dell’esaurimento che, come visto, si applica solamente in presenza di una vendita.

Tuttavia non si può negare che, per stabilire la tipologia di un contratto, non è sufficiente la qualificazione fornita da una parte, bensì è necessario guardare alla sua vera natura. Ebbene, per le licenze d’uso di software un valido criterio per discernere tra i casi di vendita ed i casi effettivi di licenza pare essere quello incentrato sulla valutazione della concreta destinazione del bene software: qualora esso sia destinato al mercato ed agli utenti finali, allora si sarà in presenza di una vendita, mentre si avrà una licenza (con conseguente inapplicabilità del principio dell’esaurimento) qualora la distribuzione del software rappresenti un mezzo di affermazione concorrenziale.

Ne consegue che la maggior parte dei contratti che si definiscono licenze sono in realtà contratti di vendita, e ad essi sarà pienamente applicabile il principio dell’esaurimento: in tal modo l’autore di un software non potrà in alcun modo compiere operazioni o prevedere clausole idonee a restringere o comunque a controllare il successivo utilizzo che venga fatto di un software. Non solo: passare da una licenza di un bene soggetto a proprietà intellettuale allo schema della vendita, renderebbe le eventuali violazioni del contratto efficaci solamente inter partes, non essendo possibile invece far valere alcuna pretesa nei confronti dei terzi (come avviene invece per le licenze propriamente dette, efficaci erga omnes).

È evidente dunque che è la disciplina dell’esaurimento e la sua applicabilità il momento più alto di conflitto tra le norme comunitarie e nazionali e gli istituti giuridici fondamentali che fanno parte del diritto d’autore, e che le norme a tutela del software tentano in un certo modo di manipolare (ammettendo, per esempio, la possibilità che un autore controlli il successivo utilizzo della propria opera).

Risulta comunque chiaro che, nella complessità di questo aspetto, il software mostra ancora una volta la sua atipicità rispetto alle altre opere dell’ingegno; o forse mostra solamente che la protezione del software apprestata dal legislatore esclusivamente mediante copyright, non è del tutto soddisfacente (non a caso infatti una disciplina che non prevede l’esaurimento per le successive utilizzazioni del trovato è presente nelle norme a tutela delle invenzioni).

5. Le facoltà riservate all’autore di un programma sono sottoposte a diverse limitazioni alcune delle

quali comuni a tutte le opere, altre relative soltanto ai programmi per elaboratore. Rientrano nella prima categoria le utilizzazioni libere disciplinate dagli artt. 65ss. l.a., la cui

applicabilità al software è controversa ma verrà qui ammessa35. A favore della loro estensione ai programmi militano infatti argomenti di ordine sistematico36 e di uguaglianza sostanziale37.

34 Sostiene tale tesi, ampiamente trattando ed approfondendo il tema, SARTI, Contenuto del diritto – esaurimento ed utilizzazione del software, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 84 ss.; nonché ID., Circolazione dei beni e diritti esclusivi, Giuffrè, Milano, 1996, 56-103 e 295-391. La stessa tesi, tra la dottrina straniera, è sostenuta pure da LEHMANN, The new software contract under european and german copyright law – Sale and licensing of computer programs, in IIC 1994, 46-49. 35 In senso favorevole v. Giov.GUGLIELMETTI, nota a Trib. Milano, 2 dicembre 1993, in AIDA 1993 223; ID., L’invenzione di software, Giuffrè, Milano, 1997, 215 in nota. Contra v. tuttavia RICOLFI, Il diritto d’autore, in AUTERI, FLORIDIA, MANGINI, OLIVIERI, RICOLFI e SPADA, Diritto industriale, proprietà intellettuale e concorrenza, Giappichelli, Torino, 2001, 388 ss. 36 Gli artt. 65 ss. l.a. si riferiscono infatti generalmente alle opere dell’ingegno; il software è un’opera dell’ingegno; conseguentemente queste norme paiono applicabili anche ai programmi per elaboratore.

MAURO SANTO

14

E così l’art. 67 l.a. pare consentire la riproduzione del codice sorgente (su carta o su qualunque altro formato) e l’esecuzione del programma (che comporti una riproduzione anche soltanto temporanea del codice oggetto all’interno dell’elaboratore) “nelle procedure giudiziarie od amministrative”. L’art. 68 dal canto suo sembra applicabile in alcune ipotesi marginali in cui un soggetto trascriva per uso personale il codice sorgente a mano o con altri mezzi non idonei allo spaccio, purché tale attività non sia strumentale alla realizzazione di un programma identico. La stessa norma non consente invece la riproduzione ad uso personale (del codice oggetto) di un programma poiché a) è difficile immaginare che in questi casi la copia possa avvenire con mezzi non idonei allo spaccio e b) non esiste un principio generale ricavabile dall’art. 68 che liberalizzi la riproduzione privata del software38. L’art. 70 l.a. consente infine la riproduzione parziale del codice sorgente effettuata, per fini di critica, discussione e insegnamento, ad esempio da una rivista specializzata oppure da un insegnante in aula. Alle stesse condizioni deve ritenersi lecita la riproduzione (permanente o temporanea) del codice oggetto che sia necessaria al funzionamento di una parte soltanto del programma (si pensi alle versioni demo allegate alle riviste di informatica o disponibili in alcuni siti web). Gli artt. 65 (sulla riproduzione di articoli in altri giornali), 66 (sui discorsi tenuti in pubblico), 69 (sul prestito) e infine 71 l.a. (sulle bande musicali dei corpi armati dello stato) non sembrano invece applicabili al software.

Altre ipotesi speciali di utilizzazioni libere sono regolate dagli artt. 64ter e 64quater l.a.. Esse consentono all’utente legittimo: a) di effettuare una copia di riserva del software acquistato od ottenuto in licenza; b) di osservarne il funzionamento; ed infine c) di procedere alla sua decompilazione quando ciò sia necessario per ricavare le informazioni sulla sua interoperabilità.

6. Per quanto attiene la durata dei diritti di utilizzazione economica dei programmi, questa è prevista

per tutta la vita dell'autore e, comunque, fino a settant’anni dopo la sua morte o la morte dell'ultimo coautore, oppure, nel caso di opere anonime o pseudonime, dopo la prima legittima pubblicazione. Il termine precedente di cinquant’anni è stato ampliato dalla l. 6 febbraio 1996, n. 52; in tal modo viene applicato l’art. 8 direttiva 250/91/CEE che prevedeva il termine di protezione in cinquant’anni, salvo il termine più ampio eventualmente previsto dalle legislazioni nazionali. Non si può non rilevare, ancora una volta, una certa inadeguatezza di tale previsione rispetto ad un’opera quale il software che, considerata la rapidità del progresso tecnologico, è destinato a diventare obsoleto molto più velocemente delle altre opere dell'ingegno39.

37 Diversamente si verrebbe infatti a creare una disparità di trattamento tra autori di opere dell’ingegno: alcuni (i programmatori) protetti in modo più forte degli altri. 38 Così CASSOTTANA, Sperimentazione in ambito privato ed uso del know-how a fini industriali nella normativa sui programmi per elaboratore, in Contr. e impr. 1993, 1255; R ISTUCCIA e ZENO ZENCOVICH, Prime notazioni sulla legge a protezione del software, in Dir. inf. 1994, 251; RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92, CEDAM, Padova, 1993, 45; SARTI, Diritti esclusivi e circolazione di beni, Giuffrè, Milano, 1996, 239; Giov.GUGLIELMETTI, L’invenzione di software, Giuffrè, Milano, 1997, 215 in nota; Trib. Roma, 17 maggio 1993, in AIDA 1995, 309; contra v. l’isolata posizione di V.FRANCESCHELLI, sub art. 64 quinquies l.a., in NLCC 1995, 299; e di Trib. Bologna, 25 maggio 1998, in Repertorio AIDA 1998, 886. 39 Ritiene peraltro inevitabile una tale scelta TESTA, Durata del diritto, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 43, sulla base della considerazione (dichiarata anche in uno dei considerandi della direttiva 250/91/CEE) che una diversa previsione avrebbe portato ad un conflitto con la disciplina prevista dalla CUB; vi è stata, quindi, un’esigenza di adeguamento al diritto internazionale.

MAURO SANTO

15

CAPITOLO II LA TUTELA DEL SOFTWARE MEDIANTE BREVETTO

SOMMARIO: 1. La brevettabilità del software. – 2. Le decisioni dell’UEB. – 3. La proposta di direttiva comunitaria. – 4. Il panorama internazionale. 1. Estendere il software al novero delle invenzioni industriali, prevedendo quindi per esso una tutela

mediante esclusiva brevettuale, rafforzerebbe indubbiamente la protezione accordata ad un autore: gli verrebbe soprattutto assicurato il controllo dell’idea o del metodo alla base del programma. L’estensione della privativa sarebbe qualitativamente più ampia di quella prevista dal solo diritto d’autore, poiché con la brevettazione di un software il suo autore potrebbe stabilirne le più appropriate modalità di circolazione giuridica. In compenso però il software, o meglio, il suo codice sorgente, dovrebbe essere reso pubblico, e quindi sarebbe sempre possibile sviluppare ed avvalersi delle invenzioni altrui per innovare tecnologicamente, senza contare la presenza di istituti giuridici quali per esempio la licenza obbligatoria, volti a garantire sempre un efficace sfruttamento delle invenzioni industriali40. In realtà ciò avviene già, ed i software che presentino determinati requisiti possono essere brevettabili: vi è dunque una tutela complementare fra brevetto e diritto d’autore in materia di software.41 Un ruolo fondamentale hanno avuto le decisioni dell’UEB (nonché, ovviamente, le decisioni statunitensi in materia).

Tale conclusione non è però mai stata pacifica né in dottrina né in giurisprudenza. Quest’ultima, in ambito nazionale, aveva reso una pronuncia in cui affermava che il procedimento per ottenere disegni ed informazioni elaborati da un computer rilevando i dati attraverso un lettore ottico costituisse un’invenzione di combinazione brevettabile qualora il coordinamento dei diversi elementi già conosciuti fosse nuovo ed originale42; dopo questa sentenza però la questione non fu più specificamente affrontata dai giudici italiani. Il più recente punto di approdo del dibattito sulla brevettabilità dei programmi per elaboratore (materia che è stata definita “addirittura incandescente”43) è costituito dalla proposta di direttiva comunitaria attualmente in discussione presso il parlamento europeo44, presentata dalla commissione europea il 20 febbraio 200245; ed intorno ad essa sono rifiorite le discussioni e le polemiche, in questo caso piuttosto vivaci, sull’opportunità di prevedere che i software siano brevettabili al pari di altre invenzioni e sugli effetti che potrebbero aversi nei confronti del mercato, dei produttori e dei consumatori.

Ciò dimostra che la soluzione della questione non è stata affatto posta dall’art. 52 comma 2 lett.c Conv. Monaco, recepito dal legislatore nazionale nell’art.12 R.D. 29 giugno 1939, n.1127 (l.i.); entrambe queste disposizioni prevedevano (e prevedono tuttora) il divieto di brevettare programmi per elaboratori “in quanto tali”, sulla base della considerazione che essi erano del tutto simili ad altre entità come i metodi matematici ritenuti non brevettabili46. Questa soluzione aveva il suo precedente nella legislazione francese

40 In particolare, trascorsi tre anni dalla data del rilascio del brevetto, qualora l’invenzione brevettata non sia stata attuata nel territorio dello stato, può essere concessa a terzi richiedenti licenza obbligatoria per l’uso non esclusivo dell’invenzione; sull’istituto del brevetto v. GRECO e VERCELLONE, Le invenzioni ed i modelli industriali, UTET, Torino, 1968, 36 ss.; ed anche VANZETTI e DI CATALDO, Manuale di diritto industriale, 3ed., Giuffrè, Milano, 2002. 41 La complementarietà delle tutele applicabili al software è un dato ormai incontrovertibile; essa è ben messa in evidenza da Giov.GUGLIELMETTI, L’invenzione di software, 2ed., Giuffrè, Milano, 1997, 255 ss. 42 Cass. 14 maggio 1981 n. 3169, in R ISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993, 77 ss.. 43 Esattamente in questi termini si esprime AMMENDOLA, sub art. 12 l.i., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998. 44 Sull’attuale status della proposta di direttiva http://wwwdb. europarl.eu.int/oeil/oeil_View/DNL.ProcViewByNum?lang=2&procnum=COD/2002/0047.html 45 In GUCE 25/6/2002, C 151 E/129; ed in http://europa.eu.int/eur-lex/it/com/reg/it_register_1720.html 46 Oltre ai metodi matematici ed ai programmi per elaboratore non sono brevettabili in base agli artt. 52 CBE e 12 l.i.: le scoperte e le teorie scientifiche, i piani, i principi ed i metodi per attività intellettuali, per gioco o per attività commerciali, e le presentazioni di informazioni. Sul divieto previsto dall’art. 52 CBE v. AMMENDOLA, La brevettabilità nella convenzione di Monaco, Giuffrè, Milano, 1980, 390 ss.; BOSOTTI, sub art. 52 CBE, in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998. Sull’art. 12 l.i. v.

MAURO SANTO

16

(l. n. 68-1, 2 gennaio 1968) che conteneva una disposizione del medesimo tenore. Parte della dottrina non mancò però di sottolineare le imperfezioni di questa legislazione47. In realtà il vero oggetto del contendere era l’effettiva natura dei programmi per elaboratore; discutere sulla utilità di ammettere che i software fossero brevettabili, implicava che vi fosse certezza o comunque consenso, sulla qualificazione da dare loro all’interno delle normative relative alla proprietà intellettuale48.

Al riguardo valgono le considerazioni svolte precedentemente in tema di tutela mediante diritto d’autore: su questo punto si era ben lontani da una visione comune, a causa soprattutto della novità del software tra le opere dell’ingegno; in particolare il suo carattere di utilità e la sua destinazione funzionalistica rendevano ardua una chiara classificazione. Vi erano inoltre peraltro apparenti affinità con il resto delle invenzioni industriali, come per esempio la destinazione del software ad un apparato elettronico ed il fatto che fosse creato secondo un linguaggio specifico.

In ogni caso, un ruolo fondamentale ha avuto la giurisprudenza dell’UEB49. 2. Come si è visto, la legislazione nazionale e quella dei paesi aderenti alla conv. di Monaco prevede

il divieto di brevettabilità del software “in quanto tale”. Da questa norma l’Ufficio Europeo Brevetti (UEB) ha preso le mosse per una elaborazione giurisprudenziale che continua tuttora.

Infatti, sebbene le norme siano rimaste uguali, l’evoluzione dei criteri alla base della brevettabilità dei programmi per elaboratore ha subito un notevole sviluppo, che ha i suoi momenti fondamentali in alcune specifiche decisioni.

L’opera compiuta dalla giurisprudenza dell’UEB50 è partita innanzitutto dall’isolare, come oggetto escluso dalla brevettabilità, i programmi in quanto tali. Quindi, qualora ad essere sottoposti all’esame dell’UEB non fossero software in quanto tali, vi era un potenziale spazio per una loro brevettabilità. Tuttavia, se era chiara l’identità minima di un programma in quanto tale, ovvero la sua presentazione come mera sequenza di istruzioni basate su un algoritmo matematico (non brevettabile proprio per la similarità agli altri oggetti non brevettabili, come metodi matematici e formule scientifiche), non vi era certezza circa il confine oltre il quale un software non era più “in quanto tale”, ossia non si risolveva più in una mera rappresentazione di un algoritmo. È stato proprio su questo concetto che si è concentrata l’attività interpretativa dell’UEB.

Attualmente, posto che l’UEB ha affermato che le eccezioni alla brevettabilità devono intendersi in senso restrittivo e che altre convenzioni internazionali, come l’accordo TRIPs, seppur non vincolanti per l’UEB, non prevedono affatto il divieto di brevettare software, i programmi per elaboratore che presentino un carattere nonché un risultato tecnico sono ritenuti brevettabili, purché naturalmente presentino tutti gli

AMMENDOLA, sub art. 12 l.i., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998. 47 Rimprovera una certa superficialità al legislatore francese e raccomanda di non considerare i software solo come idonei a risolvere processi astratti (in particolare processi matematici) ETT.LUZZATTO, Una norma francese da non imitare, in Riv. dir. ind. 1968, I, 297 ss.; letto a più di trent’anni di distanza stupisce la attualità di questo scritto e la sua preveggenza: l’A. affermava infatti che “…attraverso una lunga e travagliata interpretazione giurisprudenziale si stabilirà che sì, i programmi di calcolatrici di carattere puramente astratto non sono brevettabili, ma vi sono altri programmi che non rientrano nelle proibizioni della legge e che brevettabili invece sono.” Egli evidenziò anche l’importanza ai fini della brevettazione dell’applicazione di un software ad un processo tecnico. Le stesse posizioni, aggiornate ed approfondite, sono sostenute anche con riferimento alla conv. di Monaco: ETT.LUZZATTO e RAIMONDI, Patentability of software, particularly in the european legislation, in Riv. dir. ind. 1981, I, 65 ss. 48 Si esprime a favore della configurabilità dell’algoritmo come invenzione tout court BORRUSO, L’algoritmo per computer e la sua brevettabilità, in Dir. inf. 1987, 75 ss.; altri autori ne hanno invece ammesso la brevettabilità del software solo nei casi in cui esso comandi un nuovo metodo o processo industriale: così SENA, I diritti sulle invenzioni e sui modelli industriali, 3ed., Giuffrè, Milano, 1990, 177-179; ID., Brevetto per invenzioni industriali, in Dig. comm, II, UTET, Torino, 1987, 338. 49 Qui di seguito, per comodità, si userà la parola giurisprudenza riferendosi all’insieme delle decisioni e dell’attività dell’Ufficio Europeo Brevetti, nella consapevolezza comunque che non si tratta affatto di un organo giurisdizionale. 50 Sull’evoluzione delle decisioni dell’UEB v. HANNEMANN, The patentability of computer software, Kluwer law & taxation publishers, Deventer, 1985, 251-257; Giov.GUGLIELMETTI, Brevettabilità delle invenzioni concernenti software nella giurisprudenza della Commissione di ricorso dell’Ufficio europeo dei brevetti, in Riv. dir. ind. 1994, II, 358 ss.; ID., L’invenzione di software, 2ed., Giuffrè, Milano, 1997, 40 ss.; FRASSI, Creazioni utili e diritto d’autore, Giuffrè, Milano, 1997, 42-50.

MAURO SANTO

17

altri requisiti della novità, non ovvietà ed industrialità, e dopo che sia stato valutato in concreto l’oggetto dell’invenzione di cui è parte il programma o comunque l’uso cui esso sarà destinato.

Se quest’ultimo punto si risolve sostanzialmente nello stabilire se l’invenzione contenente il programma sia brevettabile, un punto fondamentale è invece capire cosa si intenda per carattere e risultato tecnico; in realtà l’UEB non ne ha mai dato una chiara e precisa definizione, ma, come spesso accade per il diritto di formazione giurisprudenziale, il significato dell’espressione è deducibile dal confronto delle singole decisioni e dal loro oggetto. È quindi opportuno ripercorrere i momenti fondamentali dell’evoluzione delle considerazioni svolte dai giudici di Monaco.

La prima pronuncia che ha trattato il programma per elaboratore come oggetto di brevetto è stata la decisione T 208/84 (Vicom)51: nel caso di specie si doveva stabilire l’eventuale brevettabilità di un trovato consistente nell’elaborazione, tramite l’applicazione di un metodo matematico ad un software, di immagini digitali rappresentate su uno schermo, di cui veniva modificato il contrasto tra le varie parti dell’immagine stessa. La tutela mediante brevetto ad una siffatta invenzione è stata riconosciuta, sulla base principalmente della seguente considerazione: se il metodo matematico fosse stato impiegato per operare con risultati numerici, sarebbe stata esclusa la brevettabilità, poiché sarebbe corrisposto ad una formula matematica; ma siccome in questo caso il metodo matematico operava su grandezze fisiche per ottenere risultati anch’essi fisici, la rivendicazione non aveva ad oggetto un programma (e cioè algoritmo o metodo matematico che dir si voglia) in quanto tale, bensì un programma che era parte di un più ampio procedimento tecnico (l’elaborazione delle immagini, appunto).

Era stata in concreto posta la fondamentale distinzione tra il mero metodo matematico ed il metodo operativo; erano la medesima cosa (ovvero l’idea alla base del programma per elaboratore): la distinzione verteva però sull’eventuale presenza della realizzazione di un procedimento tecnico.

Successivamente si è avuta la decisione T 26/86 (Koch & Sterzel), che sviluppava ulteriormente le premesse poste nel caso Vicom; la fattispecie verteva sulla brevettabilità di un apparato radiologico comandato da un software, il quale dosava la quantità di radiazioni da emettere. In questo caso la reale innovatività del trovato era proprio nel software che automatizzava determinate operazioni, e quindi, in concreto, esso diveniva l’oggetto del giudizio; fu affermato che il trovato era brevettabile, è ciò indipendentemente da una valutazione sull’invenzione considerata senza il relativo software. Sostanzialmente si stabilì che un’invenzione doveva essere valutata nel suo complesso, come un insieme di elementi tecnici e non. Il passo avanti rispetto al caso Vicom è chiaro: se lì si stabiliva che era brevettabile un software che creasse un operato tecnico, qui si stabilisce che tale operato tecnico può benissimo essere l’oggetto dell’unione di un programma per elaboratore con un apparato già esistente. La valutazione sulla presenza dei requisiti di brevettabilità si spostava così dal software all’invenzione nel suo complesso.

Importante è anche la decisione T 6/83 (IBM), in cui è stato giudicato un programma che non aveva alcun rapporto con una più ampia invenzione, ma che si limitava a coordinare e controllare programmi e schedari di computer diversi; i giudici affermarono che doveva essere considerato come la soluzione di un problema tecnico, poiché non gestiva solamente dei dati, bensì migliorava le funzionalità dei singoli elaboratori; in tal modo venne di fatto ammessa la brevettabilità anche per programmi di per sé considerati, senza connessione con l’apparato in cui sarebbero stati introdotti, ma avendo riguardo solo alla loro utilità (utilità, appunto, tecnica).

Questo concetto è stato approfondito e chiarito in una serie di decisioni successive (in particolare nelle decisioni T 110/90 Ibm e T 769/92 Sohei52) , dal complesso delle quali si ricava che la brevettabilità di un’invenzione non è pregiudicata dal solo fatto che in essa siano presenti (e fondamentali) moderni mezzi tecnici quali i software; ciò non significa peraltro che un software deve essere sempre considerato mezzo tecnico. In particolare, determinate attività non sono brevettabili per il solo fatto di essere attuate mediante un programma per elaboratore. Nel caso di specie si trattava di un software che sostituiva alcune espressioni con altre di medesimo significato: sulla base dell’assunto che questa era una mera trasposizione di operazioni eseguibili anche mentalmente ne è stata negata la brevettabilità. In sintesi è stato chiarito che il requisito tecnico fondamentale per ritenere brevettabile un’invenzione, non è un carattere insito di per sé nei programmi per elaboratore, ma deve essere cercato al di fuori di essi; quindi svolgere un’attività mediante un software non le conferisce automaticamente il requisito tecnico.

Vengono dunque esclusi dal novero delle invenzioni brevettabili i programmi che si limitano ad elaborare dati od informazioni; ciò è esplicitamente affermato d’altra parte nella decisione T 158/88

51 CR UEB 15 luglio 1986 T 208/84, in RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993, 147-154. 52 CR UEB 15 aprile 1993 T 110/90, in AIDA 1993, 124, con nota di G.G(UGLIELMETTI); CR UEB 31 maggio 1994 T 692/92, in AIDA 1995, 295, con nota di G.G(UGLIELMETTI).

MAURO SANTO

18

(Siemens), dove non è stato ritenuto brevettabile un trovato consistente in un software che rappresentava, in modo dinamico su un monitor, lettere di forma grafica diversa a seconda della loro posizione all’interno di una parola.

L’UEB ha infine specificato la sua posizione nelle decisioni T 0935/97 e T 1173/97, affermando che il carattere tecnico non può dedursi dal carattere fisico del supporto in cui esso è contenuto né dal procedimento in cui tale programma è usato53. Ma soprattutto è stata analizzata l’espressione “in quanto tali”, e si è giunti alla conclusione che devono ritenersi esclusi dalla brevettazione i programmi per elaboratore che corrispondano a mere creazioni astratte; sono invece brevettabili i programmi che mostrino caratteri di natura tecnica. Inoltre i giudici hanno affrontato anche il requisito del carattere tecnico, sostenendo che quest’ultimo è presente anche quando il programma abbia un effetto tecnico supplementare che non sia limitato alle normali interazioni fisiche fra programma ed elaboratore sul quale esso funziona. Sono allora ammessi alla brevettabiltà i software che agiscono sulla funzionalità dell’hardware.

È stato anche chiarito che in materia di software è perfettamente ammissibile una tutela sia mediante diritto d’autore che mediante esclusiva brevettuale, essendo queste due forme di tutela complementari fra di loro ed avendo oggetti sostanzialmente diversi; i giudici hanno inoltre spiegato che il campo delle invenzioni non brevettabili deve essere interpretato in senso restrittivo, e che dunque l’opera dell’UEB fino ad oggi non è affatto contraria alle norme della CBE, poiché il compito dell’UEB è quello di promuovere il progresso concedendo alle invenzioni adeguata tutela; a conferma di ciò si è fatto riferimento anche all’accordo TRIPs, i quali comunque non vincolano affatto l’UEB; si è sottolineato che nell’elenco di invenzioni che i vari stati possono escludere dalla brevettabilità, non figurano affatto i programmi per elaboratore, nemmeno nella loro configurazione minima e più astratta (in quanto tali).

Ecco dunque che, dalla (seppur sommaria) analisi dell’evoluzione giurisprudenziale dell’UEB, è più agevole intendere la situazione attuale circa la brevettabilità del software di cui si diceva sopra: necessità della presenza di un requisito tecnico (inteso come l’opposto della mera trasposizione di attività astratte mentali) e opportunità di una valutazione dell’invenzione nel suo complesso54.

Indubbiamente la prassi è ben più ardua di quanto possa dedursi dalle precedenti righe; la particolare fisionomia dei programmi per elaboratore, la peculiarità del settore informatico e la rapida e costante evoluzione cui va incontro, nonché la specificità dei concetti e delle applicazioni dei software, rendono necessarie complicate valutazioni ben più complesse, in concreto, della mera rinvenibilità di un eventuale carattere tecnico.

Se questa è la posizione giurisprudenziale, anche il legislatore pare prenderne atto, in particolare quello europeo.

3. All’inizio del 2002 la commissione europea ha trasmesso al parlamento europeo una proposta di

direttiva, relativa proprio alla brevettabilità delle invenzioni attuate per mezzo di elaboratori elettronici55. Essa stabilisce all’art. 2 che devono intendersi attuate per mezzo di elaboratori elettronici, le

invenzioni la cui esecuzione implica l’uso di un elaboratore, ma soprattutto che presenta a prima vista una o più caratteristiche di novità realizzate in tutto o in parte per mezzo di uno o più programmi per elaboratore. Ecco dunque che si permette, di fatto, la brevettazione dei software, poiché l’oggetto della discussione può risolversi nel solo programma per elaboratore.

Oltre a ciò la direttiva definisce anche il contributo tecnico, che abbiamo visto fondamentale nella giurisprudenza dell’UEB: contributo allo stato dell’arte in un settore tecnico, giudicato non ovvio da una persona competente nella materia.

53 CR UEB 1 luglio 1998 T 1173/97 e CR UEB 4 febbraio 1999 T 0935/97, in OJEPO, www.european-patent-office.org; disponibili anche in Riv. dir. ind., II, 1999, 545 ss., con nota di BENUSSI, La giurisprudenza europea in materia di software di fronte ad un nuovo orientamento?, in Riv. dir. ind., II, 1999, 563 ss. 54 Per le più recenti applicazioni, anche negli ordinamenti nazionali, di questi principi v. in particolare le pronunce della giurisprudenza tedesca (che si ritiene meritevoli di attenzione, essendo la Germania la nazione europea con il più alto numero di brevetti concessi annualmente): Bundesgerichthof 13 dicembre 1999 n. 11/98, in IIC 2002, 231-239; Bundesgerichthof 11 maggio 2000 n. 15/98, in IIC 2002, 343-348; Bundesgerichthof 17 ottobre 2001 n. 16/00, in IIC 2002, 753-762; tutte queste decisioni sono accomunate dalla considerazione che il carattere tecnico non è escluso dal fatto che sia necessaria, insieme all’attività dell’elaboratore anche un’eventuale attività complementare dell’uomo; in sostanza si tratta di tutti quei software che non automatizzano totalmente un processo, ma semplicemente lo rendono più agevole per l’uomo. 55 In GUCE 25/6/2002, C 151 E/129; ed in http://europa.eu.int/eur-lex/it/com/reg/it_register_1720.html

MAURO SANTO

19

L’art. 3 prescrive che gli stati membri assicurano che un’invenzione attuata per mezzo di elaboratori elettronici sia considerata appartenente ad un settore della tecnologia.

Il successivo art. 4 pone le condizioni della brevettabilità: 1) Gli stati membri assicurano che un’invenzione attuata per mezzo di elaboratori elettronici sia brevettabile, a condizione che sia atta ad un’applicazione industriale, presenti un carattere di novità ed implichi un’attività inventiva. 2) Gli stati membri assicurano che, affinché sia considerata implicante un’attività inventiva, un’invenzione attuata per mezzo di elaboratori elettronici arrechi un contributo tecnico. 3) Il contributo tecnico è valutato considerando la differenza tra l’oggetto della rivendicazione di brevetto nel suo insieme, i cui elementi possono comprendere caratteristiche tecniche e non tecniche, e lo stato dell’arte.

L’art. 5 prevede invece che gli stati membri assicurano che un’invenzione attuata per mezzo di elaboratori elettronici possa essere rivendicata come prodotto, ossia come elaboratore programmato, rete di elaboratori programmati o altro apparecchio programmato, o come processo realizzato da tale elaboratore, rete di elaboratori o apparecchio mediante l’esecuzione di un software.

Vi è poi l’art. 6, il quale afferma che la protezione conferita dai brevetti per le invenzioni che rientrano nel campo d’applicazione della presente direttiva, lascia impregiudicate le facoltà riconosciute dalla direttiva 91/250/CEE relativa alla tutela giuridica dei programmi per elaboratore mediante il diritto d’autore, in particolare le disposizioni relative alla decompilazione ed all’interoperabilità o le disposizioni relative alle topografie dei semiconduttori o ai marchi commerciali.

Gli artt. 7, 8, 9, 10 e 11 si risolvono invece in disposizioni circa l’attuazione e l’entrata in vigore della direttiva, nonché su attività della commissione consistenti nella presentazione di una relazione dopo l’entrata in vigore della direttiva e nel monitoraggio dei suoi effetti sulla concorrenza e sull’innovazione.

Si può da subito notare la reale portata di queste disposizioni; esse non pongono nuovi requisiti per la brevettabilità né modificano la disciplina sostanziale, poiché ricalcano sostanzialmente le conclusioni cui è da tempo giunta la giurisprudenza dell’UEB; la stessa relazione alla direttiva, nella parte dedicata al commento dei singoli articoli, trattando dell’art. 4 richiama espressamente le decisioni dei casi Vicom e Koch & Sterzel, al fine di valutare l’attività inventiva nel suo complesso e nel richiedere per essa la presenza di un contributo tecnico (per quest’ultimo viene letteralmente citata la giurisprudenza dell’UEB). Tuttavia, il commento all’art. 3 nonché il considerando 13 sono espliciti nell’escludere dalla brevettabilità un algoritmo definito senza riferimento ad un ambiente fisico, poiché non presenta alcun carattere tecnico.

Dunque la direttiva prende atto dell’esistente; ma a che scopo introdurre norme identiche alla ormai consolidata posizione giurisprudenziale? La risposta è nei considerando 1, 2 e 5: assicurare una protezione efficace ed armonizzata delle invenzioni attuate per mezzo di elaboratori elettronici in tutti gli stati membri, eliminare le discrepanze nella tutela giuridica di queste invenzioni e rendere trasparenti le norme che disciplinano la loro brevettabilità. Infatti la conv. di Monaco non è parte della legislazione comunitaria, bensì è una comune convenzione internazionale, il cui principale oggetto è quello di istituire una disciplina ed un organo comune per rilasciare brevetti validi in tutti gli stati aderenti alla convenzione56.

La legislazione interna di questi stati si è adeguata alla convenzione, prevedendo dunque l’esclusione dei programmi per elaboratore in quanto tali dalla brevettabilità; tuttavia vi possono essere interpretazioni giurisprudenziali differenti, facenti capo all’UEB (l’organo decisionale previsto dalla conv. Monaco) o ai tribunali dei singoli stati. Come paventa la stessa relazione alla direttiva, può accadere che un’invenzione protetta in uno stato non lo sia in un altro, a causa delle differenze nell’applicazione della normativa sui brevetti da parte della giurisprudenza dei singoli stati. E ciò avrebbe infine innegabili effetti negativi sul buon funzionamento del mercato interno.

Prevedendo invece un’apposita direttiva, i cui contenuti ricalchino la giurisprudenza dell’UEB, anche le corti dei singoli stati vi sarebbero vincolate, eliminando così in radice possibilità di divergenze. In breve, scopo della direttiva è la mera armonizzazione delle legislazioni; inoltre, fatto non secondario, entrando a far parte della normativa comunitaria, la brevettabilità del software diverrebbe materia giudicabile dagli organi giurisdizionali comunitari, favorendo ulteriormente l’armonizzazione57.

In tal modo, come previsto dall’art. 6 e come già affermato dall’UEB, il software potrebbe godere di due tutele fra loro complementari: esclusiva brevettuale e diritto d’autore, essendo quest’ultimo impregiudicato.

56 Sul ruolo della CBE in rapporto alla normativa nazionale e sugli organi da essa previsti AMMENDOLA, La brevettabilità nella convenzione di Monaco, Giuffrè, Milano, 1980, 1 ss.; BENUSSI, Brevetto europeo, in Dig. comm., II, UTET, Torino, 1987, 323-332. 57 Questa soluzione era già auspicata anche da BRANDLE, Can and may interpretation and determination of the extent of proctetion of an european patent in different countries lead to different results? , in IIC 1999, VIII, 881-882, secondo cui si eviterebbero così possibili contrasti tra le giurisprudenze nazionali.

MAURO SANTO

20

Nonostante l’armonizzazione delle normative sia lo scopo dichiarato della direttiva, essa ha suscitato accesi dibattiti. Nella naturale pluralità e varietà delle opinioni, sembrano emergere due posizioni: coloro che sono favorevoli, sull’assunto che si pone una precisa e chiara normativa per la brevettazione dei software, e coloro che sono contrari58. Questi ultimi temono che di fatto introdurre queste norme accelererebbe l’evoluzione interpretativa della giurisprudenza (che è giunta all’attuale posizione elaborando il concetto “in quanto tale”); riferirsi al carattere tecnico di un software agevolerebbe l’ulteriore abbassamento della soglia di brevettabilità ad opera delle interpretazioni giurisprudenziali. Si passa da coloro che escludono in assoluto che un software possa ritenersi brevettabile, a coloro che ammettono la brevettabilità solo per software i quali siano parte di processi industriali (con esclusione dunque dei software utilizzabili sui computer di uso generale), paventando la creazione di monopoli proprio tramite l’istituto del brevetto. Soprattutto i sostenitori del software open source hanno espresso le loro perplessità, affermando che un’eventuale brevettabilità indistinta dei software annullerebbe di fatto le tipiche modalità di sviluppo del software libero59 (su cui v.infra). Qualche critica alla direttiva è giunta anche sulla base della considerazione che essa fa propri criteri che, di fatto, sono stati superati dalla giurisprudenza dell’UEB.

Torna dunque ad accendersi (ammesso che si fosse mai spento) il dibattito sulla brevettabilità del software, o meglio, sui requisiti necessari perché un programma possa essere brevettabile (poiché ormai, che possano essere oggetto di brevetto, è indiscutibile), a riprova del fatto che l’adattare il sistema di diritto d’autore al software non rispondeva a tutte le esigenze di tutela ad esso connesse.

Importanti sono anche le considerazioni economiche: la direttiva adotta la visione del brevetto sul software (o, come si esprime la direttiva, la certezza delle regole sulla sua brevettabilità) come strumento di protezione e di stimolo delle piccole e medie imprese del settore informatico che nel campo europeo sono la maggioranza; il ragionamento esposto nella relazione alla direttiva è, in sintesi, il seguente: dovendo le imprese europee competere con le grandi multinazionali (soprattutto statunitensi), e non tutelando il diritto d’autore l’idea alla base di un software, esse sarebbero più esposte alla concorrenza delle grandi imprese, che godrebbero di un più competitivo ed efficiente apparato commerciale. Ciò appare in effetti incontestabile; la sua validità risiede però nell’assunto, implicito, che le imprese europee siano in grado di produrre software (brevettabili), concorrenti con quelli delle grandi imprese.

In realtà la direttiva non approfondisce abbastanza, a parere di chi scrive, un altro aspetto, e cioè se l’eventuale brevettabilità dei software lasci sopravvivere le piccole e medie imprese europee; spesso infatti queste ultime si rivolgono a settori specifici, basandosi spesso sui software delle grandi imprese. Ammettendo una generale e liberale brevettabilità dei software, si correrebbe il rischio di rendere le imprese europee dipendenti dalle grandi multinazionali del settore.

D’altra parte questo rischio lo intravede anche il legislatore comunitario, consapevole anch’egli che, di fatto, la direttiva non è una mera armonizzazione delle legislazione degli stati membri, ma potrebbe aprire le porte ad una indiscriminata brevettabilità dei programmi per elaboratore. Non si spiegherebbero altrimenti, infatti, gli artt. 7 e 8, i quali fanno obbligo alla commissione di osservare gli effetti delle invenzioni attuate per mezzo di elaboratori elettronici sull’innovazione e sulla concorrenza, in Europa e sul piano internazionale, e sulle imprese europee; ed inoltre di riferire entro tre anni dalla attuazione della direttiva sui suoi effetti.

Personalmente ritengo che quando ci si accinge a varare o modificare norme relative all’istituto del brevetto, bisognerebbe prescindere da posizioni aprioristiche o da contingenti valutazioni economiche. Il giudizio sulla brevettabilità e sui suoi requisiti relativamente ai programmi per elaboratore elettronico, dovrebbe avere come riferimento costante il rapporto nei confronti di quello che, in fin dei conti, è lo scopo dell’istituto brevettuale, e cioè l’innovazione60. Se si ritiene che la direttiva possa avere benefici effetti sull’innovazione del settore informatico, allora ben venga; se però si corre il rischio che l’istituto del

58 Per i vari pareri espressi sulla proposta di direttiva, v. la relazione ad essa: http://europa.eu.int/eur-lex/it/com/reg/it_register_1720.html; cfr. pure MORGAN, Chaining open source software: the case against software patents, http://lpf.ai.mit.edu/Patents/chaining-oss.html, il quale afferma che una ampia brevettabilità dei software di fatti impedirebbe lo sviluppo ulteriore dei programmi open source. 59 Si è anche redatta una petizione contro la proposta di direttiva: http://petition.eurolinux.org/index.html. 60 Sulla funzione del sistema brevettuale e sullo stimolo dell’innovazione come elemento chiave per l’interpretazione degli istituti relativi all’esclusiva brevettuale SENA, Brevetto e monopolio, in Riv. dir. ind. 1963, I, 287 ss.; L.C.UBERTAZZI, Invenzione e innovazione, Giuffrè, Milano, 1978, 1 ss.; nonché J.COHEN e LEMLEY, Patent scope and innovation in the software industry, in Calif. L. Rev. 2001, 1 ss.; S.COHEN, To innovate or not to innovate, that is the question: the functions, failures, and foibles of the reward function theory of patent law in relation to computer software platforms, in Mich. Telecomm. Tech. L. Rev. 1998/1999, 1 ss.

MAURO SANTO

21

brevetto venga trasformato in improprio strumento per la consolidazione e lo sfruttamento di ingiustificati monopoli, allora bisognerebbe adeguatamente riflettere.

4. Un excursus va dedicato al panorama internazionale, in particolare agli Stati Uniti ed al Giappone,

nazioni tecnologicamente avanzate le quali hanno ammesso alla brevettabilità il software prima dell’UEB, e che oggi sembrano adottare un approccio più liberale rispetto quest’ultimo.

Negli Stati Uniti il Patent Act non detta una disciplina specifica per il software, ma la giurisprudenza è giunta a negare la brevettabilità degli algoritmi matematici. Anche in questo paese è stata l’interpretazione dei giudici a segnare l’evoluzione dei requisiti necessari per rendere un software oggetto di brevetto61.

L’analisi della giurisprudenza statunitense inizia con il caso Benson, in cui fu negata la brevettabilità di un programma che convertiva i numeri decimali in binari e viceversa, sulla base di una sua affinità con gli algoritmi matematici, esclusi insieme a processi mentali e soperte scientifiche dalla brevettabilità. Affermata la tendenziale analogia dei software con gli algoritmi, fu tuttavia enunciato che ciò non escludeva comunque i programmi dalla brevettabilità, poiché comunque essi manifestavano analogie anche con le altre entità suscettibili di invenzione e quindi di brevettazione; gli stessi principi furono enunciati nel caso Parker.

Fu il caso Diehr ad introdurre definitivamente il brevetto tra i programmi per elaboratore; il software in questione permetteva di gestire un processo d’apertura degli stampi per la vulcanizzazione della gomma. In particolare venne ritenuto ammissibile brevettare un algoritmo matematico (quale quello alla base del software) che avesse però un’applicazione tecnica; e la valutazione sulla presenza dell’applicazione tecnica dipendeva da un giudizio relativo all’invenzione nel suo complesso62.

Furono posti dunque i principi generali, tuttora validi, di separazione tra software brevettabili e non: innanzitutto era necessaria una valutazione dell’invenzione nel suo complesso; le applicazioni dei metodi di calcolo connessi ad algoritmi matematici sono brevettabili, con esclusione perciò dei meri algoritmi.

Tali principi furono ulteriormente chiariti e precisati in altre decisioni (in particolare nei casi Freeman, Walter ed Abele): dal loro contenuto è stato possibile enucleare il cosiddetto two-step-test, ovvero il metodo attraverso cui giungere ad una soluzione sulla brevettabilità o meno di un software; in base a questo test le fasi sono due: una prima, in cui è necessario verificare se la rivendicazione includa un metodo matematico o comunque un algoritmo; qualora ciò non avvenga nemmeno indirettamente, il trovato deve ritenersi potenzialmente idoneo ad essere brevettato. Se invece la domanda di brevetto verte su un metodo matematico, e questa è la seconda fase, bisogna stabilire se esso sia in qualche modo legato ad entità o processi fisici: in caso di risposta positiva sarà ammessa la brevettazione, negata invece in caso di risposta negativa, ossia qualora l’algoritmo non sia in alcun rapporto con entità o processi fisici63.

È questo il modello fondamentale delle attuali valutazioni dei giudici statunitensi, modello che, seppur con i necessari adattamenti dovuti ad un decennale sviluppo del settore informatico ed ai numerosi casi decisi, mantiene gli stessi principi basilari, sebbene sia stato comunque ampliato lo spettro dei significati attribuibili alla locuzione processi fisici (includendo nella brevettabilità anche i business methods64), che ha determinato l’indirizzo piuttosto liberale adottato dalla giurisprudenza statunitense in materia di brevettabilità dei software.

A risultati del tutto simili è giunta anche la giurisprudenza giapponese, che condivide con quella statunitense un approccio alla brevettabilità dei software più aperto rispetto all’UEB: peraltro il processo logico sviluppato dall’ufficio brevetti giapponese differisce dal two-step-test americano, sebbene anche in

61 Per un’analisi della giurisprudenza statunitense DRAGOTTI, Software, brevetti e copyright: le recenti esperienze statunitensi, in Riv. dir. ind. 1994, I, 539 ss.; Giov.GUGLIELMETTI, L’invenzione di software, 2ed., Giuffrè, Milano, 1997, 33-39 e 176-185; FRASSI, Creazioni utili e diritto d’autore, Giuffrè, Milano, 1997, 51-60. 62 Per un’approfondita disamina della decisione del caso Diehr v. STOUT, La brevettabilità del software nella più recente giurisprudenza americana, in Dir.Inf. 1986, 78-82. 63 Sul two.step-test come processo logico alla base delle decisioni dei giudici statunitensi HANNEMANN, The patentability of computer software, Kluwer law & taxation publishers, Deventer, 1985, 249; DRAGOTTI, Software, brevetti e copyright: le recenti esperienze statunitensi, in Riv. dir. ind. 1994, I, 541-548; Giov.GUGLIELMETTI, L’invenzione di software, 2ed., Giuffrè, Milano, 1997, 176-185. 64 In particolare v. il caso State Street Bank & Trust v. Signature Financial Group Inc., in GLADSTONE, Why patenting information technology and business methods is not sound policy: lessons from history and prophecies for the future, in Hamline L. Rev. 2002, 217 ss.; su questa tendenza della giurisprudenza statunitense l’A. è decisamente critica, mettendo in guardia dal rischio di snaturare completamente l’istituto del brevetto.

MAURO SANTO

22

questo caso i momenti essenziali del ragionamento siano sostanzialmente due. Nel primo si stabilisce se l’invenzione comporti un’idea tecnica, requisito che sarà di fatto rispettato ogniqualvolta l’invenzione necessiti di un computer (e quindi di un software) per essere realizzata; successivamente verrà valutata l’essenza della rivendicazione, da identificarsi nella soluzione offerta dall’invenzione: se essa è di natura fisica allora il trovato sarà brevettabile, mentre non lo sarà qualora la soluzione proposta dall’invenzione non sia di natura fisica (come per esempio una soluzione matematica ad un problema di natura essenzialmente matematica: e si conferma una volta ancora l’esclusione dei meri algoritmi dalla brevettabilità)65.

Volgendo lo sguardo anche ad altre nazioni, si può citare il caso dell’Australia, il cui ufficio brevetti ha sostanzialmente adottato già nel corso degli anni’80 i concetti espressi negli Stati Uniti, in particolare giudicando sulla brevettabilità dei software avvalendosi del two-step-test dei casi Freeman-Walter-Abele, e rendendo così l’evoluzione di quel paese in materia del tutto simile a quella statunitense (compresa l’attitudine a brevettare business methods)66.

Anche paesi che fino ad ora hanno mantenuto un orientamento piuttosto restrittivo sulla brevettabilità dei software, come per esempio Israele, pare che siano ora in procinto di adeguarsi al trend giurisprudenziale americano ed europeo67: a conferma che ormai la brevettabilità del software è un dato scontato; meno scontati sono invece i requisiti necessari.

65 Sulla brevettabilità del software nella giurisprudenza giapponese e nelle guidelines JPO v. HANNEMANN, The patentability of computer software, Kluwer law & taxation publishers, Deventer, 1985, 250. 66 Cfr. OLD, Patenting computer-related inventions in Australia, in IIC 1993, III, 345 ss.; BIRD, In brief – Australian patents, in Patent World 2002, 146 ss. 67 HAUSMAN, COHN e PRESENTI, Will Israel follow the USA, Japan, and the EPO and allow patent protection for software?, in IIC 2002, I, 15 ss.; gli A. sostengono che anche Israele sia in procinto di adottare gli stessi principi della giurisprudenza americana: basano le loro opinioni sull’imminente armonizzazione delle norme interne con l’accordo TRIPs, e sulla proprensione del sistema giuridico israeliano ad avvalersi degli strumenti propri del diritto comparato; su tale propensione v. ZWEIGERT e KOTZ, Introduzione al diritto comparato I, Giuffrè, Milano, 1998, 286 ss.

MAURO SANTO

23

CAPITOLO III LE LICENZE GNU: CONSIDERAZIONI INTRODUTTIVE

SOMMARIO: 1. Le licenze pubbliche GNU. – 2. Codice sorgente e codice oggetto.

1. “La GPL usa il diritto d’autore per contraffare il fenomeno dell'anarchia”68: questa frase rappresenta

forse meglio di altre un giudizio che si potrebbe dare della GPL; è soprattutto l’espressione “usa il diritto d’autore” a cogliere nel segno. Di seguito si capirà il perché.

Le licenze pubbliche GNU69 sorgono durante la metà degli anni ’80 come soluzione all’esigenza di coloro che sostenevano il valore del codice sorgente dei software, e l’importanza di riconoscere a chiunque la possibilità di modificarlo. Da qui, dal codice sorgente disponibile e quindi aperto, la corrente definizione di software open source per i software distribuiti, appunto, sotto le condizioni delle licenze pubbliche GNU.

È necessario provvedere, prima di approfondire il discorso, ad una premessa terminologica riguardo alle parole licenza pubblica. Anche in questo caso, come in quello più generale della distribuzione dei software, il termine licenza è usato in un’accezione atecnica, ovvero senza alcun riferimento alla disciplina che l’ordinamento italiano detta al riguardo, ma come semplice descrizione di quel particolare tipo di contratto entro il cui schema vengono distribuiti i software, e che tanta attenzione ha attirato da parte della dottrina70. Probabilmente l’uso atecnico di questa parola è dipeso soprattutto dalla prassi contemporanea di acquisire acriticamente nuove forme e nuovi termini contrattuali sviluppati dal commercio internazionale, che porta spesso all’introduzione senza alcun adattamento di nuovi contratti in un ordinamento mediante la loro mera traduzione, ed il cui contenuto presenta talvolta un linguaggio giuridico totalmente estraneo a quello dell’ordinamento entro cui saranno trasposti; e ciò è avvenuto ed avviene tuttora soprattutto nel campo dei software71.

L’aggettivo pubblica si riferisce invece al fatto che queste licenze sono caratterizzate da una significativa estensione delle possibilità di sfruttamento del software da parte dei terzi.

Appurato dunque cosa debba intendersi per licenza pubblica, possiamo vedere che il fenomeno dell’open source ed il sistema delle licenze pubbliche GNU, entrambi strettamente collegati, non sono sorti contemporaneamente. Il metodo open source è infatti un metodo sorto parallelamente alla nascita dei computer e dei software, e trovava applicazione soprattutto in ambiente accademico o tra i pochi esperti che lo sfruttavano. Rendendo pubblico il codice infatti si permettevano migliorie ed avanzamenti più celeri, ed inoltre si condividevano idee e progetti, fondamentali anche per le esigenze didattiche. Con lo sviluppo dei personal computer durante gli anni’80 e’90 numerose imprese si affacciarono sul mercato dei software, diventato frattanto un mass-market, non distribuendo assolutamente il codice sorgente, probabilmente per due ragioni principali: la prima, per evitare di agevolare la concorrenza, la seconda, che probabilmente nel momento in cui il software è indirizzato anche a non specialisti ma a semplici utenti, ebbene costoro non hanno alcun interesse verso il sorgente.

Il revirement del sorgente è dovuto soprattutto al rapidissimo ed esponenziale sviluppo di Internet: poiché è stata costruita come una rete aperta, soprattutto da utilizzare in fieri, la disponibilità del codice sorgente è stata utilissima per risolvere problemi e soprattutto per sfruttare i contributi della cosiddetta comunità virtuale72.

68 Così si esprime, provocatoriamente, MOGLEN, Anarchism triumphant: free software and the death of copyright, in First Monday, peer-reviewed journal on the internet IV 1999. Disponibile anche su http://moglen.law.columbia.edu/publications/anarchism-it.html 69 GNU (pronuncia “ghnu”) è l’acronimo, ricorsivo, di Gnu’s Not Unix; questi tipi di acronimi sono frequenti nel mondo hacker. 70 I contributi più numerosi giungono dal nordamerica; in Italia invece sono un numero piuttosto ristretto, e comunque analizzano la GPL e l’open source da un punto di vista generale. In particolare ZICCARDI, Open Source e libertà del codice, in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1067 ss. 71 BIN, La circolazione internazionale dei modelli contrattuali, in Contr. e impr., 1993, 475ss., il quale vede nelle imposizioni da parte delle grandi multinazionali la principale causa di questa prassi, soprattutto nell’ambito dei c.d. contratti informatici (p.479). 72 cfr. BRADNER, La IETS, Internet Engineering Task Force, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 49 ss. In particolare, sull’importanza del libero accesso ai codici sorgenti, 54 e 55, in cui si afferma che “è piuttosto chiaro che uno dei principali fattori del successo degli standard IETF è la politica di sviluppo di documenti e standard di libero accesso”.

MAURO SANTO

24

La tendenza attuale è quella di introdurre il software open source, dopo i server internet (come per esempio apache, il server internet più diffuso), tra i personal computer dei singoli consumatori, soprattutto offrendo loro sistemi operativi completi, sfruttando la quasi gratuità dei software.

Ecco allora che, in vista di una potenziale espansione di questo modello di software, risulta importante capirne le modalità di distribuzione, i divieti e soprattutto gli eventuali problemi ad esso correlati; ma prima è utile accennare alla storia del progetto GNU, soprattutto per rendersi conto di come esso non sia affatto un evento improvviso ed estraneo nel mondo dell’informatica, ma di come invece sia un evento, se non pienamente prevedibile, quantomeno comprensibile.

2. Codice sorgente e codice oggetto sono due nozioni di cui è opportuno approfondire il significato, a causa soprattutto dell’importanza del primo all’interno della GPL ma soprattutto nel più ampio movimento open source. Sebbene tecnicamente codice sorgente e codice oggetto siano semplicemente due diversi modi di rappresentare un software, essi differiscono fra loro in diversi aspetti fondamentali73.

I computer (o calcolatori, macchine in grado di eseguire in modo automatico sequenze di operazioni logiche ed aritmetiche) sono costruiti in modo da comprendere solo le istruzioni usate direttamente dalla CPU (l’unità centrale di elaborazione, in pratica il nucleo di un computer) in base alla quale essi funzionano; l’insieme delle regole di queste istruzioni è detto linguaggio macchina.

La prima grande differenza tra codice sorgente e codice oggetto è che questo è direttamente eseguibile dalla macchina; poiché, come abbiamo visto, queste ultime capiscono solo il linguaggio macchina supportato dalla CPU, il codice oggetto deve corrispondere con il linguaggio macchina del computer su cui si intende eseguirlo.

Viceversa il codice sorgente non è direttamente eseguibile, ma deve essere tradotto in codice oggetto prima di poter essere eseguito.

La traduzione da codice sorgente a codice oggetto è chiamata compilazione, ed avviene tramite una funzione che è di solito effettuata da appositi software chiamati, appunto, compilatori. A differenza delle traduzioni da un linguaggio umano in un altro, la compilazione del codice sorgente in codice oggetto è un processo a senso unico. In altre parole, una volta che una parte di codice sorgente è stata tradotta in codice oggetto, è impossibile ritradurla nell’originale codice sorgente. Il motivo principale di ciò è che quando i compilatori traducono un codice sorgente in codice oggetto, essi non sostituiscono semplicemente i termini di un linguaggio con quelli di un altro, ma effettuano anche una serie di ottimizzazioni al fine di migliorare la velocità del programma e la sua utilizzazione delle risorse hardware.

Come implicito effetto collaterale di queste ottimizzazioni, vi è dunque quello consistente nella perdita di tutte le informazioni sulla struttura del codice sorgente, i nomi che i programmatori avevano dato ai moduli ed alle strutture di dati di cui è costituito il software, nonché la precisa sequenza delle informazioni usate.

Quindi, è praticamente impossibile ricreare l’originale codice sorgente di un programma partendo dal suo codice oggetto. Le imprese produttrici di software offrono dei programmi decompilatori, che provano ad effettuare il reverse engineering di un codice oggetto, ovvero risalire da quest’ultimo al codice sorgente (questa pratica è detta decompilazione); ma di solito i decompilatori generano un codice sorgente che differisce dall’originale, sebbene quando re-compilato esso porti ad un codice oggetto che è funzionalmente equivalente a quello originale.

Per i programmatori di software è impossibile scrivere un programma direttamente in codice oggetto; occorre invece scrivere prima il codice sorgente del programma di cui poi, tramite il programma compilatore, si genererà il corrispondente codice oggetto: a tal fine vengono usati degli appositi linguaggi (insieme di regole sintattiche) di programmazione.

Infatti, a causa dell’attuale stato della tecnologia, tutti i linguaggi macchina sono binari, e quindi le loro istruzioni consistono solo in una sequenza di numeri zero (0) e uno (I). Questa caratteristica rende estremamente difficile per l’essere umano leggere e scrivere un codice oggetto; è per questa ragione che la creazione manuale del codice oggetto sarebbe non solo oltremodo gravosa, ma necessiterebbe di molto tempo e sarebbe propensa a numerosi errori.

In confronto, creare un codice sorgente è molto meno problematico. A differenza del codice oggetto, il codice sorgente può essere ideato sulla base di qualsiasi linguaggio di programmazione per il quale esista un compilatore in grado di tradurre in codice oggetto un codice sorgente scritto in un determinato

73 Per tutti i riferimenti di questo paragrafo su codice sorgente e codice oggetto v. AUSIELLO, I compilatori e la traduzione dei linguaggi di programmazione, in C IOFFI e FALZONE, Manuale di informatica , Calderini, Bologna, 1986, 643 ss.

MAURO SANTO

25

linguaggio. Questi linguaggi sono di solito chiamati linguaggi di alto livello (per distinguerli dai linguaggi macchina di basso livello). Nel tempo sono stati sviluppati un vasto numero di linguaggi ad alto livello (insieme ai rispettivi compilatori), alcuni dei quali sono divenuti anche abbastanza comuni. Esempi ne sono i linguaggi C, Pascal e Basic. La caratteristica comune di tutti questi linguaggi è che essi sono costituiti da parole e regole sintattiche modulate sulla base della lingua inglese, associate a diffusi simboli matematici.

Un linguaggio di programmazione ad alto livello (HLL, High Level Language) è un linguaggio che permette di scrivere programmi senza conoscere il calcolatore su cui i programmi stessi verranno eseguiti; un programma scritto in un linguaggio ad alto livello descrive un algoritmo mediante una sequenza di proposizioni (o istruzioni, o frasi, o enunciati) costruite secondo le regole del linguaggio usato74. Si tenga presente che la conoscenza di un linguaggio non è sufficiente per scrivere dei programmi – attività che presuppone la capacità di creare un algoritmo – né a garantire un completo sfruttamento delle risorse della macchina, sfruttamento per cui è necessaria una buona padronanza del sistema operativo del calcolatore e – in particolare – del suo linguaggio di controllo.

Riassumendo, queste caratteristiche permettono la rappresentazione anche di complessi algoritmi e strutture di dati in un modo che è comprensibile dalla mente umana, rendendo non solo relativamente facile per le persone imparare i linguaggi di alto livello, ma rendendo altresì i programmatori che si servono di questi linguaggi, capaci di offrire nuovi software più velocemente che se dovessero avere a che fare solo con il linguaggio macchina.

Quindi, a causa della grande versatilità del codice sorgente, è molto più facile per i programmatori creare il codice sorgente piuttosto che scrivere il codice oggetto, ed inoltre, il fatto di utilizzare linguaggi di alto livello premette, se è disponibile il codice sorgente, la manutenzione e l’aggiornamento dei software.

In sintesi, codice sorgente e codice oggetto differiscono fra loro in tre aspetti. Primo, mentre il codice sorgente è comprensibile dall’uomo, non lo è il codice oggetto. Secondo, a differenza del codice sorgente, il codice oggetto è direttamente eseguibile sul computer. Terzo, è impossibile ricreare l’esatto codice sorgente sulla base del suo codice oggetto.

Le diverse caratteristiche del codice sorgente e del codice oggetto creano un forte incentivo per i produttori di software ad offrire ai consumatori solo il codice oggetto dei loro programmi mantenendo segreto il codice sorgente: infatti, come detto sopra, il codice oggetto è tutto ciò di cui necessita un utente per riprodurre un software sul proprio computer; ecco perché di solito le licenze d’uso di software prodotti su larga scala escludono dalle loro previsioni il codice sorgente; quest’ultimo invece è talvolta accessibile nei casi di software sviluppati sulle specifiche esigenze di un determinato soggetto.

Quindi tutto il valore commerciale di un software è racchiuso nel suo codice oggetto; ciò, insieme al fatto che il codice sorgente contiene rilevanti segreti commerciali utilissimi per gli eventuali concorrenti, ha costituito un forte disincentivo alla distribuzione del codice sorgente da parte delle imprese produttrici di software.

Talvolta la giurisprudenza si è soffermata sul codice oggetto e sul codice sorgente, affermando che non v’è alcun dubbio che il solo codice oggetto, sebbene non intelligibile dall’uomo, possa godere delle tutele previste dal diritto d’autore75; per quanto riguarda il codice sorgente né è stata invece evidenziata l’autonomia dal rispettivo codice oggetto, in modo tale che esso possa essere protetto separatamente: in particolare, si è affermato che il contratto di licenza di software esecutivo (cioè nella sola forma del codice oggetto), non si estende al relativo codice sorgente, in difetto di specifica pattuizione delle parti76. Ciò consente di cedere eventualmente a soggetti diversi il codice sorgente di un software ed il rispettivo codice oggetto.

74 Sulle loro caratteristiche FALZONE, I linguaggi di programmazione, in CIOFFI e FALZONE, Manuale di informatica , Calderini, Bologna, 1986, 367 ss. 75 Pret. Bari, ord. 11 febbraio 1991, in AIDA 1992, 33: “il software presenta il requisito di protezione dell’opera dell’ingegno……nonostante le sue istruzioni siano indirizzate ad una macchina”. 76 Trib. Roma, 31 gennaio 2000, nel Repertorio di AIDA 2000, 1033.

MAURO SANTO

26

CAPITOLO IV ORIGINE ED EVOLUZIONE DEL PROGETTO GNU

SOMMARIO: 1. Prima di GNU: il sistema operativo UNIX. – 2. La nascita del progetto GNU e la GPL. – 3 La OSI, Open Source Iniziative. – 4. Free software ed open source. – 5. Situazione attuale e prospettive future. 1. In origine il termine software veniva usato per identificare quelle parti di un sistema di calcolo che

fossero modificabili liberamente tramite differenti configurazioni di cavi e spinotti, diversamente dall’hardware, con cui si identificava la componentistica elettronica. Successivamente all’introduzione di mezzi linguistici atti ad alterare il comportamento dei computer, software prese il significato di espressione in linguaggio convenzionale che descrive e controlla il comportamento della macchina. In particolare occorre notare che ogni macchina aveva un suo proprio linguaggio convenzionale, comunemente detto assembler77.

Nella relativamente breve storia della information technology, tutte le società produttrici di hardware hanno cominciato a fornire, assieme all’hardware della macchina un certo numero di programmi in grado di svolgere le funzioni di base. Inizialmente si parlava di Monitor, poi di Supervisori, infine è stato adottato il nome di Sistema Operativo (OS)78. Tali programmi erano scritti sempre in assembler, cioè nel linguaggio specifico della singola macchina.

Una eccezione a tale regola è stata il sistema operativo UNIX79 (Uniprogrammed Computer System), realizzato da una organizzazione che non produceva hardware, e precisamente i laboratori Bell, e che pertanto fu progettato fin dall’inizio per risultare indipendente dalla specifica piattaforma hardware su cui era stato inizialmente scritto. Non solo: i progettisti iniziali dello UNIX proprio per renderlo indipendente dalla piattaforma hardware, svilupparono un linguaggio, conosciuto come linguaggio C, che conteneva costrutti della programmazione di alto livello. Un’altra peculiarità è che, avendo allora (anni’70) la Bell una causa in corso per violazione della legge statunitense sui monopoli, UNIX veniva inizialmente distribuito corredato dei sorgenti. Questo permise ad altri di portare il sistema UNIX stesso su piattaforme diverse da quelle usate dai laboratori Bell e ne causò una rapidissima diffusione fra le comunità dei ricercatori e degli sviluppatori. Non solo: la disponibilità dei sorgenti permetteva a chiunque di contribuire al miglioramento ed all’espansione delle funzioni del sistema operativo. In pratica si formò una comunità di sviluppatori volontari, in genere dell’ambiente universitario (ma non solo) che contribuì, in un modo che potremmo definire collaborativo, alla crescita di UNIX.

Nel 1984 la Bell perse la causa e la proprietà dei laboratori UNIX passò alla AT&T, che iniziò a rivendicarne i diritti, cioè cominciò a chiedere delle royalty, ma soprattutto mise un freno alla distribuzione dei sorgenti. Ne seguì una battaglia per i diritti di proprietà dello UNIX che durò una decina d’anni. Successivamente nacquero molteplici sistemi operativi proprietari basati sul sistema UNIX (AIX, Digital UNIX, HP-UX, Sinix ecc…)80.

La principale conseguenza della scomparsa della Bell e della trasformazione di UNIX in tanti sistemi proprietari fu che la comunità di programmatori, formatasi spontaneamente in quegli anni, si trovò impossibilitata a continuare a lavorare.

2. Fu avvertita allora la necessità di un modello di sviluppo simile a quello di UNIX anni’70; questa

esigenza fu sentita in particolar modo da Richard Stallman, il quale durante la metà degli anni’80 diede vita

77 v. CIOFFI, Gli assemblatori, in CIOFFI e FALZONE, Manuale di informatica, Calderini, Bologna, 1986, 306 ss. 78 v. BOVET, I sistemi operativi, in CIOFFI e FALZONE, Manuale di informatica , Calderini, Bologna, 1986, 577 ss. 79 Una chiara ed esaustiva illustrazione dell’evoluzione di UNIX è in http://minnie.cs.adfa.oz.au/TUHS/Mirror/Hauben/unix.html 80 Su questo passaggio v. la testimonianza di MCKUSICK, Vent’anni di Unix a Berkeley: dalla AT&T alla ridistribuzone gratuita, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 31 ss.

MAURO SANTO

27

al progetto GNU, acronimo (tautologico) di Gnu’s Not Unix, ovvero GNU non è UNIX; ed il senso di questa definizione appare chiaro se si ripensa a quanto detto sopra, ossia alle vicende cui andò incontro dal 1984 in poi il sistema UNIX: in breve, il ridimensionamento della distribuzione dei sorgenti. Il progetto GNU fu sviluppato durante la metà degli anni ’80 da Stallman, pensato inizialmente come nuovo sistema operativo Unix-like, con la fondamentale differenza di rendere disponibile il codice sorgente e di garantire agli utenti la possibilità di modificarlo; con lo sviluppo di questo progetto si rese necessaria la costituzione della Free Software Foundation, un’associazione con il compito di gestire lo sviluppo e la distribuzione del sistema GNU81.

Fu proprio quando il sistema GNU divenne completo, con l’introduzione del kernel Linux82, che si avvertì la necessità di costituire un documento legale che precisasse le condizioni ed i diritti connessi con la distribuzione del sistema GNU/Linux; condizioni e diritti più volte espressi e ribaditi con forza dallo stesso Stallman, ma che ormai, in vista di una più ampia diffusione, fossero resi non solo certi e chiari, ma anche binding, ovvero legalmente vincolanti.

Fu allora che venne formulata la GNU General Public License (GPL), licenza software in cui sono condensati i principi di quello che Stallman stesso definì Free software, riferendosi alla libertà garantita agli utenti più che alle condizioni economiche di distribuzione del software83. Accanto alla GPL nacque anche la Library General Public License (LGPL, dal 1998 acronimo di Lesser General Public License), licenza pensata apposta per le librerie84.

A questo punto è forse più agevole intendere i significati che si celano dietro i due acronimi oggetto di questo lavoro: GNU identifica un progetto inizialmente pensato per sviluppare un nuovo sistema operativo, ma che poi, con il passare del tempo, si è trasformato in un progetto volto alla diffusione ed allo sviluppo del software libero, senza peraltro rinunciare alla costruzione di un sistema operativo, che si realizza con l’incontro col kernel Linux; all’interno del progetto GNU sorge la GPL, che identifica invece un particolare modello di distribuzione del software.

Data l’ampia diffusione di Linux85, prodotto cui essa è strettamente vincolata, ed a causa inoltre della piena corrispondenza tra il suo contenuto e le scelte “ideologiche” che sono alla base del progetto GNU, la GPL è considerata oggi come lo stereotipo delle licenze open source, se non la licenza open source per antonomasia. Non si pensi però che sia con le licenze pubbliche GNU che sorge questo modo di distribuire il software, né la prassi di distribuire il codice sorgente. In realtà già altre licenze precedenti alla nascita del progetto GNU prevedevano e tuttora prevedono tali possibilità; la minor diffusione è forse paradossalmente dovuta alla maggior libertà che esse consentono, e cioè la possibilità di inserire il codice sorgente in un software proprietario: si tratta per esempio delle licenze BSD (Berkeley software distribution) e MIT86,

81 Sulle origini del progetto GNU v. STALLMAN, Il progetto GNU, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 57 ss. Molto utile nonché esauriente è anche la ricostruzione fornita da AMADORI, BAZZIGALUPPI, BERNOCCHI e GATTI, Sistemi operativi open source: il caso Linux, in Mondo Digitale I 2002, 47 ss. 82 Ciò che fece Torvalds, l’autore di Linux, fu di adattare uno strumento didattico ad usi reali. Il kernel Minix di Tanenbaum era un punto fermo nei corsi sui sistemi operativi, poiché forniva un esempio di come dare soluzioni semplici a problemi di base. Lentamente, e, inizialmente senza riconoscerlo, Torvalds cominciò a trasformare il kernel Minix in un vero e proprio kernel Unix per processori Intel x86, il motore dei comuni PC di tutto il mondo. Mentre Torvalds cominciava a sviluppare questo kernel, che chiamò Linux, egli capì che il modo migliore per far funzionare il suo progetto era quello di orientare le sue decisioni tecniche in modo da rendere compatibile col suo kernel gli strumenti GNU già esistenti. TORVALDS, Il vantaggio di Linux, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 111 ss. 83 v. STALLMAN, Il progetto GNU, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 63. Egli critica tralaltro gli autori di un software (l’X Window System sviluppato al MIT), considerando che “non erano interessati che gli utenti fossero liberi, ma solo che fossero numerosi”. 84 Per libreria si intende un file (dll – dinamic link library) che contiene delle funzioni utilizzabili da uno o più software. Cfr. AUSIELLO, I compilatori e la traduzione dei linguaggi di programmazione, in C IOFFI e FALZONE, Manuale di informatica , Calderini, Bologna, 1986, 672-675 ss. 85 Per avere una sufficiente idea di quanto sia attualmente diffuso questo sistemo operativo http://www.linuxjournal.com/webindex.php. 86 Queste due licenze permettono per esempio di incorporare un programma licenziato in base ad esse in un software proprietario: per una loro analisi ed un confronto con la GPL v. ROSENBERG, The open source software licensing page, su http://www.stromian.com

MAURO SANTO

28

molto diffuse in ambito accademico; oggi invece le licenze certificate come open source sono quasi quaranta87.

3. Consapevoli dell’importanza del codice sorgente per molti soggetti, nonché del loro interesse ad

adattare programmi per computer alle proprie esigenze, ma consapevoli altresì della inadeguatezza per altri della GPL a causa della sua immutabilità, alcune persone hanno creato la OSI, Open Source Initiative, stilando dei criteri il cui rispetto è essenziale affinché le condizioni di una licenza possano qualificarsi open source; questi criteri sono meno rigidi di quelli della GPL, proprio per garantire coloro che non hanno intenzione di distribuire le modifiche al software, ma sono interessati a conoscerne il codice sorgente; i criteri della OSI sono dieci, e vanno dalla necessità di garantire la disponibilità del sorgente al divieto di discriminare persone o gruppi durante la distribuzione del software88. In particolare, per essere open source una licenza deve garantire la ridistribuzione libera e la disponibilità del codice sorgente; ma soprattutto deve consentire modifiche ed opere derivate, consentendo la loro distribuzione sotto i medesimi termini della licenza del software originale. Quindi una licenza, pur essendo open source, può garantire a tutti il diritto di incorporare il software in un altro che sia proprietario; azione invece assolutamente vietata (come vedremo) dalla GPL.

Vi è un’apposita procedura (consistente nella trasmissione della licenza e nella sua discussione in appositi forum) al termine della quale si può ottenere la certificazione OSI, la quale garantisce che una licenza è conforme ai dettami dell’open source initiative89.

4. Prima di analizzare i singoli paragrafi della GPL è meglio chiarire i significati di alcuni termini che

spesso sono usati per indicare in generale tutto ciò che è connesso con il software licenziato secondo la GPL; quest’ultimo infatti talvolta è denominato free o libero, talvolta open source in contrapposizione al software proprietario. Quest’ultima categoria può essere identificata in negativo, ovvero tutti i software non licenziati sotto GPL che non siano nemmeno open source sono detti proprietari: quindi non si intende qualcosa gravato da diritti d’autore in contrapposizione per esempio, ai software public domain, i cui autori hanno rinunciato ai propri diritti, bensì indica tutto quello che non è free ed open source; questi due termini a loro volta non hanno un significato coincidente, sebbene molto spesso siano usati come sinonimi; infatti open source include ma non si esaurisce in free: questa parola si riferisce solo ai software che rispettino le c.d. quattro libertà (libertà di eseguire, copiare, distribuire e modificare il software) strettamente connesse alla disponibilità del codice sorgente ed alla esigenza che nessuno possa successivamente restringere tali libertà; tipicamente un software free (o libero) è un software licenziato sotto GPL, licenza che appunto garantisce le libertà anzidette; nulla vieta che un software licenziato in base ad una licenza diversa sia anch’esso free, purché come detto rispetti le condizioni delle quattro libertà; open source invece vuol dire sorgente aperto, ed indica tutti quei software il cui codice sorgente è disponibile, ma la cui licenza può

87 Nel marzo 2002 erano 23, mentre quasi un anno dopo sono 38: Academic Free License, Apache Software License, Apple Public Source License, Artistic license, Attribution Assurance Licenses, BSD License , Common Public License, Eiffel Forum License, GNU General Public License (GPL), GNU Library or "Lesser" General Public License (LGPL), IBM Public License, Intel Open Source License, Jabber Open Source License, MIT License, MITRE Coll, Nethack General Paborative Virtual Workspace License (CVW License), Motosoto License, Mozilla Public License 1.0 (MPL), Mozilla Public License 1.1 (MPL), Nokia Open Source License, OCLC Research Public License 1.0, Open Group Test Suite License, Open Software License, Python license (CNRI Python License), Python Software Foundation License, Qt Public License (QPL), Ricoh Source Code Public License, Sleepycat License, Sun Industry Standards Source License (SISSL), Sun Public License, Sybase Open Watcom Public License 1.0, University of Illinois/NCSA Open Source License, Vovida Software License v. 1.0, W3C License, wxWindows Library License, X.Net License, Zope Public License, zlib/libpng license. Tutte disponibili su http://www.opensource.org. Per verificarne le caratteristiche e stabilirne la compatibilità con la GPL v. http://gnu.chg.ru/licenses/license-list.it.html 88 Cfr. PERENS, La Open Source Definition, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 185 ss. 89 Per la descrizione di questa procedura PERRI, I sistemi di licenza open source, in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1088 ss; merita un cenno, all’interno di questa procedura, la fase in cui il testo soggetto alla valutazione di conformità ai principi open source resta a disposizione dei terzi per un breve periodo durante il quale chiunque può esprimere le proprie obiezioni.

MAURO SANTO

29

comunque contenere qualche elemento contrario alle quattro libertà. A sua volta, la stessa locuzione open source ha una bipartizione di significato: in un primo caso si riferisce ad un software che rispetta i criteri stabiliti dalla OSI, in un secondo caso il termine è invece generico, ed indica la mera disponibilità del codice sorgente; in tal caso potrebbe essere open source anche un software Microsoft licenziato secondo la shared source license90. Proprio a causa del rischio di riferirsi in modo non sempre univoco a determinate situazioni, è opportuno tenere distinti le varie locuzioni ed i loro significati, soprattutto nei testi legislativi. Da questo punto di visto appare condivisibile la scelta dei recenti disegni di legge che si preoccupano di dare una definizione di software libero, coerente col significato che si è esposto prima91. Sarà allora utile definire sempre anticipatamente cosa si intende per software libero o open source, per evitare confusione.

Tornando al software libero, è la traduzione dell’inglese free software; l’ambivalenza della parola free in inglese ha creato perplessità, poiché significa anche gratis: ma come dice il preambolo della GPL e come più volte lo stesso Stallman ha sottolineato, nel progetto del software libero non ha alcuna rilevanza l’elemento economico: esso non è affatto preso in considerazione e quindi ciascuno può comportarsi in piena autonomia; né la GPL né la FSF sono contrarie a che un autore richieda un compenso per mettere a disposizione di terzi il software creato (quello che è impropriamente chiamato il prezzo del software): l’importante è che ciò avvenga secondo precise modalità. Nel preambolo della GPL si può infatti leggere che quando si parla di free software, ci si riferisce alla libertà (di programmare), non al prezzo. Proprio Stallman ha evidenziato questo concetto, distinguendo tra free speech – libertà di parola – e free beer – birra gratis – , affermando che è la prima accezione della parola free quella che conta nel free software92. Scorrendo poi il testo della GPL non vi è alcun dato da cui si possa ricavare il divieto di commercializzazione del software; insomma, il progetto GNU, il concetto di open source, la GPL e la FSF, nulla è contro l’attuale sistema economico di diffusione dei software.

Molti hanno però evidenziato i bassi costi dei software liberi rispetto ai diretti concorrenti proprietari, e per molti proprio questa è la grande peculiarità ed il vero punto di forza: in realtà, proprio perché la questione del prezzo non ha alcuna rilevanza nel concetto di free software (non essendo affatto contraddittorio chiedere del denaro come corrispettivo per la propria attività creativa), è stata l’assoluta libertà di copiare e distribuire il software libero che ha causato una situazione nella quale, essendoci un’offerta molto ampia e varia, i costi per ottenere una copia di un software libero sono minimi (se non nulli), il più delle volte pari ai costi di distribuzione93.

Già questa premessa ci fa allora intuire quanto sarà più chiaro in seguito, ossia che sebbene decisamente innovativo e diverso, il copyleft94 e la GPL non sono affatto un’isola anarchica nel mare del copyright. Anzi.

90 La Shared source license è una nuova licenza creata dalla microsoft, che permette di osservare il codice sorgente, ma non permette affatto di modificarlo; v. http://www.microsoft.com/windows/embedded/ce.net/previous/ downloads/source/license.asp 91 In particolare durante questa legislatura (XIV) è stato presentato al Senato il Ddl 1188 26/II/2002 intitolato: “Norme in materia di pluralismo informatico e sulla adozione e diffusione del software libero nella pubblica amministrazione”: http://www.senato.it /leg/14/Bgt/Schede/Ddliter/16976.htm; alla Camera è stato presentato invece il Pdl 2544 20/III/2002 intitolato: “Norme in materia di pluralismo informatico e di incentivazione della diffusione del software libero”: http://www.camera.it/_dati/leg14/lavori/stampati/sk3000/ articola/2544.htm. Ecco le definizioni (identiche) in essi contenute: “a) licenza di software libero: una licenza di diritto di utilizzo di un programma per elaboratore elettronico, che renda possibile all'utente, oltre all'uso del programma medesimo, la possibilità di accedere al codice sorgente completo e il diritto di studiare le sue funzionalità; il diritto di diffondere copie del programma e del codice sorgente; il diritto di apportare modifiche al codice sorgente; il diritto di distribuire pubblicamente il programma ed il codice sorgente modificato;b) software libero: ogni programma per elaboratore elettronico distribuito con una licenza di software libero; c) programma per elaboratore a codice sorgente aperto: ogni programma per elaboratore elettronico il cui codice sorgente completo sia disponibile all'utente, indipendentemente dalla sua licenza di utilizzo; d) software proprietario: un programma per elaboratore, rilasciato con licenza d'uso che non soddisfi i requisiti di cui alla lettera a)”. 92 v. STALLMAN, Il progetto GNU, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 61; nonché il preambolo della GPL: “when we speak of free software, we’re referring to freedom, not price”. 93 Cfr. FLAMING, Linux: the new, free kid on the block, in Illinois Bar Journ. 1999, 107 ss., il quale descrive in prima persona l’esperienza di chi si avvicina al mondo dell’open source e dei vantaggi che ne trae. 94 Copyleft è il gioco di parole che indica ormai il sistema creato dalla GPL; si contrappone a copyright, ed è la sintesi delle parole copyright e left, participio passato del verbo to leave, lasciare, permettere; non ha – fortunatamente – alcuna implicazione politica. Talvolta capita di leggere su software licenziati sotto GPL: © copyleft, all right reversed.

MAURO SANTO

30

5. La situazione attuale si presenta alquanto favorevole all’ulteriore diffusione del software open

source; pur esistendo da più di dieci anni, è solo infatti nell’ultimo biennio che si è imposto all’attenzione dei mass media ed ha trovato una relativamente ampia diffusione anche tra gli utenti non “addetti ai lavori”; i dati sulla crescita e sulla quota di mercato sono lusinghieri95, e ciò ha attirato verso il software open source l’attenzione di vari economisti; sono infatti molto più diffusi gli studi di carattere economico che non quelli di carattere giuridico; ci si interroga soprattutto sulle cause e sulle prospettive di un business, quale appunto quello del software open source, che non si sviluppa secondo i tradizionali metodi usati dalle imprese in sistemi di libero mercato; incuriosisce soprattutto il fatto che spesso i programmatori non sono retribuiti, anzi il loro contributo è del tutto spontaneo; comunque, gli spunti economici sono numerosi e non possono essere approfonditi qui96.

L’importanza del software open source cresce però soprattutto se si guarda al futuro: sono sempre più numerose infatti le proposte normative finalizzate a favorire la diffusione del software libero e ad una sua introduzione all’interno della pubblica amministrazione97; si va dal ddl alla camera, alle mozioni del parlamento europeo, fino alle mozioni di vari consigli comunali (Lodi e Firenze) provinciali (Pescara) nonché regionali (Toscana)98; si è anche proceduto all’istituzione di un’apposita commissione ministeriale99. Proposte sono state fatte in Francia, Spagna, Cina, Gran Bretagna, India, Russia, Pakistan, Taiwan e gran parte del Sudamerica100; in Perù si è addirittura assistito ad un vivace scambio epistolare tra un deputato, fautore dell’introduzione presso la p.a. e la diffusione del software open source, e la Microsoft101. La Germania rimane il paese più avanzato da questo punto di vista: le sue forze armate infatti si servono già esclusivamente di protocolli software open source e tutta l’amministrazione federale è in procinto di sostituire i vecchi software proprietari102. In Italia, inoltre, l’AICA ha disposto che i test per la ECDL (european computer driving license), prima limitati solo a software Microsoft, possano avvenire anche su moduli comprendenti software open source103. Riferendosi alla p.a., sono stati presi in considerazione gli artt. 96-97 cost. che dettano per la pubblica amministrazione criteri di efficienza ed

95 Per i dati e le statistiche riguardanti la diffusione dei vari software open source v. WHEELER, Why open source software/free software? Look at numbers!, in http://www.dwheeler.com/oss_fs_why..html. Si può notare, per esempio, che i software liberi sono i più diffusi tra i server web (Apache in particolare). Niente male per un progetto (GNU) che, nel 1993, venne definito “visionario”: cfr. GARFINKLE, Stallman è in stallo?, in SCELSI, No copyright, nuovi diritti nel 2000, Shake, Milano, 1994, 154. 96 Per un’analisi del fenomeno open source da un punto di vista costi/benefici POTTER, Opening up to open source, in Richmond Journ .Law & Tech. 2000, 24 ss. Un’altra ottima analisi economica è fornita da MAHER, Open source: the success of an alternative intellectual property incentive paradigm, in Fordham Intell.Prop.,Media & Entert. L.Jour. 2000, 620 ss. Per l’esperienza diretta di un imprenditore YOUNG, Regalato! Come Red Hat Software si trovò fra le mani un nuovo modello economico e contribuì a migliorare un’industria, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 123 ss. Un altro noto saggio sul modello economico di sviluppo dell’open source è quello di RAYMOND, La cattedrale ed il bazaar, 1998, http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html; la traduzione italiana è disponibile all’URL http://www.apogeonline.com/openpress/doc/cathedral.html; qui i due modelli di sviluppo (proprietario e open source) sono curiosamente paragonati ai metodi di costruzione di una cattedrale da un lato e di un bazaar dall’altro: a sottolineare che il primo è diretto dall’alto, il secondo è invece governato dalle esigenze di chi ne fruisce. 97 cfr. OROFINO, Open source e pubblica amministrazione, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1317, il quale analizza tutte le ragioni (in particolare l’esigenza di standardizzazione legata al principio di buon andamento della p.a.) che, in base al diritto amministrativo, suggeriscono l’adozione del software open source. 98 Per tutte queste notizie v. http://www.softwarelibero.it/news/html. 99 Denominata per l’appunto “Commissione per il software a codice sorgente aperto nella Pubblica Amministrazione”; il decreto istitutivo è disponibile in http://www.mininnovazione.it/ita/comunicati/2002_11_08.shtml; in Francia esiste già l’Agence du logiciel libre: v. OROFINO, Open source e pubblica amministrazione, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1327. 100 Queste varie proposte nonché il loro aggiornamento sono consultabili in dettaglio in http://www.linuxvalley.com/news/news.php 101 Il testo delle missive in http://www.fsfeurope.org/law/law.en.html 102 v. http://www.bundestux.de/ 103 AICA, circolare 1/2003; www.aicanet.it.

MAURO SANTO

31

imparzialità; coloro che hanno proposto i disegni di legge ritengono che il software open source rispetti questi criteri meglio del software proprietario: i costi delle licenze sono infatti alquanto bassi (se non nulli) ed inoltre si punta molto sulla disponibilità del codice, che garantirebbe maggior autonomia, e dunque imparzialità, di quanto non facciano i software proprietari; in Germania per esempio la prima esigenza è stata molto considerata; l’impossibilità di avere sotto controllo l’intero codice sorgente, e quindi di poter controllare l’intera gestione e tutte le funzionalità del software, è stata determinante per il passaggio delle forze armate da software proprietari a software open source, soprattutto perché, in un settore cruciale quale quello militare, si voleva evitare di affidarsi ad imprese straniere (nel caso specifico Microsoft). L’imparzialità viene inoltre in gioco per poter garantire a tutti i cittadini, indipendentemente dal sistema operativo da essi usato, di potersi interconnettere con la p.a., usare gli stessi formati dei files, e non vedersi penalizzati a causa dei software da loro adottati (soprattutto in vista di una sempre maggiore informatizzazione della p.a.); si sa infatti che, usualmente, un certo formato di file necessita di un determinato software, non essendo possibile riprodurlo su altro software; con il software open source tale anomalia sarebbe facilmente superabile (modificando opportunamente il codice sorgente e creando nuovi formati), in modo tale da non operare discriminazioni tra i cittadini.

Si può concludere dunque, da queste necessariamente sommarie informazioni, che per il futuro è lecito attendersi un ulteriore sviluppo del software open source104, ed aumenterà quindi la necessità di approfondire e di capire quali siano realmente le sue implicazioni e le modalità della sua circolazione e del suo funzionamento.

Tutto ciò indipendentemente dalla concreta direzione in cui andrà il mondo dei software; è infatti verosimile che l’attuale modello di distribuzione del software (ossia la licenza per un software contenuto su supporto mobile) sarà gradualmente sostituito dal modello c.d. del web services: l’utente cioè usufruirà di un determinato software che sarà reso disponibile in rete, non però scaricandolo, come può avvenire anche attualmente, ma semplicemente usandolo per le finalità e per il tempo ad egli necessari; la concretizzazione insomma della c.d. pay for use society105.

104 Se ne è accorta anche Microsoft: v. i c.d. Halloween papers, comunicazioni interne e riservate che invece sono divenute di dominio pubblico, in cui si esprime “attenzione” verso il software libero; http://www.opensource.org/ halloween/halloween1.php; un esempio pratico di alcuni vantaggi del software libero rispetto ai sistemi proprietari lo si può trovare in FERRIS, Fixing security holes on Internet time, 1999, http://linuxtoday.com/stories/6947.html/: si narra di un bug che aveva colpito sia Linux che Windows: nel primo caso fu risolto in qualche ora, mentre nel secondo ci vollero un paio di giorni. 105 Su questo tema in generale, ed in particolare sulla prospettiva futura di sostituire i software contenuti su supporti digitali con i web service cfr. ANDERSON, FRANCIS, HOMER, HOWARD, SUSSMAN e WATSON, Asp.Net, Hoepli, Milano, 2001, 939 ss.

MAURO SANTO

32

CAPITOLO V IL FUNZIONAMENTO DELLE LICENZE GNU

SOMMARIO: 1. Struttura della GPL. – 2. Le licenze pubbliche GNU e le licenze d’uso dei software. – 3. Il contenuto della GPL e la LGPL. – 4. L’essenza della GPL: i §§ 4,5,6. – 5. Il rapporto tra la GPL e gli artt. 1469 bis ss. cod.civ.. – 6. La GPL come nuovo paradigma di proprietà intellettuale. 1. La GPL contiene un preambolo, in cui in poche righe sono sintetizzati i principi fondamentali della

FSF nonché le cause che hanno portato alla sua stipulazione; è composta da dodici paragrafi106 più una postilla in cui viene spiegato all’utente il modo migliore per applicare la GPL a nuovi programmi.

Già da una lettura superficiale del testo della GPL ci si può accorgere di come sia in realtà opinabile la tesi di chi vede in questo tipo di licenza un modello al di fuori del diritto e che si basa su uno schema totalmente nuovo ed innovativo di fronte a cui il giurista non ha strumenti d’analisi107.

L’innovazione della GPL è infatti più nella sostanza che nella forma, poiché quest’ultima pare essere non molto diversa da quella delle altre licenze d’uso software. Essa si inserisce pienamente nell’attuale sistema di diritto d’autore, né d’altra parte i suoi autori dimostrano di avere velleità contrarie. Scorrendo il testo della GPL è piuttosto frequente infatti imbattersi in parole il cui significato rimanda direttamente a concetti giuridici basilari nel campo del diritto d’autore; innanzitutto il preambolo, ruota tutto intorno ai concetti di permesso, restrizione e divieto (permission, allowing, restrictions e forbid); si parla poi esplicitamente di garantire diritti, rights, e che per questo scopo il software è oggetto di copyright.

Il § 0 parla poi inequivocabilmente di copyright law, copyright holder e derivative work, ovvero legge sul diritto d’autore, diritti connessi ed opere derivate. Si prosegue nelle successive sezioni riferendosi a degli appropriati copyright notice e disclaimer of warranty, oppure citando le third parties; ed ancora concetti quali void, to remain in full compliance e terminate your rights sono fondamentali per la § 4, a sua volta essenziale all’interno della GPL; ricorrono più e più volte questi termini o loro varianti in tutta la GPL, ma quelle veramente significative paiono essere le actions…prohibited by law del § 5; bisogna ammettere che è strano leggere che qualcosa è proibito dal diritto in un testo che qualcuno considerava quasi anarchico, in totale contrapposizione con il sistema di esclusione e di divieti su cui si fonda il diritto d’autore.

Più verosimilmente le intenzioni degli autori della GPL erano (e sono) quelle sì di apportare novità nel campo della circolazione dei software, ma ben sapendo che lo strumento migliore e più efficace per il loro progetto era contenuto proprio nel diritto d’autore e nelle sue disposizioni. D’altronde è lo stesso Moglen, colui che potrebbe essere definito il consulente giuridico del progetto GNU, a confermare la centralità e l’importanza dell’attuale diritto sulla proprietà intellettuale per il successo del progetto open source, quando scrive che l’essenza del diritto d’autore è il potere di escludere, che implica altresì un uguale potere di permettere ciò che altrimenti sarebbe vietato108.

2. Le licenze pubbliche GNU sono giuridicamente qualificabili come licenze d’uso di software, ed al

pari di queste ultime pongono questioni sulle quali è bene soffermarsi prima di procedere oltre nell’analisi;

106 La versione ufficiale disponibile su www.gnu.org/copyleft/gpl.html ha una numerazione che va dal § 0 al § 12; altre versioni invece (non ufficiali) numerano i §§ da 1 a 13; in questo lavoro ci si riferisce alla versione ufficiale della FSF. 107 Come scrive per esempio HILL, Fragmenting the copyleft movement: the public will not prevail, in Utah L. Rev. 1999, 797 ss., sostenendo la netta contrapposizione tra sistema di copyright e copyleft. 108 MOGLEN, Enforcing the gpl, http://moglen.law.columbia.edu/ publications/lu-12.html, il quale afferma: “The essence of copyright law, like other systems of property rules, is the power to exclude. The copyright holder is legally empowered to exclude all others from copying, distributing, and making derivative works. This right to exclude implies an equally large power to license--that is, to grant permission to do what would otherwise be forbidden; licenses are not contracts: the work's user is obliged to remain within the bounds of the license not because she voluntarily promised, but because she doesn't have any right to act at all except as the license permits”.

MAURO SANTO

33

innanzitutto il termine licenza non ha la valenza tecnico-giuridica propria dell’ordinamento italiano; sebbene oggi nel linguaggio comune, grazie alla notevole diffusione del software, la locuzione licenza software evochi quel rapporto atipico in base a cui si cede il diritto di godimento del software, giuridicamente bisogna distinguere dalle licenze propriamente dette, ovvero gli accordi, esclusivi o non, di distribuzione o commercializzazione di una determinata res oggetto di proprietà industriale (soprattutto invenzioni brevettate)109.

Fatta questa breve premessa bisogna allora capire quale sia l’altro significato della locuzione licenza d’uso, che, dopo una vita più che ventennale ed il riconoscimento implicito nella direttiva 250/91/CEE e nel dlgs. 518/1992, sembra ormai aver assunto una valenza terminologica propria, di cui pare quindi vano tentare di dare una ridenominazione più coerente al suo contenuto.

Fin dalla sua iniziale diffusione negli anni ’80, la licenza d’uso del software, così come d’altronde il software stesso, ha suscitato un vivace dibattito dottrinale a fronte dell’assenza o della rarità di significative pronunce giurisprudenziali al riguardo, portando gli studiosi ad inserirla nella categoria, dai contenuti piuttosto vari ed ampi, dei c.d. contratti dell’informatica, sebbene l’oggetto di questi ultimi fosse assai vago110.

Riguardo la licenza d’uso del software111 si è da subito notata l’improprietà della definizione nonché l’atipicità del suo contenuto112; si era già evidenziato come il modello contrattuale delle licenze d’uso corrispondesse in realtà allo schema della locazione, poiché ad essere ceduto era il solo diritto di godimento del bene software113; qualche autore ammoniva addirittura di stare attenti, e di dare “alle figure giuridiche il loro giusto nome, diciamo locazione e non diciamo invece licenza, poiché la figura della licenza evoca altre cose”114; qualcun altro suggeriva di “sottrarsi al fascino dell’archetipo della vendita”115; si è poi cercato di inserire la licenza d’uso entro un preesistente modello giuridico, ed i due poli di attrazione sono stati quelli della locazione da una parte e della compravendita116 dall’altra117. Entrambi questi tipi legali però lasciavano perplessi, poiché qualunque fosse la scelta vi erano sempre elementi estranei se non addirittura incompatibili con una delle due fattispecie codicistiche; sono allora stati introdotti vari correttivi, e la definizione che pare più avvicinarsi alla licenza d’uso software è quella della locazione atipica; le opinioni in dottrina comunque non sono affatto pacifiche, poiché anche di recente vi è stato chi, con forza, si è opposto a questa visione a difesa della qualificazione come pura e semplice compravendita118; questa conclusione non pare però condivisibile, poiché la compravendita implicherebbe ex art. 1470 cod.civ. il trasferimento della proprietà del software, con conseguente diritto in capo al compratore di godere e disporre della cosa in modo pieno ed esclusivo, così come previsto dall’art. 832 cod.civ.; ma questa facoltà piena ed esclusiva di godimento e disposizione della cosa è manifestamente discordante con i diritti

109 Cfr. SANDRI, I contratti di licenza in Italia , in Riv. dir. ind. 1996, I, 43 ss. Anche CERINA, Contratti internazionali di informatica e legge applicabile, in Dir. Inf. 1994, 416 configura come licenza di software solo i casi in cui venga concesso anche il diritto di disporre e sfruttare economicamente il software. 110 In tal senso DE NOVA, L’oggetto del contratto, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 27; l’A. si esprimeva così: “…l’elemento unificante è assai labile…non vedo alcun momento comune sul piano della disciplina”. 111 Oggetto di queste considerazioni sono le licenze relative a software precostituiti, non invece quelle relative a software ancora da creare magari sulle specifiche esigenze dell’utente (contratti di sviluppo software). 112 cfr. MIRABELLI, Modelli, tipicità, collegamento, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 11. 113 In questo senso LEONE, La concessione del software tra licenza e locazione, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 349 ss.. 114 Così GALGANO, La cultura giuridica italiana di fronte ai problemi informatici, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 380. 115 Così DE NOVA, op.cit., 28. 116 A favore della qualificazione come vendita RISTUCCIA e ZENO ZENCOVICH, I programmi per elaboratore nella dottrina, nella giurisprudenza e nel dlgs. 518/92, CEDAM, Padova, 1992, 43; BIN, L’equilibrio sinallagmatico nei contratti informatici, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 65. 117 Vi è anche una tesi che potremmo definire intermedia, che distingue tra vendita e licenza a seconda della destinazione del software: se questo è destinato ad un utente finale si avrà vendita, se invece il software servirà come mezzo di affermazione concorrenziale per l’utilizzatore si avrà licenza. Cfr.: LEHMANN, The new software contract under european and german copyright law – Sale and licensing of computer programs, in IIC I 1994, 46-49. Sostiene questa tesi anche SARTI, Esaurimento ed utilizzazione del software, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 142-145. 118 Si esprime in tal senso MUSTI, Il contratto di ‘licenza d’uso’ del software, in Contr. e impr. 1998, 1289 ss.

MAURO SANTO

34

esclusivi dell’autore dell’opera software. Quindi, sebbene la tesi che qualifica come compravendita la licenza d’uso di software abbia il merito di evidenziare le anomalie119 che persistono nella qualificazione come locazione, essa crea però ancora più anomalie, soprattutto quando bisogna fare i conti con la disciplina dell’esaurimento120.

È invece condivisibile, avendo sempre chiara la qualificazione del software come opera dell’ingegno oggetto di proprietà intellettuale, lo schema secondo cui ciò che viene trasferito è il diritto alla singola riproduzione del software inteso come bene immateriale, ferma restando l’eventuale proprietà del mero supporto acquistato (floppy disk o cd-rom). Ogni altro diritto sul software resta invece in capo all’autore (il diritto, in particolare, di sfruttamento economico dell’opera software)121. Tesi, questa, condivisa anche dalle rare pronunce giurisprudenziali.122

Proprio questa visione è alla base dell’impostazione delle licenze software, molte delle quali ormai standardizzate. Tuttavia è opportuno sottolineare che, anche volendo accogliere questa tesi, le anomalie relative alle licenze dei software non sono affatto risolte: in particolare vi è un punto sul quale è piuttosto arduo inquadrare sistematicamente la situazione giuridica: si tratta della disciplina dell’esaurimento così come prevista dagli artt. 64 bis e ter l.a.; l’unica tesi che appare in grado di risolvere tale contrasto è quella che vede una licenza vera e propria qualora la cessione del software sia mezzo di affermazione concorrenziale, mentre si avrà una vendita qualora il software sia destinato ad utenti finali123.

Ad ogni modo, numerose limitazioni sono poste dalle licenze standardizzate al comportamento dell’utente, cui di solito è permesso riprodurre il programma ed a cui sono comunque garantiti i diritti di copia (di back up) e decompilazione previsti dagli artt. 64 bis e quater124.

Proprio per reagire alle limitazioni poste dalla maggior parte delle licenze software è nato il progetto GNU e la GPL (v. supra).

Ed è appunto quest’ultima che permette una visione del concetto di licenza software da un’altra angolazione; il dibattito sulle licenze software è stato infatti sicuramente influenzato dall’uniformità dei contenuti che prevedevano spesso clausole alquanto restrittive.

Al contrario la GPL, con le sue notevoli concessioni permette di capire meglio che il vero contenuto delle licenze software consiste nella cessione e nel godimento di diritti esclusivi dell’autore sul software. La peculiarità della GPL è allora nell’ampia cessione di diritti che essa conferisce agli utenti: dalla libera riproduzione alla modificazione, dalla copia alla distribuzione del software125 (i singoli diritti licenziati saranno esaminati dettagliatamente nel prossimo capitolo).

119 Sulle anomalie e sulla atipicità delle licenze software DAL POGGETTO, nota a Trib. Torino, ord. 30 ottobre 1997, in AIDA 1999, 599; evidenzia l’atipicità anche PLAIA, Un’improbabile ipotesi di “licenza” d’uso di software, in AIDA 2001, 782 ss. 120 Sul rapporto tra la disciplina dell’esaurimento ed il dlgs. 518/92 v. SARTI, Esaurimento ed utilizzazione del software, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 84 ss. 121 Questa tesi è sostenuta da FINOCCHIARO, I contratti ad oggetto informatico, CEDAM, Padova, 1993, 90-99; ID., I contratti di informatica, UTET, Torino, 1995, 1637-1645 in I contratti del commercio, dell’industria e del mercato finanziario diretto da Galgano. La stessa impostazione è fornita anche da ROSSELLO, I contratti dell’informatica nella nuova disciplina del software, Giuffrè, Milano, 1997, 64-68. Nello stesso senso CERINA, Contratti internazionali di informatica e legge applicabile, in Dir. Inf. 1994, 417, TOSI, Licenza d’uso e vendita di copia di software alla luce del dlgs. 518/92, in Arch. Civ. 1994, 685 ss., e CHERPILLOD, Contrats de licence de software, in AA.VV., Le logiciels et le droit, Cedidac, Lausanne, 1986, 177 ss. 122 Trib. Bari, 1 giugno 1994, in Dir. Inf. 1995, 927 e Pret. Monza, 27 settembre 1989, in ROSSELLO, I contratti dell’informatica nella nuova disciplina del software, Giuffrè, Milano, 1997, 231 ss.; i giudici, incidentalmente, hanno stabilito che “il diritto di utilizzazione economica spetta unicamente al titolare con esclusione di chiunque altro…..con conseguente tutelabilità erga omnes”; il caso si riferiva ad una sublicenza non autorizzata di software, che si è ritenuto essere vietata, escludendo quindi implicitamente la qualificazione della licenza di software come proprietà. Nega invece esplicitamente l’applicabilità dello schema della compravendita il trib. di Bari. 123 Al riguardo v. le considerazioni svolte supra cap. I.4, nonché la precedente nota 117. 124 Sul tema cfr. CARTELLA, Contenuto del diritto – Le attività di riproduzione riservata, e Giov.GUGLIELMETTI, Contenuto del diritto – Analisi e decompilazione dei programmi, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 47-54 e 152-202. 125 Concorda con quest’impostazione anche GOMULKIEWICZ, How copyleft uses license rights to succeed in the open source software revolution and the implications ro article 2b, in Houst. L.Rev. 1999, 179 ss., nonché POWELL, Judgment day for the GPL? Determining the legality of the GPL, http://www.linuxplanet.com/linuxplanet/reports/2000/1/html.

MAURO SANTO

35

Si può allora dire che la GPL si inserisce appieno nella categoria dei contratti di cessione di diritti su programmi per elaboratore; la principale differenza è però che determinati diritti, invece di non essere ceduti affatto o essere ceduti ex lege (decompilazione/modifica), sono ceduti direttamente dal titolare dei diritti126. Questa ampia cessione dei diritti dell’autore include potenzialmente anche la facoltà per i vari licenziatari di sfruttare economicamente l’opera (in primo luogo a seguito della distribuzione del software): ciò fa riflettere sul fatto che il termine licenza, se improprio per le altre licenze di software proprietario, non è invece del tutto improprio per la GPL.

3. Oltre a questa prima importante considerazione ve n’è un’altra, che caratterizza ulteriormente la

GPL, identificandola non con una semplice variante ampia delle licenze d’uso software, bensì con un quid novi che solo recentemente e soprattutto negli Stati Uniti ha attirato l’attenzione della letteratura giuridica127, con particolare riferimento a quello che è stato denominato il suo effetto contaminante128 (oppure la sua “viralità”129).

È infatti di fondamentale importanza per l’economia del progetto GNU (v. supra) che sia garantito il diritto di modificare il software, con la conseguente necessità di garantire l’accesso al codice sorgente; ma soprattutto che tali modifiche, una volte operate, siano di nuovo messe a disposizione degli altri utenti in modo tale da garantire ai terzi gli stessi diritti concessi a chi ha creato le modifiche, e ciò avverrà proprio con l’ulteriore sottoposizione del programma modificato ai termini della GPL.

Questo aspetto va ulteriormente chiarito e compreso, poiché si ritiene sia, a parere di chi scrive, la vera innovazione e la principale peculiarità della GPL, ed è soprattutto un punto sul quale spesso regna un po’ di confusione130: i diritti sull’opera (software) modificata non devono essere ceduti nuovamente; chiunque può modificare un software in privato e decidere di non distribuire affatto le modifiche apportate; se si decide però di distribuirle, le condizioni della cessione saranno quelle previste dalla GPL; quindi la GPL si espande alle modifiche del software licenziato sotto GPL, non anche però alle eventuali opere che siano state create tramite tale software; quest’ultima ipotesi risulta abbastanza chiara nel caso in cui il software libero, e quindi licenziato sotto GPL, sia un sistema operativo (quale è per esempio Linux): qualora l’utente apporti modifiche al codice sorgente di questo software, ebbene, se licenziate, queste modifiche saranno sottoposte alle previsioni della GPL (saranno quindi a loro volta modificabili, liberamente copiabili e ne dovrà essere reso disponibile il codice sorgente); se però tramite questo sistema operativo l’utente riproduce o crea nuovi software, ebbene questi quando saranno ceduti non dovranno rispettare le condizioni della GPL: sarà allora ben possibile per l’utente creare software proprietari avvalendosi di software liberi: all’interno della GPL non appare infatti rinvenibile alcun elemento che vieti questa condotta.

Quindi il solo fatto di avere dei programmi supportati da un sistema operativo licenziato sotto GPL, non rende affatto i primi software liberi. Peraltro quando si parla di creazione di software mediante altri software, un ruolo fondamentale hanno le librerie131; proprio per evitare eventuali dispute circa la qualificazione in base alla GPL di un software rispetto la propria libreria (se opera derivata o meno), la FSF ha creato un’altra licenza: la LGPL, inizialmente acronimo di Lesser General Public License, oggi di Library General Public License: come si intuisce dall’originario aggettivo Lesser, è una versione diversa e meno rigida della GPL, creata appositamente per le librerie; il suo contenuto è identico a quello della GPL, salvo per ciò che riguarda il concetto di opera derivata: in base a questa licenza l’autore che si sia servito di

126 Sebbene sia una cessione atipica: AUTERI, Il diritto d’autore nella circolazione giuridica, in AUTERI, FLORIDIA, MANGINI, OLIVIERI, R ICOLFI e SPADA, Diritto industriale, proprietà intellettuale e concorrenza, Giappichelli, Torino, 607. Sulla cessio ex lege di determinati diritti Vitt.DE SANCTIS e FABIANI, I contratti di diritto d’autore, Giuffrè, Milano, 2000, 367 ss. 127 La dottrina nordamericana già da alcuni anni ha rivolto la sua attenzione alla GPL ed all’open source, dove peraltro questi movimenti sono sorti. Gran parte dell’attenzione è stata dedicata soprattutto alle analisi economiche del modello di sviluppo di un software open source ed al suo paragone con gli altri modelli; al riguardo v. supra nota 96. 128 Si esprime così HORNE, Open source software licensing: using copyright law to encourage free use, in Georgia st. Univ. L. Rev. 2001, 863 ss. L’A. parla in particolare di “tainting effect” (p.878). 129 Di “viral effect” parla invece NADAN, Open source licensing: virus or virtue?, in Texas Int.Prop.L.Jour. 2002, 349 ss.. 130 Infatti è molto diffuso il convincimento (erroneo) che servirsi di un software open source renda tali tutti i programmi che in qualche modo vi abbiano a che fare; cfr. http://www.gnu.org/licenses/gpl-faq.it.html 131 Per la definizione di libreria v. supra nota 84.

MAURO SANTO

36

una libreria licenziata sotto LGPL, non avrà l’obbligo di licenziare il software creato secondo i termini della GPL: in altre parole, è permesso creare software proprietari tramite librerie libere. Per tutti gli altri aspetti la libreria è considerata dalla LGPL come un comune software sottoposto alla GPL: l’eventuale distribuzione delle modifiche apportate dovrà rispettare le condizioni della GPL.

Tutto questo con il preciso intento di evitare l’esclusione dal mercato delle librerie libere, a causa del timore da parte dei programmatori di dover poi rendere libero il software da loro creato; con la LGPL si consente invece anche alle librerie di svilupparsi secondo il metodo tipico del software libero, senza però rinunciare ad una loro diffusione tra i programmatori.

Questo metodo tipico di sviluppo del software libero si ricava indirettamente dal contenuto della GPL; il software infatti sarà prodotto e migliorato tramite i contributi di vari e diversi utenti-programmatori, i quali non hanno alcuna restrizione riguardante la libertà di modificare un programma, ed a loro volta non possono però restringere per i futuri utenti i diritti garantiti dalla GPL. Infatti non è assolutamente consentito modificare un software libero e limitare contemporaneamente qualcuna delle libertà che la GPL prevede a favore dell’utente né a maggior ragione renderlo un software proprietario; qualora però ciò avvenisse, è la stessa GPL a prevederne le conseguenze: il § 5 avverte infatti che ogni tentativo di modificare, sublicenziare o distribuire il programma in modo diverso da quanto previsto dalla GPL farà terminare automaticamente i diritti garantiti da questa licenza.

Quindi, implicitamente, torneranno ad essere applicabili gli artt. 64 bis ss. l.a.; pare allora di capire che automaticamente per il licenziatario verranno meno i diritti di apportare modifiche e distribuire il software liberamente, nel momento in cui egli licenzi un programma secondo condizioni più restrittive di quelle della GPL.

Tutto ciò quali conseguenze avrà nei confronti del nuovo licenziatario? Egli avrà ricevuto un software il cui licenziante non aveva alcun diritto di sublicenziare; ma quali pretese potranno essere fatte valere nei suoi confronti? La risposta a questa domanda risiede nel concetto generale di licenza d’uso software: accogliendo la teoria in base alla quale si tratta di un semplice contratto, ebbene allora avrà solamente efficacia obbligatoria; se però si ritiene, come appare preferibile, che i contratti di utilizzazione delle opere dell’ingegno, e quindi anche le licenze software, abbiano efficacia erga omnes, in quanto il loro oggetto è un diritto e non il bene immateriale in sé considerato132, allora dovrà propendersi per la tesi dell’efficacia erga omnes e di conseguenza della validità del modello GPL anche rispetto ai terzi. Ecco dunque che si può vedere l’importanza della GPL all’interno delle licenze d’uso software, poiché coinvolge le più importanti questioni riguardanti la natura giuridica di tali licenze. Soprattutto negli USA infatti la dottrina si è spesso soffermata sul tema della enforceability (e cioè sulla validità) della GPL.

A tutti ha concisamente risposto Moglen, affermando: “enforcing the GPL is something I do all the time”133. Egli è altresì molto chiaro quando giustifica questo suo convincimento, affermando sostanzialmente che la GPL pone obblighi a carico dell’utente solo quando questi distribuisce software derivato da un altro licenziato sotto GPL, e quindi in pratica quest’ultima viene accettata solo qualora vi siano delle ulteriori distribuzioni del software. E siccome nessuno è autorizzato a distribuire un software senza il consenso dell’autore, si può tranquillamente presumere che chiunque distribuisca un software licenziato secondo la GPL l’abbia anche accettata.

In ogni caso tutti gli autori convengono sulla coercibilità della GPL, sulla base della semplice considerazione che essa ha la natura di tutte le altre licenze d’uso software, sulla cui validità nessuno dubita134.

4. Fondamentale nell’architettura della GPL è il § 4, che riguarda proprio la validità della licenza:

poche righe chiariscono infatti che non si può copiare, modificare, sublicenziare o distribuire il programma se non secondo quanto espressamente stabilito nella GPL. Ogni altro tentativo di copiare, modificare, sublicenziare o distribuire il programma è nullo, e farà automaticamente terminare i diritti garantiti da questa licenza.

In tal modo viene creato un sistema nel quale la GPL garantisce i diritti in essa contenuti, purché vengano soddisfatte tutte le condizioni ivi poste, consistenti essenzialmente nel garantire gli stessi diritti

132 cfr. le considerazioni svolte al precedente cap. V.2. 133 MOGLEN, Enforcing the gpl, http://moglen.law.columbia.edu/ publications/lu-12.html 134 cfr. MCGOWAN, Legal implications of open source software, in Illinois L.Rev. 2001, 249 e 287-292; HEFFAN, Licensing collaborative works in the digital age, in Stanf. L. Rev. 1997, 1508-1511; KENNEDY, A primer on open source licensing legal issues: copyright, copyleft and copyfuture, in St.Louis L.Rev 2001, 368 e 369.

MAURO SANTO

37

agli utenti successivi: qualora una di queste condizioni non dovesse essere soddisfatta, la sanzione è già inclusa nella licenza e consiste nell’automatica cessazione dei diritti contenuti in essa; in realtà questo schema ha come scopo principale quello di evitare eventuali appropriazioni del software oppure sue distribuzioni prive del codice sorgente; infatti i diritti garantiti consistono nella copia, modifica o distribuzione del programma e le condizioni cui deve attenersi l’utente sono essenzialmente due: mettere a disposizione il codice sorgente e garantire al destinatario del software i diritti previsti dalla GPL; nella prima ipotesi, poiché è implicita una distribuzione del software, omettendo di distribuire anche il codice sorgente non si avrà alcun diritto per distribuirlo e quindi colui che cede software senza codice sorgente viola la GPL; ma alquanto più importante è la seconda ipotesi, ovvero quella in base a cui il software libero si mantiene tale, senza il rischio di divenire proprietario; è infatti necessario che anche colui cui viene distribuito il software possa modificarlo, copiarlo e distribuirlo, facoltà che la mera disponibilità del codice sorgente non garantisce affatto (si ribadisce infatti che la possibilità di avere il codice sorgente di un software non lo rende affatto open source nell’accezione di cui qui si tratta135); anche in questo caso allora, colui che distribuisce il software senza garantire tali diritti, automaticamente vedrà decaduto il proprio titolo per la distribuzione stessa, ed eventualmente compirà un atto in violazione della licenza (come se ci si trovasse di fronte ad una licenza standard che proibisca la cessione del software; ebbene, da un'altra visuale, la GPL può essere vista come una licenza che proibisce la distribuzione del software, salvo che vengano poste in essere determinate situazioni, che consistono per l’appunto nel garantire ai terzi determinati diritti).

Rimangono comunque garantiti i diritti di coloro che si conformano alla GPL, sebbene abbiano ricevuto il software da chi non aveva titolo per distribuirlo (ciò è espressamente previsto dal § 4).

Il § 5 chiarisce ulteriormente ciò che si poteva implicitamente comprendere dal § 4: si specifica infatti che nient’altro accorda il permesso di modificare o distribuire il programma o le sue elaborazioni; si avverte inoltre l’utente che queste azioni sono proibite dalla legge se non viene accettata la licenza GPL; infine è prevista un’accettazione tacita della GPL e del suo contenuto solamente modificando o distribuendo il programma (od un’opera basata sul programma).

Il § 6 rende poi esplicito che ogni volta in cui il programma viene ridistribuito, il destinatario riceve automaticamente la licenza, dal licenziante originario, di copiare distribuire o modificare il programma secondo le condizioni in essa previste. Non possono essere imposte ulteriori restrizioni sui diritti del destinatario garantiti dalla licenza. Il licenziante non è comunque responsabile del rispetto da parte dei terzi del contenuto della licenza.

Dal complesso delle disposizioni di questi due punti si ricava il modello di circolazione della GPL e le condizioni cui tale circolazione deve sottostare; se nel precedente § 4 si stabiliva infatti quando era possibile avvalersi dei diritti previsti nella GPL, nei §§ 5 e 6 vengono introdotte delle previsioni solo in apparenza semplici od addirittura superflue, ma in realtà fondamentali e fortemente caratterizzanti quello che è il modello complessivo della GPL; innanzitutto l’automaticità dell’accettazione della licenza, che avviene ponendo in essere determinati comportamenti (distribuzione o modifica del programma), rende la GPL molto simile alle altre licenze in cui l’accettazione si ricava da determinati comportamenti prestabiliti, e quindi ai c.d. contratti standard. Inoltre il ricevente ottiene automaticamente i diritti previsti nella GPL, senza alcun espresso atto in tal senso da parte del distributore, il quale non può nemmeno modificare o comunque restringere i diritti garantiti dalla licenza.

Da tutto ciò si ricava appunto l’immutabilità della GPL, l’impossibilità per chiunque di modificarne i termini.

5. Si è visto dunque che la GPL è una delle tante possibili varianti delle licenze d’uso di software, e

che queste ultime nella maggior parte dei casi sono standardizzate; parte della dottrina ritiene applicabile alle licenze software la normativa sulle clausole abusive di cui agli artt. 1469 bis e ss.; ma ciò vale anche per la GPL? Vi sono elementi tali da cui poter dedurre uno squilibrio nelle condizioni poste dalla GPL? Innanzitutto bisogna fare una premessa: la dottrina statunitense, per stabilire la disciplina applicabile alla GPL, ritiene ormai pacifica la sua equiparazione alle c.d. shrink-wrap licenses136, cioè le licenze a strappo,

135 v. supra cap. IV.4. 136 In particolare, ritengono applicabile la disciplina delle shrink-wrap licenses anche alla GPL: GOMULKIEWICZ, How copyleft uses license rights to succeed in the open source software revolution and the implications ro article 2b, in Houst. L.Rev. 1999, 190-195; BOBKO, Linux and the GPL: can copyright keep open source software free? , in AIPLA Quarterly Jour. 2000, 92-96; MCCULLOUGH, Understanding the impact of the DMCA on the open source model of

MAURO SANTO

38

la cui particolarità consiste nella presenza sulla confezione esterna dell’avviso che, una volta aperta la confezione, si riterranno accettate le condizioni della licenza, che però è posta all’interno della confezione, e che dunque il licenziatario non ha avuto modo di leggere. La dottrina italiana aveva già rilevato l’applicabilità della disciplina sulle clausole vessatorie a questo tipo di licenze137. La GPL però se da un lato è simile alle shrink-wrap licenses poiché si tratta di licenze standard, ovvero precostituite, e che la rendono uguale ai contratti per adesione, dall’altro differisce in un punto fondamentale: la conoscibilità del suo contenuto: prima di accettare la GPL l’utente ha infatti la possibilità di leggerne le clausole, mentre ciò non avviene con le shrink-wrap licenses: quindi l’accostamento fra i due tipi di licenze non sembra del tutto corretto.

Fatta questa premessa, bisogna stabilire se sia comunque applicabile la disciplina sulle clausole abusive: per rispondere a questa domanda, si deve allora stabilire se si è nelle condizioni per cui il licenziatario possa essere definito consumatore; la normativa sulle clausole abusive si applica infatti ai soli rapporti tra professionista e consumatore138; nel nostro caso però entrambi i termini sono variabili: di solito infatti per le licenze software, il professionista, licenziante, è determinato e certo, mentre l’eventuale consumatore è la variabile del rapporto; nel caso della GPL invece il licenziante non sarà necessariamente un professionista, e si può addirittura ipotizzare il caso inverso, cioè il licenziante semplice utente non professionista mentre il licenziatario professionista e non semplice consumatore, ovvero, in base all’art.1469 bis, colui che agisce per scopi estranei alla propria attività professionale. L’unico caso dunque in cui sarà potenzialmente applicabile la disciplina delle clausole abusive è quella del professionista che licenzia software open source ad un consumatore; se questo è astrattamente ipotizzabile, è anche necessario però stabilire se clausole abusive vi siano all’interno della GPL: ebbene, paiono essere degne di considerazione da questo punto di vista le previsioni circa l’assenza di garanzia e le previsioni valutabili come limitanti la libertà per il consumatore di contrarre con i terzi (art. 1469 bis c.3 n.18)139.

Nel primo caso, assenza di garanzia, sembrano condivisibili le considerazioni svolte da altri autori con riguardo alle medesime previsioni delle licenze di software proprietario: si prospetterebbero clausole abusive solo se l’assenza di garanzia fosse riconducibile anche ai casi di dolo o colpa grave, previsti dall’art.1229 cod.civ.140; poiché nel caso della GPL ciò non è previsto, è ammissibile la limitazione di garanzia e responsabilità, limitata però implicitamente ai casi non di dolo o colpa grave.

Per quanto riguarda invece la libertà di contrarre con i terzi, potrebbe essere dedotta dal fatto che colui intenzionato a licenziare software open source debba farlo esclusivamente secondo le modalità previste nella GPL, ossia senza modificare in alcun modo il contenuto della licenza. Ebbene, non sembra ci si trovi di fronte ad una clausola abusiva: la GPL non impone infatti di ridistribuire il software o le sue modifiche, ma semplicemente prevede che, qualora il software venga sublicenziato, devono essere applicate le condizioni della GPL. L’utente infatti mantiene comunque la libertà di distribuire o sublicenziare un programma.

6. La GPL ha inoltre offerto lo spunto a vari autori per formulare qualche considerazione generale sul

sistema complessivo della proprietà intellettuale e del diritto d’autore; anzi, volendo considerare nel loro insieme i contributi su questo argomento, la maggior parte sono proprio quelli che focalizzano l’attenzione sugli aspetti generali della GPL e più ampiamente dell’open source, mentre alquanto rari sono i contributi che affrontano nello specifico i contenuti della GPL.

Si è parlato di un nuovo modello di circolazione delle idee e più in generale delle opere dell’ingegno, che ammorbidisce gli elementi di monopolio sulle proprie creazioni per giungere ad una più libera fruizione da parte dei terzi delle opere altrui; ma soprattutto è stata evidenziata la possibilità di elaborare e migliorare

software development, in Marq. Intell. Prop. L. Rev. 2002, 91; ROWLAND e CAMPBELL, Supply of software: copyright and contract issues, in Int.Jour.Law&IT 2002, 23 ss. 137 In particolare D’ARRIGO, Prospettive della c.d. licenza a strappo nel nostro ordinamento, in Dir. Inf. 1996, 462-468. La loro validità è esclusa anche da DE SANCTIS e FABIANI, I contratti di diritto d’autore, Giuffrè, Milano, 2000, 373. 138 Sulla ampiezza di questa categoria v. MENGOZZI, La nozione di consumatore, la direttiva CEE 93/13 ed il diritto italiano, in Contr. e impr. Eur. 2002, I, 55 ss. 139 cfr. ROPPO e NAPOLITANO, Clausole abusive, in Enc. Giur. Trecc., VI, Roma, 1994, 1 ss.; LENER, La nuova disciplina delle clausole vessatorie nei contratti dei consumatori, in Foro it. 1996, V, 146 ss.. 140 v. CABELLA PISU, La disciplina delle garanzie nei contratti e nel codice, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 75 ss.

MAURO SANTO

39

le idee altrui in uno spirito di crescita collettiva141. Per qualcuno si è all’inizio di un processo ormai irreversibile, un processo epocale in cui a cambiare non è solo il modo di distribuire il software, bensì sono le stesse concezioni attualmente alla base del diritto d’autore. Viene riequilibrato il rapporto tra interesse privato ed interesse pubblico, tanto più nel mondo informatico dove il mezzo tecnologico può essere usato per impedire l’accesso alle informazioni142; non a caso modelli di distribuzione uguali o simili a quello della GPL per i software sono nati anche a supporto di opere letterarie e musicali143.

Qualche autore vede nel software open source l’estrinsecazione delle libertà costituzionalmente garantite, pensando ad un sistema nel quale la libertà è il bene e lo scopo principale (nel caso specifico libertà di programmare, di copiare, di modificare); soprattutto viene posto l’accento sulla libertà di appropriarsi, o meglio di prendere conoscenza delle idee altrui ed avvalersene per le proprie ulteriori creazioni ed elaborazioni.

In particolare sono state attentamente valutate le conseguenze che il software open source può avere per lo sviluppo di quello che è stato denominato il cyberspazio144; in modo anche da mantenere neutrale la rete Internet145. Vi è stato anche chi ha visto nel software open source un utile strumento per combattere i monopoli nel mondo informatico, causati soprattutto dalla standardizzazione dei file146, anche se si suggerisce però di introdurre in licenze come la GPL una clausola che obblighi anche il licenziante a mantenere open source il software147.

Senza dubbio la GPL mostra notevoli elementi di novità, soprattutto per quel che riguarda la possibilità di avvalersi delle opere altrui; ed i risultati di questo metodo si sono già visti e appaiono piuttosto lusinghieri; non va però dimenticato che l’eventuale successo ma anche l’esistenza del fenomeno dell’open source si adatta in particolare ad opere dell’ingegno come il software; infatti la sua peculiarità e la sua principale differenza dalle altre opere dell’ingegno è che esso non ha una destinazione tipica come avviene per le classiche opere dell’ingegno (un testo è destinato alla lettura, un brano musicale all’ascolto, un dipinto alla fruizione visiva); il software è caratterizzato dalla sua utilità148, e quindi i suoi autori tenderanno costantemente a migliorarlo; questo fatto rende di estrema importanza gli sviluppi precedenti, e soprattutto rende possibile un’espansione del software che spesso avviene mediante piccole ma importanti modifiche. In particolare il modello open source consente di evitare ogni volta di creare dal nulla un software, solo per migliorarne la funzionalità. Lo stesso non può dirsi invece per le classiche opere dell’ingegno. Si consideri ad esempio un romanzo o un film: quell’opera è espressione della creatività del suo autore, e nessuno potrebbe pensare di apportarvi delle correzioni o delle migliorie, poiché essi non hanno alcuna utilità da soddisfare se non quella del godimento intellettuale; il software invece deve soddisfare anche le esigenze di

141 In questi termini si esprime LESSIG, The architecture of innovation, in Duke L.J. 2002, 1783 ss. Sul rapporto tra i principi fondamentali del sistema del copyright e l’open source v. pure HAYNES, Black holes of innovations in the software arts, in Berkeley Tech. L.J., 1999, 567 ss. Per la dottrina italiana ROSSATO, Diritto architettura e software libero, 2002 http://portal .lobbyliberal.it/article/articleview/134/1/19/html. 142 ZICCARDI, Open Source e libertà del codice, in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1067 ss.; l’A. sottolinea in particolare l’importanza che rivestono le libertà garantite agli utenti nei confronti dei software open source. 143 Vi è infatti per esempio il movimento OpenPress, che applica la GPL alle opere letterarie (come per esempio il volume più volte qui citato Open Sources, Voci dalla rivoluzione open source) oppure la OPL OpenPublicationLicense (http://www.docenti.org/args/open_cont.htm); ancora, OpenMusic, che applica la GPL ai brani musicali; vi è anche un’enciclopedia costituita secondo le regole della GPL, Wikipedia (www.wikipedia.com) e vi è pure il progetto OpenLaw della Harvard Law School, costituito da numerose persone che contribuiscono ad analizzare giuridicamente determinati problemi (http://cyber.law.harvard.edu); infine esiste anche OpenCola, bevanda la cui ricetta non solo è conoscibile, ma è anche modificabile secondo i presupposti della GPL (http://www.internazionale.it/copyleft.html) 144 v. LESSIG, The limits in open code: regulatory standards and the future of the Net, in Berkeley Tech. L.J. 1999, 759 ss. 145 In particolare LESSIG, Open code and open societies: values of internet governance, in Chicago-Kent L.. Rev. 1999, 1405 ss., il quale vede nel software open source il mezzo migliore per evitare che chicchessia, tramite il monopolio degli strumenti informatici attraverso cui si sviluppa Internet, possa in qualche modo monopolizzarne anche l’accesso ed i contenuti. 146 Cfr. PATTERSON, Copyright misuse and modified copyleft: new solutions to the challenges of internet standardization, in Mich. L. Rev. 2000, 1351 ss. 147 Cfr. PATTERSON, Op. cit., 1378-1382. 148 Evidenzia questo aspetto LESSIG, The architecture of innovation, in Duke L.J. 2002, 1795; sottolinea l’unicità del software rispetto le altre opere anche MOGLEN, Anarchism triumphant: free software and the death of copyright, in First Monday, peer-reviewed journal on the internet IV 1999.

MAURO SANTO

40

funzionalità. Ancora una volta allora il software mostra tutta la sua atipicità, atipicità che ha già diviso la dottrina sul tema della tutela da applicare.

Questa considerazione a parere di chi scrive ha anche un altro corollario: sarà ben difficile esportare anche alle altre opere dell’ingegno il modello open source, ed è dunque di molto ridimensionata la portata rivoluzionaria all’interno del sistema di diritto d’autore che qualche autore attribuisce all’open source149.

149 Anche STRASSER, A new paradigm in intellectual property law?: the case against open sources, in Stanf. Tech. L. Rev. 2001, 4 ss., ritiene che in realtà il copyleft e l’open source non siano in grado di sostituire l’attuale sistema di produzione dei software; i due sistemi potranno però, secondo l’A., benissimo convivere.

MAURO SANTO

41

CAPITOLO VI I DIRITTI LICENZIATI DALLE LICENZE GNU

SOMMARIO: 1. Il diritto di caricamento, copia e distribuzione (§§ 0-1). – 2. Il diritto di modificare la copia del programma (§ 2). – 3. Le disposizioni sul codice sorgente (§ 3). 1. Analizzando nel dettaglio il contenuto della GPL, si può vedere che i diritti licenziati sono

fondamentalmente quattro: il diritto di riprodurre liberamente un programma, il diritto di copiare e distribuire il suo codice sorgente, il diritto di modificarlo ed il diritto di copiare e distribuire il programma stesso.

Tutto ciò però purché vengano rispettate determinate condizioni: iniziando dal § 0, è innanzitutto previsto che per il caricamento/riproduzione (<act of running>) del programma non vi è assolutamente alcun tipo di restrizione: ecco allora un primo diritto dell’utente, che non è poi così implicito come si possa pensare: il caricamento/riproduzione illimitato; è proprio dalla locuzione <not restricted> e dal confronto con le altre licenze software che si può dedurre la più ampia libertà per l’utente circa la riproduzione del programma: non vi sarà dunque alcun tipo di limitazione riguardante il numero di macchine su cui riprodurre il software, le modalità della riproduzione ed altre restrizioni del genere; ciò è di particolare importanza per le reti di computer o per i server.150

Sempre il § 0 specifica poi che attività che non siano (<other than>) copiare, distribuire, modificare sono escluse dall’oggetto della GPL (<outside its scope>), e sarà allora applicabile il principio generale del trasferimento limitato allo scopo del contratto151; quindi per queste altre attività rimarrà impregiudicata l’applicazione del vigente dettato normativo (artt. 64 bis ss. dlgs. 518/92)152; certo, l’ampiezza delle attività previste e coperte dalla GPL, lascia spazi veramente minimi e residuali per l’eventuale applicazione del dlgs. 518/92, ma sicuramente non ne è esclusa in alcun modo l’applicabilità. Questo inciso pare emblematico del fatto che in realtà la GPL non crea un sistema di proprietà intellettuale alternativo a quello vigente, bensì si inserisce in esso (non come ritenuto da qualche autore153).

In breve, una volta ricevuto un software licenziato secondo la GPL, un utente può riprodurlo e copiarlo senza alcuna restrizione; potrà inoltre distribuirlo a terzi e modificarlo, alle condizioni però poste nei seguenti §§.

Il successivo § 1 prevede per il licenziatario la possibilità di copiare e distribuire il codice sorgente del programma così come esso è stato ricevuto, purché su ogni copia sia pubblicato, (ben in vista, <conspicously>), un adeguato <copyright notice>: quindi il codice sorgente dovrà sempre essere accompagnato dalle informazioni riguardanti i suoi autori; lo scopo di questa previsione si può comprendere meglio considerando la parte di preambolo della GPL in cui si legge che si vuole fare in modo che ogni destinatario possa conoscere gli autori di ogni parte di codice, in modo che eventuali errori introdotti da qualcuno non si riflettano sulla reputazione altrui.

Questa previsione rappresenta in realtà uno dei principali obiettivi del progetto GNU, la possibilità di continuare a servirsi di un software a fini puramente scientifici; quale scopo avrebbe infatti la mera disponibilità di un codice sorgente senza il relativo codice oggetto, se non quello di studiarlo? Non a caso infatti, ci si preoccupa di garantire la reputazione (<reputations>) dei vari autori, obbligando gli utenti a fornire sempre, insieme al codice sorgente, adeguate informazioni sul copyright, proprio in vista di una sua diffusione tra la comunità scientifica154.

150 Nella prassi della distribuzione del software proprietario sono state sviluppate per queste esigenze licenze le quali prevedono, di volta in volta, un numero diverso di computer su cui è possibile caricare un programma in base al corrispettivo corrisposto. 151 Per questo principio AUTERI, Il diritto d’autore nella circolazione giuridica, in AUTERI, FLORIDIA, MANGINI, OLIVIERI, RICOLFI e SPADA, Diritto industriale, proprietà intellettuale e concorrenza, Giappichelli, Torino, 612 e 613. 152 Per le quali v. supra cap. I.3; nonché, in generale, L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994. 153 v. supra cap. V.1 nota 107. 154 Sull’importanza del codice sorgente per le comunità scientifiche informatiche e sul significato di reputazione nel mondo dei programmatori v. RAYMOND, Homesteading the noosphere, 1998, http://www.tuxedo.org/

MAURO SANTO

42

Naturalmente si deve evitare che qualcuno possa successivamente venir meno a queste condizioni: quindi, come avviene per i programmi, anche per il mero codice sorgente è prevista l’immutabilità della licenza; si obbliga infatti a mantenere integra la GPL, che deve essere fornita a tutti i destinatari del codice sorgente (come prevede il § 6 per i programmi).

Il § 1 si sofferma anche sulle eventuali garanzie connesse al codice sorgente del programma, e quindi al programma stesso: si impone di pubblicare sempre, con la licenza, l’avviso dell’assenza di garanzia; l’utente può però offrire delle garanzie se lo vuole, anche in cambio di un corrispettivo; corrispettivo che viene permesso anche per la mera distribuzione di una copia. Ciò introduce un’atipica possibilità di sfruttare economicamente un software libero: offrire garanzie agli utenti a seguito di un adeguato compenso; ecco allora che, forse, la denominazione di licenza per la GPL non è del tutto impropria (v. supra § 3.2).

2. Il § 2 è probabilmente fondamentale per l’architettura complessiva della GPL: in essa è infatti

prevista la possibilità per il licenziatario di modificare la propria copia del programma, anche se tali modifiche danno sostanzialmente luogo ad un nuovo programma, e distribuire o copiare queste modifiche alle condizioni dei §§ 1 e 6 (cioè garantendo ai terzi gli stessi diritti ricevuti e mantenendo intatta la GPL), purché vengano però rispettate congiuntamente tre condizioni: a) l’avviso delle modifiche apportate e la data di ciascuna modifica, allo scopo probabilmente di rendere chiaro per ciascun utente quali modifiche ha subito il programma e le differenze con la versione originale, nonché per tutelare le esigenze viste prima trattando del § 1; b) qualora venga distribuito un programma modificato, licenziarlo interamente alle condizioni della GPL; c) nei casi di programma con funzioni interattive far sì che ogni volta che il programma sia riprodotto, mostri o stampi un avviso circa il suo assoggettamento alla GPL e le condizioni in essa contenute, ed ove ciò non sia possibile fare comunque in modo d’informare l’utente su come accedere al contenuto della licenza.

Se le lett. a) e c) § 2 non sembrano particolarmente significative, la lett. a) perché precisa, riferendosi alle modifiche, quanto era già previsto al precedente § 1, la lett. c) perché si riduce a norma, per così dire, di procedura, importantissima invece è la lett. b), che merita di essere approfondita, in quanto costituisce (coi §§ 4, 5 e 6) il fulcro della GPL: nel § 2b) sono racchiuse invero le previsioni riguardanti la sorte delle modifiche ai programmi e dei lavori derivati.

Abbiamo visto infatti che una delle caratteristiche della GPL è il fatto che essa si espande alle modifiche create dagli utenti-licenziatari (il cosiddetto effetto contaminante); peraltro è opportuno capire quali siano le effettive modalità con cui si sviluppa questo effetto contaminante.

Esattamente il § 2b) prescrive che bisogna far sì che (<you must cause>) qualunque opera che venga distribuita o pubblicata, che tutt’intera o solo in parte contenga o sia derivata dal programma (s’intende, licenziato in base alla GPL) o da parte di esso, sia licenziata integralmente (<as a whole>) ai terzi senza alcun onere (<at no charge>) secondo le condizioni della GPL.

Innanzitutto si può vedere che l’effetto contaminante non è contemporaneo alla creazione delle modifiche, bensì sorge solo quando si decide di distribuire o rendere pubblico il software; da un altro punto di vista, l’utente può benissimo mantenere per sé le modifiche apportate al programma, senza alcun obbligo di licenziarle sotto GPL; qualora però decida di distribuirle, dovrà applicare loro le condizioni della GPL. Nel far ciò non dovrà prevedere alcun onere per i terzi: se infatti ciò fosse permesso, chiunque, applicando costi troppo alti per licenziare le modifiche apportate, potrebbe di fatto appropriarsi del software aggirando gli obblighi della GPL155.

Il § 2b) parla di programmi che contengono o sono derivati da altri programmi; sono allora necessarie alcune precisazioni circa la reale portata di queste espressioni: per quel che riguarda i lavori derivati, non sembrano gli stessi di cui parla la l.a., la quale qualifica come opera originaria un’opera che sia derivata da un'altra. La GPL infatti non usa le parole conformemente al significato che esse hanno nei testi normativi, bensì vi attribuisce un significato più ampio e generale. Sicuramente il lavoro derivato includerà le opere derivate ex art.4 l.a., ma includerà anche tutte quelle derivazioni che originali non sono: sostanzialmente,

~esr/writings/homesteading/homesteading.html; la traduzione italiana è disponibile su http://www.apogeonline.com/openpress/doc/homesteading.html. L’A. chiarisce che per reputazione deve intendersi il prestigio ricevuto dal riconosciuto valore dei propri lavori, che consente a chi ne gode di coordinare i progetti di sviluppo collettivo di software. 155 È consapevole di ciò anche STALLMAN, Il progetto GNU, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 64 e 65.

MAURO SANTO

43

qualunque software o parte di software che sia in qualche modo uno sviluppo di un altro, già licenziato sotto GPL.

Nel campo del software peraltro non sempre è agevole stabilire quando si è in presenza di un lavoro derivato con caratteri di originalità nel suo complesso; spesso infatti le evoluzioni sono minime in termini di quantità di codice aggiunto o modificato, ma sono importantissime in termini di qualità dell’innovazione; inoltre il campo dell’informatica è per sua natura sottoposto ad un modello di sviluppo c.d. step by step: ovvero lo sviluppo dei software avviene tendenzialmente migliorando, correggendo ed adattando un software già esistente; in tale contesto si capisce bene come la GPL abbia un’influenza notevole per le creazioni successive di software.

In ogni caso, l’incertezza che si è creata intorno all’estensione della GPL ad altri software ha rallentato notevolmente la diffusione dei software open source; non vi era infatti chiarezza sui confini esatti di espansione della GPL; ultimamente però le prese di posizione da parte di personalità di primo piano del mondo open source hanno suscitato fiducia soprattutto tra il mondo del business software156; è stato infatti chiarito che non è opera derivata qualsiasi software che si pone in un rapporto di interoperabilità con il kernel o con il sistema operativo open source.

Il capoverso finale del § 2 chiarisce ulteriormente la lett.b), precisando che tutti i precedenti requisiti devono essere applicati all’opera modificata nel suo complesso (<as a whole>). Probabilmente è in queste parole che si racchiude la vis espansiva della GPL e con una loro corretta interpretazione si può veramente capire l’ambito di applicabilità della GPL; gli stessi redattori hanno d’altronde tentato di chiarire questo concetto, specificando che in ogni caso la licenza non si applica per le parti di programma che siano identificabili, non derivate dal programma stesso (quindi che non si basano su di esso), e che possono essere ragionevolmente considerate come programmi indipendenti e separati in se stessi: ciò vuol dire che si tratta verosimilmente di quei programmi che possono già di per sé avere autonomia, e che per comodità vengono inseriti come appendici nel programma licenziato sotto GPL157; e per autonomia bisogna, come suggerisce la stessa GPL, intendere un software che sia identificabile, ovvero distinguibile ed estraibile dal programma globale e che non sia comunque una qualche derivazione di questo. Ebbene, le condizioni della GPL non si applicano alle sezioni suddette, purché comunque queste ultime vengano distribuite come opere separate: quindi se un software possiede i requisiti di cui si è parlato e che lo configurano come programma autonomo, ma questo viene distribuito in modo tale che se ne possa dedurre la sua essenzialità all’interno del programma globale, in tal caso la GPL investirà anche questo software autonomamente creato; di conseguenza – ed è qui che la vis espansiva della GPL ha la maggior efficacia – se un autore crea un software, per esempio un algoritmo per crittografare le e-mail, e lo inserisce in un altro software già licenziato sotto GPL, per esempio un programma di gestione di posta elettronica, in modo tale che ciò che ne risulti sia un software unico, la GPL si estenderà anche al software di crittografia ( rectius: qualora distribuito, il nuova software dovrà sottostare alle condizioni della GPL )158. È lo stesso § 2 a sottolineare che l’intenzione non è quella di negare i diritti dell’autore che ha creato le nuovi parti di un programma, quanto piuttosto l’esigenza di controllare la distribuzione dei software basati o derivati dal programma originale; infatti, se non fosse così – tornando all’esempio di prima – chiunque potrebbe appropriarsi di un software ( libero ) di gestione di posta elettronica, per il solo fatto di avervi inserito un algoritmo di crittografia159.

Infine si precisa che se il programma o un lavoro derivato da esso viene aggregato ad un altro lavoro non derivato dal programma su di un comune mezzo di immagazzinamento o di distribuzione, il lavoro non derivato non deve essere coperto dalla licenza GPL; il riferimento è ai casi in cui su di un medesimo cd-rom, floppy disk o simili siano memorizzati software libero e software proprietario. Com’era comunque intuibile, non vi sarà alcuna commistione fra i due.

156 Sull’apertura anche delle imprese ai software open source cfr. ASAY, A funny thing happened on the way to the market, Linux, the GPL and a new model for software innovation, 2002, http://www.linuxdevices.com/files/ misc/asay-paper.pdf 157 Per esempio un software proprietario che aggiunga un’utile funzionalità in un software libero, ma che comunque non sia essenziale all’interno di esso. 158 Si tratta dell’effetto contaminante di cui si diceva in precedenza. 159 Peraltro, a dispetto dell’apparente chiarezza della GPL, nella prassi stabilire quando si sia in presenza di un lavoro derivato da un altro o quando un software sia parte di un altro è un punto molto delicato, e per risolverlo è necessaria un’approfondita conoscenza dell’informatica; gli s tessi Moglen e Stallman hanno risposto in modo diverso a domande uguali; il “colloquio” è disponibile in ASAY, A funny thing happened on the way to the market, Linux, the GPL and a new model for software innovation, 2002, http://www.linuxdevices.com/files/misc/asay-paper.pdf

MAURO SANTO

44

3. Il § 3 contiene l’altro elemento-chiave della GPL, ovvero le disposizioni sul codice sorgente: si

permette infatti la copia e la distribuzione di un programma in codice oggetto ( quindi senza il relativo codice sorgente) in base ai §§ 1 e 2, purché l’utente applichi una delle seguenti condizioni: a) il programma sia corredato dal codice sorgente completo, in una forma leggibile dalla macchina, e fornito secondo le previsioni dei §§ 1 e 2 su di un mezzo comunemente usato per lo scambio dei programmi; oppure b) il programma sia corredato con un’offerta scritta, valida almeno tre anni, del codice sorgente, ad un eventuale costo che non sia superiore alla mera spesa della distribuzione fisica, sempre secondo le previsioni dei §§ 1 e 2; oppure c) il programma sia corredato dalle informazioni ricevute riguardo alla possibilità di avere il codice sorgente ( questa possibilità è però permessa solo per distribuzioni non commerciali e solo se il programma è stato ricevuto sotto forma di eseguibile con l’offerta della precedente lett.b).

Tutte queste previsioni hanno il palese obiettivo di rendere sempre disponibile il codice sorgente, anche quando questo non accompagna direttamente il proprio codice oggetto; in particolare la lett. b) vieta di chiedere corrispettivi troppo onerosi per cedere il codice sorgente; in tal modo infatti i vincoli posti dalla GPL verrebbero vanificati. Successivamente si specifica cosa si intende per codice sorgente: esso è <la forma preferenziale usata per modificare un lavoro; per un programma eseguibile, codice sorgente significa tutto il codice 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’istallazione dell’eseguibile. In ogni caso non è necessario che il codice sorgente fornito includa qualcosa che sia normalmente distribuito (in forma sorgente o in formato binario) con i principali componenti del sistema operativo sotto cui viene eseguito il programma (compilatore, kernel e così via) a meno che tali componenti accompagnino l’eseguibile>. L’accuratezza di questa descrizione è indice della volontà degli autori della GPL di fare in modo che siano di volta in volta distribuite tutte le parti di un software, anche quelle necessario per rendere possibile l’interoperabilità. Infatti sono inclusi tutti i moduli di un programma nonché tutti i file delle interfacce; resta escluso invece tutto ciò che è di solito distribuito con un sistema operativo.

Inoltre è previsto che se la distribuzione dell’eseguibile o codice oggetto è effettuata indicando un luogo dal quale sia possibile copiarlo, permettere la copia del codice sorgente dallo stesso luogo è considerata una valida forma di distribuzione del codice sorgente, anche se copiare il sorgente è facoltativo per l’acquirente. Questa previsione è stata introdotta verosimilmente per tutelare tutti coloro che si procurano il software dalla rete .

MAURO SANTO

45

CAPITOLO VII I DIRITTI NON LICENZIATI

SOMMARIO: 1. I diritti non licenziati come categoria ricavabile “in negativo”. – 2. Il divieto di distribuzione del § 7. 1. All’interno della GPL non è rinvenibile alcun paragrafo riguardante i diritti non licenziati; infatti

nessun diritto è esplicitamente non licenziato, la cui titolarità è riservata all’autore originario; ciò non significa però che è tutto permesso all’utente-licenziatario.

La categoria dei diritti non licenziati si può infatti ricavare in negativo, osservando ciò che non è espressamente licenziato dalla GPL; ma non basta: bisognerà poi confrontarsi con la normativa della l.a. in generale e degli artt. 64 bis ss. in particolare; dal risultato di questo confronto potranno ricavarsi i diritti non licenziati, in altre parole le attività non esercitabili dall’utente-licenziatario.

A causa dell’ampio spettro di facoltà che la GPL concede ai destinatari, i diritti non licenziati rivestono un ruolo del tutto residuale: non è infatti semplice pensare ad attività relative ad un software diverse dalla riproduzione, dalla copia, dalla modifica e dalla distribuzione di esso. Questi sono invero gli scopi propri di un software, ma ciò non impedisce che vi siano ulteriori attività che, seppur meno frequenti, nondimeno siano altrettanto apprezzabili: in particolare, e questa è un’ipotesi direttamente richiamata dalla GPL, l’inserimento di un software in un’altra opera: appropriarsi di un programma o di parte di esso al fine di combinarlo con altro software, per giungere infine ad una nuova opera, è un’attività che non rientra totalmente nel diritto di modifica accordato dalla GPL; sarebbe necessario comunque valutarne le circostanze concrete. In ogni caso la GPL vieta questa pratica qualora la nuova opera sia un software proprietario, e cioè che non rispetti le condizioni poste dalla GPL. Ecco allora un primo diritto non licenziato: la possibilità di incorporare software libero in un software proprietario.

Peraltro il § 10 permette di introdurre software libero in altri software anch’essi liberi, ma distribuiti secondo condizioni diverse da quelle della GPL, previo però il consenso da parte dell’autore. Per software i cui diritti d’autore spettano alla FSF, sempre il § 10 avverte che talora vengono fatte eccezioni, e che in ogni caso le decisioni verranno prese avendo sempre come riferimento il mantenimento di un software libero e la promozione della sua condivisione.

Si può a questo punto affermare che i diritti previsti dalla GPL non sono licenziati se essa non viene accettata. Questa considerazione impone però una puntualizzazione: l’utente che non intenda accettare le condizioni della GPL può benissimo rifiutarsi di aderirvi; non potrà allora copiare, modificare o distribuire il software; potrà però godere di quei diritti previsti dagli artt. 64 bis ss. l.a., ed in particolare: potrà effettuare una copia di back up, potrà correggere gli eventuali errori ai fini della interoperabilità del software e potrà decompilarlo per finalità di studio; tutto ciò anche se, come detto, egli non abbia accettato la GPL. La giurisprudenza e la dottrina hanno infatti già messo in luce il fatto che questi diritti sono comunque garantiti per gli utenti che abbiano accettato licenze d’uso in cui però tali diritti non siano previsti; e siccome la GPL è una licenza d’uso software, questo discorso vale anche per la GPL. Sarà possibile, come accennato, correggere gli errori del programma, purché questi non diano luogo a miglioramenti od adattamenti, ma siano solo quelli che impediscono l’uso del programma secondo la sua destinazione160; saranno poi ammesse la copia di back up, il reverse engineering e la decompilazione per conseguirne l’interoperabilità oppure per osservare e studiare i principi su cui si fonda il programma, nel

160 Questa visione restrittiva è adottata pure da ZINCONE, Come prevenire le problematiche inerenti alla utilizzazione del software, in IDA 1996, IV, 393.

MAURO SANTO

46

rispetto comunque delle condizioni poste dagli artt. 64 ter e quater161; queste attività dovranno essere valutate anche alla luce dell’evoluzione e dell’interpretazione giurisprudenziale162.

Insomma, compiendo tali attività l’utente non violerà affatto la GPL. 2. Un caso particolare in cui vengono meno i diritti per l’utente-licenziatario di distribuire a sua volta

il software, è quello nel quale le modalità di creazione, di sviluppo o di modifica di un software possano far ritenere possibile un’eventuale contestazione susseguente ad una violazione delle norme sulla proprietà intellettuale, in particolare violazione di brevetto. In questo caso la GPL al § 7 prevede che in una tale situazione l’utente si astenga dal distribuire il software: nonostante il tono garbato di questa frase, in realtà tutto questo significa che l’utente non ha il diritto di distribuire un software nei casi in cui un eventuale pronuncia giudiziale (o anche un eventuale lodo arbitrale) ponga obblighi contrastanti con quelli posti dalla GPL: in tal caso si dovrà rinunciare a distribuire il software; se ciò può essere a prima vista giustificabile con l’esigenza di evitare complesse liti giudiziarie che sarebbero potenzialmente comprensive di numerosi soggetti, vi è anche un’altra più importante esigenza: quella di impedire (come paventa la stessa GPL) che un’eventuale azione giudiziaria possa rendere proprietario un software fino ad allora libero; e quindi di evitare anche che determinati soggetti inseriscano con dolo software tutelato da brevetto in un software libero, con lo specifico fine di appropriarsene successivamente, aggirando così la GPL, il cui scopo è invece quello di mantenere libero un programma. Infatti lo stesso § 7, al secondo capoverso, sottolinea che l’intenzione non è affatto quella di indurre a violare diritti d’autore o brevetti, bensì quella di proteggere l’integrità del modello di distribuzione del software libero (<this section has the sole purpose of protecting the integrity of the free software distribution system>).

L’allusione esplicita ai brevetti è chiaramente indice della consapevolezza che ormai i brevetti sul software, nonostante quanto detto sopra, sono soprattutto nel nordamerica una realtà con cui è necessario rapportarsi quotidianamente.

Le medesime considerazioni giustificano il § 8, il quale permette che l’utente-licenziatario che voglia distribuire un software libero, limiti geograficamente tale distribuzione, sulla base dei possibili ostacoli che possono sorgere in base alle norme sulla proprietà intellettuale di determinate nazioni (si parla in particolare di brevetti e di interfacce protette da copyright). Quindi la distribuzione può subire delle restrizioni, purché queste siano scritte nella licenza che accompagna il software.

161 Sulle quali BROCK, La disciplina del reverse engineering nella legge di attuazione della direttiva CEE sul software, in Riv.dir. ind. 1993, I, 266 ss.; Giov.GUGLIELMETTI, Contenuto del diritto – Analisi e decompilazione, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 152ss. Sulla copia di back up CARTELLA, Contenuto del diritto – Le attività di riproduzione riservata , in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 47 ss. 162 Per esempio, in tema di decompilazione, questa sarà ammessa anche quando l’utente abbia la necessità di visualizzare i dati trattati dal software; v. Collegio probiviri ANASIN, dec. 4 dicembre 1997, in AIDA 1998, 546.

MAURO SANTO

47

CAPITOLO VIII I TITOLARI DEI DIRITTI PATRIMONIALI E MORALI D’AUTORE

SOMMARIO: 1. La GPL nel sistema di diritto d’autore. – 2. Il software licenziato sotto GPL: opera collettiva. – 3. Segue: opera composta omogenea. – 4. Segue: elaborazione creativa. – 5. I diritti morali. 1. Il modello open source indubbiamente ha estrema rilevanza nel campo delle licenze d’uso software

e più in generale nel sistema complessivo di trasferimento dei diritti relativi ad opere dell’ingegno. Della novità e della totale atipicità della GPL nel panorama complessivo del mondo delle licenze

software si è già detto in precedenza; qui interessa prendere in considerazione un altro aspetto del software licenziato sotto GPL, ovvero la sua configurazione come opera dell’ingegno all’interno del nostro ordinamento normativo: questo non è affatto un problema secondario, poiché pare sicuramente importante stabilire il regime giuridico di un’opera la cui creazione è costantemente in fieri ed i cui autori sono molteplici.

Innanzitutto è necessario prendere le mosse da un dato spesso sottovalutato: vi è sempre un titolare dei diritti d’autore sul software rilasciato sotto GPL; come già detto, infatti, il modello open source vive all’interno del sistema giuridico, e le convenzioni internazionali e le leggi sul diritto d’autore sono necessarie per la sua esistenza; per esempio, il maggiore (qualitativamente e quantitativamente) software open source in circolazione è Linux, il cui diritto d’autore è in capo a Linus Torvalds, suo creatore originario; ancora, titolare dei diritti relativi ai software che fanno parte del progetto GNU (Emacs ecc…) è la FSF di Richard Stallman; in quest’ultimo caso titolare dei diritti è però una persona giuridica piuttosto che una persona fisica. Da ciò si deduce chiaramente che il titolare (o i titolari) dei diritti sono coloro che procedono alla creazione del software, che successivamente sarà sottoposto alle condizioni della GPL163.

Fin qui la fase iniziale di un software open source, che non si discosta affatto dalla disciplina prevista per i programmi per elaboratore; è però la fase successiva, quella peculiare del sistema open source, che merita maggior attenzione: in questa fase infatti chiunque, purché si attenga alle condizioni viste prima, può modificare il software; potenzialmente questa pratica è illimitata (illimitate modifiche ed illimitati modificatori). Qual è allora lo status di coloro che apportano modifiche al codice sorgente e poi lo ridistribuiscono? Si è in presenza di una nuova opera o di un’opera modificata? Non è possibile rispondere in modo univoco, bensì sarà necessario valutare le circostanze concrete. In ogni caso sembrano configurabili tre distinte ipotesi: opera collettiva, opera composta omogenea, opera derivata.

Per stabilire quale si adatta meglio al software open source, bisogna riflettere sull’elemento principale costituito dalla entità delle varie creazioni. Pare ovvio che la valutazione delle varie opere, che nel nostro caso si concretizzano in porzioni di codice, dipenderà caso per caso dal risultato offerto dalle varie modifiche. Così, vi potranno benissimo essere modifiche assai rilevanti per le funzionalità del software, ma che si concretizzano in poche righe di codice sorgente senza alcuna autonomia (come nel caso di una modifica di un algoritmo); mentre vi potranno essere programmatori che inseriscono nel software una porzione di codice che può anche avere vita autonoma ( il caso per esempio di chi inserisca in un software open source un programma per la crittografia dei documenti).

Stabilire quale sia il regime giuridico di un software licenziato sotto GPL è condizione necessaria per capire chi siano i titolari dei diritti d’autore e dei diritti patrimoniali; l’oggetto di questi diritti seguirà invece la stessa sorte degli altri comuni software in base alla l.a.164.

2. La prima ipotesi, software open source come opera collettiva165, seppur astrattamente ammissibile,

sarà nella prassi raramente riscontrabile; sono infatti necessari due elementi: un soggetto che scelga e selezioni il materiale e degli autori che creino opere dotate di una propria autonomia.

163 Così anche MCGOWAN, Legal implications of open source software, in Illinois L.Rev. 2001, 241 ss. 164 Sul regime dell’opera collettiva v. L.C.UBERTAZZI e AMMENDOLA, Diritto d’autore, in Dig. comm., IV, UTET, Torino, 1989, 366 ss.

MAURO SANTO

48

Entrambi questi elementi sembrano difficilmente identificabili in un software open source; innanzitutto le opere dotate di una propria autonomia: spesso si tratta di porzioni di codice sorgente che isolate dal resto del codice non hanno alcuna funzionalità, e quindi mancano totalmente di autonomia nel senso inteso dalla l.a.; inoltre la figura dell’autore dell’opera collettiva, cioè chi organizza e dirige la creazione dell’opera è con poca probabilità individuabile166; semmai una tale situazione potrà verificarsi quando viene creato e sviluppato ex novo un software open source, sempre purché vengano fra loro coordinate opere dotate di propria autonomia.

Infatti osservando le comuni modalità di sviluppo del software open source si può notare che non qualsiasi modifica al software entra a far parte dell’opera finale, bensì solo quelle scelte, appunto, dal titolare originario dei diritti o da coloro che sono da egli delegati, spesso a seguito di scambi di e-mail in cui ciascuno espone le proprie considerazioni167. Quindi, anche se vi potranno essere casi in cui è possibile ravvisare un’attività di scelta, coordinamento, direzione ed organizzazione da parte di un soggetto conformemente agli artt. 3 e 7 l.a., rimane comunque fondamentale capire se tutto ciò avvenga verso opere o parti di opere che hanno carattere di creazione autonoma; cioè se le singole parti non si compenetrano reciprocamente, ma restano distinte168, seppure all’interno di un’opera unitaria; ebbene questo requisito sarà difficilmente rispettato da un’opera quale il software, in cui la compenetrazione delle parti di codice sorgente è un requisito che potremmo definire ontologico. Possiamo allora concludere che, anche se un software open source è astrattamente classificabile come opera collettiva, nella prassi ciò sarà alquanto improbabile.

3. Il software open source sembra invece più simile allo schema corrispondente ad un’opera

composta omogenea, in cui si avranno una pluralità di coautori, i quali potranno aver creato un’opera in cui i contributi sono inscindibili ed indistinguibili, ovvero un’opera in cui gli apporti di ciascuno sono perfettamente identificabili169.

Nel primo caso il software open source sarà oggetto di comunione da parte dei coautori per parti che si presumono uguali ex art.10 c.2; nel secondo caso invece ciascuno sarà titolare dei diritti relativi alla parte da lui creata. La seconda ipotesi è comunque quella più verosimile, mentre la prima si potrà verificare solamente nei casi dello sviluppo iniziale del software open source o nei casi in cui le modifiche siano apportate da un gruppo di coautori i cui contributi siano indistinguibili; nella prassi comune però sarà relativamente agevole stabilire l’autore delle varie parti di codice sorgente, poiché è la stessa GPL170 a consigliare a coloro che sono intenzionati ad apportare modifiche al codice sorgente, di distribuire le patch (cioè le modifiche già pronte per essere automaticamente inserite nel software) corredate dal nome dell’autore, dalla data di creazione e dal simbolo ©; nel testo si giustifica questo suggerimento con il fine di voler evitare che possa essere eventualmente compromessa la reputazione di altri autori; praticamente però lo scopo principale di questa operazione è quello di rendere distinte le parti di codice sorgente create da ciascun autore.

In ogni caso, seppur per parti non uguali, permane il regime di comunione sull’opera software171, e siccome i coautori possono rapidamente raggiungere un numero elevato rispetto alle comuni opere

165 Alcuni autori parlano in modo del tutto improprio di opera collettiva, intendendo un’opera creata da più coautori; qui ci si riferisce invece all’opera collettiva così come è intesa dall’art.3 l.a. 166 Anche se lo stesso Torvalds si ritiene coordinatore di Linux: v. http://arcana.linux.it/docs/linus/linus-it.html 167 Per avere un’idea dello sviluppo di un software open source è utile consultare l’URL http://www.jwz.org/doc/lemacs.html, in cui si possono leggere le varie fasi attraverso cui si è giunti alla creazione del software XEmacs. Oppure, sullo sviluppo di Linux attraverso Minix, v.: Appendice A, il dibattito tra Tanenbaum e Torvalds, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 237ss.. 168 Sull’importanza della distinzione fra le varie parti di un’opera cfr. GRECO e VERCELLONE, I diritti sulle opere dell’ingegno, UTET, Torino, 1974, 92; AMMENDOLA, sub art.3 l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998. 169 Sull’opera composta, sebbene non espressamente prevista dal legislatore, GRECO e VERCELLONE, I diritti sulle opere dell’ingegno, UTET, Torino, 1974, 93. AMMENDOLA, Diritto d’autore- parte II, Diritto materiale, in Dig. comm., IV, UTET, Torino, 1989, 405 ss 170 v. preambolo GPL. 171 Il regime di comunione è quello tipico per le opere create da più autori; v. SARTI, sub art.10 l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998.

MAURO SANTO

49

dell’ingegno, un problema di notevole importanza è quello di coordinare tutti i coautori qualora ciò si renda indispensabile; si pensi infatti ai casi di litisconsorzio per le eventuali azioni giudiziarie, ed in ogni caso alla difficoltà di avere il consenso di ciascun coautore nei casi in cui ciò sia necessario (casi facili da immaginare visto il regime di comunione cui è sottoposto il software open source). Proprio per evitare difficoltà connesse ad una tale situazione, la FSF consiglia a coloro che contribuiscono allo sviluppo di un software open source, di cedere i propri diritti relativi alla parte di opera da essi creata alla stessa FSF, all’esplicito fine di ottimizzare le energie nei casi in cui sia necessario ottenere il consenso di tutti gli autori e di centralizzare la gestione dei diritti del software open source172: ciò è di particolare importanza per software talmente vasti e complessi per cui la ricerca di ciascun coautore è, se non impossibile, altamente improbabile: si pensi infatti al sistema operativo Linux, componente di primo piano nel progetto GNU; distribuito per la prima volta più di dieci fa, si è costantemente avvalso dei contributi di molteplici soggetti. Senza dubbio tentare la ricostruzione dello sviluppo di Linux è un’operazione alquanto impegnativa, che è però resa oltremodo più facile dalla gestione centralizzata dei diritti d’autore da parte della FSF. D’altra parte questa caratteristica è anche quella che consente di ritenere inammissibile un’eventuale ritiro di un software dalla modalità di distribuzione open source, se non a patto di un consenso da parte di tutti i coautori (che abbiamo visto essere azione molto laboriosa). In tal modo i rischi per un software open source di divenire proprietario sono molto molto ridotti.

Questo rapporto tra coautori si avrà sia nel caso in cui Tizio invia a Caio le modifiche apportate all’opera da questi creata, che provvederà poi a distribuirle con il resto del codice sorgente, sia nel caso in cui invece è lo stesso Tizio a distribuire il software creato da Caio corredato dalle modifiche apportate; in entrambi i casi infatti Tizio e Caio sono qualificabili come coautori.

4. Infine vi è una terza ipotesi, in base a cui si può definire la GPL come una preventiva e generale

autorizzazione all’ulteriore elaborazione e modificazione del programma. Infatti un soggetto per poter elaborare un’opera o comunque per apportare modificazioni od aggiunte che costituiscano un rifacimento sostanziale deve avere il permesso del titolare dei diritti sull’opera originaria, cui il diritto di modificare l’opera è attribuito in via esclusiva dalla l.a. (nel caso dei programmi per elaboratore ciò è esplicitamente previsto dall’art.64 bis c.1 lett.b ). In particolare i diritti conferiti dalla l.a. comprendono non solo quello di effettuare, ma anche quello di autorizzare le elaborazioni; ed è proprio un’autorizzazione allora quella ascrivibile al contenuto della GPL, autorizzazione alla riproduzione (art 64 bis lett.a), alla distribuzione (lett.c), ma soprattutto alla modificazione ed all’adattamento (lett.b) del software.

Si inizia così a delineare un altro schema entro cui possono inserirsi le opere create dai vari utenti, nonché lo status del software che viene inizialmente distribuito. Ovviamente vi sarà infatti un software che viene distribuito in base alle condizioni della GPL: abbiamo già visto che ciò non equivale al pubblico dominio, quindi esso avrà degli autori i quali sono i titolari dei diritti d’autore relativi all’opera software; poiché a questo viene applicata la licenza GPL, sono previamente conferite agli utenti le autorizzazioni alla riproduzione, distribuzione e modificazione. In base a ciò sarà possibile allora che ciascun utente apporti le modifiche che ritiene più opportune al software, senza incorrere in alcuna violazione delle norme sul diritto d’autore. A questo punto, che ne è delle modifiche e cioè di quelle che la licenza GPL chiama derivative works, ovvero opere derivate? Ebbene, queste opere godranno di un’autonoma tutela, senza pregiudizio dei diritti esistenti sull’opera originaria; naturalmente occorrerà valutare il carattere creativo dell’opera, e ciò dovrà avvenire in base all’art.4 l.a., secondo cui ha autonoma tutela un’opera derivata che abbia un carattere di originalità173. Tutela ancora più rafforzata nel caso in cui non si tratti di semplici elaborazioni od adattamenti, bensì di modificazioni od aggiunte che costituiscano un rifacimento sostanziale dell’opera originaria. In sintesi, ogni qualvolta un utente modifica od elabora un software open source, egli sarà autore di una nuova opera, e le opere derivate con autonomi autori saranno tante quante le modifiche apportate al

172 cfr. MOGLEN, Why the FSF gets copyright assignments from contributors, http://www.gnu.org/copyleft/why-assign.html. 173 Sul grado di originalità dei software, necessariamente più ristretto rispetto le altre comuni opere dell’ingegno cfr. MUSSO, Contenuto del diritto - Elaborazioni creative del software e programmi derivati, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 62-82; v. inoltre AMMENDOLA, sub art.4 l.a., in MARCHETTI e UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998, nonché GRECO e VERCELLONE, I diritti sulle opere dell’ingegno, UTET, Torino, 1974, 45-52 e 88-92.

MAURO SANTO

50

software. Non vi saranno dunque di norma né coautori né opere collettive, bensì singoli autori, salvi i casi in cui ovviamente la creazione e l’elaborazione dell’opera non diano effettivamente luogo a tali fattispecie, ossia le modifiche non corrispondano ad un rifacimento sostanziale dell’opera. Ciascun utente che abbia allora modificato in modo sostanziale il proprio software sarà allora autore della rispettiva opera dell’ingegno. Va ricordato che si tratta di un’analisi dal punto di vista giuridico del fenomeno open source nel suo schema tipico e minimo; nella prassi infatti si sono sviluppate forme di collaborazione tra utenti-programmatori ed autori originari volte alla ottimizzazione delle risorse per lo sviluppo di determinati software (per esempio Linux); in base a questo metodo l’utente invia al gruppo di autori originari le proprie modifiche che saranno poi valutate ai fini di un loro inserimento nel lavoro globale; si tratta in realtà di un sistema che rende più efficiente la distribuzione e la gestione delle elaborazioni; ciò però lascia inalterati i diritti che l’utente-programmatore ha acquisito in via originaria sulle proprie elaborazioni e sulle modifiche da egli apportate; un caso in particolare è importante per i risvolti di questa considerazione; si consideri il caso in cui, per assurdo, Torvalds, il detentore dei diritti d’autore sul software Linux, o meglio, la Free Software Foundation, detentrice dei diritti d’autore sul sistema operativo GNU/Linux, decida di non permettere più la distribuzione sotto GPL; potrà fare ciò liberamente o dovrà avere il consenso di tutti coloro (migliaia di programmatori) che hanno apportato un contributo creativo al software? E se potrà farlo liberamente, che ne sarà delle modifiche apportate? In base alle considerazioni svolte sopra, non pare che agli autori originari possa vietarsi di ritirare la GPL dal loro software174; ciò impedirà le modifiche, ma solo quelle future, lasciando impregiudicate quelle già avvenute; inoltre gli utenti-programmatori avranno il diritto non solo di mantenere le loro opere, ma anche di ridistribuirle a loro volta sotto GPL, poiché quando furono autorizzati ad apportare modifiche, diedero vita ad un’opera a sua volta autonomamente tutelata, seppur derivata. Quindi il quesito posto da qualche autore, e che sembrava essere il punto oscuro della GPL e del sistema open source, ovvero se in realtà si stava assistendo ad un’estensione incalcolabile degli autori-coautori, o se invece il gruppo di autori originari era in qualche modo il dominus incontrastato del software open source175, trova soluzione già all’interno delle norme di diritto d’autore, risultando da queste molto ridimensionato.

Il diritto sull’opera derivata si crea solo a condizione che siano rispettate le condizioni poste dalla GPL; se queste vengono infatti violate (per esempio mancata distribuzione del codice sorgente), come si è visto sopra, l’utente-programmatore perde automaticamente l’autorizzazione a modificare ed elaborare il software, salvi i casi in cui, naturalmente, egli agisca conformemente alle previsioni degli artt.64 ter e quater (ovvero diritto di adattamento per l’interoperabilità e diritto di analisi e decompilazione); rimane in ogni caso sempre necessaria l’autorizzazione dell’autore originario per modificare il software.

5. Un cenno particolare meritano i diritti morali spettanti agli autori del software; sebbene il testo

della GPL non ne parli, né la dottrina vi abbia dedicato attenzione, non v’è dubbio che essi trovano applicazione: sorgono in capo a ciascun autore e sono inalienabili ex art.20 l.a.176; in particolare, per quel che qui rileva, ciascun autore, sebbene abbia licenziato il proprio software secondo la GPL (e quindi autorizzando implicitamente a modificare la propria opera), può opporsi a quelle modifiche che possano recare pregiudizio al suo onore ed alla sua reputazione, salvo che esse siano state conosciute ed accettate in base all’art.22 l.a..

Il riflesso pratico di queste considerazioni è che l’adesione alla GPL non comporta automaticamente la rinuncia ai propri diritti morali, inalienabili appunto; quindi chiunque abbia scritto una parte più o meno rilevante del codice sorgente di un software libero, potrà in qualunque tempo rivendicare i propri diritti morali e vietare gli eventuali atti previsti dall’art.20 l.a..

174 È di quest’avviso anche MCGOWAN, Legal implications of open source software, in Illinois L.Rev. 2001, 241 ss. 175 Si poneva questo quesito STRASSER, A new paradigm in intellectual property law?: the case against open sources, in Stanf. Tech. L. Rev. 2001, 4 ss. 176 cfr. AMMENDOLA, Diritto d’autore - parte II, Diritto materiale, in Dig. comm., IV, UTET, Torino, 1989, 405 ss.

MAURO SANTO

51

CONCLUSIONE

Giunti alla conclusione di questo lavoro, possiamo agevolmente affermare che le licenze pubbliche GNU fanno parte a pieno titolo delle licenze d’uso software, caratterizzandosi per l’ampiezza dei diritti riconosciuti agli utenti; utenti i quali potranno assumere anche la duplice veste di utenti-autori.

L’essenza dei queste licenze è senza dubbio, oltre che nelle varie facoltà attribuite al licenziatario, nell’imporre che ciascuno garantisca successivamente le medesime condizioni di cui ha goduto, e soprattutto che a sua volta licenzi nuovamente secondo GPL le eventuali modifiche create al codice sorgente del software.

Sarà comunque di notevole importanza capire che tipo di opera si sia venuta a creare, se collettiva o composta, per individuare in concreto gli autori titolari dei diritti previsti dalla l.a.; autori che, viste le modalità di sviluppo tipiche dei software licenziati sotto GPL, saranno nella maggior parte dei casi una pluralità.

Sono innegabili la novità e, in un certo senso, il cambiamento portati da questo modello di sviluppo dei software: tuttavia bisogna riconoscere che tale modello trova piena efficacia rispetto ad un’opera quale il software (e d’altra parte è per esso che è stato creato), mentre pare meno adattabile allo sviluppo delle comuni opere dell’ingegno.

Quindi, sebbene per il campo dei software l’open source sia innegabilmente innovativo, nel campo globale del sistema del diritto d’autore non pare assumere affatto la portata rivoluzionaria che spesso gli è stata attribuita.

MAURO SANTO

52

BIBLIOGRAFIA

AA.VV., Condizioni generali di contratti di utilizzazione del computer, in Dir. Inf. 1986, 239.

AMADORI, BAZZIGALUPPI, BERNOCCHI e GATTI, Sistemi operativi open source: il caso Linux, in Mondo Digitale 2002, I, 47.

AMMENDOLA, La brevettabilità nella convenzione di Monaco, Giuffrè, Milano, 1980.

AMMENDOLA, Diritto d’autore- parte II, Diritto materiale, in Dig. comm., IV, UTET, Torino, 1989, 405.

AMMENDOLA, sub artt. 12 l.i., 3 e 4 l.a., in MARCHETTI e L.C.UBERTAZZI, Commentario breve al diritto della concorrenza, CEDAM, Padova, 1998.

ANDERSON, FRANCIS, HOMER, HOWARD, SUSSMAN e WATSON, Asp.Net, Hoepli, Milano, 2001.

ASAY, A funny thing happened on the way to the market, Linux, the GPL and a new model for software innovation, http://www.linuxdevices.com/files/misc/asay-paper.pdf

AULETTA e MANGINI, Marchio - Diritto d'autore sulle opere dell'ingegno, in Commentario del codice civile, a cura di SCIALOJA e BRANCA , Zanichelli, Bologna, 1996.

AUSIELLO, I compilatori e la traduzione dei linguaggi di programmazione, in CIOFFI e FALZONE, Manuale di informatica, Calderini, Bologna, 1986, 643.

AUTERI, Il diritto d’autore nella circolazione giuridica, in AUTERI, FLORIDIA, MANGINI, OLIVIERI, RICOLFI e SPADA, Diritto industriale, proprietà intellettuale e concorrenza, Giappichelli, Torino, 2001, 607.

BENUSSI, Brevetto europeo , in Dig. comm.,II, UTET, Torino, 1987, 323.

BENUSSI, La giurisprudenza europea in materia di software di fronte ad un nuovo orientamento?, in Riv. dir. ind. 1999, II, 563.

BERNARDI, La filosofia del software libero, http://www.interlex.it/pa/bernardi.htm

BERTANI, Impresa culturale e diritti esclusivi, Giuffrè, Milano, 1998.

BIANCHI, Programmi applicativi per elaboratori elettronici ed aspetti della disciplina del segreto , in IDA 1988, 1.

BIN, L’equilibrio sinallagmatico nei contratti informatici, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 65.

BIN, La circolazione internazionale dei modelli contrattuali, in Contr. e impr. 1993, 475.

BIRD, In brief – Australian patents, in Patent World 2002, 146.

BOBKO, Linux and the GPL: can copyright keep open source software free?, in AIPLA Quarterly Journ. 2000, 92.

BOBKO, Open source software and the demise of copyright, in Rutgers Computer. & Tech. L. Journ. 2001, 51.

MAURO SANTO

53

BORRUSO, L’algoritmo per computer e la sua brevettabilità, in Dir. inf. 1987, 75.

BOSOTTI, sub art. 52 CBE, in MARCHETTI e L.C.UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998.

BOVET, I sistemi operativi, in CIOFFI e FALZONE, Manuale di informatica, Calderini, Bologna, 1986, 577.

BRADNER, La IETS, Internet Engineering Task Force, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 49.

BRANDLE, Can and may interpretation and determination of the extent of proctetion of an european patent in different countries lead to different results?, in IIC 1999, 881.

BROCK, La disciplina del reverse engineering nella legge di attuazione della direttiva CEE sul software, in Riv.dir. ind. 1993, I, 266.

CABELLA PISU, La disciplina delle garanzie nei contratti e nel codice, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 75.

CAPPELLARO, sub art. 64 bis l.a., in MARCHETTI e L.C.UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998.

CARNEVALI, Sulla tutela giuridica del software, in Quadrimestre 1984, 251.

CARTELLA, Contenuto del diritto – le attività di riproduzione riservata, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 47.

CASSOTTANA, Sperimentazione in ambito privato ed uso del know-how a fini industriali nella normativa sui programmi per elaboratore, in Contr. e impr. 1993, 1251.

CAVANI, Oggetto della tutela , in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 1.

CERINA, Contratti internazionali di informatica e legge applicabile, in Dir. Inf. 1994, 416.

CHERPILLOD, Contrats de licence de software, in AA.VV., Le logiciels et le droit, Cedidac, Lausanne, 1986.

CIAMPI, Profili comparatistici della protezione del software nella legislazione e nella prassi contrattuale, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 331.

CIAN, Il nuovo capo XIV-bis (titolo II, libro IV) del codice civile, sulla disciplina dei contratti con i consumatori, in Studium Iuris 1997, 411.

CIOFFI, Gli assemblatori, in CIOFFI e FALZONE, Manuale di informatica, Calderini, Bologna, 1986, 306.

COHEN J. e LEMLEY, Patent scope and innovation in the software industry, in Calif. L. Rev. 2001, 1.

COHEN S., To innovate or not to innovate, that is the question: the functions, failures, and foibles of the reward function theory of patent law in relation to computer software platforms, in Mich. Telecomm. Tech. L. Rev. 1998/1999, 1.

D’AIETTI, Il decreto legislativo 29 dicembre 1992 n. 518 ed il suo inserimento nella difesa delle opere d’ingegno. La tutela giudiziaria civile e penale, in Dir. Inf. 1994, 219.

D’ARRIGO, Prospettive della c.d. licenza a strappo nel nostro ordinamento, in Dir. Inf. 1996, 462.

MAURO SANTO

54

DE NOVA, L’oggetto del contratto, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 27.

DE SANCTIS Vitt. e FABIANI, I contratti di diritto d’autore, Giuffrè, Milano, 2000.

DE SANTIS L., Ancora sui programmi per computer: che fine ha fatto Benedetto Croce?, in IDA 1988, 323.

DESSEMONTET, La protection des programmes d’ordinateur, in AA.VV., Le logiciels et le droit, Cedidac, Lausanne, 1986.

DI BONA, OCKMAN e STONE, Introduzione, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 1.

DRAGOTTI, Software, brevetti e copyright: le recenti esperienze statunitensi, in Riv. dir. ind. 1994, I, 539.

FALZONE, I linguaggi di programmazione, in CIOFFI e FALZONE, Manuale di informatica , Calderini, Bologna, 1986, 367.

FERRIS, Fixing security holes on Internet time, http://linuxtoday.com/stories/ 6947.html

FINOCCHIARO, I contratti ad oggetto informatico, CEDAM, Padova, 1993.

FINOCCHIARO, I contratti di informatica , in GALGANO, I contratti del commercio, dell’industria e del mercato finanziario , UTET, Torino, 1995, 1637.

FLAMING, Linux: the new, free kid on the block, in Illinois Bar Journ. 1999, 107.

FLORIDIA, La tutela del software, in Dir. inf. 1989, 71.

FRANCESCHELLI V., Computer, diritto e protezione giuridica del software, in Riv. dir. civ. 1986, II, 371.

FRANCESCHELLI V., La direttiva sulla tutela del software: trionfo e snaturamento del diritto d'autore, in Riv. dir. ind. 1991, I, 169.

FRANCESCHELLI V., Tutela giuridica dei programmi per elaboratore, in NLCC 1995, 261.

FRASSI, Creazioni utili e diritto d’autore, Giuffrè, Milano, 1997.

GALGANO, La cultura giuridica italiana di fronte ai problemi informatici, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 380.

GARFINKLE, Stallman è in stallo? , in SCELSI, No copyright, nuovi diritti nel 2000, Shake, Milano, 1994, 154.

GHIDINI, La natura giuridica dei software, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 323.

GLADSTONE, Why patenting information technology and business methods is not sound policy: lessons from history and prophecies for the future, in Hamline L. Rev. 2002, 217.

GOMULKIEWICZ, How copyleft uses license rights to succeed in the open source software revolution and the implications for article 2b, in Houst. L. Rev. 1999, 179.

GRECO e VERCELLONE, Le invenzioni ed i modelli industriali, UTET, Torino, 1968.

GRECO e VERCELLONE, I diritti sulle opere dell’ingegno, UTET, Torino, 1974.

MAURO SANTO

55

GUGLIELMETTI Giov., Brevettabilità delle invenzioni concernenti software nella giurisprudenza della Commissione di ricorso dell’Ufficio europeo dei brevetti, in Riv. dir. ind. 1994, II, 358.

GUGLIELMETTI Giov., Contenuto del diritto – analisi e decompilazione dei programmi, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 152.

GUGLIELMETTI Giov., L’invenzione di software, 2ed., Giuffrè, Milano, 1997.

HANNEMANN, The patentability of computer software, Kluwer law & taxation publishers, Deventer, 1985.

HAUSMAN, COHN e PRESENTI, Will Israel follow the USA, Japan, and the EPO and allow patent protection for software?, in IIC 2002, 15.

HAYNES, Black holes of innovations in the software arts, in Berkeley Tech. L. Journ. 1999, 567.

HEFFAN, Licensing collaborative works in the digital age, in Stanf. L. Rev. 1997, 1508.

HILL, Fragmenting the copyleft movement: the public will not prevail, in Utah L. Rev. 1999, 797.

HORNE, Open source software licensing: using copyright law to encourage free use, in Georgia st. Univ. L. Rev. 2001, 863.

KARJALA, Copyright protection of computer program structure, in Brooklyn L. Rev. 1998, 519.

KENNEDY, A primer on open source licensing legal issues: copyright, copyleft and copyfuture, in St. Louis L. Rev 2001, 368.

LEA, La lobby dei brevetti gioca d'anticipo sull'Unione Europea , http://www.theregister.co.uk/content/1/14305.html

LEHMANN, La tutela dei programmi per computer in Germania. Un profilo attuale, in Foro it. 1988, V, 527.

LEHMANN, The new software contract under european and german copyright law – Sale and licensing of computer programs, in IIC 1994, 46.

LENER, La nuova disciplina delle clausole vessatorie nei contratti dei consumatori, in Foro it. 1996, V, 146.

LEONE, La concessione del software tra licenza e locazione, in ALPA e ZENO ZENCOVICH, I contratti d’informatica, Giuffrè, Milano, 1986, 349.

LESSIG, Open code and open societies: values of internet governance, in Chicago-Kent L. Rev. 1999, 1405.

LESSIG, The limits in open code: regulatory standards and the future of the Net, in Berkeley Tech. L. Journ . 1999, 759.

LESSIG, The architecture of innovation, in Duke L. Journ . 2002, 1783.

LIN, SAG e LAURIE, Source code versus object code: patent implications for the open source community, in St. Clara computer & high tech. L. Journ., 2002, 235. ��

LUZZATTO Ett., Una norma francese da non imitare, in Riv. dir. ind. 1968, I, 297.

LUZZATTO Ett. e RAIMONDI, Patentability of software, particularly in the european legislation, in Riv. dir. ind. 1981, I, 65.

MAURO SANTO

56

MAHER, Open source: the success of an alternative intellectual property incentive paradigm, in Fordham Intell. Prop., Media & Entert. L.. Journ. 2000, 620.

MCCULLOUGH, Understanding the impact of the DMCA on the open source model of software development, in Marquette Intell. Prop. L. Rev. 2002, 91.

MCGOWAN, Legal implications of open source software, in Illinois L. Rev. 2001, 241.

MCJOHN, Paradoxes of free software, in George Mason L. Rev. 2000, 25.

MCKUSICK, Vent’anni di Unix a Berkeley: dalla AT&T alla ridistribuzone gratuita, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 31.

MENGOZZI, La nozione di consumatore, la direttiva CEE 93/13 ed il diritto italiano, in Contr. e impr. Europa 2002, I, 55.

MEZRICH, Source code escrow: an exercise in futility?, in Marquette intell. prop. L. Rev., 2001, 117.

MIRABELLI, Modelli, tipicità, collegamento , in ALPA e ZENO ZENCOVICH, I contratti d’informatica , Giuffrè, Milano, 1986, 11.

MOGLEN, Anarchism triumphant: free software and the death of copyright, in First Monday, peer-reviewed journal on the internet 1999, IV, ed in http://moglen.law.columbia.edu/publications/anarchism-it.html

MOGLEN, Enforcing the gpl, http://moglen.law.columbia.edu/publications/lu-12.html

MOGLEN, Why the FSF gets copyright assignments from contributors, http://www.gnu.org/ copyleft/why-assign.html

MORGAN, Chaining open source software: the case against software patents, http://lpf.ai.mit.edu/Patents/chaining-oss.html

MUSSO, Contenuto del diritto – elaborazioni creative del software e programmi derivati, in L.C.UBERTAZZI, La legge sul software, commentario sistematico , Giuffrè, Milano, 1994, 62.

MUSTI, Il contratto di ‘licenza d’uso’ del software, in Contr. e impr. 1998, 1289.

NADAN, Open source licensing: virus or virtue?, in Texas Intell. Prop. L. Journ. 2002, 349.

OLD, Patenting computer-related inventions in Australia , in IIC 1993, 345.

OPPO, Creazione ed esclusiva nel diritto industriale, in Riv. dir. comm. 1964, I, 187.

OROFINO, Open source e pubblica amministrazione, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1317.

PARDOLESI, Software, property rights e diritto d’autore: il ritorno dal paese delle meraviglie, in Foro it. 1987, II, 289.

PARDOLESI, Software di base e diritto d’autore: una tutela criptobrevettuale?, in Foro it. 1988, I, 3133.

PATTERSON, Copyright misuse and modified copyleft: new solutions to the challenges of internet standardization, in Mich. L. Rev. 2000, 1351.

PERENS, La Open Source Definition, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 185.

MAURO SANTO

57

PERRI, I sistemi di licenza open source, in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1088.

PLAIA, Un’improbabile ipotesi di “licenza” d’uso di software, in AIDA 2001, 782.

POTTER, Opening up to open source, in Richmond Journ . Law & Tech. 2000, 24.

POWELL, Judgment day for the GPL? Determining the legality of the GPL, http://www.linuxplanet.com/linuxplanet/reports/2000/1/html

RAYMOND, La cattedrale ed il bazaar, http://www.tuxedo.org/~esr/writings/ cathedral-bazaar/ cathedral-bazaar.html;

RAYMOND, Homesteading the noosphere, http://www.tuxedo.org/~esr/writing/ homesteading/homesteading.html

RICOLFI, Il diritto d’autore, in AUTERI, FLORIDIA, MANGINI, OLIVIERI, RICOLFI e SPADA, Diritto industriale, proprietà intellettuale e concorrenza, Giappichelli, Torino, 2001, 388.

RINALDI, Considerazioni in tema di direttiva comunitaria sul software ed applicabilità degli artt. 85 e 86 del trattato di Roma alle licenze di software, in Riv. dir. ind. 1993, I, 217.

RINALDI, La tutela del software nel dlgs. 518/1992, in Dir. inf. 1994, 259.

RISTUCCIA e ZENO ZENCOVICH, Il software nella dottrina, nella giurisprudenza e nel dlgs. 518/92 , CEDAM, Padova, 1993.

RISTUCCIA e ZENO ZENCOVICH, Prime notazioni sulla legge a protezione del software, in Dir. inf. 1994, 233.

ROPPO e NAPOLITANO, Clausole abusive, in Enc. Giur. Trecc., VI, Roma, 1994, 1.

ROSENBERG, Open source software licensing page, http://www.stromian.com

ROSSATO, Diritto architettura e software libero , http://portal.lobbyliberal.it/ article/articleview/134/1/19/html

ROSSELLO, I contratti dell’informatica nella nuova disciplina del software, Giuffrè, Milano, 1997.

ROWLAND e CAMPBELL, Supply of software: copyright and contract issues, in Int. Journ. Law & IT 2002, 23.

SAMUELSON, DAVIS, KAPOR e REICHMAN, A manifesto concerning the legal protection of computer programs, in Columbia. L. Rev.�1994, 2308.

SANDRI, I contratti di licenza in Italia, in Riv. Dir .Ind. 1996, I, 43.

SARTI, Contenuto del diritto – esaurimento ed utilizzazione del software, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 129.

SARTI, Circolazione dei beni e diritti esclusivi, Giuffrè, Milano, 1996.

SARTI, sub art.10 l.a., in MARCHETTI e L.C.UBERTAZZI, Commentario breve al diritto della concorrenza , CEDAM, Padova, 1998.

SENA, Brevetto e monopolio, in Riv. dir. ind. 1963, I, 287.

MAURO SANTO

58

SENA, Brevetto per invenzioni industriali, in Dig. comm, II, UTET, Torino, 1987, 338.

SENA, I diritti sulle invenzioni e sui modelli industriali, 3ed., Giuffrè, Milano, 1990.

SENA, Opere dell’ingegno, in Dig. comm., X, UTET, Torino, 1994, 362.

SIROTTI GAUDENZI, La tutela del diritto d’autore e del software nella società dell’informazione, inedito, 2002.

STALLMAN, Il progetto GNU, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 57.

STALLMAN, Permesso d’autore: idealismo pragmatico, http://www.gnu.org/ philosophy/pragmatic.it.html

STOUT, La brevettabilità del software nella più recente giurisprudenza americana, in Dir. Inf. 1986, 78.

STRASSER, A new paradigm in intellectual property law?: the case against open sources, in Stanf. Tech. L. Rev. 2001, 4.

TAVASSI, Orientamenti giurisprudenziali in ambito comunitario e nazionale in tema di esaurimento dei diritti di proprietà industriale, in Contr. e impr. Europa 2000, 781.

TESTA, Durata del diritto, in L.C.UBERTAZZI, La legge sul software, commentario sistematico, Giuffrè, Milano, 1994, 41.

TORVALDS, Il vantaggio di Linux, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 111.

TOSI, Licenza d’uso e vendita di copia di software alla luce del dlgs. 518/92 , in Arch. Civ. 1994, 685.

UBERTAZZI L.C., Invenzione e innovazione, Giuffrè, Milano, 1978.

UBERTAZZI L.C. e AMMENDOLA, Diritto d’autore, in Dig. comm., IV, UTET, Torino, 1989, 366.

UBERTAZZI L.C., Diritto d’autore I – introduzione, in Dig. comm., IV, UTET, Torino, 1989, 367.

UBERTAZZI L.C., La protezione dl software nei rapporti italo tedeschi, in IDA 1991, 347, ed in L.C.UBERTAZZI, I diritti d’autore e connessi, Giuffrè, Milano, 2000, 361.

UBERTAZZI L.C., Soggetti del diritto , in L.C.UBERTAZZI, La legge sul software, commentario sistematico , Giuffrè, Milano, 1994, 23.

UBERTAZZI L.C., I diritti d’autore e connessi - Scritti, Giuffrè, Milano, 2000.

ULMER e KOLLE, Copyright protection of computer programs, in IIC 1983, 159.

VANZETTI e DI CATALDO, Manuale di diritto industriale, 3ed., Giuffrè, Milano, 2002.

WHEELER, Why open source software/free software? Look at numbers!, in http://www.dwheeler.com/oss_fs_why.html

YOUNG, Regalato! Come Red Hat Software si trovò fra le mani un nuovo modello economico e contribuì a migliorare un’industria, in DI BONA, OCKMAN e STONE, Open sources, voci dalla rivoluzione open source, Apogeo/O’Reilly, Milano, 1999, 123.

ZAWINSKY, The Lemacs/Fsf macs schism, http://www.jwz.org/doc/lemacs.html

MAURO SANTO

59

ZENO ZENCOVICH, L’apprendista stregone: il legislatore comunitario e la proposta di direttiva sui programmi per elaboratore, in Dir. inf. 1990, 77.

ZICCARDI, Open Source e libertà del codice, in CASSANO, Diritto delle nuove tecnologie informatiche e dell’internet, IPSOA, Milano, 2002, 1067.

ZINCONE, Come prevenire le problematiche inerenti alla utilizzazione del software, in IDA 1996, IV, 393.

ZWEIGERT e KOTZ, Introduzione al diritto comparato I, Giuffrè, Milano, 1998.

MAURO SANTO

60

DOCUMENTI

GNU General Public License, version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software, to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it (some other Free Software Foundation software is covered by the GNU Library General Public License instead). You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, wewant its recipients to know that what they have is not the original, sothat any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by softwarepatents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. Terms and conditions for copying, distribution and modification 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program"means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

MAURO SANTO

61

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program,and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code (this alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above). The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attemptotherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties tothis License.

MAURO SANTO

62

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of anysuch claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. 11. Because the program is licensed free of charge, there is no warranty for the program, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright thr copyright holders and/or other parties provide the program “as is” without warranty of any kind , either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction. 12. In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or reistribute the program as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the program to operate with any other programs), even if such holder or other party has been advised of the possibility of such damages.