Open Source e "Appartenenza" del Software

Il rapporto tra Open Source e diritto d’autore

E’ facile incorrere nell’errore di contrapporre concettualmente Open Source e proprietà intellettuale. Invero fra le due realtà non c’è antinomia, ma anzi il fenomeno open basa la propria essenza ed efficacia sul diritto d’autore, cui fa ricorso con l’intenzione di sfruttare le prerogative che esso garantisce, in modo da rendere effettivamente “libero” il software ed impedirne opportunistica acquisizione proprietaria da parte di terzi.

L’open source si configura quindi non come paradigma libertario anti-autorale, ma come un particolare atteggiarsi della tutela d’autore. Per questo motivo, le regole di attribuzione della titolarità dettate dalla disciplina d’autore, valgono, in linea generale, anche per i programmi open source. Tuttavia, le particolari modalità di creazione che spesso caratterizzano il software libero possono dare (e di fatto danno) vita ai problemi interpretativi (e non solo) trattati di seguito. E’ quindi utile ricordare brevemente le più importanti regole attributive generali, riguardanti (anche) il software, presenti nella Legge 633/1941, e confrontarle col mondo open source.

Cenni sulla disciplina italiana

Ai sensi dell’art. 2 sono compresi nella protezione i programmi per elaboratore, espressi in qualsiasi forma, purché originali (requisito che si aggiunge a quello della creatività ex art. 1) quale risultato di creazione intellettuale dell’autore.

I programmi per elaboratore sono protetti automaticamente dal momento della creazione (art. 6) e titolare dei diritti morali e di sfruttamento è l’autore, normalmente coincidente col creatore.

E’ considerato autore dell’opera collettiva chi organizza e dirige la creazione dell’opera stessa (art. 7), dove per opera collettiva (art. 3) si intende la riunione di opere o parti di opere che hanno carattere di creazione autonoma come risultato della scelta del coordinamento ad un determinato fine. L’opera collettiva è protetta come opera originale indipendentemente e senza pregiudizio dei diritti di autore sulle opere o sulle parti di opere di cui sono composte. Ex art. 40, il collaboratore di opera collettiva (diversa da rivista o giornale) ha diritto che il suo nome figuri nella riproduzione della sua opera nelle forme d’uso.

Le elaborazioni creative (art. 4), cioè modificazioni, aggiunte e variazioni sull’opera originaria che ne costituiscono rifacimento sostanziale, sono altresì protette senza pregiudizio dei diritti esistenti sull’opera stessa.

L’art. 10 recita: “se l’opera è stata creata con il contributo indistinguibile ed inscindibile di più persone, il diritto d’autore appartiene in comune a tutti i coautori”. Di conseguenza, l’esercizio dei diritti è subordinato al consenso di tutti i coautori comunisti, o all’autorizzazione dell’autorità giudiziaria in caso di rifiuto ingiustificato di uno di essi.

Queste regole ora ricordate paiono applicarsi anche nel caso del software. Lo stesso può dirsi per quanto riguarda le opere create nell’ambito di rapporti di lavoro (art 12-bis): il datore di lavoro è titolare del diritto esclusivo di utilizzazione economica del software creato dal lavoratore dipendente nell’esecuzione delle sue mansioni o su istruzioni impartite dallo stesso datore di lavoro.

All’autore spettano sempre e comunque i diritti morali, irrinunciabili, intrasmissibili ed imprescrittibili sul software creato, in particolare rispetto all’integrità dell’opera e alle modifiche potenzialmente lesive dell’onore o della reputazione dell’autore.

Al titolare dei diritti di utilizzazione economica (non sempre coincidente con l’autore) spettano i seguenti diritti esclusivi: pubblicazione; riproduzione; elaborazione; distribuzione con possibilità di esaurimento; uso. Questi diritti sono fra loro indipendenti, quindi la cessione di uno non comporta la perdita di tutti gli altri. Essi possono essere acquistati, alienati o trasmessi.

Questa breve elencazione dei diritti esclusivi e del loro contenuto, è finalizzata ad esplicitare alla titolarità di quali situazioni giuridiche conseguenti si fa riferimento quando, come nel presente contributo, ci si interroga sull’appartenenza del software.

Problematiche dell’appartenenza open source

Il software open source non si sottrae ai comuni principi dell’appartenenza, la quale è sempre originaria per il suo creatore persona fisica o in regime di comunione o condivisione di diritti con altri (parimenti creatori all’interno di un gruppo) e derivativa per i terzi che la acquisiscono in forza di un titolo traslativo, che può essere il medesimo titolo in base al quale l’opera è stata creata (lavoro autonomo e subordinato, prestazione d’opera) e produrre effetti al momento del venire in essere del risultato creativo, oppure essere un titolo diverso, caso in cui si applicano le norme di diritto comune sulla circolazione dei diritti sulle opere dell’ingegno.

Il fulcro del problema relativo all’appartenenza del software open source non consta quindi nel meccanismo attributivo conseguente alla creazione del sorgente, ma è correlato alle particolari e diversificate situazioni di plurisoggettività che possono sorgere: pluralità originaria di soggetti che partecipano alla creazione; pluralità successiva di soggetti che intervengono a modificare o sviluppare il risultato intellettuale preesistente, con conseguente problematica distribuzione dei diritti sulle opere così ottenute. La dottrina è divisa nel qualificare le due ipotesi (quando relative al fenomeno open source) come ambiti normativi distinti o a farli coincidere, ma non è questa la sede adatta ad approfondire tale questione. Per il nostro interesse, è sufficiente far notare come l’area concettuale delle opere originariamente create con il contributo di più soggetti e quella delle opere derivate, pur essendo ontologicamente autonome, tendano spesso a sovrapporsi poiché le elaborazioni creative compiute da soggetti diversi dall’autore originario, pongono, come le opere già all’origine plurisoggettive, il problema di definire le posizioni reciproche e le relazioni tra i diversi soggetti e quelle tra i diversi risultati.

Inoltre la questione è complicata dalla natura in fieri dell’open source software. Esso, nella sua forma più caratteristica, si forma per accrescimento, grazie ai contributi (leciti perché autorizzati) di elaborazione, correzione, variazione, sviluppo apportati da più soggetti. Il problema della plurisoggettività è quindi da considerarsi intrinsecamente connesso alle normali dinamiche creative ed attributive del software a codice aperto, motivo per cui si rende necessario l’approfondimento proposto di seguito.

OPEN SOURCE E DISCIPLINA DELLE OPERE DERIVATE

Problemi e (possibili) soluzioni

L’elaborazione di software è definibile come l’utilizzazione diretta del codice del programma originario o delle informazioni tecniche che di esso si possiedano, al fine di modificarlo per creare un altro programma, il c.d. derivato (LOFFREDO). Perché si possa parlare di “elaborazione”, è inoltre necessario che il programma originario sia riconoscibile in quello derivato.

Tale attività da una parte va ad interessare l’appartenenza originaria sotto il profilo della gestione negoziale dell’esclusiva, dall’altra riguarda le posizioni dell’ideatore e derivatore rispetto al risultato.

Questo contesto è ulteriormente complicato dalla delocalizzazione degli interventi causata dalla diffusione delle opere tramite rete telematica globale e dalla molteplicità degli strumenti negoziali, che danno potenzialmente vita ad una collaborazione con soggetti non sempre determinabili in termini di identità e ruoli, e regolata da modalità spesso peculiari.

Nel tentativo di sciogliere i problemi sopra delineati, la prima e più ovvia ipotesi risolutiva consiste nel cercare le indicazioni di attribuzione della titolarità dei diritti sui contributi creativi nelle licenze dalle quali scaturisce la facoltà per gli utilizzatori di realizzare i contributi stessi. Così operando, tuttavia ci si renderebbe presto conto che, non utilizzando l’open source schemi contrattuali comuni per qualificare la collaborazione creativa (la licenza infatti costituisce diritti e obbligazioni in capo all’utilizzatore, ma non definisce la posizione di questi in termini di titolarità dei diritti), è impossibile risolvere i problemi di appartenenza sul piano degli effetti del negozio avente ad oggetto la creazione intellettuale.

In seconda battuta, si possono analizzare le norme di diritto d’autore all’interno delle quali viene operata una distinzione tra:

- i contributi che, se sufficientemente creativi, possono costituire un’opera derivata, da tutelarsi indipendentemente dall’opera originaria e senza pregiudizio dei diritti esistenti su quest’ultima, ex art. 4 l.a.;

- i contributi che, quando non sussistano i requisiti per costituire opera derivata, ma siano distinguibili e scindibili dall’opera originaria, sono soggetti all’applicazione della disciplina delle opere collettive, in forza della quale ciascun contributo potrà avere autonoma protezione, mentre autore dell’opera risultante dall’unione dei vari contributi sarà chi ha organizzato e diretto la creazione dell’opera stessa, ex artt. 3 e 7 l.a.; e infine,

- i contributi che, qualora non siano scindibili né distinguibili tra loro, sono assoggettati alle regole dettate per le opere in comunione, in base alle quali il diritto d’autore appartiene in comune a tutti i coautori, ex art. 10 l.a.

Ciò su cui gran parte della dottrina sembra però concorde, è la difficoltà di ricondurre i fenomeni open source ad una (o talvolta ad una sola) delle fattispecie previste dalla legge. Il software libero è difatti interessato da dinamiche di sviluppo molteplici e molto differenti tra loro, e solo un’analisi caso per caso delle stesse può portare alla più corretta sussunzione.

La dialettica creatività / autonomia

La dottrina è invece divisa sull’attribuire, o meno, rilevanza all’autonomia (in termini di funzione assolta dal programma derivato) del contributo creativo nel decidere dell’attribuzione dei relativi diritti.

In virtù della seconda impostazione, tutte le opere di seconda generazione, anche se oggetto di autonomo diritto, sono sempre e comunque dipendenti, con conseguente inibizione di ogni utilizzazione non privata senza consenso dell’autore dell’opera principale.

Secondo la prima posizione (LOFFREDO), invece, il riconoscimento dell’appartenenza di un contributo creativo è condizionato dal grado di autonomia o dalla mancanza di autonomia creativa del risultato elaborato rispetto all’opera originaria. Un intervento principalmente correttivo, privo di apprezzabile sforzo creativo non fa di norma attivare situazioni di appartenenza in capo all’elaboratore. Di contro, l’intervento che porti ad un risultato che ecceda la sufficiente creatività, nel quale cioè non sia più riconoscibile l’identità del codice originario porta ad attribuire esclusivamente l’opera derivata al suo creatore, in quanto si è persa la riferibilità all’opera originaria. In proposito, Di Rienzo fa notare come, in ambito open source, ciò comporti il non prodursi dell’effetto dell’ultrattività generalmente dettato nella licenza che accompagna l’opera originaria.

Ma se quelli appena delineati sono i casi estremi, è intuitivo che i problemi maggiori si pongano per i risultati di tipo intermedio, quelli sufficientemente creativi, ma non autonomi. A questa categoria possiamo ricondurre gli interventi di aggiornamento, miglioramento e adattamento del codice, in parte richiamando l’art. 4 l.a. il quale, unitamente al secondo comma dell’art 7, delinea una relazione dai tratti poco definiti tra autore originario e sviluppatore. Questa relazione può dar vita (alternativamente) ad una delle fattispecie che la legge ricollega alla collaborazione creativa.

Un intervento elaborativo che per funzioni e struttura concettuale corrisponda alla (e si inserisca nella) specifica logica progettuale iniziale dell’ideatore del codice originario (che ha esercitato nella fattispecie un’azione di controllo e coordinamento), è plausibilmente inquadrabile nello schema dell’opera collettiva, con attribuzione dei diritti esclusivamente all’ideatore-organizzatore, o alle software houses o gruppi organizzati di sviluppo. Generalmente quando questo schema si realizza, viene concesso allo sviluppatore il diritto di utilizzare autonomamente la propria elaborazione, ma non in concorrenza con l’opera collettivamente realizzata.

Proviamo invece ad immaginare il caso in cui il risultato dell’intervento creativo sia privo di completa autonomia, ma si colleghi in una qualche misura ad un lavoro precedente senza però essere collocabile all’interno del medesimo progetto di sviluppo. In tal situazione, riservare i diritti ad uno dei due soggetti significherebbe attribuire in entrambi i casi un ingiustificato privilegio. Una possibilità suggerita da alcuni autori è quella di applicare la disciplina delle c.d. “opere realizzate in collaborazione”, che prevede l’attivazione del modello della comunione dei diritti d’autore. Ma questa, che comunque è solo un’ipotesi solutiva, presenta dei problemi di applicazione al software open source, in quanto la più accreditata posizione dottrinale individua nella contestualità degli interventi un requisito fondamentale per definire un’opera realizzata “in collaborazione”, mentre può accadere che le elaborazioni in questione siano realizzate in tempi diversi.

Programmi applicativi: opere derivate?

In dottrina ci si è chiesti quale schema normativo applicare nell’ipotesi dello sviluppo (successivo da parte di un soggetto ulteriore) di un sistema applicativo che giri su di un sistema operativo ideato da altri e divulgato mediante licenza open source. In questo caso non c’è ispirazione concettuale, né nesso di dipendenza, ma c’è logica funzionale (l’applicativo è destinato all’operativo di cui presuppone l’utilizzo e la conoscenza). Secondo un particolare orientamento, a queste condizioni, il software applicativo è da considerarsi opera derivata, con la conseguenza che il suo autore può sì essere titolare di un autonomo diritto, ma solo passando per il preventivo consenso, avente valenza interdittiva, dell’autore originario, allo sfruttamento economico dell’opera derivata. Situazione, quest’ultima, che pare ben attagliarsi ai meccanismi negoziali di gestione dei diritti propri dell’open source software.

Per doveri di sintesi, sul punto ci limitiamo a ricordare che l’atipicità delle procedure di creazione e sviluppo che interessano il software a codice aperto ostacolano e spesso impediscono di individuare automatici collegamenti tra situazioni reali e fattispecie giuridiche. L’attività della dottrina in questo ambito consiste quindi principalmente nel formulare delle ipotesi. Per farlo è necessario altresì analizzare l’ultimo ambito delle problematiche dell’appartenenza open source: quello relativo alle opere originariamente plurisoggettive.

OPEN SOURCE E OPERE ORIGINARIAMENTE PLURISOGGETTIVE

Le opere in comunione

Come accennato poc’anzi, applicare la disciplina delle opere in comunione all’ambito open source dà potenzialmente vita ad alcune incompatibilità, sulla cui effettività è opportuno interrogarsi. Il presupposto primario per l’applicazione del regime di comunione è una collaborazione tra più soggetti nel realizzare un progetto comune caratterizzata (secondo un orientamento dottrinale) dalla contestualità dei diversi interventi creativi e (ex art. 10 l.a.) dalla indistinguibilità e inscindibilità dei vari contributi fra loro. Parlando di software, il richiamo è ad un gruppo di programmatori che lavorano nello stesso tempo, alle stesse porzioni di codice in base ad un progetto di sviluppo.

Mentre in un contesto di software proprietario (si pensi al lavoro quotidiano delle software houses), tale ricostruzione fattuale trova ampio riscontro, in ambito open source, è pressoché impossibile rinvenire una situazione di tal configurazione. La procedura “classica” prevede che inizialmente venga ad esistenza il codice sorgente, e la collaborazione abbia inizio solo in quel momento, per poi esplicarsi in una serie di interventi successivi. Stanti i presupposti sopra elencati, si potrebbe concludere che è impossibile ricondurre lo schema dell’open source al regime delle opere in comunione.

Tuttavia una differente corrente dottrinale ritiene sempre applicabile, in linea teorica, il regime di comunione ad ogni opera realizzata con contributi apportati in momenti diversi, sulla scorta della forzatura di considerare l’inscindibilità un requisito intrinseco di queste opere. Seguendo questo orientamento, il requisito della contestualità temporale della collaborazione si troverebbe svuotato di efficacia e di importanza.

Una posizione ancora differente è quella (esplicitata da Di Rienzo) di alcuni autori che propongono di considerare irrilevante la distinguibilità dei contributi perché si possa applicare, in caso di collaborazione creativa di più autori, il regime di comunione. In questa visione, è sufficiente verificare la presenza di più apporti che si estrinsecano nel risultato di un’opera unitaria. Questo orientamento si basa sullo spostamento della considerazione della dialettica collaborativa fra più soggetti dal momento genetico della realizzazione dell’opera al momento funzionale dell’attività creativa esplicatasi, riscontrabile quindi nel risultato ottenuto come esito della collaborazione e cioè l’opera unitaria. In altre parole si afferma la prevalenza dell’unità funzionale su quella concettuale e del risultato sulle modalità di produzione dello stesso.

Per ricollegarci ai problemi di compatibilità di cui poco sopra, questa visione potrebbe portare a parlare di collaborazione anche laddove l’intervento successivo di un secondo o di ulteriori soggetti si abbia rispetto a contributi creativi preesistenti.

Sempre di Rienzo fa notare come applicare il regime di comunione al software a codice aperto, attribuisca un forte fondamento giuridico all’ultrattività del regime open source, nella misura in cui per cambiare il regime di disponibilità di un bene comune occorre il consenso di tutti i comunisti. In quest’ottica, l’opera open source sarebbe pensata come opera in collaborazione già dall’autore originario ed a tale progetto aderirebbe, concorrendovi creativamente ed autonomamente, l’autore successivo.

Un’altra interessante posizione dottrinale (AUTERI), vuole che quando le modifiche dell’elaboratore si esplichino solo sull’opera originaria, si debba applicare il regime di comunione. Altri, pur uniformandosi a questo assunto, vi aggiungono il requisito che il titolare dell’opera originaria abbia già usato l’elaborazione, creando così un legame collaborativo e funzionale tra i due soggetti e le due opere. In proposito si parla di “comunione a titolo derivativo”. Se questo orientamento divenisse prevalente, assisteremmo ad un considerevole aumento dei poteri in capo all’autore originario in termini di controllo sulle elaborazioni dell’opera originaria, in quanto non vi sarebbe il rischio di comportamenti opportunistici da parte dell’elaboratore, essendo la sorte distributiva del prodotto elaborato da decidersi nel consenso di tutti i comunisti, quindi dell’autore originario. Conseguenza negativa è per contro la nascita di un eccessivo privilegio per l’elaboratore, che non avendo avuto nessuna idea di partenza, si trova contitolare di un’opera nella sua totalità

Le opere collettive

Una delle rarissime questioni (nell’ambito qui preso in esame) su cui sembrano non esistere profonde distanze dottrinali è quella dell’applicabilità della disciplina delle opere collettive ad una determinata configurazione dell’open source software: la dottrina sembra largamente favorevole al ritenere che quando esista una comunità di sviluppo dove ogni programmatore porta avanti un singolo aspetto del programma e i loro contributi (quindi distinguibili) vengano selezionati ed inseriti nel sorgente da un unico coordinatore in vista di una comune logica progettuale, la categoria delle opere collettive appaia la più adatta per inquadrare la fattispecie.

E’ utile ricordare che ai sensi dell’art. 7 l.a. è considerato autore dell’opera collettiva chi organizza e dirige la creazione dell’opera stessa. Questo schema sembra potenzialmente attagliarsi a determinate fenomenologie open source, quali ad esempio il progetto GNU / Linux, caratterizzate da una gerarchizzazione del procedimento creativo. Infatti il coordinatore dell’opera, in quanto titolare dei diritti, ha il potere di decidere delle sorti distributive della stessa e quindi, nel caso in esempio, di scegliere quale licenza abbinare al prodotto finale.

Le opere composte

L’opera c.d. “composta” è caratterizzata da:

- pluralità di autori;

- pluralità di contributi, per i quali deve integrarsi il requisito della distinguibilità;

- la produzione di un risultato derivante dalla compenetrazione delle diverse parti.

La peculiarità, in termini di disciplina, è il riconoscimento, a ciascuno dei partecipanti al risultato, del diritto all’utilizzazione separata e indipendente dei singoli contributi, in forza dell’art. 34 ult. co. l.a.

Diversi esponenti della dottrina fanno notare come tale schematismo di plurisoggettività sembri più rispondente alla fenomenologia open source rispetto a quello dell’opera collettiva. Sanfilippo, in particolare, spiega tale (presunta) compatibilità sottolineando la struttura tipicamente modulare dei modelli di sviluppo tipici dell’open source.

Questa affermazione conferma l’impressione di un ambito di studio che si presta quasi sempre a più di un’opzione interpretativa. Di conseguenza, prendere una posizione significa operare una scelta interpretativa e rifiutare altre possibilità non errate, ma alternative e che altri esponenti della dottrina potrebbero ritenere preferibili.

Quindi, bisogna concludere che anche la verifica dell’aderenza delle fenomenologie open source agli schematismi delle opere plurisoggettive previsti dal nostro ordinamento richieda un esame caso per caso per stabilire quale normativa sia più idonea a disciplinare i rapporti fra i diversi soggetti, con la possibilità che siano applicabili più fattispecie in concorso tra loro.

CAUSE DELL’INCERTEZZA NORMATIVA E FUTURO DELL’APPARTENENZA OPEN SOURCE

E’ significativo che anche ipotesi dottrinali al limite della provocazione concettuale riescano, relativamente al fenomeno open source, a risultare in un qualche modo plausibili in termini di interpretazione del diritto. Questo è dovuto da un lato al fatto che l’attuale dato normativo è ben poco corrispondente alla realtà in questione, essendo questa, per molti aspetti, di genesi cronologicamente successiva alla legge che la regola; dall’altro, alla forzatura sottesa alla scelta politica che ha portato a tutelare il software come opera letteraria.

Ci si potrebbe chiedere perché il legislatore (non solo italiano ma anche) comunitario non abbia ancora intrapreso iniziative di razionalizzazione e chiarificazione della materia, o promosso la stesura di provvedimenti dedicati. Tuttavia non lo faremo in questa sede, anche perché è opinione di chi scrive che questa mancata (fino ad oggi) produzione normativa non sia un fatto del tutto negativo, per i motivi che seguono.

L’open source è un fenomeno in forte espansione, ma con un potenziale di crescita ancora maggiore. Le dimensioni che esso ha assunto fino ad oggi sono ben poca cosa rispetto a quelle che potrebbe avere e che probabilmente avrà fra dieci o quindici anni. Considerati i vantaggi informatici ed economici che potrebbero derivare da una diffusa adozione dell’open source software, non sarebbe sorprendente se il potere politico decidesse di fare del codice aperto (e soprattutto del copyleft) il paradigma informatico - distributivo del prossimo futuro. Anche le questioni di appartenenza sorte finora sono sottodimensionate rispetto alla potenziale espansione del movimento cui afferiscono. Significativo in questo senso è che nel mondo le decisioni giudiziali finora emesse sull’argomento si contino praticamente sulle dita di una mano.

Un legislatore che decidesse in questo momento di disciplinare puntualmente l’open source, potrebbe non riuscire a cogliere la portata della materia e rischierebbe di emanare provvedimenti dalla dannosamente rapida obsolescenza.

Inoltre è attualmente in corso un dibattito sull’opportunità di introdurre in Europa la tutela brevettuale sui software, che ha portato recentemente (2005) anche ad una proposta di direttiva comunitaria, poi bocciata dall’europarlamento. Ciò rivela il rischio di produrre norme riferite alla tutela autorale, per poi assistere all’introduzione dei brevetti sui software, con la conseguente necessità di rivisitare l’intera disciplina.

Inoltre se effettivamente si dovesse decidere di tutelare il software mediante brevetto, potrebbero esserci conseguenze fortemente negative per l’espansione ma forse anche per l’esistenza dell’open source. Se del resto la cornice normativa non dovesse cambiare, prima di disciplinare puntualmente il fenomeno open source potrebbe risultare conveniente attendere il risolversi delle diatribe dottrinali ed osservare lo sviluppo del movimento, così da legiferare con maggiore competenza e aderenza alla realtà, considerato anche che, per il momento, la scarsa “contenziosità” in tema di appartenenza open source permette di ritenere “non urgente” una produzione legislativa dedicata.

L’auspicarsi una normazione attenta, competente e lungimirante, è dovuto alla forte probabilità che nei prossimi anni la crescita del fenomeno open source farà aumentare proporzionalmente le controversie sull’appartenenza del software libero. Questo non solo grazie alla maggiore attenzione che ad esso sta gradualmente tributando l’utenza privata e commerciale, ma anche al fatto che le Pubbliche Amministrazioni di un numero sempre maggiore di Paesi stanno scegliendo di utilizzare software open source per le proprie strutture informatiche, con un considerevole aumento dell’importanza degli interessi in gioco, ma anche dei soggetti partecipanti al movimento open.

E’ evidente che, se si realizzerà il quadro di sviluppo appena delineato, l’attribuzione dei diritti sul software open source diventerà uno dei più rilevanti ambiti di ricerca e applicazione del moderno diritto industriale.

Il rapporto tra Open Source e diritto d’autore

E’ facile incorrere nell’errore di contrapporre concettualmente Open Source e proprietà intellettuale. Invero fra le due realtà non c’è antinomia, ma anzi il fenomeno open basa la propria essenza ed efficacia sul diritto d’autore, cui fa ricorso con l’intenzione di sfruttare le prerogative che esso garantisce, in modo da rendere effettivamente “libero” il software ed impedirne opportunistica acquisizione proprietaria da parte di terzi.

L’open source si configura quindi non come paradigma libertario anti-autorale, ma come un particolare atteggiarsi della tutela d’autore. Per questo motivo, le regole di attribuzione della titolarità dettate dalla disciplina d’autore, valgono, in linea generale, anche per i programmi open source. Tuttavia, le particolari modalità di creazione che spesso caratterizzano il software libero possono dare (e di fatto danno) vita ai problemi interpretativi (e non solo) trattati di seguito. E’ quindi utile ricordare brevemente le più importanti regole attributive generali, riguardanti (anche) il software, presenti nella Legge 633/1941, e confrontarle col mondo open source.

Cenni sulla disciplina italiana

Ai sensi dell’art. 2 sono compresi nella protezione i programmi per elaboratore, espressi in qualsiasi forma, purché originali (requisito che si aggiunge a quello della creatività ex art. 1) quale risultato di creazione intellettuale dell’autore.

I programmi per elaboratore sono protetti automaticamente dal momento della creazione (art. 6) e titolare dei diritti morali e di sfruttamento è l’autore, normalmente coincidente col creatore.

E’ considerato autore dell’opera collettiva chi organizza e dirige la creazione dell’opera stessa (art. 7), dove per opera collettiva (art. 3) si intende la riunione di opere o parti di opere che hanno carattere di creazione autonoma come risultato della scelta del coordinamento ad un determinato fine. L’opera collettiva è protetta come opera originale indipendentemente e senza pregiudizio dei diritti di autore sulle opere o sulle parti di opere di cui sono composte. Ex art. 40, il collaboratore di opera collettiva (diversa da rivista o giornale) ha diritto che il suo nome figuri nella riproduzione della sua opera nelle forme d’uso.

Le elaborazioni creative (art. 4), cioè modificazioni, aggiunte e variazioni sull’opera originaria che ne costituiscono rifacimento sostanziale, sono altresì protette senza pregiudizio dei diritti esistenti sull’opera stessa.

L’art. 10 recita: “se l’opera è stata creata con il contributo indistinguibile ed inscindibile di più persone, il diritto d’autore appartiene in comune a tutti i coautori”. Di conseguenza, l’esercizio dei diritti è subordinato al consenso di tutti i coautori comunisti, o all’autorizzazione dell’autorità giudiziaria in caso di rifiuto ingiustificato di uno di essi.

Queste regole ora ricordate paiono applicarsi anche nel caso del software. Lo stesso può dirsi per quanto riguarda le opere create nell’ambito di rapporti di lavoro (art 12-bis): il datore di lavoro è titolare del diritto esclusivo di utilizzazione economica del software creato dal lavoratore dipendente nell’esecuzione delle sue mansioni o su istruzioni impartite dallo stesso datore di lavoro.

All’autore spettano sempre e comunque i diritti morali, irrinunciabili, intrasmissibili ed imprescrittibili sul software creato, in particolare rispetto all’integrità dell’opera e alle modifiche potenzialmente lesive dell’onore o della reputazione dell’autore.

Al titolare dei diritti di utilizzazione economica (non sempre coincidente con l’autore) spettano i seguenti diritti esclusivi: pubblicazione; riproduzione; elaborazione; distribuzione con possibilità di esaurimento; uso. Questi diritti sono fra loro indipendenti, quindi la cessione di uno non comporta la perdita di tutti gli altri. Essi possono essere acquistati, alienati o trasmessi.

Questa breve elencazione dei diritti esclusivi e del loro contenuto, è finalizzata ad esplicitare alla titolarità di quali situazioni giuridiche conseguenti si fa riferimento quando, come nel presente contributo, ci si interroga sull’appartenenza del software.

Problematiche dell’appartenenza open source

Il software open source non si sottrae ai comuni principi dell’appartenenza, la quale è sempre originaria per il suo creatore persona fisica o in regime di comunione o condivisione di diritti con altri (parimenti creatori all’interno di un gruppo) e derivativa per i terzi che la acquisiscono in forza di un titolo traslativo, che può essere il medesimo titolo in base al quale l’opera è stata creata (lavoro autonomo e subordinato, prestazione d’opera) e produrre effetti al momento del venire in essere del risultato creativo, oppure essere un titolo diverso, caso in cui si applicano le norme di diritto comune sulla circolazione dei diritti sulle opere dell’ingegno.

Il fulcro del problema relativo all’appartenenza del software open source non consta quindi nel meccanismo attributivo conseguente alla creazione del sorgente, ma è correlato alle particolari e diversificate situazioni di plurisoggettività che possono sorgere: pluralità originaria di soggetti che partecipano alla creazione; pluralità successiva di soggetti che intervengono a modificare o sviluppare il risultato intellettuale preesistente, con conseguente problematica distribuzione dei diritti sulle opere così ottenute. La dottrina è divisa nel qualificare le due ipotesi (quando relative al fenomeno open source) come ambiti normativi distinti o a farli coincidere, ma non è questa la sede adatta ad approfondire tale questione. Per il nostro interesse, è sufficiente far notare come l’area concettuale delle opere originariamente create con il contributo di più soggetti e quella delle opere derivate, pur essendo ontologicamente autonome, tendano spesso a sovrapporsi poiché le elaborazioni creative compiute da soggetti diversi dall’autore originario, pongono, come le opere già all’origine plurisoggettive, il problema di definire le posizioni reciproche e le relazioni tra i diversi soggetti e quelle tra i diversi risultati.

Inoltre la questione è complicata dalla natura in fieri dell’open source software. Esso, nella sua forma più caratteristica, si forma per accrescimento, grazie ai contributi (leciti perché autorizzati) di elaborazione, correzione, variazione, sviluppo apportati da più soggetti. Il problema della plurisoggettività è quindi da considerarsi intrinsecamente connesso alle normali dinamiche creative ed attributive del software a codice aperto, motivo per cui si rende necessario l’approfondimento proposto di seguito.

OPEN SOURCE E DISCIPLINA DELLE OPERE DERIVATE

Problemi e (possibili) soluzioni

L’elaborazione di software è definibile come l’utilizzazione diretta del codice del programma originario o delle informazioni tecniche che di esso si possiedano, al fine di modificarlo per creare un altro programma, il c.d. derivato (LOFFREDO). Perché si possa parlare di “elaborazione”, è inoltre necessario che il programma originario sia riconoscibile in quello derivato.

Tale attività da una parte va ad interessare l’appartenenza originaria sotto il profilo della gestione negoziale dell’esclusiva, dall’altra riguarda le posizioni dell’ideatore e derivatore rispetto al risultato.

Questo contesto è ulteriormente complicato dalla delocalizzazione degli interventi causata dalla diffusione delle opere tramite rete telematica globale e dalla molteplicità degli strumenti negoziali, che danno potenzialmente vita ad una collaborazione con soggetti non sempre determinabili in termini di identità e ruoli, e regolata da modalità spesso peculiari.

Nel tentativo di sciogliere i problemi sopra delineati, la prima e più ovvia ipotesi risolutiva consiste nel cercare le indicazioni di attribuzione della titolarità dei diritti sui contributi creativi nelle licenze dalle quali scaturisce la facoltà per gli utilizzatori di realizzare i contributi stessi. Così operando, tuttavia ci si renderebbe presto conto che, non utilizzando l’open source schemi contrattuali comuni per qualificare la collaborazione creativa (la licenza infatti costituisce diritti e obbligazioni in capo all’utilizzatore, ma non definisce la posizione di questi in termini di titolarità dei diritti), è impossibile risolvere i problemi di appartenenza sul piano degli effetti del negozio avente ad oggetto la creazione intellettuale.

In seconda battuta, si possono analizzare le norme di diritto d’autore all’interno delle quali viene operata una distinzione tra:

- i contributi che, se sufficientemente creativi, possono costituire un’opera derivata, da tutelarsi indipendentemente dall’opera originaria e senza pregiudizio dei diritti esistenti su quest’ultima, ex art. 4 l.a.;

- i contributi che, quando non sussistano i requisiti per costituire opera derivata, ma siano distinguibili e scindibili dall’opera originaria, sono soggetti all’applicazione della disciplina delle opere collettive, in forza della quale ciascun contributo potrà avere autonoma protezione, mentre autore dell’opera risultante dall’unione dei vari contributi sarà chi ha organizzato e diretto la creazione dell’opera stessa, ex artt. 3 e 7 l.a.; e infine,

- i contributi che, qualora non siano scindibili né distinguibili tra loro, sono assoggettati alle regole dettate per le opere in comunione, in base alle quali il diritto d’autore appartiene in comune a tutti i coautori, ex art. 10 l.a.

Ciò su cui gran parte della dottrina sembra però concorde, è la difficoltà di ricondurre i fenomeni open source ad una (o talvolta ad una sola) delle fattispecie previste dalla legge. Il software libero è difatti interessato da dinamiche di sviluppo molteplici e molto differenti tra loro, e solo un’analisi caso per caso delle stesse può portare alla più corretta sussunzione.

La dialettica creatività / autonomia

La dottrina è invece divisa sull’attribuire, o meno, rilevanza all’autonomia (in termini di funzione assolta dal programma derivato) del contributo creativo nel decidere dell’attribuzione dei relativi diritti.

In virtù della seconda impostazione, tutte le opere di seconda generazione, anche se oggetto di autonomo diritto, sono sempre e comunque dipendenti, con conseguente inibizione di ogni utilizzazione non privata senza consenso dell’autore dell’opera principale.

Secondo la prima posizione (LOFFREDO), invece, il riconoscimento dell’appartenenza di un contributo creativo è condizionato dal grado di autonomia o dalla mancanza di autonomia creativa del risultato elaborato rispetto all’opera originaria. Un intervento principalmente correttivo, privo di apprezzabile sforzo creativo non fa di norma attivare situazioni di appartenenza in capo all’elaboratore. Di contro, l’intervento che porti ad un risultato che ecceda la sufficiente creatività, nel quale cioè non sia più riconoscibile l’identità del codice originario porta ad attribuire esclusivamente l’opera derivata al suo creatore, in quanto si è persa la riferibilità all’opera originaria. In proposito, Di Rienzo fa notare come, in ambito open source, ciò comporti il non prodursi dell’effetto dell’ultrattività generalmente dettato nella licenza che accompagna l’opera originaria.

Ma se quelli appena delineati sono i casi estremi, è intuitivo che i problemi maggiori si pongano per i risultati di tipo intermedio, quelli sufficientemente creativi, ma non autonomi. A questa categoria possiamo ricondurre gli interventi di aggiornamento, miglioramento e adattamento del codice, in parte richiamando l’art. 4 l.a. il quale, unitamente al secondo comma dell’art 7, delinea una relazione dai tratti poco definiti tra autore originario e sviluppatore. Questa relazione può dar vita (alternativamente) ad una delle fattispecie che la legge ricollega alla collaborazione creativa.

Un intervento elaborativo che per funzioni e struttura concettuale corrisponda alla (e si inserisca nella) specifica logica progettuale iniziale dell’ideatore del codice originario (che ha esercitato nella fattispecie un’azione di controllo e coordinamento), è plausibilmente inquadrabile nello schema dell’opera collettiva, con attribuzione dei diritti esclusivamente all’ideatore-organizzatore, o alle software houses o gruppi organizzati di sviluppo. Generalmente quando questo schema si realizza, viene concesso allo sviluppatore il diritto di utilizzare autonomamente la propria elaborazione, ma non in concorrenza con l’opera collettivamente realizzata.

Proviamo invece ad immaginare il caso in cui il risultato dell’intervento creativo sia privo di completa autonomia, ma si colleghi in una qualche misura ad un lavoro precedente senza però essere collocabile all’interno del medesimo progetto di sviluppo. In tal situazione, riservare i diritti ad uno dei due soggetti significherebbe attribuire in entrambi i casi un ingiustificato privilegio. Una possibilità suggerita da alcuni autori è quella di applicare la disciplina delle c.d. “opere realizzate in collaborazione”, che prevede l’attivazione del modello della comunione dei diritti d’autore. Ma questa, che comunque è solo un’ipotesi solutiva, presenta dei problemi di applicazione al software open source, in quanto la più accreditata posizione dottrinale individua nella contestualità degli interventi un requisito fondamentale per definire un’opera realizzata “in collaborazione”, mentre può accadere che le elaborazioni in questione siano realizzate in tempi diversi.

Programmi applicativi: opere derivate?

In dottrina ci si è chiesti quale schema normativo applicare nell’ipotesi dello sviluppo (successivo da parte di un soggetto ulteriore) di un sistema applicativo che giri su di un sistema operativo ideato da altri e divulgato mediante licenza open source. In questo caso non c’è ispirazione concettuale, né nesso di dipendenza, ma c’è logica funzionale (l’applicativo è destinato all’operativo di cui presuppone l’utilizzo e la conoscenza). Secondo un particolare orientamento, a queste condizioni, il software applicativo è da considerarsi opera derivata, con la conseguenza che il suo autore può sì essere titolare di un autonomo diritto, ma solo passando per il preventivo consenso, avente valenza interdittiva, dell’autore originario, allo sfruttamento economico dell’opera derivata. Situazione, quest’ultima, che pare ben attagliarsi ai meccanismi negoziali di gestione dei diritti propri dell’open source software.

Per doveri di sintesi, sul punto ci limitiamo a ricordare che l’atipicità delle procedure di creazione e sviluppo che interessano il software a codice aperto ostacolano e spesso impediscono di individuare automatici collegamenti tra situazioni reali e fattispecie giuridiche. L’attività della dottrina in questo ambito consiste quindi principalmente nel formulare delle ipotesi. Per farlo è necessario altresì analizzare l’ultimo ambito delle problematiche dell’appartenenza open source: quello relativo alle opere originariamente plurisoggettive.

OPEN SOURCE E OPERE ORIGINARIAMENTE PLURISOGGETTIVE

Le opere in comunione

Come accennato poc’anzi, applicare la disciplina delle opere in comunione all’ambito open source dà potenzialmente vita ad alcune incompatibilità, sulla cui effettività è opportuno interrogarsi. Il presupposto primario per l’applicazione del regime di comunione è una collaborazione tra più soggetti nel realizzare un progetto comune caratterizzata (secondo un orientamento dottrinale) dalla contestualità dei diversi interventi creativi e (ex art. 10 l.a.) dalla indistinguibilità e inscindibilità dei vari contributi fra loro. Parlando di software, il richiamo è ad un gruppo di programmatori che lavorano nello stesso tempo, alle stesse porzioni di codice in base ad un progetto di sviluppo.

Mentre in un contesto di software proprietario (si pensi al lavoro quotidiano delle software houses), tale ricostruzione fattuale trova ampio riscontro, in ambito open source, è pressoché impossibile rinvenire una situazione di tal configurazione. La procedura “classica” prevede che inizialmente venga ad esistenza il codice sorgente, e la collaborazione abbia inizio solo in quel momento, per poi esplicarsi in una serie di interventi successivi. Stanti i presupposti sopra elencati, si potrebbe concludere che è impossibile ricondurre lo schema dell’open source al regime delle opere in comunione.

Tuttavia una differente corrente dottrinale ritiene sempre applicabile, in linea teorica, il regime di comunione ad ogni opera realizzata con contributi apportati in momenti diversi, sulla scorta della forzatura di considerare l’inscindibilità un requisito intrinseco di queste opere. Seguendo questo orientamento, il requisito della contestualità temporale della collaborazione si troverebbe svuotato di efficacia e di importanza.

Una posizione ancora differente è quella (esplicitata da Di Rienzo) di alcuni autori che propongono di considerare irrilevante la distinguibilità dei contributi perché si possa applicare, in caso di collaborazione creativa di più autori, il regime di comunione. In questa visione, è sufficiente verificare la presenza di più apporti che si estrinsecano nel risultato di un’opera unitaria. Questo orientamento si basa sullo spostamento della considerazione della dialettica collaborativa fra più soggetti dal momento genetico della realizzazione dell’opera al momento funzionale dell’attività creativa esplicatasi, riscontrabile quindi nel risultato ottenuto come esito della collaborazione e cioè l’opera unitaria. In altre parole si afferma la prevalenza dell’unità funzionale su quella concettuale e del risultato sulle modalità di produzione dello stesso.

Per ricollegarci ai problemi di compatibilità di cui poco sopra, questa visione potrebbe portare a parlare di collaborazione anche laddove l’intervento successivo di un secondo o di ulteriori soggetti si abbia rispetto a contributi creativi preesistenti.

Sempre di Rienzo fa notare come applicare il regime di comunione al software a codice aperto, attribuisca un forte fondamento giuridico all’ultrattività del regime open source, nella misura in cui per cambiare il regime di disponibilità di un bene comune occorre il consenso di tutti i comunisti. In quest’ottica, l’opera open source sarebbe pensata come opera in collaborazione già dall’autore originario ed a tale progetto aderirebbe, concorrendovi creativamente ed autonomamente, l’autore successivo.

Un’altra interessante posizione dottrinale (AUTERI), vuole che quando le modifiche dell’elaboratore si esplichino solo sull’opera originaria, si debba applicare il regime di comunione. Altri, pur uniformandosi a questo assunto, vi aggiungono il requisito che il titolare dell’opera originaria abbia già usato l’elaborazione, creando così un legame collaborativo e funzionale tra i due soggetti e le due opere. In proposito si parla di “comunione a titolo derivativo”. Se questo orientamento divenisse prevalente, assisteremmo ad un considerevole aumento dei poteri in capo all’autore originario in termini di controllo sulle elaborazioni dell’opera originaria, in quanto non vi sarebbe il rischio di comportamenti opportunistici da parte dell’elaboratore, essendo la sorte distributiva del prodotto elaborato da decidersi nel consenso di tutti i comunisti, quindi dell’autore originario. Conseguenza negativa è per contro la nascita di un eccessivo privilegio per l’elaboratore, che non avendo avuto nessuna idea di partenza, si trova contitolare di un’opera nella sua totalità

Le opere collettive

Una delle rarissime questioni (nell’ambito qui preso in esame) su cui sembrano non esistere profonde distanze dottrinali è quella dell’applicabilità della disciplina delle opere collettive ad una determinata configurazione dell’open source software: la dottrina sembra largamente favorevole al ritenere che quando esista una comunità di sviluppo dove ogni programmatore porta avanti un singolo aspetto del programma e i loro contributi (quindi distinguibili) vengano selezionati ed inseriti nel sorgente da un unico coordinatore in vista di una comune logica progettuale, la categoria delle opere collettive appaia la più adatta per inquadrare la fattispecie.

E’ utile ricordare che ai sensi dell’art. 7 l.a. è considerato autore dell’opera collettiva chi organizza e dirige la creazione dell’opera stessa. Questo schema sembra potenzialmente attagliarsi a determinate fenomenologie open source, quali ad esempio il progetto GNU / Linux, caratterizzate da una gerarchizzazione del procedimento creativo. Infatti il coordinatore dell’opera, in quanto titolare dei diritti, ha il potere di decidere delle sorti distributive della stessa e quindi, nel caso in esempio, di scegliere quale licenza abbinare al prodotto finale.

Le opere composte

L’opera c.d. “composta” è caratterizzata da:

- pluralità di autori;

- pluralità di contributi, per i quali deve integrarsi il requisito della distinguibilità;

- la produzione di un risultato derivante dalla compenetrazione delle diverse parti.

La peculiarità, in termini di disciplina, è il riconoscimento, a ciascuno dei partecipanti al risultato, del diritto all’utilizzazione separata e indipendente dei singoli contributi, in forza dell’art. 34 ult. co. l.a.

Diversi esponenti della dottrina fanno notare come tale schematismo di plurisoggettività sembri più rispondente alla fenomenologia open source rispetto a quello dell’opera collettiva. Sanfilippo, in particolare, spiega tale (presunta) compatibilità sottolineando la struttura tipicamente modulare dei modelli di sviluppo tipici dell’open source.

Questa affermazione conferma l’impressione di un ambito di studio che si presta quasi sempre a più di un’opzione interpretativa. Di conseguenza, prendere una posizione significa operare una scelta interpretativa e rifiutare altre possibilità non errate, ma alternative e che altri esponenti della dottrina potrebbero ritenere preferibili.

Quindi, bisogna concludere che anche la verifica dell’aderenza delle fenomenologie open source agli schematismi delle opere plurisoggettive previsti dal nostro ordinamento richieda un esame caso per caso per stabilire quale normativa sia più idonea a disciplinare i rapporti fra i diversi soggetti, con la possibilità che siano applicabili più fattispecie in concorso tra loro.

CAUSE DELL’INCERTEZZA NORMATIVA E FUTURO DELL’APPARTENENZA OPEN SOURCE

E’ significativo che anche ipotesi dottrinali al limite della provocazione concettuale riescano, relativamente al fenomeno open source, a risultare in un qualche modo plausibili in termini di interpretazione del diritto. Questo è dovuto da un lato al fatto che l’attuale dato normativo è ben poco corrispondente alla realtà in questione, essendo questa, per molti aspetti, di genesi cronologicamente successiva alla legge che la regola; dall’altro, alla forzatura sottesa alla scelta politica che ha portato a tutelare il software come opera letteraria.

Ci si potrebbe chiedere perché il legislatore (non solo italiano ma anche) comunitario non abbia ancora intrapreso iniziative di razionalizzazione e chiarificazione della materia, o promosso la stesura di provvedimenti dedicati. Tuttavia non lo faremo in questa sede, anche perché è opinione di chi scrive che questa mancata (fino ad oggi) produzione normativa non sia un fatto del tutto negativo, per i motivi che seguono.

L’open source è un fenomeno in forte espansione, ma con un potenziale di crescita ancora maggiore. Le dimensioni che esso ha assunto fino ad oggi sono ben poca cosa rispetto a quelle che potrebbe avere e che probabilmente avrà fra dieci o quindici anni. Considerati i vantaggi informatici ed economici che potrebbero derivare da una diffusa adozione dell’open source software, non sarebbe sorprendente se il potere politico decidesse di fare del codice aperto (e soprattutto del copyleft) il paradigma informatico - distributivo del prossimo futuro. Anche le questioni di appartenenza sorte finora sono sottodimensionate rispetto alla potenziale espansione del movimento cui afferiscono. Significativo in questo senso è che nel mondo le decisioni giudiziali finora emesse sull’argomento si contino praticamente sulle dita di una mano.

Un legislatore che decidesse in questo momento di disciplinare puntualmente l’open source, potrebbe non riuscire a cogliere la portata della materia e rischierebbe di emanare provvedimenti dalla dannosamente rapida obsolescenza.

Inoltre è attualmente in corso un dibattito sull’opportunità di introdurre in Europa la tutela brevettuale sui software, che ha portato recentemente (2005) anche ad una proposta di direttiva comunitaria, poi bocciata dall’europarlamento. Ciò rivela il rischio di produrre norme riferite alla tutela autorale, per poi assistere all’introduzione dei brevetti sui software, con la conseguente necessità di rivisitare l’intera disciplina.

Inoltre se effettivamente si dovesse decidere di tutelare il software mediante brevetto, potrebbero esserci conseguenze fortemente negative per l’espansione ma forse anche per l’esistenza dell’open source. Se del resto la cornice normativa non dovesse cambiare, prima di disciplinare puntualmente il fenomeno open source potrebbe risultare conveniente attendere il risolversi delle diatribe dottrinali ed osservare lo sviluppo del movimento, così da legiferare con maggiore competenza e aderenza alla realtà, considerato anche che, per il momento, la scarsa “contenziosità” in tema di appartenenza open source permette di ritenere “non urgente” una produzione legislativa dedicata.

L’auspicarsi una normazione attenta, competente e lungimirante, è dovuto alla forte probabilità che nei prossimi anni la crescita del fenomeno open source farà aumentare proporzionalmente le controversie sull’appartenenza del software libero. Questo non solo grazie alla maggiore attenzione che ad esso sta gradualmente tributando l’utenza privata e commerciale, ma anche al fatto che le Pubbliche Amministrazioni di un numero sempre maggiore di Paesi stanno scegliendo di utilizzare software open source per le proprie strutture informatiche, con un considerevole aumento dell’importanza degli interessi in gioco, ma anche dei soggetti partecipanti al movimento open.

E’ evidente che, se si realizzerà il quadro di sviluppo appena delineato, l’attribuzione dei diritti sul software open source diventerà uno dei più rilevanti ambiti di ricerca e applicazione del moderno diritto industriale.