DOKK Library
    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


Il Free and Open Source software nell’ordinamento italiano: principali problematiche giuridiche

Authors Carlo Piana Simone Aliprandi

License CC-BY-SA-3.0