Alcuni medici avevano consegnato a dei programmatori incaricati dalla ULSS delle idee scrtite sulla realizzazione di un software per le gestione e il monitoraggio dei pazienti affetti da dipendenze , per poi crearne una banca dati.
Avevano quindi agito per l’accertamento della titolarità propria, anzichè in capo alla ULSS, della privativa di autore.
In primo grado il Tribunale rigetta la domanda , osservando che <la documentazione dimessa non integrasse il c.d. “materiale preparatorio” del software successivamente sviluppato, oggetto di tutela ai sensi dell’art. 2 c.p.i., dovendo esso intendersi solo come quel materiale che consenta ad un programmatore di passare alla successiva fase di stesura del codice sorgente del programma. Precisava che tale definizione poteva essere attribuita solo a diagrammi di flusso o a blocchi completi, mentre il materiale fornito dagli attori, di cui i convenuti comunque avevano tempestivamente eccepito l’assenza di data e di sottoscrizione, non poteva essere qualificato come tale>.
Va però male pure l’appello, deciso da App. Venezia 07.06.2021, sent. 1665/2021, RG 636/2019, est. Micochero.
La corte veneziana infatti conferma con questo passaggio motivatrio: <<Nel caso di specie gli appellanti, nell’atto introduttivo del presente grado di giudizio, compiono un’opera di confronto grafico tra la documentazione dimessa e le interfacce del programma in questione. Tale documentazione viene corredata da una descrizione avente ad oggetto la paternità del documento, che non era stata compiuta in alcun modo nel corso del primo grado, per cui essa costituisce nuova allegazione, inammissibile nel presente grado di giudizio.
Anche prescindendo da tale descrizione e dalla effettiva paternità dei disegni e degli schemi (oggetto del secondo motivo di gravame), va comunque evidenziato che gli schemi e i disegni riprodotti non possono essere qualificati come materiale preparatorio della fase di progettazione, come asserito dagli appellanti. Va infatti evidenziato che il software “….” è il risultato di un progetto denominato “….” voluto dalla Regione Veneto con delibera n. ….seguendo le linee guida dell’Osservatorio Europeo sulle droghe e tossicodipendenze, e affidato, per il suo sviluppo, alla ULSS ……. per migliorare il trattamento dei pazienti affetti da tossicodipendenze e ottimizzare le attività assistenziali del …. Ai tre medici che lavoravano presso il Dipartimento per le dipendenze della suddetta ULSS fu dato l’incarico di seguire il progetto, ed, in particolare, al …., fu attribuita la qualifica di direttore tecnico scientifico e di coordinamento del progetto. Risulta quindi evidente che i tre medici abbiano posto in evidenza quale dovesse essere lo scopo e l’utilità del programma, indicando ai programmatori (……) quali dovevano essere le informazioni che lo stesso doveva fornire, giungendo anche a suggerire la veste grafica più idonea allo scopo.
Tuttavia detta attività ancora non integra il concetto di lavoro preparatorio di progettazione perché, come correttamente spiegato nei considerando sopra riportati [N.d.s.: cons. 7 e 11 della dir. Ue 24 del 2009] , in quanto esso già presuppone l’utilizzo di un linguaggio tecnico che permetta al programmatore di procedere immediatamente alla realizzazione successiva dei codici sorgente. Rientrano in detto ambito i “flowchart” – diagrammi di flusso – che già presuppongono una dimestichezza con il linguaggio informatico (algoritmi) e che permettono al programmatore di realizzare direttamente le stringhe nel linguaggio informatico, essendo diretti a creare una rappresentazione grafica delle operazioni da eseguire per l’esecuzione di un algoritmo. I documenti dimessi non sono, all’evidenza, diagrammi di flusso, ma costituiscono nient’altro che una spiegazione del risultato che si voleva attenere con il programma, una indicazione specifica ai programmatori su ciò che il programma doveva fornire all’utente. Ne consegue che essi non possono assurgere alla qualità di “lavori preparatori”, anche se riferibili ai tre medici>>.