Di chi sono i diritti sul software?

Molte persone attive nel settore dello sviluppo di tecnologie si chiedono: di chi sono i diritti d’autore sul software sviluppato? Dello sviluppatore oppure dell’azienda presso cui lavora? E se c’è invece un rapporto di committenza, come funziona? I diritti sono automaticamente del committente? Come è possibile, come previsto anche dal goal 16, garantire i diritti e le libertà fondamentali anche nel settore software?

Nell’ordinamento italiano, il principio generale è quello secondo cui i diritti d’autore appartengono alla persona fisica che ha creato l’opera, cioè dell’essere umano che ha estrinsecato un’idea creativa astratta sotto forma di opera. L’articolo 6 LDA sottolinea infatti che “il titolo originario dell’acquisto del diritto di autore è costituito dalla creazione dell’opera, quale particolare espressione del lavoro intellettuale”.

A questo principio generale fanno eccezione solo tre categorie di opere, quelle inserite più di recente nella nostra legge: il software, le banche dati e il design industriale.

La direttiva europea sulla tutela del software (dir. 91/250/CEE) all’articolo 2, norma poi ripresa dall’art. 12-bis della legge 633/1941, innanzitutto stabilisce che in linea generale è considerato autore del software e dunque titolare originario dei diritti “la persona fisica o il gruppo di persone fisiche che ha creato il programma”, come avviene negli altri campi della creatività umana.

Tuttavia subito dopo precisa che “qualora i programmi siano creati da un lavoratore dipendente nell’esecuzione delle sue mansioni o su istruzioni del suo datore di lavoro, il datore di lavoro gode dell’esercizio esclusivo di tutti i diritti economici sul programma creato, salvo disposizioni contrattuali contrarie.” La norma ci dice quindi che, in questo caso, i diritti di utilizzazione economica sul software vengono acquisiti in via originaria dal datore di lavoro e non appartengono agli sviluppatori in quanto persone fisiche.

Si tratta di un’eccezione importante (che troviamo quasi identica anche nell’ambito delle banche dati e delle opere di design), che risponde a esigenze sia pratiche sia economiche. In sostanza, il legislatore europeo presuppone che questo tipo di creazioni tecnologiche di norma vengano concepite e create nell’ambito di un disegno aziendale e con un lavoro di squadra, più di quanto avvenga per la creazione di opere più classiche come le opere letterarie, le opere musicali, le opere fotografiche, le opere pittoriche.

Due concetti chiave

Il primo: la norma precisa che quel principio vale solo se non vi sono disposizioni contrattuali contrarie (la legge italiana utilizza la formula “salvo patto contrario”); dunque di fatto la questione viene rimandata ai contratti di lavoro. I contratti nazionali di lavoro del settore informatico non indicano un patto contrario, ma ciò non vieta che i singoli rapporti contrattuali possano inserire una previsione di quel tipo, dal momento che si tratterebbe comunque di una modifica a favore del dipendente.

Il secondo: si dice che deve trattarsi di un lavoratore dipendente nell’esercizio delle sue mansioni. Non basta quindi che l’autore del codice sia un dipendente, ma è necessario anche che lo sviluppo di software faccia espressamente parte delle sue mansioni. Anche a questo proposito quindi la questione va approfondita a livello di contratto di lavoro; è infatti nel contratto di lavoro che vengono descritte la mansioni del dipendente.

Facciamo però attenzione a tutte quelle forme di collaborazione che tecnicamente non rientrano nella definizione di lavoro subordinato e che vengono comunemente ricondotte all’idea di lavoro “para-subordinato”, nei quali lo sviluppatore partecipa alla creazione di un progetto aziendale ma lo fa con un inquadramento contrattuale che non lo qualifica come vero lavoratore dipendente e quindi lo tiene fuori dal campo d’azione dell’art. 12-bis LDA. Pensiamo a situazioni (peraltro attualmente molto diffuse) come le collaborazioni a progetto, le collaborazioni a partita IVA con unico committente, gli stage e gli apprendistati; e in ambito scientifico e accademico le borse di studio, di dottorato e gli assegni di ricerca utilizzati in realtà per “stipendiare” collaboratori che di fatto ricoprono mansioni anche di sviluppo di software. In tutti questi casi non vi è certezza che scatti l’eccezione di cui all’art. 12-bis, quindi per il datore di lavoro che decide di utilizzare una di queste forme di collaborazione è sempre buona prassi inserire nei contratti di collaborazione, nelle lettere di incarico o addirittura nei bandi di selezione un’avvertenza esplicita in cui chiarisce che il copyright su tutto ciò che verrà sviluppato dal collaboratore sarà automaticamente ceduto al datore di lavoro.

E se c’è un rapporto di committenza in cui un’azienda incarica una software house o anche uno sviluppatore freelance di sviluppare del codice?

In quel caso nulla è da dare per scontato, poiché non vi è una norma (almeno nell’ordinamento italiano) che stabilisca a priori che la titolarità dei diritti sia di chi finanzia il progetto. Dunque tutto dipende dal contratto; ed è fondamentale che i due soggetti si accordino per bene sulla titolarità del copyright e possibilmente lo facciano per iscritto (in virtù del principio dell’articolo 110 legge 633/1941). In mancanza di un accordo scritto, qualora emergesse una diatriba legale sulla titolarità dell’opera, le parti dovrebbero ricostruire il rapporto contrattuale attraverso gli scambi di email intercorsi e gli altri documenti (come preventivi, documenti di progetto) da cui emerga chi davvero ha fornito le direttive creative. Una situazione non sempre facile da gestire, in cui si perde tempo e risorse e di cui in realtà si avvantaggiano solo gli avvocati.

Infine, si noti che gli stessi principi qui esposti per il software possono essere applicati, con i dovuti adattamenti e distinguo, anche per la creazione delle banche dati e delle opere del design industriale.

Questo articolo è rilasciato nei termini della licenza Creative Commons Attribution-ShareAlike 4.0 International.