Vai al contenuto

La tutela internazionale della proprietà intellettuale: il fenomeno del copyleft/Capitolo 2.1

Da Wikisource.
Capitolo 2 Capitolo 2.2

Prima di analizzare a fondo la storia, i principi e le forme di questo fenomeno, è necessario prima operare un chiarimento su alcuni termini che saranno d’ora in poi impiegati.

2.1.1. La nozione di copyleft

Copyleft è un termine inglese utilizzato per indicare, secondo la definizione ufficiale data dalla Free Software Foundation, «a general method for making a program (or other work) free, and requiring all modified and extended versions of the program to be free as well».1

La parola apparve per la prima volta nel giugno 1976 sulla rivista informatica Dr. Dobb’s Journal, in una pubblicazione riguardo il linguaggio di programmazione Tiny BASIC: fra le prime righe di presentazione, il dottor Li Chen Wang inserì il commento «@COPYLEFT ALL WRONGS RESERVED» (letteralmente: «Copyleft, tutti i torti riservati»).2

Il gioco di parole usato si basava sui vari significati che assume la parola right in inglese, che può significare infatti “diritto”, ma anche “destra” (da cui l’uso dell’opposto left, “sinistra”)3 oppure “giusto” (da cui l’uso dell’opposto wrong, “torto”).

Il termine copyleft attualmente indica anche il complesso movimento culturale, sviluppatosi inizialmente in ambito informatico, che ha cercato modalità di gestione dei diritti economici di un’opera diverse da quella tradizionalmente utilizzata del copyright.

Queste modalità, incentrate sulla volontà di garantire un certo grado di riutilizzo di un’opera (talvolta anche a scopo commerciale) senza dover chiedere l’autorizzazione esplicita all’autore, si sono poi concretizzate nelle c.d. “licenze libere”, ossia delle particolari licenze d’uso di un’opera che si posizionano nel largo spettro di possibilità esistenti fra il copyright e il pubblico dominio.

2.1.2. La nozione di licenza libera

Una licenza libera4 è una licenza d’uso5 di un’opera, ricompresa nell’ambito delle c.d. browse-wrap licences,6 con la quale l’autore «chiarisce al pubblico quali diritti intende riservarsi e di quali intende invece “spogliarsi”».7

In altri termini, queste licenze garantiscono l’autorizzazione («e non [il] trasferimento, in quanto la titolarità dei diritti stessi non viene ceduta»)8 implicita, rilasciata a titolo gratuito dall’autore, al compimento di alcune attività altrimenti considerate illegali, come la copia, la modifica e la redistribuzione dell’opera.

In questo senso, dunque, si possono definire le licenze libere come un “contratto” stretto in piena autonomia fra l’autore e l’utilizzatore dell’opera. Esistono addirittura licenze libere, come le licenze Creative Commons, che si strutturano esattamente come dei contratti.9

L’orientamento predominante della dottrina sembra avallare questa definizione. Scrive Boschiero: «La qualificazione che viene data in dottrina della categoria concettuale delle licenze relative al software è pressoché unanimemente quella di standard-form contract e questo, in particolare, vale anche per le licenze [libere] come evidenziato dall’analisi giuridica condotta sul tema, esclusivamente dedicata alla “contractual enforceability” e alla validità di alcune restrizioni e obblighi imposti al licenziatario dalle clausole copyleft, nonché alla questione più generale dell’assenso manifestato alle clausole contrattuali».10

Dunque, la validità di queste licenze prescinde da un eventuale riconoscimento legislativo o amministrativo in generale,11 laddove da questo non discenda automaticamente una implicita validità delle singole clausole, anche stante le differenze fra i vari ordinamenti, nei singoli casi di applicazione.

Proprio per minimizzare questi rischi e considerato anche che «la redazione delle licenze richiede una certa competenza a livello giuridico che l’autore medio non sempre possiede»,12 si sono sviluppati alcuni modelli standard grazie all’intermediazione di alcune organizzazioni (come la Free Software Foundation o la Creative Commons Foundation) o alla definizione di determinati criteri che possano permettere di definire una certa licenza “libera”.

Più in generale, queste licenze possono essere distinte in due macro-categorie:13

a) quelle c.d. “non protettive”, ossia che non prevengono la possibilità che l’opera possa essere integrata in opere “proprietarie”14 e che non impongono alcuna limitazione sulla distribuzione di opere derivate;

b) quelle c.d. “protettive”, ossia che applicano delle restrizioni alla redistribuzione dell’opera al solo fine di mantenerle “libere” perpetuamente.

Principio assolutamente non negoziabile e anzi imprescindibile di entrambe le macro-categorie è il riconoscimento dei diritti morali sull’opera prodotta, in perfetta armonia con quelle che sono le provvisioni delle leggi nazionali sul diritto d’autore – e, particolare non indifferente, con gli interessi propri degli autori.15

Il fenomeno delle licenze libere è legato alla nascita dei c.d. free software e dei c.d. open source software, anche se ormai – come si vedrà – dall’ambito informatico esso si è esteso anche ad altre forme di pubblicazione.

2.1.3. La nozione di free software

Free software è un termine inglese che indica un programma che può essere liberamente usato, copiato e modificato, così come distribuito nella sua versione originale o in una modificata senza restrizioni, tranne quella di garantire che anche altri possano usufruire delle stesse libertà.

Per dirla con le parole di Richard Stallman, fondatore della Free Software Foundation, «[f]ree software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer».16 Per questo motivo, si usa talvolta anche la definizione “software libre” o “libre software”.17

Un “programma libero” può essere distribuito gratuitamente, ma non necessariamente deve: «[r]edistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it». In pratica, è delegata al singolo (e alle leggi della domanda e dell’offerta) la determinazione di un prezzo per la redistribuzione del programma, specificando che è legittimo ottenere profitti e che questi possono essere anche investiti da chi li ottiene nello sviluppo di ulteriori software liberi.18

Per determinare quali programmi possono essere considerati free (e di conseguenza, quali licenze libere sono compatibili con l’approccio descritto), Stallman pubblicò nel 1986 la Free Software Definition, con la quale si individuano le quattro “libertà essenziali” che connotano i programmi “liberi”:19

0) libertà di utilizzare il programma per qualsiasi scopo;

1) libertà di studiare come funziona il programma, adattandolo alle proprie necessità;

2) libertà di redistribuire copie «so you can help your neighbor»;

3) libertà di distribuire le versioni modificate, così che tutta la comunità ne possa trarre beneficio.

Sia nel caso della “libertà 1” che della “libertà 3”, l’accesso al codice sorgente del programma è un prerequisito fondamentale. Così come, affinché queste quattro libertà siano rispettate, «they must be permanent and irrevocable as long as you do nothing wrong»,20 ossia che possono essere revocate in presenza di una violazione dei termini d’uso.

2.1.4. La nozione di open source

Open source è un termine inglese che indica, secondo la definizione ufficiale della Open Source Initiative, «a development method for software that harnesses the power of distributed peer review and transparency of process».21

La metodologia qui descritta era già in uso negli anni ‘50 e ‘60 nelle Università statunitensi, che all’epoca erano di fatto le uniche produttrici di programmi per computer. Dal momento che si trattava di prodotti di ricerca, i codici sorgenti22 dei programmi venivano liberamente allegati al programma dagli stessi ricercatori/programmatori. In questo modo, chiunque avesse riscontrato un malfunzionamento o avesse voluto aggiungere una nuova funzionalità ritenuta necessaria, avrebbe avuto già a disposizione le “istruzioni di base” per poterlo fare.

La tendenza iniziò a invertirsi verso la fine degli anni ‘60 fino ad annullarsi quasi completamente negli anni ‘80, quando le aziende private si sostituirono alle Università nella produzione di programmi e brevetti e licenze d’uso restrittive diventarono la norma. Nonostante tutto, la prassi di scambiare i codici sorgenti dei programmi restò in vita, sebbene limitata a piccole comunità di programmatori.

Nel 1991, con la nascita del sistema operativo Linux, il metodo “open” riacquistò man mano vigore, sfruttando anche lo slancio fornito dal movimento dei free software. Nel 1998, Bruce Perens e Eric S. Raymond fondarono la Open Source Initiative (OSI), una associazione per promuovere i programmi open source, diventata in breve una delle organizzazioni di riferimento nell’area.

L’associazione pubblicò la Open Source Definition,23 con la quale si individuano i dieci criteri alla base della filosofia open source:24

1) Libera distribuzione: non possono essere previste restrizioni alla libera diffusione (a pagamento o gratis) dei programmi;25

2) Pubblicità del codice sorgente: il programma deve sempre includere il codice sorgente, ovvero, quando ciò non sia possibile, essere reso pubblico e scaricabile via Internet e formulato in un modo comprensibile;26

3) Lavori derivati: deve essere prevista la facoltà di poter modificare il programma e di poter distribuire tali modifiche secondo i termini della licenza originale;27

4) Integrità del codice sorgente: è ammessa la non modificabilità del codice sorgente solo se è permesso rilasciare eventuali modifiche a parte attraverso le c.d. patch,28 facendo salva la possibilità di distribuire versioni modificate del programma;29

5) Divieto di discriminazione verso persone o gruppi: non può essere operata alcuna forma di discriminazione nella distribuzione del programma, anche se la licenza può avvertire della presenza di determinate limitazioni derivanti dalle norme vigenti all’interno del Paese e/o dalle specifiche restrizioni imposte da un Paese nei confronti di un altro Paese;30

6) Divieto di restrizioni riguardo i campi di utilizzo: non può essere operata alcuna forma di divieto di utilizzo di un dato programma in un dato ambito;31

7) Distribuzione della licenza: i diritti connessi al programma devono potersi applicare anche a coloro i quali il programma è redistribuito senza licenze addizionali;32

8) Divieto di licenza specifica: non può essere applicata una licenza specifica a un programma distribuito in un pacchetto (“distribuzione”) più ampio di programmi, ma va applicata la licenza del pacchetto da cui è stato tratto il programma;33

9) Divieto di contaminazione: la licenza si applica solo al programma così distribuito e non può applicarsi anche agli altri programmi eventualmente presenti sul medium utilizzato per la redistribuzione;34

10) Neutralità tecnologica: la licenza non può prevedere alcuna misura riguardo qualsivoglia tecnologia o modalità di interfaccia.35

Note

  1. What is Copyleft?, Free Software Foundation (ultimo aggiornamento: 8 gennaio 2010). Disponibile al sito: http://www.gnu.org/copyleft/copyleft.html.
  2. Li-Chen Wang, “Palo Alto Tiny BASIC”, in Dr. Dobb’s Journal of Computer Calisthenics & Orthodontia, Running Light Without Overbyte, Vol. 1, n. 5, maggio 1976, pag. 12.
  3. È opinione diffusa che il termine left sia da intendere anche come participio passato del verbo to leave, “lasciare”. Da questa interpretazione, è derivata la locuzione italiana di “permesso d’autore”, che spesso viene usata dai commentatori come traduzione di copyleft. Questa interpretazione, per quanto efficace nel “rendere l’idea”, non è però da considerarsi perfettamente corrispondente al concetto espresso in inglese, pertanto viene qui citata solo per completezza di informazione.
  4. Tali licenze possono assumere, a seconda dell’autore, nomi anche estremamente diversi fra loro (alcuni esempi: “licenze free software”, “licenze open source”, “licenze copyleft”, “licenze F/OSS”, “licenze FLOSS”), tutti comunque chiaramente riconducibili al concetto qui espresso. Per comodità, qui si utilizzerà la definizione di “licenza libera”.
  5. Il termine “licenza” è da intendersi come traduzione letterale del termine inglese license, col quale appunto si intendono le licenze d’uso.
  6. Per “browse-wrap licence” si intende una licenza d’uso i cui termini e condizioni vengono messi a disposizione dell’utente finale attraverso un collegamento ipertestuale (link). L’uso o anche solo la visita del sito linkato per poter scaricare e/o acquistare il prodotto «è considerato una manifestazione di assenso ai termini ivi contenuti». Cfr. N. Boschiero, “Le licenze F/OSS nel diritto internazionale privato: il problema delle qualificazioni”, in L.C. Ubertazzi (a cura di), AIDA - Annali italiani del diritto d’autore, della cultura e dello spettacolo, Milano, Vol. XIII, 2004, pag. 202.
  7. S. Aliprandi, Teoria e pratica del Copyleft, Rimini, 2006, pag. 15.
  8. M. Bertani, Guida alle licenze di software libero e open source, Milano, 2004, pag. 77.
  9. Per un esame delle principali licenze libere, cfr. infra, par. 2.4. “Panoramica delle principali licenze copyleft. Sulla Creative Commons in particolare, cfr. infra, par. 2.5. “Le licenze Creative Commons”.
  10. N. Boschiero, op. cit., pag. 202.
  11. Per quel che riguarda l’Italia, fa fede l’art. 1322 c.c.: «Le parti possono liberamente determinare il contenuto del contratto nei limiti imposti dalla legge. Le parti possono anche concludere contratti che non appartengono ai tipi aventi una disciplina particolare, purché siano diretti a realizzare interessi meritevoli di tutela secondo l’ordinamento giuridico». In merito, nota Sanseverino: «La lettera dell’art. 1322 c.c. pone come unico limite che i contratti siano diretti a realizzare interessi meritevoli di tutela da parte dell’ordinamento, e non può, certamente, ritenersi che sia meritevole di tutela solo ciò che è direttamente oneroso. Ne consegue che, in astratto, il modello di licenza [libera] ben possa rientrare nell’ampio alveo dell’autonomia contrattuale proprio in ragione della ricostruita e fondata meritevolezza degli interessi cui è diretta». Cfr. G. Sanseverino, Le licenze free ed open source, Napoli, 2007, pag. 61.
  12. S. Aliprandi, op. cit., pag. 31.
  13. Cfr. N. Boschiero, op. cit., pag. 183.
  14. Per “proprietario” si intende materiale coperto da copyright. La definizione è largamente in uso nel mondo open source e per comodità sarà usata anche in questa analisi.
  15. Nota Giannelli che «il meccanismo adoperato è pur sempre fondato [...] sull’utilizzo di una serie di prerogative del diritto d’autore». Da ciò deriva che «il sistema di licenze non comporta o non dovrebbe comportare abdicazione dai diritti morali che restano pur sempre in capo all’autore; [...] pacificamente considerati diritti irrinunciabili, imprescrittibili e intrasmissibili e, come tali, non oggetto di negoziazione». Cfr. G. Giannelli, “Open source e diritti morali”, in M. Bertani (a cura di), Quaderni di AIDA, n. 13, Milano, 2005.
  16. The Free Software Definition, Free Software Foundation (ultimo aggiornamento: 30 dicembre 2009). Disponibile al sito: http://www.gnu.org/philosophy/free-sw.html.
  17. Utilizzando l’aggettivo francese libre, infatti, si evita di cadere nella ambivalenza del termine inglese free, che può significare tanto “libero” quanto “gratuito”.
  18. Selling Free Software, Free Software Foundation (ultimo aggiornamento: 7 gennaio 2010). Disponibile al sito: http://www.gnu.org/philosophy/selling.html.
  19. Le definizioni della Free Software Definition sono aggiornate alla versione 1.90, rilasciata il 30 dicembre 2009 e disponibile al sito: http://www.gnu.org/philosophy/free-sw.html. La numerazione utilizzata è fedele alle indicazioni della definizione stessa.
  20. The Free Software Definition, op. cit. Riguardo questo punto, abbastanza controverso, cfr. infra, par. 2.4.1. “La GNU General Public License.
  21. Definizione tratta dalla pagina principale della Open Source Initiative, disponibile al sito: http://www.opensource.org/.
  22. Per una definizione di “codice sorgente”, cfr. infra, nota 12.
  23. La Open Source Definition, disponibile al sito http://opensource.org/docs/osd, si basa largamente sulle Debian Free Source Guidelines (ossia sulle linee guida del progetto Debian), che a loro volta si basano sulla Free Software Definition.
  24. Le annotazioni di seguito ai criteri sono delle rielaborazioni sintetiche basate sulla (o citazioni della) versione 1.9 commentata della Open Source Definition, disponibile al sito: http://www.opensource.org/docs/definition.php.
  25. Nota la OSI che, così facendo, si elimina «the temptation to throw away many long-term gains in order to make a few short-term sales dollars», aggiungendo che in caso contrario «there would be lots of pressure for cooperators to defect».
  26. Il riferimento alla “forma comprensibile” assume particolare rilievo, dal momento che non è ammesso pubblicare codici sorgenti “oscuri”, ossia formattati in modo tale da risultare difficilmente o non modificabili da altri utenti. La OSI nota lapidariamente: «Since our purpose is to make evolution [of these programs] easy, we require that modification [should] be made easy [too]».
  27. Questo principio è fondamentale, se si considera che la libera sperimentazione delle modifiche è alla base del processo di revisione paritaria indipendente, a sua volta in grado di garantire correzioni ed evoluzioni rapide del programma.
  28. Per “patch” si intende un file eseguibile creato per risolvere uno specifico errore di programmazione, che impedisce il corretto funzionamento di un programma o di un sistema operativo.
  29. Il criterio ha due scopi. Il primo è quello di garantire, da un lato, la corretta attribuzione della paternità delle modifiche e, dall’altro, la possibilità per l’utente di ottenere assistenza da parte dell’autore. Il secondo è quello di separare la versione “base” da quella “modificata”, rendendo più semplice l’eventuale ripristino della versione gradita all’utente.
  30. La OSI ricorda che una licenza pienamente compatibile con la Open Source Definition può avvertire gli utenti di tali restrizioni e ricordare loro che sono obbligati a seguire comunque le norme del proprio Paese. Tuttavia, da questo non discende l’obbligo di incorporare tali restrizioni. A tal proposito, commenta Ziccardi: «I programmatori non hanno il potere di eliminare o di aggirare queste restrizioni, ma quello che possono e devono fare è rifiutare di imporle come condizioni d’uso del programma. In tal modo, le restrizioni non influiranno sulle attività e sulle persone al di fuori della giurisdizione degli Stati che applicano tali restrizioni». Cfr. G. Ziccardi, Il diritto d’autore nell’era digitale, Milano, 2001, pag. 233.
  31. La ratio di questo criterio è impedire che un programma open source non possa essere usato anche per opere commerciali, rimarcando l’attitudine aperta e tutt’altro che avversa a chi opera nel settore commerciale.
  32. Questo criterio è pensato per impedire che si possa interrompere gli effetti virtuosi della revisione paritaria diffusa e della trasparenza delle modifiche, magari imponendo clausole che violano questi due principi e limitando, dunque, i diritti degli utenti.
  33. Anche questo criterio è pensato con la stessa ratio del precedente, applicandosi però non agli utenti ma alle singole componenti di un’unica “distribuzione”, ossia di un pacchetto preconfigurato di programmi.
  34. Apparentemente in contrasto con quanto statuito dai due precedenti criteri, è invece un principio che rimarca ancora una volta il diritto dell’autore «to make their own choices about their own software». Questo permette di tutelare, dunque, la scelta di un programmatore di distribuire il proprio programma con una licenza libera diversa da quella scelta da un altro programmatore, nonostante (per esempio) i due programmi siano distribuiti sullo stesso supporto.
  35. Il criterio, aggiunto in una stesura successiva rispetto a quella originale, è inteso a regolare i rapporti con quelle licenze che richiedono un gesto esplicito di accettazione dei termini d’uso (c.d. click-wrap licences, la cui definizione è data da N. Boschiero, op. cit., pagg. 201-202) e che, dunque, «may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring» – aggiungendo che potrebbero anche «hinder code re-use». Pertanto, in questi casi devono essere previste la possibilità di distribuire il programma anche con modalità diverse dalla click-wrap e di utilizzarlo anche su piattaforme che non supportano quest’ultima modalità.