Authors Carlo Piana Simone Aliprandi
License CC-BY-SA-3.0
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 79 — #79
i i
Informatica e diritto, XXXVIII Annata, Vol. XXI, 2012, n. 1, pp. 79-96
Il Free and Open Source software
nell’ordinamento italiano: principali problematiche giuridiche
SIMONE ALIPRANDI, CARLO PIANA∗
SOMMARIO: 1. Introduzione – 2. FOSS e princìpi di diritto d’autore – 2.1. Premesse –
2.2. La qualificazione giuridica del FOSS secondo il diritto d’autore – 2.3. Diritti dei
co-autori – 2.4. I diritti morali – 3. L’enforcing delle licenze FOSS – 4. Clausole di
esonero di responsabilità – 5. Il meccanismo del copyleft – 5.1. Come funziona – 5.2.
Validità della clausola copyleft – 6. Danni civili e FOSS – 7. Letteratura scientifica
di riferimento
1. INTRODUZIONE
Il Free and Open Source Software - FOSS è uno dei fenomeni più interes-
santi del mondo delle tecnologie e che più di altri ha cambiato il modo di
intendere l’innovazione e di gestire il lavoro di progettazione e sviluppo di
soluzioni informatiche. Come tutti i fenomeni innovativi, che si distinguo-
no per la loro effettiva novità e continua evoluzione, crea spesso alcuni pro-
blemi di inquadramento da parte della scienza giuridica, la quale – per defini-
zione – ha un fisiologico ritardo rispetto all’evoluzione tecnologica nonché
rispetto ai modelli di business e alle prassi sociali.
L’effetto è che questo fenomeno, pur essendo attualmente giunto a quasi
tre decenni di vita, non gode di interpretazioni univoche e sufficientemente
chiare, complice la penuria di casi giurisprudenziali consistenti da cui pren-
dere spunto. Lo scopo di questo articolo è proprio quello di far luce sul-
le principali problematiche giuridiche emergenti, analizzando il FOSS sul-
la scorta dei princìpi del diritto d’autore e del diritto civile in generale, ed
indicando infine la letteratura scientifica più rilevante in materia di aspetti
giuridici del FOSS.
∗ S. Aliprandi è dottore di ricerca in Società dell’Informazione, avvocato esperto
di diritto d’autore e più in generale di diritto dell’ICT. C. Piana, è avvocato esper-
to di diritto delle tecnologie; è membro del network Array e fondatore della ri-
vista International Free and Open Source Software Law Review. Licenza di questo
articolo: Creative Commons Attribuzione – Condividi allo stesso modo 3.0 Italia
(http://creativecommons.org/licenses/by-sa/3.0/it/legalcode).
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 80 — #80
i i
80 Informatica e diritto / Studi e ricerche
2. FOSS E PRINCÌPI DI DIRITTO D’AUTORE
2.1. Premesse
Il diritto d’autore (e il suo corrispondente anglo-americano copyright) è lo
strumento giuridico per eccellenza posto a tutela dell’attività creativa, quale
particolare espressione del lavoro intellettuale1 .
L’elemento fondante di questo specifico istituto è dunque rappresentato
dall’individuazione di un atto creativo originale. Buona parte delle proble-
matiche che il FOSS incontra in materia di diritto d’autore sono proprio
legate alla difficoltà di individuare e tenere traccia di tutti gli apporti creati-
vi, specie quando si tratta di progetti particolarmente grandi e con una lunga
storia.
Infatti, anche se il FOSS può essere scritto da una sola persona o essere
nella titolarità di un soggetto giuridico unico2 , dopo qualche tempo esso
diventa il risultato del lavoro di molti autori che possono rivendicare diritti
su di esso.
Il dubbio è se le parti aggiunte in seguito vadano a creare un’opera col-
laborativa (un’opera creata da più autori in collaborazione), o se il software
originale è il risultato finale e ogni contributo apportato durante le varie fasi
di sviluppo sia di per sé un’opera derivata. Le conseguenze giuridiche sono
differenti a seconda dei casi.
Bisogna inoltre precisare che, al contrario di quanto avviene negli ordina-
menti di common law, la legge italiana non parla di “opere derivate”, ma più
propriamente di “elaborazioni creative”.
Può essere solo una sfumatura, ma a fini della presente argomentazione
è utile riprendere la definizione di elaborazione creativa fornita dall’art. 4
della legge sul diritto d’autore (LDA), il quale recita: “Senza pregiudizio dei
diritti esistenti sull’opera originaria, sono altresì protette le elaborazioni di
carattere creativo dell’opera stessa, quali le traduzioni in altra lingua, le tra-
sformazioni da una in altra forma letteraria o artistica, le modificazioni ed
aggiunte che costituiscono un rifacimento sostanziale dell’opera originaria,
gli adattamenti, le riduzioni, i compendi, le variazioni non costituenti opera
originale”.
1
Si veda l’art. 6 della legge italiana sul diritto d’autore (l. 22 aprile 1941, n. 633, d’ora in
poi LDA.
2
In genere l’autore originale, un suo avente causa per un atto di trasferimento o in via
originale, come nel software sviluppato dai dipendenti (art. 12 bis LDA) o sviluppato for hire
sulla base di un contratto di sviluppo software.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 81 — #81
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 81
2.2. La qualificazione giuridica del FOSS secondo il diritto d’autore
Un’opera FOSS può essere considerata un’opera collaborativa, un’opera
composta o un’altra tipologia complessa di opera, e ogni singola versione del
software può essere classificata in modo diverso a seconda di come si è svolto
il processo di sviluppo.
Lo scenario più semplice è quello in cui è il software è stato realizzato
dall’autore A, ripreso dall’autore B e poi dall’autore C. A, B e C hanno tutti
modificato ed esteso il software. Si tratta di uno sforzo collettivo, ma tec-
nicamente è costituito da una serie di opere derivate, ognuna delle quali è
copyright del rispettivo autore; ed ogni singolo autore si avvale del permesso
di modificare il software ottenuto da chi lo ha preceduto nella “catena” dello
sviluppo (ovvero da chi, idealmente, sta a monte del processo di sviluppo).
Tuttavia, lo scenario è solitamente più complesso, allorché i contributi dei
singoli autori sono inseriti nel prodotto tramite specifici sistemi di gestione
del codice, che inevitabilmente influiscono sulle modalità d’interazione tra
gli autori.
Mentre la prima versione del software, se scritta da più persone, può
in molti casi essere qualificata come un’opera collaborativa in cui i diver-
si contributi sono indistinguibili, non sempre si può dire la stessa cosa per
le versioni successive: esse infatti sono comunque basate sull’opera origina-
ria, ma non vi è un’effettiva “consultazione” tra gli autori né alcuna forma
di coordinamento nel lavoro creativo. Le versioni successive così realizzate
saranno quindi qualificate più opportunamente come opere derivate. Per-
tanto, in termini di conseguenze legali, va fatta una distinzione tra i diritti
dei co-autori originari e i diritti delle persone che subentrano nello sviluppo
successivamente.
Secondo un’autorevole dottrina, questo modo di lavorare rappresenta
una “opera composta”, in altre parole un’opera in cui “[...] i singoli con-
tributi conservano una propria autonomia che li rende suscettibili di utiliz-
zazione separata, e pur tuttavia si configurano, nel risultato finale della col-
laborazione, come elementi essenziali di un insieme organico ove le attività
creative dei vari soggetti si esprimono direttamente e solidalmente dando
origine ad un effetto artistico unitario”3 .
Bisogna però notare che questa definizione è orientata più che altro verso
opere artistiche (come i film) in cui i contributi sono di natura diversa (di-
rezione, ideazione del soggetto, stesura della sceneggiatura, musiche, ecc.),
3
Così L.C. UBERTAZZI, Voce Diritto d’autore, in “Digesto”, IV ed., Torino, Utet, 1989.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 82 — #82
i i
82 Informatica e diritto / Studi e ricerche
mentre nel mondo della programmazione software i contributi sono per la
maggior parte della stessa natura.
2.3. Diritti dei co-autori
A meno che i componenti del software possano essere chiaramente distin-
ti e separati, il software creato in maniera collaborativa è solitamente consi-
derato una “opera indivisibile”4 . Si tratta di opere per cui non può essere
stabilito con certezza quale sia il contributo individuale di ogni autore, co-
me avviene per esempio quando due autori scrivono un testo o una musica
insieme. Nel caso di un’opera software che appunto sia opera indivisibile,
i co-autori sono liberi di disciplinare l’esercizio dei diritti d’autore con una
certa libertà e normalmente si accordano su come il software debba esser
reso pubblico (ad esempio sotto forma di FOSS) e su come prendere le de-
cisioni relative ai diritti d’autore (per esempio con votazione a maggioranza
semplice o qualificata, o attribuendo ad uno di essi il diritto di prendere
tutte le decisioni riguardo all’opera, con limitazione agli atti di ordinaria
amministrazione5 ).
Se i co-autori non hanno raggiunto un accordo su come debbano essere
prese le decisioni, si fa riferimento alle norme stabilite dagli articoli 1100-
1116 del Codice civile in materia di comunione. La regola principale è che
ogni atto che non comporta la cessione del diritto d’autore e che non im-
pedisce ai co-titolari di esercitare i loro diritti è di per sé consentito; ma gli
atti di “amministrazione straordinaria” devono essere votati e approvati con
le maggioranze previste dalla legge o concordate dalle parti. Le parti in di-
saccordo possono comunque opporsi in sede giudiziale alle decisioni della
maggioranza6 . Altro principio importante è quello posto dall’art. 10 LDA,
secondo cui, salvo prova contraria fornita per iscritto, le parti indivise si
presumono di valore uguale.
2.4. I diritti morali
La presenza e l’enforcing dei diritti morali potrebbero avere un effetto ab-
bastanza deleterio sul sistema del FOSS; basti pensare ad esempio che secon-
4
Le opere indivisibili sono regolamentate dall’art. 10 della legge sul diritto d’autore, il
quale fa espresso riferimento alle norme sulla comunione (artt. 1100 e ss., c.c.).
5
Art. 1106 c.c.
6
Art. 1109 c.c.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 83 — #83
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 83
do la maggior parte delle licenze FOSS è vietato l’inserimento di restrizioni
relative all’ambito di applicazione/utilizzo dell’opera. Per capire meglio i
punti di attrito che il sistema dei diritti morali previsto dalla legge italiana
può avere sul FOSS, ne riprendiamo brevemente i capisaldi teorici.
Per quanto riguarda i diritti posti dall’art. 20 LDA, mentre il diritto di
rivendicare la paternità non solleva particolari problemi pratici, il diritto di
opporsi a qualsiasi deformazione è stato a volte indicato come una possibi-
le restrizione al funzionamento di una licenza FOSS, visto che l’autore in
qualsiasi momento potrebbe di fatto revocare proprio il permesso a modifi-
care il programma, in contraddizione con le disposizioni della licenza FOSS.
Tuttavia, da un lato questo diritto è limitato ad alterazioni molto pesanti
dell’opera, che per altro devono essere dannose per l’onore o la reputazione
dell’autore. Inoltre, ai sensi dell’art. 22, se l’autore è a conoscenza delle mo-
difiche (e le accetta anche implicitamente) non ha più possibilità di opporsi a
loro. Ed è proprio questo principio a rivelarsi centrale in merito all’applica-
zione del diritto morale ex art. 20 nel mondo FOSS; infatti, come fa notare
Di Rienzo, “in dottrina si è giustamente ritenuto che tale autorizzazione può
essere anche concessa in via preventiva, sebbene ciò non escluda un ripensa-
mento dell’autore laddove si verifichino i presupposti indicati dall’art. 20,
secondo comma”7 .
Un ulteriore diritto morale che può creare problemi al sistema del FOSS
è il diritto di ritirare l’opera dal commercio quando esistono gravi ragioni
morali previsto dall’art. 142 LDA. Questa disposizione ha lo stessa ratio di
quella di cui all’art. 20, e ancora una volta riflette il fatto che un autore può
avere un elevato coinvolgimento morale con le sue opere, così che la loro di-
stribuzione possa risultare seriamente pregiudizievole alla sua reputazione.
Quindi potremmo sostenere che il diritto di ritirare l’opera non si applica
al FOSS per le stesse ragioni che abbiamo presentato per l’art. 20. In ogni
caso, la necessità di indennizzare i titolari dei diritti (compresi i licenziatari),
che verrebbero danneggiati dal ritiro dell’opera, nonché la complessa pro-
7
M. DI RIENZO, L’organizzazione dei mondi open source: profili soggettivi, in “AIDA”,
Vol. 13, 2004, parte I, p. 39. Alla stessa pagina si legge anche: “Se però a queste considerazioni
si aggiunge quanto già affermato circa la minore (ma non assente) rilevanza dei profilo della
tutela del diritto morale d’autore in riferimento ai programmi per elaboratori, si apre una
prospettiva interessante che permette di ritenere, a priori, compatibili (alcune del) le licenze
open source con il diritto morale all’integrità dell’opera rilasciata sotto il corrispondente regi-
me libertario, a condizione che la licenza in questione imponga di mantenere distinta l’opera
dell’autore originario da quella del successivo elaboratore”.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 84 — #84
i i
84 Informatica e diritto / Studi e ricerche
cedura prevista dal legge, relega questa ipotesi alla sfera del mero esercizio
intellettuale, senza quindi conseguenze pratiche.
Nei gruppi di discussione in rete si possono trovare argomentazioni a
favore dell’applicazione dei diritti morali al fine di opporsi ad utilizzi del
software in campo militare o legati all’energia nucleare, anche se questa posi-
zione contrasta con le fondamentali libertà di utilizzare il software per qual-
siasi uso (compresi quelli moralmente discutibili) e di migliorare e adattare
il software (che consente a chiunque di apportarvi modifiche e adattarlo per
ogni esigenza). Se questi cambiamenti sono fatti per portare un’applicazione
verso un campo di utilizzo che può influenzare la reputazione o la morale
dell’autore originale, si può sostenere che ciò potrebbe innescare l’uso del
diritto morale e consentire di opporsi a tali modifiche del lavoro.
Non vi è alcun caso noto in Italia si occupi dell’applicazione di tali diritti
al software, ma solo dottrina.
Molti autori sono inclini a pensare che, non essendoci una deroga spe-
cifica relativa al software, e trattandosi di regole di applicazione generale, le
norme sui diritti morali devono comunque applicarsi anche al software. Ma
questa argomentazione non sembra del tutto convincente. La ratio dei diritti
morali è infatti quella di proteggere la sfera più personale dell’autore, il quale
fa rivivere il suo “spirito” nelle sue opere d’arte; non si può negare che que-
sto aspetto si avverte molto meno in un’opera di natura tecnico-funzionale
come il software. Lo stesso dicasi per il diritto sui generis per i database.
In una certa misura i diritti morali dell’autore ricevono un maggior con-
temperamento in una particolare categoria di opere denotate da una forte
componete “utilitaristica” rispetto a quella strettamente autorale: è il caso
ad esempio delle opere architettoniche. Si rinviene già nel diritto positivo,
dunque, un’importante eccezione alla supposta sacralità del diritto morale.
Inoltre, dal momento che le disposizioni della legge italiana sul diritto
d’autore sono formalmente il recepimento di una direttiva europea per l’ar-
monizzazione del mercato interno, si può sostenere che, siccome l’applica-
zione dei diritti morali al software è oggettivamente disomogenea rispetto a
quanto avviene in molti altri stati, un tale impedimento all’armonizzazione
– che potrebbe pregiudicare lo sfruttamento delle opere software – si con-
cretizza in una norma “eccezionale” rispetto al diritto europeo comune e
dovrebbe ricevere un’interpretazione restrittiva.
Tutto ciò fa ritenere che un’interpretazione corretta e formale delle nor-
me in questione escludano per la maggior parte che al software si applichino
i diritti morali d’autore, se non – in modo e misura da ricercarsi caso per ca-
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 85 — #85
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 85
so – quello di essere riconosciuto autore dell’opera. Sarebbe auspicabile un
intervento normativo chiarificatore8 .
3. L’ENFORCING DELLE LICENZE FOSS
Nonostante l’assenza di precedenti giurisprudenziali, non c’è motivo di
dubitare che una licenza FOSS sia valida e difendibile in Italia, salvo casi
marginali9 .
Indipendentemente che si consideri la licenza FOSS un contratto o un
mero permesso di copyright10 , il diritto d’autore può essere considerato una
privativa che previene l’utilizzo del software da parte di soggetti non autoriz-
zati. La fonte di autorizzazione all’utilizzo dell’opera sta nella licenza stessa;
e dunque l’assenza di una licenza rimuoverebbe tutti gli argomenti avanzati
dal violatore del diritto d’autore allo scopo di invalidare la licenza e dunque
di utilizzare il software secondo quanto desiderato.
In altre parole, in un caso di enforcement di licenza FOSS il presunto re-
sponsabile della violazione non può invocare la nullità della licenza e allo
stesso tempo sostenere che l’uso dell’opera era legittimo perché autorizzato
dalla stessa licenza, a meno che non vi sia un’altra base giuridica che permet-
ta a questo violatore di utilizzare il software. Per esempio, se il violatore so-
stiene che l’obbligo di rilasciare il codice sorgente modificato è inapplicabile
perché, ad esempio, la GNU GPL è nulla, dato che questa è una condizio-
ne per l’utilizzo del software inserita nella stessa licenza GNU GPL, questo
argomento diviene inutilizzabile, perché porterebbe a sostenere che l’uso da
parte del presunto autore della violazione non era consentito del tutto.
Ma cosa dire a proposito della pretesa di eseguire forzosamente una vera e
propria obbligazione positiva (nel senso di obbligo di fare o di dare)? Come
nell’esempio di cui sopra, è possibile costringere all’esecuzione in forma spe-
cifica dell’obbligazione di divulgare il codice sorgente modificato allorché il
presunto contraffattore si sia rifiutato di eseguire tale obbligo.
8
Come si sostiene in http://piana.eu/laws.
9
Vale lo stesso tipo di argomentazione emersa dal caso tedesco Welte vs. Skype Techno-
logies SA, riportato in Groklaw all’indirizzo http://www.groklaw.net/article.php?story=
20080508212535665.
10
A tal proposito si veda C. PIANA, Licenze pubbliche di software e contratto, in “I Con-
tratti”, 2006, n. 7, pp. 720-727; disponibile online su http://www.piana.eu/repository/720_
727.pdf.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 86 — #86
i i
86 Informatica e diritto / Studi e ricerche
In teoria, un licenziatario potrebbe essere costretto a fare qualcosa che è
previsto da un obbligo contrattuale. Questo in generale è possibile, come
suggerito dall’art. 2931 c.c. Per sfruttare tale disposizione, deve sussistere
un obbligo positivo (di fare o dare qualcosa); mentre non è sufficiente la sola
presenza di una semplice condizione. La maggior parte delle licenze FOSS
prevede solo semplici condizioni che devono essere soddisfatte al fine di con-
sentire le quattro libertà tipiche del modello FOSS, e anche le clausole di
copyleft si atteggiano più come condizioni (puoi fare X a condizione che tu
faccia anche X) che come veri e propri obblighi. Pertanto è difficile, e non
necessario, individuare un obbligo contrattuale. Ci sono però eccezioni a
questa constatazione. Vengono in mente due esempi: le licenze brevettuali
automatiche (o implicite, o forzose)11 e le clausole di non responsabilità.
Le licenze automatiche di brevetto prevedono che chi contribuisce allo
sviluppo del software (e a volte anche il distributore, come accade nella GNU
General Public License v.312 ) provveda a dotare esplicitamente tutti i desti-
natari del software “a valle” di una licenza di brevetto mondiale a costo zero
per i brevetti che detiene o che controlla in qualsiasi modo.
Questo obbligo è – in senso atecnico – un effetto positivo della licenza.
Tuttavia, non si tratta di un effetto immediato della licenza ricevuta, per cui
ogni atto di modifica, seguita o non seguita da una successiva distribuzione,
comporterebbe un’automatica licenza di brevetto, ovvero un obbligo giudi-
zialmente eseguibile in via forzosa (art. 2932 c.c.). Una licenza automatica
avviene solo come risultato di una successiva distribuzione (“conveyance”
nella tassonomia della GPL v.3) del software sotto quella stessa licenza pub-
blica che lo prevede. Il che è un atto separato di licenziamento del software
modificato.
Per capire meglio le conseguenze di tale distinzione, se il software fosse
distribuito sotto una licenza diversa, vi sarebbe una violazione del copyright
dell’opera originale, ma non vi sarebbe una licenza implicita del brevetto.
In effetti, senza distribuzione, non sussiste la licenza di brevetto, e lo stesso
atto di concessione della licenza di brevetto è concepito non come un obbli-
go di concedere, ma come una concessione diretta incorporata nella licenza
utilizzata.
Allo stesso modo, tutte le licenze prevedono una esclusione di responsa-
bilità. Tale esclusione, ancora una volta, non è un obbligo, ma un effetto
11
Come nella Mozilla Public License.
12
Si veda la Section 11 della licenza.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 87 — #87
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 87
della licenza, o una rinuncia. Questo è un punto fondamentale e deve essere
affrontato più in profondità.
4. CLAUSOLE DI ESONERO DI RESPONSABILITÀ
Tipicamente le licenze FOSS contengono esoneri di responsabilità molto
forti13 . La ragione di questa scelta è che il FOSS è spesso reso disponibile
senza un compenso monetario di alcun genere, di conseguenza l’autore ot-
tiene da tale attività un reddito insufficiente a munirsi di assicurazioni sulla
responsabilità civile e a coprire i rischi legali connessi14 .
Nell’ambito dell’ordinamento italiano si pone un primo problema. Ai
sensi dell’art. 1229 del Codice civile, non si possono prevedere clausole di
esclusione della responsabilità che abbiano l’effetto di escludere la responsa-
bilità per dolo o colpa grave. Eventuali disposizioni contrarie sono nulle (an-
che se il contratto nella sua interezza può rimanere valido). Tale nullità può
essere dichiarata d’ufficio senza una specifica richiesta delle parti (art. 1421
c.c.), ma deve essere comunque funzionale ad una richiesta avanzata in giudi-
zio dalle parti. Pertanto, le disposizioni delle licenze sono nulle quando so-
no mirate ad escludere incondizionatamente tutte le forme di responsabilità
(senza preoccuparsi di tale distinzione).
Tuttavia, la nullità non si estende alle parti del contratto che invece non
sono affette da nullità (art. 1429 c.c.) e, in ogni caso, le clausole che dovreb-
bero essere considerate nulle possono comunque essere convertite in clauso-
le diverse con effetti simili, così da ricreare la volontà delle parti se fossero
state a conoscenza della nullità (art. 1424 c.c.). Tutte queste regole dovreb-
bero essere lette alla luce del fatto che la licenza molto probabilmente è da
considerare come un atto unilaterale (art. 1424 c.c.) più che un contratto
sinallagmatico.
13
Si veda ad esempio la BSD license disponibile al sito http://www.opensource.org/
licenses/bsd-license: “This software is provided by copyright holder ‘as is’ and any express
or implied warranties, including, but not limited to, the implied warranties of merchantabi-
lity and fitness for a particular purpose are disclaimed. in no event shall copyright holder be
liable for any direct, indirect, incidental, special, exemplary, or consequential damages (in-
cluding, but not limited to, procurement of substitute goods or services; loss of use, data, or
profits; or business interruption) however caused and on any theory of liability, whether in
contract, strict liability, or tort (including negligence or otherwise) arising in any way out of
the use of this software, even if advised of the possibility of such damage.”
14
A tal proposito si legga B. PERENS, The Open Source Definition, disponibile online su
http://oreilly.com/catalog/opensources/book/perens.html.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 88 — #88
i i
88 Informatica e diritto / Studi e ricerche
Qualora il disclaimer dovesse essere inefficace, ci si chiede se, secondo il
diritto italiano, lo sviluppatore di software potrebbe essere ritenuto respon-
sabile per i danni causati dal suo software, alla luce del fatto che il suo software
è rilasciato gratuitamente (sotto licenza FOSS). A parte i casi di dolo e col-
pa grave, o di responsabilità extracontrattuale, la risposta sembra negativa.
D’altronde, sul piano contrattuale è impossibile determinare una responsa-
bilità. Una licenza altro non è che un permesso; pertanto, non impone allo
sviluppatore alcun obbligo di fornire alcunché.
Supponiamo che qualcuno voglia incorporare il software in un prodotto
più ampio per un particolare scopo, ma che il software non sia adatto a ciò.
Colui che intende incorporare è quindi autorizzato a fare tutte le modifiche,
tra cui gli adattamenti e le attività di collaudo sulla qualità, al fine di assicu-
rarsi che la combinazione tra le due opere funzioni. In altre parole, è colui
che compie il lavoro di integrazione a doversi assicurare che le specifiche del
software rispondano a quanto da lui desiderato.
C’è una differenza notevole tra questo caso e una licenza di software pro-
prietario. Nelle licenze proprietarie vi è uno scambio di un prezzo o un’al-
tra utilità economica contro la consegna del software o addirittura il semplice
permesso di usare il software. Si tratta di una vendita (art. 1471 c.c.). Trattan-
dosi di una vendita15 , la cosa comporta alcune garanzie legali, tra cui quella
che il prodotto sia esente da difetti che riducano la sua idoneità all’uso a cui è
destinato (art. 1490 c.c.). Ma lo stesso principio non può essere applicato al
FOSS, che non è “venduto” – a meno che ci sia un accordo separato su quella
particolare porzione di codice – ma solo offerto liberalmente per il suo sfrut-
tamento da parte di chiunque. Se c’è un accordo separato, come ad esempio
un accordo di sviluppo software, il rapporto tra il cliente e lo sviluppatore (in
particolare la responsabilità in caso di software difettoso) è regolato da quel
contratto specifico, e non dalla licenza.
Non si può nemmeno individuare una forma di responsabilità sulla ba-
se delle norme sulla responsabilità da prodotto. In assenza di un vincolo
contrattuale ulteriore rispetto alla licenza, lo sviluppatore non può ragione-
15
A tal proposito vi sono posizioni contrastanti. A nostro parere la teoria secondo cui
la licenza d’uso del software sia una forma di locazione non ha pregio alcuno. Lo scambio
è infatti a titolo definitivo e dietro un corrispettivo unico (salvo che in concreto lo scambio
non sia in effetti congegnato come una locazione, ma non è sufficiente imporvi il nomen iuris
per farla diventare “locazione”, perché l’interprete non è ovviamente vincolato alla qualifica-
zione delle parti, occorre fare riferimento alle previsioni contrattuali in concreto). Oggetto
di questa vendita è il diritto di utilizzare una o più copie determinate secondo alcuni criteri.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 89 — #89
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 89
volmente essere considerato il “fornitore”. In ogni caso, tale limitazione di
responsabilità sarebbe stata nulla fin dall’inizio se le norme sulla responsa-
bilità del produttore fossero considerate applicabili (art. 124 del Codice del
consumo), dunque la discussione non sembra avere effetti sullo specifico te-
ma della clausola limitativa della responsabilità (anche se la conseguenza è
tutt’altro che irrilevante di per sé).
Anche una responsabilità civile per atto illecito sarebbe difficile da rin-
venire e l’onere della prova sarebbe interamente dell’attore. L’art. 1227 del
Codice civile prevede infatti che il risarcimento non sia dovuto quando il
danno avrebbe potuto essere evitato con l’ordinaria diligenza. Ad ogni mo-
do, deve essere prima stabilito che il danno sia stato causato da un atto il-
lecito (cioè un atto contro la legge e in conflitto con la condotta attesa da
un soggetto medio). Ora, lo “scambio” tra lo sviluppatore e l’utente è co-
sì rappresentabile: “io ti concedo le varie libertà, ma tutto ciò che ottieni
è codice, non un prodotto finito; quindi sappi che non ti garantisco nulla”.
È cosa generalmente conosciuta che, siccome lo scambio è gratuito, non vi
è responsabilità (sempre salvo il caso di colpa grave) a meno che sia previ-
sta espressamente una forma di garanzia16 . Tutto ciò rende particolarmente
difficile individuare un caso di responsabilità civile dotato di una certa consi-
stenza, e in ogni caso non ci sono formule contrattuali preconfezionate che
lo potrebbero impedire, soprattutto perché l’art. 1225 del Codice civile li-
mita la responsabilità a quanto avrebbe potuto ragionevolmente prevedersi
quando è sorta l’obbligazione (o il fatto illecito, in questo caso).
Resta infine da considerare l’evenienza della responsabilità per mancan-
za di titolarità. Il rilascio di software sotto forma di FOSS da parte di un
fornitore “a monte” è un atto su cui terzi potranno fare affidamento per il
ri-licenziamento successivo. Se c’è un vuoto nella catena della titolarità, ciò
potrebbe comportare dei danni per la parte finale della catena (ad esempio a
causa di azioni di contenzioso), anche se non era a conoscenza dell’esistenza
di alcuna violazione. Può dunque questo distributore di software pretendere
di essere risarcito dal fornitore che ha “offuscato” lo stato reale della titola-
rità di copyright su quella particolare porzione di codice? Tale indennizzo
è difficile da individuare, poiché non vi è alcun legame contrattuale tra co-
lui che chiede l’indennizzo e il suo fornitore. Ciò che rimane, in assenza di
garanzie esplicite, è una responsabilità non contrattuale.
16
Come previsto dall’art. 798 c.c. in materia di vizi sulla cosa donata “salvo patto speciale,
la garanzia del donante non si estende ai vizi della cosa, a meno che il donante sia stato in
dolo”.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 90 — #90
i i
90 Informatica e diritto / Studi e ricerche
Qualsiasi sviluppatore o integratore a valle deve preoccuparsi di effettua-
re una due diligence o richiedere altri tipi di garanzie da chi gli fornisce il
software, o – ancor meglio – fare entrambe le cose. In effetti, questa panora-
mica sul tema della responsabilità civile e dell’assenza di garanzie ci fa capire
come mai proprio la fornitura di alcuni livelli di indennizzo per il FOSS è
diventato il business di alcune aziende del settore.
5. IL MECCANISMO DEL COPYLEFT
5.1. Come funziona
Una caratteristica presente in molte licenze FOSS (ma non tutte17 ) è il
cosiddetto principio del copyleft.
Le licenze FOSS che incorporano il principio copyleft18 , stabiliscono che
coloro che si inseriscono nella catena dello sviluppo di software, se decidono
di apportare miglioramenti al software o realizzarne opere derivate, e poi di-
stribuire questi miglioramenti o derivazioni, possono farlo soltanto allorché
tale distribuzione avvenga con la stessa licenza con cui è distribuita l’opera
originaria. In altre parole, il software che incorpora FOSS copyleft deve es-
sere distribuito a sua volta come FOSS copyleft. Come regola generale, non
è possibile incorporare parti di software distribuite in modalità copyleft in
un’opera che invece è sotto licenza proprietaria.
Spesso ci si riferisce al copyleft usando il termine “viralità della licenza”.
Tuttavia, questa espressione ha una connotazione peggiorativa ed è fuorvian-
te rispetto a come il principio di copyleft effettivamente funziona. Infatti, la
clausola copyleft impone una condizione così sintetizzabile: “se vuoi fare X,
allora devi fare Y, altrimenti non puoi fare X”; tuttavia questo concetto è
17
Né i princìpi fondanti sostenuti dalla Free Software Foundation, né la Open Source De-
finition considerano obbligatoria la clausola copyleft. Varie licenze FOSS non ne contengono
una; gli esempi più noti sono la BSD license e la Apache license.
18
Ad esempio la licenza GPL, Versione 3, all’art. 5 recita: “You must license the entire
work, as a whole, under this License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7 additional terms, to the
whole of the work, and all its parts, regardless of how they are packaged. This License gives
no permission to license the work in any other way, but it does not invalidate such permission
if you have separately received it”. La versione 2 della stessa licenza, invece, all’art. 2 b) recita:
“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”.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 91 — #91
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 91
stato scambiato per: “se fai X, allora sei obbligato a fare Y, altrimenti posso
costringerti a fare Y”.
In altre parole, la distribuzione di opere derivate da software copyleft sot-
to una licenza differente integra una violazione della licenza, ma non è che
il software non licenziato correttamente viene trasformato per magia in un
software copyleft. Ciò non causa di per sé alcun ri-licenziamento dell’ope-
ra derivata (e delle sue componenti) sotto condizioni copyleft, a meno che
il violatore non lo faccia di sua spontanea volontà per sanare la violazione.
Dunque, le licenze copyleft non sono più “infettive” di quanto siano quelle
proprietarie (in cui, se il prezzo non viene pagato, non si ottiene il diritto di
utilizzare il software).
5.2. Validità della clausola copyleft
La questione della validità della clausola copyleft coincide con la questione
se un autore possa effettivamente stabilire come debbano essere distribuite
le opere derivate. La risposta a questo interrogativo è affermativa. L’autore
dell’opera originaria non ha diritti sull’opera derivata nel suo complesso, ma
sulla base dei suoi diritti sull’opera originaria è in grado di permettere o vie-
tare la distribuzione dell’opera derivata. Un’opera derivata può quindi essere
utilizzata solo con il consenso del titolare dei diritti dell’opera originaria, il
quale è libero di imporre le proprie condizioni.
Alcune perplessità potrebbero in teoria essere sollevate contro la creazio-
ne di diritti esclusivi che non sono previsti dalla legge, come è stato qualche
volta attribuito al modello copyleft. A ben vedere, però, il copyleft non crea
alcun diritto di esclusiva che non sia già concesso dalla legge: piuttosto es-
so “scolpisce” i suoi permessi a partire dalla materia grezza consistente nel
diritto esclusivo di autorizzare opere derivate. Dal momento che il destina-
tario a valle del software deve ottenere il permesso di distribuire le sue opere
derivate da parte di tutti gli eventuali titolari di diritti d’autore “a monte”,
le alternative non sono molte: o ciò viene realizzato sulla base della licen-
za pubblica e sottostando alle condizioni della licenza copyleft, oppure deve
essere trovato altro modo; oppure ancora non è possibile.
Se e nella misura in cui le condizioni sono accettate – e rispettate – l’o-
pera ha i necessari permessi. In caso contrario, l’opera non ha tali permessi
e una diversa licenza deve essere richiesta su base individuale, come in ogni
altro tipo di distribuzione del software. Questo, per inciso, è il modo in
cui funziona il cosiddetto dual licensing (licenza proprietaria + licenza copy-
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 92 — #92
i i
92 Informatica e diritto / Studi e ricerche
left), tanto che Richard M. Stallman ha definito questo sistema “vendita di
eccezioni [a una licenza]”19 .
6. DANNI CIVILI E FOSS
Ai sensi dell’art. 158 LDA, i danni causati da violazioni di copyright sono
risarciti secondo la legge italiana in conformità con i princìpi generali sulla
responsabilità per atti illeciti (artt. 2056 e 2059 c.c.) e per violazione degli
obblighi contrattuali (artt. 1223, 1224 e 1225 c.c.). Tali disposizioni stabili-
scono che i danni sono quantificati in una misura sufficiente a ripristinare i
danni patrimoniali (art. 2056 c.c.) e morali (art. 2059 c.c.) subiti dalla parte
lesa. Il danno patrimoniale è calcolato coi classici criteri di danno emergen-
te e lucro cessante, limitatamente al danno che era prevedibile al momento
della violazione, a meno che l’atto dannoso dipenda da dolo o colpa grave.
A differenza di quanto accade in alcuni ordinamenti (come quello statuni-
tense), nel sistema italiano non sono contemplati danni duplicati o triplicati,
o altre forme di risarcimento punitivo. Tradizionalmente, questa tipologia
di risarcimento, che è una forma di “pena privata”, è sempre stata considera-
ta radicalmente incompatibile con i princìpi fondamentali della legge italiana
(il cosiddetto “divieto di locupletazione”). Tuttavia, con l’introduzione del
TRIPS, una forma di danni punitivi (cioè danni non correlati alla perdita
effettivamente subita) è stata introdotta per le violazioni di brevetti e mar-
chi, con il nome di “sanzioni civili” – così da risarcire al titolare del diritto il
valore dei prodotti contraffatti che sono stati confiscati.
Allo stesso modo, nei casi di violazione del diritto d’autore, un risarci-
mento di danni non direttamente legati a danno emergente e lucro cessante
può essere facilmente richiesto richiamandosi ai danni morali20 attraverso
il riconoscimento a titolo di danni di una somma pari agli utili che il con-
traffattore ha conseguito illecitamente (questo profitto potrebbe includere il
vantaggio economico derivante dal fatto di non aver dovuto sostenere par-
te dei costi di produzione). Le violazioni dei diritti d’autore relativamente
al software seguono lo stesso regime delle violazioni di ogni tipo di diritto
d’autore. Il principio di cui sopra è quindi applicabile ai casi di violazione
del copyright del software, incluso l’ambito del FOSS.
19
Si legga a tal proposito R.M. STALLMAN, On Selling Exceptions to the GNU GPL,
disponibile al sito http://www.fsf.org/blogs/rms/selling-exceptions.
20
I danni morali sono espressamente menzionati dall’art. 158, co. 3, LDA.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 93 — #93
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 93
Si potrebbe sostenere che il danno al titolare del copyright, quand’anche
sussista, sarà in ogni caso molto limitato, dato che l’autore ha deciso di ren-
dere il suo lavoro liberamente disponibile. Non è detto che questa argomen-
tazione sia sempre destinata ad aver successo; d’altronde la premessa logica
viene meno in molti casi in cui il FOSS è stato effettivamente utilizzato a
scopi commerciali, come nei seguenti casi.
Oltre all’obbiettivo di formarsi una reputazione e ottenere riconoscimen-
to – il che può effettivamente essere considerato un bene prezioso – un au-
tore può avere altre ragioni per consentire che la sua opera sia disponibile
“liberamente”21 . L’autore può ottenere un vantaggio monetario diretto dal-
la distribuzione gratuita della sua opera. Il modo più semplice e classico è
quello di aggiungere pubblicità sul software (ad-ware); un altro modo è quel-
lo di offrire servizi specifici legati all’opera, come assistenza, manutenzione,
personalizzazione, garanzia, ecc., o altri prodotti correlati. In quest’ulti-
mo esempio, la libera circolazione dell’opera assicura di attirare e avvicinare
molti utenti all’operato dello sviluppatore. L’autore può generare il proprio
reddito dalla fornitura di servizi di supporto e di consulenza, o fornire add-
ons con licenza proprietaria22 (più o meno questa è chiamata “strategia open
core”). Un altro modello di business è il cosiddetto dual licensing23 .
Tuttavia, non esiste una teoria semplice sul risarcimento danni per una
violazione di licenza FOSS. Probabilmente, se il prodotto è in dual licensing,
è facile stabilire i danni per la perdita di profitti che il titolare del copyright
ha sofferto, visto che essa corrisponde a quanto il violatore dovrebbe pa-
gare per ottenere una licenza proprietaria. Se il responsabile del danno ha
ottenuto introiti come conseguenza della violazione, ancora una volta i dan-
ni potrebbero essere determinati in modo relativamente facile calcolando la
quota di profitto che ingiustamente è stata generata come conseguenza della
violazione, sfruttando il principio di cui all’art. 158 LDA. Se invece non si
applica questo principio, il giudice può fare riferimento ai costi ingiustamen-
te evitati a seguito della violazione (come se gli sviluppatori FOSS avessero
lavorato per il responsabile della violazione), o può essere preso in considera-
21
Si veda C. DIBONA, D. COOPER, M. STONE, Introduction, in DiBona C., Cooper D.,
Stone M. (a cura di), “Open Sources 2.0: The Continuing Evolution”, O’Reilly, 2006, pp.
XXV-XL.
22
Gli add-ons sono degli elementi aggiuntivi ad un’opera “free” su cui l’autore si riserva i
diritti di utilizzo, e che quindi possono essere utilizzati dietro pagamento.
23
Si veda ad esempio M. OLSON, Dual Licensing, in DiBona C., Cooper D., Stone M. (a
cura di), op. cit., p. 35.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 94 — #94
i i
94 Informatica e diritto / Studi e ricerche
zione il costo della più fattibile alternativa proprietaria al programma FOSS
(il cui prezzo il contraffattore ha evitato grazie alla violazione delle licenze).
Questa alternativa può infatti essere considerata un’indicazione del prezzo
che l’autore della violazione avrebbe dovuto pagare per ottenere una licenza
simile da parte degli sviluppatori FOSS alle stesse condizioni di licenza (in
altre parole, come se il prodotto fosse in dual licensing).
Il problema con quest’ultimo approccio è che in molti casi lo sviluppa-
tore FOSS non vuole o non è in grado (ad esempio perché egli o ella deriva
a sua volta i propri diritti da licenze copyleft che non consentono tale ri-
licenziamento) di concedere in licenza il software in modalità proprietaria.
Se lo sviluppatore FOSS i cui diritti sono stati violati avesse in ipotesi il di-
ritto di acconsentire a una licenza diversa (proprietaria), ma si rifiuta di farlo
per ragioni morali o di altro tipo, si potrebbe dire “il danno è inferiore perché
chi è causa del suo male pianga se stesso: è lo sviluppatore che ha rinunciato
allo sfruttamento commerciale della sua opera, la quale dunque nella sua stes-
sa valutazione non ha valore monetario, per cui il danno è meramente ipo-
tetico, o morale”. Una tale posizione appare invece assurda; anzi, in tal caso
avrebbe più merito sostenere che in tale situazione il danno è aumentato,
invece che diminuito o assente. Infatti, il prezzo per ottenere questa rinun-
cia al copyleft può essere immensamente alto se negoziato ex ante; pertanto
l’ottenimento in via illegale di una situazione commercialmente inottenibile
non può e non deve essere consentito, dovendosi parametrare il danno all’i-
potetico prezzo al quale solo il titolare dei diritti avrebbe acconsentito alla
concessione di un permesso24 .
Nel caso invece che questo astratto ri-licenziamento non fosse comunque
possibile (ad esempio, a causa di vincoli “a monte”, come il fatto che l’opera
incorpori altri contributi copyleft) ancora una volta questo non è un motivo
per negare il risarcimento, perché l’ottenimento di qualcosa tramite un atto
di “violenza” – ovvero l’equivalente di una licenza proprietaria da qualcuno
che probabilmente non sarebbe stato disposto a licenziare il software in mo-
dalità proprietaria per motivi morali – è un atto moralmente riprovevole,
che deve essere compensato con i danni morali.
I danni morali possono essere riconosciuti secondo equità (artt. 2059,
2056 e 1226 c.c.), il che molto spesso prende in considerazione anche il
profitto ottenuto dal trasgressore.
24
Ovviamente non è pensabile un danno risarcito in “più infinito”, si dovrà utilizzare in
questo caso l’equità. A tal proposito si veda più avanti nel testo.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 95 — #95
i i
S. Aliprandi, C. Piana / Il Free and Open Source software nell’ordinamento italiano ... 95
7. LETTERATURA SCIENTIFICA DI RIFERIMENTO
AA.VV., Atti del Convegno Open Source (Foggia, 2-3 luglio 2004), Milano,
Giuffrè, 2005.
AA. VV., FLOSS: gli indirizzi europei, la normativa italiana e le leggi regio-
nali, in M. Marchesi, G. Concas, G. De Petra, F. Marzano, P. Zanarini
(a cura di), “Finalmente libero! Software libero e standard aperti per
le pubbliche amministrazioni”, Milano, Mac Graw-Hill, 2007.
ALIPRANDI S., Copyleft and Opencontent. L’altra faccia del copyright, Lodi,
PrimaOra, 2005.
ALIPRANDI S., Apriti standard! Interoperabilità e formati aperti per l’inno-
vazione tecnologica, Milano, Ledizioni/Copyleft-Italia.it, 2010; dispo-
nibile su http://www.aliprandi.org/apriti-standard.
BERTANI M., Profili giuridici delle licenze di software libero/open source nel-
l’ordinamento italiano, in “I quaderni di dirittodautore.it”, Vol. 3, n.
24.
BOSCHIERO N., Le licenze F/OSS nel diritto internazionale privato: il pro-
blema delle qualificazioni, in “AIDA”, Vol. 13, 2004, pp. 171-233.
CIURCINA M., PIANA C., Le licenze FLOSS: stato dell’arte ed evoluzioni,
in A. Glorioso (a cura di), “Il software libero in Italia”, Milano, Shake,
2009.
COUGHLAN S., VAN DEN BRANDE Y., JAEGER T. (a cura di), The Inter-
national Free and Open Source Software Law Book, Open Source Press,
2011; disponibile su http://ifosslawbook.org/.
DI RIENZO M., L’organizzazione dei mondi open source: profili soggettivi, in
“AIDA”, Vol. 13, 2004, pp. 12-45.
LINDBERG V., Intellectual Property and Open Source: A Practical Guide to
Protecting Code, O’Reilly, 2008.
MEEKER H.J., The Open Source Alternative: Understanding Risks and Le-
veraging Opportunities, Wiley, 2008.
PIANA C., Licenze pubbliche di software e contratto, in “I contratti”, 2006,
n. 7; disponibile su http://www.piana.eu/repository/720_727.pdf.
RICOLFI M., Software e limitazioni delle utilizzazioni del licenziatario, in
“AIDA”, Vol. 13, 2004, pp. 358-387.
ROZZA L., Le principali iniziative legislative sul FLOSS, in A. Glorioso (a
cura di), “Il software libero in Italia”, Milano, Shake, 2009.
SANSEVERINO G., Le licenze free e open source, Napoli, Edizioni Scientifi-
che Italiane, 2007.
i i
i i
i i
“articoli/aliprandi” — 2012/4/5 — 9:40 — page 96 — #96
i i
96 Informatica e diritto / Studi e ricerche
SPOLIDORO M.S., Open source e violazione delle sue regole, in “AIDA”, Vol.
13, 2004, pp. 92-104.
ST. L AURENT A.M., Understanding Open Source and Free Software Licen-
sing, O’Reilly, 2004.
ZENO-ZENCOVICH V., SAMMARCO P., Sistema e archetipi delle licenze
open source, in “AIDA”, Vol. 13, 2004, pp. 234-268.
i i
i i